DevOps adoption has everything to do with continuous integration and continuous delivery — and the correct way about thinking of both. Its adoption has spread across the enterprise at an unprecedented rate. The need to produce reliable software at speed meant a new way to build and ship apps was required. Enter DevOps and transparency across departments, collaboration, agility, and automation. All these are different characteristics of the continuous integration, continuous delivery cycles. A lot of people attribute DevOps to two main contributing factors: culture, and tools. Something that’s equally important, however, is the DevOps journey itself and finding out what DevOps uniquely means to you as an organization. Let’s look at three organizations that took this journey, and have something to share with others.
Though no two companies or DevOps journeys are going to be exactly the same, we do have the luxury to access a vast horde of tips and tricks from people who have gone down that road before us. One such company, and recognized DevOps poster child, is Netflix. Netflix basically took movies online in a way that was previously unimaginable. People could hardly get two-minute YouTube videos to load without buffering at that time, and here was a company proposing to stream movies on demand. At a recent KubeCon event, Alexis Richardson, CEO of Weaveworks, noted how “Netflix crushed Blockbuster” by implementing increased availability and continuous improvement.
Netflix’s DevOps approach involved entering new territory where there were not a lot of examples or previous use cases to go by. One thing they knew for sure, however, was that they were going to be getting a lot of feedback. They would have to act on and implement changes with regards to that feedback in absolutely no time. This obviously meant fast and frequent releases, and DevOps was the answer. Now, since the problems that they would face in the future was uncertain and the only thing certain was that they would face them, Netflix developed a culture where failure was not only planned for but also implemented automatically. Yes, they automated failure.
Failing your way to success
Netflix dramatically altered its engineering process by including a tool called Chaos Monkey that’s basically a script that runs nonstop in the Netflix environment causing chaos by shutting down random events. Sounds like a bad malware virus, but by dealing with this environment on a day-to-day basis, if there is ever such a bug or monkey in the system it will be business as usual for the folks at Netflix.
In “The Social Network,” the movie about the rise of Facebook, an interview process for coders was to hack a secure system while they were drunk, the point here being if someone can do something drunk, they can probably do it a lot better sober. In the same way, by continually crashing separate parts of their own system at random, Netflix was able to build a rock-steady platform that keeps running independent of event crashes and is oblivious to failures. A similar example would be runners training at high altitudes, or gamers playing at a higher difficulty setting. If you raise the bar for yourself on your own, normal mode is going to be a piece of cake.
What we take away from Netflix’s DevOps journey is that we shouldn’t settle for anything except our ultimate goal and be ready to change everything from the ground up to achieve it. Thinking outside the box and making your worst-case scenario a regular work day is a great way to raise the standards and also makes sure everyone is always ready for trouble.
The next poster child for DevOps is none other than Etsy, and their story is quite interesting. Etsy is an online marketplace where people around the world can buy and sell goods. They were growing at a regular pace following the traditional waterfall approach where each department was siloed; Devs wrote code while Ops deployed it. By about 2008 they were up to 35 employees and deploying code twice a week. Michael Rembetsy, Etsy’s vice president of technical operations, told Network World that “deploys were often very painful, we had a traditional mindset of developers write the code and Ops deploys it. And that doesn’t really scale.”
While the Ops team was deploying code on the site, they were running into a lot of problems. For example, the entire website had to be updated every time they wanted to change a banner. It was little things like this that drove them to think differently and get the development team to not only be responsible for code but also for deployment and building tools that would let people other than the Ops team deploy code.
The Etsy story is not just about tools and strategy, but also about trust and teamwork. While the traditional waterfall approach had bred distrust between teams for no reason, the new approach just made everyone feel better. A team that’s feeling good and at peace with each other is the team you want in your corner when the site breaks. The mantra at Etsy is “it’s going to break and we’re going to fix it.” When you have everyone in your corner, or what some call “executive buy-in,” it makes a whole lot of difference because DevOps isn’t something you can ditch after a few quarters if you feel it isn’t working out. It’s something you need to stick to till the end in full confidence that it will work.
What we take away from the Etsy story is an indomitable spirit and a team that measures their success by failure. An Etsy executive was quoted as saying, “If a server bombs, we consider that a success because we learnt something.” It’s that kind of attitude that now has them at 42 million members, and about 80 releases a day, more than being about tools, DevOps is about attitude.
At the No. 3 spot, we’re going to look at an unusual suspect from the banking sector. Barclays started using Agile and DevOps methodologies about two years ago to combat the increasing competition in the sector. This competition was coming not just from banks but also from enterprise giants like Apple and Google entering the mobile payments market. Additionally, over $10 billion is being pumped into the financial technology sector every year with records being broken each quarter for the amount of investment going into fintech startups. It’s like Blockbuster and Netflix all over again, except this time the legacy firm decided they were not going to take it lying down, and went the DevOps way instead.
Moving the needle on Agile and DevOps
Jonathan Smart, head of development services at Barclays, mentioned that it was the executive buy-in from the top that was imperative to their success, stating, “I speak to many people at firms in other industries and in financial services that are trying to move the needle on Agile and DevOps, and they’re not succeeding because they don’t have the buy-in from the top.” That’s not to say they ignored the fact that they also need the support of the entire organization at the ground level, and achieved this through the creation of communities of practice.
These are voluntary teams dedicated to making the DevOps change happen smoothly and efficiently, and they have 35 such communities of practice with 10,000 members. At the DevOps Summit in London, Smart called their project the world’s largest and fastest Agile adoption, and said it has increased their throughput by a factor of three. Barclays now processes payments equal to 30 percent of the UK’s gross domestic product and, the company believes DevOps reduces risks and increases quality.
These three luminaries have gone ahead of many organizations and stumbled their way to DevOps success. Taking note of their experiences can help any organization looking to make the shift to DevOps.
Photo credit: Wikimedia