The death of the server

DevOps has become a very 'on trend' word in the last year. A combination of factors have influenced this, least of all the power of the Cloud. I for one do not believe that DevOps is the destination, more like a fuel stop along the way to NoOps. Regardless of if we are willing to admit it, we are automating ourselves out of a job (that includes developers like me too) and that isn't necessarily a bad thing. If we have progressed enough to relinquish ourselves of the need to perform mundane tasks (such as preparing environments) then we free ourselves to focus on actually solving the big problems we face. This will be a tough pill to swallow for many, but a necessary one. The investment at the bleeding edge of the industry is on making this as seamless a transition as possible, by slowly teasing open the seam between an application and the underlying infrastructure. The drive towards containerisation, the evolution of package managers and the cross contamination of operating systems (BASH on Windows?!) is posing the question; who even cares about the server?

The ideal scenario for many - and one which is looking more and more likely - is that code will be pulled directly from a source repository, built, tested and then deployed to a hosted service which will run the application within the context of a provided configuration file. From the users point of view, no machines (virtual or otherwise) are involved in this process. They did not have to guess the resource requirements of their application, they don't worry about external dependencies, they simply specify their demands (performance, uptime, etc.) and in return the service provider charges an appropriate fee.

These services, although in a fairly immature form are starting to materialise. At the //Build conference earlier this month - Microsoft announced their new Azure Functions service. This is a service which allows you to run on-demand compute in response to events. These events can be fired from any source - in Azure or otherwise - to trigger your code to be run. Rather than paying for a fat virtual machine to run this code, you simply pay for the amount of resources (execution time) you actual used. This means no more running automated shutdown scripts for your virtual machines, no more continually running web apps waiting for an infrequent event to fire.

It is true that not all software will and can be hosted in the Cloud. However, with the introduction of on-premise cloud platforms such as Azure Stack, hybrid cloud architectures, and on-premise elastic compute services like Service Fabric, these capabilities with become ubiquitous.

I know there are many unanswered questions - and I'm not convinced that all of them have answers - but this drive towards what we call 'serverless' computing has already begun.

It is worth noting that these very services are built on top of hyperscale, resilient and highly available platforms too - meaning for the most part, even the service providers don't concern themselves too much with the nuts and bolts of the infrastructure. Obviously there is always the lowest common denominator who is responsible for the actual physical machines but this role too is becoming increasingly automated.

The wave is on the horizon at the moment. I strongly suggest you learn to surf before it hits.