Will Serverless Computing Serve You?
If you keep your finger on the ever-flowing pulse of IT, you can't fail to notice the rise of serverless computing. The name implies that a server is something tiresome like a hot water storage tank in a cupboard and that you're probably better off without it. In fact 'serverless' is known within the community to be a somewhat baseless name - many conference-goers jokingly say it could easily have been called 'Jeff'. In the end, the companies that own the most computing resources want to make using their services easier.
However, for those considering transformation, it is worth looking closely at the 'what' and 'why' of this trend. When we first used a browser to look at a website, we were vaguely aware of communicating with a computer elsewhere. When certain pages took much longer to load up, again, we were aware that the database was a different and slower part of the system. When thinking about virtual computing, we can all understand that the geographical distance between the different parts (compute, memory and storage) isn't something we need to know about.
When companies such as Amazon started offering public computing via AWS, it was a model most of us understood - renting things we didn't want to own. More to the point, they ushered in the idea that computing was now a 'utility', not a 'product'. Directors who declared they should run their own servers usually didn't insist on having their own electricity supply, or independent sewage facilities as well.
The basic narrative of serverless computing is that a third party runs your code on their platform, so you don't need to maintain a server. In the case of a website for example, you expose the code (probably in a public facing code repository such as Bitbucket or Github) and the serverless provider reads it, builds it and deploys it. For example, take a look at Netlify and how they work within JAMstack. A recent entry to this arena, Github Actions, has sensibly realised that if folk keep their code on its systems, then maybe they can leverage that to add additional services.
The hidden kicker of a serverless offering something like AWS Lambda is that you only get charged when the code runs. This immediately gives an organisation the power to implement cost control in a much more meaningful way. It moves an item from any sense of it being CAPEX to purely OPEX. The need to run around turning off the lights in empty rooms goes away (this is subject to the usual political constraints; some business units may find it harder to explain any form of increased OPEX).
Now, the first obvious problem here is that there are many different things called 'code' and no one can possibly know how to run all of it. When it comes down to application development, however, there is a small group of favoured languages, one of which any given developer is bound to speak. Also, as users of Docker have discovered, there are plenty of ways to treat a server framework as a commodity, making developers a little less invested in the plumbing associated with their chosen language. This has given more or less every language the same claim as once only Java proclaimed: "write once, run anywhere".
A degree of architectural acuity is required to tackle this type of transition because of the need to split up your service into a set of smaller independent services or microservices. It is worth checking that when considering transforming an old monolithic application, you have the right mix of staff to figure it out. A big bang change from one extreme to the other is, as you may imagine, unwise. In reality, you may well find that your development team are already a long way down the road of separation of concerns (using agile, a code repository, containers etc.) and a small push is all that is required.
The thing that should animate anyone to pick up on all of this is when you realise that your business is not responding to changes quickly enough, or when small changes and success measurement cannot be carried out in a timely fashion. This can quickly breed that feeling that your application is a monster both protecting you but possibly exploiting you.
So serverless computing represents an evolutionary step from focus on the server to focus on the code. What it represents for your business depends largely on where you are in your transformation path. Once you have understood your customer journeys as code paths, it does have the power to free your development team from the complexities of server maintenance. If you can understand your critical paths as discrete events, and not a swamp of persistent state and data, then serverless has a lot to offer.