BlogPosts/“MicroServices” - The Horseless Wagon

Series: MicroServices - Understanding and adopting a business-centric Micro-Services approach to software solution delivery.

“MicroServices” - The Horseless Wagon

Make sure to share and re-tweet this as a way to increase awareness.  When a new idea arrives on the scene, it is important that its prime audience be able to relate to its concepts and have a sense of the value that they will derive from it.  It has to fit into a context that they currently understand or the value proposition may be missed altogether.  Well, MicroServices is not exactly a new idea anymore, but they are also not well understood.  What are they?  Where do they fit? Do I need them?  Is Micro-Services a buzz-word of is it really something different?  This blog series will try to help both business and technical teams to better understand. 

Go back with me for a moment to the mid 1800’s.  Say that we are out for a stroll and someone asks, “Have you heard about the automobile?”  You would probably have no context to pull from for the concept of Auto-Mobile.  Now imagine the question is posed as, “Have you seen that new horseless carriage?” Here, the latter would likely have been more relatable because the context clues were perhaps relevant to current understanding. However, your first thought might have been, “Well what good is that?  It won’t go anywhere.”  The idea is relatable, but (there is always a “But”) the value is not clear if one can't picture how it moves them along. The obvious next question might have been, “So, what makes it move?”  The answer, “Well obviously steam power.”   “What’s that?”  You can see a pattern beginning to emerge.  Suffice it to say, a good name can give some sense of context and approach (what and how).

The term “Horseless Wagon” (or Carriage) was probably the most relatable mental picture to capture the imaginations of an uninitialized public.  The idea would have been very clear.  But, the more important “How” was probably still trapped somewhere in the fog of ideas floating in the minds of the tinkerers.  I imagine that at some point there was a 5000lb prototype and we all know, there was later a viable implementation that could be reproduced.

"The idea needed a name that was flashy and as relatable as “Horseless Wagon” to convey a sense of the future and relative value. Otherwise, the world might quickly respond “Where is the horse?” or “We already have that with SOA"

  • Share:

Such was the case with horseless wagons and such is the case with MicroServices.  The term MicroServices paints a picture that is relatable for those who have delivered software especially using SOA.  It might not be so relevant for business people who are concerned about generating revenue, managing expenses and delivering value to consumers, in an agile way.  Whether business or technically focused, if in general terms you know what a service is, it is not difficult to make the leap to what a Micro-Service is.  Though, its immediate value and its implementation may remain somewhat a mystery.

Flash forward from the 1800s to about 2010, when Service Oriented Architecture (SOA) was becoming old news like crumpets and tea, and Web APIs were rising as the new rage.  A new idea was emerging for delivering capabilities as small, cohesive, autonomous, resilient, business centric, and observable processing engines.  I imagine that a geek was having a morning latte when the loud stroke of genius went pop somewhere deep in the brain’s parietal lobe (hmmm … we can replace Monolithic SOAs forever).  A snappy name was needed because an acronym for a description like small, cohesive, autonomous, resilient, business centric, and observable processing engines (SCARBCOPE), would have set the industry back 10 years.  And truthfully, re-explaining the meaning of 3 letter acronyms (e.g. SOA, ESB, and API) alone can become pretty redundant in meeting after meeting.  Years ago when I was delivering ESB solutions, one CIO kept asking me what the acronym BUS (re: Enterprise Service Bus) stood for.  Imagine my expression.  I should have captured that it in a satirical cartoon.  I think he was joking.  I hope he was joking.

Anyway, the name needed to be flashy and as relatable as “Horseless Wagon” to convey a sense of the future and relative value.  Otherwise, the world might quickly respond “Where is the horse?” or “We already have that with SOA”.  Now keep in mind, I wasn't there.  I am just speculating.

When I first looked at Micros-Services I was getting exercise in the hotel parking lot near where I was consulting. My first though was, “This is an intriguing spin and somewhat of a recast on what we already do”.  The presenters didn’t have a lot of concrete evidence or even a sample implementation of the idea. They did have plenty of hype. What stood out was “Small” and “Autonomous”.  A lot of the other ideas were consistent with what we were already accomplishing with SOA and Enterprise Service Bus (ESB).

"I imagine that a geek was having a morning latte when the loud stroke of genius went pop somewhere deep in the brain’s parietal lobe (hmmm … we can replace Monolithic SOAs forever)."

So, the NEW MicroServices delivery paradigm or style, or architecture, in my opinion is NOT SO NEW.  Small, Cohesive, Autonomous, Resilient, Business Centric, Observable solutions exist today especially in distinct ESB processes.  The technologies to create Micros-Services all exist and are in use today just like horses, steam engines, wagons and wheels existed in the mid 1800’s.   Just like wagons didn’t give up their wheels when they gave up their horses, MicroServices won’t be completely new or devoid of SOA, API or RDBMSs.  In fact, MicroServices will leverage the same base technologies and practices.  MicroServices however are different because, they are intended to be self-contained processing islands with clearly defined interfaces and their own data stores (autonomous).  They are intended to be single focused sets of functionality that can be discovered and be used to compose solutions.  There is the expectation of an ability to synchronize changes with other systems, services and MicroServices.  If you think this sounds like the argument for interfaces and applications hosted in an ESB, you would be pretty well on target because the rationale is very similar and the benefits are nearly the same.  To that end, the problems that you can create for yourself with either, are overlapping. 

Again, the MicroServices distinction is not altogether new and are not a replacement for today’s practices, but instead represent an opportunity for step-wise, business centric refinement and improvement.  There is also a promise of greater agility, but remember that there can be a 3 edged sword as, greater agility with smaller islands of functionality could quickly lead to greater complexity and increased risk.  Sure you can focus enhancements on a smaller set of code, but you are now managing many smaller islands.  At NexusHIE we have a platform that delivers MicroServices so, I have read a lot of the spin regarding MicroServices. The marketing content tends to play down the similarities with ESBs and sometimes ignores many of the responsibilities that still exist for good design and good demand and capacity management.  Even if we are moving in an agile and compartmentalized manner, the responsibilities still exist.

For the medium to large enterprise, the most effective adoption of MicroServices will be led by a precursory change in Demand and Capacity Modeling and Management practices.  These pieces need to evolve ahead of the introduction of Micros Services based delivery models.  If Demand and Capacity Management don’t change with the adoption of MicroServices, I predict that there will be a lot of failed attempts, wasted money, and heads rolling because of disastrous MicroServices projects and unexpected system outages.  If for no other reason, this will happen because the “production maintenance fires of the day” will repeatedly steal away the most capable and talented resources to fight those fires, leaving “WizBang” MicroServices initiatives exposed. 

Rather than to code all Micro services from scratch, another good idea during the adoption phase would be to leverage a platform that allows for configuration and deployment of MicroServices instances into one or more host service containers with the ability to wire up interactions and synchronizations.  Even before MicroServices had a flashy name, our team members and customers were delivering small, cohesive, autonomous, resilient, business centric, and observable processing elements with only the necessary coding, using ConnectMate Engine.  ConnectMate is a delivery platform that includes the ability to deliver and synchronize data between MicroServices and other system components, and provides monitoring out of the box.  Less coding, more delivering, built in monitoring.

I will discuss similarities, pros and cons and interoperation of these ideas as well as the business impact of adoption in future MicroServices blog posts.  For now, my architectural recommendation is, don’t try to replace the cart and the horse.  In other words, think of MicroServices initiatives as small but well-planned, moderately paced, evolutionary steps, to advance current delivery methods.  This is important to fathom because while small entrepreneurial organizations can easily start from scratch and build new MicroServices based end-to-end solutions, large enterprises may very well stick monkey wrenches into the wheels of the wagon, adding unexpected complexity to complexity and un-necessary risk to mission critical business processes (resulting in System Outages).  Like the adoption of XML in the 90’s and SOA in the early 2000’s, this is an evolution, not a revolution.  The compartmentalized nature of the MicroServices paradigm suggest a real opportunity to flip the script and approach first from the business’ perspective. 

Plan your evolution to the Horseless Wagon appropriately and get there faster.  (NexusHIE and ConnectMate = (Win) *(Win)).  More to follow in this Adopting MicroServices Series.

  • Share:
Go Back

Terry Bazemore

Mr. Bazemore is an Information Technology Executive who specialize in Health Care Information Integration, Microsoft Azure Cloud applications, Solution Architecture and Software Engineering.  He is a TOGAF 9 certified Enterprise Architect, a programmer and a software development consultant.  Terry has operated successfully in a number of business and IT roles and capacities. Among them are, Chief Architect, Director of Enterprise Integration and Process Services, Senior Manager of Solution Architecture, Senior Enterprise Architect, Software Engineer, President of a software engineering firm involved in government subcontract work, and IT Consultant.  

Terry enjoys coaching youth basketball and flying (General Aviation), and is an avid Fine Art and Sports Photographer as well as a long time musician.