Dave McAllister, NGINX | OSS North America 2023

This is techstrong tv. Welcome back to the Open Source Summit. We're in Vancouver, it's beautiful and gorgeous, and we're talking about open source proxy software with Dave McAllister from N Engine X.

How you doing, Dave? I'm doing great. Thanks for having me on here and giving me a chance to, uh, talk about my passion of open source.

What is going on in this whole proxy software space? It seemed like for years everybody just kind of downloaded one and they were content, and now all of a sudden I turn around and there's multiple choices and people are arguing about this stuff. Yeah, So the biggest change has been that we've now adopted the philosophy of microservices as an architecture.

And so everybody has now got thousands of little apps making up their big apps for that. And that requires a new approach to this. You can't just do a proxy load balancing, you've also gotta have API gateways in place.

You've gotta manage that traffic in such a way that makes it a very different and more complex. Beastie, when we started with proxy software back in the, you know, the old days, um, EngineX 2002, 2004 timeframe, it was pretty much of, oh, the data came in, the data needs to go out, and now it's, the data came in, where did it go and how do we get it back out? And so now we talk about ingress, so how do we get the data in, how do we get it back out?

But a lot of it is really driven by the microservices architecture and the fact that applications are no longer one, but many. So there is so many pieces to this now. There are the proxy software, the INGRE controller and all this other stuff.

Is it getting too complex to manage? Um, honestly, personal opinions somewhat a little bit. There are solutions that require this complexity, but there are also solutions that should never touch this complexity where very honestly, a simple app server, um, in our case, a open source project called unit just does everything you need to do.

But without that over level of complexity, it's one platform that has the ingress piece, the load balancing piece, the proxy piece all built in. Um, and because of the nature where engine X is open source is near and dear to our heart, and so we made that open source as well. So, but I, I can honestly tell you that I've seen microservice architectures that are in production that somebody should have been shot for, even considering going to the levels of complexity that they've gone to.

We hear a lot about fit for purpose these days, and unfortunately it seems like it is a bit of a, like a fashion industry, right? It's what's ever hot at the moment and people start building stuff regardless if it makes sense. Absolutely.

And you know, unfortunately that's gonna continue. Part of that is the nature of developers. Um, developers like to do the next, next thing over here.

Uh, how many developers have you ever talked to who like to say, oh, I really like fixing bugs, for instance. And so they tend to go to where the new things are? The interesting thing is that we're seeing an acceleration of that.

So if you think about DevOps, DevOps came out the combination between dev development and operations, and it started 2008, the book came out about 2011 for this, and it slowly caught on Kubernetes. 0 was announced in July of 2015, and we went through three years of everybody having their own solution. And now Kubernetes owns the marketplace.

And if you're not talking Kubernetes, you're not part of the conversation. So we're seeing an acceleration. We've seen it now with open telemetry and observability that it was three years, not five years.

And I'm worried about what's happening with the artificial intelligence and large learning models, um, that are coming into being, because that seems to be yet another acceleration point. So are we fragmenting honestly? Yeah, we're probably fragmenting a little bit.

Um, and getting back to some basic roots would really pay dividends for a lot of our developer space. We hear that service meshes are part of the solution, but I don't know, are they or, and where do they fit? Um, yeah, as you pointed out early on, yeah, it depends.

Um, sometimes service meshes make a lot of sense, and I spend and have spent a lot of time in this observability and monitoring space. Service meshes give you that for free. And so you can now automatically see what your application transactions are doing and how they're going through.

But again, unless you've got a lot of moving parts, it's another level of complexity. It's abstracted way. But, um, to, to quote a famous, uh, computer scientist, uh, I know, you know, uh, abstraction makes life easier but not simpler.

And so you can write it, but when you hand it off to the next person, will they understand it? Um, and quite often when we look at service mesh, we look at Kubernetes, we get a lot of people going, oh, this is absolutely brilliant code until somebody else has to touch it. Mm-hmm.

As I think about all this stuff, historically we had the network underlay, and then there was some software defined bits above that that people were trying to manage. Um, if I look at the current world, we're seeing the rise of application networking, which seems to be a mix of layers four through seven. Yep.

You know, I guess in New England they would use the term Misha. Um, what is the relationship between these things and how do they evolve? Will the network people just manage the underlay now and application networking?

Is the, uh, overlay or what's changing? You know, there's, there's the phrase software is eating in the world. Um, you were seeing that happen with things that were traditionally parts of networking.

They are managing sort of layer four down that still requires a sort of a physical layer infrastructure. Um, you know, discussions earlier about whether you should wire your computer or just live on wireless, um, can be complex. Fortunately for here, we've had pretty decent wireless, but I've been at shows where the wireless was not worthwhile.

So keeping that physical infrastructure in place is one thing. The, the issue from layers four to seven is that we've now started redefining what transmission qualities look like. We now are covering, um, the videocast model.

We're living on videocast right now here. We've also gotta cover new emerging technologies like Quick or Hctp three, which change that software level once again. So we can't hard code it, we can't burn it into ROMs anymore.

We have to be able to adapt to it on the fly when we get into the interplay of the application. It is its own network. And so it needs to be managed by itself.

And that's where there's another level of complexity. The goal is though, is to keep it isolated so that it doesn't impact the larger, larger world picture. And that's why Kubernetes is such a pain to work with in some ways, is how do you talk inside of Kubernetes is one of the nightmares of dealing with Kubernetes.

You're talking to an internal network versus your external network. So follow that example through, let's say I had a pod in one Kubernetes cluster and I wanted it to talk to a pod in another cluster. How does that happen?

You Should use engine X. So, so fortunately there are these things that are called the Kubernetes ingress, um, controllers. And so Kubernetes ingress controller can see something coming in, know where it's coming from, even though the assignment may change, elastic, ephemeral, things are there, things are, are moving around.

Um, but it understands where to talked to and where it came from. And so it can do that clean pass back and forth. And again, if your pod is coming out of one cluster to another cluster, the same direction change happens, you know, the, the controller knows where to talk to and it knows what it's talking to, but it doesn't really care what that pathway looks like except between controller to controller.

Who's managing all this stuff? Is it the developer or is it the networking team? The DevOps team.

Who's in Charge? The, the new phrase these days, because we are in technology, it's platform ops. Okay.

So what used to be sort of the role of just keeping the machines alive or keeping the network alive is now all rolled into a body of knowledge, which is keeping the systems alive. And so platform ops, um, great name for something we've been doing for a long time for this now, combines that capability together. So if you are a major university and all your instructors and research guys are dependent on talking to the cloud, they don't want to talk to three different groups.

They want to talk to one person who's gonna solve their problems, and then they may need to escalate. But honestly, platform offices is handling that problem by combining the Cici bin versus as well as the DevOps side. As part of that, therefore, is network operations becoming part an extension of DevOps for all intents and purposes.

And, and the fact that it didn't from the beginning was a, was a shock. Um, very honestly, when we talk about the role between developers and operations, networking has always been part of that. Um, and one of the biggest headaches was always trying to get that functionality approved and managed.

Back to something you said earlier, software defined networking became a way of managing our way around having to build every single thing, um, bespoke, if you will. I'm not sure I get the problem. I mean, devs net AI ops just rolls off the tongue.

Yeah. You know, and you just sort of crossed a boundary here. When we come to the web, the web is one of our biggest security, um, vectors.

Um, anybody can connect to anything from anywhere. And so you see, see people who are building these applications and building these systems spend a lot now trying to protect that what we did as firewalls, it's not enough anymore. And so we now have web app firewalls where are very specific to the application nature and companies have to spend a lot of money making sure that they're not attack vectors inside of that.

Likewise, open source plays a major role in how we protect ourselves coming into the application space, you know, um, we're, we're deep into that space because once again, we've had to evolve from a pure reverse proxy into that environment. Um, because unfortunately the world requires us to do that. Now, I'm not so sure that traditional networking and security people know how to spell open source.

So are they getting used to this idea or What? Uh, your mileage may vary, um, a lot, uh, across that. Interestingly enough, I've been in doing opensource since before it was called opensource.

So I, I started with Linux oh nine three back in the day. Um, if you are talking to a company that's had software roots, you likely have some indication of what open source is. If you're talking to a company with hardware roots, it's harder to find true open source capabilities and open source knowledge.

Um, what's known as sort of the open source way, how we approach working with people and how people work with each other is somewhat foreign to a hardware concept because they are used to very slow change cycles, open source early and often fix it on the fly. All those different things apply to us. They don't imply if you're, you're building a big iron router someplace.

That's also the advantage though, is because as we build more general purpose on iron routers, we can change the software on them a lot easier rather than burn it into firmware. Is application networking gonna be limited to microservices and cloud native apps, or, it seems to me these things need to talk to monoliths and they need to talk to, uh, serverless frameworks. Or you could argue a monolith is a big microservice, right?

You, you can, you can argue that a, a microservice monolith would exist. Um, I personally use the definition of a microservice as, um, a project that does as little as necessary, not as small as possible, as small as necessary. And so if you have big monolith that's serving your doing what's necessary, treat it as a service.

But you're right, the concept is not limited to microservices because we've been going back into client server models. They were network based as well. They needed to know where to talk to and how to put those pieces together.

And in some ways that's where middleware came into being to be able to, to communicate between those. And so we just simply have made this, again, we've abstracted certain things away. We've made life easier at one point, but not simpler.

And so each step that you do this, you know, otherwise we'd be back running on a deck system 10 with terminals, uh, showing 40 a rows and 80 columns acrossed. Um, actually there's a lot to be said for those days, by the way. I remember PDP 11, not all.

Um, what is your sense of, uh, as we go forward, it feels like to me at least that people are building these application networking stacks on top of Kubernetes without necessarily considering the fact that they need to talk to all these other services. So are we gonna have to kind of go reinvent this whole wheel again? Because we're gonna take a minute and say, hold on a minute, we agree that there's a thing called application networking, it just needs to be pervasive.

Yes. You're, this is, that's actually a, an interesting question. The need for Kubernetes is less than the demand for Kubernetes.

Um, and once you get inside of that cluster and model, it's, you know, as we've discussed, it's hard to talk outside that model. So we need to be able to have an approach that says, you know, hybrid model is the right space. If you, if you look at this from the journey to cloud native that quote all the companies are under, you go from mainframe monolith to this lift and shift approach, put it all on the cloud, and then you start refactoring it and breaking it down.

Honestly, most people don't need to go past refactoring at the most, um, green fields for microservices make perfect sense. Okay, I'm gonna build this thing, I'm just gonna grab all the little services I can find that, stick them together right here. But if you're moving something, you know, if it ain't broke, don't fix it.

If you touch it, you will break it. And by the way, fixing, it's going to be expensive. And so we need to be able to build solutions that provide the best capabilities of both sides.

And that's sort of again, how you get data in and out. We are in a data driven world. Um, so how you get data in and out to the right place at the right time is still the driving fundamental feature.

Your question is actually spot on. We have too many people trying to build the next, next thing without remembering that we have a very long history that we have to provide. What will be the relationship between the application networking folks as represented by you and the traditional networking companies as represented by F five who kind of acquired you guys?

So yeah, how should people think about how that interplay is gonna evolve? So again, you still need that infrastructure. You still need, you know, uh, application backing.

You still need something to run the program on. Mm-hmm. And we still need to run our, our communications across something.

Um, and when we deal with those pieces, the hardware seal plays a major role. What changes inside of that though is that, again, once we've moved over that infrastructure, we need flexibility. We need to be able to have protection capabilities.

And so that's why you're actually seeing most of these traditional networking hardware companies moving towards a more software approach. Um, that's gonna accelerate very honestly. Cool.

What's your best advice to folks then? What should they be thinking about? You Know, honestly, it's, it's, it's twofold.

When you are looking at moving into the cloud, when you're looking at moving into microservices, the first question is to stop and say, why are we doing this? And if you can't come up with a value-based answer, data-driven, value-based answer, then the question, your next question is really, should I be doing this? You know, if you're moving from a mainframe to be able to get off a mainframe, great.

You can certainly do that in cloud. Our original, uh, monolith clouds, were all monoliths as well. If you're doing this for flexibility or speed of market, so forth, identify those pieces that you need to make those changes.

Usually that's actually the user interface. It's not your back end. So that would be my biggest advice is to stop and ask yourself, why am I doing this?

And does it really provide value? All right, folks. I think he said, puppies are cool, but you gotta remember that you gotta own them for a very long time.

So you are making a big commitment here. Thank you for letting me come out and, and espouse my, my opinions. I really appreciate this.

All right, Dave, thanks for coming by. Thanks. All right folks, we'll be back in a minute.

This is Techstrong tv.