Explaining Serverless technology

If you’re an IT or business leader, you’ve probably heard about serverless. Forward-thinking organisations are planning for servless now, because it’s a big change to how we build software. You don’t need deep tech knowledge to understand why – there’s nothing mystical about serverless. I’m going to explain what this is in simple terms and how it will affect software development practices.

So, let’s begin. We all know what servers are; they run the various software applications that we have. Ideally we have enough servers to withstand a few of them failing, but not so many that we spend a lot  managing them. Many years ago, organisations would have most of their servers in the building with them in special data rooms. These days, most people keep their servers in a data centre. A data centre looks like this:

… at least, they look like that in theory. In practice they’re not as sparkly clean, everything is packed together a bit more, and they’re staffed by people who don’t see the sun nearly often enough. There are many downsides:

• you have to buy hardware that breaks and/or becomes obsolete over time
• it takes time to scale up/down an installation, and frankly most servers are only lightly used – they often sit entirely idle at night
• they’re constantly using up electricity and generating heat, both of which are expensive

Going Cloud

Smart organisations have given up the data centre and moved to the “cloud”. This means instead of buying or renting a bunch of physical servers, they’re purchasing service. This service is delivered in the form of virtual servers. Physical hardware is still necessary, of course, but the hosting company now purchases and manages this. The hardware is divided amongst their customers using virtualisation software. This is much more flexible for the customers, and a much more efficient use of hardware. Managed correctly, this is usually cheaper than the physical equipment due to increased flexibility, even though on paper the cost of the service versus the physical hardware on a like-for-like basis is more expensive.

This brings us neatly onto Serverless. I can buy a virtualised server, and the provider is giving me a very flexible service. My question is, “do I need to buy that service in server-sized increments?”

The direct answer is, of course, no – if you want, you can buy it in much smaller increments. This is what we refer to as serverless.

This simple answer requires software to be designed differently. If you’re a leader in an IT function, or more broadly in a business, you need to understand this change.

A strict definition

First, let’s get one thing clear: serverless doesn’t mean that the servers go away. They’re still there, chugging in the background. Just like cloud, you don’t worry about the hardware.

There is also a related idea labelled “No Ops”. This is the concept that you no longer need operations IT staff in order to run your infrastructure. I personally believe this is a misconception, but for more complex reasons we’ll get to later. Suffice to say, serverless doesn’t mean “no operations staff”.

Also, there is now a serverless software framework called “Serverless”. Don’t confuse serverless-the-concept with Serverless-the-software-framework. They’re related, but for the purposes of this discussion, ignore the framework.

The easiest thing to remember about serverless: this is all about using small pieces of physical server capacity. In order to do this, software needs to be nibble-sized, not pie-sized. It needs to start up quickly: within tens of milliseconds, really. The software may run for a few seconds, it may run for longer. It will then get shut down, and may not be running for a while.

Any platform capable of executing software like this is technically serverless. I use a bucket as an analogy: a bucket can carry large rocks, but there will be lots of gaps. Those gaps represent inefficiency, they’re parts of the bucket not carrying rock. If we carry sand in the bucket instead, there are much smaller gaps. The bucket is being highly utilised.

Serverless right now gets sorted into one of maybe three types (there may be more in the future): Backend-as-a-Service (BaaS), Functions-as-a-Service (FaaS) and Containers. I’m only going to talk about FaaS, because this is the game-changer: the other options are technically interesting, but don’t bring about most of the serverless benefits, and are a subject for another day.

What are Functions?

You can think of a Function as the smallest unit of software that can still usefully accomplish a task. Functions have a meaning in both software development and mathematics, and the meaning is similar. A function takes some input, generates some output, and may have some memory, which we call “state”.

In Function-as-a-Service (FaaS), we tend to think of a single independent API being a group of related functions. A great example might be user registration: there will be a function to register a user, another to log in as that user, and another to reset their password. So on and so forth.

Going back to the bucket analogy, where the large rocks might be complete applications, the grains of sand are functions. Large applications are usually made up of large numbers of functions, but they don’t work independently – they are wired up together directly.

Implications of Serverless

So, now that we understand the concept, what does it imply? What changes will be brought about by the advent of serverless? There are a number, and in no particular order:

Pricing

This is the biggest change, and is also a useful way of testing whether a product is genuinely serverless. Since functions start and stop promptly, they only execute when there is work to do. They don’t sit around twiddling their thumbs. Pricing should be based on usage and involve metering. A product that is advertised as serverless but charged at $199/month is nothing of the sort.

As well as being priced on usage, expect to see interesting price options. Metrics like quality of service and guarantee of speed could alter cost. If you’re not working with important data, you may be able to pay less for a service that is more likely to fail (or, vice-versa). Trade-offs like these will further bring IT costs down.

Composition

A large change to the way that software is developed will be use of Composition. A lot of developers will already use similar tactics when building software already. When it comes to building applications, our first question should be: “What existing functions do we have that we can compose our new application out of?”.

Software development will become more granular as the individual pieces reduce in size. This will lead to more agile development, and a much greater emphasis on architecture.

The distinctions between “applications” will disappear – there will be more ad-hoc applications created from the soup of existing functions in an organisation. Applications will develop more organically, splitting and merging as required.

Event-driven

When our applications stop running 24/7, we will drive them with events. Whether contact with customers, or a timed schedule, events will wake software up.

Since software is in place to service business processes so often, this will cause processes to become more event driven. This will increase automation, as we no longer want “pauses” in flow. Increase automation will encourage organisations to integrate with each other at a deeper level.

Client-side computing

The interface to serverless software need not be very different. However, serverless is naturally API-based and doesn’t handle “interactive” usage well. This makes it a poor fit to drive UI/UX.

However, this isn’t really a problem: the modern approach to web applications is the “single page application”. This means that the application largely runs in the web browser – probably using a Javascript framework, like Angular or React. This existing trend is entirely compatible with serverless, and in fact will probably be accelerated by it.

Challenges of Serverless

There are a lot of benefits that I’ve spoken about already. What are the challenges?

• Novelty. A lot of IT departments will be naturally anti-serverless; it’s new and they don’t trust it. Similar concerns were raised with the cloud. Organisations that fail to make the transition will be left behind.
• Predictability. Purchasing services on a metered basis means having to forecast usage in order to figure out the cost. We’re used to doing this with electricity and telephone calls, but not software. It’s not rocket science, though!
• “No Ops”. It’s not true that we will no longer need operations people, but it is true they will no longer spend time baby-sitting servers. Their jobs will become more important as they spend much more time doing design and architecture.
• Architecture. This is the big one. Existing software design patterns don’t fit the serverless world well. We know that serverless is about being able to execute small pieces of code on demand. This became much easier recently, due to the advent of SSD hard drives and related caching technology. Existing database implementations no longer work well, and a lot of application frameworks simply don’t work in this way.

Conclusion

A lot of things need to change in a serverless world. In particular, a lot of existing software simply won’t work serverless. So, why all the fuss?

If you’re a software vendor, you need to imagine your product but serverless. Is it compelling? Does your existing annual subscription model hold up against that competition? Does it change the game for your customers? In most cases, the answers are Yes, No, Yes. If a serverless version of your product destroys your revenue stream, you have to make sure you’re the one selling it.

If you’re a software consumer, you need to think about your key applications – particularly enterprise line of business. Are you making decisions for the next 10 years? Are you considering investing in another on-premise server-based mega-application? The game is changing, and you don’t want to be saddled with six-figure operational costs each year when your competitors are paying four-figures.

For the most part, this largely applies to organisations writing their own software at this point – there aren’t many serverless options out there, right now. But they are coming. You need to be prepared.