71Continuous Delivery

Microservice deployments are nothing more than the introduction of a single new instance. If the deployment fails, rollback is the decommissioning of a single instance. Microservices give you well-defined primitive operations on your production system: add/remove a service instance. Nothing more’s required. These primitive operations can be used to construct any deployment strategy you desire. For example, blue-green deployments break down into a list of add and remove operations on specific instances.

The definition of a primitive operation is a powerful mechanism for achieving con- trol. If everything is defined in terms of primitives, and you can control the composi- tion of the primitives, then you can control the system. The microservice instance is our primitive, and the unit with which we build our systems. Let’s examine the journey of that unit from development to production.

5.6

Continuous Delivery

The ability to safely deploy a component to production at any time is powerful because it lets you control risk. Continuous delivery in a microservices context means the ability to create a specific version of a microservice, and to run one or more instances of that version in production, on demand. The essential elements of a con- tinuous delivery pipeline are:

 A version-controlled local development environment for each service, sup- ported by unit testing, and the ability to test the service against an appropriate local subset of the other services, using mocking if necessary.

 A staging environment to both validate the microservice, and build, reproduc- ibly, an artifact for deployment. Validation is automated, but scope is allowed for manual verification if necessary.

 A management system, used by the development team to execute combinations of primitives against staging and production, implementing the desired deploy- ment patterns in an automated manner.

 A production environment that’s constructed from deployment artifacts as much as possible, with an audit history of the primitive operations applied. The environment is self-correcting and able to take remedial action, such as restart- ing crashed services. The environment also provides intelligent load balancing, allowing traffic volumes to vary between services.

 A monitoring and diagnostics system that verifies the health of the production system after the application of each primitive operation, and allows the develop- ment team to introspect and trace message behavior. Alerts are generated from this part of the system.

The pipeline assumes that the generation of defective artifacts is a common occur- rence. The pipeline attempts to filter them out at each stage. This is done on a per- artifact basis, rather than trying to verify an entire update to the system. As a result the

Even when a defective artifact makes it to production, this is still considered a nor- mal event. The behavior of the artifact is continuously verified in production after deployment, and the artifact is removed if not acceptable. Risk is controlled by pro- gressively increasing the proportion of activity that the new artifact handles.

Continuous delivery is based on the reality of software construction and manage- ment. It delivers:

 Lower risk of failure by favoring low-impact high-frequency single instance deployments over high-impact low-frequency multiple instance deployments.

 Faster development by enabling high frequency updates to the business logic of the system, giving a faster feedback loop, and faster refinement against business goals.

 Lower cost of development as the fast feedback loop reduces time wasted on features that have no business value.

 Higher quality as less code is written overall, and that which is written is imme- diately verified.

The tooling to support continuous delivery, and the microservice architecture, is still in the early stages of development1_{. Though an end-to-end continuous delivery pipe-}

line system is necessary to fully gain the benefits of the microservice architecture, it’s possible to live with pipeline elements that are less than perfect.

At the time of writing, all teams working with this approach are using multiple tools to implement different aspects of the pipeline, as comprehensive solutions don’t exist. The microservice architecture requires more than current Platform-as-a-Service vendors offer. Even when comprehensive solutions emerge, they’ll still present trade- offs in implementation focus2 _{. It’s probable that you’ll continue to need to put}

together a context-specific tool-set for each microservice system that you build. As we work through the rest of this chapter, the desirable properties for these tools will be the thing to focus on. You will almost certainly need to invest in the development of some of your own tooling. At the least this will be integration scripts for the third-party tools you’ve selected.

5.6.1 Pipeline

The purpose of the continuous delivery pipeline is to provide feedback to the devel- opment team as quickly as possible. In the case of failure, that feedback should indi- cate the nature of the failure. It must be easy to see the failing tests, the failing performance results, or the failed integrations. You should be able to see a history of the verifications and failures of each microservice. This isn’t the time to roll your own tooling—there are many capable continuous integration tools3_{. The key requirement}

for you is that your chosen tool can handle many projects easily, as each microservice is built separately.

73