Operations | Monitoring | ITSM | DevOps | Cloud

GitOps has become a buzzword. Developers love it, because it folds DevOps into Git, a frequently used and familiar tool. Using one tool to manage multiple DevOps activities sounds fantastic, and it can be helpful for many. The truth is GitOps has limits. In this article, we explore DevOps and GitOps, compare their similarities and differences, and examine how their principles can work together to support your software development goals.

Flux is a CNCF based open source stack of tools. Flux focuses on making it possible to keep Kubernetes clusters and cloud-native applications in sync with external resources and definitions hosted in environments such as GitHub. Implementing tools like FluxCD should enable you to achieve results such as: The results above can bring obvious benefits, and many teams are adopting FluxCD as their tool of choice for GitOps.

Matt and I are out in Los Angeles this week for KubeCon 2021 this week. At the GitOpsCon event Tuesday we were excited to attend this Kubernetes session: GitOps in the Real World: Opportunities for Developer Experience Improvement.

In a previous post, we talked about the increasing adoption of Platform Engineering teams. The post covered topics such as defining Platform Engineering and the roles and responsibilities of the team. When building an internal platform, a clear goal that many teams want to achieve is: Even though this is key to a successful platform team, this responsibility increases complexity, costs, support time, and more. Not to mention that this can be a long, very long journey.

Not to muddy the waters with one more prefix in front of ops, GitOps is a newer DevOps paradigm that slants towards the developer. As the names states, GitOps is focused around Git, the source code management tool. As a developer, leveraging an SCM is one of the quintessential tools of the trade; allowing for collaboration and more importantly saving your hard work off of your machine.

GitOps is one method used by teams to deploy microservices, but challenges usually arise when deploying applications across multiple clusters and environments. For your GitOps initiative to be successful, you should consider implementing an application operating model. In this second workshop we covered.

This article was written by a guest author. Not long ago, if we wanted to put our code into production, we needed to manually configure a server, our infrastructure, that would host our app or database. This manual process is not only time-consuming, but also prone to errors. That is why at present, developers chose to create “scripts” that are in charge of configuring the infrastructure These “scripts” are known as Infrastructure as Code (IaC).

The idea to fully manage applications, in addition to infrastructure, using a Git-based workflow, or GitOps, is gaining a lot of traction recently. We are seeing an increasing number of users connecting their Shipa account with tools such as ArgoCD and FluxCD. Based on that, we conducted multiple user interviews to understand some of the challenges teams face when implementing GitOps, especially those introduced or faced by their developers.