The Undying Death of JEE - Gartner, App Servers, and Cloud-Native (Ep. 47)

Episode 34 · 50:31 · SRT · archive.org · all Tanzu Talk

So as often happens when it rains here, I want to seek your counsel, Richard, because you live in Seattle, if I remember, where it rains every day. And everyone's running around with those, you know, fancy rain slickers, maybe from Columbia, REI, Patagonia here and there for people who like to shell out the cash. So it's been rainy here. And so my question is, what are the considerations that you put into footwear when it's moist so much? Like what, I mean, I don't even know where to start, but there must be some thinking like you don't wear those duck boots all the time, right? So there must be something that you do. Yeah, I can't really sport galoshes very well either. So yeah, depending on footwear, it's a good question. The other thing I've learned in Seattle is you actually don't use an umbrella unless it hits a biblical level of rain. So I became, I was shown as a newcomer very quickly when I broke out the umbrella and got laughed at in public. So you do have to be ready for the rain. We are at the floor. The footwear matters in terms of sneakers, often still. Sometimes rubber shoes, though. People do have those in their closets. Really? Rubber shoes. So only Noah's umbrella, rubber shoes, maybe. So you got that covered. Well, that's good. Well, we have a guest for this episode. Why don't you introduce yourself, guest? Hello, my name is guest, frequently referred to as Peter Humphrey. How are you, Michael Coté? Just fine. Now, since you're on here, I'll give you a non sequitur question, which isn't totally non sequitur. What, you know, what's up with the spelling of your name? Is that German? It is a slight Dutch tribute to my mom's father who passed when she was quite young. Now, is that Dutch like New England Dutch, which is short for Deutsch, which is German, or Dutch like Holland Dutch, like the orange people? It is not German. It is not. It is definitely Holland Dutch. If you've ever noticed, I look like that little dude on the front of the paint boy can, the Dutch white paint boy can. That's good stuff. Oh, yeah. That's good stuff. Have you dressed up like him before with that haircut that he has? Is that called a page boy haircut?

I forget. It is. It is, exactly. I try to sport that look as often as possible. That's wonderful. Well, we have a few little news items to go over per usual. And then we have Peter here because we're going to talk about the wonderful worldwide of Java Enterprise stuff, which is, you know, I don't have any connection to page boy haircuts there. So, and, you know, feel free to tell us what you think of these news items, Peter. So, first of, I noticed this too. I forget when this was. Actually, it's dated in the URL, which is nice. I guess it was announced at the beginning of January. But Atlassian, renowned for being both Australian and having supposedly no sales force, which I always think is interesting. Good claim there. But they bought Trello. So, Trello of the Jeff Atwood coding whore founding fame and Joel Spolsky, Mr. Leaky Abstraction. And every coder needs their own office. So, I think the purchase price was some umpteen hundreds of millions of dollars, which is interesting. Yeah, it was around, I think it was around $450, and I think their revenue was around $10. So, that was a nice multiplier. Ooh. Yeah. Good to be at Trello, huh? Yeah. Well, first of all, they're like, they're a SaaS company. And they're basically, they're like a Kanban board, right? Or I should say, they're like a Kanban toolkit. Now, I'm sure there's always like the uppercase Kanban and the lowercase Kanban people. Anything related to lean manufacturing always has sort of like a, sort of like an orthodox versus whatever you want to do sort of split. But, you know, it seems like of all the Kanban-y things out there, it's the most general purpose, flexible one. You basically have as many swim lanes as you want, which is to say vertical. If you imagine a screen, you got vertical towers there, things that go from top to bottom.

And then you have some concept of cards, which you can move beyond these pillars. And you can name the pillars whatever you want and put whatever you want on cards. But you can also color them and assign them to people. So, I guess the most basic usage, other than making your own version of Pinterest, which, you know, is sort of like the scourge of the craft world. You ever try to search for something and you come up with this Pinterest stuff? And it's like, you keep clicking on it and you're like, no, I want the picture. I want the picture. And the next thing you know, you've like uploaded all your photos somewhere. It's just, it's terrible. They need to solve that. Anyhow. I actually feel your pain on that one. I have an eight-year-old daughter. I get Pinterest stuff all the time. It's just, it used to be useful. You used to be able to go there and just get pictures. But now, I don't know what they do. They probably have some JavaScript that does some random linking to itself. And it's just very confusing. Anyhow. Yeah. On the Trello front. Oh, thanks for bringing us back. I was getting a little lost there. You know, I've seen a lot of companies copying that feel. So, GitHub Enterprise kind of added some of the visual card kind of swim lane thing. Some other tools have as well. I think that some of this came from, if you read some of the material about this, is these companies are looking for more ways to adopt more than just technical users. And so, heck, I use Trello to plan my move up to Washington. Like, there's other tools, usages for this besides just, you know, sprint boards and things like that. Although, our marketing team does use Trello to plan our software or our marketing sprints. And, of course, Pivotal has Pivotal Tracker. We love that for actual software release planning. But some of these tools have started to blur the line, like Trello. So, either way, it's cool to see them find a good home. I think there's some skepticism that Atlassian will keep them, leave them alone and help them continue to do their thing. But, hey, let's see. Yeah, it is basically project management tracking. And if I remember, Jira does that. But more from the Bugzilla classic way. I haven't actually seen Jira in a long time. And, like you're saying, as Peter will attest to, we've screwed around with Trello here and there. I remember I once subjected it on the team that I was on, which was a delightful failed experiment in organization.

But, I don't know. I think I even tried to use it for my wedding tour. Although, I think it was a little before that when I got married. And my wife is not interested in digitally optimizing her to-do list. It just never works. I can't get mine to even use a shared Google calendar. So, you know, consider yourself lucky. I like Trello. I've gotten used to it. I think it's just enough project management. It's lightweight enough. It doesn't really get in your way. And it doesn't, you know, yeah, it doesn't seem to want to take over your life. I like it a lot. Yeah. That's interesting. I guess I should know better, but I never really. I guess they did take investment from some of these. What else do you see out there in the news sphere, Mr. Coté? Well, there's, let's see. What have we put in here? The one thing that I mostly put in here, there's a couple of things I wanted to go over. I think my former analyst firm, 451, came out with a market sizing for containers. And if I remember, it's something, and I bring this up just because I know people will be interested in this. It's in the context of their overall, they call it cloud enabling technologies or CET, which I forget what the market size is there. But for containers, they put it at like $730 or $40 million, which is interesting. But like that's a lot of revenue for containers. I think they have some estimates for like Docker revenue. And then I would guess like, I mean, the only people that have revenue would be like VMware with Photon stuff and then Red Hat, I think. And then somehow we're listed in there, which is a little, we're listed in the overall private cloud way with what seems like an accurate amount of revenue. But we're listed in the container part, which is a little odd because we don't necessarily make money directly off of containers. So I'm not sure how they came up with it, which is all to say it's a fun sort of swag at what's sloshing around the container market. But it's good to look at with a little bit of, I don't know, more wet finger in the wind and precise way to land on Mars correctly.

That's probably the right comparison. I think you're trying to put things into buckets to show momentum, but I don't even know if you have to manufacture it. There is momentum there, but are people making money? I think that's a fair question to ask. You know, Pivotal just finished up our greatest year. I think at this point we're making more than all straight up container and config management vendors combined. So there's just a question of how much is of that as revenue as straight up containers or platforms or whatever. But hey, it's growing. And as you say, that's the direction we're going. And I think also more broadly, like the 451 is one of the only people that does what I would call a proper private cloud market sizing. The way they categorize it and do it. And like it's actually very hard to find private cloud market sizing out there. Like the – as we'll talk about later, there's a category of software that Gartner has called cloud-enabled application platforms. Or as I like to call it, creep. And that's right. It's very Nixonian. And anyhow, you know, I mean, that's a slice of it. But it's hard. The 451 one includes like OpenStack. And I'm sure there's a few dollars for Eucalyptus or something. And then VMware things. So that's one of the better market shares for that. Well, what else did you find out there, Richard? You collected the other ones. So I'm handing it off to you. Yeah, I listed something on there. You know, there's a story the last couple weeks around all these MongoDB instances that have gotten hacked and then held for ransom. And so the reason this came about is MongoDB doesn't have some default security on. So if you put these on internet-facing networks, somebody who simply has the IP address of the database can access it with no password. And then they were taking the data and holding it for ransom. So, you know, there was a lot of hand-wringing, of course, about this. And I think it just continues to drive home, though. You have to be careful with self-service data solutions. And sometimes trying to solve the problem quickly isn't solving it right. So, you know, what is the right thing to do there? Sure. In a pivotal world, it's a Bosch-enabled service for databases and things.

That you get a hardened database and still self-service. You know, in other places, if you're using cloud database-to-service, you're better covered. But, you know, developers like to solve problems. That's awesome. But this is, I think, a byproduct of doing that, is that sometimes you can be left with less than optimistic security. Yeah. With no password on it, that seems like a bad idea. I mean, I'm no security expert, but it doesn't seem like you should do that. Rule number one of databases. Have a password? That isn't P-A-S-S-W-0-R-E-T. Yeah, that was reminding me of the, you know, you used to get a router or whatever you want to call it, an access point. And it would often have a password. I don't know. I should probably go change the password on mine. It's just got some default gobbledygook that came with it. I was wondering what the tweet storm is about in the last few days with all these companies saying, hey, you know, review your default security policy settings. I saw an Elastic tweet about that. Now I understand. I didn't realize that came from Mongo. Yeah, it's pretty scary stuff. So it should be a good wake-up call for people to, again, focus on self-service, but responsible self-service. So the other thing I added was just today, actually, Oracle's been doing a roadshow talking about some of their cloud stuff. And they are also doing their investment in cloud IaaS expansion. Again, somehow they were growing two times as fast as Amazon, which seems a little strange. But nonetheless, ignoring any usual Oracle big claims, you know, they are expanding this year. And, you know, they like to put themselves as one of the top three or four clouds at this point. So I think it'll be interesting to see that continued fight for the second tier winner. Is that Microsoft and Google? Or does Oracle kind of get themselves into there? Will they be able to earn the credibility? But they're investing, and that's always good to see if you're an Oracle customer. Yeah, I can use a Trumpian rhetorical trick here and say, like, you know, I totally could say that growth from zero is massive. But I'm not going to say that.

They're great guys. They're great. Love them. Tremendous. That's right. So then you have your paper is finally nearing completion. Yeah. Speaking of growth from zero. Yeah. So I did this paper last year. Just like it was more like a series of blogs that we put into a PDF. That's a great function of the WordPress Pro. Make yourself look fancy. Right click. But anyways, so I more collected together stuff. I've been talking with people from the last year and while writing it. And it's about 50 pages of just enough to make you wish it was 200 pages. So I pretty much have all of that done written. And I'm trying to – I'll probably have our PDF people look at it. There was some publisher I was talking about who was vaguely interested in it, but I don't think they're interested in it. So hopefully we'll have that out. And I'll put a link to it in our show notes if you want to look at it in its Google Docs form. I mean if you're someone who needs to have like really wide margins and lots of fancy color in order to think something's good, you should wait until there's a PDF version of it because it's just Google Docs. And also on that note, there's some dancing around with our publishing stuff. So I think I'll put the show notes for this episode on my blog just to make sure they're out. And so I'll make a note of this at the end if I remember. But I'm going to put it at cote.io slash conversations. I don't know what number this is. Just go to conversations and you'll find it. But you've got to go look at my blog to find it. And I'll put it in the little show notes that we'll be able to publish with. So with that jangly overview there. So the thing we wanted to talk about this week is I think – I forget when it was published. A couple months ago in December. Yeah. Time flies. Anyways, but the two of the folks at Gardner who covered this space, Ann Thomas and another fellow whose name escapes me embarrassingly,

they wrote a piece that was basically – it was exciting, like bush banging to get people all riled up about it. And it was basically going over – I mean I'll give my summary of it and then hand it over to you guys to summarize better. But essentially it was noting that the – the way I would summarize it is that the pace of innovation, so to speak, of traditional Java application servers hasn't been keeping up enough with demands for new types of programming that is cloud native. They like to put a hyphen in it, which is great for them. So, you know, basically there's a new style of development that people should shift over to. And in the opinion of the two writers, your traditional Java application servers are not going to cut the mustard. Maybe one day they will. But at the moment they're not, which they sort of – they kind of back-solve to the idea that if you're doing what would be called JEE or used to be J2EE, Enterprise Java Applications, you should probably not be doing that if you want to do cloud native things. And then they also kind of back-solve to like, therefore, if you're doing your digital whatnot, your digital transformation stuff, Enterprise Java is not your best bet. And they give some recommendations. And I think they have a – you know, there's not a lot of supporting evidence, which in a thing like this you don't really have. But they do do revenue and usage to show a decline in WebSphere and WebLogic, which I think is interesting. And then over a three-year time, an increase in usage and revenue – or maybe it's just revenue – but an increase in revenue of non-traditional Java enterprise things. And I think just to sum up, I think the other sort of points of proof that you would have is one gives the benefit of the doubt or, you know, many people don't. But one gives the benefit of an out to a Gardner analyst that this also reflects conversations they've had with vendors about their own roadmaps and also conversations with end users about what they want to do. So the whole reason that – other than it being, you know, interesting, like we also licensed it so you can get a copy of it because it's a pretty good endorsement of the pivotal way of life.

But because it was available to read, it's very exciting. Normally, people can't read this stuff. So there's actually a lot of controversial stuff going on behind the analyst paywall that people just like don't encounter. But because it was available to read, there was like a whole like, you know, speaking of rain, a storm of whatnot going on about it. So it seems like a good summary. And then I keep saying finally. But I think one of the better – there's a good summary that's one of the more professionally put together info queue pieces just because it has so many sources and everything about people talking about it and summarizing it. And even from the loyal opposition of our – one of our dear leaders, Ian Andrews, kind of going over our belief about kind of our response to all of that. So there's a good piece summarizing it. And since Peter operates in this space, it seemed like it would be fun to talk about it. Thank you. So we'll – yeah. So I wanted to chat with Peter about some of the kind of the spring piece of that. We'll go over that in a moment. I think that – I think it was a good summary. There was a good summary at the top that kind of said, look, the trend from this market guide – it's a market guide for App Platform. This is something Gartner creates themselves. It's not commissioned. It's not something that any vendor sponsors. But they said, look, there should be a strategy to deal with the obsolete nature of Java EE, that you should be using application paths. That's kind of the modern middleware. Regardless of whether those other things are okay, modern middleware is now kind of in a platform as a service layer. And then arguably one of the most interesting points that I think Pivotal actually liked more than the other ones was you should be designing all your apps to be cloud native. Whether they're running in the cloud or not, that is the paradigm you should be pursuing for all of your sort of systems. And I think that's a good call to action for leaders who might think that they can just do certain things in a modern way and other things not. So, you know, with all that, Peter, I don't know if you want to give us a quick 30-second. First of all, who the heck are you and what do you do in the Spring side? How will people maybe recognize your name? Sure. Yeah, thanks, Richard. I appreciate it. And Coté, yeah, thank you very much. I've been waiting for this report for a long time in some ways because I think it just kind of acknowledges what I've seen as reality.

I work for Richard in product marketing on the Spring Cloud Foundry team. And before coming to Pivotal, I worked at BEA Systems for WebLogic for many years, from like 2001 to 2008, when we got acquired by Oracle and then stayed on for a few years, about four years, doing WebLogic server, Java EE development tool product marketing. So, you know, I saw the revenue numbers where the bodies are buried. You know, I've kind of seen the whole wave. I mean, that's where I grew up, really, technologically speaking. Yeah, and you're – so now you're kind of our Spring guy among many other things, of course. So, I mean, tell us a little bit about how Spring gets developed and shipped out today. I mean, this is something that has taken off a lot, and if you pay any attention to Spring releases, they're seemingly getting shipped all the time. There's milestones, there's releases, there's different projects. It's not a monolithic release once a year or anything. Yeah. So tell us a little bit about how the Spring – you know, get a little peek behind the curtain, how Spring hits the market. Sure. Yeah, totally. So there's a – I'd say at the high level, there's a fast lane and a slow lane. If you want the fast lane, we release milestones that are usually our feature-bearing out to the developer community so people can get the bits, you know, as soon as humanly possible, right? Zero weight and try to, you know, continuously deliver stuff as much as possible. So we will host feature-bearing milestones, then we'll move into a release candidate phase to get community feedback and, you know, signal to folks, hey, this is good enough that we think it's worth you kicking the tires for five or ten minutes to give us some feedback. Yeah, and then eventually things will go GA status, and those bits also get hosted at Maven Central or I think it's J Center for Gradle users. But if you want things like milestone builds or nightly builds even from our CI pipelines, you know, we have a separate repo for that that's not Maven Central. We host our own version of Maven Central and Artifactory. So that's kind of the fast lane, and all the projects iterate independently, right? There's lots of projects.

Oh, yeah, yes. One thing Spring does not suffer from is the lack of projects. That's certainly true. And the nice thing is, though, that they really can iterate independently, and sort of the main trunk of the tree and the main dependency is the Spring framework, which is your core application context and version of control container. On the slow lane, Spring IO platform, so we'll do a slower release site. Prices actually enjoy that slower pace, and they're going to want to pick things up once a year. You know, if you're still kind of in that three-tier monolithic world, that's often the cadence of things, every six months, once a year. So every six months, once a year kind of cadence, we do release something called Spring IO platform, where there'll be a big bang release train of all of the projects in Springdom, and they've been compatibility tested to work with each other, as well as the metric ton of third-party open source that we do testing with. And you can find information about that online on the Spring IO platform page. But so, yeah, the short version is there's a fast lane and a slow lane for people who work at different paces. Awesome. Yeah. You know, one of the things that I guess I look forward to, and you surprise me as much as you do everyone at this company, once a month when you share the Maven download numbers about Spring Boot. And so it's a good way for us to get a sense of the growth of the project, and it's not a perfect metric, but it's something, right? And it demonstrates growth. So I guess the question is, tell me a little bit about the growth of Spring Boots and which of the projects, because there are lots of projects, are you seeing more hockey stick growth than others? Right. Yeah, I mean, certainly the one that blows them all away is the Spring Framework, right? I mean, that's the core base of the stack. Yeah, Spring Boot is sort of an alternative to Spring Framework at that level. It's sort of the base of the stack. All the other projects in the ecosystem build on top of it. It used to be a truism, you know, issues with Maven numbers aside, right? We know that it's not perfect. The number gets inflated by CI builds, but we don't report on Gradle numbers, and there's all kinds of issues with it.

But you know what? At least it's an apples-to-apples compare every month, and the trend line is what matters. So, you know, certainly Spring Framework has blown away everything in terms of download numbers. But aside from that, Spring Security has always, always and always been the number two project in the ecosystem, which we always, I always took to mean an indicator of, hey, folks are actually going to production with this stuff, right? Because they're going to, you know, they need to secure it and put on some controls. So, you know, lately Spring Boot has actually eclipsed Spring Security in terms of total number of downloads. So it is now the number two ecosystem project, which makes sense if you think about it, because it's going to grow to kind of fit the headroom that Spring Framework has. Yeah. Right? But looking within the ecosystem itself, security is definitely, you know, almost always on top in terms of the number of projects, followed by quickly by Spring Cloud and Spring Data, which are coming up fast. I'm not sure which one's beating out which one this month, but Spring Data has been a perennial high downloader for many years. But what I think is really surprising is I have never seen a Spring project come up the current as quickly as Spring Cloud in terms of the downloads. It is already at, like, a million maven downloads a month plus. And that puts it in, like, the top three, top four. Wow. A lot of that's config server. I think we've talked about right now. Yeah. Yep. Exactly. A lot of that, I think, is the popularity of config server. And then just the popularity of microservice architecture in general, I think, is really putting a lot of air into that. Awesome. And people looking to build distributed systems at the app level. Absolutely. So, you know, I wanted to get y'all's take, especially with your knowing where the stink of all the rotting bodies are thing, Peter, like of the kind of, like, poofy pants reaction that all this got. And it seems like, as often happens, it's sort of like there's a pretty big, deep ditch of nuance where people can, like, dive into and kind of, like, Rorschach their way into, like, however they want to interpret this stuff. So, I think the, so it seems to me that, like, if I were to distill down what the report is saying, I mean, I said it, and I shouldn't say report.

It's more of, like, an opinion piece. But what it's saying is that, and I summarized this already, is that, like, so there's a new way of doing development. And the way, if you were just to get the stock, like, JEE stuff, it's not really going to support that. And it's not going to be your best bit for doing it. And then, on the other side, you have the fantastically named people who are, like, the guardians of JEE, which I guess, you know, sort of tells you what their response is going to be. Right. And their interpretation when they go down into that mired ditch is, like, well, they're saying JEE is dead and that we might as well go delete it all. And that's obviously demonstrably false. Because, as they point out, like, there's all these things, even in the, you know, you just sort of catalog the momentum behind. I guess what's traditionally been, at least in a straw person kind of way, like one of the main competitors of JEE, but as I'm about to say, all, many and many, if not all, of these JEE frameworks are often used in all of, in enterprise uses of Java. Which is to say, you wouldn't just go delete all this Java E stuff, there's just new ways of using it and new ways of doing things. And it seems like that sort of nuance, which has always existed in the Java enterprise world, right? It's always been sort of the fact that whether you're 100% using JEE or just using the bits and pieces that you want, like, both of those things are totally normal ways of doing things. And more of, I mean, I forget who it was, but one of the responses that summarized it well is I think, and it wouldn't have been that interesting of, well, it would have been interesting, but for a different reason, is more pointing out, like, it's probably not a great idea to just use WebSphere and WebLogic. Like, I mean, to, like, I think that's kind of the thrust of the report. And instead, there's this new way of doing development that's probably a better way of going about doing things. So, that's a bunch of statements, but I mean, like, am I wrong?

It was about a little over 10 years since I actually programmed in Java, but, like, hasn't it always been this way? Like, it's always been the case that JEE is really slow, and there's always, like, in the JCP, there's always a bunch of, like, vendor stink stuff. Going on that's always annoying, and it's lagging. And it's just, like, I feel like this is more a description of what's always been going on in the Java enterprise world than sort of, like, some gigantic thing to freak out about. It's been going on since 2004. I mean, when I was at WebLogic, part of what kept the success and part of what made it be the default choice at the time, right? I mean, back then, it was Sun, Oracle Database, WebLogic Server. You know, that was your default web stack. That was how you got off client server, man. That's how you got to the internet, right? And, you know, they've been, since Spring came out in 2004, you know, a lot of the ISVs that we were partnering with at the time, you know, they said, well, see ya. We don't need you anymore. We've got Apache Tomcat now, and we can get all the Java EE features on top of Tomcat. We, you know, Spring decoupled Java EE feature set from a Java EE server and allowed you to just run it on a servlet engine, where Spring Boot takes it one level further and decouples Java EE and then a whole lot of other stuff that Java EE doesn't even address. decouples that from the servlet engine and just says, hey, all I need is a JVM. That's it, right? So there's this constant trend of sort of less infrastructure to boot up before, pardon the pun, to boot up before you can get to work. And, I mean, that's been happening since 2004. So it's not a new trend. I think what they're calling out, though, is that Oracle and IBM, you know, the best practice at the time for many years was to spackle over the revenue losses by, counting the revenue numbers and bundling the revenue numbers from layered products on top of the application server. In Oracle's case, there's things like Suite or Soa Suite or other things that were required WebLogic as a runtime environment, but nobody was really using WebLogic as a platform for custom app dev.

They were just using the app that it ran in, right? Right. And because Oracle actually did a fairly credible job of taking WebLogic and integrating it across their middleware portfolio. They have a long and glorious history of throwing out their middleware stack even before I joined on in 2008. But, yeah, so not a new trend. I think what they're just calling is that, wow, you know, SaaS, cloud, other things are eroding those top-level products from IBM and Oracle enough that they can no longer obscure the core app server revenue loss. Does that make sense? Yeah, yeah, yeah. No, I think the way you bundle together your app dev stack is always – it's not as clear-cut as, like, Atlassian, for example, which has distinct product SKUs and they sell like that. I mean, it's such is the nature of a solution sort of sale, which, you know, back when I was an analyst, very annoying and tedious, especially our buddy's son would never break out their software revenue. Always made it very difficult to figure out what's going on. Yeah, I'm sure it's super irritating for analysts. Yeah, exactly. And, you know, maybe this is comeuppance, right? That's right. Yeah, a little bit. And this comes up in cloud, too, as Microsoft doesn't make out their cloud numbers, and Amazon does now. But so, I mean, we're probably doing this again with cloud. But, you know, to that point, Peter, so I assume that this market guy didn't surprise you when this came out. So, I mean, this was something that, you know, Forrester said, why are you still using classic Java app servers six years ago? I mean, that was a blog post they had six years ago. Redmonk talks about this. Yeah. So, I mean, was this a hot take? No. I mean, you know, one of the Google engineers had a hilarious tweet about, you know, when you're sort of getting up in arms about Gartner being a little too progressive and forward-looking, you know, in their reports, it's time to sit down and think about what the heck you're saying. So, definitely not a hot take. I think they're just acknowledging what I just said in terms of it's starting to show up in their revenue numbers now, and they can't obscure it anymore.

And, therefore, it gives the analyst something to, you know, chew on. And they've been, you know, the trend in the Java EE community has been to continually prune the scope of the API and repackage it into ever smaller scope to kind of start shedding off what's become irrelevant over the course of a decade. And there's still things that are certainly relevant in Java EE. And even Gartner points out at the end of that report, right, there's still quite a lot of revenue over there, right? But it's just they're calling the – they're signaling the shift. They're just saying that things are, you know, things are headed in a – unquestionably headed in a new direction. So, man, it's also – yeah, please, go ahead. I was going to say, so this is a little bit like asking the fox to describe how the hen conveniently located itself in its mouth. But, like, what's the deal with, like, oracles, like, I don't know, digging in their heels and, like, weirdness about the agenda? Like, if I remember back in, like – I shouldn't say if I remember because I went and reread this stuff. Back in July, they were like, ah, we're going to delay something. And then there was some stink and then they weren't going to delay something or something. Like, it seems like – it seems like almost going back to, like, back when it was Hudson instead of Jenkins. Like, oracles never quite figured out, like, open community management. And, like – and again, what with the weird fox metaphor. But, like, what's been – like, all the way up to the present, like, what's their relationship with something like Java? Like, what do you think their motivations are? Totally, yeah. You know, I think it's – for them, you know, certainly their middleware business was predicated on it, right? You know, a good chunk of their middleware business. A lot of other things, if you look at – I think it was called Fusion was the announcement at the time, Oracle's Fusion middleware. And then, you know, Thomas Curran and I think at the time it was Ted Farrell had hatched a plan to rewrite Oracle apps, which is a huge moneymaker for that. Huge moneymaker. And write that all in ADF.

And all of ADF and JDeveloper is, in fact, in – wait for it – Java, right? So, there's definitely a long-term, you know, investment protection thing for them. And I think also, you know, when they bought Sun, they got MySQL. You know, they got a bunch of other great things out of that acquisition. So, you know, I think it was long-term investment protection for them. But the thing is, with Java EE specifically, you know, I think what that Gartner report points out is that there's more going on in 2016 and 2017 than JVM. And, you know, their – Oracle's investment is going into their cloud services, right? They're not – they can't afford to invest in something like Java EE because it's not making them any money and hasn't been since around 2005. You know, their layered products certainly make money, but those are, I think, what the report is calling out, finally starting to decline because of SaaS, because of cloud. You know, and they're just – you know, and like I said, the trend and the Java EE specs themselves have been shrinking. You had something called Java EE Web Profiler introduced a number of years ago. What was that? It was pruning a bunch of Java EE and making a smaller scope of Java EE APIs. I mean, I think it was originally around 33 JSRs or 33 APIs, and even nonstandard efforts like the micro profile from Red Hat. You know, I think right now they're talking about single-digit numbers of APIs like CDI, JAX-RS, Servlet, a few other things. I mean, that's what it's come down to, right? You know, those are the parts that are still relevant. Ironically, those are the parts that Spring Framework takes dependency on, things like Servlet that are super ubiquitous. But, yeah, Oracle's investment, they are – you know, they've got to catch up a lot on the cloud, and they are hell-bent on doing so, and that's where all of their engineering effort is going. So, I just see it as they just literally can't afford to do it all, and they've got to make business decisions, and Java EE is getting the short stick. So, who would you say – like I said, I'm like 11 years out of date, although nominally I followed this stuff when I was an analyst, so I guess I knew what was going on then.

But, like, who would you say are the big Java community leaders nowadays? Like, you know, whether it's commercial or not commercial, like what companies and people would you name? Yeah, I mean, revenue aside, you know, if you count by revenue, obviously it's IBM and Oracle. But if you look at thought leadership and innovation, you know, it's – the people that have been getting it done in the Java EE community are really this – I think what they call the gang of four. You know, it's IBM Liberty, a company called Pyara, I think, which is like a glass fish distro, if memory serves. Wildfly Swarm from Red Hat slash JBoss and an open source project called TommyE. And those are the folks that are sort of innovating outside the spec and getting it done. They're doing, funny enough, exactly what Spring has been doing since 2004, innovating outside the spec and getting it done. You know, so, yeah. You know, they just – yeah, they're, you know, they're just – they're stuck out innovating outside the spec. And they're doing their best, but, you know, it's a committee-based process. And, you know, at a time of disruptive innovation like we're experiencing now where the whole stack is up for grabs, there is no standard option by definition. You know, people are just – there's so much white space right now that people are just – you know, they're looking for an option, right? That's why opinionated solutions are so popular these days because it's like, great, you have a frigging opinion. You've got a stack that's integrated. I love you, right? You're an option, you're a viable option, yay, right? So, yeah. Well, and the spring adoption trends have been pretty clear, especially spring boot adoption trends. I mean, one of the – as we think about the developers who are using this, so as we get past the, you know, vendor inside baseball of how to prioritize, if I'm a developer and I'm an enterprise, they can have what to do. Part of the market guide said you should have a plan today to figure out what to do with your more obsolete JE stuff. You'd be thinking about, you know, is JavaE right for my cloud-native apps? They say no, pretty straightforward. But more importantly, what's an enterprise to do here? Should they be thinking about containerizing their existing stuff?

Should they be thinking about lifting and shifting? You know, sure. I mean, Pivotal spends a lot of time helping companies modernize onto something like Spring Boot. But, you know, Peter, as you're thinking about the Fortune 500 company that comes in going, gosh, half my estate is JavaE. What am I supposed to do? What is some good advice that you've seen now from Gartner and others for helping modernize here? So, actually, I owe a lot of my insights to Rohit Kalipur and Larry Dino's team who's out there doing this every day, Pivotal Service folks that are out there in the trenches. And that's where I've gotten some of my – a good chunk of my insights. But, you know, I think at the highest level, you know, you're faced with a – you can re-platform – you can kind of freeze things in place. And in some cases, you can dockerize them if it's an application, if it's a JavaE application that isn't particularly revenue-generating, particularly business-critical, right? Maybe just let it run, right? And, you know, kind of freeze it, neutralize it. You're not going to iterate on it much. You're not going to maintain it much. Just if there's no business imperative to rewrite it, you're not going to get the funding for that project eternally anyway. So just figure out a way to neutralize it and kind of freeze it in time, right, for as long as you can. That's a viable strategy until, you know, Oracle's end-of-life support terms for certain things run out. But I think, you know, that's one place where Oracle does well in terms of, you know, revenue, right, with the Computer Associates model of kind of cleaning up and milking everything you can out of, you know, long-term, slow-moving type of applications. So that's one strategy. Second is, you know, if we're talking about in the category of existing apps, Richard, which I think is what you said, right? Existing apps because new apps is sort of a different answer. I mean, new apps, yeah, they're pretty clear on where you should go. But, yeah, keep looking at existing portfolios. Right. And then so there's a process that we go through called replatforming. That's an option for, you know, hey, this app, it's not super business critical. It's not the core of my business. But, you know, I can't freeze it in time anymore.

The end-of-life policy for the various vendors involved in the mix have come up in my face. I'm forced to move for one of those reasons or some other reason that's business-related, ideally, right, and not because you got painted into a corner. But the replatforming is sort of like, let's take a look at this Java EE application. And I think if you can paint a little X and Y axis in your mind, you know, the more Java EE nonstandard vendor-specific or extended Java EE features you use, the harder it is to kind of replatform, the more you kind of stuck with the sort of trend that started happening around 2004, which was stick with servlets and use Java EE servers as more of a web app container as opposed to things like transactions or messaging and stuff like that. Although, actually, that's not fair. There's still a lot of messaging usage. But, you know, the deeper you got into Java EE, the more difficult it can be to replatform. But if you're one of those many people that in the last decade has kind of stuck with it more as the web container, you're probably in decent shape, and you just need to be looking for certain 12-factor violations, things like local disk usage dependencies, you know, stateful instances of stateful stuff, stateful session beans, in-memory session persistence that maybe you've set to go to the disk, Java transactions where you're using the file system, et cetera. That kind of stuff can be replatformed, and you remove those 12-factor violations. The absolute minimum of them just to get to work on the cloud, right? So that's like, I'm going to invest the least amount of effort. I'm going to get the least amount of return. But that's maybe what's appropriate for your particular class of business app that's not super mission critical, but, geez, I can't leave it sitting alone anymore to die like a mainframe app. And maybe that's the first step to getting them onto APaaS in Gardner terms, an application platform. Like, now they run nicely on Cloud Foundry. They run on other places, even if they're not yet optimized. Right. It can run, period.

It's not taking advantage of. It's not exploiting. It's not designed for. And that's what Gardner is saying in terms of develop net new stuff this way. In fact, I would add a little nuance to that. I think monolithic applications, maybe not necessarily three-tiered, but monolithic applications certainly can run on the cloud as long as they've been, you know, as long as those 12-factor violations have been engineered out. And it's certainly appropriate for applications to begin life as a monolith. It's just, in fact, there's great talks. I don't know, Coté, have you ever run across this guy, Simon Brown? He's a frequent speaker. He has an amazing talk on monolith, on modular monoliths. And it's like, if you're going to get started with a net new app today, design your monolith, but design it with future decomposition in mind. You know, use domain-driven design concepts. That's a great way to start. If it's a business-critical application, you might just want to, you know, skip right past Go, do not collect $200, and go right to Cloud Native and start designing microservice. It's like, I think everyone knows that the modular monolith nature of the Power Rangers robot always defeats the single-unit monster. Now, they never learn that it's always going to become giant at the end, so why don't you just become giant at the beginning and stomp it? Maybe there's some energy crisis, but, you know, it's more modular. Everything we needed to know, we learned in kindergarten. It's true, Coté. It really is. You know, I had a, as you were going over that, I was thinking, and there's no, as much, many things I ramble on about here, there's no easy solution to it. But it seems like there's this constant tension that I, for lack of a better phrase, an architect of a project has to go through of thinking about which standard you're writing to. And you were kind of pointing out, like, I mean, you know, JE and Java is a standard, so you could write your application to those standards. But then the problem becomes when a new standard comes about, like, I would argue, I don't know, coding to Linux? Like, I don't know if that's how people would characterize Docker, but, like, let's say coding to the internet, you know, HTTP and to the way that Linux mostly works.

Like, then it's, like, as we were going over, it starts to be kind of annoying to make, like, 12-factor apps if you've, like, done all this JEE stuff. And, you know, I think back when Ruby and LAMP were coming about, it was kind of like the Linux-y internet threat to the standard of JEE. But I guess it does come, and again, it's a difficult thing to figure out. But as this write-up kind of addresses, you know, this write-up saying, like, you should do things in a cloud-native way, which, you know, once you take some Pepsid AC or whichever one and get your sort of, like, fire in the belly about JEE taken care of, it is good to ask the question, well, what does that mean? What is a cloud-native thing? And, you know, I think it gets to this muddled thing I'm going over, which is it's a different set of norms and conventions that you follow to write your – design your application so that it's more portable to some extent. And, you know, another sort of annoying phrase that people use this is, like, lock-in, which, as any good vendor such as ourselves would do, it's always a question of, like, well, you're always going to have lock-in. You just need to choose who your lock-in is, right? Right. And where. Exactly. And so, I mean, I think that's, you know, and I've gotten some requests from people or been involved in conversations about, like, we need to better define what cloud-native is. And I think that's more of what's interesting over the next couple of years is to say, whatever this new set of conventions and norms is, what does that look like for various communities? And how should people be thinking about selecting it for new applications or moving things over? I mean, as you mentioned, you know, we had Rohit on a while ago to talk about moving from traditional, you know, ESBs to different ones and stuff like that. And I think that's more of what's meaty and interesting is how to update things and how to fit to the new norms that exist. Yeah. I always love reading about our case studies to take. As you say, there's some apps that you just kind of freeze in place. There's non-mission critical things that you do some light refactoring on. And then there's the, this thing powers our business. We need to modernize it. And we love those as well when it comes into how do we make these more flexible, continuously

delivered. The last question I wanted to ask you, Peter, was, you know, part of the almost comical back and forth on like the InfoQ article, which at some point I enjoy it. It's such insanity. Oh, I'm out of popcorn. I don't have any left in my house. But I mean, I think to be clear, like, hey, we love Java. Yeah. You know, we depend on Java E for a number of things. So I guess I want to close on a positive note of I think we're all friends here. I think we're just trying to look at how are we helping customers deliver better software faster? And the consensus is seeming to be around cloud native patterns, flexible application platforms. And that's just a little incompatible with some of the legacy tool set. Doesn't mean it wasn't great in its time. It doesn't mean you couldn't even use it now. It's just not meant for it. Exactly. So I mean, in your mind, are we all friends here? Yeah, totally. I mean, you know, we collaborate quite a bit with the Java E JSR expert groups around APIs like JPA. I think they even kind of there was a proposal on the table for them to do an MVC JSR. You know, they were consulting with Rawson, who's the lead for Spring MVC. And, you know, so things like JPA, JMX, Servlet, obviously, Servlet being a lot of the base of the stack of the Java ecosystem for the last decade. I mean, those are places where we certainly collaborate with. I mean, we've inspired them on a number of things, certainly. But, I mean, stuff like JPA is mature. It's solid. You know, it's, you know, you can argue whether or not you like having object-relational mapping as a technology. But, I mean, they've done a pretty good job with some of these core specs. They're not going anywhere, to your point. You know, people are probably going to still use them today. It's just being able to use them in a modular way and divorce them from the all-sing, all-dancing container, you know, that makes things a little bit more flexible, right? We need things to be self-contained in the cloud today, not, you know, hey, I need to lay out this whole runtime that my app has to somehow fit all these sockets as a developer programmer. And it's like, nope, I'm just going to bundle the dependencies I need in with the app, get

a nice self-contained little unit, and then I can CI script that until the cows come home and push it around and make it a mutable infrastructure, you know, as opposed to pets, not cattle, right? That's right. All right. And, yeah, I think just the interesting idea, you know, is with immutable infrastructure, and you mentioned Docker. You know, a lot of people are saying, hey, well, can't I just Dockerize Java EE? And it's like, well, you know, the second you lay down an EE server as immutable infrastructure, you're sort of violating the whole concept of an app server. I mean, the whole idea of an app server was, hey, I have a mutable process on top of the JVM. I'm going to deploy stuff to it. I'm going to undeploy to it. I'm going to change configuration. It's hold state, right? Whereas Dockerizing a non-cluster Java EE app server, sure, it just boots up and runs the same work file over and over and over again. That's its only job in life. I mean, what's the point of an app server then? It starts to look like a framework, a bunch of libraries on disk, which smells remarkably like a framework and not an app server. So, you know, just Dockerizing Java EE doesn't get you cloud native either. But, well, listen, thanks so much for having us on. I think it's an exciting time, and, you know, we look forward to continuing to collaborate with the Java EE folks on those specs and, you know, see that they're not going anywhere anytime soon. Make it spring awesome. How do we, I'm going to steal the Coté line. How do we find you on the interwebs? You can find me at Peter Humphrey with that pie eater, Dutch spelling. Thanks, Coté. Or I'm anonymously known as Spring Central in my web alter ego. Very good. Yeah. I never realized it spells pie eater. That's fantastic. Pie eater. Showed you what I pay attention to. I got a box of pens for my ninth birthday from my aunt and uncle that said this pen did belong to Dieter Humphrey because clearly I had to, you know, I misspelled my own name and it was actually the German Dieter. Huh. Yeah. Yeah. Yeah. Well, I mean, I mean, as, as I'm fond of saying with, with a funny name like mine, you can, you can imagine I'm obsessed with other curious names.

Anyhow. Yeah. You know, I, just as one last thing before I totally wrap up, I think, I think this is also, you know, we're kind of fond of commenting on industry analysts. This is another, because you can access the report and all the commentary around it. It's a good, it's a good study in industry analystness, if you will, uh, sort of all over the board. So, uh, so that's fun as well. Anyhow, uh, this is always, yeah, sure. This is always has been a Pivotal Conversations. Like I said earlier, we're, we're like updating our CMS system or something like that. Uh, but I'm going to put the show notes for this since there will be, uh, many of them at cote.io slash conversations 47. Um, and maybe I'll put future ones there. We'll see. But, uh, it would be great if you, if you liked this episode or even if you didn't dislike it, especially if you didn't dislike it, listen very carefully and do the following. Not what you may like. It'd be good if you subscribe to it when in whatever, uh, overcast or iTunes, that's, that's always the best thing to do. And it's also good if you, uh, if you want to tell your friends about it or promote it, do some word of mouth stuff. And it'd be great if you went and left to review and in iTunes or hit that little recommend thing in, uh, overcast. I don't really know what any of those do, but. And it's always gratifying to see, uh, that there's more people listening and responding to this as delightful as it is for Richard and I just to sort of like, uh, talk at each other and discuss rubber boots. It's always good to know that there's other people out there as well. So we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.