This post shares some highlights from Decomposing DevOps: Understanding How to Get Started, a session that I gave at Red Hat Summit in San Francisco this week together with Dylan Silva of Ansible by Red Hat.
Our general approach in this session was to look at DevOps on-ramps first from a primarily developer-centric perspective and then from a more ops-oriented one. These aren’t mutually exclusive especially given that DevOps inherently commingles dev and ops concerns to a certain degree. Nonetheless, thinking about these two different constituencies is one useful way to frame the discussion.
For the dev-centric point of view about DevOps (which is what I’ll cover in this post), I find that a manufacturing metaphor provides useful insights. Whether building a car or building an application, what are some of the important principles to follow?
The first is automation. Worker productivity in automotive manufacturing has doubled in something like the past 20 years. Automating repeatable processes has simultaneously improved predictability and quality. (I guess it’s an exception to the “Better, faster, cheaper: Pick two” rule.) Similarly, developer automation that leads to an iterative CI/CD pipeline with build/test/approve/deliver/deploy stages leads to both faster and higher-quality software delivery.
W. Edwards Deming, one of the original champions of statistical quality control, once said that “Without data you’re just another person with an opinion.”
Measurement and metrics are likewise a key ingredient in an iterative software development pipeline. DevOps metrics were actually the topic of a separate birds of a feather session discussion that I led with my colleague William Henry. A full discussion is beyond the scope of this post, but when thinking about collecting data it’s useful to step back and consider your most important objectives and then design a plan from that starting point.
The automotive industry, like others, has embraced the idea of modularity and reuse; about half of all cars are built on a modest number of platforms that share key components and design elements across models and across brands. We see this same modularity in the concept of microservices—small, autonomous, bounded context services that communicate through APIs. Even when microservices aren’t adopted in their purest form, automated DevOps pipelines work most effectively when deployments can be small, frequent, and generally decoupled from other deployments.
If DevOps can be thought of as transitioning software development from craftwork to a more industrialized set of processes, then the place where new cloud-native apps run can be equally thought of as morphing from a workshop to a factory. This factory has characteristics such as the following:
- Software-defined infrastructure and/or public cloud
- Automation
- Application lifecycle management
- Developer experience including self-service
- Application services (databases, messaging, integration, mobile)
- Container ecosystem
- Orchestration and resource control
- Management
There’s enormous innovation happening in all these areas across a wide range of open source communities. However, making all this consumable for developers is certainly a challenge. That’s a big reason why, in a study of DevOps early adopters conducted last year for Red Hat, IDC found that 80 percent expected PaaS to play a crucial role in enabling DevOps because “Platform-as-a-Service (PaaS) cloud infrastructure, self-service developer platform and tools, and lifecycle management with DevOps processes—speeding time to value for both developers and operations."
That’s exactly what OpenShift does by bringing together technologies such as Red Hat Enterprise Linux, docker-format containers, kubernetes orchestration, CICD pipelines, and developer tooling. Features include:
- Self-service
- Multiple interaction models
- Polyglot, multi-language support
- xPaaS services
- Immutable, container-based platform
- Automation for application builds, deployments, scaling, and health management
- Persistent storage option
The result? Developers get up and running quickly and gain access to the platform and tools that they need to be productive without sweating the details of the underlying infrastructure.
No comments:
Post a Comment