Well, this week we have Rita back as a co-host. She had a great idea, as you'll see, to talk to Ben Hale, who's been working on the Tanzu application platform with many other people and has a long history in Spring. Now, what we wanted to talk about here is how the thinking, the influence, the way that Spring behaves, and kind of how it helps developers, how we're applying that in the Tanzu application platform to make using Kubernetes and doing cloud-native development better and easier, not only for developers, but also for the enterprise architects, the operations people in those large organizations, how it really applies a lot of those learnings to Spring to make Kubernetes the great enterprise platform it can be for people running applications. So we'll start in here with Ben introducing himself, giving a great history. He's got a great background for this job, and I hope you enjoy the show. And as always, if you want to subscribe, see archives, feed long and little videos, other podcasts, just go to tanzutalk.com and you can find all the podcasts and videos that we do. So let's listen in and meet our new friend here, Ben. So my name is Ben Hale. For about the first 15 years of my career, I was a core committer on the Spring Framework and various projects came along with that. Gave me a lot of background, a lot of really good experience with enterprise Java developers experience, especially. And about seven years ago, I also took on an additional job to lead the Java experience inside of Cloud Foundry to make sure that as we built the platform, Java developers and Spring developers specifically would love to go there. I often joke my first job was to make Cloud Foundry the best cloud to run Spring on. But after a couple of years, I changed that job title to make it the best place to run Spring, period. And I think we actually did a really, really good job towards that end. But for the last year, I've been a technical lead for the Tonsu application platform, which is our attempt to bring sort of Kubernetes to regular mainstream enterprise software developers. My
2:04purview is much larger than Spring. I care about all of the major programming languages at this point, but to take a lot of the lessons that we took from all of our deep experience with enterprise Java developers with Foundry customers and make sure that they can get those same really positive outcomes, but on Kubernetes instead. Yeah. So this is why I was excited to have Ben join Coté. During my discussions with Ben, when we were talking about Tonsu application platform and the influence that Spring has had on how we built this thing, he started telling me about this notion of an app-aware platform, and that really got my attention. I haven't heard that term. And so I want to start with, you know, I definitely want to get into what did we learn from Spring that is making up how we think about Tonsu app platform and actually just the future of application platforms in general. But before that, I wanted to get into what does app-aware platform mean? How would we define that? You know, is it, is it a very strict definition or is there room for interpretation there? So with that, you know, tell, tell us a little bit about what you mean by that Ben and where, where that came from, like how Spring kind of created that notion. Yeah, that's a, that's a really good question. So just to, to head things off at the top, uh, app-aware platform, I don't think it means anything particularly strict. Um, it's like saying the word microservice. It means what you need it to mean at any given time, but broadly, when we think about an application-aware platform, it's us saying that we want to take a lot of the lessons we turn, we learned from Spring and specifically the core idea of inversion of control. Right. And basically say it's, it's really critical if you want to have sort of portability and maintainability and observability and sustainability, but the applications that run on a given platform are to the extent possible, completely unaware of the platform that they run on. They need to be handed all of the information. They need all the configuration they need.
4:04They need to be hooked into the proper logging systems, observability systems, but without requiring them to be aware that it's happening to them. So when we talk about an app-aware platform, it's effectively us saying, you should be able to bring anything to us, bring me a Python workload, bring me a Node.js workload, bring me a Spring workload. And if, and my platform should be able to say, hey, I know your Spring. I see that you're using actuators. Let me make sure that your liveness and readiness probes are configured properly. Let me make sure that, um, we've hooked you into whatever your observability solution is, that we're collecting your logs completely, that we're pulling from your centralized configuration system, and injecting that into the container on your behalf and on and on and on. We have, you know, a whole list of things that go along with that. And like it, that seems like, well, okay, you could have done many of those same things just by putting something into a Docker file or something like that. But what we observed way back in the day with Spring is like, if you tried to bake those things in, we saw it, especially like I'm going to really date myself, all the way back in EJVs. If your platform knew that you needed to hook up to JNDI or something like that to get some sort of database, rather than having the database injected into it, you ended up with these really brittle solutions. They would only run exactly where they were at force, you know, um, weird things where people were trying to run web sphere or something like that initially locally on their development machines. Um, eventually it, you know, got to the point where we were trying to, you know, sort of at development time run against Tomcat, but at production time, uh, run against, uh, web logic, things like that. And what we observed in the spring community is the best way to make that work better is allow you to focus on your business logic, right? Focus on your pojos doing the things and say, Hey, I just need any database, right? I need a data source injected that, that key thing, that idea that we invert control and say, you give us all of your functionality, we'll assemble it for you, give you all the pieces that you need, ended up with significantly better, you know, sort of outcome velocity,
6:06all the things that you actually care about as an enterprise developer. Yeah. You know, you know, you're making me think that like, uh, you know, I, I'm, I'm always like, not always, but when I am, so to speak, like thinking in my head, like, is, is, is something like Kubernetes really like for developers? And I mean, that's a, that's, that's a pose as a very binary question, but, um, you know, as, as you're kind of going through the history of spring stuff, right? Like, and I think about like the, the, you know, the great thing about something like a Kubernetes is it's, it is really like, uh, a great boiled down specification of like, this is the computer stuff you're going to need, right? Like, like if you're running software, there's really only ever like five or six computer things you need. Right. And like, however, if you were to go out on the internet, you would find like 5,000. Right. So let's just standardize on these things. And then you can, you can get the infrastructure you need, but kind of, you know, to, to the point of what you're saying, it doesn't necessarily, there's yet to be that layer of like, so if a developer goes there, a developer, like, you know, they kind of don't need computer stuff. They need databases and they need like, you know, all of these other things that are not, that are more, that are harder to like boil down into like however many atomic units there are in Kubernetes. So that layer, that layer becomes, there's a different audience that you're serving more or less. Yeah, absolutely. Like, this is what we see is it's all about abstraction and progressive complexity. If I want to draw an analog to like where Kubernetes is today, like if you deal with kubectl and the straight API, broadly, you are dealing with the lowest possible level of a thing. It requires you to have understanding of all of the core types, all of the types that you might have installed, like all the CRDs and stuff like that. And to me, like there's a really strong parallel to using something like the bean factory inside of spring, or maybe the application context where you have the ability to be as detailed as you possibly ever want. But most of the time you
8:09actually don't want that, right? The flexibility is there if you need it, but you actually want to be working at a higher level because fundamentally like your job is to deliver this new feature for your insurance company or deliver this new way of, you know, doing car loan approvals for your car company or something like that. You want to work at these higher levels of abstraction. We introduced the application context, you know, being, sorry, Java based configuration, like we were moving up, right? Moving beyond what spring was. And then I think the big step change was the introduction of spring boot. And spring boot was customer saying, I really don't care even about spring anymore. Like, I want to move to this. I want to get convention over configuration. I want to focus even more on this stuff. That is my business logic. And so a lot of what the Tanzu application platform is, is us doing that same step up. We're building the platform on the platform. We want you to be able to say, here is my app, run it for me in the cloud. I don't care how that's the old CF, I do certainly, but it still applies here. We want developers to be able to do that. But we're also pretty clear that like, not everybody's going to be able to, to, to build an application that fits into that box, right? You can use all of the things that we're going to ship. So it's important that Kubernetes is still there. Like it's an incredible ecosystem. It's super flexible. There are thousands of different projects you or your enterprise might want to integrate with, but most of the time you shouldn't be smacked in the face with a wall of YAML. You should have something small that gets you into the system. And when it doesn't fit anymore, you should be able to drop into the full power of Kubernetes as a developer, as an operator, as an enterprise, it doesn't matter. You should have access to it, but not be required to deal with it every day. I said at the beginning that when we started building Tanzu application platform, it's, it's, it's heavily influenced by Spring, which I think is very, is great because this is a platform for developers and Spring knows developers, the Spring team. You guys really know how developers
10:09want to work. And so you took a lot of that in what we're building here. Can you kind of go over maybe like the top three or so principles that you took from Spring in, in building out this platform and how you think that's going to kind of, I guess, play out over the next few years and the future of platforms in general. And I'm asking you to be a little, you know, futuristic here. Yeah. So I think the biggest one is that inversion of control change, like number one, top of the list. We want to say that you shouldn't as a developer be responsible for imperatively defining exactly the way your Docker image is built with a Docker file. You shouldn't be responsible for imperatively saying every single piece of Kubernetes configuration that needs to happen to that image in order to get it running. Instead, we want to invert that and say something like, here is a Java, here is some Java source code. What does it mean to put it into an image, right? Allow something like the cloud native build packs project to take a look at it and say, hey, I recognize that you're a Python app or I recognize that you're Node.js app, or I recognize that you're a Spring app. Not only am I going to make sure that you get a really good safe image, right? Like, don't run as root, make sure the minimum possible operating system behind it, but also to say, hey, I notice you're probably going to need to bind to some data services. Let me make sure all the stuff in there so that you can bind to data services. Let me make sure that if we see a new version of the JVM come out, we can do a quick rebuild without needing to rebuild your entire application, make sure that you can get that. But then it goes beyond that. We can also say, hey, if I know certain things about your application, I can configure even the resources for Kubernetes. I can set up liveness and readiness codes. I can read your software bill of materials and build pack, put on your thing, make sure that we're configuring other things like your observability to hook in the right place, make sure we're injecting the proper side cards, if that's what it is, or setting some sort of configuration to hide the management URLs off of your HTTP endpoints. And it goes on and on. So the
12:10developer is really focusing on this and the platform is reacting to what it's being presented with. That's number one. Okay. Number two, I think, is the idea of dependency injection, which you might think is what inversion of control is, but it's not really. It's us saying, as a developer, I want to say, you know, sort of in spring terms, it would say, I need to be injected with a bean of this particular kind. But what we actually want developers when they get to the platform to say is, I actually need a data service of a particular kind. So for example, we'll say, hey, I need a Postgres. You can point to a specific Postgres, but we learned, right? Trying to do dependency injection by name is really brittle. Probably what you want to do is describe a characteristic. I need a Postgres database, or I need a RabbitMQQ. Maybe say some stuff like I need it to, you know, handle 1000 transactions per second or something like that, or have, you know, 10,000 IOPS. Be able to describe the characteristics and the platform is responsible for saying, okay, given all of the service instances, all the databases that I have that are on this particular cluster here, what might you want? How can I inject that into your thing? Or centralized configuration feels the same way. Hey, my application needs to go back to a Git repository, back to Vault or something like that. I need it to be injected. But for me, it's just configuration. The platform needs to get that onto the, injected into my container for me on my behalf. Number three, that's a good question. As I look sort of off into the future, I think that we're going to see a lot more of what it means to move supply chains into the platform itself, where we're sort of used to this idea that you've got something like Jenkins that is responsible for sitting off of the cluster and orchestrating a bunch of different things with the source code scanning, or you need to do image scanning, or you need to, you know, run through some sort of audit or something like that. All that runs off. And at the very end, in my previous career, the last step would be CF push this thing onto the platform. Instead, what we want to do is, I think what we're going to see is
14:13all of those things moving on to Kubernetes itself. For what it's, for my money, certainly, I think Kubernetes is the best reconciliation engine that's ever been invented, right? That's really the key, you know, one of the key drivers here is rather than having an imperative thing that says, do step one, do step two, do step three, do step four, and then finally get onto the platform. We have a platform that basically looks at the thing ahead of it and says, hey, if some change has happened, do a thing. So instead of having pipelines, we now have graphs, we can now enter and exit and, you know, in the middle of it rather than the beginning of the end. And more importantly, you all, you have a single cohesive place where all of it, including the final runtime, even if it's on another cluster, you know, we sort of think multi cluster is still part of the same platform. It's all in one location, being reconciled with high availability, you know, all the things that you want out of that kind of thing. I'm going to have so many questions now. Here are the two that I have. One, I wanted to get into how to describe characteristics. If there is, this will demonstrate my lack of developer skills here, developer experience, but what does that mean? Are there ways, like best practices that we think about, like how you should describe those characteristics? But the other one is when you're talking about, um, Kate's, uh, as the, you know, best reconciliation engine and just the notion of a supply chains into the platform. And then that makes me think about, maybe this is a whole other topic for another discussion is the supply chain choreography. Um, and that's something I've talked about with some of our other colleagues, right. And how that's different than, than, uh, orchestration. Uh, and what does that mean? Um, I don't know if that's what you're getting into a little bit here when you're talking here, but that's kind of what sparked, uh, got into my head a little bit. So I don't know which one of these you want to tackle, which one we have time for, which one's going to be, to be continued. Let's, let's, let's start next week. Yeah. Prompt me, prompt me the first question again. Okay. So, um, you talked about how, you know, we're, we're asking folks rather than to be, to say, I want this specific thing to just describe the characteristics of the
16:14thing that you want. Are there best practices of how, uh, folks need to go about that? And, um, why is that, uh, better? Like, does it lead to less brittle, brittleness, as you mentioned? Yeah. So, uh, inside of tons of application platform, we actually split two very distinct roles, which are often occupied by the same person, but have two very different, um, uh, characteristics. One is an application developer. An application developer typically speaks in a high level language, like Java or node, uh, knows exactly what goes on inside of it, understand some characteristics like, Hey, I need a dependency or, Hey, this is a web application or, Hey, I'm using spring or, uh, this requires, you know, two CPUs and a gig of RAM to actually run properly. And we want them to focus really on that, the things that only an application developer can know. And then we split out the other side of it, what we call the application operator and the application operator is responsible for that definition of what exactly those, you know, to do with those characteristics. So we'll talk a little bit about supply chain in a second, but suffice to say, it's a thing that says, Hey, if you're a web app, I want you to perform this set of actions, right? Like I want you to go through and I would, you know, eventually I need to sync it out as a K native, uh, service, right? Something that scales to zero or, you know, automatically scales to a very high number buying databases into it, things like that. But another characteristic might be, this is a job, right? This is part of a batch. And so I want to do things a little bit differently, or maybe, you know, uh, at sometimes, you know, when I first get started, it's simply give me a source and give me a URL at the end of it, but maybe as my enterprise is bigger, I started injecting things like image scanning and software scanning. I put a guard out at the end to make sure that nothing with a C, uh, a known CVE is actually deployed into production, things like that. And so like that split, I think is really important to us to be able to say developers describe, describe a characteristic. A lot of, a lot of the time we're actually looking at implicit characteristics. If you've included spring jars, right? Like we can detect that kind of thing. If you've included spring actuators, we can include that kind of thing. If you include certain,
18:14you know, Python frameworks, we'll do something based on that. But all of these are characteristics that get, um, interpreted by the platform and defined by platform operators or application operators. The, the, the key thing I think here is that we want to do what we kind of did in CF where we said, hey, platform operators can gain leverage on applications. We can take what used to, you know, require a thousand operators to run a thousand apps, and we're going to bring it down. So four operators can, you know, sort of run a platform that a thousand apps run on. We want to do that same thing for applications. We know that in enterprises, especially, but it trickles down to much smaller companies as well. Consistency is a real multiplier for people. We want to be able to say, Hey, uh, all of my spring apps probably need this set of things. So if I determine a characteristic, this is a spring app, do this thing. My Python apps need, you know, probably should all look roughly like this, apply this kind of thing and allows application operators, which in most companies these days are like SRE teams to define what makes it right to run applications in their experience and then gain leverage. Smaller number of SREs, higher number of developers over at the other side. You know, when, when, when I talk with people about like why it's good to have a, uh, uh, a platform in, in your, in your large organization, like I, I, maybe I should start using the word consistency, but I, I say it in the, uh, uh, the bad way, which is that like variability is bad, right? Like you, you want to, you know, you, you want the minimal amount of variability, especially when it comes to things like, you know, stuff that's below your actual application. Right. And the more variability you have in like whatever services you're using, how you can even how you configure and deploy applications, the infrastructure it runs on, on and on and on, like the more problems you're going to have in the medium and long term. And so it seems like, you know, listen, listening to you go over like a lot of this, you know, to, to kind of go between two levels here. Right. So again, like at the Kubernetes
20:17level, uh, I'll use your word for it. There's a lot of consistency, right? Like there's, there's a very limited amount of ways to do things. Right. And it's very thought out how it fits together. And this is what the infrastructure looks like. And, um, we have never, uh, suffered from over consistency in the application development layer. Stop. You're too consistent. Yeah. No, no, no one's ever starved from that, so to speak. Uh, but it, it is, you know, in the same way that like, I think one of the, the things that we've learned from like the, you know, container and Kubernetes world is that if you, to use my phrasing for it, if you limit variability, you get a lot of benefits, right? Like it's actually okay. If there's only like one way to specify network routing, like, you don't, you don't really need a whole bunch of different ways if you have one that's well-designed. And so similarly, like, like, you know, what you're going over is this is let's move that notion up to the developer. I don't know if anyone says middleware anymore, but the middleware layer and say like, so maybe like you need a database, right? Like, or you need an event system and describe the characteristics instead of getting obsessed with the exact thing that you need and then having to configure it. Right. Like, yeah. I mean, it gives you a lot of problems comes in. Yeah. And it gives you a lot of flexibility as well. When you have an app aware platform, it means that you can make different decisions at the appropriate time. So for example, we often think about development as a continuum between personal at one end, production at the other end, some staging and QA somewhere in the middle, and like, and like applications go through from one end of that continuum to the other during their lifetime. But it means like, if I asked for, Hey, I need a, my SQL database, right? Like I need the one that has all of our user accounts in it. When I deploy this in my personal environment, um, call it mini cube on my, my laptop or something like that. Fulfilling that requirement, maybe, Hey, I just deploy a quick
22:21helm chart with ephemeral storage behind the scenes and who cares, right? It's just dead tomorrow, but you know what I'm doing personal development. So it doesn't matter when I go to something like staging or QA, maybe I do actually provision a database. It's a little bit more controlled, probably. Um, but it's not like, you know, any, like it, it probably has some cross controls around it says, Hey, my team is only allowed to do four of these, right? You know, it's only allowed to ask for four of these because otherwise my Azure bill goes absolutely insane. Finally, um, when you get to production, that exact same requirement, I need a MySQL might be just the platform vending a set of, you know, credentials that point to the bare metal DBA care and fed production database that has been around in your company for 10 years, right? Like you can do really great things without the application developer really knowing about it and programming against it, because what they're doing is they're describing characteristics and in different situations, those characteristics can be fulfilled by something else. Yeah. Yeah. Yeah. Yeah. No, it's, it's that same notion that you get that again, down at the infrastructure layer of like how to use developer language, how this is implemented, the infrastructure can vary because you've basically specified what you need. And so we can, we can, we can switch things around depending on production or development and, and, or even just simple as simple as, as, uh, handling more load, right? Like just the way that we do load balancing can change between these different things because you've told us what you need instead of specifying how to achieve what your needs are. Yeah. And like one final point I want to make is like, while I think there's demonstrable value to this kind of consistency, the balance you really have to strike is making sure you don't hide it completely, right? Like there will always be the thing that needs to be the exception. And if you build a system that is so locked down, but that exception can't be made, you really end up in a bad situation. So like one of the things that I think about every day on, on the times of application platform is how do I give developers sort of like their day-to-day
24:21experience as, as productive as possible, as simple as possible, as, uh, um, as consistent as possible while still maintaining the ability for them to make a different decision, to make a small exception without having to throw out the entire platform. Hey, you don't want to use build packs because build packs aren't right for this app. I need a Docker file. What would it take for me to make all of the rest of the platform work, except we, you, you, you can use Conoco to like do on cluster builds with a Docker file and then deploy that. How do I, how do you do that? And like, that's, I think, uh, one of the big value propositions that we're really going after with tons of application platform. Well, I think we're, uh, about ready to wrap up. So I don't know how deeply we can get into this again. I think maybe this will be a stay tuned for next week, but you mentioned supply chains and, uh, which again, sparked this like, Ooh, Ooh, choreography versus orchestration. I don't know if there's anything you want to say about that today, then we can get into it and deeper discussion later. But, um, yeah, that, that, that struck me. So. Yeah. To tease it just a little bit. We internally use the phrase choreography in almost all cases, instead of orchestration. And the semantic difference we observed between that is an orchestrator is like saying, do this thing, do this thing, do this thing, do this thing. And what, the way we think about it, especially since we're built on a declarative reconciliation is it's more of notice a piece of information has changed and move that information to someone who cares about it. Right. Don't do any actual work. Don't force a thing to happen. And so like sort of a concrete example of this is we might notice that, you know, a piece of source code, the version of source code, the latest commit has changed. All we're going to do is shuffle that information over to the front end of, of the cloud made to build packs, KPAC project. If KPAC wants to do a build, they're free to do it, but they don't have to. And the platform doesn't have any strong opinions on this. Each individual project gets to do what it thinks is right to do. And we notice and help people understand and help the data flow around between them. Yeah. You have a platform for building your own opinions.
26:22Absolutely. Uh, we know that customers absolutely love opinions. Uh, and we want to make a nice getting out, uh, getting started out of the box kind of experience with a set of default opinions, but you should be able to change those opinions as your company evolves that you become more sophisticated in your usage and you really understand what makes your company tick. That sounds good. Well, great. Well, well, thanks for being on. I, I think, I think, uh, as always, Rita had a good instinct for a topic that would be fun to talk about. So, so if, if, uh, uh, if people are interested in like, whether, whether it's these ideas or just you yourself, do you, do you have, do you have like a, you got a weblog, a live journal, anything you would point people towards? Where do you put your morning musings? Probably my Twitter account, although it has a lot to do with cycling rather than, uh, software or anything else. Yeah. Uh, but yeah. Yeah. There's actually some really great content also on the Tanzu Dev Center actually. And especially on this last one that we started talking about choreography and orchestration. And, um, we're going to be, uh, talking a little bit more about inversion of control and things like that on the various Tanzu blogs and such. So go there. Yeah. Yeah, it's true. It's, it's well fleshed out. Well, great. Well, thanks for being on Ben. One more, one more plug for, uh, Ben and Valentina's, uh, SpringOne keynote also talks, uh, about this and specifically in the context of Tanzu application platform. So that's it. You can find those on YouTube or spring.io. Sounds good. Well, as always, as always, this has been Tanzu Talk. If you want to get the archives, you can go to TanzuTalk.com, uh, find them there and we'll put in links to the, uh, the things we just mentioned there. And otherwise that you can check out that keynote or learn about cycling and Ben's life. I, I don't, I, you know, even though I live here in the Netherlands, I don't really know what cycling culture is like. It's much different if it's just your daily commuting vehicle than if it's something you actually, uh, think about, uh, much more squeaky sounding over here than it is in the States. Anyhow, you can, uh, go to TanzuTalk.com and check that out. And with that, we'll see
28:27see everyone next time. Bye-bye.