What is "serverless"
I know serverless isn't exactly a new word any more. The first truly abstract serverless offerings came around more than 10 years ago, which is an eternity in the tech world. The reason I want to write about it is that even though it has been around a while, many folks (especially large, established corporations) who could benefit from it suffer from inertia of mindset, commitment to previous investments, and a lack of serverless-ready skillsets. Perhaps accurately understanding what it is will help set a course for progress.
TL;DR
Serverless is more than just a buzzword applied to a product by the marketing team. It's an architecture paradigm, a mindset, a pricing model, and a commitment to an additional layer of abstraction that keeps your time focused on what makes your project special.
Adding to the confusion, there's also a company called Serverless Inc, offering tools to help you build...serverless apps. We won't dive into that today.
Serverless: An Architecture Paradigm
When designing an architecture for a serverless system, one has a different set of building blocks at her/his disposal. Instead of thinking of CPU and RAM capacities, one thinks in more abstract terms like services, protocols, and data pipelines.
A serverless architecture is one that can scale with little or no intervention because it is built on "elastic" services that scale horizontally as the load increases.
A serverless architecture will avoid stateful transactions where possible. Statelessness lends itself to horizontal scaling, scale-to-zero services that shut down entirely when not needed, and typically result in information being stored in nonvolatile, highly durable places instead of memory.
A serverless architecture will decouple wherever possible. Technically decoupling is a useful feature in any type of architecture, but it's especially beneficial in serverless. Cloud services designed for use in serverless architectures are built to make decoupling easier than ever before.
Here's a great set of serverless reference architectures complete with diagrams that I found very useful.
Serverless: A Mindset
I like to think of serverless as a mindset. Some projects I've worked on start with someone asking something like,
"Ok, so how big of a server do we want and where should we host it."
Someone with a serverless mindset would first ask,
"Can this be done without a server?"
That seems like a simple change, but the payoff can be impressive. I haven't researched the economics of it, but it seems to me that cloud providers charge quite a bit for a VM. Moving to cloud VM's has benefits, but it's very expensive, too!
Ben Kehoe is one of the top serverless gurus out there, and during an interview on the Real World Serverless with theburningmonk podcast (#15), he mentioned the serverless mindset:
Interviewer: What advice would you give to people just looking to start their serverless journey today? Anything that would help them get started quickly and avoid common mistakes?
Ben Keohe: The most important bit is adopting the serverless mindset, which is something you can do even before you can use the technologies that we refer to as serverless. It's about wanting to own less technology to deliver customer value better.
Serverless: A Pricing Model
When you're looking at pricing information for serverless services, you'll probably see prices listed in hundredths or thousandths of a penny. Most serverless offerings have a per-invocation or per-use pricing model. This means that if nobody is using your app, the cost to operate it goes down. If you have a big surge in load, you'll pay for exactly enough horsepower to tackle it.
This pricing model helps you pay for the things that are actually giving you value. A beefy server with no workload applied to it is giving you negative value. It's costing you money without performing any tasks. A serverless function, by comparison, will only wake up when needed, and then evaporate when it's done. You get charged for the milliseconds/seconds that it was awake.
This is a big benefit for startups who need to keep costs low during development and testing, but need to scale quickly as their apps gain traction.
Serverless: A Commitment to Abstraction
One great way to focus on the important things is to alleviate the need to give your attention to other things. This is an unsung strength of serverless! While you may be capable of managing your own servers, that's not the mission of your app! Having spent an hour managing server OS patches will not result in your app being fundamentally better at what it does. Having that hour to start development of that community-suggested feature on your backlog WILL make your app fundamentally better.
In economics this dynamic is called "opportunity cost" and we should be careful to add this to the equation when evaluating the server-based vs. serverless decision.
Technology has long been a game of abstraction. Serverless computing is the next major step in getting us further away from 1's and 0's and closer to the ideas and concepts that we use to build amazing things.
Downsides?
While serverless is awesome, it's not quite a silver bullet. Here are a couple challenges:
Portability: If you built your system in GCP and then one day are required to port it to Azure, it's not just going to be spinning up a new server and copying over your configs. It's going to involve understanding the nuanced differences between GCP's services and Azure's services, and you'll likely spend quite a bit of time adapting your code and architecture to work well with the new cloud provider.
Control: When using a service, you're at the mercy of the owner of that service. While many times a cloud provider will make positive changes to their services to keep the it modern and secure, sometimes your schedule can be clobbered by a notice that says, "you have a resource using [protocol/runtime/service version] that will be retired on [date]." In my experience cloud providers are judicious about the kinds of changes they make and allow for backwards compatibility where reasonable. Notice is typically given well in advance of anything changing. The bottom line remains, however, that they are in control of their service, and your system must be kept in compatibility with it.
Summary
Serverless is important because it presents new opportunities for us to be effective, efficient, and excellent in our work. The impact of serverless can be seen in the stories of many successful businesses, but some of the most dramatic impacts are not yet realized.
I hope this fairly informal post has helped shape your perception of serverless systems and their characteristics, and that you'll be able to use this exciting set of tools to build something amazing!
Top comments (0)