A Microservices architecture makes it possible to isolate failures through well-defined service boundaries. But like in every distributed system, there is a higher chance for network, hardware or application level issues. As a consequence of service dependencies, any component can be temporarily unavailable for their consumers. To minimize the impact of partial outages we need to build fault tolerant
In the most recent projects I’ve worked on, the teams I’ve been a part of have decided on the direction of a microservice architecture pattern. The main motivation for this has been to overcome the challenges typically faced in monolith architectures. However, when dealing with microservices, you’re likely to face the issue of communication between the different services that
Designing Microservice Architecture the right way is quite challenging and difficult. On contrary to Monolith Architecture which gives one solution for all, Microservice Architecture gives a different solution for different problems. If the wrong solution is chosen, then the Microservice Architecture is just a ticking time bomb that is destined to explode. A badly designed
In Microservice Architecture, there are many Microservices often developed by separate teams. These microservices work together to fulfill a business requirement (e.g., customer request) and communicate with each other Synchronously or Asynchronously. Integration testing of a Consumer Microservice is challenging. Usually, TestDouble is used in such scenarios for a faster and cheaper test run. But TestDouble often does not represent the
Every business Application has many configuration parameters for various Infrastructure (e.g., Database, Network, connected Service addresses, credentials, certificate path). Also, in an enterprise environment, the application is usually deployed in various runtimes (Local, Dev, Prod). One way to achieve this is via the Internal Configuration, which is a fatal bad practice. It can lead to severe