Serverless computing is a really new and very trans formative change that allow companies to grow and scale their businesses very quickly. Serverless computing done correctly has the potential to dramatically increase development velocity, and reduce costs. In my blog post, What is Serverless Computing I covered what it is and some of the vendors that are available.
Adopting serverless computing makes a lot of sense for companies, but there are steps that you need to do before you can begin moving to serverless technologies. One of the first things to make sure you and your team understand is that serverless computing is primarily event driven and functional programming has the potential to make things a lot easier.
Before beginning to switch to serverless computing or before building anything using serverless computing there’s quite a few different things your company should consider and do.
Understand how Microservices Work
Before doing anything, I strong recommend you take the time to consider and learn how microservices work. Microservices are a variation of the service oriented architecture that strongly encourages loosely coupled services. In general, microservices share very little to nothing. Josh Evans from Netflix has done a lot of really good talks about how the architecture has changed things at Netflix.
Microservices are hard to architect and get working correctly. It’s very easy to end up with a very large mess without taking the time to have a plan and understand how existing systems work.
Have a Plan
Before any development should begin, you need to have a plan that involves the existing documentation and any requirements. I strongly recommend documenting how functions will communicate to one another as this will have a huge effect on how your system performs. For example, using a Queue or Stream to perform the communication means that one function won’t know if the function has completed yet. If you have the functions communicate directly with one another then you will have two functions both consuming resources at the same time.
Document Existing Systems
Before beginning to make dramatic changes to split a monalith or before deploying things to new environments, make sure that you have documented how the current system actually works and add a lot of tests. In the book Working Effectively With Legacy Code, Michael Feathers explains some of the different ways to make sure you understand how the system works. It might make sense to give this book at least a quick skim over before making dramatic and breaking changes to your existing code and processes.
Start Small If you have existing systems
If your company has existing systems, don’t try to migrate everything to serverless computing in one process. It will fail, and your company will probably fail as a result. Instead, take an iterative mindset and start with small little pieces that can be broken off piece by piece. I recommend looking for something that isn’t essential and can be converted in a couple of days – something like your company’s job board or something like an image or document processor.
Also, have a very good understanding of your application’s state and sessions – serverless computing needs to be completely stateless.
Get The Requirements for Any New Systems
I’m really not going to cover too much about getting the requirements, but make sure you have them and understand what the requirements are. How long should responses be, will you be uploading large files, etc. There are constraints that AWS has added to the API Gateway and AWS Lambda that can become a burden, for example, there’s a limit of 10 megabytes in the body of a post request and there’s a limit of 1536 megabytes of RAM.
Investigate Available Vendors
As I mentioned in the gathering requirements post, there’s lots of little constraints you may not notice at first with each of the vendors. I have only worked with Amazon Web Services (AWS) at this point, but I’ve been hit by lots of little quirks I didn’t know about didn’t notice because I didn’t spend all of the time I should have on gathering requirements and reading through the limits of the platform. AWS’ documentation is pretty hard to navigate – it’s usually easy to use a search engine like Google and do searches to find constraints.
Serverless Tooling
In the serverless computing ecosystem, there’s very little in the way of tooling outside of the Serverless Framework. The serverless framework can package code up and deploy it with most if not all of the major vendors. If you plan on using Node.js / JavaScript and the serverless framework you should be relatively set for being able to do automated testing with some of the various plugins and using mocha or chai to test.
Also published on Medium.
