I thought, you know, Richard and I had the good idea that we should goose the episode content again with some quality just for the people who are kind of like have a sour gut about like, you know, talking about high level stuff. So we're lucky that we we have we have someone from my team, Kenny, and also a returning guest, James Governor from Red Monk. And, you know, they were they were hanging out talking about like cloud native and what all that is and things going on in the area. And I think along with Richard and I doing sort of like, you know, the old the old guys on the Muppets commentary from the side, I was thinking it would be fun to, like, listen in to to James and Kenny talk about it. But first, you know, for everyone who who hasn't listened to the complete episode, like the one person out of all of our listeners, why don't you two introduce yourself? Why don't you start, James? Great. Hi, this is James Governor. I am one of the founders of a company called Red Monk. We are an industry analyst company, but we're interested in developers instead of just the pointy head people. How about yourself? Give us an introduction, Kenny. Hi, I'm Kenny Bastani. I am a spring developer advocate at Pivotal, also the author of Cloud Native Java, who I wrote it with Josh Long. And that's about it. I'm mostly on an airplane any any day traveling around the world, talking to Pivotal's customers, prospects about Cloud Native. And also, as I recall, someone who is brave enough to play Andrew Schaefer at chess. I just I can't even imagine if that's like a profitable endeavor, sort of just purely based on time spent. It went way better than I thought. I was really worried about it, but I lasted a full 10 minutes. So that's great. Yeah. Yeah. I think I think I think if once you play, if you sit down to play chess with someone who likes to give lightning talks about how to punch properly, you're in for an exciting ride. Absolutely. No table flipping. No. He needs to he needs to coach that guy that that punch Richard Spencer because that punch was not good at all.
2:02So let me let me start you guys off by asking James, you know, I think I recently learned someone was copy editing some of my material that Cloud Native actually has a hyphen in it. So I feel like I'm pretty much halfway to being an expert on it, but it would it would be it'd be good to hear like when you when you both use this phrase Cloud Native yourself, if you do. And when you see other people outside of Pivotal or whatever, kind of in the industry using Cloud Native. Yeah. So so what is Cloud Native? Well, if someone if someone were to ask you that, who who was, you know, like not a civilian, they're one of these nerd people like us. Like what what would you explain to them? That's a great question. Kenny, what is Cloud Native? So Cloud Native for me, it really starts with starts with developers. Right. So it's it's a way for developers to frame a new way, a modern way of developing applications that is native to the environment of the cloud, which things are aren't static. They're ephemeral. They're dynamic. And being able to create these applications on demand, self-service way. That's really what Cloud Native is all about. Well, you are really good at this. Am I? Yeah, that was fantastic. Why is that different? Different than what we were doing before? Because it used to suck. And now it's not so bad. His answer is way, way better than mine. So, yeah, Cloud Native, I don't know. There's just a set of disciplines that we seem to have learned from companies that, frankly, you know, and individuals that have built things in the area where we did have these cloud resources. And, you know, this set of associated disciplines in around things like CICD, you know, breaking things down into smaller components, actually understanding distributed development, trying to take advantage of all the progress that we've made in probably these last five, 10 years in terms of just better programming. So I think it's sort of capturing some of those principles and, you know, then perhaps refactoring the architectures to better support those principles.
4:05I mean, we can go back to, you know, the famous kind of 12-factor Heroku kind of vision of how to build apps. That's been really influential, you know, certainly, you know, frankly, if we look at Cloud Foundry, that came out of, hey, this Heroku thing is a good idea. Let's make that a thing. And so I think it's just bringing together the lessons we've learned and developing accordingly. That's kind of my terrible definition of cloud native. I mean, it doesn't fit on a T-shirt, but that's still a solid definition. No, it does with small font. I've actually got that T-shirt. I mean, jump in, Coté, do you see the, I mean, you talked about the dev practices. I mean, there's the cultural side of it, too, I think, that we've kind of labeled a cloud native way of working. I mean, do you see that as well? It's not just the tools. It's a style. So I have this metaphor that I've been running with, which is that imagine you go to an airport and there's only one electric socket. And everyone's trying to charge their phone. That's in Britain. That's definitely Heathrow. And so what ends up happening is everybody has to wait for their turn or they have these extensions. And that's one solution. They have to figure out how to share this one resource. And that's what developers have been dealing with and operators have been dealing with before cloud native, right? So cloud native is really just a way to not share as many things, to be able to have things that you need to be successful, to be able to provision those in a self-service way on demand. And you get to have your own electric socket and charge your phone, charge your devices. You don't have to share and go into all this complexity of all these extensions and sharing this one resource. But I like sharing. I always try and teach my kids to share. Sharing is good. I mean, it's generally a great idea. But when it comes to development and operations of applications that have to be online all the time, not such a great idea.
6:06It turns out that developers are most successful when they have the tools and they have the infrastructure they need to build their application and be successful. So do you see that – I mean, you've talked to a lot of web companies. So, I mean, what do you think that cultural piece is? I mean, most of these labels seem to come from people who have, after the fact, described what other people have already been doing. Like cloud native, Netflix was cloud native before it was cloud native. But, you know, you talk to a lot of web companies. What do you see as the cultural characteristics of a cloud native shop? Oh, some of the obvious ones. I mean, you mentioned Netflix. So it tends to be small teams. You know, I think that's one of the things that, you know, whether we, you know, I'm a bit loathe to now introduce another thing we might need to define. But, you know, people bandy around that word microservices. And that's really about small teams working together on units of work. That's one of the really important things. People taking responsibility for things, you know, and not developing things with the idea that you're kind of handed off and someone else is going to, you know, do the QA and the test. And, you know, it's the – you know, it's for a lot of enterprises. I mean, they're still, you know, they're only just kind of emerging from that horrific abomination called waterfall. And so, you know, I think, again, I see cloud native as sort of, you know, part of the – yeah. It's agile team, agile, you know. I mean, certainly in the pivotal sense, you're going to be pair programming. What was the question again? I think that was the cultural aspects of cloud native. I think you described it as that way of working. To some extent, maybe even the way of thinking about software and thinking about modularity and thinking about constantly shipping. It's almost this – I know we think of it sometimes pivotal as a combo of microservice-y stuff, but DevOps plus agile. Well, it's just focusing on delivery and focusing on having compute at the drop of a hat, which is very different than 10 years ago.
8:07I like what you both said, but you said something that really appealed to me, which is responsibility, accountability. One of the things that happens when you're sharing the same resource, the same application across the company of 500-plus engineers and operators is that not everybody treats it with the same amount of respect, right? There's people who put more work into it than others. And what ends up happening is that nobody really just feels themselves accountable for that application, which ends up hurting the end users. And so with microservices, right, you have accountability for all the things within the realm of that application. And you're communicating in an ecosystem with other teams, and I think that's just a much better way to go about building an application. So talk about building apps. You apparently know something about this Java thing, this new programming language and environment. Brand new. All the kids are doing it. All the kids are doing it, right? So this Java thing, that's cloud-native, right? It is. Well, Spring Boot's cloud-native. Oh, there you go. So what even is cloud-native Java? So cloud-native Java, it was interesting. So Josh and I, when we first started writing the book, it was a different book entirely. It was Spring Boot. But then this cloud-native thing came along and Pivotal was seeing such great success in the platform end of things. That really, all of these things came together in one package, and we decided to rename the book Cloud Native Java. So originally, it was just a way to explain the Spring ecosystem, and it turned into a way to explain how all these pieces connect together. I have to say, by the way, that is pretty funny. There was, I think, a review, although I don't know how they reviewed it, but it isn't really out yet. It wasn't early. Did you? But there was someone who was like, this book is not about cloud-native Java. This is about Spring. I'm like, maybe the Reacher Show. That was literally the first comment I saw about it.
10:08Maybe it isn't out yet, so they're just saying that. They imagine that's going to be a problem. I think you did pre-release stuff with O'Reilly, right? Yeah. So I am very familiar with all of the comments. Those comments, right? And, yeah, yeah, so we talked with O'Reilly a little bit about that, and, I mean, what we decided is that we're just, Spring Boot really is just leading the charge. And it's just, it's created an open-source ecosystem where developers around the world are flocking to this because there's just gaps. There's gaps in the Java ecosystem. Okay, well, tell me about one Java thing that is not a Spring Boot thing that is cloud-native Java. You know, I can't even tell you. I mean, we are Java, right? So the entire framework is Java. It's kind of like, in a way, like .NET. If .NET now is open-source, a lot of it is, but I came from a .NET background, and .NET really was the framework, right? There was no other framework. So what Spring Boot really is is just a lot of passionate developers in the Spring ecosystem who came together and created something that there was a major gap, something that worked in a way that is native to the cloud environment. And people are seeing tremendous success today, and they're flocking to the framework, and they're contributing. And that's just increasing the value of that cycle. In terms of the Spring Boot thing, I mean, I guess everybody – does everybody that listened to this podcast know all about Spring Boot? I think so, but I think it's still probably worth potentially summarizing, you know, where this came about and . . . So what are the edges that had to be scrubbed off to make Java a little bit better? So that's a great question. Spring, for almost the last two decades, right, that has been a driver, it has been the framework for Java in a lot of ways. It was very popular because it was the first open-source framework that had all of these features that you're able to build an enterprise application with not a lot of manual effort up front. What I mean by not a lot, there was still some. Now, in 2013, the Spring team came together and they said, "Hey, we have all this manual configuration.
12:14Let's look at how these developers are creating these applications and the time that it takes for them to prototype and to get an application into production, to decrease that time." And Spring Boot really came out of that where there's this idea of auto-configuration, where everything that used to be manual is now auto-configured. You have a default auto-configuration and then from there, it kind of turned into this idea of, "Hey, what about recipes?" Well, if you can just pick a few things and we can auto-configure these components together, you can have an application that has these features out of the box and all you have to do is start customizing. And then microservices kind of became a trend, cloud, and kind of all these things converged into this way of developing cloud-native job applications, and that's Spring Boot. Well, this week, I thought we'd have a little exciting mid-roll thing going over one of the fun jobs we have open here at Pivotal. You know, if you listen to Pivotal Conversation every week, maybe you think, "How could I go work at that place?" So, why don't you tell me who you are and what open position you have at the moment that folks might be interested in? Thanks. Yeah, my name is Simon Horrid. I'm the director of Pivotal Labs in Boston. So, Pivotal Labs has about 20 offices worldwide and the Boston office is relatively one of our newer offices and it's actually located in Kendall Square in Cambridge, just a few steps from MIT in the Charles River. We're looking to bring on an associate director to join our leadership team for the Pivotal Labs team in Boston. The associate director role really has kind of five core elements to it. The first is consulting project help. So, at Pivotal Labs, we engage with our clients, we bring our clients into the office to build software products together with them. So, the associate director's role is really about making sure that the projects are healthy from the client's perspective and from Pivotal's perspective. This requires experience in, you know, dealing with consulting relationships and we work in this highly transparent way with our clients in the office. So, it's really about kind of having a continuous awareness to the consultant client relationship. The next element is people development.
14:16So, this means thinking about the people in our office, the consultants understanding their career path at Pivotal and making sure they're supported towards it. So, we're looking for the skills in mentoring and managing and giving feedback in difficult situations. The next is around practices. And I'm sure, you know, on this podcast, you hear a lot about our practices. And so, we're really looking for deep experience with one of our three core skills that we bring to labs teams. So, that's XP development, user-centered design, or lean product management. And so, the AD is responsible for encouraging kind of continuous improvement and innovation in those practices. The next area of skill is in business strategy. As an associate director, you'll be supporting the sales team and growing the size and conversion rate of our sales pipeline. And making sure you're worried about the kind of keeping the office revenue and margins healthy. And then also thinking about kind of maintaining alignment with the broader Pivotal strategy. The last element is thinking about the office space itself. Wanting to maintain an effective and efficient and inclusive workplace. And we have actually an upcoming office move to brand new office space down the street in Kendall Square. So, there's plenty that goes into ensuring that that office space is going to be a conducive environment to helping our clients transform the way they build software. And you can find more info about this job at pivotal.io/locations/boston. Yeah, that sounds good. I've had the pleasure of working with labs people here and there. And it's always enjoyable. It's sort of like you add the human to computer. So, that's always fun. Well, great. Well, thanks for going over that. And again, if you want to check that out, you go to pivotal.io/locations/boston. Hopefully, you know how to spell Boston if you want a job in Boston. If we think about Java, there's like, you know, not everybody is a millennial Java programmer. But, so, for people that have been, you know, in the trenches doing Java for years, and then suddenly there's like these two idiots on a podcast being like, "Oh, yeah, Cloud Native Java.
16:18Great. Spring Boot. Woohoo!" Like, is that something they, do you think they want to know about that? I mean, the person that's like a nine-to-six kind of developer in a shop that has a bunch of on-prem stuff. You know, they just, like, have their job to do. I mean... Writing JSP, you know, JSP pages and... Yeah, like, what is this? I've not met one developer who enjoys doing that stuff. Because there's just an easier way to do this, right? Every developer wants to be productive, right? What really makes a developer's job the worst is having to repeat work or having to copy code from somewhere else just because... You don't know how it works, but that's going to make this application go into production. With Spring Boot, it's just a way to specify, here's a few recipes. I trust the framework will do what it says it's going to do, and I can just customize it. And by the end of the day, I can have a new application in production. It makes things faster, increases the velocity, and increases developer experience. I think that's really where we're going is that we're giving developers really this freedom from being stuck into this world of legacy where it's very hard to change things. It's very hard to create new applications. And that's what the Spring Team is really passionate about is because they came from those backgrounds, right? So they intimately understand it. And so they've built a framework that they would want to use. So let me take a long-winded walk up to two questions, one for each of you. The first one is essentially, so Kenny, Spring Boot is essentially like I package up all these things I want, all these different components of a framework because I'm going to make a software application. And then there's a standardized way of like configuring them all and making sure these different subcomponents know how to talk to themselves or to each other, I guess themselves too. And then also, essentially, if you want, if I remember, it'll give you an executable of something.
18:21So it sort of like lets you select your subcomponents of your system, it wires them up for you, and then it packages it so that you can execute it. Now, that may not always be the best idea to just execute it on its own, but it sort of like uses basically automation and standardization to make it easier to get up and running. And then there's also some, you know, when you do the second to 500th sort of rev of that because you've got so much standardization, it's easier and better. So is that like sort of accurate? Yes, sort of. What was your second question? That was a very Germanic kind of question. I haven't met that many Germans, but I assume just like a good German, I wanted to make sure I was correct in my thinking. So, so, so given that, like, in Java technologically, like, what would you say are the top three, like, things that enable that or that that kind of like do that and all, all sort of like I was talking about this with our co worker Mark, right? How, for example, last time I was a Java programmer in 2006, if, if like introspection and the ability to kind of like do funny business, like behind the scenes didn't exist, much of the benefit of the spring framework wouldn't exist, right? Because all of the magic of doing this configuration stuff is based on like introspection and setting stuff and blah, blah, blah, right? This, this kind of metaprogramming layer in Java. So I'm curious with, and this gets to the technological nature of cloud native, right? Like, what are a few other things that you would say, like, well, when you look at whether it's spring boot or what cloud native is in the Java world, these are like technologically things that differentiate it from like, say, doing an EJB in 2004, right? Like, like, like what are the actual things like, I don't know, rest frameworks or queues, or like, what's like technologically things that differentiate a cloud native approach than, I don't know what the opposite of a cloud native approach is confused, like, you know, groundling native or something.
20:21I like to explain it like this. That's a great question. It's, it's like a declarative programming language or a declarative query language like SQL. I tell the application what I want. I don't tell it how to do its job. And that's really the big difference is that I don't have to spend all this time manually configuring things. And when you manually, manually configure things, it's not always standard, right? So across the board, you have a standard way to auto configure. And that's, that's really a huge benefit to developers because they know how things are going to work across all these different distributed components. But, but ideally, they just want to do their job, which is to add value, right, to build the business logic of the application. And what cloud native is really all about and cloud native job in general with Spring Boot is just having developers be able to say, here's the architecture. This is what I want. I'm not going to tell the application framework how to do it or how to wire it up. But if I need to go down deeper, I can certainly do that because we're built on abstractions. We use dependency injection. And it provides you with a way to override these things. So that's not going to get in your way. And that's pretty much it. I think developers just like that experience better than having to manually configure everything and then everything can go wrong with that as well. So if, if, if, if I were to make you pick like one thing from what you were saying that kind of like is the important sort of like necessary, but not sufficient, uh, that, that makes like Java cloud native. A lot of it sounds like, and I'm, I'm purposely picking a boring thing. Cause that's fun. A lot of it sounds like configuration. Like we think a lot about configuration and how we want to configure things because, and this is almost like, and you know, I don't know. I'm just, uh, extemporaneizing here if that's a word, but this is almost like one of the big epiphanies of the DevOps world is like, Oh, configuration. That's kind of important, right? Like, and it'll screw us up if we don't spend a lot of time about it, but it strikes me that configuration is perhaps like, I don't know if it's the most, but it seems like the most important sort of like philosophical epiphany of doing cloud native stuff.
22:24Yeah. I like that. I think that there's, there's a lot more, there's a lot more to it. Um, and I, I know you've reviewed the, you've been so kind to review the book and give feedback. Um, so, um, you kind of have some hints into this, but, but yeah, it starts with that. It starts with the things that we can easily change and the things that we can't, um, things that we can easily change our configuration, but it just turns out that that's where a lot of the things can go wrong. So, uh, yeah, configuration. I think that that's, uh, it's a really interesting point because one of the, the, the, we think about really what kicked off a lot of. You know, uh, the thinking, uh, in and around cloud native is the instantiation of an opinion in the code to reduce configuration. And this goes back. I mean, of course, you know, we can go back to, to rod having these ideas, you know, back in the day, but, but I think rails when they kind of, you know, when, when, when, when the rails framework for Ruby came out, it was just like, oh, this is so much easier. Cause I don't need to configure everything configuration that has like a very high cognitive overhead. And, you know, Java definitely really suffered from that. You can do anything with it, but you had to configure it appropriately. And, and I think one of the things about sort of, if there is something in cloud native, it's, it, it, I think that the, the sorts of architectures and applications that I have seen tools and platforms are generally ones that do indeed, uh, instantiate an opinion and reduce the amount of config. You needed, you need to do in order to run, uh, in order to build an application and, and, and run it. Yeah, absolutely. And a lot of ways, as, as we explain, uh, developers, what spring boot is, we, we use that word a lot of opinionated. Um, I don't like to use that, that word so much anymore because, uh, everybody can have their own opinion about it.
24:24And, and I know, but they're all wrong. Yeah, probably. So the way that I like to say that, yeah, you, you really just, uh, tell the application what you want and not how to do it all the time. And that, I think that's really, um, in a way, uh, a good way for developers who are new, new to the Java ecosystem, um, to approach this. All opinions are equal, but some opinions are more equal than others. Well, I mean, I think it just saves you from living on Stack Overflow. You said you came from a .NET background. I remember using WCF in the world and there would be all these settings. Like I'm changing buffer sizes. I don't know what I'm doing. Like just set it for me with normal defaults. Why do I have to figure out what the right values are? Be smart and tell me. I remember that. Yeah. It's nice when these frameworks, I mean, you can really start these up and connect to Kafka or connect to rabbit or connect to a cache. I don't really have to know much. And if I want to override it exactly, I can't. It's extensible. But Hey, who cares? Who cares? Yeah. What, what's the, uh, what's the old, uh, the old Monty Python thing where they sit around in white jackets complaining about how miserable their life used to be and trying to one up each other. That's that, that, that bit has a name, right? You had one bean. You were lucky. We didn't have any beans. Exactly. Exactly. Exactly. My dad would beat me and put me in a box and, you know, rather than a bed. So it's, it's like, Oh, you had to set buffers. I had to use property files. Oh, it was terrible. It's just like over and over again. Yeah. I remember looking at the, the Java IO things and thinking about these were not written for humans to use. I have no idea what's happening here, but, but yeah. Yeah. Yeah. So, so that, that, that, that kind of like slides nicely into, uh, into the question I had for James and just to like, uh, you know, long wind up to it. Like I, I was writing in my notes that like this idea of, uh, automating and standardizing, I think that's kind of what you decompose opinionated into, right? Like you standardize something and then you automate the application of it. Yeah. Cause opinionated does have a weird tone to it, but it's, it's a very direct. So anyways, so here, here's, here's what I want to ask you, James, to, to kind of take advantage of your, your, uh, your broad perspective of everything.
26:28It's, I mean, I mean, it's essentially, I mean, to be brief, it's like the lock in question, which I think, I think is really hard for a vendor to be credible, giving you any answer about it. Um, but you know, when it comes to having an opinionated infrastructure, right? So there's, there's two parts to this question. One is like, so like, if that's so awesome, why don't we all just still do mainframe coding? Right. Cause I mean, like that's all kind of opinionated. Like, like when, when, when you're using a technology, do you decide like this set of opinions is crap and I need to get a new set of opinions. And then, and then kind of related to that is like, so how do you make sure you don't like choose the wrong opinions? Like, what do you, I don't know, like, how do, how do you see people even thinking through that or saying folks are thinking through it? Like what's, what's the selection criteria people should go through? Well, I know what you said today, which I was hoping maybe I'll try to influence your answer, but you kept hammering today with pivotal, the idea of convenience. And I think even you or Steven said, look, something might not be, be completely optimal, but if you've made it convenient, those are, those are gonna be things I'm going to consume. Do you see that? Is that how you choose which opinions are better as sometimes which ones just makes sense or easier to consume? Yeah. I mean, I think to Kenny's point, you know, generally developers do like convenience, um, in, you know, and in fact, everybody, all human beings like convenience. Um, you know, you, why do you use Uber? Because it's super convenient. Um, you know, then you find yourself, you know, ordering a car you don't even need. So, you know, I think some of it is just like what, what genuinely is, is, is the thing that is going to make things most easy for me and, you know, wrong and right opinions. Um, you know, there are some pretty smart people working on, uh, these things. And, and it's very, I think it's, it's an interesting question because I, I feel like there is very often a, an individual that is actually an opinionated individual.
28:28I mean, if you've ever seen, you know, DHH talking, he's not short of an opinion or two. Um, and you know, of course he was, you know, initially the, you know, wrote, wrote, wrote the rails framework. Um, you know, rod, very strong opinion about how things should be done and sort of implemented that, that in code. Um, but yeah, I think it is, it's just about convenience. And, you know, do, do we pick the wrong opinions all the fricking time? Right. Um, it's changed. Humans make terrible decisions constantly. Um, but you know, sometimes you find a tool that works well for you. And, and that at the end of the day is the only opinion that, that really matters. I guess you hope these things can grow with you to some extent that you haven't just done the startup tech or the new team tech. And as soon as you have a scale problem, it collapses. But even then you can, nobody can predict the future. I guess you just have to some, as you said, maybe trust where this comes from, that hopefully some smart people thought about problems at scale or. Well, I think Salvatore at Redis is, is a really, you know, interesting, uh, point here in the, in the, you know, talking, talking, talking to him is really interesting. Cause he's kind of, you know, at this point, benevolent dictator for life. No, he makes the, makes the decisions. And when he joined, uh, Redis labs is like, these people are actually pretty amazing. I'm, I'm good. I trust them a lot, but as a designer, my role as a designer, I mean, I trust them to write code, but I don't, I'm not ready to relinquish my, my design. Um, or, you know, I, I mean, you know, if we think about, uh, not that Linux is a development framework or whatever, but it, it certainly does.
30:28Uh, uh, it, it contains opinions about how stuff should be done. Very strong opinions. Right. Um, so who all is the sort of the, who's the, who's the, the designer? Who's, is there a, is there an individual that kind of drove, like, who do we credit spring boot in terms of the, the, you know, in terms of pulling all that together? It is the entire ecosystem. It, most of all, it's the spring team who, who kind of facilitated this, but there's a, it was the entire ecosystem. Yeah. Self formed around itself. But then we feel like there's a grandfather of this or grandmother. There might be, but I mean, does, does that really matter? I think that. I think you're trying to get to, is there a set of opinions that came from some, not even individual brainchild, but that they were like, this is a good way to do spring code. And therefore, and yes, the community validates that because that person could be insane. But these opinions, they flow up as issues. Right. So this is really born of the open source ecosystem. Well, who drove the project? Spring boot. Spring, who drove the project for spring boot? Yeah. Phil, Phil Webb is one of the co-found. I mean, there are many people and I don't want to just give one name there. Sure, sure. I know Phil Webb would love me to credit him on this, but there, there really is a lot of, of hardworking talent and ideas that go. Phil Webb makes really good slides. He makes great, really great slides. I have to say, he makes really good slides. Yeah. He should give up the day job. He, he could set up a great little agency just making slides for people. That's what Phil should do. No, he and Unsi, you know, and I have to tell my, my child where, where kids come from, Unsi's creating the slides for me. I'm telling you, it's, you know, those two, imagine that agency now. Holy cow. I would definitely get them to make my slides. Here we go. Hmm. You know, I, I, I thought of, I thought of some, some replies involving, uh, what kind of butter clock makers use and putting, putting bread in a toaster slot. But I've, I've, those kind of, they've effervescently gone out of my head when it comes to, uh, using emojis to explain the birds and the bees, which I'll have to go check if those, if those are available in there.
32:37So, uh, yeah, I forgot what it was. Uh, so really think about the things that developers do with an application that get them attached to that application. Now with Spring Boot, we've kind of standardized things in a way where it's, it's cheap to throw things out in a way, right? You're not having to do all that manual setup work that gets you attached to that application, uh, where you no longer want to change it in a way or, or, or throw it out. And that's how a lot of legacy accumulates is that there was all of this effort upfront, uh, to build this application. And that's kind of alleviated today with an opinionated framework like Spring Boot. And I think it's going that way in general with, with the cloud kind of converging on this automation idea. So how, how opinionated, I mean, it's interesting cause you think like node is all over the map. Like what's the, I mean, there's a, there's certainly a lot of, of cloud native apps built in node. Um, but I'm trying to, I'm trying to think about like, uh, whether there are configuration decisions being made. I'm just trying to prove this out a bit rather than just only thinking about Spring Boot. It seems like the framework to me, Express has opinions. Yeah. And there's things like, this is how I have the middleware and, you know, ASP.net core has middleware with its microservices or services. So I think they're always, again, steering you somewhere. It's the usual, again, I think you're one of the people that, you know, even talked about PCF as being opinionated, but extensible. It seems like any good framework meets that, that it's got some opinions, but you're not completely beholden to it, that you are able to stretch that. And it's not Java. It's also node and .NET. I'm sure Ruby as well. Very good point. I think that's probably a signal of a good framework. So Kenny, have you looked at, have you looked at OpenWisp by any chance? A little bit. I haven't gotten to dive into it yet, but it does look interesting. Yeah. I was just kind of wondering about, you know, I think that, yeah, I think that we, we need to kind of brought, I think that has to be some other interesting art in the Java landscape that is also.
34:39That is coming at things from a cloud native perspective. Now, not, I mean, I only say OpenWisp because I think it supports Java. So I'm trying to, if you, if you're running, if you write a function on, what does it know? So it's Node. I think it's Node and Swift. Swift. That's it. So Java's coming, but they don't have it yet. Java's just in Lambda, I believe at the moment. So Java on Lambda, like, is that cloud native? Yeah, of course it is. But you're not going to be able to pull in all the things that you get. You're not, you're going to have to actually be impaired in the way that you program that function and how it's going to tie together with other functions, Java functions that you have on Lambda. It's, or you're going to connect into the services that are provided to you, which in a way is an opinion. And, and that's how you're going to go about it. But yeah, absolutely. It's cloud native. Yeah. Cause I think the opinionated thing is interesting and it's added value to spring boot, but I'm just trying to draw out a little bit about like, just thinking about, so we started with some sort of definitions of cloud native. And then we just ended up talking about effectively what a frame was. So we're, yeah, where all do we run these things to cloud native apps have to, do we have to deploy them in Amazon? Absolutely not. Um, now the cloud native stack, right? All the way down to the bottom of the IaaS layer, which is the infrastructure as a service layer. Now I'm not going to go through the whole stack, but there's this layer of abstraction. Similar to how spring programs their starter projects is that there's this layer of abstraction and each layer of the abstraction, you can change things out, right? The very bottom layer, we have the IaaS layer, right? That's an API that allows me to provision infrastructure using API on demand. And on top of that, we have a platform, uh, which is going to, uh, have an opinion about how it's going to manage that infrastructure. And, uh, that's really the application platform is how you're going to deploy and run and operate your applications. Uh, and again, the automation that's provided with that is that it has an opinion of how you should deploy and operate these applications.
36:45And it's going to, uh, reduce a lot of the cognitive overhead comes with maybe rolling your own solution, um, or a spoke solution, uh, which, which ends up being hard to manage long run. But I can run that on these fields open stack, right? Or raw IaaS, like a cloud native app. Is it, is it more about the app or the infrastructure? Is it an inseparable combo? They're, they're intimately tied together. I think, um, absolutely. Well, I think that's a good place to end. You've got, uh, you got cloud native at the application layer and cloud native at the infrastructure layer. It's a good, uh, until next time sort of conversation, but thanks for both of you for being on. This is fun. It's good. It's, it's nice not to have to like come up with questions and have someone else do it. Well, that's good. Cause you don't actually ask questions. Coté, you mix. No, no, no. Let's say, what do you think? I, I, I don't, I don't, I don't like to give intellectual ground to anyone. I just sort of lull people into, uh, coming into my library and farting around. That's, that's what I enjoy. So as always, this has been Pivotal Conversations. You can find the most recent things at soundcloud.com slash Pivotal Conversations. If you don't subscribe to it already, that's really the best thing to do. It makes everyone really happy. And then you don't have to do anything. Even if you don't listen to him, subscribe to him and download it, download them five times. That'd be great. If you haven't already, uh, and you probably haven't, unless you're that one person, it'd be great if you went to iTunes and left a review for us or a rating. It's even better if you just refer people to it or promote it somewhere. And we'll see everyone next time. Bye-bye.