Patterns, heuristics and elephants!

Patterns, heuristics and elephants! Why elephants? Because elephants are an observable phenomenon, a pattern in nature. We observe them, they are described and represented in various ways and even some people claim to know all about them. The fact is that our knowledge from elephants is limited.

This article by making an example of elephants talks about challenges, taboos and problems related to understanding and using patterns. But what are these challenges or taboos? The challenge of representing and explaining a pattern for authors, dealing with newborn patterns, the idea of having a whole book for a pattern, the minimum needed questioning and … are all just a few examples of what can be discussed. These problems and concerns are the elephant in the room, they exist but no one talks about them.

The reason that trigged me the most to read this article was curiosity about the mindset of pattern authors and gatherers. Because when we look at this issue from a distance, we start to realize that we developers are solving puzzles with techniques invented by them. Before I come across this article this thought was something that one friend and I had a conversation about and our main question was that where these people’s point of view comes from and in order to reach that point which mental strains should be loosen. If issues that are discussed in article interests you or you have a question like mine, I suggest that you read this.

Download article

Uber & microservice case

Studding Cases of Utilizing modern methods in big tech companies can be valuable and informative. This case is one the interesting ones in which Uber company’s engineers explain that how and when they migrated towards microservice architecture. In this case Uber’s engineers have taken a road to a style of microservice architecture which was named as “Domain-Oriented Microservice Architecture” by themselves.
Some parts of this story:

As a result, we adopted a microservice architecture. Ultimately our systems became more flexible, which allowed teams to be more autonomous.
🔘 System reliability. Overall system reliability goes up in a microservice architecture. A single service can go down (and be rolled back) without taking down the whole system.
🔘 Separation of concerns. Architecturally, microservice architectures force you to ask the question “why does this service exist?” more clearly defining the roles of different components.
🔘 Clear Ownership. It becomes much clearer who owned what code. Services are typically owned at the individual, team, or org level enabling faster growth.
🔘 Autonomous execution. Independent deployments + clearer lines of ownership unlock autonomous execution by various product and platform teams.
🔘 Developer Velocity. Teams can deploy their code independently, which enables them to execute at their own pace.

Source: https://eng.uber.com/microservice-architecture/

Criticism and review

Chris Richardson is one of the experts in the field of microservice architecture. In the majority of his talks, he emphasizes that “Use monolith as much as you can.” And use microservice architecture only when you are sure that monolith architecture is not enough for you.

Make the most of the monolithic architecture.
The monolithic architecture is not an anti-pattern.
If software delivery is slow =>
▫️ Optimize development process
▫️ Improve deployment pipeline = more automation
▫️ Improve team autonomy
▫️ Modularize the monolith
▫️ Eliminate hand-offs and create cross functional teams
▫️ If technology stack is obsolete => modernize to a new monolith

Read more: https://www.slideshare.net/chris.e.richardson/decompose-your-monolith-strategies-for-migrating-to-microservices-tide

Microservice or monolith?

این تصویر دارای صفت خالی alt است؛ نام پروندهٔ آن photo_2020-12-15_19-24-44-1024x766.jpg است

Chris Richardson is one of the experts in the field of microservice architecture. In the majority of his talks, he emphasizes that “Use monolith as much as you can.” And use microservice architecture only when you are sure that monolith architecture is not enough for you.

Make the most of the monolithic architecture.
The monolithic architecture is not an anti-pattern.
If software delivery is slow =>
▫️ Optimize development process
▫️ Improve deployment pipeline = more automation
▫️ Improve team autonomy
▫️ Modularize the monolith
▫️ Eliminate hand-offs and create cross functional teams
▫️ If technology stack is obsolete => modernize to a new monolith

Read more: https://www.slideshare.net/chris.e.richardson/decompose-your-monolith-strategies-for-migrating-to-microservices-tide