Over the last few years, I have been lucky enough to work on several so called “Cloud First”, “Shift Left” or “Cloud 2.0” projects for different clients. What they all had in common is their heavy usage of Platform as a Service and/or Function as a Service technologies.
As the innovation and technology changes in the Cloud space is so rapid it is vital to understand what the client is hoping to achieve from its Cloud journey. For this reason I usually start with the following diagram below by Paul Kerrison (https://www.paulkerrison.co.uk/random/pizza-as-a-service-2-0) to show just how different these modern architectures are at the infrastructure level and how those differences ripple through the makeup of the team and their responsibilities.
Docker based solutions are more complex than those that utilise technologies built by the Cloud providers. Hence, I recommend that that teams utilise Docker if their solution needs to be able to cross Cloud providers or when components need to run within an organisation’s own data centre.
The primary driver for using Platform as a Service (PaaS) or Function as a Service (FaaS) is to leverage the Cloud providers extraordinary levels of automation in the areas of software defined networking, firewalls, patching, scaling, managing backups, replication and cross region/data centre high availability.
Often the easiest and first component to move to PaaS is the database with both Azure SQL and Amazon RDS being robust mature technologies. Although they are more expensive than a self-managed solution when the additional labour costs are included in the analysis the total ROI is often far lower. Further we have had great success using the serverless configuration of SQL Azure which automatically scales the database based on load. For systems that are idle at night the serverless costs can be 60% lower than using a static server sizing.
The next component to move to PaaS is the web server. Often there will need to be some minor code changes required as part of the migration. Issues can occur when the website connects to local or remote file storage which need to be replaced with a cloud storage solution. Or when its running under an integrated security context which will need to be moved to a Cloud security API such as Azure’s Managed Identity or a simple username and password combination.
Next scheduled jobs that are kicked off by CRON or Windows Schedular are converted to AWS Lambda or Azure Functions. This can lead to the removal of all Virtual Machines from the solution.
The removal of VMs enables a simplified networking and security model. Where instead of locking down the subnets that host VMs the firewall rules are lifted into the application layer where IP Address filtering and role management are combined to provide a richer security model.
These changes lead to a different team makeup as well. The environment support team will naturally reduce in size as that function as been outsourced. There are entire classes of problems that effect environment support staff that are eliminated by Cloud such as those caused by differences between environments. The Cloud provider will ensure that their PaaS and FaaS components are at the same patch level.
The next change is driven by Infrastructure as Code where Cloud resources are created via scripting against APIs as opposed to being built manually. This innovation is turning Infrastructure Architects into programmers and programmers into environment experts. This cross skilling is extremely beneficial to the team. I would recommend that pair programming techniques are utilised as we have found that there is often lots of code duplication and poor error handling in code written by Infrastructure Architects. Meanwhile infrastructure code written by developers may not have firewalls configured correctly or can be oversized.