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

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:


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?


Coté Memo #059: Containers make butter-scotch pudding delicious and floors shine

Tech & Work World

Floor wax, dessert topping

As I mention below, I’ve had more time to write reports recently. I just submitted one titled “Docker: floor-wax or dessert topping? Reflections on DockerCon EU”. It’s one of our “spotlight” pieces, which means it’s an open-ended think-piece rather than a write-up of a briefing.

Here’s some excerpts:

451 Take: The container technology Docker and the ecosystem around it is figuring out its identity while at the same time contending with a sudden rise in popularity. While early attention on Docker paired it up against the likes of VMware at, let’s say, the IaaS level, as we look at it more, Docker looks like more of a PaaS innovator. VMware would certainly like that option, and Docker, Inc. spent much of its recent conference in Amsterdam talking more about Docker-as-PaaS – through the lens of “microservices” – than Docker-as-IaaS. From this vantage point, it looks more and more like dotCloud never really stopped being a PaaS vendor, and instead, with under its new name of Docker is just evolving the nature of PaaS.

The technology promises at least two things: (1.) an alternative way of virtualizing workloads on servers using the underlying containerization technology and (2.) a DevOps friendly way of packaging applications for deployment on cloud and cloud-like infrastructures. Much of the vendor sports watchers fixate onto the first use-case, looking to thrust Docker into a Thunderdome with VMware. However, as both Dockers – the open source project and the startup – have evolved, it’s becoming clear that the second is perhaps the more interesting promise, long-term.

Over the next 12 to 18 months, expect to see much shuffling and toe-stomping on the ecosystem dance floor. Indeed, with so many interests, large and small involved, it wouldn’t be surprising if the landscape changed dramatically over the next year. Early moves like the Rocket container standard effort point towards conflicting (or at least “differing”) interests, and with deep larders and large revenue sources to protect behind many, large Docker ecosystem member’s backs, anything could happen with something as miraculous as a floor wax that also makes butter-scotch pudding taste so terrific.

One of the ongoing theories I hit on in the piece is that (a.) cloud is all about developers, but, (b.) the PaaS market is small compared to others, so, (c.) what up with that? As you can imagine, I posit that the interest in Docker-cum-containers could change the market-dynamics a bit. We’ll see.

I’ll throw a link in here and all the usual places once it gets published, I’m guessing next week. I put in three or four charts too, so look forward to them if you like charts.

(Lucky[?] for you, this is the only place you’ll see the silly dessert topping floor-wax reference as the copy desk asked me to take that out since another analyst used it recently.)

How I use Twitter: ignore the timeline

I’ll let you in on a secret: I don’t really pay attention to my main timeline in Twitter. There’s too much crap in there that I’ve ended up following (1,910 account, to be exact) since I started using Twitter in 2006.

Sometime ago, I created a list called “Focus” that I actually follow. It has just 127 accounts in it and it works well. There’s some tricks of how to do this depending on which client you use. I can stand the official Twitter web and iOS (actually, I haven’t looked at it in awhile) apps so I use TweetDeck on my desktop and TweetBot on my phone. In both instances, you can choose to focus on a list.

In TweetDeck, it’s easy: you just move the column over that you want. You’ll notice in the below that my “timeline” is nowhere to be seen:

Switching around columns in TweetDeck

In TweetBot, it’s a bit more hidden, you have to “long tap” (is that what you call it?) on the title bar until it pops up a list of lists, then select the one you want. You can see what it looks like after I long-tapped on the title bar:

Viewing a list instead of your timeline in TweetBot

Sometimes I go slightly insane and think there’s not enough from Twitter. Recently, I thought I’d take a look at the timeline and see what was in it, what was going on. It’s a fun walk down memory lane as I discover clusters of accounts I’ve added over the year. I found a bunch from when I thought I didn’t get enough local and “real-world” news so I have/had several Austin accounts and things like Meet the Press. There’s also folks from long ago in there that I vaguely remember. And, going in and out of the analyst world, there’s also a lot of people who are or were clients at RedMonk and 451 Research. Lots of IBM. Lots.

I’ve been pruning that main timeline this week in the hopes of perhaps actually using it. I’m not sure it’s worth it, but it a good distraction-as-entertainment.

Quick Hits

Fun & IRL

No fun today, just work.


  • FRONTSIDE.IO – HIRE THEM! Do you need some developer talent? When you have a web project that needs the “A Team,” call The Frontside. They’ve spent years honing their tools and techniques that give their clients cutting-edge web applications without losing a night’s sleep. Learn more at


Coté Memo #055: It’s cold in Toronto


Tech & Work World

Quick Hits

“Script” for Docker orchestration

Oftentimes, I write a “script” for presentations. I never read it for the presentation (maybe I should!), but it helps me organize my thoughts and presentation. Here’s the one I used for the Docker orchestration webinar I did with CloudSoft last week:

Macro-context: the demand for building your own PaaS – DevOps, cloud, etc.

[chart on DevOps delivery pipeline, old dto solutions DevOps pipeline]

I like to reduce things down to brutal simplicity. I have a lot going on in my work and personal life so I have to leave nuance for entertainment. To me, cloud is mostly about supporting custom written software, whether that’s for something like a SaaS (from social to ERP), consumer facing business applications (like online banking), or applications used by companies to help run their business. And what that means is creating a delivery pipeline that encompass all the phases of an applications life and automates each step as much as possible to reduce bottlenecks and increase throughput. You have to look at this pipeline as a mission critical process in your business: from development to production, it’s you’re factory, the thing that helps you make money…not just a cost center. You’re pushing out incrementally improving software that runs your business.

Custom written software is the most valuable work-load for cloud, I’d theorize, where value is rated by how technology can help a company get competitive differentiation.

So, something like Docker is especially interesting because it promises to speed up that pipeline. I don’t think anyone know exactly what it will shape up to be, but it looks like the “private PaaS” answer we’ve all be looking for.

[chart with SaaS, PaaS, ISaaS, IaaS market-sizing – put OpenStack market-sizing in there next to it]

Now, PaaS is an odd category of public cloud. It seems like the perfect realization of the efficiencies of cloud, and yet it keeps limping along as a market as this 451 market-sizing shows.

Much of that revenue comes from Salesforce which has its own platform (a “PaaS for SaaS” as we call it) and Heroku.

[chart on demand for private cloud]

For some reason, developers and companies have a lust for build your own cloud: they either get their own gear or rent raw IaaS and build up their own stacks to support as automated as a DevOps delivery pipeline as possible. Maybe it’s cost (I haven’t ever heard a developer say public PaaSes like Heroku are cheap), maybe it’s the need to exactly customize functionality, maybe it’s good old paranoia and FUD (which could be justified, who knows).

Whatever the case, people want control over their stacks, and that’s where things get interesting. The more control you have, the more you have to worry about the more hassle there is.

We seem to have a long way to go to replicate the magical, effortless push to deploy demo we remember from early public PaaS days. Much of what’s needed is what’s currently going under the title of “orchestration” which, roughly, means “making sure my complex distributed system is installed and configured properly…and then allowing me to modify its runtime characteristics and upgrade it.” You know, getting the application up and running, tuning its performance ongoing as needed, and upgrading it.

[insert chart showing rise of new automation tools/brands]

This area has long been the domain of custom shell scripts, manual configuration, and, thankfully, in recent years configuration management companies like Chef and Puppet (who are taking over the automation reigns from OpsWare and Bladelogic).

Docker has burst on to the scene of late as an interesting salve for cloud infrastructure woes. To me, it starts with the right goals: make using cloud easier for developers. That may seem subtle, but it’s different than most infrastructure software goals which is make like easier for sysadmins and auditors.

To keep pushing on the dream of being able to build your own PaaS, the ad hoc community around all of this has been obsessing about orchestration of Docker-based clouds, let’s call them, of late. So let’s look at that.

Emerging market for orchestration

Mindmap from Krishnan Subramanian

When it comes Docker orchestration, there are almost too many projects to count, and even a few products. I love this mindmap from Krishnan that shows just full this market is – and tedious for analyst to keep up with. This is a good sign, however: there’s so much interest and passion in figuring out Docker and how to orchestrate it that surely, something will work.

Emerging requirements for orchestration

When I look across what all of these projects are trying to do – and slap in some old IT Service Management think – I come up a list of requirements for orchestration. Some of them may seem obvious, but it’s always good to be explicit. If you spot ones that are wrong, or missing, you should pass them along and perhaps we can winnow down a list. We don’t need a manifesto or any nonsense like that, but in studying this space, you do find a distinct lack of architectural-level specifications and requirements – which is fine, people are busy coding.

Cluster/fleet management

  • Operate in terms of multiple nodes, not single nodes – configuring a single Docker node is mind-blowingly easy, doing it over 50 or 100 nodes gets to be tedious, esp. if you want to continually be turning over builds. Pets vs. cattle and all that.

Configuration management & Automation

  • Application modeling that describes the layout and configuration of various components – this is an old ITSM notion, “service modeling,” which got bogged down in drag and drop fantasy (just like UML). You need to model what all the different components are and how they fit together
  • Basic CRUD – creating nodes, updating nodes, restarting them as needed. You want more than just modeling what a node looks like, you want you orchestrator to actually do something.

  • Separating configuration from basic state – easily modify configuration without having to change too much about each node/image, like changing port numbers easily without rebuilding the entire node

  • Ensure proper configuration passing across nodes – passing server names and ports to servers, handing out credentials, wiring in service directories, etc.

Heterogeneous platform support

  • Support for different infrastructure, bare-metal, to plain old virtualization, to multipule clouds – some might call this “hybrid cloud” or “multi-cloud” – useful just for moving along the pipeline

Baby and bathwatering ITSM

  • Asset database to track all your cows – another ITSM trick. this starts getting into “enterprise” needs, but it handy even if aren’t tweedy. You need to know what you have out in the wild and quickly locate it when things go wrong.

  • Capacity management and adjustment of resources – not only monitoring if you’re over (or under!) capacity, but actually going back to your CRUD operations to make adjustments on your nodes. This is also where keeping configuration separate from node state is handy: you could increase memory, keeping the same configuration, for example, without having to rebuild or swap out nodes.


  • Ease of use, and esp. low cost – otherwise, why not just use a full on PaaS? This is always easy to forget, but it’s sort of the point of all of this. Ask yourself, is this easy and quick to use? If it’s not, something is wrong.

This last point is key. You need to remember that once you’ve done all the above, that’s when the difficult work begins. You still need to come up with an idea for an actual application and its features that will help your business. You need to stop orchestrating and start coding, not to mention working on the product management that will tell you what to code in the first place. Don’t get all caught up in all this Heathkit stuff: save your cycles for the most valuable thing: ABC.

[Always be coding chart]

And with that, I want to pass it over to CloudSoft to tell you how they’re helping you get closing to coding.

Fun & IRL

No fun today, just work.


  • FRONTSIDE.IO – HIRE THEM! Do you need some developer talent? When you have a web project that needs the “A Team,” call The Frontside. They’ve spent years honing their tools and techniques that give their clients cutting-edge web applications without losing a night’s sleep. Learn more at