A Microservice Architecture Needs A Microservice Process

Yes, the title of this article said it plainly, "a microservice architecture needs a microservice process." If you are using a monolithic process for a microservice architecture, forget it. You are wasting your time.

Let me explain with the figure below.

Figure A microservice architecture needs a microservice process

The three columns above shows three different stages of delivery, from development to integration testing to production. Each row represents a different combination of monolithic versus microservice architecture and process.

The top row represents the traditional way of working involving a monolithic architecture with a monolithic big-batch, big bang delivery process. We know the many problems associated with this waterfall-ish approach, and I will not discuss further.

The second row represents the approach taken by most novices, and this perhaps is caused by the term microservices itself. The first thing that comes into most practitioners' minds is to start breaking down their monoliths into small microservices. This is not wrong in itself, but if you still are using a traditional big-bang, big-batch process with lots of manual deployment, system integration and releasing all microservices at once, then you do not really reap the benefits of a microservices.

A microservice style creates an added degree of complexity. Organizations that used to have 10 applications may now have 200 microservices to develop, debug, deploy, monitor, trace and tune. This added complexity is only useful if you can deliver faster and manage microservices effectively. I will focus on the delivery part in this article. If your delivery process is still traditional, then microservices will not provide any advantage. You still are going to integrate test everything, and you do not save any time, but perhaps you may spend more time. Remember, Integration Testing is Monolithic Testing

I like to call out the integration testing step. A team that does microservices well will not need any integration test, at least in theory. Each microsevice will have its APIs and dependencies clearly defined. That means that unit microservice tests can be defined for all positive and negative cases. And, by design, so long as the APIs are adequately defined, unit microservice tests would sufficiently cover all cases, ceasing the need for integration tests. This allows a microservice that passes testing to go directly to production without the traditional integration testing step. By traditional integration testing, I mean all microservices are held up and waiting until all microservices are developed before conducting a big-batch integration testing step.

Instead, all integration test cases are already embedded into unit microservice test cases. This is what happens in the last row where a microservice architecture is accompanied by a microservice delivery process, specifically one that embeds integration and API compatibility tests within unit microservice tests. The integration testing step disappears.

Is a microservice delivery process every possible? Is there such a thing as NoIntegration? You bet! And we have such an approach for over 50 years! Just look at your phone. When you make a call from your phone to another phone, the signal goes through a labyrinth of network switches. Each network switch is tested and deployed independently. The API design and test case design do consider the effects of integration, including the fact that the switch upstream or downstream may be using an old version of the API.

Without doubt, telecom network switches are not applications, but bnevertheless, the analogy holds. Just as you do not "Integrate Test" your network, but instead test one switch at a time, the same approach, and discipline can be applied to microservices.

So, if you are thinking about adopting micrsoservices, first think about how you can turn your monolithic process to a microservice one as well.