Warning message

  • The service having id "twitter" is missing, reactivate its module or save again the list of services.
  • The service having id "facebook" is missing, reactivate its module or save again the list of services.
  • The service having id "google_plus" is missing, reactivate its module or save again the list of services.
  • The service having id "linkedin" is missing, reactivate its module or save again the list of services.

Presentation: Beyond ad-hoc automation: to structured platforms



2:55pm - 3:45pm

Key Takeaways

  • Advice on navigating DevOps Tooling and Platforms
  • Learn to work with the right level of abstraction with DevOps Tooling
  • Hear stories of successful and not so successful solutions
  • Grok how different DevOps pieces fit together into a cohesive solution


What is your platform? Everyone has one, whether it’s Docker wrapped in config management wrapped in thousand-line fabfiles, bespoke artisanal hand-crafted shell scripts… or both! What promises can your platform make and keep? What contract does your platform provide to your applications? Does your platform deliver value rapidly, reliably, at scale... or has it become a burden unto itself? Perhaps a bit of both?

Continuous delivery has gone from an aspirational nice-to-have to a must-have capability for staying competitive at the edge of innovation. Nearly every automation project sets out to provide self-service deployments for developers with visibility and reliability for operations. Whether using configuration management or embracing containers to package workloads, we need a long list of capabilities to fill gaps in the automation. How do you provision infrastructure? Who can provision? How much? How do you deploy? Who can do deployments? What can even get deployed? What about canary deploys? Rolling deployments? Monitoring? Metrics? Fault detection? Fault remediation? Everyone across the industry has needed to handcraft a platform specific to their organization. (I’ve done it. I bet you have too.)

The operational needs of a continuously delivered microservice architecture bring with them new considerations and constraints. If the cost of deploying and operating a service is high, in terms of time or resources, deploying more things more frequently sounds like a really bad idea. The era of ad-hoc automation is coming to an end as the patterns of cloud native organizations who move quickly and safely are becoming more apparent. Between rolling your own from open-source components and implementing a turn-key platform solution, a vast array of choices exists. I’ll talk about where I’ve been (spoiler alert: containers in production without hype) and what I’ve learned on this journey.

Interview with Bridget Kromhout

QCon: What's your main goal with your talk?

Bridget: What I'm hoping that people get as a takeaway are the right questions to ask as they're trying to decide exactly how they're going to put all their containers and whatnot together.

Exactly which of these end solutions should we use? Is there a right one? Is there a right combination? I'm not sure those are the right questions to ask. I want to help people ask the right questions. Like, levels of abstraction and this notion of how much of your platform do you want pre-composed, and how much of it do you want to assemble?

QCon: You're title is Beyond ad-hoc automation: to structured platforms. What do you mean by ad-hoc automation?

Bridget: When you start trying to automate all the things (like the meme says), sometimes you find yourself automating things that after you've spent a bunch of time trying to get them running in a repeatable way, you realize that you're actually not doing it in a way that you want.

So you refactor and repeat. Just automating all of the processes that you have. Taking all the automated processes that you have and trying to glue them together is not necessarily going to give you a cohesive result.

What I've found (because I have totally done it), is when you take Lincoln logs and the Legos and a whole bunch of bubble gum and duct tape and stick them together, you will have something! And it will probably work. Moving to a structured platform is paying a little bit more attention to what’s going on (not just with Cloud Foundry and Pivotal stuff), but in the wider ecosystem.

QCon: Say I'm a DevOps person, and I'm coming to your talk. What am I going to take back afterwards?

Bridget: I think that after hearing this talk, the DevOps person in question might think to themselves: “Hey, before I came to the talk I was pretty bewildered about the differences between things like: Kubernetes, Mesos, or Mesos with something like Marathon. Or maybe the devops person was thinking: "I could roll my own just with Docker." I might be questioning whether I need these other pieces?

I'm hoping to be able to provide people with some guidance there, so that when they leave they have a better handle on how these pieces fit together. There really is no clear matrix out there for them all.

QCon: Wow! You're going to go down the matrix route? That's going to be a big matrix!

Bridget: Well, that's the thing. I don't think that there can be a clear matrix, because you can't easily align all these pieces up with each other. It's not the right level of abstraction. I think you should start from what you are actually trying to accomplish, and work backwards from that.

QCon: Who is the right audience for your talk?

Bridget: I think that this will be pretty applicable to the people who have been in the weeds and done implementation on a deep level. We can and we probably will talk a little bit about the layered file system issues that you want to think about if you are building a Docker based PaaS for yourself. Taking a step back from that, we will look at the compatibility of your entire system.

QCon: You’ve been, obviously, to a lot of conferences, done a lot of talks. What makes a really good technical talk to you?

Bridget: A really good technical talk is a conversation with the audience. Showing that you're not just giving a set of answers, context free- you know. "Your mileage may vary may or may not apply to you." I don't think that's as helpful. I think it's really more helpful when you say. “Why did I do this? What was I expecting? And then "What result did I actually get? What did I regret? And what did I feel like I learned?" I feel like those are the kinds of things that you're not going to necessarily get answers to in every blog post.

Similar Talks

Director of Tencent Social Network Group
VP of Global Platform and Infrastructure @PayPal
Technical Evangelist @ThoughtWorks
Interactive Director + Founder @ChalkChisel
Senior Director of Engineering @LinkedIn
Netty Core Developer & Cloud Infrastructure Engineering @Apple


Covering innovative topics

Monday Nov 16

Tuesday Nov 17

Wednesday Nov 18

Conference for Professional Software Developers