Microservices rules #8: Design independently deployable services
microservice architecture microservices rules testingContact me for information about consulting and training at your company.
Until June 25th, enroll for $95 in my virtual bootcamp, distributed data patterns in a microservice architecture
This is another article in the series about microservices rules: what good looks like, which are a set of principles and practices for using microservices effectively. The articles in the series are:
1. Practice continuous delivery/deployment
2. Implement fast, automated deployment pipelines
4. Provide a great developer experience (DevEx)
5. Use a deliberative design process
6. Design independently deployable services
7. Design loosely coupled services - part 1, part 2, part 3
8. Design testable services
9. Develop observable services
10. Big/risky change => smaller/safer and (ideally easily) reversible changes - part 1 - incremental architecture modernization, part 2 - continuous deployment, part 3 - canary releases, part 4 - incrementally migrating users, part 5 - smaller user stories
11.Track and improve software metrics and KPIs
Microservices rules #8 is design independently deployable services. Independently deployable service is a defining characteristic of the microservice architecture. Many of the benefits of the microservice architecture are due to services being independently deployable.
In this article, I will define what it means for a service to be independently deployable and why it’s essential. Then, I will look at a common antipattern - end-to-end testing - and the problems that it creates. Finally, I explain how to migrate away from end-to-end testing to independently deployable services.
Let’s start by defining independently deployable.
Read more (This post is for paying subscribers only)
Need help with accelerating software delivery?
I’m available to help your organization improve agility and competitiveness through better software architecture: training workshops, architecture reviews, etc.