Developers are building production-ready applications faster than ever. Businesses are getting products and services to market at record speed and cost. And they’re doing it by going serverless.
To begin with, let’s clear one thing up. Serverless architectures still require servers. It’s just that developers don’t have to think about those servers or the process of scaling them. All they have to think about is delivering business value to customers.
Cloud computing has always been about abstraction. Serverless takes that abstraction and turns it up to 11… automatically. Businesses should be focussing on delivering their products and services. Not managing servers or infrastructure. These things, unless you’re a public cloud provider, aren’t where your business value lies.
When you send a parcel to a customer, do you really want to provision a van, hire a driver and plan a route? Of course not. You just want to throw a stamp on it and give it to someone else to deliver. If traffic is bad, you don’t want a call asking for your opinion on the best route to take.
The same applies to delivering your products and services. This isn’t always possible of course (maybe you need more control over the environment for security or compliance reasons) but it is the ideal situation for most businesses.
Evolution of Cloud Computing
Before we take a look at some of the benefits of serverless, let’s see how cloud computing has evolved.
Infrastructure-as-a-Service (IaaS) was the first cloud computing offering. IaaS abstracts away physical hardware (and networking) using virtualisation. This means that some companies no longer need to purchase, house and setup physical servers. They can just rent server space from a cloud provider instead.
Provisioning Virtual Machines ‘in the cloud’ is as easy as clicking a few buttons (or running a few scripts). Of course, you’re responsible for patching the operating system and runtimes. But the convenience leaves you with more time to build the stuff that makes you money: your business applications.
In IaaS, scaling and orchestrating Virtual Machines is also up to you (or software you run). But this can still be more cost-effective than running your own data center. What’s more, when you no longer need a Virtual Machine you can deallocate it and stop paying for it. Pretty agile, hey?
Your agility can increase even more when you start using containers. But again, it’s up to you (or rather software that you manage) to orchestrate the provisioning and scaling of container instances. Also, containers add complexity to the development and deployment process. This means they often require a specialised, experienced (and therefore expensive) team.
Further along the abstraction curve, we get to Platform-as-a-Service (PaaS). This cloud offering abstracts away not only physical servers but also the operating system, middleware and runtime. But, even though you’re no longer having to patch operating systems or update runtimes, capacity planning and scaling is up to you.
Scaling decisions can be configured to happen automatically, but the process remains manual initially. It requires careful planning and redundancy, which can be expensive. However, PaaS can be a great option especially if you’ve got a long-running application.
Finally, we come to serverless. Serverless computing is true abstraction from any infrastructure or scaling concerns.
And it comes with lots of other benefits too!
1. Faster time to market
Getting your product or service to market quickly is important. You want to beat your competitors but you also want to start earning revenue as soon as you can.
Agile saved us from the long delay between conception and delivery that traditional waterfall delivery dumped on us. ‘Going serverless’ fits nicely with agile delivery. Your development team can focus on delivering features fast.
2. Lower costs
Serverless can save you money. Why? Because many serverless offerings are pay-as-you-go. You only pay for the compute time you actually use.
Virtual Machines usually come at a fixed cost. Some of the time, however, they might just be sitting there doing nothing. So you’re paying for idle capacity. You might also be paying for redundant instances just in case you get a spike in demand and need to scale.
Serverless turns your fixed costs into variable costs so be careful. If you get an unexpected increase in demand one month you might end up paying more than you budgeted for. To manage this risk, providers allow you to set a limit on monthly expenditure.
You can also potentially save on staff costs too. Serverless computing can be managed by developers so there’s a reduced need for a dedicated DevOps team.
3. Easier scalability
If you go serverless, you don’t need to worry about scaling. The cloud provider handles that for you.
Serverless architectures encourage developers to split applications into independent functions. This means applications naturally evolve into microservices (or even nanoservices). So you get the benefits of microservices but with a reduced management overhead.
By default, you can scale parts of your application independently. In fact, the provider takes care of this for you.
4. Reduced complexity
Breaking apart a complex, monolithic application can be hard. But serverless can help. Simply break off parts of the application into serverless functions. You can use this approach to isolate complex, resource intensive parts of a codebase.
It’s important to realise that not all of your application needs to be serverless. It’s not always be appropriate either. If you try to construct your entire app as serverless functions you might end up actually increasing the complexity.
A simple rule of thumb is that ‘if it involves events, it can probably be enhanced by serverless’. Serverless architectures are also great for workflows! See Azure Logic Apps, for instance.
5. Minimal administration
As there’s no server provisioning, patching, or scaling, developers can focus on writing and deploying code. Developers get to focus on the business logic without worrying about writing infrastructure code. This can dramatically reduce the size of the codebase, which is a very good thing.
The only administration that needs to happen is deployment. Most vendors, however, have tools that make this extremely easy. Serverless functions elegantly fit into any continuous deployment pipeline.
Serverless architectures are a great option for startups and for building MVPs. Small teams can roll out features quickly and easily. If and when it’s time to pivot, you can simply delete functions and deploy more!
New features are easily added because the application is already loosely coupled. It could even mean estimates become easier.
7. Better development experience
Serverless functions are easier to understand and use than containers. So there’s an easier learning curve and lower barriers to entry. Your existing developers should be able to get up-to-speed pretty quickly.
This can be very beneficial for frontend specialists because it simplifies backend development. Serverless is basically Backend-as-a-Service.
Deploying serverless functions is easy too. If you’re using Azure Functions, you can easily deploy from the command line, Visual Studio or Visual Studio Code.
In true microservices style, developers can even use different programming languages for each function. Although some governance is advisable here!
Drawbacks of serverless
Now, as always, there are some downsides to going serverless so this post wouldn’t be complete without listing them.
1. Not for long-running applications
Some providers restrict the amount of time that a serverless function can run. In Azure, for instance, functions are restricted to to run for 10 minutes.
But, that’s only on a Consumption Plan. It’s possible to run Azure Functions on an App Service Plan that doesn’t have this restriction. In that case, it’s back to fixed monthly costs though.
2. Vendor lock in
Some people worry about vendor lock in. If you build serverless functions using Azure Functions and use some of the other Azure services like Blob storage or Azure Service Bus then you’re already tied to a vendor so is this really an issue?
You might decide to publish your functions to multiple cloud providers to offset this risk. While you might not be charged (as they’re effectively pay-as-you-go), it will increase the management complexity and overhead by a large degree.
One thing you do want to check though is the Service Level Agreement. This can help you choose the best plan.
3. Increases network overhead
Serverless functions are independent pieces of functionality and they’re normally separated by a network connection. This means calling a function is a network call.
The Fallacies of Distributed Computing list the false assumptions developers make when building distributed systems. Developers need to bear these in mind when designing a distributed serverless architecture.
Quite often vendors will run serverless functions on the same Virtual Machine as other customers. This might be a concern for some companies. Again, that’s why it’s important to know the SLA.
5. Cold starts
If a serverless function hasn’t been called for a while, the vendor might deprovision the container that it’s running in. There can be a latency when spinning up a new instance.
The latency might be negligible but for more complex functions can be as much as 10 seconds. This isn’t always a problem but it’s worth taking into account. Bear in mind that you can also architect around this problem, for example by writing light-weight code. In Azure, you can also use a dedicated plan.
So go ahead. Give serverless a try today! Let me know if you have any questions in the comments or via email.