devopsy.kinsta.cloud

Tag: gene kim

DevOps Board of Advisors and other DevOps blog musings

Well it looks like putting big names on Board of Advisors is having a good week in the DevOps world. Our friend Steve Hall over at ScriptRock announced on their blog yesterday that DevOps luminary, Kevin Behr (@kevinbehr) has joined the company’s board of advisors. ScriptRock has also been putting some great content up on their blog as well. If you don’t already you should follow it. Also stay tuned for some ScriptRock folks posting here on devopsy.kinsta.cloud.

Speaking of Board of Advisors, here at devopsy.kinsta.cloud we announced our own Dream Team board yesterday. With Brad Feld, David Cohen, Sean Charnock, Dean Mann, Gene Kim, Rich Mogull and regular devopsy.kinsta.cloud journalists George Hulme, Tony Bradley and Ericka Chickowski, it is a great group that should help a ton with all of the many plans for devopsy.kinsta.cloud. Rajat Bhargava, CEO of JumpCloud is one of the members of the board here and JumpCloud put up a nice post about it too.

What do you think about boards of advisors? Helpful or not?

It was a busy day with in other DevOps blog news, but two posts I wanted to call out were:

1. Back to the future with Old School Devops on the Logentries Blog. First of all you have to love the Motorola beeper. I remember those, in fact I had one. It is an old chocolate meets peanut butter story where the lead dev happens to be having a beer with the Ops dude. Luckily that is when the crap hits the fan and together they can solve the world’s problems almost. Of course it doesn’t always work like that does it? I suppose what makes it old school is that today the Dev is the Ops 😉 Either way the point of the article is sometimes simple works is best.

2. How to measure DevOps success: Ok put on your thinking caps for something really important. Helen Beal over on the AppDynamics blog has a really great article up on measuring your DevOps success. This is an issue we hear about often. How do I know if this DevOps stuff is really working? We have all seen numbers like a 20% productivity spike with DevOps, but how do we really measure it? What do we measure? Do we measure tools, culture, revenue something else? This is as good a stab at it as I have seen put out there and worth your time.

What DevOps blogs are your reading? Drop a line and let us know here in comments or at parker@devops.com.

Also stay tuned tomorrow for our first Frequent Friday list of DevOps people to follow.

March 20, 2014
devopsy.kinsta.cloud ANNOUCES DREAM TEAM BOARD OF ADVISORS

Thought Leaders Gene Kim, Brad Feld, and David Cohen to Provide Strategic Direction and Advice to Foremost DevOps Community Site

Boca Raton, FL – March 18, 2014 – devopsy.kinsta.cloud, where the world meets DevOps, today announced its Board of Advisors, including Gene Kim, renowned author and thought leader; Brad Feld, managing partner of Foundry Group; David Cohen, Techstars; Sean Charnock and Dean Mann of DH Capital; Rajat Bhargava, CEO, JumpCloud; Rich Mogull, CEO, Securosis; and, award winning, experienced tech journalists – George Hulme, Tony Bradley and Ericka Chickowski. This stellar lineup will help guide and position the company as it becomes the leading destination to help further the methodology and adoption of DevOps by organizations around the globe.

“DevOps is changing the way our portfolio companies operate and I’m looking forward to helping devopsy.kinsta.cloud become a catalyst for the DevOps community,” said David Cohen, founder and CEO of Techstars.

“I think that DevOps will be one of the most important trends in technology over the next 5 to 10 years, devopsy.kinsta.cloud can help accelerate its adoption and growth. Both Dean Mann and I recognized this which is why we helped found devopsy.kinsta.cloud and are honored to be on its Board of Advisors,” said Sean Charnock of DH Capital and co-founder of SoftLayer Technologies.

“In founding JumpCloud I have seen for myself how DevOps is changing the game for organizations both big and small. We are strongly committed to DevOps at JumpCloud, and devopsy.kinsta.cloud is a terrific way for us to help the entire community, whether they are already invested in the DevOps movement or simply interested in learning more about the groundbreaking methodology,” said Rajat Bhargava, CEO of JumpCloud.

“Coming from the information security industry, we recognize that DevOps is a tremendous opportunity for security finally to be built into instead of bolted on to applications and IT. I am looking forward to helping devopsy.kinsta.cloud bring DevOps to the security industry specifically and the entire IT industry in general,” said Rich Mogull, CEO of analyst firm Securosis.

“As a 20 plus year veteran of the technology media industry, I am very excited to make sure DevOps fulfills its promise to change the way business is done. I am thrilled to be on the Board of Advisors of devopsy.kinsta.cloud to help guide it toward becoming the leading destination for the DevOps community,” said George Hulme, award winning technology journalist.

The Board of Advisors will hold semi-annual meetings as well as quarterly virtual meetings. It will advise the Board of Directors and management of devopsy.kinsta.cloud to help it fulfill its goal of becoming the leading destination for the DevOps community[as1] .

## ##

About devopsy.kinsta.cloud

devopsy.kinsta.cloud is where the world meets DevOps. With over 100 new original content articles per month, it is the largest source of DevOps related news in the world. Additionally its community support and other DevOps information help DevOps community members the world over.

March 18, 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
The Unexpected Benefits of DevOps

There are many well and widely known benefits of DevOps, including rapid software delivery, a higher degree of enterprise agility, increased system resilience, and being able to swiftly identify and resolve problems.

But what unexpected benefits have been experienced by organizations that are already down the DevOps path? Kevin Behr, chief science officer at Assemblage Pointe, says that one is the move to continuous improvement. “We’re seeing organizations move to continuous improvement because, as it turns out, the DevOps teams lend themselves very well to continuous improvement and cross-functionality,” he says.

While working with a current enterprise, Behr explains how the company established a continuous improvement IT team in the same spirit as the continuous improvement culture at the automaker Toyota. “The development and operations teams are doing this and they’re solving some really, really crazy problems really quickly. You couple the collaborative mindset of DevOps with continuous improvement and you see stunning results,” he says.

One of those outcomes includes hybrid thinking among collaborating teams. “I witnessed a developer using a checklist the other day. That’s something you never see. Developers are typically all about how many scissors they can run with pointed at their eyes. They are about creativity and danger,” Behr says.

However, after working more closely with the operations teams, the developers tend to start adopting some of the tactics employed by ops teams. “The developer explained how the operations team provided a pre-handoff checklist, because items often were forgotten before release,” Behr says.

The tighter coupling with developers is also changing the perspectives of operation team members. “Operations people typically have this fortification versus resilience mentality. They build big turrets, and they’ll put a big gun down. Now, having worked with more nimble dev teams, they’re wondering how—when the big gun fails—they can react more quickly,” says Behr. “You never often hear ops people talk like that,” he says.

Another surprise is increased security. While some organizations fear that the rapid release cycles and the autonomy within DevOps would derail security efforts, many are experiencing quite the opposite. “I think that existential fear is present in security professionals, as well as a lot of test and QA professionals,” says Gene Kim, founder and former CTO at IT security firm Tripwire, and author of The Visible Ops Handbook and The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. “In observation, however it is the exact opposite. No longer does infosec do the testing work. QA and infosec now will be the consultative authorities to help developers do the testing. They will either write the tools that help increase the quality or help developers write their own tests. We no longer become the bottleneck that people try to figure out how to go around. Instead, we are actively helping them do their daily work. It’s the opposite of preordained failure; it’s active involvement,” says Kim.

Another unexpected outcome that resulted from security becoming more integrated with DevOps is an emphasis on relevant metrics, explains Bill Burns, former director of information security for a U.S.-based major on-demand Internet streaming media provider. “If the security team identifies an important capability or service to build into a new service or product, then, just like other business units, security teams should proactively prepare to present metrics for the risk items they discussed,” he says.

As Burns explains, operations teams see this more clearly as development and operations capabilities merge: the business has an expectation to have key operational metrics available all the time to support decision making. Security is no exception. And having security metrics as part of the same dashboard or review process builds trust and credibility toward the security team. “It also forces the security team to really focus on what the key threats or risks are, how they to measure them, and why the business should care,” says Burns. “This level of relevancy is great, another way for security teams to communicate and work with business units—something every security (should) strives for,” he adds.

The next unexpected benefit—more work for the security team—is both good and bad news, explains Burns. “We’d engage with one team on one particular project, and out of the blue we would get that same person or one of his peers come to us proactively and request our input on other initiatives. Those were exceptional moments for me. You would have a small success with one engagement and you would build trust, and then you find other developers come to you and seek advice. That’s a huge indicator of success right there,”

March 11, 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
devopsy.kinsta.cloud Pitches a Big Tent

If you are reading this you have already discovered one way or another, that the new devopsy.kinsta.cloud website has launched. I am proud to say that I have been one of a team of folks who have been working hard on devopsy.kinsta.cloud for many months and weeks now. I will serve as editor-in-chief and as a co-founder. Anyone who has started a business knows that I am also chief cook and bottle washer. That is OK though. This is not my first start up. Staying up until 2:30 or 3:00 am working on the site reminded me of how alive you feel when you are building a business. If only you could bottle that. We know we have much more to do to realize our vision. But we think we have enough to introduce you, the DevOps community to devopsy.kinsta.cloud

So what is devopsy.kinsta.cloud? Frankly, it is a big tent. What we have tried to do is create a destination for the burgeoning DevOps community to gather. Our goal is to have something for everyone with an interest in DevOps. We realize that many DevOps devotees are highly technical. All of the culture and business discussions are nice, but how can you do more, faster and better? Our aim is to give you lots of information, education and resources to help in your everyday work. We want bloggers and writers who are living the DevOps life and are sharing their own experiences with you. In fact, we also welcome you to participate fully by sharing your own experiences and thoughts as well. We are always looking for people who have something to add to the conversation. That last phrase says it all. We want to add to the conversation. But that conversation can’t be just for those who are technical. We want a bigger tent than that.

I have met and there are many people who know little about DevOps. They have heard the name and are curious though. What they do know is that somehow this could help them transform their organizations into what my friend Gene Kim calls a high powered IT organization. They are faced with a world where the rules have changed. Iterations take place daily if not hourly, automation is not nice to have, it is mandatory, software has replaced hardware for many. How can they succeed in this environment? DevOps is a key. We want devopsy.kinsta.cloud to have a place under our big tent for these people. Whether they are C-level executives looking to leverage DevOps in their business, VCs looking for insights into their next investment or even job seekers, exploring what talents and skills they will need to succeed, devopsy.kinsta.cloud has a place for them under our big tent.

Another goal of devopsy.kinsta.cloud is to be more than just a place with great articles, stories and DevOps related content. We want to be a linchpin of the community. Though not ready in time for our launch, you will shortly be seeing several other parts of devopsy.kinsta.cloud. We will have a community forum Q&A section shortly. If you have a question you can ask. Either someone from our staff or maybe someone in the community will answer. Maybe more than one person will answer even. Maintaining these Q&As will over time build up a great knowledge base which will always be available to the community.

Additionally, we want to facilitate and help all of the great meetup and user groups that are out there dedicated to DevOps. I have spent a lot of time these past months going to meetings, observing, listening and understanding. We know that these groups need speakers for monthly meetings, sponsors to supply food, drink and often a place to meet. Help with local community outreach and connecting with other groups to share ideas, experience and learning are also somethings these groups need. The good news is there are plenty of people and organizations out there who want to help you. Our mission will be to help match these groups together to strengthen these grass root groups. We have lots of room under the big tent to help in this mission.

Holding a local DevOps Days or workshop? Need sponsors, speakers, logistic support? devopsy.kinsta.cloud can help you too. Local groups do more to further the DevOps cause than anyone. We want to help and encourage more of it.

In the not too distant future devopsy.kinsta.cloud will also be more involved with conferences that play on bigger stages. Whether it be as a media sponsor, covering and reporting on the goings on or providing speakers and content ourselves, we will be on the scene. We plan on holding our own conferences with multi-track sessions, keynotes, exhibits and of course social activities. Stay tuned for details in the coming months.

Is this an ambitious agenda? You bet it is. But if you aren’t going to go big, you might as well stay home. We are being helped by some people who know how to succeed. We will be announcing shortly some of the people who are behind devopsy.kinsta.cloud and who will be helping out. I am proud to call these people my friends and am honored that they are lending a hand. One person I want to mention now though is my devopsy.kinsta.cloud co-founder, Martin Logan. When I first started talking about the idea of a DevOps community site I registered a bunch of domains, but knew that devopsy.kinsta.cloud would be the best domain name. I found Martin as owning the domain and reached out to see if he would perhaps sell it for a reasonable sum. A few hours later we were partners! Martin is a real, live DevOps dude. He understands what DevOps is about. None of this is possible without him.

For now take a look around our site. Be sure to sign up for our newsletter in the top right column. The site look and feel will be changing daily as we continue to iterate in the DevOps way. Most of all there will always be fresh content. We should be averaging about 100+ new content articles a month. There will be something for everyone!

You can reach out to me anytime with comments, suggestions, complaints or questions at ashimmy@devops.com.

Thanks for stopping by and enjoy!

March 11, 2014