Hi dilip.mehra,
The topic is really huge, but here are my two cents:
1 - Organizations may go for microservice development if they are investing on a new solution. Ideally you will want to start with a monolith and then break it apart by using the domain driven design. Converting a monolith to microservice technology can be time consuming and might not bring all the benefits you wished for - not to mention all the additional overhead of inter-microservice communication. If you find real value in a possible conversion, then start slowly. Figure out all of the dev-ops requirements first by defining two teams dealing with the first "break" where you find it could be really meaningful and has the most potential value.
2 - The most important values I see in microservice architecture are either related to resources utilization or resilience.
Resource Utilization:
When you deal with a monolith scale-out is achieved by duplicating the monolith in memory and having a load balance in front. The more instance you add, more memory you need. The microservices approach is that each microservice can be scaled out independently of each other. Therefore, you overall solution (application) could be comprised of several instance of the sales module whereas the customer module could have just two. Therefore, you are not duplicating the whole thing but using the memory and CPU more efficiently. Usually you can have an auto-scaller service that can increment on-the-fly processes based on the microservice's usage.
Resilience:
One of the most important feature a microservice must implement is that it must be autonomous and be able to recover from any type of failure. It means that you should be able to start additional instances, remove them, make them crash and your overall solution (your users) won't be able to notice that happening at all.
3 - Older solutions may go microservice. Be extra-careful here because most developers that have taken part of the product creation and maintenance won't be used to the dev-ops nor the platform. So, unless you have dev-ops in place and the teams are already used to develop using microservices principles, then I wouldn't suggest going that route.
4 - Another aspect that some organization really like about the architecture is that it is possible to work on a blue/green deployment. It means that companies can have a productive application running while developers can beta-test some new features on the same environment. That's basically what Facebook and others use to deliver new features to users very rapidly. The delivery cycle is really fast, because you can increment the overall solution and make some changes on the productive application, test it and make the necessary changes on the fly - and nobody will notice the old application had stopped in detriment of the new one.
5 - DevOps means you must be able to deliver to production any changes you make during development phase using automated processes for testing, building, publishing. This is most critical part because it involves both humans and automation tools. So, you must have a very effective process for TDD, source versioning repositories, Change Management, CI/CD Tools, Cloud Foundry Integration, etc. The tools will do the automation made by humans - so everything can go down the drain if a piece of the puzzle if not really well thought through or give the proper testing.
Hope this helps.
Best regards,
Ivan
Bluesky
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.