devopsy.kinsta.cloud

Tag: phoenix project

Winners of “The Phoenix Project” by Gene Kim From devopsy.kinsta.cloud

As one of the banners on devopsy.kinsta.cloud says we are picking some lucky winners to receive a copy of Gene Kim’s “The Phoenix Project”. To be eligible to win you must sign up for the devopsy.kinsta.cloud newsletter on the right of your screen. We have more books to give away, so it is not too late for you to win your copy.

You get a free great book and nightly updates of all the new content on devopsy.kinsta.cloud.

Here are the first group of winners:

Don Marsee, CISSP, CISM

Jon Thorson

Matthew Barr

Steven Nemetz

Their books are on the way. More winners will be announced next week!

March 21, 2014
The DevOps Journey
Maintaining a constant thirst for learning is essential for anyone dedicating their career to the IT, computer and networking industries. It’s more than just learning about the latest technologies, rather, it’s imperative we embrace new methodologies and paradigms for doing work, thinking about problems and creating solutions. Enter DevOps, which is a healthy mix of all the above.

You might find things a bit confusing if you’re new to DevOps. There are many perspectives on what it means. For myself, there were two significant milestones on my journey to understand and embrace DevOps; 1) rethinking how we design large, dynamic applications and manage the underlying infrastructure in cloud environments such as Amazon AWS, and 2) reading the book The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford.

At first blush, I thought DevOps suffered the “definition bloat” of so many other industry buzzwords (for example, “cloud” comes to mind.) Depending on who you talked to or what you read, DevOps definitions frequently encompassed one or more of the following:
1. embedding development resources within business units for better alignment and reduced cycle time,
2. high frequency software releases into production (multiple per day, hour, etc.)
3. automating infrastructure and system administration tasks vs manual provisioning and sysadmin
4. embedding operations functions within development organizations
5. operations performed by developer, even doing away with traditional operations in some cases
If these seem like a somewhat confusing, loosely assembled list is ideas, don’t fret — they struck me the same way at first too. These ideas actually fit very well together around a few core ideas essential to DevOps.

Quicker Time To Value – Being Fast and Agile

DevOps is about changing traditional paradigms, enabling us to more rapidly deliver production updates, new capabilities and improved operations. Outcomes include reducing software releases from months to multiple, micro releases per day, and even hours. To do this requires much more than can be achieved through traditional operational efficiencies. It requires tight alignment, coordination and execution by product, development and operations functions. Embedding multiple disciplines together helps gain this alignment, shorten communication paths, setting priorities quicker, enabling lightning fast coordination. DevOps promotes new practices like embedding development and operations functions within other parts of the business, breaking down long standing barriers between IT / Ops and development / business groups.

Automated Provisioning, Operations and SysAdmin

From app development to infrastructure operations, DevOps is about automation. DevOps is about faster software testing and integration, quality improvement, and working in much more dynamic and rapidly changing operating environments. For example, rather than building system images by hand (stick built), automation is used to rapidly generate and spin up new virtual environments on a small or large scale. Systems wake up, check in to learn their personality, install, configure or update code (OS, database, web server, application code revs, etc) and join the network dynamically. This can occur with a single instance or with hundreds simultaneously. Initial upgrades and feature updates can occur on smaller or isolated sections of the network, then are rapidly rolled out across the network, and rolled back quickly if necessary. Sysadmins, be they developers or ops people, use scripts, code and automation tools to manage much larger environments than would ever be possible using manual methods. Automation is an essential differentiator in any DevOps environment.

Culture of Open Collaboration, Communication and Failing Fast

DevOps breaks down silos and places a premium on collaboration and communications amongst all players involved. It’s no longer us vs. them or this department vs. that other department. The blame game is gone and the focus is on making work happen, and fast. Communication lines are drastically shortened and conflicts in chains of command are collapsed. It’s about how “we” get things done, no longer about what “they” didn’t do. Failures are viewed much differently. Failures happen and from them we learn and develop newer, better, more innovative solutions to solving problems and prevention problems in the future. Because of the speed DevOps can bring, recovery from failure is much quicker. If a new release into production is causing issues, we quickly flip back to a previous known-good version running on other virtual instances. Updates can also be rolled out much more quickly.

I hope these and coming views on DevOps are valuable to you as a reader. I know our conversation will help me and the teams I work with, as we learn and grow our expertise in DevOps. Please share your ideas, disagreements and learnings as we move along this journey together into the fast moving and quickly changing world of DevOps.
March 16, 2014
A Q & A with Gene Kim: DevOps and What Separates High Performing Enterprises

We recently caught up with Gene Kim (@realgenekim) as he was wrapping up the final touches of a draft of the upcoming DevOps Cookbook. We wanted to get his thoughts on what causes IT deployment failure, the DevOp movement, and finally what separates high performing IT organizations from low performing ones. If you’re following DevOps, no doubt you are familiar with Gene. In case you are not, Gene is an award winning CTO, researcher and author. He founded the security firm Tripwire, and was the CTO there for 13 years. To date, he’s written three books, including The Visible Ops Handbook and The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. Gene is a huge fan of IT operations, and how it can enable developers to maximize throughput of features from “code complete” to “in production,” without causing chaos and disruption to the IT environment. Now, let’s jump into our discussion.

devopsy.kinsta.cloud: When organizations decide they want to move to DevOps, or continuous delivery, what is a barrier that they immediately run into? And is DevOps something all types of companies can embrace?

Gene Kim: In my mind it’s the unicorns (leading web app companies) that are sort of showing the way out. Just to show why I’m so interested in this, you know I’ve been studying high performing IT organizations since 1999. What I’ve noticed is that there is this downward spiral that happens in almost every IT organization. It led to more fragile application in production, longer deployment times, building up of technical debts, and the business goes slower and slower. I think one of the reasons that I cared so much about is that it led to preordained failure. Where people felt, especially downstream (operations, test, security) trapped in a system where we were powerless to change the outcomes. No matter what we did, failure has been preordained. I think the way out of the downward spiral is what organizations like Google, Amazon, Twitter, LinkedIn, GitHub, are doing. These organizations are doing tens, hundreds, or even thousands of deploys a day. In a world where most of us are stuck with one deploy every nine months with catastrophic outcomes. I think that the first objection is that we’re not an “Amazon,” we’re not a “Google,’ we’re a bank, we’re telco, we’re a retailer. That it doesn’t apply to them. However, it turns out if you look at who’s adopting DevOps it’s Nordstrom, Walmart, General Motors, SAP. One of the statistics that I saw was, that Google has 15,000 engineers, or developers. HSBC, the European bank, has 15,000 developers. I think every company is an IT company regardless of what business we think we are in. I think it just shows that anything we try to get down relies on IT. So for DevOps not to be a core competency is absurd.

devopsy.kinsta.cloud: And even increasingly software has to become a core competency, as more devices become API-enabled? All companies are software companies now.

Gene Kim: I love that Jeff Immelt, CEO of GE, quote: “Our biggest fear is being disintermediated by software. So I’m going back to school on software and big data.” I imagine that they run into that same objection internally. “Hey, we’re not Netflix, we’re not Amazon.” Right? They are trying to sell the idea of moving to DevOps or becoming more agile. Anyone can do it and benefit from it. Even in general conversations that was the first objection that always came up. Well that’s good for so and so, but we’re not so and so. I think that makes it a belief issue. So that’s what we’re talking about here, right? It can’t work here. I think it a serious of problems and it’s very predictable what the bottlenecks or obstacles are. The first one is that it takes too long to do the deployments, actually you can go a step before that. One of the biggest problems is that operations is always in the way. Whenever a dev or test wants a test environment it’s not uncommon in typical enterprises, that it takes 40 weeks to get one. Back in my Tripwire days, I use to think that developers didn’t like testing the code, because that’s what I saw. The truth is even worse than that; the developers really want to test their code. Their problem is they can never get an environment when they want one or they need one. So the survival mechanism kicks in, they’ll always go to the guy they know that’s really good at getting an environment, Their Corporal Klinger or Nash. They don’t want to ask any questions about where it came from, because you know someone is missing a server somewhere. This person probably just stole an environment from another project. With virtualization and infrastructure code there’s no almost no excuse not to be able to create environments available on demand. One of the things that we did, with Puppet Labs, is we reached out to me to help design their DevOps benchmark. This was awesome, when I found out about it I jumped out of my chair because, I saw this as a logical continuation of ten years of benchmarking we had done.

devopsy.kinsta.cloud: What have you learned that separates high-performers and makes DevOps possible?

Gene Kim: There were three findings about it that blew me away. The first one is the high performers were massively outperforming their non-high performing peers. Thirty times more frequent code deployments. They were able to complete the deployments from code committed to running a production 8,000 times faster. In other words they could do a deployment measured in minutes or hours. Whereas low performers it took them weeks, months, or quarters. Furthermore, they actually had better outcomes. Twice the change success rate and when they caused outages they could fix it 12 times faster. There were 4,200 that completely responded and it just showed that you could be more agile and reliable at the same time. I think if we just connect some dots, they’re also going to be more secure, they’re probably going to have a faster find fix cycle time. We didn’t actually test that but, if that were true it would mirror what we found in the previous benchmarking work I had done. So that’s surprise number one the extent that they were out performing their non-high performing peers. Second surprise, we found two behaviors that were present in every high performer but they were universally absent in every non-high performer. The first one was that they are they checking in all their production artifacts and version control. Meaning, they could reproduce a production environment based off of what was in version control. Versus only it being an indescribable asset that only one person understood, if they knew about it at all. The second one was is there an automated code deployment process? Which includes being able to create environments available on demand. The next one is the code deployment process. I think it’s very typical in most enterprises that whenever you want to do a new release or deploy it takes days or weeks to complete. Involving tons of hand-offs from the developers, DBA, release team, back to the developers to the security people, and the firewall change and so forth. All that creates delays and is error prone and so forth. In the high performer there usually a one click to deploy or an automatic deploy. If you look at Google, Amazon, Twitter, Facebook, in general they have a continuous deployment process so that when a developer checks in code it automatically runs all the tests. Then it puts it into an integration test environment and runs all the tests there. There might be some manual work, but then in general it automatically migrates to production. Clearly, that’s what’s required to do multiple hundred of deploys a day.

devopsy.kinsta.cloud: That is incredible to learn, Gene. A lot of fascinating findings. Thanks so much for your time.

Gene Kim: Thank you, George. Always a pleasure speaking with you.

March 16, 2014
Is DevOps Ready to Cross the Chasm to Mainstream?

There are just a handful of business books that I have read that have had a profound influence on me. One was Gene Kim’s “The Phoenix Project”, another was Eliyahu Goldratt’s “The Goal”. A third one was Geoffrey Moore’s, “Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers”. Even though written in the early 90’s, it is as relevant today as it was then. Though our technology has changed (dare I say advanced), the adoption curve of who uses it has remained static.

When I look at the world of DevOps today, to me it is on a classic chasm model. The real question is will it or rather how quickly will it make the hop over the chasm into mainstream. The picture above is a great representation of the chasm. Most technologies go through the enthusiast period, moving to the visionary. I would say that DevOps has been in this visionary period for a few years now.

In order for any technology to jump the chasm it needs to build up enough momentum and critical mass to successfully make the jump. Now there are some technologies that never build up enough critical mass to successfully jump over to the pragmatist’s cliff of mainstream adoption.

Back in my StillSecure day’s NAC had a tough time making the jump. It was not until mobile technology and BYOD served as ignitions that NAC made the cross-over to mainstream. But enough about NAC lets return to DevOps. For DevOps the Cloud and virtualization have been ignition points. Using software to replace hardware has allowed for rapid deployment, automation and continuous delivery models that characterize DevOps.

With so many pundits and analysts predicting that this is the year Cloud goes mainstream (I thought it did already), DevOps will not be far behind. As disruptive as Cloud is, could it be as disruptive if not for DevOps? There is a symbiotic relationship between the two.

But it is not just Cloud alone. DevOps has other boosters that will help it over the chasm. SDN is another big boost. Software will eat the world according to Marc Andresseen. It may very well start with networking hardware. But software is eating more than hardware.

One of the hottest trends in security (and one you will see featured here in the SecOps neighborhood of blogs on devopsy.kinsta.cloud) is Software Defined Security. It may sound like marketing speak to you, but it involves putting security right into the virtual, software stack. It is DevOps for security. In fact DevOps and security is something you are going to hear more about from the likes of Josh Corman, Dave Mortman and Dwayne Melançon and others. Their “Rugged DevOps” discussion is ripping through the security industry for the last year or more.

All of the above aside the real key for DevOps to making the leap is that instead of just enthusiasts and visionaries being involved, what Moore calls “the Pragmatists” get involved. These pragmatists are not hung up on labels or new versus old. They just want to get the job done. If DevOps will help them get the job the done, that is good enough for them.

The pragmatists make up a good chunk of the mainstream market. The silent majority if you will. To win these pragmatists over DevOps just has to show that its benefits are real, quantifiable and worthwhile. The good news is that the Pragmatist are the first group on the other side of the chasm.

Having the Pragmatist as the first part of the mainstream is a good thing, because after that it gets harder to gain traction. According to the Chasm model after the Pragmatists come the Conservatives. Though not quite reactionary, this group doesn’t like change. They won’t change until they are nearly forced to by business pressures. They will resist adopting DevOps just because it is different than what they do now. Generally technology has to be pretty mature, its benefits well established before this group will consider doing anything more than a small trial. With DevOps representing as much a change in philosophy and culture as it does new tools, this is a really bitter pill to swallow for the Conservatives.

I would think we are years away from DevOps making real traction into this group. Especially when there are still some folks who claim that DevOps is DOA, DevOps is much ado about nothing, that it is doomed to failure. But hey there are people who still say that the science doesn’t point to climate change and that we should teach creationism in schools.

Call me the eternal optimist though. I do think that as Cloud and the other catalysts behind DevOps continue to expand, DevOps will be swept up even into the conservative base.

Between Conservative and Pragmatist, a large slice of the market is spoken for. Added to the pre-chasm market and DevOps is well beyond critical mass. Whether the last segment of the market, the skeptics ever adopt is not even relevant. Many of these skeptics have a bone to pick. As I have grown older I am convinced that they are just wired to be skeptics. They literally look at everything through a half empty glass.

So there is little doubt in my mind that DevOps will not be a stillborn technological movement. It has the catalysts, the benefits and most importantly timing and circumstances are lined up to help push this from the early adopter crowd and right over the chasm into the mainstream. What’s more is I think this is already under way and will be much quicker than most people think.

This is all a big reason why we launched devopsy.kinsta.cloud. There is a big enough critical mass now to support a site dedicated to DevOps like this. But as we cross the chasm to mainstream, we want to ride the crest of the wave, helping to bring DevOps to pragmatist, conservative and anyone else who would benefit from it.

March 14, 2014
How We Can Help DevOps Cross The Chasm

The problem that DevOps solves is universal, urgent and important. Every IT organization is responsible for two things: deliver fast flow of projects and features, while preserving reliable, stable and secure services. Until very recently these were thought to be mutually exclusive, we thought it was only possible to achieve one of those objectives, at the expense of the other. This caused years (or even decades) of inter-tribal conflict between Development and IT Operations; led to chronic underperformance, with features taking slower than ever to reach market, deployments taking longer, an ever-increasing number of Sev 1 outages, and IT Operations becoming buried in technical debt and unplanned work; and a variety of other symptoms.

We now know that there is a better way. The proof is that high-performing organizations such as Amazon, Google, Twitter, Etsy and Netflix, are adopting a set of techniques that we now call DevOps, and are routinely deploying hundreds or even thousands of code deployments per day, while preserving world-class reliability, stability and security.

During the 2012 Puppet Labs DevOps Survey of Practice ), we benchmarked over 4000 organizations. We found that the high performers were massively outperforming the low performers. Those employing DevOps practices were doing 30 times more frequent code deploys, and had deployment lead times measured in minutes or hours, versus weeks, months or quarters.

DevOps organizations also had far better deployment outcomes: Their changes and deployments had twice the change success rates, and when the changes failed, they could restore service 12 times faster.

This is what every IT organization needs to be able to replicate.

DevOps Isn’t Just For The Unicorns

“If there’s anything that all horses [enterprise IT organizations] hate, it’s hearing stories about unicorns [DevOps shops]. Which is strange, because horses and unicorns are probably the same species. Unicorns are just horses with horns.” — Christopher Little

We know that without something like DevOps, IT organizations will fall into the downward spiral. However, most enterprise IT organizations will come up with countless reasons why they cannot adopt DevOps, or why it is not relevant for them.

One of the primary objections from horses is that all the unicorns (e.g., Google, Amazon, Twitter, Etsy, etc.) were born that way. In other words, from their beginning all unicorns used DevOps style work patterns.

In reality, every unicorn at some point in their history had the same problems as horses: an inability to grow capacity fast enough to keep up with market demand, dealing with years of accumulated technical debt, lack of automated testing to sustain high rates of change, monolithic and overly tight architectures that prevented developers from being productive, and so forth.

The unicorns have made the journey that every horse will need to make.

The DevOps Survey of Practice showed that DevOps isn’t just for unicorns. Not all of the 4000 or so respondents were startups, and they weren’t all web operations companies either. Instead, 42% of the organizations that were implementing DevOps practices had over 500 employees. The link to those slides is here.

DevOps is equally relevant for startups as it is for legacy enterprises. The need to decrease time to market and shrink lead times is universal. In fact, it may even be more urgent for the multi-billion-dollar enterprises – creative disruption is making the tenure of Fortune 500 companies ever more tenuous. Richard Foster, a professor at Yale University, has said that the average life of a Fortune 500 company has decreased from around 75 years to 15 years in the last half century. Of the Fortune 500 companies in 1955, 87 percent are no longer on the list.

Increasingly, IT is the value creation and customer acquisition engine for organizations. As my friend Chris Little says, “Every company is an IT company regardless of what business they think they’re in.”

DevOps Isn’t A Fad

I compared the plight of DevOps to apartheid. With ridiculously worse conditions and a much more self evident problem, Nelson Mandela sat in jail for 27 years to show a minority of people in only one country that racism is wrong. Industry level change doesn’t take seven years. It takes upwards of 27. — Stephen Fishman

Some may worry that as more people write about or seek knowledge about DevOps, that DevOps will become a dismissible fad.

I’d encourage anyone who wants DevOps to become a pervasive reality to look at it this way: there is a spectrum of awareness, spanning from “no one has heard of it, and dismiss it as a movement that is irrelevant to them” on one side, to “everyone has heard of it, and rolls their eyes that it’s the latest fad.”

If I had to choose one of those scenarios, I’d choose “fad” every time. Why? Because there is nothing worse than trying to solve a problem that no one else thinks is important. The fact that so many communities are working to solve the DevOps problems is amazing. Development, testers, agile coaches, IT operations: We all believe it’s important.

As DevOps advocates, we must always be ready to respond when someone asks us, “I’ve heard about this DevOps thing. Is it something we should be doing?” The response should always be, “Yes, of course, we should be doing it! Here’s what I can do to help!”

As the DevOps community grows past what Geoffrey Moore called the “innovators” and “early adopters” (i.e., the unicorns), we must continue to tell the story so that the “early majority” and “late majority” will realize that DevOps is for them, too. Only by doing this can we have mainstream adoption, a phenomenon that Moore called “crossing the chasm.”

To create DevOps outcomes, we need a coalition that spans the entire value stream, from Marketing, to Product Owners and Product Managers, to Development and Testers, IT Operations and Infosec. Only then can we help our organizations go from low-performing IT to high-performing, which we’ve shown we can do through DevOps practices.

Conclusion

When IT does poorly, the business will do poorly. And when IT helps the organization win, those organizations will outperform their competitors in the marketplace. DevOps allows IT to win.

March 11, 2014