Facebook Share
LinkedIn Share
Twitter Share


Microplatforms: Designing for Change with the Future of DevOps

Stuart Harris & Viktor Charypar, Red Badger

Cover Image

Technology departments fear change. Change “causes” issues and outages, people make mistakes, mistakes cost money. But change cannot be avoided.

The speed of change in all industries enabled by digital transformation is so fast now that we can no longer make large iterations and stand still in-between. Traditional organizations still try to manage or control change, which is just as ridiculous as a surfer trying to manage the wave.

Embracing continuous change is an opportunity for continuous improvement. Successful organizations are constantly changing every aspect of what they do and customers now expect their digital offerings to continuously improve as well. Accepting this as inevitable, we can design for change and make it easy, fast and safe. In the digital space, this means designing for Continuous Deployment to Production (CDP).

A natural extension of Continuous Integration (CI) and Continuous Delivery (CD), CDP means that every change made to the product codebase will go into production within a few minutes as long as it passes all the validations. Doing more deployments sounds like it would increase the deployment related risk of failure, but in reality, as the deployments happen more and more often and the gap between them tends to zero, the size of each change tends to zero as well and the risk associated with deploying that change also tends to zero. CDP is the safest way to embrace continuous change.

In order to practice Continuous Deployment to Production, a strong safety net has to be in place and every aspect of the process has to be automated to be fast and extremely reliable.

The process needs to precisely fit the team and has to freely change and evolve with the team’s needs. The impact of the changes (and also human error) has to be reduced to the absolute minimum—the blast radius has to be small.

Capabilities of automation in every layer of the stack and every step of the development process have recently come together to enable an approach we are calling Microplatforms: small, independent, and fully capable platforms for microservices applications.

Microservices architecture enables flexibility, better scalability and reliability and forces strong boundaries around domain concepts, leading to a better design, making change more local and therefore easier and cheaper. However, it also brings a whole new level of complexity to manage—because microservices can be deployed individually, making sure the system as a whole still works as intended is much more difficult.

With Microplatforms, we intend to bring some of the simplicity of monolithic application architecture back by treating the orchestration of the microservices that form an application as a first-class concept, in code.

Full automation of infrastructure provisioning, application build, testing and deployment ensures environments are identical, repeatable, disposable and cheap. This not only speeds up the process of setting up infrastructure and deploying onto it, it also means problems can be discovered earlier, even on a developer’s laptop, because the environment is identical to the production one. Being written down as code, every aspect of the approach can evolve the same way that the applications themselves do. Platforms managed entirely as source code are the best enabler for Continuous Deployment into Production we have seen to date.

It is also an enabler for high levels of autonomy of the teams. A small cross-functional team can own all aspects of the product from design, build and testing to 24/7 operations to infrastructure provisioning, from cradle to grave (if there even is a grave). The high level of automation and design driven by simplicity allows a team of fewer than ten people to do a job that used to take hundreds and allows more effort to be spent higher up the value chain—on work that really matters.

This autonomy leads to positive variation between teams, driving a continuous improvement of the overall approach to product delivery. Individual improvements get adopted and evolved by other teams and everyone helps each other move forward and make things better. Aligned autonomous teams are by far the best organizational design for change and can scale horizontally without creating bottlenecks. This is what we’re hoping to enable with Microplatforms.

Author picture
About the author: Stuart Harris is Chief Scientist and co-founder of Red Badger. With a burning desire to empower autonomous teams, Stu is driving digital transformation in large corporations whilst many are still just talking about it, saving them time, cash and enabling them to focus all of their efforts on delivering user value. Despite his youthful looks, Grandad Stu has been innovating the UK tech industry since the 80’s and has been known to dance like he’s still there.

Viktor Charypar is a Tech Director at Red Badger. For the past five years he’s been helping guide large organizations through digital transformation by demonstrating a better, leaner way of designing and delivering digital products, focusing on enabling DevOps and team autonomy, so that designers and engineers can spend as much effort as possible on delivering customer value.