To begin with an interesting question, is a microservice architecture a good choice for the system you’re working on?
Basically, micro-service often deals with large team, multi-tenancy, supporting many user interaction models, allowing different business functions to evolve independently, and scaling. However, the best answer is it depends on complexity and productivity. If a system is less complex, microservice will reduce productivity. Finally, skill sets of the team will decide which microservice or monolith is the best choice.
Remember: “Don’t even consider microservices unless you have a system that’s too complex to manage as a monolith” (Martin Fowler, 2015)
Advantages of Micro-service
Strong module boundaries: A big software can be divided into good module boundaries. These modules are handled by many small teams, maybe from different locations. The teams are able to work independently with less communication required in comparison with a large team. Decentralized Data Management is also a good point of microservice. Each module has its own database and other services have to call service’s API to get information, which prevents us from getting messy data in large system. In addition, I hear that it is possible to do with Continuous Delivery because developers become familiar easily with a project which requires high productivity and frequent delivery. This idea needs to be considered carefully with reasonable researches and maybe not true for outsourcing.
Independent deployment: Microservice is a distributed deployment basing on decoupling module boundaries, which takes advantages of a distributed system such as reduced risk of single-point failure (Reliability), expandability, and scalability (*). For example, if developers want to maintain or update some existing services, but something goes wrong. The whole system does not collapse entirely. Perhaps, the deploy independently is the most important characteristic microservices.
Technology Diversity: Microservices can be written in different programing languages, used different libraries, even different databases, and deployed in different environments. For instance, from back-end side, a module can used Java Spring, Hibernate and Neo4j – graph database and deployed in Linux environment to provide APIs resources, other modules maybe use .NET technologies and Postgres database. These modules work closely together as a single provider. Web Front-end technologies like Node, Angular JS or mobile apps simply call the services via gateway endpoint regardless of back-end technologies used.
However, everything has both sides. Micro-services also bring some drawbacks
Distribution: Performance is a first consideration. The key explanation for this is nested services (like nested classes) where a service calls a lot of services, each service still remotes many other services. This leads to very high time-consumption for response times, so-called horrible latency characteristics. The second factor is asynchronous and synchronous issues. This topic is very tricky for developers to get right and implement it. Suppose that you do not put your books in one shelf instead of many places in your room. Whenever you want to find a book, you have to know where it could be and how much time to see your book.
Eventual Consistency: This causes potentially many intermittent bugs which are quite hard to replicate and resolve. For example, a service used ten other services for updating a trading. Then, the first of eight services updated trading successfully, but the service 9th was fail. It is clear that the executed services cannot roll back as transaction actions of a database management system. In worse cases, multi-update resources, and distributed transactions e.g in banking, stock brokers where easily get conflict results in inconsistent data issues.
Operation complexity: Require increase cost of management and monitor of thousands of services; use sufficient resources, and effective tools. As far as I can remember, my task updated logic business of an existing service where micro-services implemented as spider’s web without well-documented details. It takes much time for training and learning, especially for new team members. Integration testing for dozens of services is also significant challenges to make sure all services work properly.
I stole ideas from Micro-service Trade-Offs, and The Principles of Microservices
Embrace Autonomy to Optimize Performance. A big thank to Martin Fowler, Sam Newman.
- Microservice Trade-Offs, Martin Fowler. Retrieved 07 Nov, 2016 from http://www.martinfowler.com/articles/microservice-trade-offs.html#ops
- Multi-tenancy vs Single Tenancy, Sam Newman. Retrieved 07 Nov, 2016 from
- Optimistic Offline Lock, Martin Fowler, Retrieved 07 Nov, 2016 from
- Microservice Premium, Martin Fowler Retrieved 07 Nov, 2016 from
- IntegrationDatabase, Martin Flower. Retrieved 07 Nov, 2016 from
- Distributed System – Theory. Side show. Retrieved 07 Nov, 2016 from http://web.info.uvt.ro/~petcu/distrib/SD1.pdf (*)