Monoliths gained popularity because they were safe: easy to build, easy to operate, and secure. They were in fact the way software was built for a fairly long time. But the way we build things is changing fast.
A monolith is not a good platform for fast, radical technological evolution—the sort of evolution that wins new markets. Monoliths lock a business into a particular feature set, putting them at serious risk on multiple fronts. They face pressure from more dynamic competitors stealing away market share because they can deliver faster, or by driving down margins because they can deliver more cheaply. Or those competitors pose the ultimate risk: simply beating them to new customers.
During our research in industry and our work with enterprises like Shell and Adidas, Container Solutions have consistently observed a strong desire to compete and differentiate via rapid experimentation and adaptation. A monolith is not a good platform for this kind of responsive and iterative change, and that is precisely why it is no longer a safe platform at all.
The Answer Is Cloud Native
An increasing number of enterprises are adapting flexible architectures that fully support freedom of movement. The most popular of these architectures utilises a combination of small independent processes (microservices) hosted on flexible infrastructure (cloud) and managed with an automated orchestration framework (for example, Kubernetes). This approach is what we think of as 'Cloud Native' and is widely used from hyperscale online businesses like Google and Netflix to younger, fast-growing services like HolidayCheck and Zoover.
Cloud Native is not a single architecture but a set of tools and an overall approach. At Container Solutions we are vendor-neutral. We work with enterprises to teach them about all the tools available and select the right ones for them. We enable enterprises to reconfigure themselves to move quickly, with smaller, nimble steps to
- Decrease risk: every decision is less critical and results are assessed immediately.
- Make strategic direction changes fast.
- Use rapid iteration to uncover and refine successful strategies ASAP.
The Dangers of Cloud Native
Despite its advantages we believe there are four critical dangers in pursuing Cloud Native without guidance.
- Philosophy. Changing from a company that delivers big changes slowly to one that delivers small changes fast is a cultural shift, not merely a technical one. Doing it piecemeal or focussing only on tech will not deliver the full benefits.
- Risk. Throwing out a working monolith and re-implementing whole systems from scratch as complex, untried microservices is a highly risky strategy. Microservice design requires advanced tech knowledge that takes time to learn. Without that knowledge, newly built systems will be unstable and insecure.
- Commitment. Major organisational changes like those above require serious, company-wide senior management commitment. That can be very hard to deliver.
- Complexity. Cloud Native is a broad term covering lots of options and potential gains. A high percentage of the businesses we encounter struggle to know where to start, or become bogged down on too many fronts.
Controlling the Dangers
It is simply less difficult and less risky to deliver small, iterative projects than huge 'big bang' ones. Small projects are also more obviously viable, making it easier to develop buy-in. But is iteration a workable option for getting enterprises from where they are now to a Cloud Native culture and architecture?
“The vast majority of enterprises we have encountered now using microservices got there by evolving their monolith—not replacing it.”
Evolve Your Monolith
In our judgment, the fundamental motivation for microservices and Cloud Native is to transition businesses from a culture of high-risk, utopian, 'big bang' deliveries to iterative, lower-risk releases with quick ROI or speedy failure.
We believe it’s perverse to kick this journey off with a risky big bang by rewriting your monolith. Surely there must be a better way? In fact, the vast majority of enterprises we have encountered now using microservices got there by evolving their monolith, not replacing it.
This may be a transitional architecture but often it is not. Many organisations keep their monolith for at least some of their core functionality.
Evolution is not easy, but it is often the most effective strategy.
Mono+Micro Architectures (MoMi)
There are a dizzyingly large number of approaches an enterprise can take to evolving their monolith (models like 'llft and shift', 'sidecars', 'API-first' and 'ambassadors'). The right mix depends on a company’s existing tech and priorities. Different approaches have different strengths and weaknesses. We believe it is imperative that companies evaluate which evolution strategy works for them, based on a solid understanding of the available options.
Container Solutions has a range of proven template plans and step-by-step implementation processes for Mono->MoMi migrations that we tailor for individual businesses. Container Solutions employs experts in this field, experienced consultants who can assess the right strategy and help get the ball rolling.
We then have a wide range of teaching materials and courses to allow us to ramp up the client’s engineers and hand over the successful running of their environments ASAP. We have no desire to be either a long-term Cloud Native crutch or an impediment.
Build a Platform for Change
It makes sense to build a platform for iterative change iteratively, so your platform quickly helps build itself.
Start with the fundamentals and add complexity later. Begin with basic automated testing, scripted environment creation, Continuous Integration/Continuous Delivery (CI/CD), and containerisation. Choose the best-fit mono-micro architectural strategy and orchestrator and gradually introduce them into production. Just say no to big bangs.
If you have a successful monolith, start there.
- Build a basic platform for development and operations.
- Adopt the best adaptive MoMi architecture pattern for you.
- Roll it all out small, step by small step.
In the long term, a more nimble technical platform will enable a more autonomous organisation. As choices become less risky, they can be made lower down the chain of command. As any Cloud Native architecture matures, development methodologies will also need to evolve to support faster, more delegated decision making.
The aim is to achieve an adaptive organisation that is comfortable with change. One that is experimental but can still manage risk effectively. There is no reason this can’t start today, and there is no need to start by throwing out the monolith completely—it’s not on fire. Yet.
Previous article
