Serverless architecture – pros and cons [BoilingFrogs2017 #2]

Serverless architecture – pros and cons [BoilingFrogs2017 #2]

Emilia Tyl bio photo By Emilia Tyl Comment

Hi guys! Welcome to the second part of notes from the BoilingFrogs conference. I have so many interesting topics to write about, but firstly I wanted to finish this little series, as I don’t wanna waste that notes that I took during lectures.

In the last conference post I wrote about first two lectures that I found really great. I saved the juiciest one for today. Serverless architecture – also a hot topic, one that I was really interested in lately, just to check if it would profitable for us to use it for our games at work. My conclusion was that it wouldn’t be, but still it was great to hear all about it from someone who had little fun with (although he didn’t use it in production).

What is serverless architecture? For me it’s combining small functions running in cloud to achieve backend functionality. It’s even more micro then microservices. It’s when you need some work done, but you don’t really bother writing a big fat backend server. There are already complete, commercial services, which offer for example user authentication or in general – CRUD operations on some collections. Some examples are Firebase and AWS Lambda (the latter I utilize on production for some maintenance tasks).

What did I learn during the great talk performed by Michał Kurzeja?

First of all, when utilizing serverless architecture, we need to redefine our way of thinking about writing apps. We are able to write small chunks of code that can be run. These chunks share some common features:

  • no real disk access (in AWS we have 512MB),

  • stateless and cannot share anything, there is no cache,

  • ephemeral – cannot run for too long, functions are run in containers and when the time passes – are killed,

  • easy pricing model – GB-seconds, it’s used when a function utilizes 1 GB of RAM during one second, it’s scalable thanks to that too.

Also, AWS has many cool features that could be used when running BaaS (backend as a service), like API Gateway, S3 for storing files, SQS – queues, Cognito – authorization. The lecturer talked about many generic use cases that are present in almost every application and are kind of mundane, like processing logs and generating miniatures for a website’s pictures. At this point I kind of had a feeling that the presenter was bribed by AWS to just glorify its services, because he was talking about all of that like it was the best thing in the world.

Thankfully at the end of presentation, there was a great recap of pros and cons of serverless architecture:

Pros:

  • easy to learn,

  • reduced time to market,

  • lower cost (really?),

  • microservice way,

  • easy to scale (aren’t all cloud services easy to scale?),

  • fits into sprint iterations (many things do).

Cons:

  • vendor lock – in, but there are frameworks that make it easier to switch between them,

  • communication overhead – the same case as concerning microservices,

  • cold start – it you used Heroku’s free option you know that feeling ;) - to run maximally efficiently, JVM needs a little warm up,

  • a bit harder to test locally,

  • not always cost efficient.

In conclusion – there are many interesting use cases for BaaS, but it will not always be the cheapest solution.

Fun with Lambda

From my experience, there are many neat solutions that you should take note of. I’m personally using AWS Lambda for two things. One is backups of my database machine – the function is run once a day and it takes a snapshot of an instance. Restoring machines from such snapshots is really fast and easy. When AWS fucked up one of my servers lately, I set up a copy of it in like 3 minutes.

Tip: when your application stops responding and you cannot access it via SSH, and also when you try to reboot, it gets stuck on “stopping” state – it means something like “some at AWS tripped over a cable and you’re machine is broke down” happened and there’s nothing you can be apart from cloning the broken machine.

That actually happened to me once, when I thought “what a wonderful Friday”, entered an office and saw an alarm email. : ]

Thinking about that day even inspired me right now to draw this picture:

1

My second use case is turning on and off the staging server. I keep it running during the office time, then it goes down to save precious pennies. Of course there are plenty of ways to achieve that, but setting up Lambda functions is really fast and straightforward.

And as always - like my fan page or follow me on Twitter to get notified when future posts appear. (。◕‿◕。)

comments powered by Disqus