Deploying to Serverless? It's not that easy

So you have a new web app and want to deploy it to your favourite cloud computing provider. You’ve heard about Serverless and how it might save you hundreds of dollars a year in hosting fees.

So why not go ahead and deploy it to Serverless? Who wouldn’t want advantages like these?

• Not having to deal with infrastructure (at least not server instances)
• Security best practices baked into the whole experience
• Scales pretty well
• It’s the cool thing to do these days

Well, unfortunately it’s not that easy.

Maybe you’re using one of the server-side rendered web frameworks like Ruby on Rails or Elixir Phoenix. Maybe your dev team felt adventurous and chose Node/Express for your backend that acts as an API to your React frontend. It doesn’t really matter.

Problems everywhere

One of the things that’s most likely going to haunt you is your database*. You’ll still need an instance of your MongoDB or Postgres running and it will still cost you 24/7–the very thing we’re trying to eliminate.

Unless of course you picked a DynamoDB, Cloudant or one of the other serverless-ready distributed database technologies. My guess is you wouldn’t be here reading this if you did.

And even if you say costs are not the issue (yeah, right…), you’re still in a world of pain trying to get your lambdas to talk to the database. There’s complicated network routing required and it comes with its own set of drawbacks.

On the other end, squeezing your entire app into a lambda function is also very likely not going to fly. Although you can often bring your own runtime, there are size limitations that will probably prevent you from doing so.

Serverless is a new paradigm to write backends for web apps, APIs or data transformation workflows.

It’s similar to deciding on any other web framework really. You make that decision once and you stick with it.

Serverless means heavily relying on the tools of your cloud provider of choice and combining them in various ways. It’s a little bit like playing this funky little minigame inside of Bioshock where you have to direct a stream of water with lots of different little pipe elements.

In a way your cloud provider is your web framework toolbox and you pick the tools at your disposal that get the job done.

What now?

Well, you could always do a re-write, but that’s probably not the answer you were looking for.

Let me give you a better answer. Deploy your app the traditional way and start bringing parts of it piece by piece over to functions by extracting micro services.

What parts of your app are work-intense, ideally asynchronous processes that you’d be happy to remove from your monolithic app anyway? Bingo, those make for great candidates.

Alright, that wraps it up. In one of the next posts I’ll touch on a few things that you could outsource to serverless functions.

Ready for some examples of micro services that lend themselves well to the serverless paradigm? Read part two here.

* There’s a serverless flavor of AWS Aurora available (MySQL and Postgres). So technically you could turn your Postgres serverless. The other problems still persist, though.