Is Serverless for you ?

One of the more recent architecture choices we can play with is the idea of serverless aka FaaS (Function as a Service). Thankfully, it is not hyped like say Machine Learning is. But nevertheless, it is widely misunderstood – often leading to bad design choices. I am just going to list a few questions I have been asked often (or I have asked fellow techies) , and give my point of view on those. I will try to keep this at a level where it makes sense for people who are not full time technologists .

Are there really no servers?

To begin with the name serverless itself is quite misleading. Your code does not execute in vapor – it still needs servers. From a developer point of view – you choose a provider to handle a lot of things servers do (but not everything) , and you can focus on your application tasks. That is not the same as there being no servers. Its one of those things where my developer friends smile and wink, and my Ops friends roll their eyes 🙂

Is it really much simpler than other options ?

A very hard question to answer with a YES or NO. If we look back 10 years or so, it was all about service oriented architecture (SOA). Now think how many well designed services were created in the time since then ? I personally have seen way more badly designed/implemented services than good ones. My point is when you try to deconstruct an existing application into smaller ones – it often (not always) becomes more complex, not more simple. I know it is counter intuitive till you think through it, or work on an actual project. The simplicity argument is strongest in favor of FaaS when you eliminate server management from what a developer has to worry about – but even there, you need to be careful about where the server logic goes. Sometimes you implement it in client, sometimes you move it to the function, and some times you need dirty hacks to keep everything working. Simplicity is in the eye of the beholder.

It is cheaper ?

When used for the right scenarios, it is indeed cheaper. The obvious case is bursting – where once in a while you get a lot of traffic to handle. If you are not careful about designing – and especially if you don’t test with production level data, its quite possible that you may end up with a more expensive solution than having to deal with full time server management. That is hardly unique for serverless though. Poor choices have a price to pay now and/or in future.

What does the developer not have to worry about ?

For the code implemented as a function, the provider ( like AWS Lambda) takes care of making sure it will get executed when triggered. So things like horizontal scaling, fault tolerance and high availability are things you don’t need to worry about. Needless to say, you have to make sure your code is friendly for parallel execution. And it is still on your plate how the application as a whole works – Lambda etc only controls what you passed on to it. So developers can enjoy more breaks ( or officially , they can work on making their app so much better ) 🙂

Also, if your server code is in java – which is true for many cases – you save a lot of time because you don’t have to redo the whole code. You can lift and shift with low effort. Another thing to gain more coffee breaks !

Also, API gateways become a good friend for developers in mapping parameters to and from functions. This makes development and maintenance more efficient in many cases. API Gateways themselves are fairly new too – so there is that. I guess you can also consider authentication to be implemented via the gateway – but my security expert friends may not like this idea. I need to think through this one more.

What is the big difficulty for developers in FaaS world ?

If you are like me, you spend more time debugging than actually writing code. As with all distributed computing scenarios – you have a tradeoff to make here. As we introduced these paradigms in quick order, the monitoring and debugging tooling has not kept pace. So the first movers typically spend more time debugging across all the layers without useful tools and it can be quite frustrating and inefficient.

How about testing ?

Since computing is distributed, you should plan for higher quality of testing in general. Its also about setting expectations with testers and users. Since the server is not always on waiting for a request – it needs to be switched on every time, and then it stays on only for a few minutes. If you have a lot of near real time needs, implementing it as FaaS is perhaps not the first option to cross your mind. Also – a lot of dirty hacks get introduced while testing if you are not careful with designing. A common one is to keep pinging the service to keep it awake since you realized some tasks take longer. You really need a close approximation of production peaks and valleys in testing to make sure you don’t get a midnight call to debug.

isn’t FaaS stateless ?

Short answer is yes , of course. But often we need some hack to hold state – usually by using a cache or database . Some logic on session management could be in client side too.

Is AWS Lambda the only option ?

Lambda is definitely the most popular and have been in the market the longest. But a lot of big players like IBM (OpenWhisk), Miscrosoft ( Azure functions) and Google ( Google cloud functions) . So you do have choices – they all have different things they support, but probably will converge over time. I will resist the temptation to talk about standardization 🙂

So what is a good place to start ?

Serverless is a newbie in the world of architecture – so proceed with sufficient caution. Since my playground is in large enterprise space, what I have seen the most is large existing apps offloading small parts of their functionality to functions. Those companies who have embraced DevOps also consider serverless when they create new apps . At the moment, I don’t expect to see a lot of pure serverless architecture options in large enterprises. Some kind of hybrid approach is probably where we are headed. Once the tooling gets strong, I am sure we will see definite patterns emerge.