devopsy.kinsta.cloud

Tag: IaC

What’s the Difference Between DevOps and Platform Engineering?
The DevOps space is buzzing with a new trend—platform engineering. Platform engineering has been gaining steam over the last few years but has really peaked in interest lately. In fact, according to a study conducted by Puppet Labs, 51% of organizations have adopted platform engineering or plan to do so in the next year. But what exactly is platform engineering, and how is it different than DevOps?

Below, we’ll explore the nuances between these two concepts. We’ll review what DevOps and platform engineering are and see how they’re similar and dissimilar. We’ll also outline the benefits of platform engineering and suggest some best practices to make the most of this emerging discipline.

What is DevOps?

DevOps is a broad topic, but it generally involves efforts to increase software release efficiency and frequency. Some of the hallmarks of the DevOps discipline include reducing siloes between teams and increasing collaboration. DevOps is often directly associated with various tools that automate the process of moving code from a local environment into production, also known as continuous integration and continuous delivery (CI/CD). Monitoring, incident management and configuration management tools also support the DevOps process.

“DevOps reflects more of a philosophy and a way of working,” said David Sandilands, senior solutions architect for Puppet. DevOps enables more of a shift left mentality. Instead of having operations teams “guarding the gates,” developers work in partnership with Ops. In doing so, groups can decrease build time significantly, he said. This style helps engineers incrementally and rapidly release new features, replacing old waterfall development cycles.

The ultimate goal of DevOps is to automate the software life cycle and shorten the feedback loop. Thus, DevOps takes a life cycle approach to shipping applications more efficiently, streamlining phases such as build, release, configure, monitor, plan, create and verify. Microservices architecture and containerization also often play a crucial role in enabling DevOps.

What is Platform Engineering?

Platform engineering is all about developing a self-service internal platform that serves the needs of developer consumers. Although DevOps opened things up and empowered individual developers with advanced automation, it left organizations with scattered tooling and processes, especially at large enterprises. For example, various infrastructure-as-code (IaC) configurations might exist for similar functions within the same organization but be unknown to engineers in different departments. Not to mention, overseeing a growing DevOps pipeline means added responsibilities around continual updates and security.

Platform engineering places more control in the hands of a central platform team rather than individual developers. These teams typically treat the platform as a product. They do so by evaluating the needs of developers across an organization, building out internal self-service tools that suit the needs of most consumers and maintaining the platform.

The 2023 State of DevOps Report found that this self-service approach typically handles areas like deployment, operation of infrastructure, monitoring production applications and security and compliance. Other capabilities, such as abstracting Kubernetes or overseeing secrets management, may also play a role in these efforts.

Benefits of Platform Engineering
- Improve developer experience: Platform engineering can enhance the experience a developer has with their software build and release systems. A better developer experience can do loads to improve morale and create a more productive engineering atmosphere.
- Standardize DevOps practices: By bringing together common DevOps approaches into a shared platform, organizations can begin to standardize with reusable build processes and automated infrastructure. This can unite an organization on common runtimes, observability methods and deployment processes. This can streamline the introduction of DevOps practices to an organization.
- Secure the DevOps pipeline: Various vulnerabilities exist within tooling that comprises modern CI/CD chains and cloud-native open source software. By outsourcing DevOps responsibility to a shared platform team, the organization can coalesce around more secure practices and avoid overlooking important updates or holes.
- Supply additional guardrails: Platform teams might also assist in the acquisition of new tools as well as outlining and enforcing policies for software infrastructure. While this may come at the cost of customization, additional guardrails can help avoid shadow IT and governance around internal development. Letting platform teams handle it could make maintenance easier across an organization.
Platform Engineering: Under the DevOps Umbrella

I don’t see platform engineering as replacing DevOps. Instead, I view platform engineering as falling under the umbrella of DevOps since platform engineering takes DevOps processes and makes them more reusable and self-service. Both use a lot of automation and share many of the same end goals.

However, there are nuances between the two approaches that reflect the recent trends in the IT market. With DevOps, the market was more interested in shifting responsibility left and empowering individual developers to oversee the entire software life cycle. Now, as sprawl and shadow IT emerge, the pendulum seems to be shifting back toward a bit more centralization and governance with platform engineering.

Platform engineering is typically more of an in-house development initiative. So, what are some best practices IT divisions should remember to get the most out of platform engineering? Hope Lynch, senior director of platform at Cloudbees, shared some great strategies to consider that revolve around treating the platform as a product. Doing this involves accepting feedback from developers, not controlling everything and always maintaining a focus on developer experience.

Hopefully, by following these tips, organizations should have a better grasp of the emerging discipline of platform engineering and have the confidence to begin introducing platform-based concepts within their own environments.
May 18, 2023
Start Automating Now

A bit of feedback I received from last week’s post is that I didn’t provide any background, I just jumped right in with examples. So let’s take a step back and talk about the bigger picture.

It is always a surprise to me when I talk to enterprise friends and associates and hear that automation has not taken over their DevOps processes. Yes, we still (and might always) want the ability to have a person review what is being done and make course corrections if the automation has something wrong, but most of the automation that is available for DevOps is no longer new and should be a no-brainer.

The ability for a build to block based upon any given criteria and notify Jira or ServiceNow—or whatever issue tracking system you use—while alerting the people responsible for the build is simply obvious … and yet, some organizations aren’t even that far yet. The ability to stop a build, create a ticket, assign it to the appropriate person and give it a priority is built into most of these products. It should be looked at to see if it’s suitable to the organization.

This goes on and on. We’re now to the point where everything in the toolchain can be automated. IaC and GitOps are tackling the broad operations end, and if the application is 100% public cloud-based, CloudOps simply solves the problem. Automation from check-in to production is possible, with very few places where intervention from humans is needed.

Given that most of this technology is mature—even though some of it has not been around as long but has broad enough adoption that it can be considered mature (Flux and Argo come to mind here)—it is time for enterprises to start another round of automation. Just like AI won’t eliminate most development jobs this year, automation won’t eliminate jobs, either. But we’ve been so strapped for time for so long that this may be a surprise. Automation might reduce the need to scramble for new team members while asking current employees to give a bit more … over and over.

So get started. The math that made DevOps appealing in the first place—streamlining to reduce time to market and free up IT hours—is the same math that applies to the current round of automation. The more that can be automated, the more time team members will have to perform more productive work.

Having mentioned AI in passing, I’ll use that as a segue to include AI in the “automation” discussion. At this time, nearly all of the tools we call AI are simply advanced automation tools and should be considered in the process of increasing IT automation. The ability for an app to run, learn your systems and improve them (be that improvement in development, security or ops) is just advanced automation. In the places where it works well in a given environment, it should be adopted. It is highly unlikely that AI will get worse over time, so even marginally acceptable AI results make it worth implementing, counting on technology advancements and continued training to improve that benefit moving forward.

So, start automating now. Free your time, take a holiday at the beach, do the same job in less time or, to quote a previous generation, “Work smarter, not harder.” You’re doing the job that keeps the servers humming and users coming, now do it with less effort. And keep rocking it.

April 19, 2023
Pulumi Brings Advanced Analytics and AI to IaC Platform

Pulumi today launched a platform that leverages analytics and artificial intelligence (AI) to generate infrastructure-as-code (IaC) from natural language prompts in addition to automating infrastructure management.

Pulumi CEO Joe Duffy said Pulumi Insights will substantially improve the productivity of DevOps teams in addition to ultimately reducing the total cost of cloud computing.

At the core of Pulumi Insights is an analytics engine automation application programming interface (API) that enables DevOps teams to launch queries using a search interface or natural language prompts across more than 100 cloud computing platforms. Results can then be organized to highlight the most-used clouds and resources broken down by project and environment using built-in dashboards. There’s also a REST API that makes it possible to export that data to a data warehouse such as Snowflake, Amazon Redshift, Google BigQuery and Azure Synapse.

In addition, Pulumi has created a companion website and command line tool to make it possible to create code for provisioning infrastructure. That uses large language models like those at the core of generative AI platforms such as GitHub CoPilot or ChatGPT that promise to eliminate much of the toil associated with writing code.

Pulumi has been making a case for an alternative approach to IaC tools, such as Terraform, that gives enterprise IT organizations more control over how IT environments are provisioned. Too many developers with limited cybersecurity expertise are provisioning infrastructure themselves, resulting in misconfigurations that cybercriminals can then easily exploit.

The Pulumi approach also makes it simpler for IT teams to create platform engineering teams that can centrally apply guardrails that prevent those issues from arising without slowing down the rate at which applications are being built and deployed, noted Duffy.

There’s also a much greater focus on improving the productivity of DevOps teams during uncertain economic times as organizations look to either limit or reduce the number of full-time employees they hire or retain.

For one reason or another, DevOps teams are going to be required to find ways to become more productive as the number of applications being built and deployed continues to increase. AI clearly has a major role to play in enabling organizations to achieve that goal. However, before organizations can reliably benefit from those advancements, they will need to ensure the accuracy of the data those AI models use to surface recommendations and generate code. Otherwise, no matter how advanced these platforms are, the results will be suboptimal.

In the meantime, IT organizations will need to revisit how IaC tools are being employed in an era where the focus on securing software supply chains has dramatically increased after some high-profile breaches. The challenge is that, in addition to all the applications currently being developed, there are thousands more that were deployed by developers without the same emphasis on cybersecurity.

April 13, 2023
env0 Extends Workflow Platform for Provisioning Infrastructure

env0 today announced it has added support for additional infrastructure-as-code (IaC) tools and the Microsoft Azure DevOps platform to its workflow automation and management platform.

Fresh from raising an additional $35 million in funding, env0 CEO Ohad Maislish said while Terraform remains the most widely used IaC tool, there are now more organizations using alternatives such as CloudFormation from Amazon Web Services (AWS) along with Pulumi and Terragrunt.

Other capabilities added to the env0 platform include automated drift detection, multi-tier workflows, auditing, external logging platform integration, support for plug-ins and expanded role-based access controls and OpenID Connect (OIDC) authentication.

Finally, env0 is extending its existing Terraform support to include support for remote backend, module registry, remote plan, and the ability to plan and apply pull requests. The capabilities are especially critical for organizations that are now building microservices-based applications that require more sophisticated workflows to provision infrastructure resources, noted Maislish.

Most IaC tools are designed to enable developers to address technical implementation and provisioning issues without regard for user experience, security and governance, or business goals. The env0 platform makes it possible to create infrastructure environments with guardrails in place that enable DevOps teams to centrally address governance issues, noted Maislish.

In general, there’s now a lot more focus on continuous delivery (CD) as organizations look to continuously update applications, said Maislish. That requires a more structured approach to provisioning infrastructure across teams of developers that is managed by a platform engineering team, he added. The challenge is that CD is dangerous—in the sense that mistakes can easily be made, noted Maislish.

It’s not clear whether organizations are embracing platform engineering to centralize the management of DevOps workflows, but the number of organizations that have mastered CD best practices remains low. Most organizations are adept at continuous integration (CI), but given the number of unique platforms on which applications are deployed, CD has proven more challenging to adopt. In theory, a platform engineering team should make it easier for DevOps teams to define a consistent approach to CD that could be adopted across an organization.

Regardless of the DevOps approach, the overall goal is to improve developer productivity. The problem is that in the absence of any guardrails, developers have been provisioning cloud infrastructure as best they can. Not surprisingly, cloud computing environments are rife with misconfigurations that create vulnerabilities that cybercriminals have become more adept at exploiting. The fundamental issue is not such much the cloud infrastructure that is available as much as it is the processes employed to provision the resources. In their rush to build and deploy applications, developers will sometimes ignore best practices unless guardrails force the issue.

One way or another, IT organizations are exercising more control over cloud computing environments as the security of software supply chains becomes a bigger issue. The only thing that remains to be resolved now is how to put much-needed guardrails in place in a way that adds the least amount of friction possible.

March 29, 2023
Quali Update Strengthens Infrastructure Security

Quali today announced enhancements to its Torque automated infrastructure platform to add support for security scans and Open Policy Agent (OPA) software being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

OPA enables organizations to implement cybersecurity policies as code. The challenge many organizations have encountered is that not many developers have mastered the programming language required to implement OPA. Quali is embedding OPA in a platform that enables IT teams to implement it using a graphical tool that enables central management and application of those policies.

David Ben Shabat, vice president of research and development at Quali, said the overall goal is to implement scans and policies in a way that reduces the number of misconfigurations that are made when organizations provision infrastructure-as-code (IaC).

As part of that effort, Torque now flags any policies that fail validation. In addition, administrators can pick and choose which OPA policies to import, including both out-of-the-box and existing custom policies. Those policies then enable Torque to automate approvals or denials of deployments based on compliance with those policies after scans and other health checks have been run.

Quali has been making a case for policy-based triggers for cost controls, automated start-up, shut down and pausing of IT environments to give IT teams more control over infrastructure using a software-as-a-service (SaaS) platform. That approach enables IT teams to provide a set of guardrails for provisioning infrastructure that prevent mistakes from being made, noted Ben Shabat. Those controls can be applied using the graphical tool Quali provides or programmatically via an application programming interface (API) that Quali exposes, noted Ben Shabat.

It’s not uncommon for a port to be left open, for example, which cybercriminals later exploit to exfiltrate data. Quali is offering a DevOps platform that allows for central application of policies that act as guardrails to prevent developers from making these types of mistakes as an alternative to scripts created using tools such as Terraform. That approach also provides more visibility into how infrastructure resources are being consumed.

Every minute a developer spends managing infrastructure is one less minute they could be spending writing code. As application environments become more complex, it is becoming more challenging for developers to manage infrastructure-as-code. The issue is that DevOps teams who could provision infrastructure for developers are overwhelmed by the number of projects they need to manage. As a result, DevOps teams are becoming bottlenecks. Naturally, that only encourages more developers to provision infrastructure on their own, leading to more mistakes.

It’s not clear whether IT organizations will look for an alternative to provision infrastructure in a way that doesn’t require developers to have as much infrastructure expertise. However, as organizations look to lock down software supply chains, the way infrastructure is provisioned using code will, in many cases, need to be reconsidered within the context of a larger DevSecOps workflow.

February 15, 2023
Back to Basics

We here at devopsy.kinsta.cloud do sometimes suffer from The Curse of Knowledge. We write about DevOps regularly for an audience that is doing or managing DevOps. We assume knowledge, but there are still a fair number of people and organizations who are unclear about some of the terminology/technology that we talk about.

So if you are a regular reader of my blog, this might be a redundant post—but read on because it might have info you haven’t had a reason to consider yet.

I’m going to start with the obvious—how most readers got here to begin with: DevOps. DevOps is automating the build process so that builds are automated and repeatable. Teamed with Agile development, DevOps means that development teams can rapidly iterate through development and generate regular updates to their applications. Everything else in this blog is based on the premise that it is running in a DevOps environment.

Continuous integration: Typified by Jenkins, continuous integration (CI) is the part of DevOps that runs the automated builds. It includes reporting and defect resolution only in the sense that it feeds into other systems that track defects. With CI in place, a developer or DevOps engineer can say, “Okay, ready to test a build,” and with one command, can kick off a build that will result in a finished artifact. Or result in a built product, anyway. ‘Finished’ is optional, and the target of CI is not generally a running application.

Continuous delivery: One of the most confusing things for new DevOps people is CD. The way that the space evolved, there are actually two things that CD could stand for; continuous delivery–automated build of the complete application —or continuous deployment—delivery of a running application onto infrastructure. Continuous delivery is straightforward and means all the bits of the application are code complete–or at least the current state of the application is complete enough to build an application. Continuous deployment is much more convoluted. It might mean deployed to a development environment for developer-level testing or a test environment for running automated (continuous testing) tests on or in production. It might be a staged rollout, where users are siphoned over, or it might be a hard rollout where the old version is replaced by the new in a manner similar to ripping a Band-Aid off.

Continuous test: Automated testing is at the heart of continuous test (CT), and it is only now becoming a real possibility for most short-staffed enterprises. Advancements in machine learning (ML) mean that tests can be run, results filtered to eliminate false or duplicate results, and IT staff is only notified of the important bits. Unlike traditional testing, staff is required only to create the tests and to look at meaningful results.

Infrastructure-as-Code: Infrastructure-as-Code (IaC) is the ability to define all relevant elements of infrastructure with text files. Often this is done in YAML and sometimes in a variety of other formats. The idea is that infrastructure provisioning can be on-demand and adaptable. It is certainly more agile to change a text file from port 80 to 8080 and then run a command to process the text file–now the port is documented and whenever needed the command can be re-run to move to a known state. IaC largely relies upon software implementations over physical. While the idea of software-defined networking (SDN) has fallen out of favor, the underlying principles are everywhere and part of IaC, for example.

GitOps: All the rage these days, GitOps is probably best defined as applying DevOps to operations. That does sound weird, but I like to break it up as “traditional DevOps is DevOps, while IaC (to a lesser extent) and GitOps (to a huge extent) are DevOps.” The point being that GitOps uses the text files generated in IaC and worker nodes generally designed for continuous deployment and then performs operations tasks based on those text files. If IaC defines the entire environment that an application needs and DevOps defines all of the sources that an application is composed of, bundling the two together will enable full-on automation from conception to decommissioning. When a new version of a source file or configuration file is checked into Git, the system then makes certain that every instance of the application is updated with the new version. Of course, this process, like every one listed here, is far more complex than that in implementation; we are talking about ‘what, not how’ at this level.

All of this really is the very tip of the iceberg, but that was the goal here – to offer readers a place to start if they’re finding themselves looking at DevOps for the first time. As you dig deeper, things like DevSecOps and test driven development (TDD), or defect tracking and Agile methodologies start to play into the landscape, and maybe I’ll write an intro bit for those also. But this time, we’re out of space.

As always, keep rocking it. No matter which or how much of the above you are using, if the organization’s applications are up and running, that’s you. And you deserve more kudos than you are likely getting. But keep grinding through—the rest of us get it, and thank you.

Image source: Photo by Towfiqu barbhuiya on Unsplash

February 15, 2023
Understanding the Infrastructure Automation Maturity Model

Nearly every company wants to evolve its digital transformation and increase the pace of software delivery and operations. And infrastructure automation is a new means to achieve these ends. It supports the emerging discipline of platform engineering and can increase scalability and reactivity to unforeseen events, enabling software ecosystems to be more anti-fragile. Increased infrastructure automation also helps free up engineers from focusing too much on managing DevOps when they really should be building out new features.

But introducing more infrastructure abstraction can be met with certain challenges. This is often because departments have a wide range of cultures, processes and tooling already in place. With varying maturity levels across teams, it can be challenging to gauge where a company is before attempting to introduce new automation across the board. And as further evolution may require significant changes, having a baseline is key to planning for the future.

I recently chatted with David Williams, senior vice president of market strategy at Quali, about an internal technique they’ve been using at Quali to gauge the maturity of their clients’ infrastructure automation. Their infrastructure automation maturity model breaks down the journey into four unique stages, moving from the least-mature ad-hoc automation to the most-mature autonomous solutions. Below, we’ll review this model and consider what questions need to be asked to ascertain where your team sits on the spectrum. We’ll see how enterprises can leverage such a model to hone in on improving their software operations.

Four Questions to Determine Infrastructure Maturity

DevOps is still a wild west in terms of how people approach it, said Williams. So before attempting to mandate sweeping cultural changes, it helps to first determine the base level of DevOps maturity within an organization. Here are four questions that can quickly assess the state of infrastructure automation within an organization.

1. What Culture Already Exists?

First, it’s good to evaluate the culture that already exists. How do teams deliver value and how is this value measured? Perhaps throughput or code quality is measured with specific metrics or SLAs. Understanding the DevOps attitude (and aptitude) within the organization will highlight pre-existing capabilities and show how teams collaborate.

2. How Are People Organized?

The genetic makeup of teams can dictate much about development and operations. How are teams organized? Are they large, siloed teams? Or are they two-pizza-sized teams? Understanding team organization and communication patterns are necessary to identify bottlenecks.

3. What Processes Are Already in Place?

Next, consider the development timelines and procedures already established and in use. Are teams applying SAFe, Lean, Agile or Scrum methodologies? What are these exact processes and how mature are they? Answers to these questions will demonstrate general release cadences and how teams drive productization.

4. What Infrastructure Automation is Already Being Used?

Lastly, you’ll need a window into what level of infrastructure automation, if any, is already in use today. How is it delivered? How is it managed? How is the success of this automation measured, and what is the overall outcome? You will likely find that automation is typically quite siloed and teams have differing approaches. This auditing is vital to identify what works well and what doesn’t.

The Four Levels of the Infrastructure Automation Maturity Model

Asking the above questions will quickly determine an organization’s “readiness state,” said Williams. But how do these answers map to the overall maturity of the organization’s infrastructure automation? Well, he shared four basic levels of infrastructure automation maturity that are commonly found in practice throughout today’s software development environments, ranging from bespoke scripts to more robust self-defining automation.

Level 1: Ad-hoc

The most basic level of infrastructure automation is ad-hoc integrations involving a mix of old and new technology. This level is chaotic and fragmented, with varying processes used throughout the organization. These bespoke integrations and scripts also may not have excellent visibility, limiting the potential for reusability within an organization.

Level 2: Automation

Next is having automation that is specifically tied to a certain technology stack. Nowadays, organizations are commonly hybrid multi-cloud, having adopted automation piecemeal with each new stack. This often results in multiple silos of automation stacks that are blind to each other. At this maturity level, one automation might fire off another automated procedure and so on, but engineers aren’t 100% aware of how they influence each other.

Level 3: Frictionless

The next level of infrastructure maturity begins to take the reins with more intentional automation adoption. At this stage, organizations embrace an internal developer platform, similar to Spotify’s Backstage, that helps engineers deliver and manage infrastructure more seamlessly. This tooling is more advanced than other levels integrating key commands into the developer’s IDE. Doing so eliminates the need to switch between environments and reduces friction.

Level 4: Self-Defining

Finally, the most advanced form of automation involves deeper intelligence within application operations, including the ability to dynamically optimize infrastructure. At this stage, infrastructure is self-defining, meaning production applications can automatically adapt, be self-governed and enable bursting and non-bursting capabilities. Such intelligence is typically proprietary to cloud providers, said Williams, yet companies often desire this intelligence inherent at the application level. Williams describes this stage as the “intelligent allocation of resources in line with application life cycle requirements.”

Benefits of Self-Defining Infrastructure Automation

Self-defining infrastructure automation has many benefits for companies, including having the infrastructure in line with application needs, scalability and measuring usage to optimize cloud spending. Many points within the software development life cycle could warrant increased automation, such as infrastructure-as-code (IaC), deployment release engines, configuration, traffic scalability, cloud management, containerization and documentation. But it’s not until you open conversations around infrastructure automation maturity and understand who is responsible for managing it that you can hone in on what areas can be improved.

February 14, 2023
The Differences Between DevOps and GitOps
The transition to a DevOps model has been welcomed by many organizations that are looking to implement more efficient development processes. However, there are multiple models to choose from, with GitOps a popular choice for many. So what is the difference, and which one is better?

In this article, we will discuss what each model entails and their key differences and establish if one is better than the other for your business.

What is DevOps? – An Overview

The DevOps model involves several tools and practices designed to make software development much more efficient. This increase in efficiency is achieved by implementing more automation, adopting continuous delivery practices and improving the communication channels between the developers and operations.

Ultimately, DevOps is designed to assist organizations in deploying new products and systems faster. By establishing more collaboration between development and operational teams, changes can be made quickly to best suit the business’s overall goals.

There is no single tool that is required for DevOps. In fact, your team can use any tool that effectively improves communication and automates key tasks.

How to Integrate a DevOps Strategy

Adopting and integrating a DevOps strategy into your organization’s overall workflow is not a difficult process, and it can be achieved by following these steps:
1. Create a continuous integration/continuous delivery (CI/CD) pipeline.
2. Configure this new pipeline to enable the automated deployment of changes to your development/production environment.
3. Set up an alert and monitoring system for your development environment.
4. Create collaboration channels so operational teams can inform the developers of new opportunities to improve the business’s workflow.
An Overview of GitOps

GitOps is a modern concept that was initially introduced by the Kubernetes management system Weaveworks. This model uses Git, an open source, distributed version control system, to track any changes to a system and who has made them.

The GitOps model uses a Git repository as the single source of truth (SSoT), improving collaboration between developers and operational team members. This, in turn, allows organizations to automate the deployment process.

By leveraging CI/CD pipelines like DevOps, changes are automatically applied to the codebase without any need for manual input. Thanks to Git, these changes can also be easily reversed if needed, reverting to a previous working version.

How to Integrate a GitOps Strategy

GitOps can be integrated into a business’s workflow quite simply by following four key steps:
1. Set up a Git repository for your organization’s codebase. When integrating a GitOps strategy, an organization does not need to use GitHub exclusively, as any code repository that uses Git commands can do the job.
2. Connect this repository to a CI/CD tool.
3. Configure your chosen tool to deploy automatic changes to your development environment. Popular tools include Jenkins and Circle CI.
4. Set up monitoring and alerts for your development environment.
It should be noted that the CI part of GitOps still needs to go through your DevOps tool, whether it’s GitHub Actions or AWS CodeBuild.

The Differences Between DevOps and GitOps

The core difference between the two is that GitOps allows teams within an organization to manage and deploy changes to infrastructure using Git as the single source of truth. DevOps, on the other hand, focuses on effectively connecting development and operational teams using a tool of the organization’s choosing.

Either model can offer a number of benefits in terms of development and deployment, but there are notable differences between the two that should be considered. It should also be noted that DevOps and GitOps can work in unison as long as continuous integration (CI) is delivered using your chosen DevOps tool.

DevOps – Key Elements
- The DevOps model is considered a working culture.
- DevOps can use a variety of CI/CD pipelines and is not restricted to any one tool.
- This model increases automation and the regularity of deployment, reducing any human input.
- Cloud configuration can be used for coding, supply chain management and other key requirements.
- The pipeline separates development and operations processes while improving collaboration between the two.
GitOps – Key Elements
- GitOps is a development and deployment technique that relies on the Git version control system.
- Git is used as the single source of truth for all changes to the codebase.
- GitOps can use Kubernetes and infrastructure-as-code (IaC) practices and various other CI/CD pipelines.
- The GitOps model is designed to increase development times and reduce reliance on lengthy scripts.
- It also enables a smoother transition between a project’s development and operation stages.
DevOps Vs. GitOps – Which Model Is Better?

Both GitOps and DevOps are becoming increasingly popular when it comes to adopting new approaches to improve software development processes and making deployment quicker and more efficient. As outlined above, the difference between the two models largely comes down to the tools that are used, but the result is roughly the same in terms of the overall benefits.

Deciding which approach is the right one for your organization or determining which one is “better” will always come down to the needs and requirements of your organization. In fact, the ideal scenario would be to integrate GitOps so it works alongside your DevOps approach.

GitOps is not a replacement for DevOps, as the CI process still relies on DevOps tools. However, GitOps can improve the effectiveness of the DevOps team thanks to continuous delivery processes. Using Kubernetes-native mechanisms and commands and sticking to standard source code principles, GitOps does not require developers to change how they work, guaranteeing a seamless implementation process.

Wrapping Up

DevOps is a working culture that improves collaboration between development and operations teams and utilizes automation tools, resulting in rapid and more efficient software development. GitOps, on the other hand, uses Git as the single source of truth, making it easy to track changes and further increase development times thanks to continuous delivery processes.

Although each model can be used exclusively, they can also work alongside each other to deliver rapid software development and high levels of collaboration. Therefore, it is unfair to claim that one model is better than the other, as they can both play their part in an overall DevOps strategy.
February 9, 2023
Looking Ahead, 2023 Edition

DevOps is in a perpetual state of change that keeps all of us engaged and busy, but makes a mess of things overall. Do you cloud-first? Are your APIs GraphQL yet? Are you doing SDN to connect to the VPN so you can put files on the CDN and build closer to the market? Sorry, had to do it. You get the point.

The point is that the ground is forever changing under us, and often things that seem straightforward are not. Like “cloud-native,” including Kubernetes. Yeah, I get it, you mean software-defined infrastructure that works well with infrastructure-as-code (IaC); this field is confusing enough—calling it cloud is dumb when, these days, cloud has a specific meaning in the minds of IT.

In our current round of change, a few patterns are showing up. Automation is king. Sometimes it is sold as AI/ML because those are the buzzwords of the day, but it is just continuing the trend of automation to make IT more responsive and predictable. We are rapidly approaching a point where the entirety of the application development/deployment process can be automated reliably and configured to create predictable results. By that I mean that development has more assistance writing code, test has more assistance running tests and processing results, deployment environments can be grabbed from application release automation/orchestration tooling and the final product all of that means that builds can be deployed with very little human interaction unless something breaks.

Highly automated systems are a prerequisite of high-volume output, though – automobile factories are the easiest example of that statement. My problem is that we don’t seem to be asking “Should we be high-volume producers?” Does the average enterprise require non-stop development? I think that the initial answer is yes, and the more considered answer is “Only because the business wants more, consistently.”

At some point, the gains we received from DevOps need to be looked at from the “What value is added?” perspective. And that is a business function with IT input. Before SaaS and DevOps made IT easier (to get something running; not minimizing our work here), the business had to consider carefully if it needed that application or that change to an existing one. Today, that consideration is pretty much “Because we want it, put it on the backlog.” But all of our new development adds to our technical debt. While the wave of automation we have been living through since “The Pheonix Project” was first published is keeping us ahead of the curve, we will inevitably need to consider flattening the curve. I suggest that the time is now.

Getting started with this is actually pretty easy. For many organizations, simply stating, “We do not need two ways to do that” will yield benefits quickly. Other organizations will have to ask “Why can’t we use the functionality of existing tools/apps to do that?” and yet others will need to ask the business, “Do we even need to do that?” Prioritization still exists, and management does an okay job of pushing back at all of the organizations I talk to. Still, at some point it goes beyond “prioritize your wishlist,” and IT managers will have to start asking if a project is even necessary–even if doing so makes waves.

Continue to rock it, but we’re past time to look for redundancy, synergy and misdirection. There is more complexity coming, and more sweet solutions to problems (both known and unknown) are right around the corner. But, as I’ve said before, simplify as you go because you need to be able to handle the next wave, and eventually, automation won’t cover the gap.

January 31, 2023
Devs Increasingly Rely on IaC to Manage Multiple Clouds

A survey of more than 300 DevOps professionals conducted by Firefly, a provider of a platform for automating cloud provisioning, found that more than a third of organizations (36%) have allocated the equivalent of two or more full-time engineers per month to writing infrastructure-as-code (IaC) templates.

A full 82% are also deploying the templates within the context of a DevOps pipeline, with 68% reporting more than half of their cloud instances are now managed using IaC tools, according to the survey. A total of 27% reported they are now managing every aspect of IT as code.

The challenge is that 61% of respondents also admitted they can’t automatically detect configuration drift over time, with more than a third (35%) spending days or weeks remediating IaC templates. Well over half of respondents (56%) said they are also retrofitting existing cloud instances using IaC tools.

Cindy Blake, vice president of marketing for Firefly, said this issue is likely to become more challenging to address as the number of clouds in use continues to increase. The survey found 44% of respondents already use multiple cloud providers. Overall, 42% reported having more than 10 cloud accounts.

The top IaC benefits identified by survey respondents are improved efficiency (75%), increased reliability (55%) and easier compliance (52%) and simpler troubleshooting (49%).

Not surprisingly, the survey identified knowledge (46%) followed closely by complexity (43%) as the top challenges organizations face when using code to manage cloud infrastructure. Factors increasing complexity included cost and complexity (70%), followed by security (61%).

In addition, only 14% of respondents reported that all their engineers are IaC literate. More than a third (36%) said they only have one IaC-literate engineer. As a result, many organizations are now attempting to navigate IaC bottleneck issues that could be alleviated if they relied more on automation that can be integrated within a continuous integration/continuous delivery (CI/CD) platform, noted Blake. She added that many organizations are already allocating too much engineering time to manually writing IaC templates.

Those manual efforts often result in misconfigurations that are easily exploited by cybercriminals, added Blake. Many developers using IaC tools such as Terraform have had little to no cybersecurity training, so the odds they will make a mistake are high.

At a time when more organizations are focused on the productivity of DevOps teams and ensuring the integrity of software supply chains, there is a clear need to automate processes that increasingly span multiple clouds. More organizations than ever are employing multiple clouds to ensure application availability in the wake of a series of outages over the past few years, Blake said.

Regardless of the motivation, multi-cloud computing is here to stay. Developers opt for different clouds based on the performance capabilities they can provide for various classes of workloads. There may be one cloud platform that runs the bulk of the workloads, but the number of organizations that have standardized on a single cloud are comparatively few. The issue is finding the best way to manage multiple clouds that doesn’t require as much manual effort so organizations can reduce the total cost of managing IT environments.

January 11, 2023