Application Networking and Service Mesh – Chris Holmes, Greymatter.io

This is Textron TV. Hey guys. Thanks for the throw.

We're here with gray matter IO CEO Christopher Holmes. We're talking about service meshes are actually Beyond service meshes, because I know most folks are starting that finger what these things are, but there's still a lot of folks who are going. What is that anyway, but turns out maybe we need more than a service Mission.

Anyway, Christopher. Welcome the shop. Nice to be here.

So walk us through this a little bit because I know folks are still wrestling with when to apply say a service mesh versus an API Gateway or even proxy software and yet you guys are talking about the need to move Beyond service meshes. So where are we on this proverbial Journey? Sure.

Absolutely. I think it does start with apis a hundred percent and what's happened over over while I guess the question. Probably 10 years now now it's become an API driven world.

I think that I saw a stat the other day that's that was 97% of developers are using apis in some way shape or form. And as those apis have developed over years, especially inside Enterprises. You've had to change your your infrastructure.

You've had to add things like kubernetes you 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 you've got, you know, we we met with Gartner a couple weeks weeks ago and they said something in the order of magnitudes that most Enterprises at scale have 50 plus kubernetes clusters running thousands of services and and they have to control them they have to manage them. So at that point when you reach that scale you really are looking at application networking and you're trying to figure out how do I manage my API gateways?

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 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 you need more than a service mesh. We have 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 a hundred percent. So when we first started and we've been around since 2015, we 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 not just in containers and hell not just in clouds. They've got systems that run on racks of servers that's 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 is not a kubernetes problem istio was a great thing for us because it sort of trained the world on what it meant to be a service mesh.

You have to have this service talk to this service, but it's also bad because what happened is it was built specifically for kubernetes and service mesh and things like microservices became sort of Hijacked and known for it's only going to be used in kubernetes when in fact apis microservices East-West communication talking from service a to service B that happens everywhere Legacy systems Cloud environments multiple container environments. It's not just a kubernetes world. Am I going to be connecting multiple service meshes together with some sort of overlay between various platforms, or do I need the service mesh at all if I have your platform, and I'm kind of just going to install you guys as the alternative to a service message.

We we embed a service mesh. So right up front we have to use that same underlying technology for certain things. Not not everything because it is good glueware.

It's nice glue air. 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 long time ago when 5G was a thing became a thing the telcos realized this the telcos realized in order for us to continue to go down this path of virtualization virtualization doesn't mean just putting my app in a virtual machine. It really means virtualizing core componentry that my app needs the security layer the communication layer the TCP layer the the layer seven layer it all needed to be virtualized. They use service.

Mesha. It's core as well. It's control plane.

It's a bunch of data planes that control planes sends policy to those data planes those to planes need to be resilient enough to stand on the road. So if they're not receiving any policy, they can still operate without any kind of downtime. That's at its core.

What a service mesh is and that is the foundation for application networking. Is it somebody's job to install and manage all of this stuff? Because I mean yeah, 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 and do we need them?

Very good, very good questions. So we just got back from Cuban. And one of the one of the things we were talking to people about were this this new thing called platform engineering teams, and we're seeing this manifestation of platform engineering teams, at least in large scale Enterprise and that that team usually consists of align manager who's got some job that he's got a hand.

He's got to make sure that all of his 50 plus kubernetes clusters or our secured our our meeting Enterprise governance requirements our auditing the right things and connecting to the high the the other Legacy type of infrastructure and and they usually consist of devops Engineers usually consist of some ciso security engineers. Which is which is pretty new usually a subject matter expert from a CTO kind of organization and and they're they're calling them platform engineering teams. It's it is a lot of devops.

It is a ton of data devops and when we first started, I mean we're full of a company of devops Engineers sres those sres 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 is it was always sort of an in-between kind of thing. You've got the core person who's writing polygot 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 the guy who wrote the code. And in fact, there's this little glue where that's been there forever things like Apache a proxy. Things like nginx.

These are application networking pieces configuration and and really application networking in that layer 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 allow you to control the application at scale.

One of the use cases that we just recently had was there was a compromise and we were managing roughly 400. Services, and it was a segmentation. It was in a segmented application area a couple of apps using those 400 Services.

They weren't sure where the compromise was but there was some sensitive data. So in 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 our back rules access deny our back rules immediately that the control plane then sent to all of 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 and without a layer like this that usually consists of somebody trying to figure out which more south routers. You're actually trying to to circumvent or it's the application owners and you know application owners are not known for being Network monks and going in and shutting down access to their services. Their their answer is just shut the whole app down or remove the app from production.

Neither one of those are great. It's much easier to add one line of configuration to say create an access to my role. Give the Cyber team, you know, 10 minutes to kind of find the problem find the problem and then open up only the services.

That we need to open up for continuity of operations keeping the ones that were compromised offline. That was a really use case. We just had do you think therefore that we're about to see the convergence of netops and devops because you know, we've been doing infrastructure as code Forever in a day, 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 gets us code.

It has to it has to I mentioned our customers and our customer base a little while ago at scale. If you think about traditional things like nginx, you know at scale and a large Enterprise. You're probably have thousands of nginx proxies.

They all have configuration. It's not like you just install an engine X proxy and it works and they all have configuration think about. Where we store that configuration today, we don't.

Best case scenario at scale, you know, you've got a network engineer who's who's brilliant? What's up a bunch of proxies like this has everything working through the network traditional layer one layer two routers and things like that, but then that network engineer goes and finds another job and he leaves well the best case scenarios you might have some documentation and some SharePoint portal that you're hoping is accurate and the worst case scenario and we've seen this more than enough times. You're sitting there when something is is wrong and you're gripping nginx.

Logs you're looking at configuration on production and then you're tweaking on production and that's the worst case scenario anything needs to be because when you make a change to production, there's no cm and and you just lose complete track of it. You might have fixed the problem very immediately because that's what they're there for traditional now netops is I 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 media 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 one layer 2 vendors like Palo Alto and Cisco.

We talk a lot about the southbound impact of all of this but looking Northbound. Do you think we're going to be presenting developers soon with this higher level of abstraction. We're invoking these services and they don't have to play around with all these low-level apis that kind of require them to become distributed computing experts.

It'll just be built into the platform. That's our goal. That's that's our main reason for being we've we've I mentioned we've been around since 2015 service mesh and general and the concept of service mesh and even more broadly application networking now because as people get what it is and and you've been asking some great questions about I got to think more broadly outside of 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 do I add our back policies on my routes?

So that I'm blocking traffic here, but I'm letting traffic there. They they shouldn't they shouldn't be dealing with traffic control at all on their or network policy and quite frankly. We believe they shouldn't even have to deal with auditing logic.

They should be able we should be able to glean that from this layer which we are. They should just have to write their apps and 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.

Has to adapt get Ops because developers are using gitops. And all of this all those processes where code is managed the more you manage your infrastructure the more those layers. Can be created the more tenants can be supported and and the more segmentation can happen.

So it literally has to happen now. Otherwise, we're going to continue to have cyber attacks and security issues and breaches data breaches. I think that's why there's a big thrust around this stuff.

Well, there's an old it joke that says, what's the one thing in it? Admin and a developer can agree on The answer is it's the network guys fault. So.

So what is your best advice to folks about how to get started with all this? io and and certainly reach out to us. But there's a there's an awful lot of articles on on this stuff in the cloud native space our competitors, you know, they write they rate good stuff.

We all write good stuff and and follow Gartner Gartner is actually really starting to talk about application networking and what it means and the importance of it for us during Google. All right. Hey Christopher.

Thanks for being on the show and sharing your knowledge and Incense. Thank you enjoyed it. All right, folks you heard it here application networking is the next big thing back to you guys in the studio?