There are six issues that every organization encounters when implementing a microservices architecture to cope with scaling. Susan Fowler-Rigetti, a former Uber engineer at Stripe, detailed these six issues at the Microservices Practitioners Summit in San Francisco last month. She claims that you can probably get around these problems if you are running fewer than 100 microservices, but scaling up services to arbitrarily large scales brings its own problems that you need to solve in order for the system to run efficiently.

1: Organizational isolation and spread

The anti-pattern of Conway’s Law suggests that a company’s organizational structure can map its software architecture. Fowler-Rigetti says a company that migrates to microservices often ends up with several isolated microservices teams. In addition, no one knows what the other teams are doing, and best practices cannot be shared, resulting in technology spreading without direction.

“Microservices developers and teams of developers are like microservices,” Fowler-Rigetti said. “They’re great when they focus and do one thing.” This is great for certain teams, but it becomes a problem when developers want to change teams.

Fowler-Rigetti says she has heard developers who have changed teams say they feel like they are moving to a new company because all the rules are different.

2: fancy failure

The bigger and more complex the system, the more likely it is to fail, and therefore the system will fail. They usually occur at a few points. As hundreds of microservices are deployed, any one of them can have problems.

3: Resource competition

Microservices provide services to organizations, and like ecosystems, they are complex and fragile, Fowler-Rigetti said.

Hardware and engineering resources are scarce and expensive. Unlike stand-alone apps, microservices can’t solve the problem with unlimited hardware or more people. This may work at first, she says, but as time goes on and you have more and more microservices, it won’t be able to scale.

So how should organizations prioritize when there are hundreds or thousands of microservices? Who gets priority? Who decides?

4: Myths about microservices

These misconceptions spread among developers and managers, and are dangerous for the fragile microservices ecosystem.

One of the most popular myths is that microservices are the Wild West. You can do whatever you want, use whatever code, database, programming language, etc., and once you’re done, other services can rely on it. This can be costly, as the system may end up having to maintain multiple library and database versions.

Another dangerous myth: microservices are a silver bullet that will solve all problems. Fowler-Rigetti denies this. Microservices should be a step in the evolution of corporate architectures as they reach the limits of their ability to scale, not a shortcut out of engineering challenges.

5: Technology contagion and technology debt

When teams of developers build microservices using different languages, individual infrastructures, and custom scripts, organizations end up with a vast system where there are a thousand different ways of doing any one thing.

It could end up being hundreds of microservices, some of which are running, most of which are in maintenance, and some of which are forgotten. “Your scripts are in the corner of the machine doing god knows what, and no one wants to clean them up,” Fowler-Rigetti said. “They all want to build the next thing.”

Words of wisdom: Any customization is not extensible.

6. Inherent lack of trust

Since microservices exist in complex chains of dependencies, they depend on each other, and there is no standardization or communication, there is no certainty that dependencies are reliable. ‘There’s no way to know if microservices are reliable for production traffic,’ she says.

Out of the woods

If you’re a developer and you’re moving to microservices, this is pretty common. How do you get out of this mess? The first step is to get buy-in at all levels of the organization. To make microservices viable, standardization is not only a best practice, it is a critical mission. It needs to be adopted and implemented at all levels of the stack.

Next, companies need to “control high-level architecture, operations and organizational standards across all microservices, rather than on a service-by-service basis”, she explains. Only when a microservice meets all of these criteria can it be considered “production-ready.”

Demand for standardization

The figure above shared by Fowler-Rigetti shows the various levels of a microservice environment from a microservice perspective. The microservices team only needs to work at level 4. To make microservices possible, something else needs to be abstracted from it. This will limit technological sprawl and increase scalability. A lot of people think they’re getting scalability for free with microservices, but that’s not the case when you get to a crazy scale.

Next, product-ready requirements need to be agreed upon, and these requirements need to become part of the engineering culture. Engineers often see standards as a barrier, she says, but in the new world of microservices, where each service belongs to a complex dependency chain, the barrier is no longer there. Microservices should not compromise the integrity of the entire product or system.

What makes a service “product-ready”? Fowler-Rigetti gives a list:

• The stability of

• reliability

• scalability

• performance

• Fault tolerance

• Disaster preparedness

• monitoring

• The document

Fowler-Rigetti explains this further:

Stability and reliability

With microservices, more changes and faster deployments lead to instability. A reliable microservice, she says, should be trusted by its customers, dependencies and ecosystem. She believes that stability and reliability are closely related, and most stability requirements are accompanied by reliability requirements. A good example is a deployment pipeline that has multiple phases before going into production.

Scalability and performance

Fowler-Rigetti says most people think they can get scalability for free with microservices, but that’s not the case with huge scale. As traffic increases, they should be appropriately expanded.

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 properly. Fowler-Rigetti declined to name specific languages, but said, “I’m pretty sure I can think of some.” Scalability, she explained, is refers to the micro service can handle many requests (translator: scalability refers to the system to cope with the business increase of ability to extend themselves accordingly, sometimes also will be scalability, namely when business shrinking, contraction of the system size accordingly), performance is much better service to be able to handle these tasks (translator: this should be called QoS). A high-performance service should use resources wisely, handle tasks efficiently, and handle requests quickly.

If microservices do not scale as expected, the probability of failure increases dramatically. Delayed growth leads to poor availability.

Fault tolerance and disaster recovery

To ensure usability as the ultimate goal, developers need to ensure that any microservice failure will not cause system downtime. Therefore, developers need to be aware of all failure modes and do backup work in case of failure.

The key to successful DISASTER recovery is robust resilience testing, which includes code testing, load testing, and chaos testing with other proactive tests. Each failure mode should be replicated in the production environment to see if it can “survive.”

Given the complexity and complex dependency chains of a microservice environment, failures are inevitable. Microservices must be able to withstand both internal and external failures.

Monitoring and documentation

“I find that in microservices architecture, the state of the system is never the same as it was the last second,” Fowler-Rigetti said. If you don’t know what the state of the system is, you won’t know when the system fails, which ultimately leads to failure.”

Having a good monitoring tool to show what the system is doing at any given moment is critical. Lack of good monitoring tools is the second most common cause of service disruptions.

Logging is an essential part of monitoring because it will be almost impossible to reproduce bugs. The only way to know what’s going on is to make sure you document the state of the system at that time. The only solution is proper logging. This makes it easy to trust the service.

Documentation is a hindrance to every developer, but it is critical. It removes technical debt and allows new team members to catch up.

Sun Ke – 6 Challenges every organization will face in implementing microservices