DevOps for Microservices

Main > Key Concepts > DevOps for Microservices

The Microservice Architecture is the one that has finally equalized the cut for a unit of (back-end) software among all three life-cycle stages: design (logical), development (build) and run-time (deployment). The classical 4+1 Architectural View now can have the same granularity of domain representation in the three UML diagrams: Class, Component and Deployment.

So, the same concept that is first conceived at design time (possibly doing DDD) is then implemented, packaged, tested, deployed, executed, measured and operated.

And here comes the complexity to DevOps: what is good and essential to Lightweight Architectures ads complexity to the CI (Continuous Integration), CD (Continuous Deployment) and CT (Continuous Testing) pipelines.

##Individual development environments Monolithic state-full applications are developed in a shared development environment the same way the production one is.

With state-full microservice, however, each developer must have a separate environment for each microservice under development, without any shared production-like services such as Directory Service, API Gateway, Message Bus, etc.

The subsequent environments (Integration, Quality Assurance and Production) are all shared ones and the microservice must be connected to such shared production-like services.


So, the same code should behave the same way in stand-alone Development environment and in remote shared ones, with only changes in its configuration files.

Liquid makes it easy to do so by dealing with those configuration changes, by controlling the way a microservice communicates externally, calling or being called.

##Single repository & policy for many (deployable) units

The microservice concept is the new black and aims to reach the corporate scope as a whole, leading to hundreds of these software units to be developed, deployed and executed individually.

On the other hand, many projects will be changing these units independently, in waves, in a manner not linked to any previously defined rigid structure or silo, as usually is the case with monoliths. In fact this is another subtle aspect of Liquid Applications.

It should also be noted that projects and teams are different entities. And while a project is likely to span multiple microservices (involved in the new features to be built), it is best practice to organize teams by domain (by microservices). And that only adds to the sophistication of the versioning strategy.


Hence microservices should be CI, CD and CT independently, starting from a delta of code change that was made as a release of one of the active projects - all sharing the same code repository every which way.

Liquid provides CI, CD and CT templates for working with this strategy, starting small (with few individual microservices) but making the addition of new ones a matter of simply adding new code. And that could grow to hundreds or thousands.

The new code is then automatically CI, CD and CT by the same DevOps pipeline. No need to create a new build definition for each new microservice or to split a single (dynamic) release into various pull requests for each statically separate repository.

##Unit and integration tests on deployed software units By having dependency on its entire run-time stack to get tested, a microservice must first be deployed to then be available for testing.

To do so in a continuous fashion (CD and then CT), it is necessary to mock many dependencies transparently and with little (or, hopefully, no) additional test coding.

Mocking and unmocking calls to other microservices allows to easily convert unit tests into integration tests and vice-versa.

Liquid makes it easy to continuously test microservices by providing a simple way to mocking/unmocking synchronous and asynchronous calls (REST and messaging) and authentication as well as seeding test data.