This is the first in our series of digital briefings: an outline of digital technology trends for non-techies. This piece is on the trendy topic of “serverless” – the what, why and how. Let us know if there are topics you would like covered.
Serverless is becoming a trendy term. Techies talk about it, some organisations dabble with it, and a few have embraced it. But what is it? And does it deserve the hype?
Broadly, serverless is a new way of hosting digital solutions (e.g. websites, online applications and services). It has significant implications on the way the solutions are developed.
Below I attempt to demystify it, explain why it is gaining traction, and why it isn’t a silver bullet.
(If you have a good understanding of what hosting and cloud hosting are, you might want to skip the next two sections. If anything isn’t clear, you can skip down to the Analogy section.)
So first, let’s consider more conventional hosting. If we take the example of a simple website, you can build a site on your own laptop. However, once built, you will need it sat on a computer permanently connected to the Internet so others can reach it any time – i.e. to have it hosted.
Although technically you could host the site on your laptop, there are numerous reasons why you wouldn’t, not least that your laptop would always have to be on and connected the Internet. So, you’d typically deploy your website to a server – a computer always on and connected to the Internet permanently.
You may deploy your site to multiple servers, and even to servers in multiple locations, but the principle is that you are deploying to physical servers, with their own resources and software (CPU, memory, operating system, etc.), always running and constantly “listening” out for requests for a page request from a browser somewhere in the world.
Enter the cloud and virtual servers
“Cloud” is quite an abstract term. A slightly simplistic but useful way to look at it is that something “in the could” is a service running on the Internet somewhere, and that you don’t have to worry about where and how it works.
Barring a few niche services, the first phase of cloud hosting was to virtualise the server. Amazon was the first big player – they had many racks of physical servers in data centres which they needed for peaks in shopping demand, but much of that capacity ran idle for most of the time. Selling that capacity out for others to use made commercial sense. Other big players such as Microsoft and Google followed, as well as many smaller players.
With virtual severs, the hosting companies still have physical servers in racks, but those servers run virtualisation software on them that effectively emulates servers (i.e. the virtual servers). This allows virtual servers to run on the physical servers. These virtual servers have virtual resources – an operating system, memory, CPU cores, hard drives, etc. – that map to real resources on the physical servers. And there isn’t always a one-to-one mapping – a physical server might run multiple virtual servers, and a virtual server may be hosted across multiple physical servers.
The important thing to note is that if you use a virtual server, you never get to see any aspect of the physical servers – that is completely invisible to you. When you interact with it (e.g. remotely connect to its remote desktop), it behaves exactly like a real server. The operating system on it thinks it is physical server, and sees memory, hard drive, network cards, etc. as if they were physical hardware. You can install your own software on it and configure it as you want just like a physical server, and in turn you will need to keep it updated (e.g. apply security updates) just like a physical computer.
There are many advantages: You don’t need to buy or lease physical servers and simply pay for what you use (time it is running form and resources you use). You can make changes the virtual hardware easily (e.g. increase the memory or disk space) without having to physically upgrade it. It may be running across multiple physical servers and fail-over automatically when physical hardware fails, so you don’t have to worry about hardware at all. And the entire contents and configuration (its “image”) can be moved or copied around to other virtual servers. This makes it typically much more flexible and cost-effective than physical hosting.
The cloud hosting described above still has some constraints. It is still a “server” that you have to look after. It needs to be running all of the time (including its operating system) to be accessible even it no one is accessing it, and you pay for this idle time. You still need to think about maintenance (e.g. applying security updates as they are released).
Typically, much of the time a server is running it is waiting for something – an event. Take our simple website example from above. It is sat there waiting for someone to request a page. You are paying for all of the time it is just waiting there for someone to come along.
With serverless, rather than developing your code to sit on a server (whether physical or virtual), you write your code in functions (a piece of code to perform a very specific function) that you store in the cloud (i.e. in some paid-for cloud storage). You also define triggers to invoke that function. In our simple example, you might define a trigger of the requesting of a URL (e.g. a browser somewhere on the Internet requests a specific page on your website). The cloud hosting environment picks up on that request, follows the trigger rule, and then calls your function which generates the specific page. Functions can call other functions, and there are various rules that can define a trigger, so there’s a lot you can do with serverless functions.
Here, you have no had to worry about a server – the cloud provider is managing all of that for you. And you haven’t had to pay for a server to be running all of the time regardless of whether it is being used – plus you haven’t had to be concerned about setting up and maintaining a server – you have simply paid a very small amount of money for that function to run.
Additionally, scaling is built-in. If you have a sudden peak in activity (e.g. your website suddenly goes viral and you go from a few page requests a day to hundreds per second), you don’t need to worry about setting-up additional virtual servers – the cloud hosting service just creates more instances of your function.
The most established provider is Amazon – they provide service called Lambda as part of the Amazon Web Services (AWS) cloud platform. Microsoft provides a similar serverless platform on their Azure cloud platform called Azure Services.
In summary, key advantages are:
- In summary, key advantages are:
- You only pay for what you use, not for a server and operating system running all of the time
- No need to set-up and manage a server (e.g. operating system maintenance)
- Scalability is and built-in
Let’s say that you were getting in touch with a company’s contact centre which communicated via text messages. For you, the customer, each of the following scenarios would appear the same, but the company is organising its contact centre differently in each case.
1: There is a dedicated person with the role of dealing with sales enquiries – sales is all that person works on. When there is high sales demand, they are overly busy and enquiries are slow to be responded to. And when sales are quiet, they are sat there idle. If the business is ramps up, the company could recruit another sales person, but is a long-term and costly commitment, and will require time and effort to train them up.
This is analogous to physical hosting. The employee is like the server. Servers are fixed and inflexible, and adding more is long-term and costly.
2: Now imagine that the contact centre could call on staff from throughout the business to work in the service centre at relatively short notice, and therefore management can plan to grow and shrink the contact centre team with a bit of planning. Employees don’t have fixed roles but could be deployed from say sales today to customer services tomorrow. These functions (such as sales) are now virtual roles – there isn’t a dedicated sales person – it is more a sales function (or virtual sales person) covered by potentially multiple employees. A function (such as sales) could still have too many or too few employees as demand shifts, but management can reassess and revise at relatively short notice.
This is analogous to cloud virtual hosting. The full company of employees is like the cloud, and the sales function is like a virtual server. The employees performing the functions or roles are like the physical servers behind the scenes. Virtual servers can be scaled up and down relatively flexibly with the physical resources (servers) behind being adjusted. There isn’t reliance on any one physical server as others can jump in as needed. But the virtual servers still need to be operating all of the time for a function to be available with a management overhead (such as operating system constantly running) to keep them going.
3: Finally, let’s consider that there is no contact centre at all. In the previous examples, there was a team assigned with different roles, and that team needed to be there and to be managed all of the time in order to respond to queries. In this scenario, when a text message comes in, the message will go through to anyone in the company with capacity, and they have all the instructions they need for any enquiry. Once they have replied, they are free to work on something else. No overhead of managing a team is required. The cost to the service centre cost centre is just the time each individual spends responding to texts.
This is analogous to serverless hosting. There are no roles (servers or virtual servers) needing to be running and managed all of the time. Rules define a trigger (e.g. a text message is received). This triggers a function (like an employee following some instructions). Once complete, the function ends. The underlying resources, i.e. the cloud computing infrastructure (like our pool of employees) is large enough to cover as many requests as may be required at any time. Cost is only incurred when functions are executing.
If it is so great, why isn’t everyone hosting serverless?
Serverless is a relatively new approach in mainstream computing. Architecting solutions that can be deployed to serverless hosting requires a specific approach to designing and coding the solution. It requires an “event-driven” approach all the way through the solution which is quite a mindset change and new to many developers and architects.
This also means that existing solutions (e.g. existing applications or off-the-shelf solutions) will not work on serverless hosting unless they have been designed specifically for it (and most haven’t).
From now into the future
At the moment, many developers are starting to use serverless for parts of their solutions. Consider a typical website – let’s say it is using the WordPress content management system (CMS). They may have the main website, including the off-the-shelf WordPress application, running on a virtual server. However there might be specific functions – say calculations, functions to integrate with other services, or other business logic – that they are developing from scratch, and can be built to run stand-alone as serverless functions. The two approaches – conventional hosting and serverless – can be used together.
We are already seeing some off-the-shelf applications being built to run in as serverless functions, and that will continue – I believe that this will eventually be a big driver to greater adoption of serverless.
There is also a related movement in architecting and development circles – the microservices architecture. I’ll talk more about this another time, but in essence, it is the designing and building of solutions as many little functions that run autonomously. This a relatively new movement (at least in the mainstream) and is still gaining traction. It isn’t perfect for all situations, and to implement it properly requires a different way of thinking and a lot of planning. There is still a lack of blueprints for doing this for different types of application, and a lack of tools to support the development and deployment of true microservices architectures. However, serverless functions are perfect for microservices, so as microservices become more mainstream, it will in turn drive the move to serverless.
Was this helpful?
Our mission at Articulate Digital is improve communication between business and technical professionals. Talk to us if we can help to articulate technical concepts, whether you are trying to get your message across, or you are needing to understand specific technical concepts. Our services include consultancy, training and senior technologist mentoring.
If you would like to be informed via emailed of new blog posts, please follow us here:
Articulate Digital Ltd, Newminster House, 27-29 Baldwin Street, Bristol, BS1 1LT
UK registered company no: 11732374