Cloud Native DevOps Requires Squad Autonomy
With the move to Cloud Native, many teams are accelerating their DevOps processes with a strong focus on Continuous Delivery. To realize the benefits of Continuous Delivery, many enterprise development organizations need to eliminate inhibitors to adoption including traditional governance models that disrupt agility.
The cloud is a significant disruption to the tech industry. Developers are demanding control of their ability to delivery quickly and receive instant feedback on what works and does not work. Adopters of the Lean Startup philosophy has resulted in a significant shift in how developers bring new technology to market. Developer responsibilities have expanded and now have to consider the impact of their code deliverables beyond the code commit to now having to support the live operational aspect of their applications that are running in the cloud with possibly 1,000s of tenants all leveraging a collection of highly scalable Cloud Native applications.
In this article, we will argue that team autonomy requires the removal of high touch enterprise governance. The shift in the role of DevOps requires a level of squad autonomy where development teams automate the entire DevOps workflow. These workflows typically are triggered with a single Git commit driving a pipeline that generates insights into the quality of their code based upon code quality and test coverage all with the intent to gauge readiness for promotion to production. These teams will demand dashboard style views of their deployments with real time metrics of their entire DevOps process. In shifting the power back to the squads, teams can react in a more agile fashion and adapt to industry disruptions on the turn of a dime.
Squad Autonomy
In Continuous Delivery, the notion of delivering small incremental changes is a basic table stake for high performing teams. To achieve high velocity, teams need to be prescriptive with the tools that will be used to deliver code to production with limited intervention. These tools when viewed in aggregate are considered a toolchain. Many teams view their toolchains similar to a production assembly line and often use the term pipeline to describe the path code takes to get released to production. Example of the type of tools range from source code repos (git commit triggering builds), to a CDI/CI tool such as Travis (build, package and test of the source code), to dependency management (using tools like NPM). Eventually, the packaged code gets deployed to various environments such a test, staging and then ultimately to production. With the focus on small incremental changes, each deployment is easily understood and verifiable for quality and stability to ensure the application continues to operate efficiently.
Transparency
In the past, the role of Release Manager controlled the roll out of new code. However, this is changing with the move to the cloud. Gone are the days where a deployment consisted of a large batch of new function, the constant incremental deliveries by multiple teams asynchronously has shifted the paradigm. Dashboard summaries providing drill downs to specific micro services, their test coverage, versioning of their applications and their dependencies as well as real time health dashboards have become the new normal. Release Managers now work closely with teams to ensure that key performance indicators such as Service Level Agreements are met, teams are adopting a consistence cadence on releasing new function to production and that git branches are being integrated on a frequent basis. By having this transparency and open interaction model between the DevOps teams and Release Management, the need for traditional governance is removed from the discussion. Based upon these shifts, conventional roles such as Release Manager play a completely different role in a strong DevOps culture.
Now that we have talked about squad autonomy and transparency, lets go deeper into how Cloud Native Applications relates to DevOps and where containers play in this environment.
The Twelve-Factor App
The leading methodology for building Cloud Native applications is a method called “The Twelve-Factor Methodology”. Adopters of these principles, in theory, allows for supreme agility and provides the foundation for realizing the benefits of Continuous Delivery. In this methodology, the developer is presented with guidelines ranging from the source control methodology using modern tools such as Github, to how you leverage dependencies in your application all the way through to how you build, test, deploy and manage your application throughout the DevOps lifecycle. In theory, if you follow these principles, your application will be resilient, scalable while remaining highly maintainable allowing your developers to focus on innovation and increasing your development velocity.
Containerization
Containerization — also called container-based virtualization and application containerization — is an OS-level virtualization method for deploying and running distributed applications without launching an entire VM for each application. Instead, multiple isolated systems, called containers, are run on a single control host and access a single kernel. [1]
Containerization has gained significant adoption in the industry with the release of Docker. Docker allows developers to quickly package and deploy their code at an application level and provides a consistent ecosystem for developers to host and test their applications both locally and in the cloud. As the development environment is more closely aligned with their production environments, via containers, the DevOps cycle is able to be even further accelerated and maps squarely on the Twelve-Factor app category around “Dev/Prod Parity”.
Summary
Continuous Delivery is a real game changer for adopting Agile Principles. The concept of squads and autonomy really empowers the development teams to deliver high quality innovative solutions in a model that minimizes risk. The key is to ensure that teams continue to provide high value insights into their DevOps progress ranging from the rate and pace of code commits to ensuring that SLAs are continuing to be met. With a industry focused on the how many 9s your application is, your level of autonomy can easily be impacted. My hope is the days of big bang organizational level releases is a thing of the past and that we can continue to focus on building autonomous high performing engaging teams!!
Looking for more of the latest headlines on LinkedIn?
Originally published at https://www.linkedin.com on March 27, 2017.
