Software Defined Talk: Docker is just cheap VMware, right?

cover-art-088-2

Our new episode is up, from this past Friday:

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.

Listen directly, subscribe to the podcast feed, and go check out the full show notes, which has a web player as well.

The crowded cloud native space

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.

Link

The Container Landscape, choosing what to do now

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.

Link

071: Unbreakable Docker, or, elephants, er, like other elephants – Software Defined Talk

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

Listen above, subscribe to the feed (or iTunes), or download the MP3 directly.

With Brandon Whichard, Matt Ray, and Coté.

SPONSOR

Show notes

  • 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.”

Can someone explain this “Docker forking” hoopla?

  • Coté’s write-up.
  • 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.”
  • Re: that episode where we discuss Docker ecosystem challenges: “Yet on a regular basis, Red Hat patches that enable valid requirements from Red Hat customer use cases get shut down as it seems for the simple reason that they don’t fit into Docker Inc’s business strategy.”
  • 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.

VMware hybrid cloud solutionaring

This Week in Tech Private Equity…

BONUS LINKS! Not covered in podcast.

Spaces vs. Tabs

Recommendations

Deciding where the Docker ecosystem will make money

I drink your milkshake

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.”

As a side note, while I don’t follow Docker, Inc. as an analyst any more (so I’m not mega up-to-date), it seems like the company consistently puts the end-users first. They’re looking to play the Tron role in this ecosystem most valiantly. This role doesn’t, really, conflict at all with elbowing for the biggest slice of the pie.

chart_vendors-focused-on-deployment-platforms-orchestration-developer-tools-2
From The New Stack’s Docker & Container Ecosystem research

Similar to Docker Inc’s incentives to maintain as much control as possible, the “not-Docker, Inc.” members of the ecosystem want to commoditize/open the lower levels of the stack (the “core”), and leave the upper layers as the point of commoditization. This is the easiest, probably most consistently successful business model for infrastructure software: sell proprietary software that manages the “lower,” usually low cost to free, layers in the stack. From this perspective, not-Docker, Inc. members want to fence in the core Docker engine and app packaging scheme as the “atomic unit” of the Docker ecosystem. Then, the not-Docker, Inc.’s want to keep the management layer above that atomic unit for themselves to commercialize (here “orchestration,” configuration management, and the usual systems management stuff) . But, of course, Docker Inc. is all like “nope! That’s my bag o’ cash.”

As explained by one of those ecosystem vendors, who works at Red Hat:

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?”

Screenshot 2016-09-01 12.09.56.png
From one of Donnie’s recent presentations.

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.

Figuring out that TAM and market size gives you a model for any given ecosystem member’s potential take over the next 10 years. That’s a tricky exercise, though, because the technology stack and market are being re-defined. You’ve got the core virtualization and container technology, then the management layer, and depending on if you’re one of the mega-tech vendors that does software and hardware, you’ve got actual server, storage, and networking revenue that’s dragged by new spend on “containers,” and then you’ve got the bogie of whatever the “PaaS-that-we-shall-not-call-PaaS” market becomes (disclaimer: that’s the one I work in, care a great deal about, am heavily incentivized to see win, and am rooting for – roll in the bias droids!).

I skipped figuring out the market size last year when I tried to round-up the Docker market. Needless to say, I’d describe it as “fucking-big-so-stop-asking-questions-and-ride-the-God-damn-rocket.”

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.

DockerCon 2016: A Summary of Announcements and Key Takeaways

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.

Dependency management: always a hassle.

Source: DockerCon 2016: A Summary of Announcements and Key Takeaways

067: Fried chicken, Docker Swarm, tech journalism, or, “but that sweet @MattRay interpolation, tho.” – Software Defined Talk

SDT_filled_three_heads_1400x1400 - cote.io watermark

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.

Listen above, subscribe to the feed (or iTunes), or download the MP3 directly.

With Brandon Whichard, Matt Ray, and Coté.

SPONSOR

Show notes

Rainbow Chicken vs. Chick-fil-A

  • The “happy meal” barter system.
  • The Left needs some fried chicken chain.

DockerCon

Is there product strategy going on in the container space?

  • Accident-driven intentionality.
  • Yes, they’re building up momentum and then monetization.

Midroll

  • SpringOne Platform – funny name, etc. $300 off registration with code pivotal-cote-300.
  • ChefCon – July 11th and 13th in Austin!

Brook & Bob memorial segment, On the Tech Media

Apple & ZFS

  • More detail than you’d care to want
  • It’s like a story of the ups and (mostly) downs of enterprise infrastructure software. Also, the flirtation nature of announcements that keeps eager nerd-beavers on tender-hooks.

BONUS LINKS! Not covered in show

Infrastructure Software is Dead, or, “With friends like these…”

  • Hard truths from Mirantis
  • “Everybody’s OpenStack software is equally bad.”
  • “But none of this matters, because today customers don’t care about software. Customers care about outcomes.” (Because, you know, they used to not care about outcomes…? Plz. advise.)

Infrastructure Investments by Cloud Service Providers

10 Hour Maintenance Windows on Oracle Cloud?

Operational Best Practices for Serverless

Checking in on CostCo

Recommendations

Docker industry research roundup, circa 2015 – Austin Docker Meetup, Jan 2016

Screenshot 2015-12-08 13.41.23

I was asked to be on a panel for the first Docker Austin meetup of the year, tonight, Jan 7th at 6pm. Here’s some slides I put together in my capacity as “person who used to put together slides like this and is trying really hard not to do his job pitching Pivotal to avoid being rude” (well, except for a shameless plug or two):

See ya there!

Update: I’d wanted to put a TAM in – the money Docker and containers are going after, this from Gartner:

chart.png

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).

For this kind of hand-wavey, way future looking TAM’ing, what’s a plus or minus a billion or so anyhow?