The Holy Grail Times Three – Cloud Native Now Podcast EP 3

Hey everybody. Welcome back to the Cloud Native Now podcast. I am Sharon Florentine.

I am here again with Mike Fazar, and we are gonna kick off this week talking about a great conversation that Mike had with Solomon Hikes that is over on Textron tv. I'm gonna ask you, Mike, to sum up that, sum up that conversation and uh, then we can segue it into our conversation. Yeah, well, Solomon and team have been trying to figure out a way to build, um, or at least automate the building of pipelines that we use to construct applications in our CI/CD platforms.

And it's been something people have been trying to do for a while and there's merit to the case, but it was just interesting to listen to him talk about there is no silver bullet for creating a DevOps platform. And even he was saying, there's always gonna be work involved here. I mean, organization's gotta go in there and define these pipelines.

I think what we're saying is Dagger makes it simpler to build those pipelines, but, um, I don't see it as some kind of magic thing. And I'm not even sure, you know, there was a lot of hype because he was involved that people were saying this is gonna be the greatest thing since Docker. Right.

I think it's just another tool in the case that we can pull out as needed. 0 as it were. Right.

com talking about how it was Dagger was gonna be the holy grail of standardizing ci cd pipelines. And uh, obviously, you know, it seems like that has not come to pass based on what, what we know and what we've seen over the last two years. Um, and it, it also seems like a lot of that, like you said, may have been driven just by his well-known celebrity in the, in the industry as, you know, former Docker.

And, uh, so maybe he was playing on playing on that a little bit. But, uh, it, it is still, still interesting to see that, that this is still still an issue. Well, I think we're still looking for the original holy gra, so that tells you something about the probability assessment of that being the holy grail for anything.

Right. Um, I think what he's pointing at is that it's getting more complex to build the pipelines in the age of microservices and containers because the containers come and go and there's a lot more microservices and APIs and a lot more calls being made. So we need a higher level of abstraction, and that's true, but it's only one piece of the puzzle.

So calling something, you know, the magic holy grail, silver bullet, pick your buzzword choice there as you see fit, um, it, it's a disservice to, you know, the people who are building this stuff, they know better, right. You know, they have experience in this space. So I think, you know, we're getting realistic and it's maybe high time where we, uh, even with Docker, I mean, that was supposed to solve all our portability issues, but doesn't really work so well when you move from Linux to Windows.

And, um, there's still a lot of issues with, you know, now we have more container types than ever and we're trying to run these things in different platforms. And so the portability issue goes beyond just, you know, the software artifact itself. So I just think we're getting a little more mature here about our use of hopefully hyperbole, Tone it down.

I don't know. Uh, the hyperbole definitely seems to, uh, seems to appeal to some readers and viewers, so maybe we'll just tone it down. There you go.

Um, Go ahead. I was gonna say, speaking of holy grail, uh, portability, you know, we, we published a piece also this week that, that you wrote reported on and wrote about, uh, DIA Grids Conductor Enterprise, and that is based on dapper, which is a framework for running or deploying microservices on Kubernetes clusters. So I'm gonna let you dive a little deeper into that and explain what that means to the cloud native ecosystem here.

Well, this too, when it first came out was a holy grail. So we had a lot of holy grails there for a while, but I think people are getting used to the notion here, DIA grid is basically saying that they will centrally manage your instances of this platform for essentially, you know, providing a framework for integrating the microservices themselves. So you don't have to constantly do that yourself, but there's winds up being a lot of these in runtime.

So essentially managing those things require somebody who's gonna do the updates and kind of take care of all the operational scut work that a lot of folks prefer not to do. 'cause well, they wanna write code, right? Um, I think, but it's not just set it and forget it again that everybody kind of seems to, to wanna move toward.

Yeah. I don't think there is a set it and forget it. I mean, basically there's a, either set it and do it yourself or get somebody else to manage it kind of thing.

Right. But somebody's gotta do the lift, right. At the end of the day, um, they may have come up with ways to automate it, uh, more, but um, it still needs to be deployed, updated, secured, and all those things don't ever go away just because something has been, um, deemed to be the latest, coolest thing going.

Yeah. Yeah. And it, it seems like, um, you know, adoption has been pretty steady.

Um, they're claiming it's 10,000 developers now using it, and that's, that's not insignificant, but, But if they assume that there are 50 million plus developers, they got a long way to go. Yeah, indeed. Uh, how many of them are running on Kubernetes?

Let's assume that there's 7 million of those. You still got a long way to go. Yeah.

Yep. Right. Well, and I, since we're talking about yet another potential holy grail here, uh, you know, Raffic is, uh, updating its API gateway to add support for was as well as OpenTelemetry and the Kubernetes gateway, API mm-Hmm.

And so if we're talking about Holy Grails, you can't not talk about was and, uh, you know, that that's supposed to solve the, the portability issue, right. So how does this, I think very, Yeah. You know, was, is coming along as something that is more portable that will run on the server side.

I don't think it replaces containers as much as it, um, allows certain classes of applications to become more portable because they code will run about the client and the server side, and it's basically a format. Um, and, you know, we'll have tools that will make that more accessible to folks. In this case, we're talking about, you know, how to, uh, invoke those modules using an API and a and a and accessing them through a gateway that's provided by Traffic Labs.

I'll be honest, this whole space around application networking gives me a freaking headache and You and me both. And, and, and here's the thing about it, it's, so most people, you know, you start out with a handful of APIs and you're kinda like, okay, I'm going to use a proxy. And, um, they'll go get one of those and, you know, some are lighter weight than others, but people have been doing that forever and a today.

Um, then we get into this notion of API gateways, which are kind of like the next level of abstraction up, and they're typically built on some sort of proxy and that becomes a little easier for people to manage. A lot of times they'll either do that in an on-premise environment or they'll be up in the cloud. TRAFIC is trying to make a case for one integrated platform for all of that, but behind that is this, you know, whole service mesh concept, which is also based on proxy software, which is, you know, from my perspective API management at an even higher level of scale.

And it's not clear to me how many APIs I have to have before I need a service mesh versus an API gateway. But, uh, I'm thinking, you know, you gotta be into the hundreds to get a service mesh and we'll see how that goes. And a lot of folks are gonna be like, do I need a service mesh or do I need, you know, three API gateways?

I couldn't tell you the answer, but, um, I, I bet you one thing one's a lot cheaper and a lot easier to deploy even if you have three of 'em. So, um, these are issues that go into people's thinking and decision making. A lot of it comes from where you start too.

Yeah. I think if you've got a platform engineering team and you're, uh, putting together, you know, the end all be all for programmable operations, yeah, service mesh looks great, but who's in charge of that? Is the networking team or is it the DevOps team?

Nobody seems to know on the other end of it. Your average developer looks at all this stuff and says, you know, proxy software and maybe an API gateway, I can wrap my head around and I'm service mesh is a little scary. And some of them find linker D because it's an easier service mesh.

But I think the default option is just to go with the animal, you know, in the zoo. And that seems to be the proxy software. And then, you know, and then I hope to have a scalability problem someday when I need an API gateway and I hope that somebody else's problem.

Right. Right. And then, you know, even if you decide that you need the networking team or developers or someone to manage all this good luck finding them because then you're kind of stuck with whoever's already in your organization that maybe can get a crash course and how to do it.

It seems like, you know, there's, there's always that issue. Even if you decide that someone else should be handling it, if they don't already work there, good luck. I, I mean, in theory, layers one through three should be run by the networking team.

'cause that's the underlay. Yep. Layers four through seven are increasingly becoming what is known as programmable application networking services, but the number of people who know how to manage that is low.

And the number of networking people who are willing to give up control of layers four through seven or even lower. Yeah. So there's kind of this, you know, back and forth and a little tension in the system that has to get worked out before all this application networking stuff becomes, uh, shall we say defacto standard of some type of All that being said, we keep talking about microservices and microservices and modernizing applications and is there really an advantage between, uh, between monoliths and microservices?

This is an ongoing conversation and um, you know, I was talking to the CEO of flagrant about this particular issue, uh, Jim Resnick, um, and his point of view on it was, is that monoliths are better. And his view was, hey, um, they're easier to, for developers to wrap their arms around, there's not as many moving parts and um, it just gets too difficult to manage microservices at scale. Um, there's a lot of folks who started out building some sort of microservices application and rolled back to the monolith approach because they were like, we cannot wrap our heads around all this and we don't have an engineering team the way Netflix does to put on every microservice.

So, um, it becomes, you know, financially and, um, unwieldy, shall we say, to kind of do this at scale. I think a lot of, Was it Amazon that was the, the recent, you know, famous example of, uh, is that who it was that that tried to do microservices for their streaming video and then it turned out to be such a headache that they rolled back? Yeah.

I think that, uh, you know, they tried to imitate the Netflix approach and um, you know, it's challenging and it's hard and I think that's why we don't see as many of these so-called cloud native applications just yet. 'cause we haven't figured out the tooling to make it easy. And most developers are like, where's my web framework that I just used to build a monolith?

And then they are like, I want to go home and I'm done, and I it's five o'clock and I got things to do. Yep. Um, no, I don't think they wanna be on call for this microservices thing that they built 24 7 and they're not, you know, they're like, I didn't sign up to be the guy with the beeper on my belt waiting for a call because somebody doesn't like something at four o'clock in the morning, which is inevitably when that will happen.

Right. Um, so there's this whole notion that, you know, you wrote it, you own it. Well, I'm not seeing the bulk of developers sign up for this program.

I, I think, you know, you can mandate it in certain companies if you started out that way from scratch. But, um, I'm suspicious of even the folks who say that that's what they're doing, because I'm like, well, when do you sleep? And who's gonna own it when you're sleeping?

So there's a lot of little nuances here in this whole microservices thing. I'm not saying we shouldn't do it, but I think we gotta think it through. And sometimes, you know, I half joke a monolith is nothing more than just a big ass micro, and then I got a bunch of little microservices that wrapped around it that calls stuff through APIs.

And that's not a unreasonable approach to you figure out how you can carve more pieces of that monolith off into something that's a manageable set of microservices. But I think we got into a head about, you know, it was gonna be one way or the other. And I got a feeling it's as always with it a little bit of a mix of everything.

Yeah. Yep. I have a feeling that you're right.

I don't know, you know, when we gonna have this adult moment, but I feel like, um, It's coming, I think it's coming very soon. I feel like all of these factors are converging and is eventually they're gonna crash into each other. Yeah.

And I just don't know where the source of this conversation comes from. I mean, is it the vendors who are out there like, you know, tout in a particular platform so therefore this is the new hammer and everything must become a nail that fits that hammer? Or because I'm not hearing the developers saying all this stuff.

I mean, you know, if I go to a conference, I don't see somebody walking down the hallway with a T-shirt that says microservices are bust. Right. Um, So I feel like developers are just trying to figure out what's the best path to write some code and get something done and it, and, and meet a deadline.

And, you know, maybe we've all gotten into this whole argument about this versus that and they kind of probably go home at night and say, I don't know what those guys are talking about. I'm glad to know about this tool versus that tool, but at the end of the day, uh, you know, whichever one gets me home at six o'clock is the winter. Yeah.

Yeah. So, I don't know. Um, you know, we have a cube con coming up, which is in Paris this year.

This is the Cube Con European event, and we're gonna be there doing some video interviews live with folks. So if you're listening to this and you're gonna be in the neighborhood, come on by the booth and say hi. We'd love to chat and get some of your opinions and see what's going on.

Otherwise, uh, Sharon, you got anything else you wanna add? I, I don't. I think that is it for this week folks, and, uh, we look forward to seeing you again next time.

Thanks so much for tuning in and have great rest of your day. Alright, we'll see you guys. Bye.