The most popular and comprehensive Open Source ECM platform
Let us know more
Microservices: The Ultimate Architecture or Distributed Pain?
30 percent of Java developers are already architecting systems based on microservices and another 20 percent are piloting microservices for ultimate deployment, according to a survey by Lightbend.
What are some of the advantages of microservices?
- Scalability – In an application architected with microservices, as load increases, only those heavy-use elements of the entire application need to be scaled up.
- Simplicity – Each microservice is autonomous, can be tested independently and doesn’t require a complex environment for development.
- Economy – Because maintenance is easier and faster, fewer developers and support staff are needed.
- Scoped – Upgrades and repairs can be limited in scope. If something breaks only that one microservice needs to be repaired and then redeployed rather than the entire system. This approach also enables more frequent and incremental upgrades.
But that’s not all. Other benefits of a microservice architecture include:
- Polyglot programming – The platform is language agnostic and systems can easily be built up from individual services running on .Net, Java and Spring, or other languages.
- Hot swapability – Replacing, deprecating or adding new microservices is easy to do and can be a life-saver when trying to fix mission critical problems
So, it all sounds good. But, one big problem is managing and monitoring many independent services. The complexity of it all grows very quickly. If something goes wrong, where do you know to look to diagnose the problem?
Bert Ertman, a fellow at Luminis, said that “the first thing to realize about microservices is that it is all about distributed computing. With so many moving parts there will always be something that breaks. Leveraging tools and techniques to do distribution and asynchronous programming models was never easier than today, but can you also wrap your head around those things? Understanding, debugging and solving issues are exponentially harder in a distributed environment than in the traditional world of running everything in a big application server. My key message is to explicitly design for failure from the start and treat as a fact of life that things break. Make sure you are prepared and have your alternatives ready, both in code and on the infrastructural level.”
