I frequently give a talk on “what’s the deal with VMware and software development?” Here’s my script/storyboard for one I’m going to give next week.

Sometimes I’m told “don’t make this a vendor talk,” which, as you may recall, dear reader, actually means “don’t be boring.” In this one, I was asked to talk directly to what VMware does for software developers, so you’ll see that.

If you like it, you should come check out the discussion next week, be won’t be just me and I’m looking to forward to learning from my co-talker.

1. Why is application modernization relevant now, what even is it?

• It’s been almost 12 years since that whole “software is eating the world” notion. We all understand that good software helps organizations run better, perform better, and so forth. To be specific, what I think about here is custom written software, the software that you build and run on your own. It becomes the core way your business runs.
• There’s not really much dispute about the need to be good at software now.
• Around 2015 I saw organizations sort of realizing the en mass, us vendors did a good job of spooking them that Google and Tesla were coming from, AirBnB! BOO! This kicked off several years of learning and even building new apps in a new, agile style. You probably remember all the “Labs” that big companies setup and did videos about in three or four years ago.
• It took a couple years, but people learned the modern, product-mindset way of doing software. What does this mean? It means that your “developers” are working very closely with the actual customers/users of the software to continually discover what features their apps need, even what problems need to be solved. The way this looks is that the team includes not only developers, but also a product manager and often a designer. They’re building a product, not delivering on a set of requirements and wireframes (that’s a project). This means that, hopefully, the team is releasing software weekly, at most monthly. This means that, of course, they deliver smaller batches of code than you would every 12 months. But by studying how people are using their software, they’re getting feedback that allows them to learn and improve that software.
• So, for example, one insurance company we work with, Liberty Mutual, had their team follow this pattern when they were building their Australian motorcycle insurance business. Their team studied how the sales people were working and sped up the sign-up process, meaning they could sell more. That’s the whole thing: instead of your software just running the business as is, your software becomes the primary way the business innovates and grows.
• Anyhow, I think what’s happened is that many of the new and easy apps have been done or are being worked on, and now it’s the whole rest of the apps and services that organizations are facing. And what I mean by this, are all the apps that run the existing business and probably are involved in most of the revenue for the organization (or mission/purpose if it’s non-profit oriented, e.g., government). These apps and the services backing them need to be modernized to keep up the “software is eating the world” thing. You see that in surveys a lot where many executives say that tech debt, legacy software - whatever you want to call it - is holding them back from releasing new apps, putting new features in: 76% of executives said they are too invested in legacy applications to change .
• Put another way, most organizations are now scaling transformation to their entire organization, and this brings them up against older software and older software practices. And, sure, there’s also a lot of organizations who haven’t even started!
• There’s at least two things that get modernized:
• First, as the name says, the actual applications, and services they rely on. Older app frameworks, services, and infrastructure usually aren’t up for the task of weekly releases, scaling to the type of usage businesses have, and, sadly, there’s also just a lot of forgotten lore about older apps.
• Second, the practices, as you can imagine, change a lot. Shifting from developers just implementing what they’re told to and sort of throwing it over the wall to someone else, those developers now share responsibility for the business. That seems bonkers if you’re operating in the traditional way.

2) What VMware is working on here, as a reflection of the modern application “stack.”

• When it comes to apps, you’re always thinking in terms of “stacks,” like a good hamburger.
• To support a modern way of doing apps, you need a mostly new stack, and I think there’s three major parts to it: the infrastructure (usually based on cloud and kubernetes, now-a-days), the app platform (not just the programming language and framework, but all of the tools that surround the process of building and running apps), and the practices people follow (put broadly, the “culture”).
• Handily, we at VMware have just such a stack!
• This is a simplified illustration of that stack. Frankly, it doesn’t emphasis the third part, practices, as much as I’d like, but whatever (I’ll cover that a bit more later):
• There’s the “raw infrastructure” at the bottom, either your friendly old VMware stack, public cloud, and sometimes “edge” (which is sort of an up for grabs term at the moment). The key thing here is that most organizations have all of it, or at least want all those types of infrastructure. This is what “multi-cloud” means, you’re not stuck with just one “cloud” or one type of infrastructure.
• Now, what’s genuinely new in this stack is the middle layer, kubernetes. What kubernetes is doing is standardizing what that raw infrastructure looks like and standardizing how its used, configured, and run. So, instead of having many different ways to configure a server or deploy an application, there’s one (more or less) way of doing it. This is also true when it comes to how those apps are run in production, scale, etc. This removes variation and toil. It makes “multi-cloud” possible and economical, and gives you more options
• With that standard layer in place, you get a whole new ecosystem of software tools, frameworks, and services that you can pick from. Most of these are all servicing the same basic needs any app has, but they’re fit onto kubernetes. What’s more key here is thinking about this part of the burger/stack as a “platform,” as collection of all the tools, programming frameworks, and services needed to not only run the apps, but build them. So, as you can see here, there’s build tools, for example.
• From a developers perspective, the goal of this stack is to remove as much toil around managing the platform, coming up with how to do configuration and release management, and even monitoring and troubleshooting apps. You can think of it as making as much as possible self-service. But, also, what you’re doing is trying to give developers templates and guardrails so that they don’t mess up, for example, security.
• Anyhow, we have a great stack, all the way down, that you can put in place that will get you that modern app dev experience.
• Now, I mentioned the practices. We have a long history (through the Pivotal acquisition) of crafting a set of agile, product-driven practices that both developers and operations people follow to be “modern.” Here they are:
• As with the tech burger/stack, any component on its own is kind of cool, but it’s putting them all together and integrating them that actually matters. The next key thing is to actually follow them! I joke about that, but what I’ve found is that most people know these practices, but they don’t actually follow all of them.
• So far, this can all sound very “developer” oriented, but the way you do operations is equally important and involves a lot of changes.
• In the same way that you developers take on a product mindset, working more closely with customers/users, operations people treat developers as their customers. You product manage the platform you’re providing, continually discovering what’s needed, experimenting with it, and refining it. This is a huge shift from how most infrastructure people operate.
• These so called “platform engineers” also think about the supporting tools developers use, build pipelines and services. The reason for this is illustrated well by “DevSecOps.” A lot of what makes DevSecOps what it is is building security into the tools and process that application developers use instead of relying on the developers to follow policy. You see, you’re building “security as a product” for the developers, not imposing it on them. That same type of thinking goes to other parts of the stack.
• Anyhow, the point is: to support doing apps in a different, better way, you need a new stack of technology, and a new “meat stack,” the way people work.
• That’s the stack of stuff we have at VMware Tanzu.

3. What inf/VI admin types can do next, should be thinking about if they want to do all this.

• OK, so now the most important part. You actually need to start doing something. That sounds kind of silly, but I see most people just sort of never getting around to changing. Everyone agrees that there’s new, better ways of doing software, that it needs to happen…and then years go by with not much happening.
• So, how can you get started?
• First, I’d spend a little bit of time (but only a little!) tracking down what exactly is in your portfolio. You probably know all the applications and services you have, at least the ones that are important. You need to pick a handful of these to start working on. They should be both technically “easy,” but also “real” to the business, something that is strongly connected to day-to-day operations.
• You pick these apps, and you set aside around 6 to 10 weeks to modernize them. We have a process we call SWIFT that does this analysis and some tools to automate a lot of the data collection needed. Possible visual:
• What you’re doing here is, sure, modernizing an actual app, but you’re learning what that means for your organization, what needs to change, what barriers you have, etc.
• Your developers will learn a lot about a new way of working, and your operations people will quickly identify processes that need to be automated and secured.
• What you’re doing here is optimizing the entire, end-to-end process of how your business evolves through its software:
• The shocking thing you find with these little apps at first is that very few people know everything that goes into getting software out the door. I find that the problems are all in the arrows, the spaces between the boxes/chevrons - the hand-offs.
• Until you start doing actual work, you won’t find all the problems - you can’t do a bunch of up-front analysis, or even PoC’s, you need to do real work - hence selecting those initial apps.
• And, mostly, it’s the platform engineering team that will do a lot of this fixing and platform building.
• There are a some things that you can predict and start doing. These are validated, more or less, by the fact that every organization encounters them. The chief one is security and, more broadly, “governance.” Security is going to be a problem instantly, so you should start working on that. This means getting security people on your team, understanding each other’s needs and dreams, and both of you “building” this platform…again, you’re thinking of the “developers” as customers. There’s some reference architectures for securing kubernetes out there, I’ve been liking this one from the US Department of Defense of late because it’s short and thoughtful .
• Now, product wise, it’s really easy to start messing around with this stuff. If you’re running vSphere now, it’s likely you can just get kubernetes up and running to start looking at that. You can also get our open source kubernetes distro and app dev platform, the Tanzu Community Edition for free at tanzucommunityedition.io. And, more recently, if you’re using Docker Desktop, you can install it from there. And, of course, you can always ask Softcat for help. Getting all this stuff up and running for the initial poking around used to be very tedious, but in the past two years it’s gotten much better.

End/Q&A

• Well, that’s a lot, probably.
• Also, we haven’t really talked about the struggles people have: the hard work of improvement is getting over the hurdles to change. That’s a lot of what I get interested in and am always excited to learn about.
• We have some time to take questions about whatever you’re interested in. And, I’d like to leave with this list of common problems, blockers, etc. people have when they’re modernizing how they do software. Have any of you encountered these? Do you have some experience to share?
•