Microservices Best Practices for the Optimal Architecture Design

Microservices have fundamentally changed the way server side applications are architected. Rather than a single giant monolithic codebase hosting all the business logic of your application, microservices reflect the distributed systems model, where a group of application components work together to deliver the business needs.

1. The Single Responsibility Principle

Just like with code, where a class should have only a single reason to change, microservices should be modeled in a similar fashion. Building bloated services which are subject to change for more than one business context is a bad practice.

2. Have a separate data store(s) for your microservice

It defeats the purpose of having microservices if you are using a monolithic database that all your microservices share. Any change or downtime to that database would then impact all the microservices that use the database. Choose the right database for your microservice needs, customize the infrastructure and storage to the data that it maintains, and let it be exclusive to your microservice. Ideally, any other microservice that needs access to that data would only access it through the APIs that the microservice with write access has exposed. 

3. Use asynchronous communication to achieve loose coupling

To avoid building a mesh of tightly coupled components, consider using asynchronous communication between microservices. 

4. Fail fast by using a circuit breaker to achieve fault tolerance

If your microservice is dependent on another system to provide a response, and that system takes forever to respond, your overall response SLAs will be impacted. To avoid this scenario and quickly respond, one simple microservices best practice you can follow is to use a circuit breaker to timeout the external call and return a default response or an error. This will isolate the failing services that your service is dependent on without causing cascade failures, keeping your microservice in good health. You can choose to use popular products like Hystrix that Netflix developed.

5. Proxy your microservice requests through an API Gateway

Instead of every microservice in the system performing the functions of API authentication, request / response logging, and throttling, having an API gateway doing these for you upfront will add a lot of value. Clients calling your microservices will connect to the API Gateway instead of directly calling your service. This way you will avoid making all those additional calls from your microservice and the internal URLs of your service would be hidden, giving you the flexibility to redirect the traffic from the API Gateway to a newer version of your service. This is even more necessary when a third party is accessing your service, as you can throttle the incoming traffic and reject unauthorized requests from the API gateway before they reach your microservice. You can also choose to have a separate API gateway that accepts traffic from external networks. 

6. Ensure your API changes are backwards compatible

You can safely introduce changes to your API and release them fast as long as they don’t break existing callers. 

7. Version your microservices for breaking changes

It's not always possible to make backwards compatible changes. When you are making a breaking change, expose a new version of your endpoint while continuing to support older versions. Consumers can choose to use the new version at their convenience. However, having too many versions of your API can create a nightmare for those maintaining the code. Hence, have a disciplined approach to deprecate older versions by working with your clients or internally rerouting the traffic to the newer versions.

8. Have dedicated infrastructure hosting your microservice

You can have the best designed microservice meeting all the checks, but with a bad design of the hosting platform it would still behave poorly. Isolate your microservice infrastructure from other components to get fault isolation and best performance. It is also important to isolate the infrastructure of the components that your microservice depends on.

9. Create a separate release train

Your microservice needs to have its own separate release vehicle which is not tied to other components within your organization. This way you are not stepping on each other’s toes and wasting time coordinating with multiple teams.

10. Create Organizational Efficiencies

While microservices give you the freedom to develop and release independently, certain standards need to be followed for cross cutting concerns so that every team doesn’t spend time creating unique solutions for these. This is very important in a distributed architecture such as microservices, where you need to be able to connect all the pieces of the puzzle to see a holistic picture. Hence, enterprise solutions are necessary for API security, log aggregation, monitoring, API documentation, secrets management, config management, distributed tracing, etc. 

By following these microservices best practices, you should end up with a loosely coupled, distributed, and independent microservice system, wherein you can achieve the true benefits of a microservices architecture as listed at the beginning of this article.

Remove a file from git pull request

Learned something amazing today.

Scenario : You have updated a file that already existed in main branch and want to remove it from the pull request.

Assume you're working on a branch (say featureBranch) off of development (means you created featureBranch from the development  branch) , and your pull request includes a file named AccountController.java.

To remove this file from the pull request and revert its changes, simply do :

1. Checkout your branch (featureBranch).
2. Run below command.
     git checkout development --  AccountController.java
3. Commit and push into your branch (featureBranch).

IntelliJ | SLF4J: Failed to load class org.slf4j.impl.StaticLoggerBinder

JAVA standalone program failed with below error on IntelliJ (Community Edition 2020.3).

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".

SLF4J: Defaulting to no-operation (NOP) logger implementation

SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

Process finished with exit code 0

Fix : 

Go to File-> Project Structure -> Modules,  then update slf4j dependency to compile.