If you run a business of any significant size, the cost of IT starts to loom large. You are probably not in the technology business but a non-trivial part of your time is spent caring and worrying about technology.
One of the biggest sources of cost, and worry, is usually physical infrastructure. It seems inevitable that if you have to have software to run your business, then you also had to have hardware: the servers, and all the things that come with them (operating systems, routers, switchers, cables), which allow you to install and run your software.
Back in prehistory (say, 25 years ago), you had to buy your own servers and install them in your own (small) server room. It took weeks for them to arrive and then you had to have someone there to plug them in, configure and look after them and the server room.
Then came data centre providers. You could buy servers and they would install them in their (enormous) server rooms. And that was amazing. You did not have to have server rooms and people who lived in them. Installation turnaround times also reduced.
Then came the cloud providers. You could now rent the servers from their (gigantic) server rooms. And that was transformational. You could have servers ready in minutes and no big capital expenditure outlays.
But the server (whether you bought it or rented it) was still yours. You had to secure it, patch it, upgrade the Operating System (and pay the licences) and generally look after it.
As your business (and therefore your number of servers) grew, that task became more and more onerous. It seemed an inevitable part of doing business.
Until Serverless came along.
It is a simple pitch: you only worry about the code you want to run. Someone else worries about the infrastructure. You never have to think about servers ever again! No bills to pay for upgrading operating systems (and no licensing costs for those either); no vulnerable infrastructure open to cyber attack; no upfront costs for buying servers. You just get charged by the owner of the infrastructure every time you use it, for as long as you use it (and this is measured in micro-seconds), and they deal with all those headaches. And some of them, like Amazon Web Services, have very generous free monthly tiers, so you could run entire services for free until they build up enough scale and you need to start paying for the usage.
For example, I once thought it would be a good idea to become a millionaire by buying and selling cryptocurrency. How hard could it possibly be? What I wanted to do was read the prices of various cryptocurrencies every minute from a free service available via API and analyse the price fluctuations over a period, then decide whether or not I should be thinking of buying or selling that crypto.
In the old days I would have had to buy (or rent) a server to host the programme that read and analysed the data, and the database that would save the data. But now, all I had to do was write my programmes in a way that was sympathetic to one of these serverless platforms (AWS Lambda in this case, because AWS is my cloud speciality) and instruct the platform to run the data-gathering programme once a minute and the data-analysis programme every 10. The data was saved in an AWS database-as-a-service (DynamoDB) with similarly generous free tiers.
After a few months I realised that I was not well suited for the rollercoaster ride of the cryptocurrency markets and that I had to look elsewhere if I was to become a millionaire! So I turned all that stuff off.
The total infrastructure cost of my crypto adventure? £0
I never reached the limits of the free tier, even though I was making thousands of API calls every day and running hundreds of analyses. All that computational power, for months, free!
This is the promise of Serverless: hugely reduced infrastructure bills and a lowering of the barriers to innovation and experimentation. There are potentially thousands of people like me trying, and failing, to create businesses because the cost of entry (and of failure) has plummeted. But some will be succeeding. And they could be your more nimble competitors.
So why isn't everyone doing it?
A lot of people are, both big and small. If you are not using Serverless you should be asking yourself why not, especially when it comes to new initiatives within your organisation. The benefits in terms of cost, scalability and innovation are very clear and you should be exploring them.
For legacy applications, the situation is more nuanced. Serverless applications need to be architected with the advantages and limitations of the serverless framework in mind. For example, running a serverless piece of code requires upfront time to load it onto the machines and this can increase the latency for some of your users. There are strategies for dealing with this, but they have to be implemented in the right way. Also, just because you are not installing and running the servers does not mean they don't exist! You need to be aware of the limits imposed by your provider if your application suddenly experiences a surge in use.
If you have existing applications, re-architecting and re-writing them to fit into a serverless model could be time consuming. It also requires a different mix of technical skills. In general, the embrace of cloud transformation has blurred the lines between programmers/developers and system/operations engineers. A more integrated DevOps approach has emerged, with people who have a mix of skills in both areas, greatly to the benefit of agility and customer-centricity.
And it is not only your technical team that needs to adapt. Your finance team will also need to think differently. Although the costs of running serverless can be low, they are more difficult to predict. Gone are the days of one big chunk of Capex buying your infrastructure and not having to worry about that any more. Serverless (and cloud more generally) follows an Opex model, so your financial planning team and budget-holders need to think differently.
You may conclude that rearchitecting your code and/or retooling your workforce is not cost-effective, unless it is in the context of a wider re-think of your service offering. But if you are in the middle of that re-think or about to start it, you should consider Serverless and discuss with your teams the opportunities, and challenges, that it brings.
If you'd like some guidance on thinking through the opportunities that Serverless offers, thenDrop us a line