10th module: Going Micro(soft)

The article talks about a general overview on the architectural style known as microservice. While it isn’t exactly new or niche (many of my friends who work in mobile and web development use it), it is a rather interesting change from the usual monolithic services, and I think it points towards a trend that has been going for most of the history of the software industry. I am talking about modularity and our preference for smaller units whether it is for hardware or software elements. One example of this is how companies went from giant IBM supercomputer centers over to servers and then going a bit 

 further distributed systems, among other things.   

The authors talk about one of the so-called disadvantages of the microservice architecture being that changing interfaces or code from one service to another can be a lot more problematic than with a monolithic architecture. I, however, disagree, not so much that it can be quite difficult, but rather, that it is not a fault of the model, rather than the general quality of the design. In larger systems, one can cover up a bad block, interface or module more easily than when every process is dutifully separated.  Not so much in this kind of architecture. 

Another interesting aspect of the article is how the boundaries of each service must be well designed and implemented by using business’ processes. I think this tends to align the development of the system in general to the objectives of the company, creating things that yield a lot more value while minimizing costs and unnecessary modules or features. This notion of module individuality goes so far as to include metrics for each module, with the objective of better optimizations and general evaluation. This may seem a bit extremist at first, but it allows teams to always understand the observed system and its context, providing valuable an efficient data for every member of the team , whether they are new or have been there since the start of the module.