Docker CEO Steve Singh Interview: All About That Migration To Cloud

The single biggest one is the move to public cloud, and this is where Docker is focused today. This is the number one area that we are putting all our investment in. We have this great container platform that allows you to do a lot of things, but just like any company, we need to pick an area of focus and for us, helping customers take legacy apps, moving them to the Docker platform, and allowing them to run it on any infrastructure because it’s hybrid cloud world, does a couple of things — it drives massive savings for customers, typically 50 percent cost reduction in a cost structure, but it also opens up real opportunities for the customer and our partners to innovate within that environment

Also, this is an insanely good example of a fluffy leather chair conference interview, plus, The Channel filter.

More:

Where does the 50 percent savings come from? A few different areas. The biggest is, honestly, in the mass reduction in number of VMs [virtual machines] and that’s not good or bad, it’s just the reality. The other is that there is a massively increased density factor on compute, and so we can put a lot more workloads on a fewer number of servers. If you are a [company like] Nestle, and you are going to take a bunch of information and business systems and move it to the public cloud, doing a one-to-one move is not necessarily all that advantageous.

Partners:

When I joined Docker I had a good conversation with someone over at Microsoft that said ‘I’d love to partner with you.’ His view was, the more people move to Docker, the more business they get on Azure. In fact, for every dollar we generate, he generates $7.

Momentum and the EBIT(A) chase:

we’re growing at 150 percent-plus year over year and expect that to continue for at least another few years. I’m hoping to get to profitability in mid-2019, and that’s important

Source: Docker CEO Steve Singh On The VMware Relationship, Security, And The Opportunities Around Containers For Partners

Core DevOps (tech) metrics, from Nicole Forsgren

Everyone always wants to know metrics. While the answer is always a solid “it depends – I mean, what are your business goals and then we can come up with some KPIs,” there’s a reoccurring set of technical metrics. Nicole lists some off:

These IT performance metrics capture speed and stability of software delivery: lead time for changes (from code commit to code deploy), deployment frequency, mean time to restore (MTTR), and change fail rate. It’s important to capture all of these because they are in tension with each other (speaking to both speed and stability, reflecting priorities of both the dev and ops sides of the team), and they reflect overall goals of the team. These metrics as a whole have also been shown to drive organizational performance.

And, then, further summarized by Daniel Bryant:

Key metrics for IT performance capture speed and stability of software delivery, and include: lead time for changes (from code commit to code deploy), deployment frequency, mean time to restore (MTTR), and change fail rate.

Also in the interview, a concise DevOps definition:

I define DevOps as a technology transformation that drives value to organizations through an ability to deliver code with both speed and stability.

See the rest.

Pivotal Conversations: The management perspective on transforming Allstate, with Opal Perry

I’m always interested to hear how management manages to change how software is done in large organizations – it can seem impossible! As ever, Allstate provides a fascinating stream of information here, and I was lucky to get the chance to interview Opal Perry there on how Allstate has been doing with all that cloud-native stuff.

Check out the listing on SoundCloud, and be sure to subscribe to the podcast if you like it.

Also, if you want to hear more, Matthew Curry and I had a similar conversation a few weeks ago at OSCON.

Coté Show: Biz Dev, Defining an application, the atheist eagle scout, with JJ Asghar

Another interview, mostly on cloud and other dorky topics:

Having worked in cloud since before cloud, JJ and I talk about what companies are using various cloud things for. We also discuss the conceptual history of cloud, and what exactly he does as a “business development” person at Chef.

Subscribe, tell your friends, or just download the episode directly.

Reactive applications, with Josh Long – Coté Show #18

While in San Francisco for a Pivotal meeting, I recorded an episode with Josh Long. We talk about what reactive programming is and why you’d use it. Also, dish towels. Also, check out the livestream of this if you’re into video.

If you haven’t subscribed already, subscribe to the Coté Show. I do little monologs and interviews like this in it, somewhat irregularly.

Gary Gruver interview on scaling DevOps

I always like his focus in speeding up the release cycle as a forcing function for putting continuous integration in place, both leading to improving how an organization’s software:

I try not to get too caught up in the names. As long as the changes are helping you improve your software development and delivery processes then who cares what they are called. To me it is more important to understand the inefficiencies you are trying to address and then identify the practice that will help the most. In a lot of respects DevOps is just the agile principle of releasing code on a more frequent basis that got left behind when agile scaled to the Enterprise. Releasing code in large organizations with tightly coupled architectures is hard. It requires coordinating different code, environment definitions, and deployment processes across lots of different teams. These are improvements that small agile teams in large organizations were not well equipped to address. Therefore, this basic agile principle of releasing code to the customer on a frequent basis got dropped in most Enterprise agile implementations. These agile teams tended to focus on problems they could solve like getting signoff by the product owner in a dedicated environment that was isolated from the complexity of the larger organization.

And:

You can hide a lot of inefficiencies with dedicated environments and branches but once you move to everyone working on a common trunk and more frequent releases those problems will have to be address. When you are building and releasing the Enterprise systems at a low frequency your teams can brute force their way through similar problems every release. Increasing the frequency will require people to address inefficiencies that have existed in your organization for years.

On how organization size changes your managerial tactics:

If it is a small team environment, then DevOps is more about giving them the resources they need, removing barriers, and empowering the team because they can own the system end to end. If it is a large complex environment, it is more about designing and optimizing a large complex deployment pipeline. This is not they type of challenges that small empowered team can or will address. It takes a more structured approach with people looking across the entire deployment pipeline and optimizing the system.

The rest of the interview is good stuff. Also, I reviewed his book back in November; the book is excellent.

Link

Puppet and containers

When we’re talking with customers about the value that Puppet brings to them, invariably we talk about the future, and the future in their mind in some ways includes containers. There’s a lot experimentation going on. There’s a lot of Docker work being done and container work being done, Kubernetes work being done on their laptops. The conversations we have with them is how does Puppet help you bring it into production, into mission-critical production? How do you keep it secure? How do you operate it? All of those things that we know how to do and have done with various kinds of infrastructure, whether it was OpenStack, whether it was virtual machines, whether it’s just server configuration. For us, we take the same approach to containers and are evolving our road maps to make sure that customers have the same benefits they’ve have had over the years now with containers or other technology.

From an interview with Puppets CEO, Sanjay Mirchandani.

Link