The beginning of October marks the start of Halloween season, but one thing you don’t want to frighten or scare your users with is your application. There are many benefits to moving  your monolithic applications to microservices, but it can be easier said than done. Inability to manage services, set good service boundaries and provide reliability end up looking what some in the industry call Frankenstein’s microservices.

Frankenstein started out with good intentions trying to understand how the human body worked, but what he ended up with was a skewed and warped version of what he intended and that had  horrible cascading effects, according to Michael Hamrah, chief architect at Namely, an HR software provider.

Hamrah spoke at this week’s O’Reilly Velocity conference in New York City to discuss how to avoid the monster of Frankenstein’s microservices. According to Hamrah, companies fall victim to the same problems when they embark on microservices, and what they end up with is a very manual and painful process.

Segment, a customer data infrastructure company, recently wrote a blog post called: Goodbye Microservices: From 100s of problem children to 1 superstar.  “In early 2017 we reached a tipping point with a core piece of Segment’s product. It seemed as if we were falling from the microservices tree, hitting every branch on the way down. Instead of enabling us to move faster, the small team found themselves mired in exploding complexity. Essential benefits of this architecture became burdens. As our velocity plummeted, our defect rate exploded,” the company wrote.

To avoid this, Hamrah offers some key advice:

  • Make DevEx great
  • Ownership is a feature
  • Observability is a feature
  • Deployments are a future
  • Traffic management is a feature
  • Standards are important, but not absolute

According to Hamrah, the way microservices should run is like “water.” He gave an example of how Uber thinks, which is “transportation as reliable as running water.” What he means by that is in the first world, we take water for granted. We use it to wash dishes, shower, and drink, among other things. However, we forget there is still a tremendous amount of infrastructure and complexity that goes into it. There are laws, sanitation systems, plumbers, and engineers involved.

“This is a microservice system,” Hamrah said. “Specific people doing specific things working together towards a common goal.”

A service should own data and functions, prevent coupling, create opportunity, and have a service level objective, according to Hamrah.

If your business can’t identify what team owns a service, then they won’t be prepared when something goes wrong. Hamrah explained businesses need to think about teams and how they allocate teams and tools to run and manage services. The next step is picking a serialization and transport solution for how services can talk to each other. Hamrah recommends gRPC, an open-source RPC framework for defining services. Then, businesses will want to think about how they deploy. “Most outages occur from a bad deploy,” said Hamrah. Business should have clear visibility into what is running in each environment and a central place to manage change. In addition, they should never coordinate deployment, because that is a form of tight coupling.

Another element businesses need to look into is service discovery and traffic management. How do you want to handle and direct traffic if something goes wrong. Then, think about observability. You don’t want a dashboard for each microservice because there could be dozens or hundreds, Hamrah explained. The right tool can help pull out the right metrics.

A key point is to remember things are always going to fail, Hamrah explained. To prepare, he suggested looking into chaos engineering, an approach that breaks systems on purpose to find vulnerabilities and address them before they happen.

Lastly, Hamrah said to be open to new opportunities. For instance, Namely has three levels when it comes to introducing technology to their workflow. First, it has preferred services that it recommends its teams use. But, the company doesn’t want to prevent opportunity, so the next level is supported technology where it will support certain tools to an extent. The last level is experimental technology. This is where someone can try something new and make the case for it. Namely will then take it into consideration and if the company feels like it is missing from its ecosystem and it improves the overall ecosystem, it will move it to supported or preferred technology levels.

“Standards are important, but not absolute. Unlock value and increase overall velocity,” he said. “Push code out to production. Do it safely.”