The last few months have been the first few months of my new job as a senior software engineer at Leighton, and it has been a time to learn some new tricks. In particular, Serverless Computing.
You might be thinking, "Just what the hell is serverless computing?" And it is a good question.
Many cloud computing service providers offer it, and for my work I have been in the AWS sandbox, so any terminology used from here on out is specific to that platform.
When we think about running websites, and all the gubbins on the backend that supports that website, such as databases and code that performs the business logic. These have to exist as services on a server, and the server requires enough cores, storage space, and RAM, in order to accommodate the amount of traffic to the website and the workload of each session. This requires estimating the number of resources and planning for spikes in the use of the service. This means that there are resources that are never being used for significant periods of time.
Moving to the cloud, there are two approaches we can take with our website. We can simply "lift and shift", and effectively replicate our physical resources on the cloud servers. This is an entirely valid approach, yet dooesn't leverage the newer technologies offered by the cloud, and in particular, Serverless Computing.
Serverless computing in essence is about breaking down a service into smaller functional microservices. And rather than provisioning the resources a priori, we are charged in a piecemeal way when a microservice is invoked, and the invocation of our microservices is not bound i.e. if the workload means that a particular microservice is being called a lot, many instances of it can be created, and we are charged on a pay as you go approach, rather than limited by some arbitrary cap which limits the number of instances of the microservices running.
In the AWS world, this means we have moved from what we would call "monolithic" programming and split the program into smaller parts, called microservices, which really are independent programs which are passing information back and forth between each other, and to databases and event queues, in order to perform some work. For instance one microservice would simply interact with a database and write to it, and nothing more. Another would take a json object passed to it from the webclient and perform some work upon that information, before passing back the result.
Diagrammatically it looks something like this.
In this example, an API is handling our requests and based upon the request, the data from the front end it routed to one of a series of microservices, called Lambda Functions. In this example, it is likely the most used Lambda function is "getTodo", and so many instances of that can be created to meet demand, while the other Lambda functions are only invoked when required.
Splitting up a service into small functional parts like this opens up a lot of new options. We have already covered the first, being that different parts of the total service can replicate as their demand increases, without the need to replicate underused parts.
The next advantage is limiting access rights. AWS uses programmatic access management, and we can use this instead of VPNs, to create policies for how Lambda functions interact. For instance, the getTodo Lambda function can ONLY read from the Items table. This granular approach to access is a boon for both the security and stability of the code. If for instance, the getTodo Lambda function were to be changed to enable writing to a database, but the policy to allow that was not similarly updated, then the Lambda function would still be prevented from writing to the database.
Another useful aspect of creating services as a collection of event-driven microservices, is that code becomes much more sustainable. One of the driven philosophies of AWS Lambda is to keep it lean. This means that a) Lambda functions consist of very little code, and if they become large, that is likely a sign that it should be split into more Lambda functions or step functions, and b) but reducing microservices to small actions, we can then identify Lambda functions that have greater utility and can be reused in different parts of the service e.g. a Lambda function that is writing to a database can be used into different workflows in our service if at that point in the workflow we are passing the same sort of information to the same database.
So that is a taster of what Lambda functions and Serverless Computing means, and in no way exhaustive, as there are many other parts to Serverless Computing we can go into, and in the AWS sandbox we link together many different services to perform complex operations, such as Step Functions, Data Streaming, and Machine Learning.
Of particular note, is that Lambda functions can be written in a number of languages, and one of the more popular options is my favourite, Python, which opens up an entire toolbox of libraries to use to write Serverless applications with informative log files and tracing, which enables some deep analysis of how our application works.
Freelance Work
It's been a busy month on the freelance front for me, as I have finished two projects, and have another to go and likely a new one on the horizon. It's been a mix of work, but always fun when the project feels like the sort of thing that "writes itself" and so you can crack out 15k of words in less than a month. Hopefully, soon I can announce what those projects are. But soon to come to Kickstarter is another project I worked on earlier in the year. The next Iron Kingdoms RPG book is the Cryx setting book, which contains a whole host of new archetypes to play as, plus loads of information regarding the Nightmare Isle. This book was fun to work on simply for the fact that this book has never existed in any edition of the IKRPG, and it offers the chance to play as the undead minions of the Dragon Father.
Podcasting wise we have put out more interviews and episodes of Darker Days Radio and Darkhammer. A particular highlight was talking about the new Sabbat book with Khaldoun Khelil, and also some teases regarding the upcoming Second Inquisition book for Vampire the Masquerade.
Hobby Bench
Lots of freelance work means less hobby. So this month has seen me painting the terrain from Killteam: Nachmund, and putting together the new Chaos Marines and Aeldari Corsairs (both sets of minis are amazing and really show how Games Workshop has moved to this true scale). The terrain now means I have substantial amounts for Necromunda :D Pictures soon to come.
Comments