Ian Andrews explains and whiteboards out how all the cloud-native infrastructure fits together:
Go to 7m21s if you want to skip right to the diagraming.
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.]
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.
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.
- (~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.
There’s plenty to like in here from this 2013 talk, tips and such. Also, see this more recent interview, in text, for example:
[Y]ou have to start with a position that all organizations (it doesn’t matter what industry you’re in) are going to be disrupted by highly agile, highly automated competitors who leverage technology to be the disruptive force in the sector. And, businesses clearly have a choice as to whether they are going to be the ones doing the disruption or whether they are going to be the ones having to respond to the disruption. But in either case, it depends on your ability to adapt, change and to compete. We live in a world that is increasingly digital and where technology is the lever through which much of that computation takes place. My advice to IT folks is that you’ve got to be able to have that conversation in the voice of business leaders – you’ve got to be able to articulate that reality in a language that can be understood. This is not a technology conversation, it’s a business and a competitive strategy conversation.
Also, see the slides.