The idea to fully manage applications and infrastructure using a Git-based workflow, or GitOps, is gaining a lot of traction recently. We are seeing more and more Shipa users adopting GitOps as the cloud-native deployment methodology. While it is no secret that ArgoCD and FluxCD are by far the most used tools today, we see FluxCD users trying to address the challenges below.
Shipa is designed to make it simple for developers to run their code on Kubernetes without having to know Kubernetes and for platform engineers to enforce controls and policies.
On August 11th, 2021, we conducted a workshop to discuss implementing a GitOps workflow using ArgoCD, Crossplane, and Shipa. We were overwhelmed by the hundreds of people who registered for the session. We believe it shows a few important challenges have to be solved for GitOps to become mainstream across different enterprises. While GitOps brings many benefits, we often see teams facing challenges.
Virtualization and cloud have forced the need for automation. In the “old” days, it would take weeks for a new physical server to arrive. There was little pressure to install and configure the operating system on it rapidly. We would insert a disc into the drive and then follow our checklist. A few days later, it would be ready to use. But the ability to spin up new virtual machines (VMs) in minutes required us to get better at automating this process.
Kubernetes allowed us to manage application deployments and infrastructure components using declarative configuration files (yes, those YAMLs that you may not be a fan of ). While dealing with a myriad of YAML files may be loved by some and hated by others, it enables us to host all these files into a Git repository, hook it up to a pipeline (Jenkins, GitLab, etc.), and have a tool apply those changes to a cluster—and voilà, you have GitOps.
The growing adoption of microservices and Kubernetes gave rise to the need to efficiently manage, schedule, and control Kubernetes clusters, where tools like Terraform are helping many organizations address those challenges today. Terraform is a popular choice among DevOps and Platform Engineering teams as engineers can use the tool to quickly spin up and edit environments directly from their CI/CD pipelines.
In a previous post, we discussed what an Internal Developer Platform (IDP) is and some drivers behind IDP initiatives. If we go through our interactions with different organizations, we see teams embarking on the journey to build their IDPs mainly driven by the following requirements: While building an IDP may seem like an obvious choice and initiative, it is definitely not an easy task to accomplish. Building an IDP involves dealing with many moving components.
GitOps has been getting traction as a cloud-native approach to continuous deployment, leveraging Git for version control. If executed well, GitOps can bring benefits such as automation of your continuous deployment pipeline, lower downtimes, consistency of workflows, and more.
In a previous post, we described how we envision cloud-native initiatives reaching the 2.0 phase, where phase 1 was centered around providing clusters and running its underlying infrastructure effectively. Now that teams are starting to move some of their existing services to a microservices architecture, developers and platform engineers are being tasked with implementing the right policies and governance controls to ensure applications are running as securely as possible.
At this point, it’s fair to say that containers and Kubernetes changed the dynamics of infrastructure and platforms. It’s no secret that even though managing Kubernetes clusters is still somewhat complex, in the early days, it was even harder, which is when we saw solutions such as Rancher come up to help us address those challenges. You will inevitably run into cluster-related challenges when adopting Kubernetes.
