Coding in the clouds

This an evolving document

The definition of “the cloud” is the resources that make up a computing infrastructure, such as virtual machines, storage, and fundamental applications, used as a utility rather than having to build and maintain these resources in house. The general trend of computing infrastructure is to be further and further abstracted and in this way serverless is the next generation of cloud, it’s about as abstracted as you can get. The benefit of this abstraction is that the infrastructure becomes more stable (highly available, fault tolerant), more scalable (you can just turn a knob to get more resources), more agile (more easily connect to different services and people), and more distributed.

At its core the serverless model of software development relies on discreet units of code interacting with PaaS (platform as a service) and SaaS (software as a service) services. These discreet units of code are usually hosted on Function-as-a-Service platforms such as AWS Lambda,Google Cloud Functions, Microsoft Azure Functions, and others with no configuration and maintenance of servers and where you only pay for the computing time and storage that you use. An alternative to this is platforms such as OpenStack where you host your own cloud, this can be useful for on premises solutions where you require this for legal or other such reasons.

Like any major shift in computing it means we need to migrate away from some of the patterns we have mastered over the years, but it also means we have a whole new set of bigger toys to play with, and some of the other toys have a new place in our lives. It also means we need to get better at documenting our work, diagrams are especially helpful here.

DevOps principles seem to be essential to keep this stuff manageable, especially the principle of infrastructure as code. Serverless is still relatively young but has the benefit of many years of process evolution, some tools for this are:

The evolution of database technology is cyclical, the better our database technology the more data we find to store and the better our database technology needs to be. Relational database technology was designed to reduce redundancy because storage was expensive and CPU was relatively cheap. Today this is flipped, storage is cheap and CPU is expensive, NoSQL is a response to this.