WP006 - Kubernetes & container landscapes from Forrester & Gartner
Software Defined Talk Members Only White Paper Exegesis Podcast, episode #06
Coté & Brandon Whichard, August 2017.

This week we look at a recent Forrester paper, “Navigate The Kubernetes Ecosystem,” by Charlie Dai and Dave Bartoletti from June 23rd, 2017 ($499 USD). See Charlie’s blog post on the paper, too. Also, because we’re good boys, we added some bonus reading, a similar paper from Gartner.

To be released as a free, sample episode in the regular Software Defined Talk feed. If you like this kind of thing, sign up as a Patreon for $1/month or more and you’ll get about one of these types of exegesis’s a week. See past episodes.


A summary from the blog post:

  • Two types of software offerings provide container orchestration features. Open source frameworks and commercial solutions such as CoreOS Tectonic, Mesosphere DC/OS, and Docker Datacenter (as part of Docker Enterprise Edition) can cover most of the major enterprise features around container orchestration. There are also open source tools that include some but not all orchestration features, such as Apache Mesos for task scheduling and etcd for service discovery. Among these, Kubernetes (K8s) dominates client inquiries and is enjoying high adoption momentum…. K8s is quickly becoming as popular as Docker itself, and for good reason.

"Client inquiries” tends to be a primary driver of how analyst rank technologies, somewhat secondary to surveys, likely followed by their own opinions. People are interested in kubernetes, so let’s take a look at it.

I think this paper accomplishes what it set out to do. It could use some more survey and market-scaping context to show the realness and penetration of kubernetes in the enterprise, but the topic is so hot, that it’s sort of not needed.

It does leave you hungering for a more in-depth explanation of what all this is and what workloads fit well in a kubernetes environment (“why would I do all this ‘cloud-native’ stuff instead of just for LAMP and JEE?”), but that’s not really the goal.

The goal is to provide EA-types with an explanation of what you want a kubernetes stack to do and who the players are. Why you’d want that stack in the first place (and what the alternatives are) is out of scope.

Why you’d care

Charlie’s blog lays it out:

  • Containers are at the heart of so-called “cloud-native” applications and platforms — the emerging term of art for apps born in or redesigned for container-centric technologies. Containers enable faster software delivery, tremendous scale, higher resiliency, greater flexibility, and a wider range of implementation options — all critical features that EA pros need to accelerate digital transformation. But large, highly distributed collections of application components running in containers require coordination and orchestration. As enterprises begin to adopt containers throughout the application life cycle, the number of inquiries Forrester receives about container orchestration is increasing.


Largely considered the “number two” analyst firm, Forrester has long positioned itself more towards practitioners than the broad focus that Gartner has. In my experience, Forrester analysts sit somewhere closer to Gartner’s own practitioner focused group, Gartner Technology Professionals than Gartner’s “normal” industry analysts. Much of what I find in Forrester is targeted at IT decision makers; here’s you’ll see them referring to “EA pro’s” at lot, enterprise architects. Forrester doesn’t seem to follow as strict a regiment of paper categories as Gartner does. This results in much broader, often more interesting, set of topics, but it also makes them unpredictable and seem a bit disorganized. Choose your poison. Forrester, of course, has The Wave, which is their Magic Quadrant equivilent. They also have a cool lobby in their headquarters with guitars and their CEO’s obsession with guitars and (Southern?) rock extends out to conferences rooms named after bands and other rock things.

It’s worth thinking about this obsessions with the phrase “professional.” In the context of talking about enterprise architects, the term “pro” is weird, as I don’t think there are enterprise architect amateurs. Though, I’m sure the opiners on Hackernews might qualify as that, so perhaps the pro modifier isn’t redundant. You’ll see some vendor lingo - usually Microsoft, among them - using the word “pro” a lot too. It’s usually used by people when they want to make some nuanced distinction about a certain role without using a generic term. For example, instead of just “operator” or “sysadmin,” Microsoft and other systems administration vendors will often say “IT pro.”

I’d read it as demarcing “people who do the work, not the managers.”


  • This paper seems long at first - 20 pages, oh my! - but it’s full of a lot of diagrams and tables.
  • DevOps was chugging along nicely as a developer and operator concern for a while, following “cloud,” both of which analysts covered pretty well. DevOps was very difficult as it turned out to have little in terms of vendors to cover; the result was analysts just writing report after report extolling the need to focus on process and organization change. The “pro” cousin of DevOps, in analysts land, is “bi-modal” IT which causes all sorts of delightful playground squabbles. Then along came Docker, and analysts had a new thing to cover. Must be exhausting.
  • Here, Forrester is wrapping it’s arms around container orchestration, first laying out the definition/requirements, and then going over the top vendors. As with any exercise like this, one of the first things to pay attention to is the date the paper was done and the criteria for including vendors. For example, this paper was done before Pivotal Container Service was fully released, and so that’s not included.
  • How technologies like container orchestration are defined has changed dramatically over the past ten years. It used to be that standard bodies or single vendors defined what was in a stack, e.g., HTML/the web, Java/.Net/J2EE, SOA, even something like PHP and rails to an extend, and then cloud with Amazon. Around the time of the LAMP stack, and solidly with DevOps, who defined a stack became more ad hoc and emergent. And, now, with container orchestration, there seems to be no central body defining exactly what it is. As with DevOps, a mostly agreed upon definition may emerge, but with so many commercial and community interests involved, the definition of “container orchestration” will likely be loose and, thus, confusing, for many years to come. The CNCF will be a force for locking down a definition, but “vendors” will likely run confusion missions on that and how enterprises end up using container orchestration will create confusion as well. Of course, the second confusion assault will be reality.
  • Analogies to OpenStack and the OpenStack Foundation are extremely apt here. Everyone in the kubernetes world, of course, hates this comparison and bristle at it. Nonetheless, the dynamics of the OpenStack community are the baseline of expectations in defining the kubernetes ecosystem.
  • The paper’s core components of container orchistration are: 
  • Task scheduling with high-availability support.
  • Application configuration management.
  • Service discovery and configuration management. 
  • Container cluster management.
  • Container networking.
  • Container storage management.
  • These result in the center-piece of any paper like this, the giant burger of definition:
  • There’s much laundry listing of vendors and technologies. There’s a lot of in’s and a lot of out’s on this stuff. No one vendor seems to own it all like Red Hat does in Linux. This landscape is a fragmented mess of confusion.
  • What’s interesting in this paper is that there’s little explanation of what all this tech does: it’s assumed you know and are just looking to see who the vendors are.
  • Another Absense is survey and market data to demonstrate how “real” all of this is and growth. Either the authors didn’t care to highlight this, or Forrester doesn’t have it: analysts rarely cite other data, and never other analysts work.


  • Very rapidly, they start using the term “K8S” instead of typing out the full “kubernetes.” As someone who types out that phrase a lot, I can sympathize. “Kubernetes” is perhaps one of the worst, most annoying technology names of our era. I remember talking with some Google people early on and telling them that it was difficult to pronounce and spell, to which they replied, “yeah, most of the engineers just type K8S for it. So, yeah.” Tech Marketing Rule #1: don’t let developers name things.