

Yes it is an architecture trend, yes it has its fanboys and fangirls… and yes I think it’s awesome!


Microservice architecture just makes so much sense to me, keep things modular, keep things maintainable and keep them simple… do one job and do it well. While this thinking isn’t exactly new in the least, it’s the underlying philosophy of UNIX after all; it is relatively new for web applications.

Development and maintenance cycles for applications become much easier by implementing microservices, and in fact, this approach lends itself to SCRUM as they often fit neatly into user stories either in isolation or groups solving a particular pain point. Likewise, iterative versions of apps become much simpler as fixing existing or integrating new services is very straightforward.

However, it is not all smooth sailing: with ever-increasing numbers of microservices forming the app, inter-service calls over a network increases latency, there is an increased need for load balancing, and then there is the tendency to focus on the size of services leading to too much complexity when often traditional modularisation can be more efficient in some respects. Testing also becomes an issue, unit testing is par for the course, but integration testing (data layer, service layer and GUI) is also vital to ensure full compatibility and to minimise bottlenecks, which can become a cumbersome process when compared to traditional monolithic applications.

Overall the handy rule of thumb with regards to microservices is to make them as small and lightweight as you can while making sure they are as large as they need to be in order to provide a reliable and efficient service.

It’s also worth noting that a key reason I like microservice architecture is that it allows you to write the services in a variety of languages, essentially allowing you to choose the correct tool for the job as opposed to picking the most utilitarian one for the general purpose of the application.
