The benefits of cloud native architecture are real, but they belong to software that was designed to earn them. There are five worth having: capacity that follows demand, failures that repair themselves, releases that become routine, less software for you to patch, and an environment that is written down and can be rebuilt. How much they are worth to you depends on how often the system changes and what it costs the business when it stops.
What cloud native means
Cloud native is not the same as “runs in the cloud”. An application moved unchanged onto a rented virtual server is in the cloud, but it still behaves like software on a single machine. Cloud native software is built to use what a cloud platform provides.
The Cloud Native Computing Foundation, the body that looks after much of the open-source software in this area, defines cloud native systems as loosely coupled and “secure, resilient, manageable, sustainable, and observable”. In practice that means some combination of the following.
- Containers. A container packages an application with everything it needs to run, so it behaves the same on a developer’s laptop and on the live platform. Kubernetes is an open-source system for running containers across a group of servers.
- Managed services. The database, file storage and message queues are run by the cloud provider, not installed by you on a server.
- Serverless functions. Small pieces of code that the provider runs on demand and charges for by use, with no server for you to look after.
- Microservices. The application is split into parts that are released and scaled separately.
- Infrastructure as code. The servers, networks and settings are described in files, and a script builds the environment from them.
A system does not need all five to count, and most business systems are better off without some of them.
The five benefits
1. Capacity follows demand
A cloud native application can run as several identical copies behind a load balancer, which shares incoming requests between them. The platform adds copies when the system is busy and removes them when it is quiet. You stop paying all year for the capacity needed on the busiest day, and a sudden rush is absorbed without anyone resizing a server.
2. A failure is contained and repaired without a phone call
Because each copy holds no data of its own, a copy that fails is simply replaced by the platform. A fault in one part, such as report generation, need not take down order entry. Compare that with a single server, where one full disk stops everything until a person intervenes.
3. Releases become small and routine
A new version is built, tested and released by an automated pipeline, a practice described in what is DevOps. The new version can be started alongside the old one and traffic moved across gradually, with a quick way back if something is wrong. Changes that used to be saved up for a risky evening release can go out a few at a time during the working day.
4. There is less for you to patch
On a virtual server, the operating system and the database software are yours to update. On managed services the provider does it. That takes much of the end-of-support cycle for Windows Server and SQL Server off your list. It is also the direction the National Cyber Security Centre recommends. Its cloud security guidance advises building applications on managed platforms in preference to virtual servers, and delegating as much responsibility for security to the cloud platform as you can.
5. The environment is written down
When the whole environment is defined in files, a test copy identical to the live system can be created when it is needed and thrown away afterwards. After a disaster the environment can be rebuilt from the same files. Knowledge of how the system is set up no longer lives in one engineer’s memory, which matters on the day that engineer leaves.
What it costs
More moving parts. Ten small services have ten sets of settings and ten ways to fail, and a call that used to happen inside one program now crosses a network. For a system used by a few dozen staff, splitting the application into microservices usually adds cost without adding anything those staff would notice. In our experience a single well-structured application on managed services gets most of the benefit.
Scarcer skills. Kubernetes in particular needs people who know it well. If only one person at your supplier understands the platform, you have swapped a server in a cupboard for a different kind of dependence.
A less predictable bill. Paying by use is cheaper when use is low and can surprise you when it is not.
Closer ties to one provider. Containers move between providers fairly easily. Serverless functions and most managed services do not, so the more of them you use, the more work it would be to leave.
The risk of a rewrite. Rebuilding a working system from scratch to make it cloud native carries all the usual dangers of replacing software that the business depends on. We set those out in should we rewrite or modernise legacy software.
How an existing system gets there in stages
A system that runs on a server today does not have to be rebuilt to gain these benefits. It can pick them up one at a time, and stop at any stage.
- Move it as it is, but build the new environment from scripts. That delivers benefit 5 immediately. A cloud migration of this kind usually needs configuration changes only.
- Move the database to a managed service. Backups and patching of the database become the provider’s job.
- Take files and scheduled jobs off the server. Uploaded documents go to the provider’s file storage and overnight jobs to a scheduling service. Once nothing is stored on the server itself, it can be replaced or duplicated freely, which opens the way to benefits 1 and 2.
- Automate the build and release.
- Upgrade the application’s platform. Older Microsoft applications are built on .NET Framework, which runs only on Windows. Modern .NET also runs on Linux, in standard containers, which avoids the Windows licence charge. A .NET upgrade assessment establishes how much work that step would be.
- Split out a part only where it has a need of its own, for example a document-processing job that is busy for one hour a day.
The National Cyber Security Centre is cautious about stopping at stage 1. It recommends avoiding a machine-for-machine move, known as lift and shift, where possible, warns that such a move “will not fully realise the security benefits that can be provided by the cloud”, and encourages those who start that way to go on to managed components.
Questions to ask before agreeing to a cloud native rebuild
- Which of the five benefits does the business need, and what is each one worth in money or in risk removed?
- Can we reach them in stages while the current system stays in use?
- Who will be able to run this platform in three years, and how many such people are there?
- What will the monthly bill be at present usage, and at double?
- Which parts would tie us to one provider, and what would leaving involve?
If the answers to the first two are vague, the proposal is probably about the technology and not about your business.