When it is about creating enterprise software, “Loosely Coupling” everything is the big deal. That is one of the reasons which makes Microservice Architecture a good candidate for enterprise systems. It has a direct impact on the cost of development and maintenance.
Imagine a server side web application for transportation which serves various purposes. (i.e. passenger system, payment gateways, booking system, driver system, user activity tracking and so on).One way to implement this application is hosting all features in one giant application made of hundreds of interfaces and classes.
In other words we can create one big API and put it in charge of the whole business. This is evil in so many levels yet I have seen that practice in several businesses (legacy codes and even brand new startups). I can count the cost and talk about extra resources that businesses spend on maintaining a bad designed system. However let me focus on the solution instead.
Some people argue that: when it is all about Minimum Viable Product why should I care about microservice architecture.
This question is wrong. The right question is: Can we implement a MVP via microservices? Yes! You can have your Minimum Viable Product implemented inside a microservice architecture.
The difference between these two approach will be obvious after you had a successful pitch and got the fund you need to implement the final enterprise system.
- In the former approach, you need to throw away the previous code and start over.
- In the microservice architecture you can continue building the enterprise application on top of your MVP.
The microservice pattern is NOT recommended for small businesses. Because it comes with its own challenges regarding CD (Continuous Delivery) and CI (Continuous Integration). In other words tasks like running tests, evaluating use case scenarios on an inter-server environment and deployment are not as easy as old fashion uni-server applications.
For that reason it is highly recommended to apply this architecture only for enterprise systems.
How Microservice Architecture Works?
In a microservice architecture, we break down the application into smaller pieces and create independent APIs for each piece. Then host them on their own VMs (i.e. AWS EC2).
Easy right? NO! Here is where CTOs make the big mistake. Just because you’ve created a couple of instances for your services, it doesn’t turn your application architecture to microservice.
Each service needs its OWN database as well. In other words using a shared database among all services is the common mistake in microservice design.
Simply put, the services are NOT loosely coupled if they are sharing one database. A shared database is an anti-pattern.
Having separate DBs sounds like a lot of work. Imagine all of those query joins to assemble a piece of data which is now scattered all over those databases. But again when it is about counting the cost, maintaining a microservice architecture is far cheaper and easier than one giant API.
To address the complex queries, we can use patterns like: event-driven architecture and CQRS (Command Query Responsibility Segregation). I will talk about them in more details in the following posts.