 Hi, I'm Kenny Bustani. I'm a spring developer advocate at Pivotal. I'm a little bit about myself. I wrote a book called Cloud Native Java, which is all about building microservices using Spring Boot, Spring Cloud, and Cloud Foundry. All right. Hi, I am Cornelia Davis. I also work for Pivotal, have been working on Cloud Foundry for about five years almost. And I have not written a book as in past tense, but I'm writing one now called Cloud Native, which covers apps, data, and what I call the Cloud Native Collective, which is bringing it all together. And I've been working with customers and partners on Cloud Foundry for some time. I did write a book. It was, as you talk about books, it was 20 years ago. The Java source book, first book on Java programming. Don't read it. It's horribly out of date. It's full of errors. I'm a founder of our energy team with Leastat and worked with all the publication with publishers. And we'll begin with that. So we've published books on, there are copies of the published books on the Kubernetes ecosystem, and we come with our friends and fans, and we publish every day on the site of the new stores and stuff, so Leastat.io. OK, thank you. And romantic lighting, which is a social experiment. I want to travel with both possible and uncomfortable. All right, without further ado, well, the first set of questions I have is in terms of navigating the library services stack using air quotes. It's sort of looking at things from the traditional, more air quotes, plan stack with pre-tier web architecture. And think about, you know, what carries forward? What else is coming forward? And then you can use it as a point of comparison to understand if that works, so define stack and what sort of maps it over. So we're going to start with Ed in terms of thinking about the old web to your versus now in a microservice architecture, API would be kind of the front end for microservices. Is that a fair way to think about it? Well, it's definitely a starting point that a lot of people are coming through. So a lot of the API activity, probably for many of the folks in this room, was about moving to sort of a new front end, usually mobile apps, but also people rebuilding their presentation field with JavaScript and simple paybacks and what have you. And so, you know, for a lot of application developers, they're sort of first pouring into building APIs, you know, page-centered architecture is something that was used in our front end. And then microservices now is a lot of overlap with that, but there's also a lot of things that we need to do. And we're also going to have thoughts about where the API's front end or what the API is going to be placed in the front end. While we need to prepare to jump in, frankly, for chairs on the stage in terms of how it works. Cloud Native Deathmatch. The native tier, is it always there? How many people thought the native tier was different? Are there kind of big questions there? Yeah, and so it's interesting that you start with the lamp stack because we've always kind of tiered things and we've always broken things apart and that hasn't changed too, too radically in terms of this, from a philosophical and from an idealistic standpoint, the fact that we have our business tier and then we've got our storage and our persistence tier. Except that in the lamp stack, there were a couple of things that were very different. In the lamp stack, we might have had some level of distributed nodes in any of those layers, particularly the business layer, the application server layer, but it was not on the order of magnitude that we have now. So we might have had two or three nodes or maybe even half a dozen or a dozen nodes, but it was an order of magnitude that we could still kind of put in our heads and we could still manage and it wasn't constantly changing, so we knew we had five servers in that layer and we networked them together a particular way and we tied them back to our data tier in a particular way. And having a more static and predetermined and not so frequently changing architecture in there allowed us to bleed some of the persistence and some of the data into the business tier. So that's one of the things that has markedly changed when we moved over into cloud native applications and microservices is that we started to say, well, don't allow that to bleed into that layer anymore. So we have to be much more strict when we talk about stateless microservices, we're much more strict than we were before on no truly, there should be no state in there. So that's one of the things that changes when we move from a lamp stack into the microservices that we have to be a little bit more strict about that. And that's where everybody here is at the Cloud Foundry Summit. So you're all familiar with the service API. So the service broker and that model, sometimes I don't even like to call it the service broker, I like to call it the service protocol, which is this, okay, I'm going to be explicit about where my data tier is and I'm gonna create these services and I'm gonna bind them to the applications. And that's where we've been with Cloud Foundry for about the last four years is that's kind of the level of thinking that we had was yep, move data into its own separate tier, be super strict about it. Here's the services protocol to be able to allow you to do that binding and that's where we were done. What's changing now is that we are realizing that we have to take now that data tier that we've largely left alone aside from being more strict about making a separation. But we've left it largely monolithic and largely not polyglot, largely homogeneous. And now we're moving into a world where the data tier we're having to take what we did in the application tier and apply some of those same principles to the data tier, start to break it apart, start to break apart the monolith, treat it as logically perhaps still as a single data thing, but implementation-wise and it's far more distributed. So the data tier has to change radically. We just haven't done a lot of that work yet. I wouldn't say it's entirely net new, but it's something that you need as a part of a microservice architecture. Now, service discovery's been around for a while. It's not entirely new, but you would need it if you're gonna do microservices, to be able to find other services without having a configuration file that has all of the routes defined in there and what happens when you spin up new containers, you need to know where those are located, so you need service discovery. And so that's the reason why we need these kinds of things. Pretty much, I mean, so there's a pent-up demand for something that is more lightweight, cloud-native, agile response to what we used to to call service-oriented architecture and a lot of people want microservices to be that. And maybe they will be. A lot of people are using the terminology in that way. For example, Netflix really uses the term in that way. On the other hand, a lot of what you see right now where there's a very pressing need is for a mechanism for essentially decomposing your apps and beginning to communicate between them, but it isn't an attempt to reinvent service-oriented architecture. What's interesting about that, though, is one of the things we always talk about, so we're gonna start throwing chairs here soon. So this is good. Thank you for the question, Alex. Yes, I'm glad you were being intentionally provocative, and that was good. So one of the things that we talk about with microservices all the time, and one of the big benefits, in fact, that people talk about usually first is autonomous teams. And you just made the suggestion that that isn't, in fact, the way it's done most of the time. I think you said that the consumer and it's the same team that's consuming and producing the API. So it isn't about team autonomy. So is that something that you're seeing pragmatically? What is meant by team autonomy? What I mean by that is that there's a team that's building a something. They're gonna be a consumer of a microservice, and they are loosely coupled from the team that's over here. They are not in lockstep. They do not have to have a Gantt chart that says, hey, I can't release version two of mine until you release version two of yours. That's what I mean by autonomy. You're saying that's not necessarily what you think. Well, what I'm saying is that you suddenly are going to move into an entirely different realm that microservices may or may not protect you from, which is now you suddenly get into things like API description formats. You get into things like API versioning. And a lot of that is typically not the hallmark of what people are talking about when they mean microservices. Again, this is a continuum. So just to not make it as provocative. So we solve a lot of that with Spring. Like API versioning, for instance. And I like to think about each microservice as a GitHub project, right? Or a Git project in general. Now, if you're a consumer of another service, you're going to maybe make an issue against another repository. Now for versioning of your API, you can use something called consumer-driven contracts with Spring Cloud Contract. You would be able to contribute or make pull requests of your expectations of that service, and you can run tests against that when you go through your continuous delivery pipeline. So before you get into production, you have to pass those tests, and that allows that autonomy. That's going to prevent the breakage, but you're still going to end up having a big side-band governance model. I don't believe that Spring actually completely solves that problem. People have been using Spring to, you know, and Spring is a whole portfolio of things. I won't debate with the pivotal folks about the entire definition of that, but when you start working with, particularly clients that are outside of the Spring ecosystem, you are going to end up with a whole bunch of communications challenges that, again, are side-banded for the code in terms of communicating to clients that versions have changed and so on. Maybe if you are all in on both sides. Excuse me. Sorry. Assuming you've got, and again, this is one of the things we're seeing in microservices where you've got a common stack on both the calling side, on the consumption side, and the provider side where you're able to start to deal with these things, but a lot of what people are trying to do is use these in very heterogeneous environments where they don't. Sure. I wonder, I love how Alex asked the audience for a question, and I'd like to ask one here as well, is that when it comes to API versioning, my sense is that many of us don't really grok that particularly well, that we have a ways that we can go in understanding what we need to do in terms of API versioning and the techniques that we're using and even the value of it. And so my question to you is, would you agree with that statement that we could all learn a little bit more and maybe do a better job doing API versioning? Yeah, almost, yeah, more than half the folks. So for Spring Boot, which has been an incredibly successful project, we have over 19 million downloads a month now. I really think it's two things, right? The first thing is packaging. So when you talk about a Spring Boot application, what really changes is that you're no longer shipping a war artifact to an application server. Your application is the application server, so that's the big difference and that's fueling a lot of this microservice growth. The other thing is reuse and composability, right? You can go to start.spring.io, and you have all of these ingredients you can choose to put together a recipe. And that recipe can be the prototype for your microservice. And then you can replicate that across your organization. You can standardize on components. And I think that's really fueling a lot of the success that we're seeing with microservices today. It may get more complicated. So standardization is really important. So I've seen that across the board. When I started out with microservices, I thought, yeah, every microservice should be able to choose the technology that they want to use to solve the problem at hand. But you really need to choose that technology across the board at your company. Otherwise, you're not really gonna have specialists in the company that you can draw upon to solve certain problems. So you need to standardize at some point. So I've thought the main problem is for a while legacy culture, right? I think there's a lot of people out there who just don't really want to change. And two, some people don't need to change. I mean, if you really need a microservice architecture because you want agility, you want to go faster, then go there. But you have to want to change. You have to want to embrace the new technologies. Now you're all here at this conference because of that. But you have to go back to your company and you have to really spread that amongst your colleagues so that they get on board as well. I think that's the biggest blocker is getting everybody on the same page. Speaking of things up, and things are going so hard fast, it just seems kind of, just doesn't seem really logical to me when you think about kind of like, how fast actually things are, right? And how active these ecosystems actually are and how fast the building source communities are actually moving. And I don't know, if you guys can have me fast on that because I feel like it's, you know, you know, things are still, the market's still slow and everything else, but I don't really buy it. Do you guys? I definitely do. You know, to a certain extent, the overall speed. So, we're in the middle of a platform renaissance and a framework renaissance and increasing choice and all the things we talked about. And thankfully, we're only talking about, you know, things like microservices, we talk to people often in the JavaScript land, they've got a new framework every month to sign. You know, they, this is all sort of, you know, paced by the actual, you know, delivery of applications and adoption of those applications, which I think is the part that we forget about. So, even though we can deliver the application faster, getting the users on it and building a life cycle and so on around that takes time. So, a lot of the apps that are being built on these new platforms, you know, are still in there. Even though they got delivered much faster, they're still out there. People are experiencing them. They're going through their own pace of revisions and those are going to drive new requirements that, you know, are going to be incorporated back into the platform. So, I think, you know, that concept of pace layering, different things happening at different speeds very much applies. I think we all, very close to technology are moving very quickly, but it takes a while for it to propagate. Okay, I'm sorry, I had to interrupt. Okay, and maybe the right way to keep it is just, it's the speed to value for the folks trying to get the value out of building and bringing models and building new microservices architectures, and they want to get the value out of that. And so, what's the theme that needs to change? Kenny says it's not anything in technology, it's just people in culture that will help people get to that value faster to figure if we can friend the question or if we can do that. But for the rest of the panel, it's all fine there. Yeah, I mean, certainly what I've talked about earlier around figuring it out at the data tier is critically important. And there isn't a single person that I talked to about that who doesn't say, oh yeah, gosh, that remains a huge problem for us. I do want to just very quickly echo what Kenny said. I'm not sure if it's culture, but I think it's along the lines of what he was talking about. Just sitting here today is making me think when we had this conversation around what was it we were talking about? Were you chimed in? I have such a short-term memory. But let me give you another example. So I was chatting with a group earlier this week and we did some user interviews of developers and one of the conclusions we reached was the developers are a lot more comfortable with synchronous APIs than they are with asynchronous APIs. And my fear was that we were reaching the conclusion that we were just gonna stay with synchronous APIs, but that isn't gonna work in this new model. So there is this notion of we've got the primitives, we've got some primitives in Spring Cloud or in Spring Boot and Spring. Do people know how to use those? Do people actually know how to leverage those and we still have a ways to go to re-educate into what are the patterns that work in this highly distributed, constantly changing environment that is the cloud? Well, I think that a piece of it is that it seems like we are relearning a lot of the lessons that start to happen as you widen the scope of reuse and you start dealing with sort of, so I think for some of the previous comments about it's company culture and so on, the minute you start talking about services and you start talking about reusing them and so on, you're now dealing with an ecosystem of individual teams, different practices, different technologies. And I actually don't think we've made that much progress on that. I think that the people who are being the most productive with microservices and done so by moving towards sort of a more homogenous culture and a more common platform, which in many ways is great because it allows you to move a lot quicker. But I think that as we start to sort of hit these boundaries and some of these boundaries are what happened when you try to share services outside of the perimeter of your organization but in some of these organizations that are now adopting this, they're just vast sprawling organizations of 40,000 developers who are using a variety of different technologies. I think that's the challenge point and it's going to be where a lot of these microservices projects suddenly realize that it isn't that micro anymore. Now it's looking an awful lot like the old fashioned sort of sort of architecture projects of two decades ago. There's two things that come to mind. One is that, one thing that I heard this morning said is that when developers start thinking about application development and the management starts to think about application development and making the process faster, that has an effect on the entire organization. And it affects the hatred of the entire organization. And that seems to be a shift that you have to be ready for. The issue that seems to come when you start having these changes in application development and the management, the deployment and the management of those applications becomes a new reality that is often difficult to understand. There's different time dimensions. There's different ways that you might have done something manually before which you can't do it anymore. We're seeing kind of the out of the sort of those architectures and that affects so much in terms of just thinking of how you can monitor the dedicated systems. That's complicated, that's very complicated, but it seems to me like the next step is to get the business involved much more. You can start having more analytics to have the real representation of the entire organization because if the developer organization truly is impacting the overall organization, there has to be kind of a much more explicit way. Despite my best efforts, there's actually, I think at least like three or four arriving at something on culture, people, education, all those changes, so I guess I failed. But I really want to thank you everyone and we'll continue the conversation. Thank you, Jeremy. Thank you. Thank you.