The benefits of microservices are undeniable. Software development companies want to be able to deliver software rapidly, frequently and reliably — and microservices are a means to that end. A recent O’Reilly Media report found that more than 50 percent of software projects are currently using microservices. Of those surveyed, 86 percent have found at least partial success with microservices while only 15 percent have seen massive success.

The problem is that, like with any new trend, businesses tend to jump on the bandwagon too quickly, according to Michael Hamrah, chief architect at the HR software company Namely. “You think just by having it that you unlock the value proposition, but like anything there is a learning experience,” he said.

RELATED CONTENT:
Securing Microservices: The API gateways, authentication and authorization
Microservices anti-patterns
Microservices gone wrong

A common mistake Hamrah sees happening when businesses move to microservices without a clear understanding or intent is they end up with what some know as Frankenstein microservices, microliths or monoservices, where you end up with an inability to manage services, set service boundaries or provide good reliability.

“Organizations need to assess if microservices are a right fit for them and adapt their organizational structure and culture before embarking on a microservices adventure,” said Carlos Sanchez, principal software engineer at continuous delivery software provider CloudBees. “Microservice architectures can start with good intentions, but can go wrong and end up with Frankenstein microservices or distributed monoliths that manage to get the worst of microservices and monoliths: slow development velocity, more defects and increased complexity.”

However, since microservices are a completely different way of working and there is no framework out there to tell you want to do, it can be hard to tell whether or not you are on the right path before it is too late, Hamrah explained. You need to ask yourself, are you releasing to production and continuing to release to production? “If you are doing that and you are feeling really good about your ability to develop features and work on features then that is the most important thing no matter how you are doing it,” he said. If you are struggling to manage infrastructure you probably need to rethink your architecture.

Hamrah provides four considerations to keep in mind when creating a microservice:

  1. Think about what the boundaries are and the APIs. Hamrah explained a service “must be the definitive source of truth for data and functionality it is intended to cover.”
  2. Microservices must promote loose coupling so operations are simplified and services can evolve independently of another.
  3. Microservices should create opportunities and add value. “You should really be thinking about what new service can you leverage in various ways. What new data can you provide? What new functionality can you enhance through your product?” he asked. “And then going back to your first two principles are you able to do that independently and just focus on that piece?”
  4. Service must be reliable, so it is important to think about uptime and usage, according to Hamrah. This includes properly monitoring it and having observability into the service.

Another reason companies are having trouble successfully implementing microservices is because they get too caught up in the term microservice itself, according to Chris Richardson, microservices consultant and founder of the transactional microservices startup Eventuate. While a common belief around microservices is that they should be small, single-function services, Richard believes that is a nebulous idea and it is better to create cohesive services with functions that belong together. “The big idea of microservices is functional decomposition to accelerate development,” he explained. “If a team, one of many teams developing an application, is in production with a single service then why split it since more services equals more complexity.”

Richardson explained micro tends to imply that things have to be small when really it is an architectural style that should imply loosely coupled services within an application.

Organizations often have the misconception of the more services the better. “This pushes people down the route of creating or defining too many services,” he said. “I always try to tell people to aim for as few services as possible and only if there is a problem should you start to split and introduce more services.” Your services should implement meaningful chunks of business functionality, he added. Richardson’s characteristics for a microservice are that they are easy to maintain, evolve, test and deploy.

If you find yourself in the trough of disillusionment with microservices, Hamrah said it is important not to get discouraged. “There is initial excitement when people go and and maybe they go in too fast, but you learn from that and hopefully you are constantly learning, iterating and improving,” he said.

When the computer software company Nuance recently went through a microservices transformation, the team found it was hard to get the balance right. “What service should be responsible for what and avoiding creating a new monolith in the process by trying to put too much into one place was really hard,” said Tom Coates, senior principal architect for Nuance. “We had a couple false starts that were way too big and too much like the old system, but we kept refining and breaking it up until we got to a place where we were comfortable.”

Hamrah added, “If you can move forward to solve your immediate problem and you have a very healthy culture of refactoring, improving and iterating — I think you are going to work through these common early mistakes and get to a point where you fully understand and adopt patterns of a healthy microservice ecosystem.”

Managing with the complexity
The  benefits of microservices can overshadow an important fact of moving to this architecture: it’s sometimes more complicated moving to microservices because data is distributed, there are many moving parts, and there is a lot more to manage and monitor, according to Eventuate’s Richardson. It is a big change going from having to manage one codebase to multiple and even hundreds of codebases and services; and sometimes it’s not always the right choice.

“Companies jump too early into microservices. I don’t think there is anything wrong with monoliths. There is nothing wrong with starting out early products or even projects in large organizations in a monolith way,” said Hamrah. “You really want to be focused on where you are spending your effort and if you are spending too much effort in dealing with bugs and not being able to release your code because things are too tightly coupled or not being able make safe factor choices, you probably need to move to microservices.”

If your application is not large or complex and you don’t need to deliver it rapidly, then you are probably better off with a monolith, explained Richardson.

“You shouldn’t do microservices until you need them. You shouldn’t use them for small applications, or in small organizations that don’t have any of the problems that microservices are trying to solve,” said CloudBees’ Sanchez.

If you do decide a microservice architecture is the best fit for your organization and teams, Nuance’s Coates said from experience it is best not to try and go in halfway. “It is an all-or-nothing proposition in my opinion,” he said. “Unless you have a system that already has some clearly defined interfaces then maybe you can try to piecemeal it. Our first attempts were, let’s do a little here and there, and that just doesn’t work. Since it is such a fundamental shift, it’s tough to make it play nicely with other legacy systems. If you are going to migrate from a classic architecture to a microservice architecture, you have to more or less greenfield the entire thing and start from ground zero.”

To do this, you need tooling and processes in place to ease the complexity, such as service meshes or  server monitoring and distributed tracing tools, according to Sanchez. “You need an automated pipeline from development to production, as you can’t manually scale the monolith architecture processes to dozens or hundreds of microservices. You also need to take advantage of DevOps and progressive delivery methodologies, like blue-green or canary,” Sanchez added.

Additionally, APM-based tools will help teams get the right observability capabilities in place, according to Namely’s Hamrah. Some tools Hamrah recommended include the open-source framework gRPC for defining services and Istio for monitoring traffic. But when it comes to picking tools and addressing challenges, Hamrah explained teams should be aware of whether they are actually struggling with managing their infrastructure of struggling with a particular technology they are using to accomplish their goals.

Calvin French-Owen, CTO and co-founder of customer data infrastructure company Segment focuses on three different pieces when it comes to building microservices: 1. Making sure they are easy to build in the first place by providing a service template and scaffolding necessary to get users going. 2. Making sure they are easy to deploy and spin up the infrastructure. 3. Making sure it is easy to monitor and understand what is going on in production.

In order to tell if you are actually on the right path and improving, some key metrics you should be looking at are the time it takes for developers to commit or check in a change until that change is deployed into production, and how frequently you are relaying changes to production, Eventuate’s Richardson explained. “Improvement efforts should be centered around improving those metrics. If you are adopting microservices but not seeing those metrics improve, then something isn’t right,” he said.

Lastly, Nuance’s Coates added having architectural guidelines in place can help teams understand what a service should and shouldn’t do. “Each service has a purpose and should be able to stand on its own, describe what it is for, and how someone might use it. No matter what microservice you are looking at, you know your way around it because it is packaged and laid out similar to other ones.”