One of the incredible privileges of this job is that you regularly get to hang out with people that have driven the state of the art in tech forward. In the world of DevOps, Adam Jacob and Luke Kanies are two such examples, being the creators of Chef and Puppet respectively. Last week Kanies spoke at our Monktoberfest 2018 conference. Today I had lunch with Jacob at Chef’s London community summit.
One thing that really strongly me in conversations with both of them was the deep pragmatism, and indeed pessimism about how far we have actually travelled as an industry in terms of improving how we manage infrastructure. Matt Asay recently quoted Kanies saying DevOps practices are “barely present around the market”, and “as a result we’re going to be another decade or two before anything interesting happens.” [italics mine]
In the cloud native ecosystem we’re currently seeing a bit of magical thinking, where containers are going to solve all known IT problems. Jacob said he and Kanies, having been in the management trenches for 20 years, “the real world” as he put it, had a different perspective than some of these new market entrants.
Jacobs has a point – the idea that just because Google created an open source version of its container orchestration layer – Kubernetes – that it’s applicable to general purpose IT doesn’t really make sense. Let’s face it, very few organisations face Google’s scale challenges. How many enterprises have the kind of infrastructure homogeneity and control Google does? Zero. The boundary between cloud native, and traditional enterprise IT, is a really interesting point of friction in the industry right now. We have come round to the idea that hybrid cloud is indeed a thing, so now the question becomes how are we going to run and manage it? Do we really need to re-platform all of our apps? Ain’t going to happen. Take Cloud Foundry, for example, which is strongly opinionated, originally conceived as a Heroku for enterprise IT to run so-called Twelve Factor apps. Quick reminder:
One codebase tracked in revision control, many deploys
Explicitly declare and isolate dependencies
Store config in the environment
Treat backing services as attached resources
Strictly separate build and run stages
Execute the app as one or more stateless processes
Export services via port binding
Scale out via the process model
Maximize robustness with fast startup and graceful shutdown
Keep development, staging, and production as similar as possible
Treat logs as event streams
Run admin/management tasks as one-off processes
Let’s be honest – a vanishingly small set of enterprise IT customers is going to deeply understand this list, let alone develop apps this way. Cloud Foundry was not intended to run traditional enterprise workloads, but rather to demand a new style of writing and running applications.
One of the key questions for bridging the new and old worlds is persistent storage. How, for example, do you manage an app that uses both Cloud Foundry and SAP HANA (which expects a very particular storage model, and set up of physical disc for persistence). Kubernetes, meanwhile, can be extended to cover other persistent models, but they’re going to then only be manageable in the context of Kubernetes.
Jacobs argues Habitat can be used to manage this tension between hybrid 12Factor/traditional infrastructures because it manages packages and dependencies for you. Of course that’s the promise of more runtime-oriented platforms and platforms (as a Service) – but the difference is that Habitat is designed so that you can deploy an application consistently in multiple formats and runtime environments: Docker, Kubernetes, Cloud Foundry, Mesosphere, VMs, bare metal, and more. Chef announced support for Cloud Foundry and Kubernetes just yesterday – good write up here by friend of RedMonk Michael Ducy.
While the industry was over-rotating to everything is public cloud (15 Ways To Tell It’s Not Cloud Computing) it might have seemed like overkill to worry about platform support. Let the cloud manage this stuff. Then containers came along, and we over-rotated there. But in a world where on-prem is still a thing, people are going to make decisions like using bare metal (in say high frequency trading). And disc isn’t going to suddenly disappear. Jacobs wants to position Habitat as a bridge between the newer runtimes and formats and all the other stuff, particular where persistence is a problem. For all the excitement about containers there is definitely a market for the configuration as code DevOps models pioneered by Chef and Puppet. Red Hat’s acquisition of Ansible is paying dividends as sales tick along nicely because customers have all kinds of non cloud native stuff to manage, and automation never goes out of fashion. Also enterprises are always going to do custom things, no matter how strong the vendor opinion is. As Jacob would put it “that’s why we can’t have nice things”. But it is reality.
I am Cloud Foundry’s European summit in Basel tomorrow, and Docker Con in Copenhagen tomorrow, so I will try and flesh out some of these thoughts, with a view to better understanding the emerging hybrid – 12Factor/traditional landscape.
disclosure: Cloud Foundry Foundation and Docker are clients, but all opinions expressed are mine.
No Comments