4 common microservices problems, and a single way to fix them all

Forrester said in a new report that businesses considering microservices also need to remember a crucial layer of infrastructure that may make the difference between microservice success and failure: A service mesh.

Service meshes are additional layers of infrastructure that exist to standardize how services, micro and otherwise, communicate with each other. In particular, service meshes are notable for their uses of proxies between services to increase security and improve observability.

The whole of the report covers how microservices will drive specialization in the service mesh industry, and those with access to Forrester reports should definitely give it a read. There’s a lot of valuable tips and information in the report, with Forrester’s list of four common microservices problems, and ways in which service meshes can solve them, as a great jumping off point.

4 common microservices problems

“Distributed systems are hard, and microservices are harder,” Forrester said in its report summary. That’s an accurate statement: Microservices are applications broken into their most piecemeal bits and distributed across a network, which surely makes things a bit trickier to manage.

SEE: Microsoft Azure Virtual Desktop: A cheat sheet (free PDF) (TechRepublic)

“As development teams expand their use of microservices, the complexities and problems of highly distributed applications built from microservices also surface,” the report said. Those common problems include the following four issues.

Insecure communication

Take one application, break it into pieces and distribute those pieces across network-connected services and you have a massive increase in attack surface.

Forrester said that each microservice is a potential entry point; in one instance the report said that healthcare technology companies are one example of those affected by microservices. In the case of one such company Forrester researchers spoke with, microservices raised serious concerns over healthcare compliance demands: Can they be met when every single piece of a healthcare platform is a potential attack point?

Routing adds complexity, and fail points

Latency and scaling flexibility is a key point of microservices, and it creates a lot of advantages for those using it. That advantage has a flip side, though: As developers program ways to call a service, they may need specific information, like software version, or they need to decide whether to look up a service instance or hand that responsibility to a load balancer.

Over time, all that complexity just gets in the way of performance, leaving companies like JPMorgan Chase’s WePay platform, Forrester said, stuck having to decide between a new method of connection management, or to remain with REST APIs that were part of the cause of its traffic jam.

Errors aren’t easy to handle

Communication failure between microservices is almost an inevitability as companies scale them to previously impossible levels. Developers are hamstrung in such situations, with Forrester saying that devs “must know how to handle scenarios when a call to a microservice fails.”

One solution, hardwiring frameworks into an application, can get around the issue, but it sort of eliminates the advantage of the whole microservices concept. That, and it makes way more work for developers.

Runtime errors are hard to find

“It’s not enough to know the status of individual microservices; operations staff need monitoring tools to show the sequence chains of microservices calling one after another — and then identify specifically which link in the chain is down or running slowly,” the report said.

Trying to track microservices traffic is like trying to follow a single piece of paper on the floor of the New York Stock Exchange: It’s gonna take way more work than it should, and in the end you probably could have found the same info in an easier manner.

How a service mesh tackles four common microservices problems

Microservices are fantastic when they work. As far as this Forrester report is concerned, they won’t work well for developers and operations until a service mesh is added as an underlayer. Such a mesh won’t solve every microservices challenge, Forrester said, but it does come with “benefits like less coding, consistent security, and better runtime insight,” all of which become increasingly essential the further a business invests into microservices, the report said.

Service meshes and security

Service meshes use proxies on both sides of a communication and apply policies that foster better security, Forrester said. In addition, “by not depending on developers to correctly program security into each service, a service mesh fosters consistent service-to-service security,” the report said.

In essence, all service-to-service communication flowing through a mesh is protected and secured at a central level, eliminating many of the new attack surfaces that appear with the implementation of microservices.

Service meshes and communication failures

As is the case with security, microservices typically have their calls programmed right into them. This means that, in the case of failures, the best you can hope for is an error that does little to address the issue.

With a mesh, on the other hand, “developers can assume that if a call to a service fails, the proxy has done its best to handle communications errors. Additionally, the mesh may provide features for service health checks and the ability to route to the service instance with the lowest latency,” Forrester said in the report.

SEE: Checklist: How to manage your backups (TechRepublic Premium)

This addresses two of the problems that Forrester hit on above, routing complexity and failure handling. The mesh itself had proxy-enforced retry policies that Forrester describes as “completely insulat[ing] developers from scenarios where the called service is transiently unavailable.” Failing that, the service mesh would automatically attempt to find a different path or alternate service to avoid throwing an error, something much harder to do when everything is hard coded in lieu of a service mesh.

Service messages and analytics

As mentioned above, trying to find a single datapath through a network of microservices is more likely to lead to madness than a solution. The proxy built into a service mesh, on the other hand, logs every single bit of communication between microservices.

“From these logs, downstream monitoring tools can analyze and report on microservice performance and availability, and they can provide a basic level of tracing across call chains,” the report said.

Shape your mesh to your services, not your services to your mesh

Service meshes, Forrester said, introduce their own type of complexity that can quickly overwhelm a team trying to implement one, particularly if they aren’t prepared for it.

Forrester said that the biggest hurdle to building an effective service mesh is how to conceive of it from the beginning. In this case, a strong understanding of how a service mesh removes complexity for developers is key.

There’s a lot more that goes into building a good mesh, and it’s covered in Forrester’s report (paywalled), which is a must-read for those looking to get into, or expand, their use of microservices.