The title for this article comes from yet another email in my inbox regarding serverless architecture: this time it’s from Google. The statement seems true in my world; everybody is talking about serverless (architecture), and often in the same sentence as ‘the next revolution of IT’. So: what do you need to know?
When I started my career in IT there was no cloud - in fact the internet was just beginning and was very immature - but it was the internet that tempted me finally to turn a hobby into a profession. I could see awe-inspiring possibilities for IT when a ‘global network’ was involved. Back then we worked on what is now affectionately known as ‘Tin’ or ‘bare metal’.
We spent weeks working out what computer hardware we required for a specific function, we ordered it in a modular fashion and ‘bolted together’ servers in a largely unwanted area within whatever building I was working in at the time. Next, we installed an operating system, applications and their dependencies, configured the server and named it. It became a member of the family and you loved and cared for it.
Like a newborn baby, you could be awoken in the night if it was sick (if you were unfortunate enough to be on call) and you happily changed its hardware to keep it healthy. We hardware engineers were invaluable: we knew everything that was needed to know about our servers (Laurel and Hardy at one site, I remember), but those days were numbered.
From server room to data centres
Soon people realised that commonality and mass purchasing brought economies of scale in the computing world, as well as elsewhere, and servers moved from your less than salubrious on-site server room to data centres - large, bright, HVAC (heating, ventilation and air conditioning) equipped security-aware warehouses with cages of servers and spare parts on tap.
All servers would share some level of commonality in terms of spare parts and maintenance/hardware replacement, so fleets of hardware engineers could also service the machines and the previous adoration shown with affectionate names had disappeared and was considered quaint.
Virtualisation
The next obvious step ‘forward’ was Virtualisation. Spreading your compute loads across your hardware and abstracting the concern regarding the actual hardware itself. All you needed to know was along the lines of: I’m running two Windows 2008 Servers and I need x CPUs, y GBs of RAM and z TB of HDD via SAN, per server, backed up nightly.
Soon after, the leap forward to making this virtualised compute available over the internet was termed the cloud. Here you could point and click on ‘Windows Server’ and it ‘magically’ spun up a virtualised instance running Windows Server OS.
You were billed by the hour the server was running and it was your responsibility to look after the server in terms of patching/ updates, software installation and all dependencies. The above steps enabled the removal of ‘infrastructure’ from a customer’s list of dependencies when it came to IT. So... what’s all this serverless architecture business then? Surely, we’re already here? Well, we’ve not discussed one thing that came along about the same time as the cloud: containers.
Build apps with services, not servers
Containers allowed another ‘step’ of virtualisation in the sense that you abstracted away the reliance upon an OS as much as you had abstracted away the reliance on ‘Tin’ or ‘Bare-Metal’ previously. Containers brought improved performance, repeatability, and isolation into the bargain. Importantly for your developers though, they could develop their code and run it in containers on their laptop, and this portability (ability to run the same code with the same dependencies on any environment running a ‘Docker’ like system by ‘containerising’ it) allowed developers to develop code and test it without needing IT Ops / SysOps input for infrastructure deployment, maintenance, and troubleshooting. Agile was becoming agile.
Now you’ve probably guessed the final step: Abstract the need for containers. Just ask your developers to write the code and the serverless architecture will run it. In IT terms, we would describe the above journey as:
IT Ops -> SysOps -> DevOps -> Low Ops -> No Ops
So, what’s the advantage to serverless architecture?
Well, you have no need for OS costs, installation, dependencies, maintenance, support, patching and other overheads that come along with OS’s. No need to wait for virtual server instances to spin up, no concern about tearing them down. You pay to run your code (in terms of time/ memory it takes to run) and that’s it. We’re down to ‘bare-code’ not ‘bare-metal’. On top of this, it will seamlessly scale to demand. As Google puts it: ‘from prototype to production to planet-scale.’
This is true pay-as-you-go computing with no idle fees and ultimately scalable performance. The most striking advantage that I can see is for start-ups. Before this revolution, a start-up had to either fi nd a large investment to pay for their IT set-up CAPEX expenditure costs in a fully managed data centre, or purchase their own hardware, HVAC facilities and also factor in salaries for IT hardware engineers, SysOps engineers, DevOps engineers and finally the coders writing the magic that sells.
Now more than ever before, small teams of developers are able to run code themselves without the dependence upon teams of infrastructure and support engineers - more developers are DevOps skilled and distinctions between being a software developer or hardware engineer are blurring.
Who’s in the game?
From a cloud architect’s point of view, this one’s pretty simple:
- Amazon Web Services (AWS) with AWS Lambda: ‘AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume - there is no charge when your code is not running.’ AWS Lambda will accept JavaScript on Node.js, Python, Java (Java 8 compatible), and C# (.NET Core).
- Google with Google Cloud Functions: ‘Construct applications from bite-sized business logic billed to the nearest 100 milliseconds, only while your code is running. Serve users from zero to planet-scale, all without managing any infrastructure.’ Languages available: JavaScript running on Node.js (running on Google’s V8 engine - more about that in another article).
- Microsoft with Azure Functions: ’Azure Functions is scale-based and on-demand, so you pay only for the resources you consume.’ Azure will accept: JavaScript, C#, Python and PHP.
Whom to choose?
Well that’s out of scope for this article, but if you join me soon for a discussion on the ‘G5 of IT’, it’ll help you discover what’s going on underneath the big names in IT. A ‘fun fact’: Google Docs recognised ‘serverless’ as a word, however, Microsoft Word 2016 didn’t. To take this any further would be an article in itself, so perhaps let’s revisit what that difference really meant in a few years.
Frazer Jamieson CEng MBCS CITP is currently working as an AWS Architect and he has been working in IT for over 20 years. During that time, Frazer has been involved in a mix of infrastructure design and software development.
