Why “serverless” architecture isn’t the HOLY GRAIL (yet)

If you are a hacker, and somebody walks up to you and offers you these 3 benefits :

1. Pay per execution (with a generous free tier)
2. No server management
3. Infinite scale

There are good chances that you’d want to check it out. Even more when the company offering you this is none other than Amazon.

Amazon Lambda is a service which is picking up momentum for the above mentioned reasons, and no doubt, it’s a marvel to be able to provide that.

On top of the benefits, they also allow lambda functions to be triggered by aws ecosytem events, not just http. So you can run a ‘image optimization lambda’ when a user uploads a profile picture or a ‘welcome email lambda’, when a new record is created in users table. And all of that in js, java or python.

But, the benefits come with their costs. Costs that might be too high for a trade to occur. The tradeoff in this case is a cumbersome deployment process. In order to achieve the benefits, each module of your app is hosted as a service (or a function). For example, if you come from REST API background, then think of each route, as a function, hosted separately, in an isolated container.

While this gives you a lot of power, it makes a few traditional things very (very) hard. These are :

1. Sharing dependencies (and configurations)
2. Deployment (imagine git push lambda users/create master; git push lambda users/update master; …)
3. Local testing
4. No right way of doing things — the field is nascent

Naturally, to solve the pain, an ecosystem of tools and frameworks has sprouted up. If you are new to the serverless scene, you should checkout frameworks like serverless, chalice, gordon, kappa, Apex and many more. All of them solve basic problems of deployment almost completely.

It’s dependancy management and local testing that is still a pain. Even more so is competing standards ie. no right way of doing things.

Dependancy Management

All lambda functions are zipped into a file and then uploaded to aws, with some cloudfront templates magic, api gateway configs, stream config so that your lambda is accessible via http and gets triggered.

And all functions are run in a container, so unlike express or flask or celery, where I can define dependancies in the package root, I have to:

1. Either define dependancies for each service separately
2. or somehow make each service share the global dependancies

The first approach is cumbersome and convexly focusing. By taking the first approach, you work only on a service, not caring about how other services work like. This scenario is ideal, but in reality, at some point you’d get stuck and will need to interact with other services. This is the right way of doing things.

The second approach is a lambda anti-pattern. Because all lambdas are zipped and uploaded, and downloaded and unzipped at runtime, it is required to keep the zip size small, preferably, only include the dependencies required by that specific function. But it is hard to cherrypick dependancies.

This was our deal breaker. The normal application model, where dependancies like db models, and configs are shared at application level is an anti pattern when it comes to lambda. We felt it’d be very hard to change our motor instincts (but we’d try to), so we have given up on lambda for now.

Local Testing

Consider a scenario where I use a dynamo db stream to trigger a lambda (streams are just notification of an update, insert or delete that occurred on a table). Ex: Resizing a picture after it gets updated in users table.

This is virtually impossible to test, without deploying it to lambda. Yes you, can write tests, but that’s still slow. A usual lambda takes anywhere between 40 seconds to 3 minutes to deploy. Now imagine you making 8 changes to a file. That is 8 * 1.5 minutes (median deployment estimate) = 12 minutes. Any significant project can easily have 1000s of files with a dev working at 20–50 files at a time. That is approximately 35*12 = 7 hours of deployment time.

Yes, once you get past the initial architecture, you’ll be saving tons of money, and have reliable and less moving parts, but reaching that level, I feel is a huge pain.

We planed to develop a serverless architecture, but gave up, after facing these problems. But we are optimistic that it’s a good time to get into serverless, and we will definitely try our luck again.

No right way of doing things

The serverless field now is what web app development used to be before Ruby on Rails. We need an MVC for serverless architecture.

In times to come, a standard solving the given problems will show up. I’m waiting for that day to happen. That will be the day, when you could actually reap the benefits without the tradeoffs.

In a nutshell

> Is serverless good for all kinds of development ?

It might be. As of now, it’s good for rest apis and pathetic for background processes. It’s almost magical for frontend apps. You should definitely use them on the frontend.

> Does serverless means no dev ops ?

Yes. But it increases the costs of programming and code management, until a standard approach to solve standard problems surfaces.

> Where should I get started ?

This talk by Austin Collins, the creator of serverless framework (don’t confuse this with serverless architecture) and this talk about Amazon’s Chalice is a good starting point. (Just don’t get too excited to incorporate this into production)

> Did you make something from it ?

Yes, I made the mistake of getting to excited and deciding to pull it into production and wasting a weeks time on it.

> What did you learn ?

The way we think of app backends is about to change dramatically. This is the right time to ride on the wave.

> What do you suggest ?

I feel just one lambda for the entire app, is what will work. Expose graphql on that lambda.

> Is serverless for beginners ?

If you have to ask this question, then it’s probably not for you. But keep learning and reach a point where you don’t have to ask this question.

> Who are you ?

I’m a self taught software architect, a story teller and off lately a sales man at Proposl.

> Do you want to work with us ?

Maybe. I sometimes run out of money and look for contract work. You can reach me on linkedin or comment on this post.

> Hey, you missed out on “x” !

Sorry about that, please tell me what I missed or got wrong and I’ll fix it.

Thanks for reading. Peace.

--

This article was originally published on Medium. You might also want to read :

* 14 Life Lessons Learnt After 1 Year of Graduation

* When prospects don't respond &

* Love