From TechStrong.TV: Application Networking and Service Mesh

Watch the 15-Minute Interview

Read the Transcript:

The Need to Move Beyond Service Meshes

Michael Vizard (MV): Hey guys, thanks for the throw. We’re here with Greymatter.io CEO Christopher Holmes and we’re talking about service meshes — actually beyond service meshes — because I know most folks are still figuring out what these things are. Turns out maybe we need more than a service mesh. Anyway, Christopher, welcome. So walk us through this a little bit because I know folks are still wrestling with when to apply as a service mesh versus an API gateway or even proxy software. You guys are talking about the need to move beyond service meshes. So where are we on this proverbial journey?

Chris Holmes (CH): Absolutely. I think it does start with API’s. 100%. And what’s happened over probably 10 years now, it’s become an API-driven world. I think that I saw a stat the other day that 97% of developers are using APIs in some way, shape, or form. And as those APIs have developed over the years, especially inside enterprises, you’ve had to change your infrastructure, you’ve had to add things like Kubernetes, you’ve had to add things like containers, you’ve been dealing with probably more than one cloud. And now all of a sudden, you’ve got all of these environments.

We met with Gartner a couple weeks ago, and they said something in the order of magnitude that most enterprises at scale have 50-plus Kubernetes clusters, running 1000s of services and they have to control them. They have to manage them.

So at that point, when you’re wrestling, you really are looking at application networking, and you’re trying to figure out how do I manage my API gateways? How do I manage my ingress controllers? How do I manage my east-west communication, not necessarily north-south, which is out to my external customers? And then the big question and really when it becomes a ticking time bomb, how do I configure it? And how do I secure it? So that’s why we kind of say way more than a service mesh.

MV: We’ve seen the rise of service meshes mainly in Kubernetes environments. But it seems like this whole issue of application networking and connectivity goes well beyond just Kubernetes. We’re dealing with all these legacy monolithic platforms as well. So do we need to think about this as a cross-platform initiative rather than just something that happens between like-minded clusters as it were?

CH: 100%. So when we first started, and we’ve been around since 2015, we saw this happening. We have a lot of customers in the United States intelligence community and the Department of Defense, and they have systems that run, not just in Kubernetes, and containers, and hell, not just in clouds. They’ve got systems that run on racks of servers that sit in the back of Humvees and they have to all be connected. I mean, they still have to all talk to each other because data is important to move from one place to another. It’s not a Kubernetes problem, because it’s sort of entering the world on what it meant to be a service mesh was talking to the service.

But it’s also bad because what happens is it would also be for Kubernetes, and service mesh and things like Resource Services became sort of hijacked and, no, it’s not only going to be used in Kubernetes, when in fact five microservices east-west communication and talking from service A to service B, that happens everywhere: licensing, cloud environments, multilateral agreements. It’s not just the Kubernetes world and we’re going to be connecting multiple service meshes together.

MV: Do I need the service mesh at all if I have your platform?

CH: So, right up front, we use that same underlying technology, a service mesh for certain things, not everything. It is good glue. Is it a product by itself? We don’t believe it is. And, yes, you’re going to have to connect multiple fabrics. So you know, a long time ago, the telcos realized in order for us to continue to go down this path of virtualization. Virtualization doesn’t mean just a virtual machine. It really means virtualizing or controlling. That might happen. It’s the security layer or the communication layer, layer 7, it all needed to be virtualized. Its a control plane. It’s a bunch of data planes. That control plane sends policy to those data planes. Those data planes need to be resilient. Enough to stand on their own. So if they’re not receiving any policy, they can still operate without and that’s at its core, what a service mesh is. And that is the foundation.

Moving from NetOps and DevOps Toward Platform Engineering

MV: Is it somebody’s job to install and manage all of this stuff? Because, I mean, we have traditional networking people and then we have DevOps teams, and we have developers, but it’s not clear to me that we have application networking specialists that do anything.

CH: Very good question. So, we just got back from KubeCon. And one of the things we were hearing about this new thing called platform engineering teams, and we’re seeing this manifestation of platform engineering teams, at least in large-scale enterprises and that team usually consists of a line manager job that he’s got to handle, he’s got to make sure that all of his 50-plus Kubernetes clusters are secured or meeting enterprise governance requirements, are auditing the right things, and connecting to other legacy-type of infrastructure, and they usually come up to engineers, they usually consist of some CISOs or security engineers, which is pretty new, and usually a subject matter expert from a CTO kind of organization.

It is also a ton of DevOps and when we first started — I mean, we’re a company full of DevOps engineers. They have had to learn things that were network-centric, and also application-centric. And that’s the most interesting thing about DevOps engineering in the first place. It was always sort of an in between kind of thing. You’ve got the core person who’s writing their code in whatever language they want, and then you’ve got the network guy. And when something goes bad, usually they point the finger at each other. “It’s not my problem. It’s the network.” “No, it’s not my problem, it’s the guy who wrote the code.” And in fact, there’s this little glue for peripheral things, like Apache proxy, things like NGINX. These are application networking pieces of configuration. What we’re doing is about making that a real layer in the application that is decoupled, so that it’s not tethered to your application or network, but allows you to do things that are somewhat network-centric, but also allows you to control the application at scale.

One use case that we just recently had was there was a compromise. And we were managing roughly 400 services. And it was a segmentation error. It was on a segmented application area, a couple of apps using those for services. They weren’t sure where the compromise was, but there was some sensitive data. So in our application stack, you were able to actually just go into a few edge nodes. I think it was roughly 10 and we were able to create and access RBAC rules immediately. The control plane then sent to all the data planes, lock this stuff out, so that the cyber team had time to actually figure out where the issue was.

That’s not traditionally easy without a layer like this that usually consists of somebody trying to figure out which North-South routers, you’re actually trying to circumvent, or it’s the application owners and application owners are not knowing the network, and going in and shutting down access to their services. Their answer is just shut all that down or remove the app from production.

Neither one of those are great. It’s much easier to add one line of configuration to create an “Access Denied” role. Give the cyber team 10 minutes to find the problem and then open up those services for continuity of operations, keeping the services that were compromised offline.

MV: Are we about to see the convergence of NetOps and DevOps, because, you know, we’ve been doing infrastructure-as-code forever today, but the networking team — to your point — was always somewhat off to the side. And will those networking services just become part of the infrastructure that gives you an edge?

CH: It has to. It has to. I mentioned our customers and our customer base a little while ago. If you think about traditional things like NGINX, you know, at scale and a large enterprise, you probably have 1000s of NGINX proxies. They all have configuration. It’s not like you’re just installing NGINX proxy and worse — they all have configuration. Think about where we store that configuration today. We know best case scenario at scale. You know, you’ve got a network engineer who’s brilliant with a bunch of proxies like this has everything working through the network, traditional Layer 1, Layer 2 routers and things like that.

But then that network engineer goes and finds another job and he leaves. Well, the best case scenario is you might have some documentation and some SharePoint work that you’re hoping is accurate. And the worst case scenario — we’ve seen this more than enough times. You’re sitting there when something is wrong, and you’re grepping NGINX logs, you’re looking at configuration on production, and then you’re tweaking on production. And that’s the worst case scenario. When you make a change to production, there’s no CM, and you just lose complete track of it. You might fix the problem very immediately because that’s what they’re there for traditional NetOps — got latency or I’ve got a problem or I’ve got to get this thing going: “fix it and fix it now because it’s a problem.” Without any kind of configuration management, that’s bad.

So I do think that NetOps and DevOps and application networking are all coming together. That’s a big part of what application networking is doing is introducing GitOps processes, OCI-type processes into the network stack itself. It’s focused on the application networking, but I do think it’s going to be adapted very, very quickly by Layer 1/Layer 2 vendors like Palo Alto and Cisco.

MV: We talk a lot about the southbound impact of all of this but looking north-bound, do you think we’re going to be presenting developers soon with this higher level abstractions?

CH: We’re invoking these services and they don’t have to play around with all these low-level API’s that require them to become distributed computing experts. It’ll just be built into the platform. That’s our goal. That’s our main reason for being, which I mentioned, we’ve been around since 2014. Service mesh in general, and the concept of service mesh, and even more broadly, application networking now, because people get what it is, and you’ve been asking some great questions about, I got to think more broadly outside Kubernetes that touches more people.

And developers don’t know that kind of universe. Developers want to write an app or an API and they want to bang out their code. They shouldn’t have to deal with things like traffic shadowing, they shouldn’t have to deal with how they add RBAC policies. On my routes, so that I’m blocking traffic here, but I’m letting traffic there. They shouldn’t be dealing with traffic control at all, on their network policy. And quite frankly, we believe they shouldn’t have to deal with auditing logic, they should be able to glean that from this layer. They should just have to write their apps. It should be damn simple. And it should flow right into the same processes.

And going back to the questions that we just talked about, that’s why NetOps should adopt GitOps because developers are using GitOps and all of those processes where code is managed, the more you manage your infrastructure, the more of those layers can be created, the more tenants can be supported and the more segmentation can happen. So it literally has to happen now. Otherwise, we’re going to continue to have cyberattacks and security issues and data breaches.

How to Get Started with Application Networking

MV: I think that’s why there’s a big thrust around this stuff. Well, there’s an old IT saying, “What’s the one thing an IT admin and developer can agree on? The answer is ‘it’s the network guys fault.’” So what is your best advice to folks about how to get started with application networking?

CH: Well, you certainly can come to our website. And you can certainly reach out to us, but there’s an awful lot of articles on this stuff in the cloud-native space. Our competitors, they write good stuff. We all write good stuff. Follow Gartner. Gartner is actually really starting to talk about application networking and what it means and the importance of it as well as Forrester and GigaOm.

MV: Alright, folks, you heard it here. Application networking is the next big thing. Back to you guys in the studio.