Chaos engineering is a hot topic in the platform engineering field as organizations try to build more robust applications. Chaos engineering involves deliberately injecting faults into a system to observe its behavior and build confidence in the behavior of that system. The Chaos Monkey from Netflix pioneered the concept of deliberately inflicting chaos on a production system, but the discipline has grown extensively since this initial project.
Enterprise application development services are growing faster than organizations can deliver them. For development teams, it means a growing necessity to become a high performing dev team that achieves ultra-fast operational performance and software delivery ahead of their competitors.
In an increasingly fast-paced and complex business world, the continuously disruptive digital channels and mobile devices evolution and competition mean organizations must adapt to survive. For example, technology leaders must wrap their heads around DevOps acceleration to gain an advantage and expand their software market opportunities.
We’re all used to spicy social media debates producing more heat than light. But occasionally, the script is flipped and something useful is illuminated. Such is the case with a recent debate about the state of DevOps. It was started in the comments on a post by Leon Wright titled, “No one should write Terraform.” That spawned threads on Twitter (Sid Palas), with more conversation on Reddit, here and here. The bottom line?
“Platform engineering is a process organizations can use to leverage their cloud platform as efficiently as possible so that engineers can deliver value to production quickly and reliably. It consists of removing obstacles between developers and production.”
The Open Policy Agent is emerging as a standard framework for policy decisions in cloud-native environments. Running OPA on Kubernetes is a common method to provide Kubernetes admission control. OPA has become so popular that even Terraform recently announced beta integration of OPA support in Terraform Cloud.
When I reference ServiceNow in discussions with DevOps and platform engineers they often look at me and quickly roll their eyes – with that bored look on their faces saying “next…” Why is that? At Cloudify, our DevOps automation platform primarily targets DevOps engineers, who were also locked in this mindset. Over the past year and a half, we started a deeper integration between Cloudify and ServiceNow, originally as a way to address a specific customer environment.
The DevOps world is going through rapid changes and rightfully so. In a world where everything is cloud or cloud-native-based, scale is becoming one of the most critical parameters for business efficiency. In fact, velocity is no longer measured by the number of code lines a developer produces, but rather by the time it takes the team to release a feature. Focusing on a feature release rather than the number of code lines forces businesses to switch to a more sophisticated delivery mechanism.
The #1 KPI is not how fast a developer codes, but rather how long it takes from the time a developer starts to work on a new feature till it gets to production. In this blog I’d like to describe a few concepts and present a real life example, where we utilized a chain of open source tools to automate the entire software development process, from code to production.
Organizations are eagerly adopting containers and Kubernetes, investing in cloud-native to foster innovation and growth. According to the CNCF and Slashdata, nearly 5.6 million developers use Kubernetes. That’s 31% of all backend developers. We all know that Kubernetes is a great container management platform.
