Day Two Cloud 093: Don’t Get Your Whittling Badge
Ethan and I had the privilege to talk to Kit Colbert and Dormain Drewitz from VMware for this episode of Day Two Cloud. Kit has been on several Tech Field Day presentations, and I have always found him insightful and plain spoken. He doesn’t try to dress things up in marketing fluff and is open to criticism about VMware and its position in the market. I’ve been following Dormain on Twitter for a while now, and I’ve always found her content to be equally insightful and a bit humorous.
The episode is a sponsored VMware episode, so obviously we are going to talk about VMware, but that was not the central focus of the chat. What we really focused on was app modernization. For some this is a well-trod topic; however, I think there are still plenty of folks on the Ops side that have been heads-down focused on putting out fires and may be missing the larger trends at work. The core principle here is what it means for an application to modernize, and it does not mean taking a mainframe monolith and magically transforming it into a distributed 12-factor app running on Kubernetes. It could mean that, but it doesn’t have to mean that.
Dormain brought up the idea of a Goldilocks zone when it comes to app modernization; just enough change to meet business requirements without adding unnecessary complexity. As always, it’s the intersection of business needs and operational requirements that drive application design. Kit offered up three levels of abstraction at which you might interface with the application, including the hardware, platform, and management layers. There is also a process layer for the Dev and Ops crowd which determines how the application is maintained and deployed.
Just because an application is written in COBOL and running on a mainframe doesn’t mean that the software lifecycle of the application can’t be modernized. Getting the source code into a modern VCS, creating a deployment pipeline, and adding automated tests and validation is something any app can benefit from whether you deploy a new version every six months or every six hours. I would say that it is especially important that you automate tasks you only do every six months, as you’ll probably forget what you did last time when six months rolls around again. Better to have your app deployment in a pipeline with all the proper actions and tasks codified.
Where does VMware come into all this? It’s about the consistency of tooling. Now I’m not going to say that VMware products have to be your go-to when it comes to DevOps tooling. There are a lot of choices out there, and you need to pick tools that both Devs and Ops are familiar with and meet their needs. Maybe that’s VMware’s Tanzu suite of products, or it could be Red Hat OpenShift, or it could be the HashiCorp stack with Jenkins. I don’t know what makes the most sense for you and wouldn’t presume to. I can say that folks like Kit and Dormain are helping steer the VMware ship to dev friendly waters, making their new product portfolio worth a look.