Many teams are moving inexorably away from monolithic software. While the phrase “monolith” has taken on a negative connotation, there’s nothing inherently wrong with monolithic software. The word describes a codebase that is self-contained and mostly independent.
Increasingly, we use the word monolith or legacy to mean a Big Ball of Mud, a codebase that is difficult to change, it’s capabilities are set in stone. The popular solution is application modernization, which usually involves microservices.
If circumstances haven’t changed much, legacy software doesn’t necessarily need modernization. When it does, organizations sometimes imagine a Big Lift and Shift Transformation. But that’s not how modernization works.
Moving from monolith to microservices (smaller, containerized applications) is an incremental decoupling of capabilities. Most of the time, microservices are brought online in relationship to the current (monolithic) software. Microservices are self-contained and independent, like monolithic software, but unlike monoliths, they depend on well-designed relationships with other software. Relationships replace the capabilities that were previously housed wholly inside the monolith.
Microservices are easier to change and evolve … unless they are tightly coupled. In a monolith, information is always available to all the code. Microservices have access to only the information they need, only when they need it. Redesigning the structure and flow of data is critical to loose coupling. When we modernize, we rearchitect space and time in our system.
The most difficult aspect of architecting microservices isn’t Kafka, Kubernetes, Docker or learning GoLang. (Though those skills are challenging!) The most difficult part is changing the way teams, and the organization, think about software. Teams need to adapt to new patterns and surrender those that don’t fit the new paradigm. For example, teams unwilling to let go of database transactions (as essential) will create very complicated microservices implementations.
Microservices rely on pattern thinking. Which often means transforming a linear software delivery approach into an adaptive, learning-driven approach. Otherwise, teams can’t help but build a Distributed Monolith In the Cloud.
How do we reconsider and adopt the patterns, in the technology and in the people, that support microservices? What guides our decision making? Where do we begin?
Here are some resources for diving into these questions. They’ll help us explore the patterns, perils and pitfalls while developing the thinking skills needed.
Just remember: there is no such thing as a microservice. The microservice architecture is an architectural style that structures an application (a.k.a. system) as a set of loosely coupled services.― Chris Richardson
You Might Enjoy …
November 29 – 30, 2022
YOW! London 2022
Internationally-recognized speakers, including some mentioned in this edition, explore emerging technologies and technology-agnostic best practices in the software industry.
You can attend in person or online.