Rita's back, as always, for an interview episode, and we have a guest here. Why don't you introduce yourself, guest? Hello, Michael and Rita. Thank you for the opportunity. I'm AJ Patel. I run the Modern Application Business Unit at VMware, and really excited to be here with you. I'm excited that you're here. I've been wanting to do this for a while because of your history, if you will. Coming at this with some of your background, specifically, you were right there, front and center, on the front lines during what I would call the app server war. WebLogic, WebSphere, JBoss, all those things. And so I was super excited to get to work with you again. Tell us a little bit about that, about your experience during that time. My own history, as you know, is early days at BEA. I wasn't really part of the app server team. I was part of the integration team. So I caught the EAI bandwagon, if you will. So I'm kind of dating myself, as you can see, from just the use of the terminology. And then very quickly, that EAI became a SOA metaphor. But if you look at the history, we went from monolithic applications to end-tier apps, to PaaS, platform as a service. And now we're hitting microservices, right? And the whole notion of public cloud and cloud native, as we call it. And consistently across those, I think of both the whole notion of middleware. And people hate when I use that word almost now, right? It's called a bad word. But if I look at what all of these application and data services are, they're nothing more than granular middleware services that were part of these larger platforms we built. So one trend I've seen is this general trend of breaking these large suites that software vendors love to sell, right, into the enterprise, because that's what we sold to enterprise, made it easier to package up these things and sell, to now more of these, you know, services that are easy to consume and are managed and are accessible to developers, right? But at the end, these are really about productivity. So the idea is, how do you give developers a set of things that they can quickly build applications and not have to worry about, whether it's transactions, whether it's security, whether it's messaging, whether a database persistently or et cetera. That notion has always existed. So I think middleware as a layer to give you portability, developer productivity, being
2:02able to scale, those benefits or those patterns haven't changed. The architectural patterns have gotten better, I would say more refined over the time. But there's a lot of learnings in my view. When I looked up an app server, and if I break up its parts and I see a microservices architecture today, the component still exists. You still have a messaging or event-driven architecture. You still have a transactional system that you need to build, usually backed by a database, right? You still have scale-up, scale-out architecture. So the learnings are, you need some kind of a productivity app platform. Whether it's an app server, whether it was a PaaS, or now moving to the world of Kubernetes, I think there's a gap here that we've got too fine-grained and there's a need to package up a more modular platform. And that's really the opportunity, as I see from my history. That is spot on. This occurred to me, I was a few years ago reading an analyst report. It was a taxonomy. It was a PaaS taxonomy. And there were like 19 PaaSs. It had everything from like mom PaaS, which was message-oriented middleware PaaS, to I PaaS, to DB PaaS, to A PaaS, to all these different PaaSs. So spot on with that. Still some of the same components, just broken up and renamed as a service. Yeah, the architecture pattern was loosely coupled, right? More and more developers own responsibility of the app. I think what Docker and the whole container and now Kubernetes deliver is, it's really made it easy to package up and make the deployment easier, right? So now developers can take everything they need. And so the granularity of a component or an application has really shrunk. In the world of SOA, the business contract and the services contract are much more coarse-grained. In microservices, you have much more smaller components. Like I remember the promise of EJBs 20 years ago, right? The idea was creating, you know, at BA, I think in 2000, our company bought 20 components. They were e-commerce components. And the whole idea of modularity was that you could take these building blocks and quickly build an application, but these were the components.
4:02You change the word component to microservices, you know, it's quick. And I know it's not the same, but you can start to see the principles haven't changed. The problems do change with the microservice world. So things like DevOps as a delivery, as a practice for how we deliver software becomes even more urgent, more critical as you break this down. But it's an improvement of a lot of good practices and a lot of learnings we carry forward. Every generation has taught us something new. And I think the past productivity has been just unbelievable. Something that I wasn't directly involved in, I competed with it. And so now being part of that Spring PaaS platform owner, if you will. It's, it's pretty exciting. It's pretty exciting. Tell me if what you're reminding me of is wrong, but when you're going over EJB, the promise of enterprise Java beans and SOA stuff is I'd forgotten that a lot of that effort was modularizing business process and workflows, right? Like that, like this EJB is for paying for something or this EJB is for like approving a job title change, right? There was a tremendous amount of, what did they call it? Like industry working groups that were trying to codify what this service looks like and therefore have the reusable component, not just be like a technical thing. Like here's how you, I don't know. Business service. Yeah. And I hadn't really thought about that, but we don't really like do that yet in, in like our microservices days. You're actually seeing some of that now. If you, I'll pick on something else. If you look at a company in Twilio and some of the communication services that you now have just used. So you have a little bit of mix of both, right? You have higher level services that you're not procured. You don't even buy. So we call it PaaS or application services or public cloud services that the abstractions are getting more well-defined. We went from complex schemas and XML and web services, right? Something much more simpler with Rust, JSON, et cetera, the protocol. We're also starting to see that business services you can actually just consume.
6:04The entire company like Twilio has formed around communication APIs. And also I don't have to worry about those, right? So there's a mix of that's happening. The big trend here is you're buying it as a service versus setting up that component and building it yourself and operating it. So one big trend is you're consuming it as a service is one trend. The second trend you'll see here is my own application. I'm breaking it down to smaller pieces. Domain-driven design is really becoming really critical. So I'm starting to self-contain everything around a capability or function, but a much more granular level. And then the application developer's job is to build an app or solution or workflow by composing these pieces together. Some things are bits of code I wrote, self-contained as a service. Some things that I'm procuring or acquiring. Some things are libraries I'm taking from open source to build these things as well. And so this world of a new app is a composite app. That's a combination of images, code you build, services you're wiring in at runtime, not even at build time. And so how do you start to manage this? That's the new fun world we're living in. Yeah, yeah. To manage control and flexibility. I like that explanation where those business modules have shifted to SaaS things, essentially. Like it gets to Rita's point of all the different types of cloud things. I remember those reports. There's lots of them. And I think a lot of those categories were trying to, a lot of those analyst reports were trying to categorize exactly that. The types of business services versus just lower level technical things. How do we render a UI or whatever? Those kinds of services are great, right? Like it takes care of a huge amount of operational problems that you would have in the pre-SaaS days, which is wonderful. And global scale. So I build an app. I need to deploy it in another region. How do I deal with all the local constraints or leveraging the infrastructure? And this is like communication is a big problem. It's like SMS. I was talking to another company that's doing something similar in this space. And they're like, we provide SMS as a service.
8:05So developers don't have to worry about it. And we provide a very simple programming model by which you can consume this service. But we make sure the messages are delivered to each of these 20 countries in Africa. And they've set up the infrastructure to do that. So this is where the world is coming together between cloud and a traditional self-contained application server, right? The deployment model was much more. App server was a box you put applications into. The internet and the cloud is, quote, unquote, the platform on which you're deploying these services to. So all of a sudden, the problem statement has changed, right? It's no longer a foundation of a PaaS or a container of an app server or a Java instance, or if you will, that you want to set up on a JVM somewhere. It's now a collection of these things running at scale. And you're wiring them up to talk to each other. You're making me think when we think about cloud services for developers, right? We've talked about this. There's hundreds. Yet the onus is still on the developer decision together to build the thing they're trying to build. What we propose is, as you said, put it all together so they have it all in one place and not have to worry about that. Reducing even more toils. That's what I'm thinking about. The evolution of that. The other thing that strikes me is we talked about Conway's Law in a previous discussion and how this evolution from SOA to microservices and just thinking about it as granularity, but also how it impacts your operating model. You can't talk about microservices without talking about DevOps, without talking about domain-driven design, without talking about agile practices. So that's probably been an interesting evolution for you to watch and see, especially having left the middleware world and gone to infrastructure software and now back. I used to talk about my buddy Yafim and Massimo from almost a decade ago when I used to work in the middleware. I call them Mr. and Mr. Middleware. And we used to talk about this concept and we didn't know what to call it even then. And we said there is this layer above infrastructure, but it's more flexible than an opinion it has. And then it also competed with the products that now I am responsible.
10:06And we call it this IaaS plus layer. It was this flexible modular PaaS that gave you a lot more productivity above infrastructure, but was not as constraining, if you will, and supported all application deployment stuff. And what's happened is with containers, with Kubernetes, you effectively now have a toolkit that allows you to package up application, give that control back in the hand of the developer. There's this constant battle of how much control you give the developers or the platform teams. It has been an ongoing battle between the architects who own enterprise architecture teams, right? Who need to set up the guardrails, if you will. The developers need more self-service flexibility. We've been in this constant tug of war of where the line is. And I think the beauty of Kubernetes and some of the work is we can start to now, we layered this both as an infrastructure IaaS, but also the platform on which to deliver capability. And so we are all on this race to take what TaaS has successfully done for the largest enterprises, but make it much more ubiquitous and much more pervasive to leverage the breadth and the ubiquity of cloud. And so that's really where the next innovation is going to happen. And so I'm pretty excited about the practices are evolving. The platform is becoming more richer. It's becoming more open and more standards-driven, allows us to start to really layer on and take all the experience and capability we build with TaaS and the productivity that is unbelievable productivity that I've seen, right? And what TaaS continues to deliver. But extending that to a Kubernetes world or leveraging the Kubernetes more natively, that is really a huge opportunity for us. I want to go back a little bit too to talk about the evolution of microservices, right, from SOA. When microservices was first coming on the scene, if you will, there was a lot of talk about how microservices is, you know, people were, it's just SOA done. But there's more to it than that. I think the key difference was SOA also was one of those architect enterprise, what Michael, you were saying, at a business services level. The intent was really much more to say, how do I take my, either my legacy application, wrap them up, or start to build these kind of building blocks that led to this whole BPM or workflow.
12:16I also had a technology called Beeple, business process execution language, if you remember, how you wire these things up. So it was much more at a higher level, if you will. And as you said, it was more on process automation and driving those new applications or taking legacy ERP applications and providing that customization layer on top. That was where bulk of the SOA efforts. It was also the next generation integration using well-defined services contracts versus doing it in a more one-off adapter manner, et cetera. So those are the kinds of problem or EAI evolution. That's where it ended up more in the business process automation space, more in terms of, you know, wrapping up capability, right? It didn't really become the way you build your new next generation application. It was how you connect to something that you wanted to integrate with, right? On the other hand, what I saw with Beeple Paths, and by the way, what a surprise when I took this business over, how Spring had evolved. Spring often would utilize this amazing thing that drove the injection model into reality, but it was considered a heavy framework, right? And now I look at Spring Boot, Spring Cloud, and some of the work we're doing around Spring Cloud Gateway or Dataflow. It's really putting the power in the hands of the developer. It's becoming more lighter. It's becoming more productive. And so what was exciting was the PaaS revolution was really about simplifying the life of the developer who wanted to get some basic web application or transactional application out. And so I saw these two parallel evolution. One was more in the integration evolution, if you will, with Sova, and the application development evolution with PaaS. Yeah. And we're now having an interesting gesture which says, okay, what have we learned in the world of public cloud and microservices? How do we now bring the same productivity, the simplicity, the security, the management value into this world, right? Because now I've got a whole bunch of toolkit. I've got 400 piece parts. I've got tremendous power at my hands. But I have to be an amazing expert to pull it together and build one at scale. That's interesting. The, first of all, I haven't thought about Beeple in a long time. I keep trying to remember the name of this book, but there was a book that I read way back then that was like, we all read these books, these breathless books about how awesome the future is going to be because of computers.
14:24And I remember I read one that was about Beeple, like business processing stuff. And it was just going to revolutionize everything for us, which it was, yeah, that was, it was one of those books that I remember reading all the way to the end. And then I realized I have no idea what that actually means I should do now, other than anticipate an awesome future. I think it's interesting to look at the branching of, let's just call it SOA from, I think, what microservices ended up being. And to your point, a lot of SOA ended up being about the XML standards, the WS star, or as people eventually started calling it WS death star. And that, as you were saying, is all about integration and not just, what's the other I want? Being able to talk with each other. Interoperability was a big thing. There you go, exactly. And then I think that was right at the tail end when I was still a developer. And I feel like what the developers were frustrated about is it had very little to do with coding. Like those concerns are more about standards and controls. And it almost seems like I'm reaching for a connection here, but it almost seems like that frustration led to more of microservices thinking, which was, it still is largely about the actual coding and defining the APIs, not so much about the business process. And then, but eventually those two parts, they eventually need to come back together. So if you see the evolution, right? A lot of the code, you know, process SOA companies have become low-code automation companies. What's happening is, you know, there are layers of productivity and layers of granularity, if you want to think about it that way. As an application developer, or if I were now an application architect, responsible for building my next generation e-commerce, my banking app, my prescription platform, et cetera, et cetera. What I want to do is I still want to have all the principles of, you know, modularity, loose coupling, well-defined services contracts. But more and more APIs are becoming critical, not just between how I publish and make myself exposable to the world, but how my two different teams or 20 different teams that have broken this down.
16:27Exposed a set of contractor services. And so you're starting to see in the world of microservices, notion of East-West API contracts between two development teams. My own application is a combination of using somebody else's services and being able to discover what other APIs and services exist in my company's portfolio that I reuse. And so those problems of reuse still exist. Service discovery still exists. Being able to late-bind still exists, right? Being able to deploy and manage and iterate at a component level so I don't have to change the entire system. Can I not just change my part? These ideas of A-B testing where I want to try something new and see if it doesn't work, roll it back. All the things public clouds do at scale. And the DevOps practice we all aspire for, and I say this because not every enterprise has really mastered this yet. That is really the opportunity. Everybody wants to be able to push out code every day. Repave the environment if needed every day so there is no malware sitting up there. Be able to change just their piece without breaking the whole thing. Test this thing called a system. I'll give you a simple example. My old observer is we used to have a massive environment in front of the largest banks running at Oracle because I had to figure out how to debug it. And the only way we could do it was we could do that scale. How do you do this now in a modern cloud world? You don't own the infrastructure, but you're using all these services. So the new problems are starting to emerge around day two operation. And things like observability as a category have emerged because you can't reproduce that problem. You've got to diagnose what happened in the environment itself, and hence you need a lot of observability to know what happened. Because you can't go and become the reproducibles in the lab. Let's get a reproducible done so we can then figure out how to debug it. There's no reproducible. You've got to go get the data from the live environment and make the change in the live environment and deploy it without bringing the system down. So the scale problems, the management problems, the operations problem become even much larger than just the developer productive thing. We tend to get indexed on. So these new systems have to be designed for resilience.
18:29How do you do that? That's a good segue into the next thing that I thought would be interesting to extract from you, so to speak. I think like a lot of us, one of the fun things you get to do, usually it's fun. Sometimes it's not. But one of the fun things you get to do is talk to a lot of the executives and teams at various enterprises and organizations. And I think having that bird's eye view of what everyone does, it allows you to collect a lot of what you were just talking about. And in talking with all these organizations, like what are the common, to put it in a negative way, what are the problems people have now, right? To put it in a more neutral way, what are the management concerns that people have, whether they're new or old? What are the problems they need to solve? So a couple of things, and I'll pick, I've been fortunate enough to be now an executive sponsor to several large banks, just happen to be all financial services, but this problem applies more broadly. So I'm using this just as an example, right? And you're starting to see some kind of either a CTO office or platform office trying to figure out what are the common building blocks that each line of business, CIO and teams need, so that we can pull that back and make it a common platform. In some ways, the principles of SOA were exactly that, right? Build a common thing once, make them available. So from a principles perspective, it follows the same desire to have a set of core components. This notion of pipelines that reflect the CICD DevOps operating model is another thing we're seeing. Can we create these three or four common pipelines by which they reflect the different application patterns and the deployment patterns we need to support? So there's this, on one side, it's about the generalization of providing ready-to-use infrastructure or platforms and decoupling that from the developer who doesn't have to worry about setting up all of this stuff. He just is a user of these pipelines. The second thing we're seeing is having a more curated set of what we call accelerators of some forms. And we've seen this from our experience with Spring. The Spring starters demonstrate a tremendous opportunity to take a whole bunch of curated capability, whether it's images, whether it's blueprints, application patterns, and make it available.
20:39So when a developer starts on a particular type of application type, they have a recommended set of patterns to start with so that they can start to build this new composite application. So one side is really about reducing complexity, removing the concerns from the developer for all the infrastructure concerns, if you will, and making them highly productive. Second one is around this whole DevOps practice, making it mainstream, really creating the art of setting up a centralized or set of pipelines that developers can use. And the third piece is really this application patterns and the curated set of images that they can expose to the developers for productivity. And the fourth for them is really, how do I wire in security into this right from the get-go, right? Because if it's too late, by the time it's gone. So this notion of the secure software supply chain is starting to get a lot more discussion at this topic and top of mind. So those are the kinds of problems. So there are developer productivity, deployment concerns, general security concerns, and then day two operations management concerns. And under management, I'll put observability, put the cost, being able to predict costs and manage it. I think those set of being able to patch and upgrade, right, at scale, like those are the kinds of problems I hear when I talk to customers or challenges that they're trying to deal with in your work. Yeah, one of the first things you were talking about is, we don't really use this phrase very much anymore, but there was a big debate a couple of years ago about like full stack developers. The idea that your application developers would be in charge of everything down to the infrastructure, which was the reality of early cloud stuff. I met one of those ones. I was like, oh, you're a full stack developer. And he was like, what? And similar to what you're saying, as I've talked to organizations over the years, I think one of the major things they struggle with is like, that doesn't actually work, right? It's almost like the question they have is, so how much stuff do I actually want the developers to do aside from the application? That's been the holy grail, right? We've always debated. We want application developers to work on the business logic, the customer experience, et cetera, and give them a palette that they can quickly draw these beautiful pictures or these beautiful applications.
22:48On the other hand, the problem with PaaS typically has been, it's been a hard line. So if you were not able to fit within the jacket, which is where the challenge of low-code, no-code has been, it's great for my own, I'm sure my bias here. It works great for very specialized problems because then you can say for that set of problems, I can provide you a phenomenal developer experience and I can give you very high productivity. As you go further right, you get a lot more flexibility, but now you have to be responsible for wiring the things up. And that line is a fuzzy line, right? And most customers that I speak to are trying to get the largest number of developers highly productive, having to worry the least about infrastructure. And maybe there's 5% or 10% that need to be the sophisticated developers, I'll say, that need to break glass and dive into infrastructure and be those full-stack developers for a set of concerns. And when they do that, they should hopefully create components or services that others can use next time around as part of these accelerators so that not everybody has to go solve for that over and over again. So I think this is going to be an evolution, Michael. We've been at this for 20 years. So when I look back, it's the same set of problems. We just have a richer palette and sometimes more complex palette. Yeah. So we got middleware, Beeple, business logic. I think that these are good phrases and words we can put in the Rosetta Stone for new developers to explain what... Accelerators and starters. Sure. Yeah. Frameworks being more lighter weight, but more in the control so they don't pull in the rest of the world. We love this idea of injection. We like the idea of being more declarative or intent-driven versus imperative. So some of those are the new principles. We still like the domain-driven design where we can start to create a well-defined contract, fully encapsulated set of capability. The fact you can now package your own database as part of that, so you can have your own persistence layer as part of that fully integrated versus having to depend on all things. So those well-defined contracts, I think, are really very critical.
24:48And then have a platform team that gives you a place you can deploy this at scale. And it's part of the pipelines and the platform. You can start to define your policies. And I'm introducing a new concept. I get a new terminology of policies, which says, my policies dictate where this thing gets deployed, who talks to who, who has access to the data that it's speaking to. And more and more, you're going to start to see this become described, both application intent, controls as policies, being brought together through an automated platform that defines where an application runs and what controls we need to put in place. And it has to be done at scale without human intervention. And so it's driven by data, things like observability that allow us to then react and act on things like this. So that's the future we're talking about. Hopefully, I'm not recreating the book that you read and say, OK, I don't know what to do about it. I have to say, one of my favorite things that you said is layers of interoperability and layers of productivity, right? Because to Coté's point, those things sometimes seem antithetical, especially when you bring in standards and stuff. Are we, is that, are we making this, are we fixing this for the future? I'm very bullish. I'm a simple, I'm no longer a technologist as much as I sound one like here. I'm more of a business guy now. And so when I think about the world for me, like Spring and the productivity that Spring and frameworks like Spring offer, Kubernetes is both a platform and a platform of platform, if you will. Standards by which we could package up content, ways we can then have well-defined services that we can engage with. New operating models like serverless, like this isn't, when I look at all that, this is nothing more than a new middleware. It's a platform that runs on any IaaS infrastructure, whether it's VMware or public cloud. And so hinting at where we're going as stands, right? We see an opportunity here to build the kind of next generation application platform, a modern multi-cloud application platform that takes a ubiquity of Kubernetes and containers, brings in the productivity of frameworks and patterns, and brings the DevOps automation of CICD into this kind of holistic platform with strong distributed connectivity, application runtime.
27:02This is a distributed application runtime, so application connectivity, things like service mesh become even more critical. So those concerns are, again, more, when I look at an app server, it took on some concerns, so I didn't have to worry about it. I think the service mesh does something similar around security and app connectivity. I don't have to worry about those things. I can just turn them on or off. And then you start to add API management and API collaborations on top. Now you see the shape of a new platform emerging, right? And I think that platform is what customers need to get all the benefits they're looking for developers while driving the level of kind of guardrails and controls they need to operate at scale across any cloud. So, and cloud is not just a big data center cloud or backend clouds, but more the edge clouds as well. So, to me, cloud is ubiquitous of any location where I can spin up a compute runtime and manage it at scale. And so the world is going to be this internet is the new cloud platform, and we've said that for many years, right? Internet is a new platform. How do you not put a layer or application across that? And what is the infrastructure middleware to unlock that value, right? And I think that's a pretty exciting, bold opportunity. So, bringing a lot of the infrastructure and bringing a lot of the middleware of expertise to bear. Yeah, I know. I remember having those conversations as well many years ago. Awesome. Yeah, and like you were saying, like we said, when you see everything in effect and that productivity goes up and everyone leads a better, I don't know, to make it grandiose, leads a better life because they have less stuff to worry about. Like, it's very rewarding. Well, great. It was good having you on. For this discussion, we'll have to have you back on. Yeah. And yeah, do you have anything you want to point people to? You like promoting your Twitter handle? You have a web blog? Anything like that? Watch out for our big cloud event, end of March, as well as if you haven't looked at Tanzu Advanced, it is the start of this journey of building this new platform. As well as if you're an existing Tanzu application service customer, rest assured, we're going to continue to invest heavily there. And a lot of the work you're leveraging and driving in the industry is the expertise we're trying to capture and bring to the masses.
29:04Thank you again for the opportunity and I'm looking forward to working with you again, Michael, and being on the pod again next time. Yeah. All right. Great. As always, if you listeners want to get the archives, you can go to tanzutalk.com, check them all out. And we'll see everyone next time. Bye-bye. Thanks again, Michael. Thanks. Thanks, Rita. Thanks, Rita.