Unveiling the nuances of the DevOps paradigm proves to be an elusive task, exacerbated by the controversial nature of the materials available around the world-wide web, which often obscures its fundamental tenets.
Meet an expert
No more traversing the labyrinth of theoretical preambles about the enigmatic facets of all things DevOps — Oxagile reaches out to their Chief DevOps Engineer, Gleb Skuratov. As a specialist endowed with the firsthand knowledge of DevOps practices, he takes center stage, demystifies the most frequently posed questions, and shares a compendium of hands-on DevOps experience.
Stay engaged to unravel the layers of DevOps strategies, the intricacies that businesses going to implement DevOps often face, and the shades of the DevOps culture, because Gleb is on the airwaves, ready to illuminate the path for those eager to get to know DevOps better.
Let’s start easy: What’s DevOps?
Uncertain about whether the question is simple, though. Let’s delve into DevOps services through the lens of business acumen. Business, at its core, is an intricate orchestration of processes designed to yield predictable financial outcomes with optimal efficiency and profitability. Throughout human history, the relentless pursuit of maximizing results while minimizing temporal and monetary expenses has been encapsulated by the project triangle.
Pioneering this ethos, Henry Ford revolutionized industry dynamics by implementing a conveyor system and splitting the responsibilities. This approach not only facilitated the mass production of automobiles, but also achieved economies of scale, enabling the realization of more cars at a lower cost within a stipulated timeframe.
DevOps operates in the same way within the software delivery domain. In essence, DevOps emerges as a holistic methodology crafted to institute and refine software delivery processes, mirroring the time-honored pursuit of optimizing outcomes while economizing time and resources.
Would you formulate key DevOps principles?
Initially, it’s imperative to dispel any notion that DevOps operates in isolation. The implementation of the DevOps strategy is contingent upon the pre-existing development practices within the organization, the availability of QA resources, and the pressing needs of the business landscape.
Consider a scenario where manual QA processes dominate, with automated QA conspicuously absent. In such instances, the adaptation of deployment processes necessitates a smart approach that seamlessly integrates with the existing workflows and a lack of automated testing. For instance, the utilization of Argo CD, a continuous delivery tool, encounters a bottleneck, given the imperative to ensure meticulous testing by QA specialists, rendering it unsuitable for this concept.
Establishing a correlation between DevOps and other operational methodologies within the company constitutes the foremost principle that should not be overlooked.
Turning to other DevOps tenets, I’d spotlight the following:
Collaboration
Existence unfolds across three temporal dimensions: past, present, and future. Each dimension serves as a repository of invaluable information, unlocking the potential for active and, ideally, proactive responses to challenges, thereby steering our trajectory in the right direction. Communication stands as the guide to this informational trove. Collaboration transcends mere dialogue; it’s the orchestration of collective action to get results of greater magnitude than solitary endeavors.
Yet, the Ringelmann effect cautions us that team productivity wanes as the team expands. This predicament sets the stage for another DevOps principle born to address the issue.
Culture
Business, akin to a finely tuned orchestra, relies on conscientious individuals operating autonomously within defined parameters to deliver results within their spheres of influence. The same symphony resonates in software development and its ancillary processes. The baseline of the DevOps culture lies in adhering to conventions, standardized rulesets, and agreements. But why bifurcate responsibilities and mandate adherence to processes and inter-team communication? The answer, encapsulated in the next DevOps principle, is displayed below.
Automation
The linchpin of business prosperity, automation levels the playing field for diverse talents, allowing them to apply their expertise without the attention blur, — a veritable conveyor for software.
With a product in hand and a collaborative team in place, the question emerges: how effective are they? The following DevOps principle, deftly addressing this facet, awaits exploration.
Measurements
Assessing team performance, software efficacy, and customer satisfaction rates serves as an internal compass, revealing insights into our actions — illuminating missteps, identifying gaps, and delineating arenas ready for enhancement.
Do any DevOps principles remain ambiguous to you?
Oxagile’s DevOps team stands prepared to provide lucidity and rectify any misconceptions.
DevOps strategy vs. roadmap vs. plan: What comes first?
A DevOps strategy encapsulates the foundational concept of why DevOps implementation is imperative and addresses the pivotal query: “What resources are requisite for the successful assimilation of DevOps within the company’s processes?”
Speaking about those resources in detail, I’d divide them into four fundamental sections: Agreements, Processes, Approaches, and Tools.
Agreements and conventions
They are inscribed in written form into a knowledge base, constituting the bedrock upon which every team member treads. These agreements form the foundation of the DevOps automation principle, furnishing a cohesive input essential for the efficient automation process. Examples abound. This is about establishing branching strategies, versioning processes, infrastructure, repository, product, and branch naming, application variable agreements, development standards (e.g., 12-factor application), an architecture governance model and methods, and more.
Processes
Once the input gains a semblance of consistency, the narrative unfurls into processes, with each wielding influence over the product’s delivery: development, QA, deployment, release/rollback, project management, architecture, and the quintessential DevOps processes.
Their orchestration mandates mutual alignment, a precondition for automation predicated on agreed priorities, and meticulous articulation where automation finds its limitations.
Approaches
Within the matrix of the working process, diverse approaches come to the fore, contingent upon team members’ expertise, know-how, quality gates, or the constraints of the available budget.
Tools
Please keep in mind that DevOps tools wield power but also impose constraints. The selection demands sagacity, a wise curation tracked with rationale in the knowledge base, aligning seamlessly with the architecture development process.
Enumerating all the existing DevOps tools proves to be a futile pursuit, given the myriad options available. Instead, I’ve categorized some of the automation tools based on their functional roles, and I’m delighted to present you with an approximate DevOps toolset.
DevOps toolset
Now let’s get closer to a DevOps implementation roadmap, which covers a preliminary phase that tackles the questions lingering in the rearview mirror before we sketch the DevOps project baseline (for the brownfield projects) or outline the target architecture (for the greenfield ones).
What exactly are these preliminary inquiries?
Imagine we’ve just rolled into the project as the DevOps implementation crew. We’re in the dark, peering around, chasing the intel needed to figure out how to implement DevOps in the project. The adoption of the DevOps methodology depends on whether we’re dealing with a greenfield or brownfield project. But it all starts with a deep dive into the business needs.
Here are the burning questions:
- What business goal are we running for? Is there any silver bullet for immediate impact — something invisible to the client but glaringly apparent to us?
- What about people and enterprise processes? Are we lucky enough to have a support team backing our play, or do we have to do it all by ourselves? Or maybe, right off the bat, we need to integrate with some third-party systems using specific APIs or document formats.
- Where do we stand at this moment? What have our predecessors pulled off (if there are any), how are the current business processes humming along, and where do the gaps yawn wide?
- What are the requirements? They are crucial as they set the stage for our scope of work.
- What constraints are we wrestling with? We’re sussing out any limitations throwing a wrench into our gears — like, you know, the GDPR dictating that our servers must be in the EU.
- What’s the scope of work and terms? Here, we’re dissecting a slew of activities into project phases, setting task priorities. One of the convenient tools that helps to do this is an action plan matrix — a nifty solution to rate tasks based on their impact and the effort needed to tackle them.
Action plan matrix
When we talk about the DevOps implementation roadmap itself, we’re usually taking steps like laying out the project baseline or drawing the target architecture (like I’ve mentioned, it hinges on whether we’re in a greenfield or brownfield scenario). Then, it’s all about picking the slickest transformation approach, conjuring up epic tasks, and documenting them.
So, the DevOps implementation plan hinges on the chosen approach and the epics we’ve crafted. We take each epic, break it down into stories, those stories further splinter into tasks, and voila! The tasks unveil the interdependency between stories, giving us the lowdown on how to map out our task priorities. And for the grand finale, we picture it like a Gantt chart — visualizing the roadmap in all its glory.
Let’s talk cases: How do these plans unfold in practice?
Given the significant nuances between greenfield (starting from scratch, no established business processes) and brownfield (something’s already up and running) initiatives, let me quickly spotlight two instances from Oxagile’s portfolio where we put DevOps implementation plans into practice to tackle business issues.
Case 1: Brownfield
Picture this: A client’s data aggregation system, riding on SolarWinds, found itself in the crosshairs of hacker attacks. Our mission was to propose a solution that not only thwarts these attacks but also aligns with our client’s security requirements.
So, what went down? Here are the moves our DevOps team made:
- Virtual machine configuration within a private data center
- Automating Docker and Prometheus deployments
- System level provisioning. This entailed deploying Kubernetes clusters within the private data center, crafting base images, filling up the servers, and performing visualization activities.
- Data center level provisioning: We teamed up with the client to deploy the entire data center.
Case 2: Greenfield
This time around, we ventured into the cloud project. Here, the goal was to deploy the system on hardware, following all DevOps principles, and achieve 100% automation.
What Oxagile’s DevOps team has done:
- Deploying virtual machines on the hardware
- Virtual machines provisioning
- Filling virtual machines with the requisite content, specifically tailored to each machine’s role
A lineup of DevOps tools we’ve used:
- Kubernetes for container orchestration
- Terraform for deployment
- Helm to render configurations for Kubernetes
Benefits of DevOps: Which are the most persuasive?
If you’re not the one who’s going to implement DevOps, rest assured your rivals are ready to seize the reins of its power. Plus, if you’re thinking of going solo but skipping the automation bit in your DevOps journey, brace yourself for a slowdown. But if your DevOps implementation plan involves not just surviving but thriving in the market and expanding your business horizons, then DevOps is the savvy route. It’s the ticket to releasing your product quicker and more cost-effectively than the competitors — scaling it up and keeping its lifecycle nimble.
Now, let’s ditch the abstract chatter and dive into Oxagile’s project, where the mere absence of DevOps and the established continuous integration and continuous delivery practices was like navigating a ship without a compass. The system faced major turbulence, and the client was wrestling with databases, having no idea how to utilize them wisely, not saying that the networks were a maze that left them completely bewildered.
On top of this, their project carried a technical debt at the production stage. Every tweak to the system or network architecture became a financial rollercoaster.
DevOps just for the sake of it is the flip side of the coin. When I’m hyping up the perks of DevOps, I’m talking about sensible DevOps consulting practices and approaches, not those instances where unproven DevOps automation tools waltz into a project, complicating matters instead of solving them.
Let’s take a quick poll in conclusion
Why is DevOps a must-have for startups?
If they’re gunning for a fully-fledged MVP in three months or less, DevOps is the golden ticket. Based on my experience, without a DevOps implementation strategy and practices, your project will be stuck in development for what feels like an eternity — think about a year and a half — with no MVP in sight.
What are the pros of starting DevOps from scratch?
In the greenfield scenario, it’s like having a blank canvas — total freedom to cherry-pick the finest technologies and approaches right from the get-go. You’re also mapping out configurations and scalability options, leaving plenty of room for strategic maneuvers.
Brownfield advantages: Are there any?
While greenfield projects demand financial investments upfront, brownfield brings its own set of perks. You’re dealing with a system that’s already functioning, meaning processes are somewhat solidly in place, and there’s a stream of financial gains flowing in.
