Advice on introducing DevOps from Merrill Corp & SPS Commerce – Highlights

Nicely moderated by Bridget. Some of my notes and highlights:

  • Amy talks about pace of change, sustaining it in the beginning, etc.
    • The amount of time it took us to get going was a surprise – was longer.
    • If you can start to show results early, it helps build up momentum. “Having enough wins, like that, really helped us to keep the momentum going while we were having a culture change like DevOps.”
    • It takes the right people to keep that energy going, but also be able to go back to the business to show that why we are putting these changes in place.
    • You’re going to be able to see the changes to the business right away.
  • Peg – tools, don’t try to fix the old ones, like ITIL service desk tools. Instead we just had Jenkins open tickets and such, automating the toil of dealing with old tools
  • Global/offshore tactics, from Amy:
    • What with all the retrospective stuff, you need to be able to get teams together, physically. The collaboration angles are much better in person
    • Set-up each “shore” as an architecturally and management island, make them as independent as possible. They also need their own context, not held up by time zones so they don’t need to wait 24-48 hours for authorizations and collaboration. [To my mind, this means taking advantage of the organizational de-coupling you can get with microservices.]
  • Starting change, even when they company needs it. Amy: You have to start with the business need, what’s the big driver behind a change like DevOps. [Managers often don’t make sure they figure this out, let alone decimate it to staff.]

Not actually a DevOps talk

I get asked to talk on DevOps a lot. Here’s my current (late 2016 and 2017) presentation, going over the why’s, the how’s, the technologies, and the meatware that supports including some best and worst practices based on what Pivotal customers do. See the newer slides with big pictures on most slides, and some of the older slides

Also, here’s a more blatantly pro-Pivotal (and longer) version that you might have seen, esp. if the talk title was something like “Digital Transformation in the Streets.”

Much of it draws a lot on my cloud native journey booklets as well.

Stop Hitting Yourself. Tips for Succeeding at Digital Transformation

Check out this fine panel from DellEMCWorld:

Observations on how large organizations successfully go through Digital transformation.
When it comes to digital transformation, despite vast resources, large organizations are 40% less likely to be high performing organizations than smaller ones.

Cloud Platform Adoption: Lessons Learned — Philip Glebow, Gap

Gap’s Philip Glebow goes over their use of Pivotal Cloud Foundry, including things that worked well and need improvement. His list of the supporting tools they use – like APM and data virtualization – is handy as well.

Some items:

  • (~2:30) Fast deploys: “We can deploy changes faster than people can really consume them.”
  • (~18:00) Developer morale: “We could really push something in five minutes… and developers love it, you click the commit button and there you go.”
  • (~19:40) [Poor transcription by me] On the danger of changing too fast: …generally we want to have a little bit of control into what goes into that production environment… but we don’t want to change so rapidly so that users are confused… There’s also a little bit of cultural change that we need to go through… ((too rapid of change is jarring)) …and as we bring that capability forward, we want to be sensitive to those concerns.
  • (~23:58) Overview of their pipeline and testing.
    (~26:29) [Poor transcription by me]  Typically we’ve organized out teams around sort of domain concepts – so we have a pricing team – then there’s several squads, then that squad is responsible for optimization – price, packing the stuff, etc. That’s how we’ve organized the teams, two pizza teams, we’ve tried to that. Also, distributed teams… sometimes that’s a little bit complicated.

Cloud Native, the why and what

We launched the Austin Cloud Native Meetup this week, on March 2nd. Marcello and I gave talks, first defining what cloud native is and then doing a demo of what a cloud native setup looks like.

Here’s recordings of the three parts, an intro, defining “cloud native,” and the demo:

Intro

Cloud Native, the why and what

Check out the slides as well.

Demo

Up Next

We don’t have the next meetings scheduled, but we do have people committed to giving talks. Diego Lapiduz said he’d come talk about the work 18F is doing with cloud.gov (you may remember him from a Lords Of Computing podcast episode and the frequently cited ATO reduction of 9 months to 2 days). And we’ll also have Amit Likhyani come down a reprise his talk from the Dallas Cloud Native Meetup, “Tibco’s Journey on Cloud Foundry”.

So, keep your peepers peeled – and sign up with the MeetUp group – and we’ll see you next time.