DevOps is one of the buzziest terms out there and for good reason. To deliver on the service agility and “fail fast” goals, both technology and culture transformations are needed. Cloud, NFV, and web-scale technologies need a companion organizational philosophy for service providers to truly thrive and rapidly respond to market opportunities.
By now, most people in technology have heard the term DevOps. In just a few short years, this term has gone from fuzzy idea to mainstream methodology. The term originated somewhere between 2008 and 2009 (the idea preceded the label) and was introduced by technologists who realized that the traditional model of software delivery was slow and cumbersome.
Traditionally the organizational structure was basic and siloed: there is a development group and, separately, there is an operations team. Being two separate teams caused big inefficiencies that resulted in the slow release of software into production. In a traditional environment, the developers write code and then throw it over to the wall to operations. The developers go off and celebrate their “success” while operations spends the next few weeks cleaning up the code and getting it ready for release into production. In this model operations generally ends up with a large, complicated mess that they need to make sense of and somehow get released into production. In this model, it could take just as long for operations to release the software to production as it was taking for the developers to write the code. And by the time it’s finally production-ready, it might miss the mark or, if changes are needed, the service provider will be too slow to pivot and miss the revenue opportunity.
Not only is this model inefficient but it fosters lower quality, more frustration, finger-pointing, and low morale. Early pioneers in DevOps knew there had to be a better way and from that simple idea, DevOps was born.
Notably, this focus on faster time to market and being more agile in responding to customer demands is one of the drivers for adopting new virtualization and web-scale technologies like NFV and SDN. Technology by itself won’t fix this issue. Culture and team organization are essential too.
Alianza has been an Agile Scrum shop for 2+ years and we have seen huge increases in productivity, quality, predictability, and employee morale. Agile does not necessarily equal DevOps (Agile != DevOps) but it should. We realized early on that in order for us to realize our maximum potential we would need our operations and development teams to work more closely together (DevOps). We saw the inefficiencies of how we were working and recognized the need for better collaboration and shared ownership. The key to success with DevOps is recognizing that everyone in the organization, and especially development and operations, have responsibility for software delivery speed and quality.
An early mistake that organizations often make with DevOps is creating a “DevOps Team” or giving an engineer the title of “DevOps Engineer” and then tasking him to fix all the problems with slow software delivery, quality, and frustration with the process. This is the wrong approach; DevOps is a mindset and not a position with a fancy title. DevOps works when development and operations start working together and feel a sense of shared ownership for software release and quality. When they start talking more often, attend meetings together, and are both given responsibility for accelerating software delivery and improving quality then things will start changing. Until a company reaches that point, no single engineer or small, dedicated team will affect the kind of change that is really needed to address core underlying issues.
We found that all of this was much easier said than done. Old habits die hard and our default position is to revert back to old behaviors. Successful integration of DevOps requires management buy-in, patience, and most importantly, a continual stream of education and vision. It also requires a core number of key individuals who understand the concept, see the value, and are willing to act as change agents. This process is difficult to speed up and it’s important to come into this realizing that it will take time. Changing long-held beliefs and ideas are hard – but it is possible!
We’ve found that the speed of the change is directly proportional to the time we invest in evangelizing the reasons for the change and getting everyone aligned behind the concepts. Developers and Engineers are sharp people who know a good thing when they see it—they just need a clearly articulated vision and value statement. Once those things click then watch out and move out of the way!
Further, when you combine that DevOps speed with our micro-release strategy (new features/functions every few weeks) and the easy feature delivery of the cloud (see SaaS: Freedom from Product Release Tyranny), our service provider customers can really boost their service agility for VoIP.
While we are still not perfect, we are working hard to improve our software delivery speed and quality each day. As we implement these ideas, we are seeing big improvements in both areas for our customers. What used to take months now takes days. Quality is better and we are able to move faster, providing more value to our customers. As we continue to get better we know it is ultimately our customers who win since software quality is better, delivery is faster and our customers are put in a better position to win!
Contact us if you want to learn more about this super agile, cloud-based VoIP solution that we call the cloud voice platform.