What's Next in IT? Part 1

Micro-Service Architecture

Micro-Service Architecture will finally put an end to complex and massive application systems.  After all the maintenance, patching and myriad engineers hanging changes all over it, there is no mystery as to why nobody understands it.  

Many IT shops are too busy mopping their floors to turn off the water.  They are truly collapsing under the weight of their own technical debt!  They can't keep up with their competition and freshly graduated engineers look away from their hiring departments.

What if we pulled out a blank piece of paper and designed the next generation of software as disposable loosely connected pieces that are superior at performing their role and responsibility for the application?  Get outside the traditional application system and clear your minds.  Think about your car for a moment.  What if you could not replace a failed battery without breaking your car?  That would be stupid, yet most software systems in production today break for such trivial reasons.  It’s called coupling and can be thought of this way.  Suppose the battery in your car has the red and black wires connected permanently and whatever is on the other end of those wires is also welded onto their parts?  The mechanic might have to tell you to buy a new car even if only the battery needed replacing.

This is an example of tightly coupling the parts together so trying to change one thing immediately breaks another.  It’s called collateral damage and is the basis of the game Whack-A-Mole.  You whack one mole only to find two more pop up elsewhere.

Micro-Service Architecture is sort of a weird idea that is actually brilliant in practice.  Rather than a monolithic application of stacks and parts of inter-coupled layers that honestly nobody really understands, we start from simplicity.  Tiny objects that an engineer can totally understand in a few minutes time.  If the consensus is the object is too confusing you throw it away and try again.  Moreover, if after a few months a better object would do the job, you discard the current and plug in the new one.  Whatever object is the best for the job is only a point in time thing.  Even the best object today will be replaced by a better one tomorrow!

This panacea is rooted in the notion of an endpoint producing behavior or data for a consumer.  Note we did not mention programming languages machine types or anything else that will inevitably be superseded by something better. 

If you develop your architecture based on certain obsolescence, you will have a future-proof application where parts can be easily disposed of and replaced by better pieces.

Think about this idea for yourself while I begin producing a sample application of these little Micro-Services Part 2.