Skip to main content Skip to Footer

BLOG


March 17, 2016
Breaking the 2 pizza paradox with your platform as an application
By: Mark Rendell


I had the absolute pleasure last year of speaking at the DevOps Enterprise Summit 2015 in San Francisco and I’m pleased to say the video is available here.  In this post I’m going to summarize my talk.

In my experience many large enterprises would love the adoption of DevOps to be as simple as bringing Development closer to Operations. In practice, they need to consider many development teams, multiple suppliers and multiple service providers, not to mention multiple business divisions.  I believe that the simple act of re-evaluating and re-defining your Platform-as-an-application (PaaA) will have a significant impact on the improvement of IT.

It is first helpful to start with a working definition of DevOps:

We value: Enhancing IT systems to meet the business’ needs over IT operating efficiency

How can we organize everyone towards this common purpose?  Most enterprises are far too large to make putting everyone in a single cross-functional team possible.  Jeff Bezos, founder and CEO of Amazon.com, has recommend that you should be able to feed your team with two pizzas (i.e., 6-8 people per team).  How in a large enterprise do you create end-to-end teams aligned to deliver high-throughput, complex IT without large teams?  This is what I call: “The Two Pizza Paradox.”

To visualize the problem, we can draw a simple abstraction of the end-to-end software lifecycle and overlay the traditional functional teams—and they are littered all over the place.

Try to avoid using acronyms and abbreviations in your diagram, spell out release and UI etc.

In some ways organizing by skills is similar to organizing a zoo.  We put the DBAs together over here, the Developers over there, etc. With a zoo you certainly aren’t thinking about organizing the animals  to help them achieve  a common goal.  When you organize a zoo, you are trying to prevent animals from eating each other, or worse yet eating the public! The zoo metaphor goes further because zoos aren’t necessarily the best environment for nature to thrive in.  If you think about a rainforest there is an amazing thriving autonomous, ecosystem filled with incredible symbiotic relationships.  Zoos take a lot of money and micro-management just to keep them running.

A better way?  
I think we have to rethink our lines of division and go back to prioritizing our products. Products are the things we need to optimize, and what we need to protect.  So let’s create end-to-end teams to develop and operate products.  We can even interpret the word DevOps as literally meaning:

Organizing for throughput by forming teams that both Develop and Operate products end-to-end.

Now, each product has one owning team primarily concerned with its development and support, or more importantly, its welfare and ability to evolve at the pace of business.  There is no wall to chuck software over. Keeping these team sizes down by decomposing products is a common practice.  The logical and fashionable conclusion of this is implementing Micro Services.

But what about the typical traditionally Operations concerns such as DBAs, Systems Administrators, Network Administrators, etc.?

  • We could consider trying to embed them into the end-to-end application team, but, in reality, that is going to cause those teams to get too big.  And it is also likely to lead to duplication and potentially un-necessary complexity and fragmentation.
  • We could make them available as some kind of support pool, but that is inevitably going to lead to contention and queueing.

My recommendation is to recognize that such concerns aren’t just performing a support / operations role.  In fact, they are Infrastructure Coders also performing a development role. The platform is their product and is as much a first-class product as the business applications.

A new approach
Potentially, we now have a new approach and a new mind-set for something that has traditionally been very hard to define and had ownership shared by lots of teams.  We have a way to tackle something I think is almost always the greatest constraint to IT delivery.

We can define a platform application as a thing on which everything else is run (“everything else” could be called your business applications).  This assumes the responsibility of abstracting away all non-core hosting details from the application, allowing the business product teams to focus only on their product.  For example:

  • Being the only thing close to being aware of hardware
  • Handling requirements like high-availability, auto-recovery and auto-scaling
  • Handling installation and configuration of all software that sits on top of the operating system, but below the business applications, so this could be a MySQL installation or RabbitMQ etc.
  • Implementing a clear strategy for easily creating, re-creating and deleting environments in a self-service manner
  • Supporting easy deployments of the business applications onto it
  • Supporting configuration management and Continuous Delivery

The great thing about defining your platform-as-an-application is that it suddenly has a lot more in common with the other applications:

  • All products need to be developed and supported and owned end-to-end.
  • All teams are essentially doing the same process:
    • Controlling scope, developing code and testing it
    • Managing dependencies with other applications
    • Releasing code, and ideally doing Continuous Delivery
    • Supporting it.

Making progress on a DevOps journey can be difficult but I believe re-evaluating your attitude towards the platform to be a valuable and tangible step forward.  I’m also proud to now say that the DevOps Platform that my team developed is now open sourced, here on GitHub.  It makes implementing the tools needed in the platform trivial therefore allowing you to focus on environments and completing your end-to-end platform application.

Topics highlighted

Applications

Popular Tags

    Archive