By Rajat Bhargava Posted March 17, 2014
This is the third segment of the DevOps State of the Union event in Boston Recap.
Our friends at Dyn took the lead on a discussion around how hard it is for organizations to embed DevOps into their culture at our recent DevOps State of the Union event in Boston. Cory Von Wallenstein (CTO of Dyn) kicked off the discussion describing how Dyn leverages it for their organization.
The strongest points made during this part of our event were around how to make DevOps work inside of an organization. The entire group seemed to agree that it must be embedded into the fabric of the company. One of Dyn’s customers was also at the event and openly described how they had started several years ago with a DevOps team. They were a separate group that reported to the CIO of their company. It was a few engineers tasked with using DevOps principles inside of their company. The effort ultimately failed because it was an adjunct effort. It wasn’t connected to the development team and wasn’t integrated into the daily flow of the engineering process.
As a result, this organization knew that they wanted the benefits of DevOps – more rapid iteration of their application – but they knew that they needed a different way to achieve their goals. So, they made two fundamental changes. They embedded the function into every developer’s role. Just as Google used to have 20% time for focus on different types of projects, developers would need to make time. There would be time in their schedule where every engineer would have to practice it. And, second, they shifted the responsibility of DevOps from their CIO to their VP of Engineering. This individual became responsible for delivering the benefits of DevOps and embedding that culture into the organization.
Not surprisingly, their efforts flourished. With an infrastructure of several thousand servers, over a hundred developers, and a wider product range, the company was able to accelerate their product and company through a better implementation of the DevOps methodology. Every engineer now has some responsibility for their purview of it. Depending upon their product deliverables, they may be tasked with taking advantage of DevOps In different ways. Some engineers may be on the lookout for different tools, while others may be figuring out better processes to streamline testing or code delivery. An interesting piece of data from the conversation was that this company only had 3 operations engineers. Because they leveraged the cloud and DevOps, they could have a very lean ops organization. The bulk of their efforts were run by their engineering team.
While this was just one example – and one that the group spent a lot of time digging into – it turned out be incredibly instructive. DevOps is hard to implement, and it is something that needs to be embedded into the fabric of a company. This is why you see so much adoption of DevOps within startups – it’s much easier to embed it into smaller companies and ones that are just getting going. In fact, JumpCloud has had to practice DevOps from inception. With a small engineering team at the beginning, we needed to merge dev and ops into one group and function. We also wanted the benefits of fast iteration cycles as we were delivering the first cloud-based directory service called Directory-as-a-Service®. With fast iteration cycles, we’ve gone from just a core server user management service to a centralized, core directory service with support for Windows, Mac, and Linux systems, WiFi authentication, True Single Sign-On™ support with SAML, and hosted LDAP among many other capabilities. While small companies may be easier, trying to turn the ship of a large company is much more difficult culturally. In both cases, though, the pain that comes with implementing it was far smaller than the benefits. It seemed like the conclusion of the group was that it paid to be a DevOps organization.