A Cloud Migration That’s Going Somewhere – the Humana Story with Jon Cwiak

About a year ago I had the pleasure of meeting with Jon Cwiak, an enterprise architect at the insurance giant Humana. I love the Humana story and I’ve been watching them overcome obstacles and challenges along the way – they always move upwards and their cloud migration effort is really starting to gain traction.

Jon’s one of those hero architects I wish were more common in our industry; he’s a purist with a very strong vision of what cloud development and architecture means, but he’s pragmatic and engaging in how teams chart their course to get there. I think you’ll love this discussion, which explores some of the topics we covered in his interview in Achieving DevOps!

A link to the interview is here – and it’s on the podcast platform of your choice. Apple, Google, Spotify, blah blah….

Here’s some of the topics we cover in the podcast:

  • Humana’s swing for the fences with their cloud migration
  • Why do good architects start with empathy – and what impact can this have on a project?
  • “DevOps isn’t a role or a title – it’s a set of practices that you do.”
  • How does Humana build a sense of community, and what 4 pillars do they look at in migrating workflows to the cloud?
  • Does Humana insist on a specific set of tools for monitoring, release, etc?
  • What does monitoring look like at Humana? And what about security – how does Humana handle their data stewardship without overloading engineers?
  • Does everything need to be a microservice? Where does Humana start in peeling off services and flows that would be a good fit for microservices?
  • On COTS products and buy vs build – “You buy for commodity and build for differentiation. I’m not going to build my own log analytics platform – that’s a solved problem. Then I can go on and solve more interesting problems.”
  • Moving away from big, destructive tsunami releases: “Shipping is a feature – do so early and often.”

 

I really enjoyed my talk with Jon, and I think you will too! Let me know what you think, and enjoy!

Advertisements

DevOps Is About Habits, Not Outcomes

It’s a Friday; a good time to reflect and think a little about what I’m grateful for, and what I’ve learned. I wanted to share with you a little story and what it taught me about myself and how to create lasting change.

In November of 2018 I went in for a routine checkup to my doctor. It had been a while – like five years – since my last visit. A few days later I got the news: I had full-blown Type 2 Diabetes. I go into this more in my book, but this was shocking to me, and I went through all the stages of denial, anger, and guilt. Guilt especially – diabetes is a lifestyle disease. I had done this to myself, with too much pizza and beer, too much time on the couch.

While I was struggling with coming to grips with my new limitations, I found two amazing resources: “Tiny Habits” by Dr BJ Fogg, and the book “The Power of Habit” by Charles Duhigg. Both are game changers. Finally, I realized why all the grand resolutions and big pushes I’d made to change my lifestyle had ended up in failure, and how to create change that sticks.

Basically, I was trying for a “Big J” – an all out effort, based on a big New Years Day type resolution. “I am going to lose 30 lbs in 3 months!” To do this, I’d embark on all-out ‘personal transformations’ – radical diets, 2-hour gym torture exercises. You know the deal! Well, guess what – maybe a few weeks later, or a month at most, I’d be back on the couch – discouraged, depressed. What had happened?

Interestingly, a friend of mine had a similar “now what?” moment – when a doctor told him he needed to change or he’d be dead in ten years. My friend went home and decided to try something he liked – getting on a bike. So every day when he got home, he’d bike 3 miles from his home. This was an easy, low-effort habit to start with. After a month or so, he started going for 5 miles… then as far as 10, on weekends. Then he joined a riding group. Three years later, he’s dropped thirty pounds – all by doing something he likes, starting small, and gradually ramping up his positive habit.

Too much change, too fast, is a sure recipe for failure. It takes a significant amount of energy to get up and go to the gym for 2 hours, for example. I’ll bet, after a week or so, you’ll hit snooze on your alarm clock and go back to bed – or a friend will come to visit – and that speed bump will leave you right back where you started, frustrated and discouraged.

Both Charles Duhigg and Dr Fogg point out that like any other chemical reaction, it requires energy to start anything new and overcome inertia – something called “activation energy”. Lowering that activation energy is the key for success. So, you might do something simple – like lay out your clothes the night before, so its easy to get to the gym. Or you could start with a 10 minute a day goal in the gym. The point is patience. It took you years to get to this point; it’ll take you years to dig your way out.

I’ll repeat those three common factors in failing to create change:

  • Trying too much change too fast.
  • Not planning for failure. (Something is going to break your routine. What then?)
  • Thinking in terms of big outcomes and aggressive goals.

But the point is, what you are trying to do is not based on an outcome. You aren’t thinking about losing 30 lbs for example. You’re trying to establish a habit, one that sticks. Dr Fogg for example started with doing a single pushup every time he went to the bathroom. Five or 10 pushups would have been too much – a single pushup was just right for that low activation energy target. And a year later – lo and behold, he’s doing 50 pushups a day, easily and without much effort.

So to create lasting change, we want to change that big “J” shape to a bunch of little J’s. Something like this:


Change means risk, and risk means… well, you know. A lot of companies attempt the “big push” like this – calling it a “DevOps transformation”, or a Digital Transformation, or a Cloud Migration. Most will end up in failure, and the reason why is simple: too much change is happening too fast, and often their measures of success are targeting outcomes. They’re not thinking about habits, and they’re not taking into account the constraints of the enterprise. Put simply, change means risk – and most enterprises have a long successful history of operating in a certain way. A company like that simply does not pivot on a dime.

That’s why you’ll see many of the people presenting at DevOps events working elsewhere a few years later. Change is risky. If we fail in financial goals, we end up in debt to credit cards, discouraged. If we fail in health goals, end up on the couch, frustrated, apathetic, risk health. And if we fail in managing change for our company, make promises we can’t deliver on, that’s a career ending decision.

Here I have to give a shout out to my favorite local gym, 3 Peaks Crossfit. About 8 months ago, I started going, and I hated every day. Some weeks I could only go a few times – but I told myself I’d give it a year to see if I could make this one habit stick. They do a few interesting things:

  1. They are all about building habits. So it’s encouraged to sign up for classes, so you’re accountable – and to come in as often as possible. Daily is best.
  2. They have a whiteboard on the wall, where you write down what you lifted, or your time. It changes every day, but over time you can clearly see progress.
  3. The workouts can be tuned so that anyone at any fitness level can participate. Some people do full-on pullups – others stay on the ground and swing their legs. But, everyone is moving, and no one is stretched too much beyond their limits.

 


Think about how to make your goals small and achievable. Remember the three keys for success with lasting change:

  • Small and achievable
  • Simple and clear
  • Habit oriented, not about outcomes.

What does that look like in DevOps? It could look something like the following:


I just pulled out a few sample limiting factors, and what might help address that pain point. But making this even simpler – if we treat the delivery pipeline like a garden hose, the problem COULD BE in the middle somewhere. Say it’s not using version control for our environments (DevOps has been defined as ‘coding for Operations’), or infrastructure as code. Or maybe it’s a worthless or missing test layer, so our deployments constantly fail. But quite often we find it’s the beginning or the end of the hose that’s the problem. Maybe we’re making guesses on what features will be valuable, so 75% of our development is being wasted. (Imagine being able to multiply your dev staff by 4x! That’s what HDD can offer.) Or we have no blameless postmortem process, so bugs keep getting swept under the rug and problems keep getting repeated. Or there’s no telemetry or monitoring to knock down problems quickly and keep our availability up.

Enough with the nerd stuff though. Getting back to that gym, and what makes it special – they’ve got a list of values on the wall. It calls out specifically that negative talk, about ourselves or others, is not allowed. Crossfit recognizes that out of our thoughts come our abilities. So let’s be careful about labels. If we think and say things like:

  • “I’m stuck in a rut.”
  • “I never get ahead.”
  • “I’m lazy.”
  • “I’m incompetent.”
  • “My boss hates me.”
  • “I can’t because…”

We are creating a negative feedback loop, reinforced by the language and labels we give ourselves. But if we say:

  • “I love learning.”
  • “I’m capable of anything.”
  • “I always do my best.”
  • “I’m a great teammate.”
  • “In this one area I can…”

Whoa, that’s a different story! That’s a self-reinforcing, virtuous cycle. The fact is, ANYTHING is possible with enough practice and consistent effort.

Anyway, that’s my positive thought for this Friday. You can do ANYTHING if you set yourself up for success, one habit at a time.

Want video or audio of this? Check out our podcast using Apple, Google, or the podcast host of your choice – and also on my Youtube channel. And, of course, there’s more like this in my book. Enjoy!

Interview with Abel Wang – Part 3!

On our podcast this week, we get a chance to chat with one of my good friends Abel Wang from Microsoft. This one was so GOOD we had to stretch it out into three parts to make it fit our podcast. You’re gonna love it! (Click the links here for Part 1, Part 2, and Part 3)

Check out Part 1 and Part 2 for more… but this discussion is muy caliente! We talk about testing, the power of feature flags (Abel’s a tireless advocate for LaunchDarkly, one of our faves), how eliminating flaky tests is key, and Dynatrace.

  • [1:00] – The power of feature flags
  • [3:03] – Capability matrixes
  • [6:00] – “Quality used to be something we just worried about at the end of the project… You just can’t move at speed without unit testing!”
  • [9:41] – Unit tests are for regression errors.
  • [12:08] – killing flaky tests – is a “red” build really red?
  • [15:00] – Azure DevOps’ unique advantage in dogfooding – we can be our own guinea pigs with release rings!
  • [19:10] – Dynatrace and the unbreakable release pipeline – using AI to catch and roll back on issues quickly
  • [20:55] – What does the future hold? We look into a crystal ball and think about where we’ll be in 10 years.
  • [22:50] – Is lift and shift an antipattern?

 

Click below to check out the podcast. We’re on all the major platforms now, including Anchor, Apple, Google, Spotify, PocketCasts, and RadioPublic.

 

Links to live by:

Interview with Abel Wang, Part 1!

On our podcast this week, we get a chance to chat with one of my good friends Abel Wang from Microsoft. This one was so GOOD we had to stretch it out into three parts to make it fit our podcast. You’re gonna love it!

(Click the links here for Part 1, Part 2, and Part 3)

I love the energy Abel brings to the table, and his background as a serious coder makes his advice both pragmatic and spot on. He’s a fantastic speaker as well, if you’ve ever had the chance to catch him at a conference. (Check out his latest from Build 2018!) He wrote the foreword to my book, and with our conversation we got a chance to revisit some of the things we love most about DevOps and where we see the movement going in the future.

A little bit about Abel – he’s a Senior Cloud Developer Advocate specializing in DevOps and Azure with a background in application development. He is currently part of Donovan Brown’s League of Extraordinary Cloud DevOps Advocates. Before joining Microsoft, Abel spent seven years as a Process Consultant and a Certified Scrum Master helping customers globally develop solutions using agile practices and Team Foundation Server. Prior to that, Abel founded and sold his own software company. Abel’s a lifelong coder and I think you’ll find this conversation very interesting… We cover a lot of ground in this episode, so much so that I split our talk into three parts.

Part 1 includes the question that got Abel first thinking about DevOps, how to get CXO buyin, the power of one success story, the #1 pitfall he sees with change efforts, and do we really need QA?

  • [1:00] – How little habits build up to success
  • [2:24] – The question that got Abel thinking about DevOps (why do some projects succeed and others fail?)
  • [6:30] – Getting CXO/director buy-in
  • [10:20] – All you need is one team, one success – it catches on like wildfire!
  • [13:20] – Start with what hurts the most! And Abel’s #1 rule for success
  • [17:55] – Do we really still need that QA department?
  • [19:26] – Knowing what we don’t know, and experimenting.

 

Click below to check out the podcast. We’re on all the major platforms now, including Anchor, Apple, Google, Spotify, PocketCasts, and RadioPublic.

 

Links to live by:

Interview with Abel Wang, part 2!

On our podcast this week, we get a chance to chat with one of my good friends Abel Wang from Microsoft. This one was so GOOD we had to stretch it out into three parts to make it fit our podcast. You’re gonna love it!

(Click the links here for Part 1, Part 2, and Part 3)

Check out Part 1 and Part 3 for more…

  • [1:00] – Painful! Dave finally pronounces “hypothetical” correctly…
  • [2:24] – How does Microsoft power their experiments with telemetry? Abel talks about “doubling down” on success.
  • [5:39] – Engineers, stop negotiating on quality! Abel covers how to deliver estimates so unit testing and telemetry aren’t always on the chopping block.
  • [12:16] – “Quality is nonnegotiable… Quality has a cost. You have to be willing to pay it.”
  • [14:40] – “Not enough people are adding security to their release pipelines.”
  • [16:00] – We talk about pipelines, and how to handle managing interdependencies with versioning. “The complexity is well worth the cost!”

 

Click below to check out the podcast. We’re on all the major platforms now, including Anchor, Apple, Google, Spotify, PocketCasts, and RadioPublic.

 

Links to live by: