What is Serverless Architechture

TL;DR – There is a server. It is not a “my-on-premises-Linux-box” kind of server, but there is one at the end. Perhaps it is just not yours and looks and feels a little bit different from the developer’s perspective.

 

server unavailable

 

The Buzz-Word

What would you answer if I asked you what is our industry best at? Well, I personally don’t know what we are best at, but we are definitely very good at creating buzzwords. The recipe for a perfect one would be to take some terms we all know and love, tweak them a little bit and use it to describe a completely different thing.

The new buzz-words in the industry today are ‘Serverless Architecture’. We can all imagine something when we hear our colleagues say the word ‘Server’ at the water-cooler. If you are a more traditional Desktop oriented developer, you probably think about a physical server-box that might be sitting in the next room. If you are a Web developer, you might be thinking about a Reqest\Response type of server that is running some server-side technology like ASP.NET or NodeJS.

In any case, when you hear ‘Serverless Architecture’ you probably think about an Architecture that has no Servers. So, are we back to rich client desktop application that only talk to a database? Or maybe the clients will talk between themselves without a server? Perhaps some new peer-to-peer oriented technology?

Well, that’s how you know that the new kid in town is misleading – it means something completely different from what it seems.

 

The General explanation

How we generally imagine our architecture:

client server arch

 

I am simplifying here in favor of clarity, but a ‘Serverless Architecture’ basically means that the server as YOU know it is gone. The server in general is still there, but it looks and feels a little bit different from the developer’s perspective. It is somewhat of a redefinition of the word Server.

Some may think that this is a natural turn of events. As in everything, we always have opposite forces that pull to other directions, but eventually, after a turmoil, we find an equilibrium in which those forces lay still. In our case in Software Architecture, there are 2 major forces – one that states that the “Server is God” and the other states “Client is God”. As with anything else, non of those forces are “correct” so to speak. The are many good reasons why for so many years the Server ruled the world, and now with the advancement in computing power and client side capabilities, we are shifting quickly in to the Client oriented architectures. In this new world the the server simply provides discrete, stateless functionality for the Client.

In the last 10-15 years we’ve seen the server becoming an external worker, sort of a contractor that provides discrete functionality for the Client. We migrated the business state of our applications from the Server to our Clients, so the server only comes in to play when the Client needs some specific functionality like Persistence, Authentication or heavy-weight calculations. The clear evidence is in the popularity of Microservices these days (another buzz-word, I know). So developers started breaking their monolithic Servers down to little independent pieces where each piece will perform a specific task (or a Service if you will).

Naturally, when one of the forces has its momentum, we are shifted to the extremes. In our case, the extreme is the ‘Serverless Architecture’. We decided that a Service is not a discrete or lightweight enough backend, so what is the next stage of diminishing the backend? The next stage is to break those services into even smaller pieces like functions. Yes, as in a function should become a service with an endpoint. It has an input, it performs a task and maybe emitting some output.

So we started by taking away the state from the servers, they became kind of one-time contractors per specific input. No state. Then, if the servers have no state and they only perform specific functionality, why should they exist as an integral piece of our system? Can’t we just break the functionality to a more granular level and then outsource that functionality to a third party vendor? We can. That is what ‘Serverless Architecture’ means.

 

BaaS vs. FaaS

Some of the literature out there is calling ‘Serverless Architecture’ different names with a slightly different meaning, but the general idea is the same – you should not write your server logic and maintain a server (or Service if yo wish), rather you can delegate that functionality to 3rd party vendors like Amazon, Microsoft, Google or any other vendor.

BaaS – Backend as a Service. The more popular use of this term would be with a Mobile backdrop, so BaaS becomes MBaaS. You basically develop your mobile application while using services like Firebase for real-time DB, AWS Cognito for Authentication services and so on. This type of ‘Serverless Architecture’ is not new, and many articles have been written around that topic.

FaaS – Functions as a Service. This is the new kid on the block. In this case you can consume server side functions without developing your own server, maintaining its code etc. You deploy business code, and that is the only deployed piece of software that you are responsible for. The rest will be provided for you as a service with endpoints.

So a Serverless application may look something like this:

serverless arch Fowler

(Taken from MartinFowler, I advise you to read the full article by Mike Roberts)

 

Pros and Cons

 

There is lots of literature out there regarding this, so i’ll just mention some key points:

If you need a responsive UI, you need to think twice before responding to user events by using FaaS because this will incur additional setup time for the remote function instance. Your function is not a server, it is not sitting around waiting for your request. Using FaaS in this case may present additional latency to your application.

On the other hand, if you are posting messages to a remote and asynchronous message queue, the FaaS provider may set-up a bulk of function instances to process your messages backlog and after it finishes processing the backlog, the function instances will be torn down.

Moreover, think about the DevOps effort that might be saved for you? All you have to do is deploy some kind of package to the server, and instruct the vendor to deploy your new function code. That’s it. The vendor becomes your DevOps guy on demand.

 

The Biggest Providers

So who are the biggest providers of Serverless functionality? Obviously, the biggest companies are up on the wagon.

You can also find many small firms starting to deliver services in that area.

 

Further Reading

 

Feedback is welcome!
Shonn Lyga.

About Shonn Lyga

Obsessed with anything and everything in Software Engineering, Technology and Science
This entry was posted in General Software, Software Architecture, Software Concepts, Software Design, Uncategorized and tagged , , . Bookmark the permalink.

2 Responses to What is Serverless Architechture

  1. Nik says:

    Good one Shonn. I recently was on a talk that explained how Facebook runs its “servers”. They are really just bare bone $200 motherboards with absolutely bare essential chips glued onto them. They don’t have the shiny cabinets, they don’t have PCI cards, they don’t even really have fail safes! If the state is not on there the failover doesn’t really matter as long as there is another device ready to start crunching numbers! So basically big enterprises such as FaceBook are also on the trend of moving away from servers. There is an excellent book titled The Big Switch that provides some very compelling arguments and visions of how cloud computing would soon be as ubiquitous as electricity and thus making servers obsolete.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s