“DevOps“, that infamous “word” that has been circling the IT community for many years now. What is it? Why do I care? Most will say DevOps is a fantasy world where developers and operations teams are BFFs, they sing ‘Kumbaya’ at their weekly double rainbow viewing parties while happily playing ping pong during which time the infrastructure purs along happily and code changes are automatically integrating safely into production. Does anyone actually believe this is possible? In the real world developers and operations teams are NOT friends. The developers can’t stand the infrastructure team because they can never keep up with their demands and the operations team can’t stand the developers because they are always demanding bigger systems/faster systems and they want it NOW! This is why “shadow IT” has become such a problem. The developers got fed up with time it takes the operations team to provision new systems to their dev/test or production environments so they have begun provisioning to the public cloud where they have a self-service interface and can have their systems built in minutes not weeks/months. Meanwhile the operations team barely has time to look up from their screen because they are putting out yet another fire and are more than happy to allow the developers to continue pushing out their dev/test workloads to the public cloud so they can focus on “keeping the lights on”.
So how does the internet define “DevOps”? Webopedia defines “DevOps” as follows…
DevOps (development and operations) is an enterprise software development phrase used to mean a type of agile relationship between development and IT operations. The goal of DevOps is to change and improve the relationship by advocating better communication and collaboration between these two business units.
So, even the internet believes DevOps is possible but I thought we just discussed how DevOps is a fantasy?! Face, meet palm.
If DevOps is truly an attainable thing, how can we attain this status? How can we unite our teams to strive for a common goal? It turns out it’s actually possible – shocker, right? 🙂
If anyone has read the book “The Pheonix Project” then you know that it chronicles a story whose main character, Bill, is tasked with the responsibility to improve IT operations and to successfully deploy a new application – “Pheonix” – so that their company “Parts Unlimited” can stay in business while their competitors keep releasing new online features. In the book it describes something called “The Three Ways” (great, more Kumbaya nonsense…). The First Way is about the left-to-right flow of work from Development to IT Operations to the customer. To maximize flow, we need small batch sizes and intervals of work, never passing defects to down-stream work centers and to constantly optimize for the global goals. Practices like continuous build and integration, on demand environment creation, limiting work in queues, and building safe systems. The Second Way is about the constant flow of fast feedback from right-to-left at all stages of the value stream, amplifying it to ensure that we can prevent problems from happening again or enable faster detection and recovery. By doing this, we create quality at the source, creating or embedding knowledge where we need it. In order to follow the second way we must do things like stopping the flow of work if an error is encountered during build integration, improving our daily work, and making sure we create fast/automated test environments so we ensure our code is always deployable. The Third Way is about creating a culture that fosters two things: continual experimentation, which requires taking risks and learning from success and failure and understanding that repetition and practice is the prerequisite to mastery.
So how does Enterprise Cloud provide the framework for DevOps? Well with an Enterprise Cloud with built in automation we have the ability to remove shadow IT by giving developers an environment where they can access different system blueprints through a self-service interface with quick access to resources right in their own datacenter. The business loves this because now they are consuming their own infrastructure and not paying the high costs of the public clouds. An Enterprise Cloud also needs to be built with intelligence where the common issues seen in legacy 3-tier datacenters are not seen because an Enterprise Cloud can SCALE and scale on demand while maintaining performance for our critical applications. An Enterprise Cloud also needs to be self-healing, where there are no SPOFs (single points of failure) so that the operations team does not need to scramble if there is a hardware failure and we can limit unplanned downtime. The Enterprise Cloud needs to provide forecasting and analysis by giving the operations team the ability to view their consumption and see their resource runway to allow them to get ahead of purchasing cycles so that the development team is never without datacenter resources. Lastly, the cornerstone to allow any of the above is a hyper-converged infrastructure built on webscale technology that combines compute, storage, and virtualization into a single software defined platform. All of these components allow the operations team to focus their energies on the needs of the business and to become IT consultants for the business and to park the fire trucks.
In closing, DevOps, while still a fantasy to many, is quite possible with the right infrastructure/self-service automation provided by the operations team to the development team. In a world where business are in constant competition, the ones that embrace DevOps and “The Three Ways” will consistently come out on top and hey maybe weekly Kumbaya sessions will become common place. 🙂
For more information on DevOps and The Enterprise Cloud see the following links.
