How is Your “Shopping Experience” Related to Docker?

A few days ago we had a great friend of mine over for dinner. He also happened to be my very first mentor at IBM (when I joined back in 1994) and one of the smartest guys I have ever met.

A few years ago he decided to unplug from the IT industry and has only recently rejoined the mad-house. Since he was so smart, it only took him a few months to get up back to speed with new stuff he had lost track of.

However, something he said he is having a hard time to get a proper understanding of is “all this noise around Docker”. When he asked what that was and why everyone is talking about it I had a “Aha” moment.

When people are heads down on this stuff it’s (sort of easy) to find the starting point on where to begin the pitch. But with someone else that isn’t 100% plugged, where do you start? What do you assume the other side knows about what’s going on? But more importantly: how can you make sure people understand WHY certain things happen? I came across a lot of “well I am doing it because I can (and seems cool)” as of late.

This helped me to think, as a mental exercise, how I would explain all the container buzz to someone that isn’t day in and day out in all these stuff.

I have recently wrote a couple of articles that are Cloud Native Applications for Dummies and DevOps for Dummies. What I have failed to do however is to tie them together into a cohesive  non-engineering story to explain why these things do matter.

I would consider these two articles, similarly to a Star Wars layout, Episode 2 and Episode 3 of my own saga while what you are reading now is Episode 1.

I suggest you keep reading in storyteller order Vs release order :)

So, how is your “shopping experience” related to (say) something like Docker?

Note: if you are a cloud pundit (or if you think you are a self-proclaimed one) you can stop here. I take no offense.

It all starts with thinking about how the world surrounding you is changing.

I am not talking about what happens inside the data center (or the public cloud).

I am talking about what happens around you, as a person. All of a sudden we woke up and…

  • we saw an 80 years old nana doing Skype with her nephews

  • we saw our kids swiping the TV to change channel

  • we saw soldiers with a tie dropping bombs while flying drones remotely

  • we saw our 4 years old suggesting us “Ask Google if you don’t know the answer”

 This was an eye opener for me (particularly the last one).

In the meanwhile, on the business, side:

  • Amazon is killing the retail market

  • Uber is disrupting transportation

  • AirBnB is revolutionizing the hotel industry

There was this interesting article a few days ago where it was said that “[In San Francisco] Yellow Cab Co-Op said challenges from tech rivals Uber and Lyft, as well as mounting lawsuits from traffic collisions contributed to the fiscal Hail Mary.”

But it doesn’t stop here.

It’s way more pervasive than that. It touches all of us directly. While farmers are buying John Deere tractors for the apps that come with them, I am buying scales from a particular brand for the same reason (yep, that’s what I did).

So why is that? There is only one answer to it:

“Software is eating the world” (aka: the value is in the software). And is giving people and organizations an edge…

This isn’t anything new in the data center as “hardware is commodity while software provides the real value” is something that we have known for many years now.

What’s interesting (to me) is that we are now seeing the same pattern applying to (and changing) our own life. Changing what we buy and how we buy these things.

Oh… talking about HOW we buy things.

Good software could change a BAD user experience

… into a GREAT user experience

But what does all this have to do with Cloud Native Apps and DevOps anyway?

Well, if software gives you (organization) an edge…. the time from a “business/developer idea” to “when it hits the user” should tend to zero. You can even express this as a mathematical formula:

Time(user enjoying experience) – Time(developer idea of said experience) –> 0

Enter the role of Cloud Native Apps and DevOps.

Let’s have a look at how applications in a traditional environment get architected and deployed (and ultimately get in the hand of a consumer):

Now let’s have a look at how a brand new application is architected and deployed:

In the end it’s really all about getting to the user faster.

DevOps is how you make that happen.

And Cloud Native Applications is what allows you to do DevOps.

I am oversimplifying, but I think you get what I mean.

Talking about oversimplifying, as a side note, the speed in the second picture is also a symbol of why workloads are slowly moving to the public cloud: if you set up yourself to try to deliver your application fast, are you willing to wait for IT to deliver what you are asking them to deliver….? Exactly.

Back to Docker and my friend’s question.

Docker, per se, is just an enabler technology in a much (MUCH) larger picture as you can see. You could argue that it was a match in heaven because the value proposition of Docker is a perfect fit with the technology requirements of a Cloud Native Application managed via a DevOps approach:

  • Fast to start (sub-second)

  • Lean / Small self-contained environments

  • DevOps-oriented self-service authoring (e.g. dockerfile)

  • Ease of Sharing (public / private registries)

  • Infrastructure agnostic (move transparently from laptop to on-prem to off-prem)

  • 1 container = 1 process (ideal to de-construct the monolith)

Docker is a great way for developers (or DevOps people) to package applications application processes.

I often refer to Docker as “MSI without DLL-hell” (who knows, now that Microsoft is embracing containers and Docker full steam that may become less of a joke and more of a reality?).

There is something else, however, I am still trying to form an opinion around.

Everything we have seen in this short article (and that you usually read on the Internet) assumes that organizations 1) develop their applications and 2) operate said applications.

As you can imagine, in a DevOps context, it is often very hard (rightly so) to discriminate between Devs and Ops.

So everything we discussed could potentially work for Internet companies, some large Enterprise organizations that do internal development and SaaS providers.

However there are lots of different patterns too in this industry. For example, there are organizations that do not have in-house development (so they only do Ops of off-the-shelf software). Also, there are ISVs that only write applications (hence they only do Dev) for third parties to buy and operate.

How Cloud Native Applications and DevOps could apply to these entity is entirely TBD (in my head at least).

Some will argue that all these organizations will move to a SaaS-based consumption model and, consequently, ISVs will move to a SaaS-based provider model. Surely an interesting layout for the industry.

Time will tell.


2 comments to How is Your “Shopping Experience” Related to Docker?

  • PJ

    Time will tell indeed, but:

    regarding the “hybrid-devops-model” (hey, I forged a new buzzword) i.e. whenever the dev and ops team don’t fit in the same organizational boundaries, that doesn’t limit the uptake of devops practices. Whether it’s customized, purpose built software, or packages off the shelf, there is need for integration, or at the very very least governance from the end user. That means that The dev side of devops in this case is just happening with a different length of the cycle, but the “glue” that might tie the ops and dev is still there (if one wants, of course). It’s not about the tooling and best practices, rather than trust and processes (albeit lightweight ones). One of the integration nightmares of traditional/legacy approaches in SDLC is really tied to packaging, and working with containers might help adopting a lingua franca when it comes to the artifact delivery process. What’s more, container inspection might allow ops to add cross-cutting features to finalized “packages”, so that the ops lifecycle and the dev lifecycle interact but don’t overlap or stomp on each other feet.

    Long talk. Need some serious dish of Pizzoccheri for this :-)


    • Massimo

      Yes I agree. In the end containers may become the new “delivery artifact” (going back to the MSI reference). This would make sense.

      I am always in for Pizzoccheri :)

Leave a Reply