“It’s not about infrastructure, it’s about providing a discreet capability.”
Serverless is a bit of a buzzword at the moment. It’s also a genuine misnomer and should you decide to Google it, you will probably end up none the wiser.
However, the clever bods at Dootrix are increasingly making use of Serverless in the solutions we are rolling out today. It brings with it some pretty significant benefits both to us and to our customers.
To this end, we picked the brains of our DevOps team to explain the what and the why’s of what is fast becoming a new normal in software architecture and development. If you’re not a solution architect or a senior developer, but you do want to know what Serverless is and why it matters…then this article might just be for you.
The one thing that the current crop of confusing blog posts do seem to agree on is this: Serverless does not mean there are no servers involved; it just means you don’t have to care.
Provisioning the machines (physical or virtual), installing the operating systems, patching the operating systems, managing the software, updating the software, procuring and managing specialist networking equipment. All gone. The infrastructure that is running all of your stuff is still there, but it’s abstracted away. It’s someone else’s problem. That means we can stop thinking in terms of servers; database servers, application servers, file servers etc, and think instead in terms of services.
Services are what Serverless is all about. Today, the world of IT is moving, at some pace, away from infrastructure as a service (IaaS) and towards platform as a service (PaaS). PaaS is not concerned with physical infrastructure; it’s focus is on providing a discrete capability. Want somewhere to store large amounts of unstructured data? Thinking of provisioning a NoSQL database server? That’s not as simple as it sounds. What about backups? What about sharding and replication? What about global redundancy? What about scaling as your data needs grow?
Wouldn’t it be nice if you didn’t have to worry about all of that? Well with PaaS you don’t. Someone else has thought about all of that and wrapped it up in a service. If your cloud provider of choice is Microsoft then you can go right ahead and subscribe to the Cosmos DB service on Azure. You have just made all of that pain largely someone else’s problem.
Not quite. PaaS is the technological shift that has made Serverless possible, but with many PaaS services you still have to work with constraints on compute, bandwidth and storage etc. Sure, those constraints all becomes easier to manage and it becomes far easier to add capacity (you can normally automate this process entirely based on set criteria or rules), but you still have to plan for how your PaaS architecture scales and understand under what conditions it should.
A ‘pure’ serverless application makes use of fully elastic PaaS services. The service itself decides when to scale and when to add capacity. You are just sent the bill. Good examples of this are AWS Lambda, Amazon S3, API Gateway and Azure Functions (see here for Amazon’s take on its full serverless offering)
1. Serverless services are incredibly cheap to run
You only pay for what you use. If no one is using the software, you incur little or no cost.
2. Failover or backup systems are often not required
Services are elastic (they scale automatically to meet demand) and can be spread across multiple regions; failover and backup are built into the services, as opposed to being an additional consideration.
3. You are not paying to procure or maintain hardware or software, virtual or otherwise
No bare metal (or virtual metal) means you don’t have have to worry about CPU cores, RAM or Operating Systems etc. You also don’t have to worry about replacing disks when they break or get full or keep on top of the constant stream of software updates.
4. A standard set of well defined SLA’s
Azure and AWS have well defined SLA’s for each service that they offer. This can simplify contractual terms for both the supplier and the customer.
5. Quicker build/release/deploy cycles
A well written serverless application has a scripted deployment and update process. The ‘infrastructure’ is actually code and can be version controlled along with the software that runs on it. After the initial setup, spinning up and down environments or updating the platform can be done in minutes instead of days or weeks.
6. Software that scales with your business needs
Services such as AWS Lambda automatically scale your application. Your code runs in parallel, scaling precisely with the size of the workload. You will not have to provision any more servers to manage an increase in demand. Serverless architectures are built to scale; scale is baked into their DNA.
7. Standing on the shoulders of giants.
Microsoft and Amazon have invested billions in their data centres and cloud platforms to develop best of breed services that your applications can leverage. They are improving these services, and the SLA’s that back them up, and building more of them all the time. Even die-hard infrastructure companies are now pivoting to base their service offering atop cloud platforms such as Azure and AWS.
We have recently worked with Suffolk Libraries to develop a low priced self-service kiosk system. Unlike the more ‘star-wars’ boxes that are expensive and have substantial support and maintenance charges, Suffolk Libraries wanted a budget system that could run on consumer hardware. Libraries, like all publicly funded services, are under tremendous pressure to save money and are having budgets slashed year on year, so managing costs was very important.
While the project needed to be lean in terms of price, it still needed to shine, offering library users a significantly better user experience than the legacy system it was replacing; we needed to take a holistic approach. The solution consisted of the following:
Each action that the kiosk has to perform, to borrow or return items, is handled by a small piece of code. The code is hosted and runs as a function on AWS Lambda. Much of this code handles business logic and communicates over the AWS NAT Gateway to the library management system (LMS). Resources for the app are stored in S3 and, although it is essentially a hosted web application, the entire system is able to work offline by making use of the latest advances in progressive web technology.
There are two very important things to note:
We only pay for what we use, right down to the individual CPU cycles it takes to run one of those Lambda functions; each borrow or return incurs a tiny, tiny cost, but we do not pay for any always-on virtual machines or physical infrastructure. As such, there is also no cost required to maintain and patch them.
All services are fully elastic. We do not need to define scaling rules. We do not need to plan for more infrastructure. AWS takes care of it all; it does whatever it needs to do to ensure we always have enough capacity to handle the load. This means that we can scale the rollout to a huge number of libraries without having to worry about supporting infrastructure changes. What’s more, we can do this while continuing to keep the costs low, only paying for what we actually use.
For Suffolk Libraries, this has meant we can be confident in ensuring future capacity while at the same time being able to offer a managed service that is very competitively priced. Today the self-service kiosk is being successfully used in more than forty libraries across the county and Suffolk Libraries have plans to take it even further.
You can read more about our cloud and serverless expertise here.