Using monoliths and allowing the future to flourish

"Who gets the job of pushing the knob? That sort of responsibility you draw straws for, if you're mad enough“ - The Stranglers - "It's always the sun"

In the age of digital cannibalization in e-commerce, it is becoming increasingly important for decision-makers in German SMEs to keep pace with modern architectures and drive forward their own digital transformation. But how can you break up the existing software landscape and pave the way for a more agile and future-proof corporate structure? What do strangler figs and software systems have in common?

The way a “strangler” works is only partially suitable for describing the path to a sunny future. But sometimes you have to break new ground, disregard the tried and tested and sometimes “walk over (software) dead bodies”. Nature makes this very easy: always towards the sun! This is what the strangler fig does, for example, which “strangles” old trees in the tropical rainforest by clutching them and thus fights its way into the light. The old trees die off over time and a strangler fig remains, which is only indirectly recognizable as the support it once embraced.

How can this be applied to established software systems and their replacement?

The British-American author and recognized software architecture pope Martin Fowler used this analogy to the strangler fig for his architecture pattern of the “Strangler (Fig) Application”, a software application that gradually takes over the function of old, monolithically grown software systems. This architectural pattern or the analogy to the strangler fig is almost 20 years old. 15 years after the initial post, Martin Fowler changed the term from “Strangler Application” to “Strangler Fig Application” in order to interpret the sometimes brutally interpreted analogy to a strangler more in the direction of the behavior of the strangler fig.

Two important aspects of this pattern (of nature) are resource optimization and risk minimization. How much faster could a new plant grow into the sky if the roots of the ancestral placeholders were first cut and the “support corset” removed? Could the strangler fig grow “independently” upwards towards the sun or would it tend to bend sideways? How much biomass would the plant itself have to produce in order to grow to the same height or higher? How much oxygen would not be produced if the previous producers were eliminated with an axe blow right at the start?

Modernizing a software architecture: A pragmatic approach to migrating from monoliths to microservices

The first step is always the decision to break new ground and move beyond established, monolithic software architectures.

A rough procedure for migrating services from the monolith to a new service architecture comprises the following phases:

1. analysis and division: Identify business areas, separate components and define independent microservices. Simplify your application and also consider the database and access controls.
2. interfaces and communication: Define clear communication protocols and interfaces between microservices. Choose RESTful APIs, Message Queues or Event Streaming based on the requirements and expertise of your team or the team of the selected service provider.
3. step-by-step migration and monitoring: Perform the migration step-by-step and monitor the progress. Ensure data consistency, troubleshoot issues and ensure a seamless transition.

In the spirit of Conway's Law, which states that communication channels and organizational structures in a company very often also influence or even limit the design and development of the software systems used, you should also take a look at this aspect in a company or, even better, have it looked at from the outside.

What does the software-technical foundation of these services look like?

Setting up a so-called MACH service architecture (acronym for “microservices-based, API-first, cloud-native and headless”), e.g. in a Managed Kubernetes Service (AKS) in Azure or an Amazon Elastic Kubernetes Service (Amazon EKS), is an ideal breeding ground for new shoots and thinning out the “heavyweights” in the thicket of the existing software jungle. The flexibility of an AKS or EKS cluster also enables parallel processing and commissioning of different services by several development teams.

An example of the application of the “Strangler Fig Pattern” and the use of a Managed Kubernetes Service (AKS) in Azure is the Product Portal for architects and planners of the Hörmann company, which was implemented together with communicode.

More information on Composable Business and Commerce through MACH architecture can be found here in our blog.

If you have any questions about modern architectures, technologies, but also for a conversation about “music in IT”, please do not hesitate to contact me.