Microservice Architecture is a strategy for designing software in which each part of software exists separately from the others in what is called a microservice. These microservices have their own CPU’s, exist in their own runtime environment, and are designed to do one specific job. Microservices communicate with each other through Application Program Interfaces (APIs) to form the whole of the product.
In their blog “What Is Microservice Architecture? Microservices Explained”, Johnathan Johnson and Laura Schiff discuss in detail the difference between Microservice Architecture and Monolith Architecture, a system in which the entire application exists as a single unit, and how Microservice Architecture is implemented and used. Today I want to discuss the pro’s and con’s of this architecture listed in the blog, and how I plan on using it in the future. I selected this post specifically because it goes into detail about the benefits and drawbacks of Microservice Architecture. If you would like to learn more about the specifics of the implementation, please visit the blog post linked above.
There are many pro’s to using microservices. The main reason it is implemented is because it promotes feature independence. This feature independence has many benefits, such as developer independence, isolation, resilience, and scalability. Personally I think that developer independence is the most beneficial since developers will become very competent with their microservice and will be experts at their specific job.
When a microservice wants to interact with another it makes a call to that service’s API. Since microservices exist in their own runtime environment they will continue to function even if that API call is not executed. This means that if a part of an application goes down the rest of the program continues to run, albeit at a loss of functionality. In my opinion this is the one of the best reasons to use microservices since it makes applications very resilient.
The final pro I would like to discuss is scalability. Since each service has its own dedicated CPU, its usage can be scaled to meet demand. I think this is a great byproduct of microservices, but do not believe this should be the main reason for using them.
The issues related to microservices are real, but manageable. Microservice Architecture adds complexity to a project, but this can be mitigated with training. Microservices also cost more since they use more processing power and require experienced engineers, but I believe the benefits are worth the cost. Finally microservices adds a security risk since each microservice can be attacked individually. Given an experienced team of engineers and good oversight, this risk can be lessened.
In conclusion, I believe Microservice Architecture to be a very good design choice and plan on using it in my future work. Reading the blog post was worth the few minutes it took, and I can say that I understand microservices much better now than I had before. The benefits far outweigh the risks and I can imagine many employers would already be using this architecture.
From the blog CS@Worcester – Ryan Blog by rtrembley and used with permission of the author. All other rights reserved by the author.