Fast feedback accelerates decision making and provides more time for making observations and identifying new directions.Observe, orient, decide and act (OODA), pioneered by John Boyd, is increasingly used to model feedback loops in software development processes. Successful companies have adopted this decision-making framework and turned it into a commodity.
Feedback loops are an essential ingredient of Agile and DevOps mindsets. Feedback loops not only provide immediate results on activities in the development process, they also instill good habits among developers. Scientifically speaking, it’s been proven feedback loops change human behavior and actions.
Stages of the Feedback Loop
Building a feedback loop for developers requires attention to four distinct stages. It starts with collecting observations, including the feature usage metrics, code quality, static analysis, performance metrics and testing results, among others. We can term it as the first stage of the feedback loop.
This information is then fed into an engine that provides valuable inferences based on the observations. These inferences avoid the clutter of raw data and produce practical metrics, including test coverage, cyclomatic complexity, user preferences and more. This can be termed as the second stage of the feedback loop.
The data generated from the first stage, and the inferences produced through the second, are used to create directions. This is the third stage, wherein each direction is a possible path of calibration and diagnosis. The directions represent multiple choices for decisions that could be taken based on the result of the first and second stage.
Finally, an action is taken in the fourth stage, depending on which decision is selected. The actions taken are then fed back into the loop. This circular process is very effective in creating a flow in the software development process, and in the long run, reduces the cost of changes and emergence of issues.
The most important aspect of the feedback loop is the time it takes for each step to complete.
The goal is to automate as much as possible in each stage of the feedback loop. A fast feedback loop is essential to move and produce reliable software for end users. This reliability breeds from the actions that are continuously taken based on current observations and decisions thereafter.
One of the major roadblocks to building faster feedback loops is the pain of integrating and deploying large code base. A large code base increases the cost of compilation, bundling and deploying on an infrastructure. The cost of installing the required dependencies for a software environment to run the code can be prohibitive and slow the process. Also, with regards to diverse deployment environments running on heterogeneous infrastructure, supporting this diversity can become another issue that leads to further latencies. All of this adds up to longer decision intervals and reaction times, both of which are crucial to delivering production-quality software to users.
The Cost of Change
At the heart of a fast feedback loop is reducing the cost of change. Improving feedback time from minutes to seconds, although seemingly trivial, can have a large impact on reducing this cost of change. Developers can confidently build new infrastructure and code with the promise that no change is too big. Facebook’s mantra of “done is better than perfect” fits into this ideology of being able to build software at a rapid pace while minimizing costs.
As communities and organizations start experimenting with microservices, they also need a new way to bring the change to their feedback loop.
That’s where containers come in. The container ecosystem is promising this change, and ultimately allowing developers to see their code in action by accelerating all four stages of the feedback loop.
Hyper-Agile Feedback Loop and Developer Experience
A hyper-agile feedback loop is one where the transition time from one stage to the other is minimal and measured in seconds.
Creating a hyper-agile feedback loop is nothing short of an extraordinary developer experience. Such an experience encourages risk taking, alternative solutions and a cycle of Kaizen. The easiest way to understand how the container ecosystem produces this hyper-agile feedback loop is to be aware of the ecosystem participants and their contribution to the loop.
We can do this by mapping the container ecosystem to the key aspects of the hyper-agile feedback loop. This feedback loop will typically involve the following:
- Quick and Consistent Development Environment Provisioning: The developer on a team obtains the local test environment and source code for their development environment. The test environment is itself a declarative manifest that is used to provision the environment for the developer. The provisioned environment is a containerized set of service instances each running independently. The local test environment contains all the necessary services and related dependencies for the product.
- Loosely Coupled Development: The developer changes or adds a new service, along with the required test cases. The local test cases are then run to test the changes. To avoid breaking clients, developers could also insist on having consumer-driven contracts to validate the change before publishing.
- Automated Deployment and Tests: The developer then deploys this change to the local test environment and triggers the integration tests for the various participating services that use this particular service.
- Version-Controlled Development Artifacts: Once the changes are tested with the local test environment, the developer then commits the changes to the repository. If the service also requires a configuration change or a new dependency, the developer adds that to the environment manifest and commits the same.
- Automated Build and Production Release: Committing the code leads to scheduling a build task on the build and deployment service. This service only deploys the relevant changed service as a new service version, instead of replacing the old version, which follows the principles of canary releasing. The appropriate load balancers are informed of the new service version and a progressive load shifting takes place to allow a certain amount of requests to the new changes in the service.
- Migration and Deprovisioning: The new change is then observed and metrics are collected based on A/B testing and user analytics, vis-a-vis the older version of the same. If the results are promising, more load is shifted and eventually the new service takes prominence over the old one. The old version is gracefully retired. If the change is not promising, then the new service is gracefully deprovisioned, and the load is moved off of it.
The above steps merely scratch the surface of what is possible when creating a feedback loop for developers. The container ecosystem provides a rich set of services covering a wide range of capabilities for developers, and accelerates each of the above steps.
Platforms and Version Control
One of the most interesting aspects of the container ecosystem is the rise of niche PaaS options, like Tsuru, Giant Swarm and Deis, among others. Some of these PaaS options are transparent solutions while others provide a layer of abstraction in the form of developer-friendly DSLs to architect and deploy complex applications. With rapid change cycles and an iterative development process, PaaS solutions like these come in handy when considering quick developer feedback. Existing PaaS implementations, like IBM Bluemix, Pivotal Cloud Foundry, Apcera Platform and OpenShift, have already geared up for integration with the Docker and container toolchain, and provide mature, stable options for enterprise-level solutions.
Most organizations adopting containers for purposes of speeding up their development process have the inherent need to manage multiple versions of their services at the same time. This is primarily needed to support canary releasing and service immutability. The latter is an interesting proposition, in that it is considered a change to deploy a new service instead of updating an existing one. This reduces rollback time and provides an opportunity for A/B testing.
The Need for Standardization
To enable fast feedback for changes, it is essential to provide developers with a template that has all the underpinnings of the various container ecosystem toolchains, including monitoring, governance and PaaS integration and solutions.
At the heart of all these concerns is the idea of standardization.
A project like ZeroToDocker is an initial step towards creating a boilerplate for developers — one that is already preconfigured to provide microservices-based development practices. This allows developers to invest their time developing and releasing reliable code instead of managing the complexities of a service-oriented system.
The idea is to have a standardized “hello world” boilerplate project for different language types. It would consolidate best practices of service-oriented development, including preconfigured logging, monitoring, service registration and discovery, and integration with container ecosystem toolsets. This forms the service unit of a microservices system, which can be quickly developed and released without reinventing the wheel.
Despite its roots and vibrant history, the current container ecosystem is still in its infancy, and changing nearly every day. The criteria for creating a mature platform for fast feedback loops will also, surely, change in the course of container ecosystem maturation. However, it does already provide the building blocks for creating a hyper-agile feedback loop, which signals how software will be built and released in the coming years.
Apcera, IBM, Pivotal, Red Hat are sponsors of The New Stack.
Feature image via Pixabay.