If you are reading this post in July 2016 (when the post was written), you will probably agree serverless architecture is H.O.T right now.

Although the concept has been well used for quite sometime, we now have an alias and title associated. So as a result we have a meetup we can now go to, a conference where we can be preached to and of course this all leads to the proverbial bandwagon to jump on. - This is where we are right now, so lets ask the question What really is Serverless Architecture and how and when should we use it.

What

To begin with the name serverless can be a little misleading. But in short, it's typically a small application or unit of work that itself and its dependencies run on server's that you don't manage or concern yourself about.

But what's new about that right? Prior to the recent #devops movement, developers never really concerned themselves about consistency, availability and partition tolerance anyway.

But serverless takes it to the next level in the form of BAAS and FAAS where there is absolute no consideration to scaling and availability. Your cloud provider takes care of this with a typical 4x9 uptime SLA.

But for a better definition and insight to this, Martin Fowler and thoughtworks will give you greater detail than I will. - And it really is comprehensive. This in itself suggests the relevance of serverless and its expected impact in future software solutions.

How

FAAS

Functions as a service is quite simply a method of executing code, or a unit of work, as a service.

Serverless can often be better known as FAAS. Demonstration by the tweet below; it's certainly a common opinion.


I for one first started seeing the term used more often when last year AWS released [API gateway](https://aws.amazon.com/api-gateway/), a managed service that alongside Lambda, offers "serverless" APIs.

The benefits are obvious, just as PAAS has brought cost effective benefits, FAAS gives you a similar model. You pay for how much you use.

BAAS

Backend as a service is a simlar approach to FAAS but at a larger scale and covers more domains. A classic example is using authentication as a service. Auth0 for example packages all the complexities involved as a oAuth provider; token persistence, user management, token serialisation and offers it as and when you need it.

I've come accross many custom implementations of oAuth, open Id and identity providers and all have their own faults. - Due to the complex nature of the topic. - Its a perfect candidate to offload to an expert.

But there are many more use cases. Consider the regulations you have to oblige to when implementing payment providers or simply taking your end users personal details.

This isn't just a solution for lazy software developers, this is a smart product decision to offload business value to an expert.

When

The problem I have with this architecture, whether we are using AWS Lambdas or Azure functions, blob storage or an S3 Bucket. We are building software driven by a chosen cloud provider.

My concern with building software cloud first and tying your product to a 3rd party, is less about availability and more about losing control.

AWS for example sets the minimum supported node runtime for lambdas, what happends when they decide to increase it? All of a sudden your application needs a rewrite.

Although cloud provider costs are compelling now, what happens if this changes and your tied to a given cloud platform? It quickly becomes unsustainable.

However, serverless and the adoption of the cloud offers excellent value and current pricing tiers for serverless features/products, allow us to build enterprise solutions on startup budgets.

... enterprise solutions on a startup budget

These are some considerations not to overlook when choosing to adopt serverless architecture. We're currently using it quite successfully but as always there are tradeoffs to consider. I hope blog a followup, detailing the tradeoffs and disadvantages I have experiences.

Please share your links and examples below and thanks for reading.