DevOps is the modern way of delivering applications faster and with higher quality
Put simply, DevOps is the modern way of delivering applications faster and with higher quality to meet the needs of the business. The need for DevOps emerged from a common organizational anti-pattern of siloed development and operations organizations. Conventional IT organizations siloed Development (think, programmers) and Operations (think, sys admins) away from each other. Development organizations were motivated and measured to push applications and application updates to production to accommodate business features. Operations organizations were motivated and measured to stabilize production to accommodate SLA’s. It was a classic duel of “make more changes” vs. “don’t make any more changes.”
To break the tie, we had to turn the focus from managing the silos to managing what was being delivered—the application (or in Agile terms, the “product”). A product-centric focus defuses the rivalry between development and operations and renews the commitment to delivering the product faster and with higher quality.
United around that singular mission, developers must be empowered to progress their product in the SDLC as far along as possible with a reasonable amount of risk as determined by the business. An example of this kind of development empowerment would be to allow developers to deploy their code into development and lower-level test environments as much as they want, as long as they don’t affect production. Governance, which includes processes for delivering products from code to production, must be well-understood, well-documented, and implemented with software tools to ensure confidence that whatever product ultimately reaches production is secure, fault tolerant, performant, and addresses the functional aspects required by the end user.
Why is velocity so important? The simple answer is that if enterprises can’t respond to market conditions and end consumers quickly, your competitors will be more than happy to scoop up market share and consumers you can’t keep.
Culture and organization
Simply put, siloed organizational structures impede velocity. Typically, organizations have their own way of measuring success, which can deviate from what is best for the business and end consumers. Breaking down the silos and getting development and operations to work together is key to removing this impedance.
But, it does not end there. What about the business (product owners), testers, and security specialists? All stakeholders need to come together with a product-focused mindset to achieve the velocity the business requires. Question, with boldness, everything that slows down getting the product to production. It could be a gatekeeper that loves saying “no” or can’t keep up with manual approvals, it could be a manual process that no one bothered to automate, it could be a requirements owner that doesn’t have time to write user stories.
Culture and organizational structure is the single most important factor in successful transformation.
Governance and process
Defining what must happen to get from ideation and user story to production deployment is critical. Cranking out a product to production that is not secure or performant is a business risk. In a world where competition is fierce, digital reputations can make or break a business. Ensuring that proper risk is mitigated for production deployments is a foundational aspect of business reputation. Defining a governance process ensures that the end product meets the original intent of the user stories it was born from, is compliant with the regulations the business is obligated to meet, is performant to the expectations of end users, and is secure to standards required by the business. Governance can start with the following simple rules:
All source code shall be version controlled in a source-code management tool (no code pulled from a developer’s hard drive).
Deployments shall only occur with the enterprise-sanctioned deployment tool (no deployments from commands originating from a developer’s machine).
All deployment packages entering production shall be scanned for security vulnerabilities.
Having a governance process in place inspires confidence and paves the way for DevOps tools to programmatically and repeatedly perform deployments (which is faster than humans can do).
Continuous delivery pipelines
Enter the “continuous delivery pipeline,” with a maniacal focus on increasing velocity and quality of products to production. Getting workable code to production quickly requires a rich backlog of features and an SDLC that has minimal resistance. How do you create minimal resistance?
Define a governance process for software delivery that includes ideation through production deployment.
Eliminate governance process steps that have no value add (think, arbitrary manual approvals that have subjective or no criteria).
For each step, define the risk mitigation to ensure the value of an added step is bringing benefit to the business.
Automate as much as possible (humans will never outperform software delivery tools).
Integrate SDLC tools (many have API interfaces and plugins that are designed for integration) into a pipeline.
Smaller code chunks
This is an aspect that reaches far back to product ownership. Smaller user stories beget smaller code chunks (which dovetails nicely with microservices). Designing, coding, and delivering code in smaller chunks enables faster velocity. It’s the difference between delivering a 10-ton gorilla vs. a hive of bees.
Logistically, monolithic apps (gorillas) are bigger and require coordination, dependency management, and heavy lifting to design, code and deploy. If features can be vertically sliced and designed, coded, and delivered in smaller pieces, incremental solution outcomes can reach end users faster and at a higher frequency. A beneficial side effect is mitigating the risk of “big bang” deployments.
Increasing velocity is not beneficial if you are pushing “junk” to production. That is how digital reputations are destroyed and consumers are lost. I recall a conversation with a client that said he hated Agile because all he got was “incremental emergencies.” What a face-palm moment! Quality is important.
Shift left testing
Testing motivations are born out of the desire to mitigate the risk of sending defects into production. Even in waterfall delivery, there was a well-known acknowledgment that when the earlier defects are identified and remediated, there is lower cost, impact, and effort to the business.
Defects can occur for many reasons, including a lack of understanding of requirements, poor development behavior and discipline, inadequate testing, and lack of accountability, among others. Testing and quality assurance should have a constant presence in the SDLC, from ensuring adequate understanding of user stories to testing production (yes, you read that right—testing in production). If you were to look at the SDLC with a “testing lens,” you would see opportunities to mitigate risk through organization, behavior/practice, and tools, such as:
Have a Product Owner (requirements owner, in heritage “speak”) co-located with developers to collaborate daily on user stories (organization, behavior).
Pair programming to ensure that peer code reviews are occurring along with coding and unit test authoring (organization, behavior).
Run unit test cases as part of the build process (tools).
Leverage service virtualization to mitigate the risk of integration failures early on (tools).
Shift left operations
Critical to the successful delivery of applications is the management of the application once in its “runtime” state. Monitoring applications, rather than just a heritage “up/down” check. If your application has API endpoints, are each of those endpoints accessible and returning expected payloads? What about cases where microservices are coordinating in a mesh to handle a logical unit of work—how will we “track” a transaction through the service mesh if something goes wrong? And when something does go wrong, how do we ensure that the application does not “die” with an orphaned transaction in flight?
API health checks, correlation ids, standard logging, and application fault tolerance (among others) are all paramount to addressing serviceability (or non-functional qualities, in heritage speak) in applications that require instrumentation of the application code or “build-to-manage.” To complement these build-to-manage approaches, operations in the cloud must proactively listen, monitor, and probe the heartbeat of runtime workloads. The concept of code instrumentation implicitly implies early activity in the SDLC—one of the reasons for shift left operations.
DevOps is a people, process, and tools strategy
In conclusion, DevOps is not just a story of tools and automation; it is much richer than that. DevOps is a people, process, and tools strategy. Although the DevOps domain is quite large, there are some very prescriptive “quick wins” that can be achieved to demonstrate an increase in velocity and quality. For each of the dimensions listed above, there are incremental solution outcomes to advance maturity. When embarking on any type of DevOps transformation, measuring success is crucial to prove value add. In general, every investment in tools, effort, and cost should yield an improvement in velocity and quality.
I would love to hear your perspectives, what does DevOps mean to you?
- Learn more about IBM DevOps solutions
- DevOps for accelerating the enterprise application lifecycle
- DevOps: A Complete Guide
Stay tuned for more blogs on other interesting DevOps topics. These are some of the subjects we’ll be covering in the future.
DevOps is in the DNA of Modern Delivery (IBM Garage Method, Agile, Lean, hybrid and multicloud architectures, skills/competencies, commoditization squeeze, innovation)
DevOps Anti-Patterns (“field of dreams” (technology), “ivory tower” (organization), “mutant virus” (skills))
DevOps as a Gateway (CSMO, Garage, App Mod, Cloud Adoption)
Permutations of DevOps (DevSecOps, BizDevOps)
Heritage DevOps (approaches for conventional application estates)
Modern DevOps (approaches for cloud-native and cloud-ready applications)
DevOps as an Enterprise Transformation