Source: thenewstack.io
Service mesh technologies have emerged as a reliable way to manage observability, security and traffic management in microservices environments, typically with the use of Kubernetes for container orchestration. Specific use cases and needs for service meshes also vary.
The New Stack recently completed a survey about service mesh use cases. While one third of those surveyed said their organizations already use service meshes to control traffic between microservices and Kubernetes environments, adoption rates and use varied significantly among the respondents. Sixteen percent of respondents said that their organization broadly uses service mesh in production environments and 17% said service meshes have limited use in production environments, for example.
In this latest episode of The New Stack Analysts podcast, Lee Calcote, an analyst and founder of service mesh provider Layer5, and Brian “Redbeard” Harrington, a principal product manager for OpenShift service mesh at Red Hat, discussed the many nuances of what the survey numbers really mean.
Calcote notes how traffic management is seen as a key feature among the many different service mesh capabilities, but it’s most useful to advanced users. Speaking about the use of traffic management functionalities, Calcote said: “Folks tend to be a little more advanced as they get into that because they’re at that point they’re actually affecting traffic and then routing requests differently, as opposed to something like just purely observing or getting a ‘read-only’ view in their environment.”
Harrington agreed. “I’m happy that Lee kind of pointed out the specific distinction around traffic control, because among the users who I’m talking to that’s the — pun intended — ‘gateway drug,’” Harrington said. Organizations with legacy bare-metal environments and “pretty expensive hardware incumbencies” face challenges as they move “move to dynamic environments” and as they “de-prioritize” some legacy hardware, traffic management capabilities service meshes can provide help when making the shift, Harrington said.
The survey results and experience in the field also indicate organizations are still mulling the best use cases for service meshes. When asked whether an organization should adopt or how they should begin to rely on service meshes, it is often “irrespective of whether they’re starting on the simpler…or more sophisticated [possibilities] in that spectrum,” Calcote said. “The advice is generally the same which is you should start and adopt a bit at a time a bit of value at a time and what that value is sort of dependent upon what you’re looking for out of mesh,” Calcote said. “But between you getting comfortable with what you’ve deployed and getting the value out of what you’ve deployed, [organizations should] take the next step from there to hopefully at some point leverage all of the functionality of the mesh.”
Service mesh adoption should also result in ultimately offering business results. “The biggest kind of pet peeve of mine is when I start talking to users, and I always have a very specific and deceptively simple question: When you go and when you deploy a mesh and it has changed your organization, your processes and the way that you develop code for the better, what has it done? How does that outcome make your business better?” Harrington said.”And almost without fail, what I get back as a response is just a list of the bullet points of features from the marketing front page. And, you know, that’s why I asked this specific question because while features are important, but features are only a small piece of software.”
