by Once upon a time in ancient ages, there had been a team of software developers. These developers had had a web application idea. After a lot of meetings, discussions, diagrams and cups of coffee, they had started to build their web application project in monolithic architecture.
They had written a lot of controllers, service api endpoints, DAOs, models, etc. After several months (or years, I don’t know, the books from ancient times are not very clear) they had started to deal with problems that are mostly related with their architecture. Every time:
- Oh my god! Adam, please finish your work as soon as possible and don’t touch the part that I work on.
- I have typed the run command, let’s go to the theatre while the project starts up, I have tickets for a great show.
- Damn it! I am lost in the project. Yes again! Where were the user profile apis that serves to 3th parties, and what were the names.
- Should I apply the changes here, orrr, here? I think not both of them… Rock-paper-scissors?
- Come on! I just finished the deploy 10 minutes ago. I can’t do it again right now, it is so hard. Please Alice don’t push me to do it again!
One day a developer, tired but excited, had been running and shouting: “Eureka! Eureka!” (not naked this time). The developer had found a new solution, a way. The way that provides:
- Easy maintenance and update
- Independently development, deployment and scaling
- Efficient team working and gaining maximum benefits from it
- Autonomous deployment and continuous delivery
The other developers had loved the idea and named it as microservice architecture. Then the developers had started to use this new way and lived happily ever after. (At least until the new architecture and techniques needed or microservices drawbacks came up.)
As we see in the above story (even if half of it is fake). Microservice architecture provides us a bunch of benefits. You can develop and deploy your application with separating into specific parts and functionality via microservice architecture. Each part (each microservice) can be developed independently. Each one has its own database. Each one can be developed with different technologies and can be deployed different platforms.
However we don’t live in a perfect world, everything has positive and negative sides so although the microservice architecture is a nice technique, it has disadvantages and difficulties too. For example:
- Managing and monitoring microservices (maybe you can use Kubernetes): You can independently scale your microservices. However you don’t want to deploy your each microservices on each machines one by one, right (I don’t want).
- Decomposition of the existing monolithic application and/or determining the microservices correctly: Maybe it is the most important issue in microservice architecture. Because you may think that you don’t need X microservice and decide to merge its functionality into another microservice but later you may realize that you really need that microservice independently. And rolling back maybe too difficult.
- Keeping low coupling situation while designing: If your microservices need each other too much to process a request, your application may fail, even it can down. Also most probably, new changes in your application affects a lot of microservices and you may need to deal with the others too.
- Testing the application: If you want to test a functionality in a microservice (you have to) and this functionality depends on another microservice, you may need to wait to test until that required microservice is ready.
Of course the classic monolithic architecture is not an evil thing. It is old but still gold. If your application is not complex or you are a startup and you want to publish your application as soon as possible with a cheap way, it is better to go with monolithic architecture. Because you don’t want to deal with designing, building, managing and deploying each microservice.
Lastly, this is the first part of the article series. We will build a perfect web application with microservice architecture in the next articles.
OK. OK. Not so perfect but I believe that we will learn new things and improve our skills while building it.
See you next part.
