If the last 10 years in enterprise IT felt like a blur, it's probably because the industry churned through new technologies, terminology, and acronyms at breakneck speed: "cloud," "IaaS," "PaaS," SaaS," "NoSQL," "big data," "software-defined," "microservices," "DevOps," and "containers," to name just a few. Thankfully, though, the dust has settled a bit, and we've more or less figured out what works. That makes now the time and place where the rubber meets the road, where applications must adapt to these new patterns and technology standards.
In this episode of Cloud Native in 15 Minutes, James Watters—CTO of VMware's Modern Application Platforms Business Unit (MAPBU)—shares insights from his journey over the past decade, which began with helping launch the first iteration of the Cloud Foundry platform-as-a-service offering and now involves driving VMware's new Kubernetes-centric Tanzu business. However, it's less a conversation about products, and more a conversation about how the various shifts in IT and application architectures—including IaaS, PaaS, microservices, open source, and big data—led us to where we are today, and about how organizations should get started thinking about modernizing their applications using these new standards.
Here are a few quotes from the episode, where Watters talks through the early days of Cloud Foundry and microservices; Kafka and Kubernetes moving into the mainstream; and the value of "1-factor" applications.
What the original Cloud Foundry (circa 2011) got right
"I think there were two things that it did that were still indicative of the future that it got right. . . . One is it really had a super highway for the developer to get code to production. It had the 'cf push' experience, where you just gave it an app artifact and it did everything that you needed to get that running on n number of servers for you. . . .
"But then the second magic thing it had . . . is it had a declarative container engine underneath that. And we had a magic command, 'cf scale,' and the demo used to be: 'cf push' app running and then 'cf scale' times a thousand, and suddenly you had a thousand instances of your app running. And that was about 30 or 40 seconds. And in 2011, 2012, no one had ever seen container automation like that.
"And so those were the two super powers that it had back in the day. But I think we were just curious, like, 'OK so these are, these are new powers, but how do we make a market for that? How do we go to market with that?' That was all very wide open, but you can see the potential of what's now become the developer experience on containers, as well as declarative automation. They were there early on."
Why microservices define the decade in distributed systems
"I remember being in the room when we were working on Cloud Foundry early on, and everyone was like, 'Look, we could have a much better developer experience and we can be so much more efficient operating this, if we could only find a way of standardizing more of how each application works and communicates with each other over a network.' We were essentially articulating microservices as a trend. It hadn't really been named that yet.
"And I had an acquaintance with Adrian Cockcroft and used to go watch all of his talks, when Netflix was the first really at-scale adopter of Amazon, and went Amazon-native. And Adrian's group at the time, building on what you might call now 'rudimentary IaaS,' they really had to invent this whole scaffolding for microservices and to make that pattern work on top of IaaS. And so they built tools for service discovery because there was no longer multicast on Amazon at the time. They built circuit breakers because any part of the infrastructure was expected to be unreliable at a given time, and they did a whole series of innovations around these patterns.
"It also allowed them to scale their engineering teams, and I think that's when the lights went on for me. Because not only was this a new trend in application patterns, it was a new trend in organizational patterns. And a lot of enterprise companies were going to, I thought, adopt that pattern because they were already operating at scale and how do you get more engineering horsepower into your customers' . . . hands faster and faster? . . .
"So I really look at microservices patterns as the most important trend that happened over the last 10 years in terms of driving real demand to buy systems like this, that are both developer-friendly and declarative."
How Kafka brings everything together
"I'd say Kafka has been one of those magical connective technologies between the world of data engineering . . . and modern applications. When you look at 2013, it was sort of the all-in on Hadoop era, as well, before the microservices trend kicked off. But as I went and used some of those technologies, it wasn't easy for an application developer to go turn that into an application or to connect that to an application . . MapReduce was this very batch-based system, the way it thought about things. And applications tend to want to respond more on a per-event basis or more real time, to make it engaging for users and to orchestrate across a lot of services.
"And so when you started to see Kafka being this linking technology across things like Spark, as well as into microservices and application patterns, you start to go, 'Oh, wow, I can start to really think of at least starting off with a lot of my data in something like Kafka, and then I could query it in different ways, or I could use those events to enrich applications.' . . .
"I've literally been in banks' data centers where they walked me to the right and, 'That's the application clusters,' and they walked me far to the left and, 'That's our big data cluster.' I didn't realize how extreme it was. They're completely different teams . . . Conway's Law to the extreme.
"But now you have the central Kafka integration point where every team can feed off that. And that's a big change in terms of how we think about enterprise architecture. Because at the end of the day, enterprises are about integrating thousands of applications together. They're not about building one app."
When Kubernetes APIs meet vSphere
"I think [Project] Pacific is a really a really fascinating moment in time, because it really starts to directly incorporate those distributed system APIs right into vSphere. And back to when I joined VMware, that was sort of my hope—I wouldn't call it a vision—but the hope that this company I was joining would both do the very traditional IT workflows of basically offering a virtual server at a time, as well as starting to get into some of those distributed-system declarative-programming models that you could see even back in early days at places like Facebook. And so Pacific now is a really amazing moment in time for VMware because they've formally launched a product with vSphere 7 that is the best of both of those worlds, that can do both of those things.
"And I think it starts to rationalize the Kubernetes market in an important way. When it came out . . . one CIO that I was talking to said, 'All the time, there's a platform team for every component that comes out.' But now I think we can say, 'You don't have to go buy and integrate Kubernetes. That just comes into the infrastructure that you have.' . . .
". . . As along-traveled person in this journey, it's great to see the very core of vSphere clients starting to shift to that declarative model and to the Kubernetes APIs right in vSphere."
Do you even have a 1-factor application?
"There are different ways of coming at this trend change. One is, 'I have some new capabilities I want to build. I have relative greenfield or I have a strong appetite to do a real business-level refactoring of my apps.' And that's where things like Spring Boot and Spring Cloud and Kafka and this general move to a microservices architecture—or what you might call the next generation of distributed architectures—is really important to get right and make sure that you have some standards there.
". . . But maybe the interesting thing is what do you do with all the apps that you just want to evolve, [that] you're not ready for a full refactor on. And I've been asking companies, 'How many apps do you have that are one factor, at least?' And they kind of laugh. They're like, 'Well, what's the one factor?' Because sometimes enterprises say, 'Hey, we're not ready to make everything 12 factors.' So I try to reduce it down to just a simple question, and the one factor is: 'Hey, can you even restart this application predictably? Because shifting to declarative automation and scheduling, you might want to be able to restart that app.'
"And so I think there is this application-first movement of either at least be able to do some basic automation of even your monolithic applications, or a full refactor of them. But I think everyone recognizes that the app is the scarce thing right now. We've made Kubernetes more and more ubiquitous—it's in Project Pacific, it's in public clouds—I think the question now is how quickly all the application portfolios adapt to that."
Cloud Native in 15 Minutes publishes bi-weekly (or at least it tries to), and you can find it on most of your favorite apps and platforms, including:
Learn more about what we talk about in this podcast
About the AuthorMore Content by Derrick Harris