If you're running less than 100 microservices, you might be able to circumvent these problems, but if you scale your services to any larger order of magnitude, this will bring its own problems, and in order for the system to run efficiently, you need to solve them.
1: Organizational isolation and sprawl
The anti-pattern of Conway's Law states that a company's organizational structure mirrors its software architecture. According to Fowler-Rigetti, a company migrating to microservices often ends up with several siloed microservice teams. Also, because no one knows what other teams are doing, and best practices can't be shared, the technology eventually spreads without direction.
"Microservice developers and developer teams are like microservices," Fowler-Rigetti said. "They're great when they're focused and doing one thing." This is fine for a specific team, but it becomes a problem when developers want to change teams.
Fowler-Rigetti said she's heard developers who have changed teams say they've moved to a new company because all the rules are different.
2: Fancy fault
The larger and more complex the system, the more likely it is to fail, so the system will fail. They usually arise from a few points. As hundreds of microservices are deployed, problems can arise in any of them. Please click here to enter image description
3: Competition for resources
Microservices provide services to organizations, and like ecosystems, they are complex and brittle, says Fowler-Rigetti.
Both hardware and engineering resources are scarce and expensive. Unlike monoliths, microservices can't solve problems with unlimited hardware or increasing the number of people. That might work at first, but over time you have more and more microservices, and it won't be able to accommodate the need to scale, she said.
So how should an organization prioritize when there are hundreds or thousands of microservices? Who gets priority? Who will make the decision?
4: Myths about Microservices
These misunderstandings spread among developers and managers, which is very dangerous for a fragile microservices ecosystem.
One of the most popular myths: Microservices is the Wild West. You can do what you want, use any code, database, programming language, etc., as long as you're done, other services can rely on it. The cost of doing this is huge, as the system may end up having to maintain multiple versions of libraries and databases.
Another dangerous myth: Microservices are a silver bullet, they will solve all problems. Fowler-Rigetti denies this. Microservices should be a step in the evolution of a company's architecture as it hits the upper limit of its ability to scale, not a shortcut to an engineering challenge.
5. Tech Sprawl and Tech Debt
When teams of developers use different languages, their own infrastructure, and custom scripts to build microservice structures, organizations end up with a huge system where there are a thousand different ways to do anything about it.
It could end up being hundreds or thousands of microservices, some running, most under maintenance, and others forgotten. "Your scripts are doing things that only God knows in one corner of the machine, and no one's going to want to sort them out," Fowler-Rigetti said. "They all want to build the next new thing."
The maxim: Any customization is not scalable. Architecture technology is an inescapable topic for programmers. About distributed, microservices, source code, framework structure, design patterns and other technologies, I share them in the group 650385180, which can be downloaded for free. I hope to help friends and children's shoes who are developing in this industry, spend less time looking for information in forums, blogs and other places, and spend limited time on learning. I will share these videos. I believe that for coders who have already worked and encountered technical bottlenecks, there must be something you need in this group.
6. Inherent lack of trust
Since microservices live in a complex dependency chain, they depend on each other, and there is no standardization and communication, so there is no way to be sure that the dependencies are reliable. There's simply no way to know if a microservice is trustworthy for production traffic, she said.
Out of the woods
If you're a developer and you're moving to microservices, the above is commonplace. How do you get out of trouble?
The first step is to get buy-in at all levels of the organization. In order to make microservices practical, standardization is not only a best practice, but a mission-critical one. It needs to be adopted and implemented at various layers of the stack.
Next, the company needs to "go across the entire organization, with high-level architecture, operational and organizational standards across all microservices, not on a service-by-service basis," she explained. Only when a microservice meets all of these criteria can it be considered "production ready".
standardization demands
The above diagram shared by Fowler-Rigetti shows the various layers of the microservice environment from the perspective of microservices. The microservice team only needs to work on layer 4.
To make microservices possible, something else needs to be abstracted from it. This will limit technology spread and increase scalability.
A lot of people think they get scalability for free with microservices, but that's not the case when you get to an insanely large scale.
Next, the requirements for "product readiness" need to be agreed, and these requirements need to be part of the engineering culture. Engineers often see standardization as a barrier, but in the new world of microservices, where each service belongs to a complex chain of dependencies, the barrier no longer exists, she said.
Microservices should not compromise the integrity of the entire product or system.
What makes a service "product-ready"?
Fowler-Rigetti gives a list:
stability
reliability
Scalability
performance
fault tolerance
disaster preparedness
monitor
Documentation
Fowler-Rigetti explains this in depth:
Stability and reliability
With microservices, there are more changes and faster deployments, which leads to instability. A reliable microservice should be trusted by its clients, dependencies and ecosystem, she said. She believes that stability and reliability are closely related, and most stability requirements will be accompanied by reliability requirements. A deployment pipeline with multiple stages before going into production is a good example.
Scalability and Performance
Fowler-Rigetti said most people think they can get scalability for free with microservices, but that's not the case at huge scale. They should scale appropriately as traffic increases.
Many languages are not designed to scale efficiently because they cannot be concurrent, partitioned, and efficient. This makes it difficult for microservices developed in those languages to scale reasonably. Fowler-Rigetti declined to point to specific language, but said, "I'm pretty sure I can think of some."
Scalability, she explained, refers to how many requests a microservice can handle. time, the size of the system should shrink accordingly), performance refers to how well the service can handle these tasks (translator: this should be called QoS). A high-performance service should use resources reasonably, handle tasks efficiently, and process requests quickly.
If a microservice does not scale as expected, the probability of its failure increases dramatically. Latency increases can lead to poor availability.
Fault Tolerance and Disaster Recovery
To achieve the ultimate goal of availability, developers need to be sure that any microservice failure will not cause the system to go down. Therefore, developers need to know all failure modes and make backups to deal with failures.
The key to successful disaster recovery is good resiliency testing, which includes code testing, load testing, and chaos testing with other proactive testing. Each failure mode should be reproduced in production to see if it "survives".
Given the complexity and complex dependency chains of a microservices environment, failures are unavoidable. Microservices must be able to withstand failures from both internal and external sources.
Monitoring and Documentation
"I've found that in a microservices architecture, the state of the system is never the same as the last second," Fowler-Rigetti said. "If you don't know the state of the system, you won't be able to know when the system fails, which can lead to eventual failure."
Having a good monitoring tool to show the state of the system at any time is critical. Lack of good monitoring tools is the second largest cause of service disruption.
Logging is an essential part of monitoring because you will be nearly impossible to reproduce bugs. The only way to know what happened is to be sure you recorded the state of the system at that time. The only recourse is reasonable logging.
This allows us to easily trust the service.
Documentation is a hindrance for every developer, but it's really critical. It removes technical debt and enables new team members to catch up.