Practical learnings on microservices

Publish date:

If you are planning a cloud-based project, then you must seriously consider going cloud native to efficiently use all the resources available on the cloud. Cloud native means making use of microservices and DevOps as the foundational building blocks. DevOps teams build microservices and APIs and then orchestrate these services on containers or managed container platforms

Below are some notes on real-life learnings from a live project where the Capgemini Cloud team built over 60 services.

Designing the microservices:

  • Start with the business focus for each service
    • Design these as small services with CRUD operations on a single business function or domain.
    • Use the API-first design approach to ensure that reusable services are built across LOBs and these conform to enterprise-wide consumption and comply with security and governance requirements.
    • Domain-driven design (aka DDD) is the de facto architecture pattern for microservices. This helps break up the complex system into data-driven microservices that reflect the business problem.
    • The key challenge in DDD is deciding where to define the boundaries of each bounded context. This will require multiple iterations – you start with unique contexts and redesign to avoid chattiness between services.
    • Use lightweight REST-based communication (client-to-service and service-to-service) where there is need to communicate between services. This, however, must have loosely coupled services and you must ensure that the services are stateless.
    • Break up services into synchronous and asynchronous, preferring async as far as the business process allows. This slots into the favored philosophy of “smart endpoints and dump pipes.” This basically means that the microservice is built using asynchronous communications thereby keeping the service autonomous and not depending on other services.
    • Appropriate design patternssuch as aggregator, proxy, and branch patterns are commonly used.
    • In unavoidable cases, there will be distributed transactions and the need to design for them. The common solution to this is the saga pattern, which helps design for failures in case of distributed in case of partial executions.
    • Go beyond the twelve-factor design for microservices. Capgemini Cloud Native uses fifteen-factor design principles to achieve agility, scalability, and operational efficiency.
  • Resilience
    • Microservices must be designed for network and system failures, for example delays, errors, or unavailability of another service or third-party system.
    • As mentioned earlier, keeping communication async allows an architecture that is resilient when some services fail.
    • They must provide a default functionality in case of failures from a service. This could be an error message or if the business case permits, a default value that is acceptable until the external service is available.
    • Even if services are built for a UI screen to consume, it must be responsible for all data input validation – (client-to-service and service-to-service). There are common frameworks to do this using expression language and annotations rather than code.
  • Observability
    • Centralized logging and monitoring is a must across distributed microservices along with tracing and alerting mechanisms
    • Log events for timeouts and shut downs
    • Logging should include the level, hostname (instance name), message
    • Log events can be used for capacity planning and scaling, for example which services need higher instances
    • Business data related metrics such as number of bookings, or time taken to fill out the form.
  • Automation
    • Use Testing tools for integration of services – in unit testing the service as well as contract testing to ensure the APIs are functioning even though the service is treated as a black box.
    • Quick feedback on check-ins and failures in the build and CI/CD pipeline are possible through automation testing as soon as code is committed and built.

Would you like to learn more about the fifteen-factor design or our point of view on the containerization platform options for microservices –contact me for more information.

Related Posts


Delivering faster with better use of micro-frontends in financial services

Date icon September 21, 2021

What works well is multiple SPAs owned by specific DevOps teams that can decide what happens...


No one likes waiting. With Continuous Delivery, now you don’t have to!

Venky Chennapragada
Date icon March 22, 2021

Automated and on demand – here’s how, why, and when you should adopt Continuous Delivery...

cloud services

Product-oriented delivery, enabled by POD models

Rishi Kulkarni
Date icon November 26, 2020

Why POD models are the future