Microplatforms. The best enabler of continuous deployment ever

Extremely high levels of automation in the area of infrastructure provisioning and container orchestration have recently enabled a capability we are calling microplatforms - small, and fully capable platforms for microservices applications.

This is a concept that allows a cross-functional team to manage, create and destroy (but not modify, because of Immutable Infrastructure) their own short-lived platforms on which they can choreograph a collection of microservices.

100% automation (terraform, Dockerfile, Kubernetes, yaml config etc) ensures environments are identical, repeatable, disposable and cheap. The best enabler for Continuous Deployment into Production we have seen to date.

Until recently it made sense for large organisations to build shared platforms by creating teams that, often manually, provisioned servers, VMs, and supporting software. It was a high cost activity so it made sense to amortise that cost across the business.

Now that cloud providers have mastered infrastructure provisioning by API, full automation is possible. Today that time is better invested in writing code that declaratively specifies what the platforms, networks and supporting infrastructure should look like, down to the last detail.

This makes it possible to create in seconds or minutes what would have taken months before. Because it’s fast and declarative, it becomes cheap, repeatable, reliable and fully auditable.

This top to bottom automation now allows cross-functional teams to create, manage and destroy environments for their applications with little effort, saving time and money, whilst improving on reliability and reducing MTTR.

Their conversations with the shared “platform teams” move from “Please can you install MongoDB on this VM?” to “Please will you accept this Pull Request?”. Now everyone can take advantage of the change and there is code that can be evolved in the community. For already accepted practices, no coordination outside the team is necessary.

When everything becomes code, that’s where the sharing and reuse happens. That’s where we improve things. And then we just build and deploy our code to do those things.

Things like creating VMs, subnets, clusters, service meshes and microservices. It’s a forward-only paradigm that always starts with changing source code. If a subnet needs a bigger CIDR block, we change the Terraform code and re-apply it.

If a microservice needs an egress route to a service on the internet, we change the Istio yaml file and re-apply that. If a microservice has a bug, we change its source code and re-apply that (through the CI/CD pipeline).

If we ensure that every time we re-apply our code, it’s idempotent (i.e. we can apply it as many times as we like and the net result will be the same), then we can re-apply the whole stack if we want to, and only the things we changed will be replaced.

This is the core concept behind microplatforms. The ability to splat our application (and if necessary, it’s supporting infrastructure) onto a provider-agnostic “substrate” whenever we want to.

We can create and destroy production-identical, ephemeral environments to do performance testing, for example, in minutes. Even production environments can (and should) be short-lived. You wouldn’t create new production environments on every deployment (there could be hundreds of those each day), but they would be recreated as the underlying code evolves (e.g. a security patch is released).

Microplatforms have a small blast radius, are cheap to create and destroy, enable continuous deployment into production, reduce risk and MTTR, increase reliability and repeatability, and can be managed within a cross-functional team. They can massively improve a team’s velocity and help prevent large organisations from grinding to a halt behind inter-team dependencies.

Learn more about Microplatforms here.