• By Terry (Coach T) Bazemore
• 03/23/2017

MicroServices? - Buzz Word Alert - Don’t expect to get the same answer twice.

Go ahead, google the word "MicroServices". Chances are you will find many definitions with similarities.  But, it may be hard at first to cut through the many vague assertions, to find common ground, and to gain clear understanding of what MicroServices are.   All you really want to know initially is how MicroServices may benefit you, and how you get there from where you are. Given the current maturity of the concept, it is really no surprise that the definitions are varied.  As with other industry paradigm shifts, there are reasons why the answers are tough to find.  

1) There is a lot of latitude early in the lifecycle of a new idea and this is true with MicroServices.  Even if the principles for an idea are clear, the implementation details are often nebulous in the early phases.  This leaves room initially for wide interpretation. The varied interpretations and descriptions of MicroServices leave a lot of latitude for implementations. 

2) Vendors are motivated to jump on the band wagon as quickly as possible to grab market share.  So, each vendor will put their own spin on what MicroServices are and how they are implemented.  As the practice matures, stronger vendors will often influence, refine and or narrow the landscape. Many times, new vendors with new products will land on the scene with lean implementations.

This is actually very normal when new patterns are discovered and new architectures emerge. And guess what, neither of these scenarios is wrong. 

In this writer’s opinion, the idea of a MicroService is intentionally flexible because the principles should be achievable with a wide array of technologies. What I mean is, MicroServices are not about a specific technology or language.  It is about how we assemble and deploy business functionality using many of the same technologies and practices that we use today.  And no worries because, we do this by applying slightly modified principles that have been enabled by advances in the technology landscape.  What will be different is the way that we assemble and deploy, now composable pieces as autonomous solution components. 

Given your search results, you may have an even bigger question mark floating over your head than before.  But that is perfectly ok. Why you ask?  Well, I believe you are not alone.  Many individual computer programmers and IT teams using MicroServices still have some of the same questions.

Why is there so much BUZZ about MicroServices?

Let's be honest, it is about dollars.  For enterprises, it is about increased market share because you beat the other guy to market.  It is about reducing technical debt and time to value as we transition to this new way of delivering software.  For vendors, it is about winning new customers because your technology can do MicroServices.

Why are MicroServices different?

Here, I will try to do a little compare and contrast to give MicroServices a little more meaning for business users.  To understand MicroServices, let us talk about the predecessor.  We will call it the Full Scale Application (FSA).  Historically, the way that we have built software applications has been to create large programs that encompassed many business functions and services.  These FSAs can start out solving for a few business functions.  Over time, more functions and capabilities get added. Sometimes the long term result is that the code that makes the system work gets messy and the clear lines between business functions begin to blur.  This leads to large systems that are hard to maintain and enhance.  What does this all look like?

 

In the figure above you see a simple, conceptual illustration of a Full Scale Application.  The container has many business functions as well as data services and integration services (e.g. Enterprise Service Bus).  

Imagine a company has a billing application to manage customers and bills.  Early in the application's life, all of the customer business functions are kept together and all of the billing functions were kept together.  Over time, maybe because new programmers are added to the team (who don't understand the original system), or because changes are added in a rush, business functions may become muddled together. The larger the application, the more messy things can become.  This has the potential to make systems more complex for end users.

Some characteristics of the FSA might include:

·       Allows users to access business functions and information

·       Answers questions for other users and systems

·       Shares its information with those who need it

·       Executes and serve many, many business functions

·       Maintains data relevant to many business functions

   

 With a Full Scale Application we would expect to maintain all of the relevant business function in one or more giant containers.

This means that the Business must be evermore present at the IT table. In fact, the notion of the development team (typically programmers, analysts, project managers and testers) must change to include business process subject matter experts.

Full Scale Applications tend to become very large.  In contrast, MicroServices are intended to be very small and more importantly, tightly focused.  As a result, the expectation is that you will have many individual MicroServices to make up the servicing functions of an application.  In this way MicroServices can ultimately serve many end user applications (e.g. Mobile tools, web applications, desktop applications). In a sense, a single MicroServices could in some cases be considered a very tiny Full Scale Application.  More specifically, it could be thought of as a very narrowly focused, nearly single purposed Full Scale Application.  In this case, I use Full Scale to mean that, it encompasses everything it needs to satisfy its objective. I describe it this way because it has to do many of the same things like manage its data, but for a single business focus.  It is then, autonomous. 

So, let’s think of a MicroService as a small and single focused services application that is by nature autonomous.  Its characteristics may include:

·       Answers questions for other systems

·       Shares or synchronizes information changes with dependent systems

·       Serves a single business function or focus 

·       Maintains data relevant to its business function or focus

 

 

What you may notice right off the bat from the image above is that the MicroService has a single business function.  However, as this area matures it is probably safe to say that most MicroServices may encompass multiple business functions that meet the needs of a single business focus.

 For example, a Hospital Patient Registration MicroService might encompass the following functions.

·       Look up Patient Data

·       Collect Patient Demographic Data

·       Register Patient for Outpatient Services

·       Register Patient for Inpatient Services

·       Send Registration Data to Hospital Management System 

 

To the contrary, a Hospital Patient Registration MicroService might NOT encompass the following functions.

·       Send Patient Order to Modality with DICOM Image

·       Retrieve Data from Patient Monitor

·       Convert Order Results to Human Readable MDM Document

 

With MicroServes we would expect to separate out each Business Focus into its own container or application.  We would also expect to develop it and maintain it as a separate entity.  We would expect each MicroService to maintain its own data, and to synchronize data with other systems that depend on it.  This synchronization is a very important and strategic consideration.  In the past, all of the data might have been in a relational repository and managed by referential integrity and transaction processing.  With data now scoped to MicroServices, integrity will be designed and maintained differently.  Development teams maintaining one or more closely related MicroServices may be tightly knit.

The idea is that if we keep the theoretical containers small and focused, maintaining and enhancing them will be easier and less confusing.  In other words, we simplify how we maintain our business functions.  Every time we simplify (ok this will sound redundant), we reduce complexity.  The more we reduce complexity, the more secure our systems become and our systems become easier to maintain.  If our systems become easier to maintain, we have to spend less money on them.  This means we can spend more money making improvements that will help us gain market share.  There, that sums it up, doesn’t it?

What is clear here is, as we evolve into a MicroServices culture, the notion of a business function (which is often hidden today, deep in code) becomes a first class citizen.  This means that the “Business” must be evermore present at the IT table.  In fact, the notion of the development team (typically programmers, analysts, project managers and testers) must change to include business process subject matter experts.  Over the years, this has often not been the case as business intellect was garnered from lengthy requirements documents, and the completeness there of often dictated the success or failure of a Full Scale Application Implementation.

So, look at MicroServices as an opportunity to move toward a more compartmentalized delivery model.  If approached properly, organizations could expect to gain cost savings and agility from the refinements that a MicroServices approach brings.

Next we will begin to break down a MicroService into its component parts.  We will walk through a demo, and we will discuss related principals.  

Cheers, it is a Beautiful Day.