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
The Bulkhead pattern is a type of application design that is tolerant of failure. In a bulkhead architecture, elements of an application are isolated into pools so that if one fails, the others will continue to function. It’s named after the sectioned partitions (bulkheads) of a ship’s hull. If the hull of a ship is