There’s tell that some people just look at containers as a cheaper way to virtualize, eschewing the fancy-lad “cloud-native stuff.” We discuss that idea, plus “the enterprise cloud wars,” and also our feel that Slack is actually a really good tool and company.
The wider Cloud Native ecosystem is, however, a very disparate and confused place. We anticipate a significant level of consolidation over the next twelve to eighteen months with some clear winners emerging. The emergence of several opinionated distributions of Kubernetes is hardly a surprise and this space will expand a little further before settling down.
A round-up of all sorts of container stacks, and some advice on what to do:
Therefore, the key lessons learned from this event (from developer’s perspective): Do not focus on developing code for the container under the hood. Care instead about the business logic. Implement your microservices in a vendor agnostic way.
Do not make the same fault as we all did with J2EE / Java EE where all vendors used the same standard specifications, but still offered many vendor-dependent features and “added value” in their specific “standard implementation”. Migration, i.e. deployment to another Java EE application server was a lot of efforts (re-development, testing, …); sometimes a complete re-write was easier and faster.
There’s a lot of fragmentation in container land now. This is what Linux must have felt like back in the late 90s.
Our advice at Pivotal, of course, is to focus on using Spring and other services towards the top of the stack for that layer of lock-in protection.
Eventually, you have to decide how your open source software is going to make money, and your partners probably won’t like it. That’s what the dust-up around Docker is this week, it seems to us. We also talk briefly about VMware’s big conference this week, and rumors of HPE selling off it’s Software group to private equity.
Check out the full show notes for links to the recommendations, conferences, and tech news items we didn’t get to cover: https://cote.io/sdt71
I have a discount code for Operability.IO, September 19th and 20th in London. I hear good things about this conference; check out their talks from last year. It has a good list of speakers, including our very own Casey West. You can 10% off registration if you use the code COTEMEMOOIO16.
Nippers – “Nippers learn about safety at the beach. They learn about dangers such as rocks, and animals (e.g. the blue-ringed octopus), and also about surf conditions, such as rip currents, sandbars, and waves. Older Nippers also learn some basic first aid and may also learn CPR when they reach the age of 13.”
Docker Inc. doesn’t want to be a commoditized building block From a Red Hat person: “The conflict started to escalate earlier this summer, when Docker Inc used its controlling position to push Swarm, it’s own clone of Kubernetes-style container orchestration, into the core Docker project, putting the basic container runtime in a conflict with a notable part of its ecosystem. Docker Inc. then went on to essentially accuse Red Hat of forking Docker – at the Red Hat Summit no less. After that, Docker Inc’s Solomon Hykes came out strongly against the efforts to standardize the container runtime in OCI – an initiative his company co-founded.”
A fight over where to draw the line between free/open/commodified and costs/proprietary/competitive: “And while I personally consider the orchestration layer the key to the container paradigm, the right approach here is to keep the orchestration separate from the core container runtime standardization. This avoids conflicts between different layers of the container runtime: we can agree on the common container package format, transport, and execution model without limiting choice between e.g. Kubernetes, Mesos, Swarm.”
Don’t bring a pistol to a bazooka fight. Enterprises love RHEL – have you ever tried to sell Ubuntu into organizations? It’s like what selling NT must have been like.
The Docker forking hoopla is providing an interesting example, in realtime, of how open communities figure out monetization.
#RealTalk: Open communities are not immune to C.R.E.A.M.
One of the most important decisions an open source community makes is where and how it will make money. I always liked Eclipse’s take because they’re mega clear on this topic; the ASF plays this goofy game where they try really hard to pretend they don’t need to answer the question, which itself is an answer, resulting in only the occasional quagmire; Linux has a weird situation where RedHat figured out This One Cool Trick to circumvent the anti-commercial leanings of the GPL; MySQL has a weird dual licensing model that I still don’t fully grasp the strategic implications of; RIP Sun.
The role of standards plays another defining role when it comes to monetization. Think of Java/J(2)EE, vs .Net, vs PHP (a standard-less standard?), vs HTML and WS-*. vs, the IETF/ISOC RFC-scape that defines how the internet works. While not always, by far, standards are often used tactically to lesson the commercial value (or zero it out completely) of any given component “lower” in the stack, pushing the money “up” the stack to the software that implements, uses, or manages the standard. Think of how HMTL itself is “of no value” (and was strategically pushed that way early on), but that the entire SaaS market is something like a $37.7bn market, part of the overall $90.3bn that, arguably, uses HTMLas one of the core technologies in the stack, at the UI layer, (along with native mobile apps. now).
The dynamics of how open source, standards, and the closed source around it are defined and who “controls” them are one of the key strategic processes in infrastructure software.
The Docker ecosystem is sorting out monetization
Right now, you can see this process in action in the Docker ecosystem. Product management decisions at Docker, Inc. are forcing the community to wrestle with how ecosystem members will make money, including Docker Inc. itself.
By “ecosystem,” I mean “all the people and companies that are involved in coding up Docker and/or selling Docker-based products and services.” Actual end-users play a role, of course, but historically don’t have as much power as we’d like at this stage of an open communities formation.
End-users have to vote with their feet and, if they have one, wallets – whether wearing expensive loafers (enterprise) or cracked sandals (paying with nothing but the pride of ubiquity) – which, by definition, is hard to do until a monetization strategy is figured out, or completely lumped all together.
Looking just at the “vendors,” then, each ecosystem member is trying to define which layers of the “stack”‘will be open, and thus, free, and which layers will be closed, and thus, charged for. Intermixed with this line drawing is determining who has control over features and standards (at which level) and, as a result, the creation of viable business models around Docker.
Naturally, Docker, Inc. wants as big slice of that pie as possible. The creator of any open technology has to spend a lot of nail-biting time essentially deciding how much money and market-share it wants to give up to others, even competitors. “What’s in it for me?” other vendors in the ecosystem are asking…and Docker Inc.’s answer is usually either some strategic shoe-gazing or a pretty straight forwardly the reply “less than you’d like.”
And while I personally consider the orchestration layer the key to the container paradigm, the right approach here is to keep the orchestration separate from the core container runtime standardization. This avoids conflicts between different layers of the container runtime: we can agree on the common container package format, transport, and execution model without limiting choice between e.g. Kubernetes, Mesos, Swarm.
We saw similar dynamics – though by no means open source – in the virtualization market. VMware started with the atomic unit of the hypervisor (remember when we were obsessed with that component in the stack and people used that word a lot?), allowing the ecosystem to build out management on-top of that “lower” unit.
Then, as VMware looked to grow it’s TAM, revenue, and, thus, share price and market-cap, it expanded upward into management. At this point, VMware is a, more or less, the complete suite (or “solution” as we used to call it) of software you need for virtualization. E.g., they use phrases like “Software Defined Datacenter” rather than “virtualization,” indicative of the intended full-scope of their product strategy. (I’m no storage expert, but I think storage and maybe networking?is the last thing VMware hasn’t “won” hands down.)
“What, you don’t like money?”
All of this is important because over the next 10-15 years, we’re talking about a lot of money. The market window for “virtualization” is open and wildcatters are sniffing on the wafting smell the money flitting through. Well, unless AWS and Azure just snatches it all up, or the likes of Google decides to zero the market.
We used to debate the VMware to Docker Inc. comparison and competitive angle a lot. There was some odious reaction to the idea that Docker Inc. was all about slipping in a taking over VMware’s C.R.E.A.M. At one point, that was plausible from a criss-cross applesauce state of the market, but now it’s pretty clear that, at least from an i-banker spreadsheet’s perspective, VMware’s TAM is the number your doinking around with.
Looking at it from a “that giant sucking sound” perspective, most all of the members in the Docker ecosystem will be in a zero-sum position if Docker Inc moves, and wins, the upper management layers. Hence, you see them fighting tooth-and-nail to make sure Docker Inc is, from their perspective, kept in their place.
Good overview of DockerCon announcements, including a new “manifest” type thing:
At DockerCon 2016, held in Seattle, the latest 1.12 beta version of Docker Engine was announced that includes the integration of Docker Swarm to provide container orchestration. Additional announcement included: the Docker for Mac and Windows has now been made public; a private beta for Docker for AWS and Azure has been opened; and the release of a ‘DAB’ file format for packaging artifacts.
Is anyone minding the business side of these container orchestration plays? That’s the main topic we discuss after doing over recent Docker announcements. We then discuss the state of tech journalism and throw out a free business plan for left-ish fried chicken slinging.
If you chose a provider, you do not get to just point your finger at them in the post mortem and say it’s their fault. You chose them, it’s on you. It’s tacky to blame the software or the service, and besides your customers don’t give a shit whose “fault” it is.
Update: I’d wanted to put a TAM in – the money Docker and containers are going after, this from Gartner:
While matching it to virtualization is a poor match (you’d probably also need some systems management and maybe even appdev numbers in there), I think looking at the current x86 virtualization TAM is as good as you’re going to get with a conservative approach.
My reasoning is that if “the market” is willing to pay this much for virtualization now, that’s the kind of foot-print and allocation we should start looking at for “containers” (over more of a 10 year time span, probably).