Devops for Growth

DB: Interesting. You said previously, in order to migrate to microservices, you have to learn how to strangle the monolith. Can you explain it to us a little a bit?

CR: You know, interestingly, it's sort of a slightly violent term. And it actually goes back to an application modernization strategy that Martin Fowler promoted in 2006, I believe, known as the Strangler Application. And he has since modified it to the Strangler Fig Pattern. And so I guess one day he was going for a walk in a rainforest, I think in Queensland, right? Do they have rainforests?

DB: They do in Northern Queensland.

CR: Yeah. And so he got inspired. He came across a Strangler Fig, which is this plant that starts off life in the canopy of a tree and then actually grows down to the ground and establishes roots and basically grows so large it envelopes or sort of, you could say shades out the tree, and that can actually cause the tree to die.
And so that was where he got inspired to think about modernizing applications that way. So instead of doing a big bang rewrite, which is extremely time consuming and risky, you actually incrementally build up a strange regular application around the legacy application. Sort of migrating functionality out of it, you know? Very intuitively. And so the legacy applications shrink, and the Strangler Application continues to grow. And so that was his generic application modernization pattern. And that's how you should migrate to a microservices architecture.

Tackling complexity in large Software Systems was always a daunting task since the early days of Software development (1960's). Over the years, Software Engineers and Architects made many attempts to tackle the complexities of Software Systems: Modularity and Information Hiding by David Parnas (1972), Separation of Concern by Edsger W. Dijkstra (1974), Service Oriented Architecture (1998).

All of them used the age-old and proven technique to tackle the complexity of a large system: divide and conquer. Since the 2010s, those techniques proved insufficient to tackle the complexities of Web-Scale applications or modern large-scale Enterprise applications. As a result, Architects and Engineers developed a new approach to tackle the complexity of Software Systems in modern times: Microservice Architecture. It also uses the same old “Divide and Conquer” technique, albeit in a novel way.

Software Design Patterns are general, reusable solutions to the commonly occurring problem in Software Design. Design Patterns help us share a common vocabulary and use a battle-tested solution instead of reinventing the wheel. In a previous article: Effective Microservices: 10 Best Practices, I have described a set of best practices to develop Effective Microservices. Here, I will describe a set of Design Patterns to help you implement those best practices. If you are new to Microservice Architecture, then no worries, I will introduce you to Microservice Architecture.

By reading this article, you will learn:

• Microservice Architecture
• Advantages of Microservice Architecture
• Disadvantages of Microservice Architecture
• When to use Microservice Architecture
• The Most important Microservice Architecture Design Patterns, including their advantages, disadvantages, use cases, Context, Tech Stack example, and useful resources.

Please note that most of the Design Patterns of this listing have several contexts and can be used in non-Microservice Architecture.

There are many other patterns used with microservice architecture, like Sidecar, Chained Microservice, Branch Microservice, Event Sourcing Pattern, Continuous Delivery Patterns, and more. The list keeps growing as we get more experience with microservices.

Remember that such things as web services are also presentations, even though they are used by computer users rather than human users. So don't intermix domain code with the code required to support a web service, or indeed any other external API.

En 2013, Segment a démarré avec une architecture monolithique. Cela permettait des coûts d'exploitation réduits, mais n'apportait pas d'isolation système. Les fonctionnalités de Segment s'appuient sur l'intégration de données de différents fournisseurs. Dans le monolithe, des problèmes de connexions à un fournisseur peuvent avoir un effet négatif sur l'ensemble des connexions et sur le système entier.

Le manque d'isolation à l’intérieur du monolithe fut adressé par l'adoption des microservices, avec un "service worker" par destination (fournisseur). Les Microservices ont également amélioré la modularité et la lisibilité au travers du système, permettant à l'équipe de monitorer les queues et identifier les problèmes facilement. Alexandra Noonan nous a fait remarquer que l'on peut concevoir un monolithe en le rendant plus lisible, mais que les microservices ont cette qualité par défaut. Par contre, ceux-ci engendrent un surcoût sur les opérations et posent problème quant à la réutilisabilité du code.