[What are Microservices? | IBM]
To prepare for my capstone, I decided to read up on microservices. This article is mainly just describing what they are, but it also mentions some common pitfalls towards the end. I was also interested in exploring criticisms of microservice architecture, but I want to keep the scope of this post short. However, I think it’s a pretty straightforward trade-off, which I will mention in a moment.
Microservice architecture is an architectural approach in which one application is composed of smaller components called services. This is distinct from other forms of software encapsulation because services essentially function as distinct programs, potentially operating on different programming languages, frameworks, and with their own databases. Rather than messages within the same process, services communicate over a network with a shared API.
Services can be updated individually without knowledge of the overall application. Different programming languages can be used for different components to better suit the needs of those components. Individual services can be scaled when necessary, rather than the whole application. This method also demonstrates the quality of “loose coupling,” which is lowering the amount of of dependencies between components as much as possible. The risk of a change to one service introducing problems in other services is still present, but minimized.
In general, this kind of technique basically combats complexity by adding complexity. It isn’t applicable to every situation. It should not be chosen if the overhead of designing the system is significantly more than the overhead of not doing so, which will often be the case for small problems.
For the purpose of the LibreFoodPantry project, microservice architecture is useful. In another scenario, such as one where high performance is a major concern, it may be a problem. If different services are busy sending messages back and forth, it can waste a lot of processor cycles on providing flexibility that isn’t really necessary.
Microservice architecture introduces complexity in communicating between all the services. Different tech stacks being used between different services raises the amount of general knowledge a person needs to be able to understand the whole application.
All this being said, I’m actually looking forward to working on a project using this architecture. The only large project I’ve worked on before was the backend for a school website, which was using a more monolithic approach. We were locked in to one specific language, and what we were doing was often a little inscrutable (although this may be in part because I was a junior in high school). I think that microservice architecture allows for more flexibility in low-level decision making, which will make using it in practice more engaging.
From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.