3 Months In. 3 Big Observations. 6 Abstractions.

Over the last 3 months, I’ve been talking with a LOT of customers of every shape, size, language, culture, geography, industry vertical.   Ditto with many partners.   One topic that comes up ALL the time can be summarized in a few sentence samples/snippets:

  • “Everything will be serverless/functions – it’s all we need” (usually from someone who has no idea what they are talking about but REALLY needs to look smart).
  • “I don’t want containers – I just want platform/functions – it’s all we need” (usually from App/Dev folks who just detest all infra stuff)
  • “I don’t want platforms/functions – I just want containers – it’s all we need” (usually from Infra folks who are the “Dev/Ops OSS” new kids on the block).
  • “I just want a thin containers/platforms to layer on top of my kernel mode VM focused IaaS – it’s all we need” (usually from Infra folks who have spent a lot of blood, sweat and tears on building and maintaining kernel-mode VM IaaSes over the last 4-5 years).

The funny part – often this is at the same customer, and sometimes even in the same room at the same time.

This comes back to the human instinct to see the world through your own eyes, your own biases (this applies to me too).   We also always want to think of “the one right way” and when presented with a list of: “A”, “B”, “C”, “D” to jump to the conclusion that it is a “pick one” or an “OR” question vs. a “how much of each” or an “AND” question.

Everything I see points me to 6 large grouping of abstractions existing for the for foreseeable future.   These abstractions are the “where does the workload live”, and “where is the highest common denominator” for said grouping of workloads.

This will be a familiar picture to some, but I’ve made some edits.

There’s a tendency for each of us to ignore the parts of this we don’t live in every day.    For example, often Pivots forget that there is an abstraction ABOVE “PaaS/FaaS” (which are kissing cousins – will talk lightly on this here, and lots more about this next week)… that abstraction is SaaS, and represents a customer focusing even more on what is “above the value line”.

But – it’s a great visual, so will steal, and contribute – this is something I’ve been working on with my Pivotal compatriots like James Watters (@wattersjames), Cornelia Davis (@cdavisafc), Ian Andrews (@IanAndrewsDC), Raghvender Arni (@r_arni), Richard Seroter (@rseroter) and others.   I’m standing on the shoulders of giants, and building on pre-existing ideas.

First Big Idea – Strategic goal: Push as many workloads as feasible (through a filter of technical, business, practical, timing decision criteria) to the top of the platform hierarchy.

Now, there are good reasons to NOT move a workload/app up the abstraction stack.

These include: “I’ve thought about it, and I can’t” (“it’s not my software, but an ISVs”, “or the app has a hard dependency on infra that I can’t move past”); “I’ve thought about it, and have made a conscious decision and won’t” (“the app is so old, it’s better to put it on late-stage life-support and phase it out”) of “I will, but just not right now” (“I have bigger fish to fry that will yield bigger results I need to do first”)

This is not just a “Chad Thing” or a “Pivotal Thing”.   One of the BEST blog posts that Richard kindly linked me to was this great series from Google.   I strongly encourage reading this here.

I LOVE the observation in the blog post series of “time to value” – how much work goes into getting a “hello world” app up and running.    If you’re too lazy to look at the link (seriously read it!) – here’s the punchline.

Seriously, follow the link, read the post series, it’s great.

BTW – the Googler does the thing we all do (focuses on their domain)… The post misses the abstractions BELOW the GCP kernel mode VM layer… but imagine adding the data point for “time to get the code running” if you were using the hardware abstraction, and needed to design, acquire, deploy the underlying hardware!   This is why for workloads that will run on prem, dramatic simplification (hint, software defined infra, industry standard hardware, turnkey HCI appliances – aka standardization, automation) are MANDATORY if you want to be serious about private clouds.

I’ve realized over the last few years, not just months that customer dialogs really need to start with an honest self-assessment of where they are, and where they are going with workloads across these abstractions – if for nothing else to have a pragmatic dialog.

Often, when meeting with a customer for the first time, I list the abstractions, then ask the customer to guesstimate their workload distribution… today, and in three years.   This is always fascinating.  I often get a table that looks something like this:

BTW – this topic echos in this blog post if you want to double-click – because each abstraction creates its own “stack”, “org”, “tools”, “process”, “operating model” – you name it.

Everyone will dispute the numbers – and these are from a recent customer dialog.  Even the dialog that the process triggers at customers is useful for them to discuss amongst themselves.   I often find they aren’t talking/thinking about this over the more strategic window.    I would encourage you to talk to customers yourself (and sample the same customer in multiple parts/people in the org).

A common set of comments in this discussion are things along these lines:

  • “yup, there’s still some workloads/apps that force us to stick to hardware as the highest abstraction we can get to – we just can’t abstract out… and while this has gone down over the last decade, what’s left is really, really stubborn, I bet they will still be there a decade from now”.
  • “we love the kernel mode VM abstraction, and it’s carrying the bulk of the workloads today – we know that many of those will move to higher order abstractions over the next few years… That said, it will still be the abstraction for the majority of workloads in a 3 year horizon, and while kernel mode VMs won’t be the abstraction surface for containers/PaaS – we know those will depend on a solid kernel mode VM base layer”.
  • “We’re not sure how much will go CaaS/PaaS/FaaS from the Kernel Mode VM abstraction – but we know we’ll use more SaaS, that’s for sure”.

Of course, this also triggers the “how much will be on-premises, vs. off-premises” dialog which is important – but independent of this topic.

Second Big Idea: recognize, embrace the fact that each of these abstractions is really important – and will have workloads on them for the foreseeable future.   This is why I’m passionate on the change management topic of “n-modal” states in the customers I interact with.   I tend to recommend to people that they should politely ignore those who are dismissive of this fact and won’t listen to arguments to the contrary – they tend to be fanatics, and talking to fanatics is educational, fun, but rarely productive.

For a non-exhaustive list of examples for context, here’s examples of each abstraction:

Now, let’s put an elephant on the room right on the table .   Everyone in the industry (including many at of my Pivot brothers and sisters) often distort the reality for a variety of reasons:

  1. Sometimes this is for innocent reasons. Humans have passion for one particular abstraction or area, and they dig in really, really deep.  This is common amongst some of the smartest folks who focus deeply into one abstraction or another, or focus their careers in one particular place.  This is passion, expertise… very innocent, very noble reasons… However, often those same humans struggle for the bigger picture.  The motivation isn’t evil at all – it’s purely excitement about one thing.   While the motivation may be pure – it can cause some pretty negative effects.
  2. Sometimes this is for classic “human error” reasons. A slightly more negative human tendency to be dismissive of the domain that is not OUR domain.   I’ve made an axiom about this: “An engineer will assess that a new unplanned technical problem NOT in their domain will just take 3 people, a weekend, a case of beer and 4 pizzas to solve.  An engineer will assess a new unplanned technical problem that IS in their domain as taking the resources of the Apollo space program and years to solve”.    This manifests like this (and I’ll use Pivotal voices as an example)…
    • Statements like: “we are multicloud.. ” (true) “… so the IaaS and hardware doesn’t matter”. This is false – there’s a strong dependency, but a loose binding (all it takes is having really poor infra underneath a PaaS/CaaS to learn this fast – but at the same time, a good PaaS/CaaS/FaaS should not have explicit bindings to a particular IaaS.
    • Another example are statements like “containers are OK, but don’t offer the true value of the higher abstractions like Pivotal Application Service (PAS)” (it’s more true to say that the higher order PAS abstraction delivers higher effort focus on higher value = more speed, but the Pivotal Container Service (PKS) abstraction delivers more flexibility – and the right abstraction depends on technical/business/practical/timing considerations).
  3. Sometimes this is for more overtly “evil” reasons. All players in the ecosystem play in SOME, but not ALL off the abstractions.  Some only play in one.   All players have relative strengths/weaknesses in the abstractions that they play in.   There’s a strong tendency for the voice to echo their strength and be dismissive of the abstractions they don’t play in.   Again, I’ll start by casting the first stone at ourselves (I think the whole ecosystem does this to varying degrees).   When Dell Tech teams work well together – they do this right (each playing their position – Dell EMC at the HW layer, VMware at the IaaS layer, VMware/Pivotal together at the CaaS layer which crosses the infra/dev domain, Pivotal at the PaaS/FaaS layer which is all about devs).   I’ve seen our field teams not nail this in the struggle to be “the most important” to the customer, dismissing the importance of each abstraction.   We are not innocent, and we can all get better.    Often Dell Tech teams ignore the SaaS abstraction (as this is a layer we don’t really do too much in, though we support a lot of the SaaS out there)…   Now that I’ve pointed at ourselves, I will say that I see examples that make those look innocent.   I see vendors who don’t participate in segments, or who are relatively weak in their parts of the abstraction stack do things that just aren’t right – throwing everyone else and other abstractions under the bus.  Often those same humans change vendors, and completely change their tune multiple times to suit what they are shilling – ergo, they are mercenaries.   You know who you are, because you know this in your gut.

Now, let’s talk about what you HAVE to give up to live in each abstraction, and what you GET in return.

Here’s my quick take:

I’m sure there will be lots of opinions here (I’m trying to make a complex topic simple) – and I want them all.   Let me give you some more color to maybe cut some of the flame wars off at the pass:

  • It’s not that you can’t automate hardware. You can.  You just can’t automate it well.   Automation and standardization go hand in hand, and when you are optimizing every stack at the hardware layer – you will never make much headway.
  • The security hardening that happens when you REALLY move up the stack (hyper-standardizing, totally automating below and above the abstraction line, moving everything below the abstraction line to “consume” and ceasing “construct”) vs. “faking it” (still wildly varying below the line). This is not fakery.  I’ll give you a real world example I see left right and center when it comes to CaaS vs. PaaS.   In Kubernetes, privileged containers are a reality – and that’s of course a big security question.  In some cases persistent volume controllers require it.  In some cases helm charts require it.   Yes, Kubernetes permission models are maturing and security models for namespaces are an emerging space, and the SIG is getting busy, but it’s still early, early days.  It’s one of many reasons why multi-cluster patterns and fleet management are a core PKS design center.   Notably, this is simply not a consideration because this can be completely hardened down in PaaS/FaaS models (of course, they don’t expose the lower level functions, so this is “opinionated”).
  • In each layer, the other layer is underneath. Yes, the higher order abstraction always shifts value away from the layer underneath.   Yes, done right, it become a “low binding dependency”.   But – they are still a stack, and some of those bindings always pop through.
  • Yes, with the PaaS/FaaS abstractions – if you’re not careful, you can accidentally create very high-energy, high inertia bindings. By definition, PaaS/FaaS are application platforms, not infra platforms, and the only thing stickier than data is code.   My guidance to people is always create bindings here very, VERY thoughtfully.   Consider using things like the Open Service Broker.   Consider using PaaS and FaaS platforms that are cloud agnostic.   This doesn’t mean that the choice to create hard bindings to a particular cloud platform is definitionally BAD, just is not something to do by accident.  You need to decide that you want to be married to that particular implementation, that particular service, that particular API, to have an “accidental” cloud app that you will be living with those dependencies for 20 years.   Multi-cloud abstractions are like a prophylactic.   Protect yourself, and make choices that have permanent implications very thoughtfully.   There are times where the value/benefit of the vendor-specific dependencies can absolutely be the right call.
  • With SaaS, you are making one of the highest order trade-offs (only thing higher is “totally stop doing this altogether”). It’s absolutely the right choice where there is NOTHING in “doing that” that is uniquely you.   Just recognize what you are giving up.   It’s always funny to ask people who throw out “lock-in” FUD: “right – so are you using SaaS?”   the answer is always “YES” – and there’s no better example that lock-in is silly, the better consideration is the ratio = (benefit):(cost to move).   High ratios = “good”.   Low ratios = “bad”.

One place where I think things get blurry is CaaS/PaaS/FaaS – but it really isn’t that blurry.

  • CaaS is still an infra-centric construct. It’s a platform on which app platforms are built.   Whether YOU build it, or whether YOU consume it (ergo someone else builds it) is a more important distinction.   Other than the very important ecosystem of ISV’s who bring container images/Helm charts/deployment YAML of some form or another – all the other cases are ones where SOMEONE is doing the work to build some form of a developer platform ON the container platform.   The one and only @kelseyhightower (I highly encourage following):

Third Big Idea:  there’s a distinction between infra platforms and app platforms that has to be accepted, embraced by infra teams, and this has been the thing I’ve learnt the most about in the last 3 months and change.

When I see customers somehow think that “we use Kubernetes” is magic “Cloud Native dust” (and have a dog’s breakfast of automation and developer tooling that they are trying to build themselves)… I just shake my head.

It’s NOT a case that container platforms don’t matter – they absolutely do (it’s why we’re betting big on Kubernetes and partnering furiously with Google – more on this next week).

There are examples of apps that for the technical/business reasons we talked about earlier don’t fit into PaaS/FaaS abstractions Examples are a ISV apps, workloads that demand some ability to reach into infra layers more than PaaS/FaaS allow – like network and persistence volume dependencies.  Sometimes it’s that the time that would be spent on app transformation is simply better spent elsewhere (at least for now) – and containerizing the app without changing the code is a baby step.

But… If you stop there, you’re missing the prize.

I’ll make this point about containers and developer platforms with some customer examples.

  • T-Mobile goes from 7 months and 72 steps to update software, to same day deployments.
  • Liberty Mutual builds and deploys an MVP in one month and delivers revenue-generating version just hours later.
  • The Home Depot ships to production 1,500 times a month, and 17,000 times a month to all environments.
  • Comcast supports over 1500 developers with an operator team of 4 people.
  • Express Scripts went from 45 days to patch one product in nine environments, to five days.

In each case, they have a truckload of containers that underpin all of the stories, all the outcomes above, but it’s not about the containers.  They share their stories public at SpringOne and other places – and the stories cannot be told without talking about developers, apps, culture – much more than infra.

Here’s the two questions that shine a light on the role of the containers in those stories:

  • PaaS/FaaS are developer-centric constructs. They are platforms on which apps are built.  Yes, they have container platforms at their heart, but it’s simply not about the container platform per se.   The developer platform itself is the thing.   Again, quoting the one and only @kelseyhightower:

  • PaaS/FaaS are kissing cousins. The distinction is real – but is about triggers (is it pushing a long-running app, or is it triggering very short running functions based on events), and scaling/duration.   Both scale – but PaaS scales up/down on relatively low frequencies (measured in minutes); FaaS scales up/down in milliseconds – and scales down to zero (I’m not using anything).  PaaS code runs for long durations.   FaaS code runs for very short durations.   Over time (this will be years pundits – please chill) I would fully expect these kissing cousins to converge.

Wrapping this up:

  • First big idea – these 6 different abstractions exist. You get the most value, the most speed, the most focus on what matters by moving to the highest order abstraction you can (for technical and non-technical reasons… but don’t make excuses, make conscious decisions).
  • Second big idea – Embrace that it’s not about one abstraction or another. With each, there are things you MUST give up, and things you get in return.  If you don’t let go, give things up – you don’t get the benefit of moving up the abstraction stack (you don’t give, you don’t get).   All these abstractions have their place and will exist for the foreseeable future.   Don’t get into stupid bar fights.    Each abstraction depends on the abstraction underneath it – but done right, this is done as a dependency, but with a light/loose binding.
  • Third big idea – Recognize where the “infra ops/developer productivity” line crosses – it crosses at the PaaS/FaaS layer. Don’t artificially blur the CaaS domain.   This isn’t about pooh-poohing CaaS.  Simply, recognize that when using a CaaS, someone will have to use that platform to build a developer platform – the only question: “is it you… or is it someone else?”.


4 thoughts on “3 Months In. 3 Big Observations. 6 Abstractions.”

  1. Thank you Chad. Great blog post, as usual. I like the diagram a lot. I may definitely steal with attribution.

  2. Just for the sake of clarity I think it would be helpful to readers who may not be aware that Pivotal Container Service is PKS.

Leave a Reply

Your email address will not be published. Required fields are marked *