Microservices Are Great, But Only if You Solve These Challenges

By now, you’ve heard of microservices. Can microservices really benefit your organization? That depends on what your organization looks like and which approach you take to implementing them.

Put simply, the term microservices refers to a software architecture in which applications run as a set of multiple independent services. Each microservice provides a small and specific type of functionality. By putting microservices together, you get a fully functional application.

If you worked with the Service Oriented Architecture (SOA) model when it was popular in the 2000s, then you’re already familiar with the fundamental concepts behind microservices. They are like SOA, except a microservices architecture typically involves more numerous and smaller services. The APIs that connect microservices tend to be more complex, too.

Opportunities and Challenges

In theory, microservices make applications more efficient, easier to update (especially when a microservices application is deployed using containers) and more secure. However, leveraging these benefits requires more than just refactoring an application into a microservices architecture. While microservices create new opportunities, they also impose additional challenges that organizations need to address in order to take full advantage of the microservices model.

Common challenges include the following:

IT Skill Sets

Not every IT department is prepared to create and manage microservices applications effectively. As JP Morgenthal, CTO for application services at DXC Technology, explained in an SDxE talk, “The barriers for adopting microservices as an organizational program are often tied to how IT is organized as well as the limited resources for skilled architects in this area.”

Martin Fowler, a DevOps thought leader, makes a similar point, writing that if you use microservices, “You need a mature operations team to manage lots of services, which are being redeployed regularly.”

What Morgan and Fowler mean is this: To get the most out of microservices, your team needs to be prepared for them, and not all teams are.

Examples of specific IT skill sets for leveraging microservices include the ability to manage software written in multiple languages, since microservices sometimes entail different languages within the same application. The team should also be familiar with modern APIs and best practices for managing interservice communication. Understanding of next-generation technology for connecting microservices, such as service meshes, also is a useful resource.

Without the proper skill sets in place, microservices will prove more trouble than they are worth.

There is no shame, by the way, in avoiding microservices because of skills limitations. If you choose not to take on microservices because you lack the requisite in-house expertise, it’s a sign that you make smart IT decisions, not that your IT team is failing.

Standardization

In order to help manage all of the moving pieces in a microservices architecture, you need standardized APIs and governance policies for the microservices applications that are shared across the organization. Such standardization can be difficult to achieve, especially if you have multiple teams and units within the organization.

To make matters more complicated, microservices standards need to be balanced with flexibility and team independence. As developer Vinay Sahni writes, “Give teams the freedom to do what’s right for their services, but have a set of standardized building blocks to keep things sane in the long run.”

Standardized policies for designing and managing microservices architectures can be implemented, but standardization won’t happen on its own. You need to approach them with a standardization plan in place from the start.

Monitoring

Microservices mean that your application is broken down into many small pieces. By extension, there is more to monitor. When something goes wrong, the root of the problem might not lie with the service or feature that fails, but a dependency. For this reason, identifying and fixing problems quickly in this type of architecture is especially challenging.

What this means in practical terms is that traditional monitoring tools don’t always work well for microservices. You might need to look beyond open-source platforms like Nagios in order to keep proper tabs on your microservices applications.

Aligning with Business Contexts

When developing a microservices application, the focus should be on solving business problems, not just implementing microservices for microservices’ sake. That can be hard because defining business goals is not always a straightforward affair.

“There are many ways to view a business, such as customer, operational, executive, etc.,” Morgenthal said in his SDxE talk. “If you’re using this a means of organizing your microservices, then you will arrive at very different architectures.”

The solution to this challenge is to identify which business needs you most want to solve, then prioritize building microservices that address them.

For example, if your biggest business problem is slow delivery of new application features to customers, then leverage microservices to speed application development and delivery. If the greatest issue is application performance and reliability, focus on using microservices to make your applications more scalable and fault-tolerant.