Three Great Serverless Use Cases
The design patterns for serverless functions that are here to stay
Serverless was one of the buzzwords of 2017, but more than that plenty of organisations went ahead and implemented these technologies. Others have plans in the pipeline or a prototype underway. So which shapes of architecture problem are a good fit for a serverless solution? TL;DR Microservices, data transformation, and enabling frontend/mobile developers to change the world.
APIs and Microservices
An image-resizing microservice is the classic use case for serverless technology because it’s a pretty excellent example! The suitability of serverless technology to this sort of application is two-fold. Firstly, delegating any sort of processing away from the main application is a win, and serverless is ideal for processing variable workloads since the platform scales to meet the demands put upon it. Image resizing will usually fit within the limited memory and execution time typical of the serverless platforms, and each unit of work is independent of all the others. Compare that with the overheads of keeping a server with a fixed capacity running, and a queue to handle any bursts in traffic, and the serverless option starts to make a lot of sense.
The other reason the image-resizing microservice is ideal is because APIs (or to give them their thought leader name “microservices”) and serverless are a natural fit. Write a single serverless function and wire it up to an API Gateway — and you instantly have an API endpoint. Rinse and repeat to create an API consisting of as many independent endpoints as needed for your API or microservice requirements. In a more traditional programming approach, it’s common to see the microframeworks such as Flask, Express or Slim used to provide the routing. With serverless, the API gateway provides the glue, and the actual code (a.k.a., the interesting bit) is in each individual action rather than in a series of callbacks.
The most compelling reason that developers build APIs this way is scalability. If your traffic is small, at least to start with, then your costs will be low since serverless is charged by unit of execution time. In either a rapidly-growing or a bursty environment, the ability of the platform to grow to meet current demand is very valuable and avoids needing to keep a lot of servers running with empty headroom “just in case”.
Data Pipelines and Transformation
One success case for serverless that I’ve come across several times this year is for moving and processing data. We work with increasingly large datasets, and so the pursuit of scalable processing is key in this area of the industry. Distributed approaches such as MapReduce work really, really well here — and serverless is a great way to implement a distributed approach. For working with a constant stream of data, serverless is a very accessible way for someone with a little coding knowledge to be able to apply processing to the data as it comes past. For one-off batch migration or transformation tasks, such as data cleansing, serverless is even more compelling. It’s still approachable, but in between batches the platform doesn’t cost anything while it isn’t being used. With a more traditional setup, you’d provision that beefy platform and be paying for it in between batches of data or keeping it running with spare capacity that might not be needed.
Most of the mainstream serverless platforms support Python. Python is an approachable and humane language with top-class support for data science workloads due to its large number of brilliant maths-oriented libraries. These won’t all be included on every platform by default, but these extra libraries can be supplied alongside the serverless function code when we create the function. For any situation where the processing can be broken down into independent units of work where the output of one unit doesn’t impact what comes later: then work can be parallelized and serverless becomes an excellent candidate for making that happen.
Just Enough Serverside Code To Be Dangerous!
To deploy a web or mobile application today requires knowledge of a huge stack of technologies. Every developer has their own specialisms, whether it’s theme building, mobile accessibility … you get the idea. What serverless technology brings to the table is a simple way for developers who are not serverside experts to implement any small features they need — independently. This echoes the point above about the platform being approachable to data professionals, who may also be experts-of-disciplines-other-than-backend-code. You’ll often hear the serverless technologies described as “NoOps” which isn’t accurate; there is a large quantity of excellent automation taking place here! However as a developer, I don’t need to worry about installing, securing or administering the server. Removing this large hurdle opens the doors to many developers to get done what they need to do without learning so many more skills.
Enabling the mobile and frontend development crowd to build anything they can write the code for, without the need for learning how to administer a Linux server securely? This is the beginning of a sea change in the industry. With both JavaScript (on almost all serverless platforms) and Swift (on IBM Cloud Functions and other Apache OpenWhisk platforms) widely available, serverless opens doors to professionals who are already building great things. By enabling them to build something that can hit a data store or keep an authentication key on the server, many more applications become something that can be built without external help, paying for access to a third-party service, or lots of studying.
The learning curve for serverless isn’t steep. This change might take time to propagate through an entire web development industry, but this change will change much of the work we do in the coming years. Serverless enables such a great community to build so many things … watch this space!
Serverless and the Future
Today’s post is a high-level overview of some of the best-fit applications for serverless. Hopefully it’s also sparked some ideas for your own development, and also given a starting point if you’re new to serverless. Serverless may have been a buzzword in 2017, but in 2018 and beyond it’s a tool in the toolbox that is here to stay.
