This site is also available in: Deutsch (German)
In this (formerly) short blog, the terms DevOps, GitOps and Plaform Engineering will be described and compared. Is DevOps now dead and platform engineering “the new kid on the block”? Or was it simply a case of re-branding an existing concept? And what does “GitOps” have to do with it? We shall see!
DevOps
DevOps is not a technology. That’s a short sentence, but it’s worth remembering. It is much more a cultural change that aims to connect the different camps of IT teams and improve collaboration.
Traditionally, these camps are divided into “development” and “operations”. According to the DevOps approach, the barriers between the camps should be broken down, people should learn from each other and work together. When each person feels actively involved in the projects, a shared sense of responsibility is established, which has a positive effect on overall success, satisfaction and velocity.
As a result, a number of practices such as continuous integration, continuous delivery, test automation,
infrastructure automation, monitoring (and much more) have become established in the DevOps environment. This does not mean that infrastructure automation or monitoring solutions did not exist beforehand. That is not the point. Much more important is the efficient provision and smooth collaboration of the various experts. Possibly even within a team.
By establishing these (and other) practices and shifting the mindset of the organization and everyone involved, teams will be able to develop, test and deploy software faster and more reliably. If there’s one takeaway from this section, it’s this: The DevOps approach seeks to solve the increasing complexity of systems, particularly through a cultural shift. Of course, technologies play a central role in the implementation as an executive tool.
GitOps
GitOps is an approach to deploying and managing software and infrastructure. The most obvious feature is that a Git repository serves as a “single source of truth” for the automated provision of software and infrastructure (CI/CD). Essentially, all applications and infrastructure components that are required for the respective project are written down, including their versions (and possibly other details). When changes are made to this “inventory list”, pipelines (or similar mechanisms) ensure that the changes are applied. Sounds simple, doesn’t it?
- The truth is in the repository – everyone knows where to look
- The application does not need more than what is in the repository to be executable
- Not only the software, but also the required infrastructure is described
- … resulting in development and operations suddenly using a common platform
- A deployment is a commit (+push)! This inevitably means that it is clear who, when and what has been rolled out to which environment
- Security issues are also addressed. It is now easy to use the repository to determine whether teams are using outdated templates or infrastructure components that they should no longer be using
- Migrations can be carried out much faster if configurations are stored in a central location
- ….
Platform Engineering
For the impatient among us, in the first sentence we answer two questions that we are occasionally asked:
- Is DevOps the same as platform engineering? No
- Is DevOps dead? No
But there is something that both approaches have in common: the need for an increasing number of components and complexity in systems.
While DevOps tries to solve the problem of collaboration and decreasing velocity during software development from a cultural perspective, platform engineering tries to approach the problem from a different angle: that of self-service.
The following example illustrates the different approaches: An application is to be implemented that consumes and processes data from a Kafka topic and stores the result in a database. The Kafka resources are to be provisioned using Strimzi (a Kubernetes operator), while the database is to be provisioned in AWS RDS. Unfortunately, there is a catch: the person chosen for the implementation is not familiar with either Strimzi or AWS RDS. Increasing complexity inevitably means that not every person can know everything.
The DevOps approach could look something like this: Either a team member is consulted or a member of a “cross functional” team assists in writing the Terraform/CloudFormation/CDK/… and Helm/Customize/Scaffold templates, which are then stored and applied in a Git repository.
The platform engineering approach would be that there is an“Internal Developer Portal” (idp) in the company, where the respective developer can request both the database and the Kafka resources via a self-service, which are then created.
construction of an integrated product (the IDP) that includes toolchains and workflows
to meet the operational requirements of the entire
software development cycle. This self-service approach enables
developers to achieve a high level of quality in a very short implementation time according to current best practices. The IDP must inevitably be well maintained and in return promises the entire organization a potentially high increase in speed in software development.
It is important to note with this approach that not every use case can and should be covered. There are always edge cases or developers who have an exceptionally high level of expertise in the respective areas. The IDP provides the Golden Path according to the current status – it is not a Golden Cage.
Finally, a few exemplary use cases for an Internal Developer Portal:
- Overview of available services and responsibilities (Service Catalog)
- Provisioning cloud resourcesProvisioning Kubernetes
- Resource bootstrapping of projects based on templates (e.g. using Cookiecutter)
- Automated requesting of resources through a stored workflow
- Provide pipeline descriptions when creating new projects
- Upgrading existing projects, for changes to the Golden Path
- ….
