How Service Meshes Are a Missing Link for Microservices
How Service Meshes Are a Missing Link for Microservices
It is now widely assumed that making the shift to microservices and cloud native environments will only lead to great things — and yet. As the rush to the cloud builds in momentum, many organizations are rudely waking up to more than a few difficulties along the way, such as how Kubernetes and serverless platforms on offer often remain a work in progress.
“We are coming to all those communities and basically pitching them to move, right? We tell them, ‘look, monolithic is very complicated — let’s move to microservices,’ so, they are working very, very hard to move but then they discover that the tooling is not that mature,” Idit Levine, founder and CEO of Solo.io, said. “And actually, there are many gaps in the tooling that they had or used it before and now they’re losing this functionality. For instance, like logging or like debugging microservices is a big problem and so on.”
Levine, whose company offers service mesh solutions, also described how service meshes were designed to “solve exactly this problem,” during a podcast episode of The New Stack Analyst hosted by Alex Williams, founder and editor-in-chief of The New Stack, with Janakiram MSV, a TNS Correspondent and principal of Janakiram & Associates.
One of the first things organizations notice when migrating away from monolithic to microservices environments is how “suddenly you’re losing your observability for all of the applications,” Levine said. “That’s one thing that [service meshes] is really big in solving.”
Then there is security. Making sure that applications and microservices are secure involves different dynamics than monolithic security does in a number of ways. “Are microservices allowed to talk to each other or are they not?” Levine said. “How you do all this policy about who’s allowed to talk to whom and if it’s secure” is a major consideration.
Routing can also pose problems. “It’s about making sure that the pipe is available to all those microservices with all of the connections,” Levine said. “This is one of three problems any organization will have once they try to move to microservices — and that’s exactly why service mesh is needed because it’s solving those problems.”
The early development of service meshes can be traced back to when Google, IBM and other firms created Istio, Levine noted. “And the reason I believed that they did it is because they looked at their Linkerd and they just said, ‘yeah, the idea is very solid but the implementation is not the best.’”
The issue, Levine said, was how the Java code “was very, very heavy and then there was a lot of overhead in the performance and the installation and the overall solution.”
“And they worked a lot to make the best solution that they could,” Levine said. “They already did Go and they created filter and C++ and so on and that’s what Istio is.”
Google and most microservices platforms use Envoy as the proxy, which was created by ride-sharing service and Uber competitor Lyft. “Envoy offers great performance, great way to extend,” Levine said. “So. I’m guessing this is why they chose it. And once they chose it, that become kind of like the [de facto] proxy.”
“So this is kind of like they make the market again kind of like defragment, right? Because now there is a lot of offers and the customers are very confused of which one to use,” Levine said. “And the only thing that’s common between all the new one besides Linkerd, is the fact that all of them is using Envoy. So, in a way, Envoy will become kind of like a commodity proxy.”
In this Edition:
1:45: Levine’s thoughts on service mesh and the current players in the space.
6:00: Is the path right, and is it in the right direction?
13:44: When you think about that overall, is that a multitenancy issue?
19:04: So what does that mean for Solo?
24:55: The management and grouping of different service meshes and bringing them together.
26:54: Discussing serverless projects built on top of Kubernetes.
Feature image via Pixabay.
