Please log in to watch this conference skillscast.
Or: How to control the risks of continuous deployment for Node.js microservices
The microservice architecture is a powerful way to structure large scale Node.js systems, providing a component model that scales both at the human and system levels. To fully gain the benefits of the microservice architecture, you need to move to a continuous deployment work process. It should be possible for developers to write the code for a new feature in the morning, and deploy it to production in the afternoon. This high-speed development cycle allows you to meet business goals much more effectively.
Continuous deployment brings risks. You can no longer manage those risks in the traditional manner. There is no multi-month release cycle to fall back on. The familiar work categories of development, quality assurance, information security, and operations no longer apply. Instead you must learn to live with the devops approach. But giving developers the keys to the server does not automatically imply less downtime, even if you hand out pagers with the keys, and adopt a "you build it, you run it" philosophy. Even when this approach does work, it is notorious for burning people out. Is there a sustainable set of work practice that reduce the risk of continuous deployment to acceptable levels.
The solution is to take a scientific, engineering based approach, grounded in reality and driven by actual business goals. First, quantify the business objectives, both in terms of the value that you intend to create, and in terms of the cost-benefit of failures. There are always going to be failures, so what's your error budget - how much downtime is acceptable? Second, control the production system by making all changes incremental - you are only ever allowed to add or remove a single microservice instance. Nothing else. Microservice instances are built as immutable artefacts - changes to production are not possible. To change behavior, you must deploy a new instance. This gives you a definitive history of the system. It also gives you a way to measure risk!
Each microservice instance change can be measured. By connecting your quantified business goals to the technical metrics of the live system, you can verify each change. Does it improve the metrics or harm them. If it does harm them, then rollback the change. The rollback is not a major event - it is just the deactive of a single microservice instance. By using immutable microservice instance as the unit of deployment, you enable the use of many risk reduction strategies without needed to build custom implementations. From partial deployment, to canaries, to bifurcated verification, to blue-green deployments, and many others. All of these deployment models are defined as operations on microservice instance activation states. By connecting the state of the system with your business goals, and by operating at speed within a defined error budget, you can fully control the risks of microservice deployment, without need the overhead of traditional release planning.
YOU MAY ALSO LIKE:
Richard Rodger is CTO of nearForm, a leading Node.js specialist. He is a technology entrepreneur who has been involved in the Irish Internet industry since its infancy and wrote the seminal book on Node: Beginning Mobile Application Development in the Cloud.