Microservices are here to stay!!

Introduction

Microservices is the new IT buzzword. IT Consulting firms, Software Product Vendors are competing fiercely to grab their share of business by publish 'ground-breaking' white papers (like they always do)!! CIOs, CTOs are excited (and compelled by their bosses) to implement microservice based solutions.

This article attempts to clear the hype around Microservices. I literally had my 9-year-old proof-read the next section. Other than the terminology, she claims to have understood it !!

So what is a microservice?

It accepts pre-defined data (input), processes that data and spits out another set of pre-defined data(output). 

A microservice is an independent ‘block’ of activity performed by a system.   

Behaviourally, this is not a new concept. A 'function/procedure' in a software program, an 'object' in Object-oriented programming or a 'service' in an Service Oriented Architecture (SOA) are based on exactly the same concept as that of a microservice.

How are they different from each other

Function & Object-Orientation

'Function/Procedure/Object' are 'blocks' of code that perform a specific activity intended by the designer. Typically, they reside in the same physical environment as the main software program. Let us take the case of a wooden race car. You cannot change the shape or basic capability of the car unless you create a new one. At most, you can change features such as the helmet, wheels, colour, number etc if the design permits. In case something breaks, or you would like to change a feature, you may have to replace the car. Same is the case with 'function/procedure/object' in a software program. They are like the features of the wooden race car. Their ability to work independently of the main body of code depends on designer's skill in writing the code. You may be able to easily change the 'function/procedure/ object', if it is architected really well. Otherwise, it needs wholesale changes to the main program.

SOA

SOA entered the scene with a true revolutionary streak. It promised to physically de-couple a 'function/object' and allow changes to it independent of the main program.

SOA’s plug and play potential neatly coincided with the rising wave of Multi-Channel/e-Commerce wave around 2005-2007. There was a compelling business case in the form of common re-usable ‘services' (for activities such as 'stock check', 'payment', 'order confirmation') to be simply plugged in systems supporting store, online and call centre channels. And this was projected to bring in a 200% decrease in IT costs. Obviously, now IT execs wanted to implement SOA based solutions.

However, some of these services contained application integration elements. As a result, vendors of the unsuccessful Enterprise Application Integration (EAI) wave immediately switched to SOA.

Previously failed EAI products were re-packaged as Enterprise Service Bus (ESB) to enable SOA. The ‘re-usable service’ concept was transformed into ‘re-usable integration’ concept in no time.

Thus, the ESB industry was born. Each ESB implementation sucked in significant resources to install hardware, software and 'configure' numerous components to make it work. This was similar to building a shiny new toy race car 50 different components. Its gives a great sense of achievement of having 'built' something configurable but one component goes wrong and the car stops working.

Inevitably, ESB-based SOA implementations starting competing with Core Business applications for IT budgets

IT Consulting firms loved it. SOA Product vendors were delighted. However, organisations gradually lost sight of SOA objectives. ESB was just one of the many product implementations for them!!

Microservices

Microservice is SOA without the heavy baggage of ESB implementation. It consists of discrete building blocks of features configured to deliver solutions for varied business needs. And these discrete building blocks are available on-demand in serverless cloud-computing facilities. Organisations can implement independent 'blocks' of code without expensive and long-drawn hardware and software implementations. For example, AWS toolkit of Kinesis, Lambda with the right connectors and data storage can spin up microservices at a fractional cost in vastly compressed timescales.

‘Pay-as-you-go' serverless cloud computing enables organisations to try-test-optimise solutions in fast and cost-effective way. Microservices provide IT teams the capability to ‘fail fast and small’ without catastrophic impacts

Gone are the days with multi-year, multi-million dollar implementation plans for ERP-type implementations. Organisations can conceptualise, design, build and implement ‘blocks’ of solutions in weeks. With a clear direction from stakeholders, Microservices can deliver considerable tangible value to the Business in a genuinely ‘agile’ manner.

'How not to Fail' Tips

Start Small with a tangible deliverable

Start with small but real projects with tangible benefits that can be immediately understood by stakeholders. Such 'low-hanging fruit' projects help establish credibility of microservice-based solutions. Business teams like tangible things because that’s how they run the business.

Work with the Business 

For 'Big-Idea' projects, approach Business Teams with Straw-man solutions, instead of with a blank piece of paper. Straw-man solutions have a great ability to sow seeds of big ideas in fertile Business minds. Work like ‘consultants’ who learn from the client and present it back to the same client in a compelling manner.

Speak with the Business in their language and not in microservice language.

By doing this, they will understand your messages and relate to your suggestions.

Aim for 'Quantified' Benefits

As much as possible, quantify benefits. Benefits can be with cost-driven or revenue-driven.

Cost-driven quantification is relatively straight-forward. Typical examples include automation of manually-intensive processes resulting in decrease in cost of output.

Revenue-driven quantification can be a bit tricky. In this case, the Financial Payback models need to be complemented by human judgment based on experience. A case in point would be 'build-vs-buy decisions for new solutions', 'introducing new trading channels' and so on.

Avoid falling into the trap to look ‘cool’ within the organisation and in the industry when quantified benefits do not stack up

Address Single Points of Failure in the IT estate

These are the least attractive ones for the Business because of their preventive nature. ‘Don’t fix if it isn’t broken’ is a very convincing argument when multiple projects compete for the same pot of money. However, months of business planning and investment can vaporise within hours when customers cannot buy your products as a result of system failures. For example, system downtime during Black Friday, Christmas, New Product Launches, New Promotional Campaigns etc can have catastrophic effects.

Apply your own filter on ‘google-results’ 

Be pragmatic while using google-results to define your roadmaps. Vendor success stories, white papers, analyst ‘Quadrants’, ‘Waves’ are often written by individuals (with pompous titles) with little or no hands-on experience. In fact, many such reports seem to have standard content templates. The only difference in a new report is introduction of terms related to the latest IT trend. For example, a white paper on SOA form 2007 will work very well if you replace SOA with microservices and publish it in 2018!!

Recognise the small ‘footprint’ syndrome

Because of the inherently small footprint of a microservice, there is a likelihood of losing sight of the big-picture. In such cases, microservice proliferation the across the IT estate can create an irreversible stream of increasing costs. Always look out for opportunities to re-factor already implemented microservices and keep overall costs in control.

End Notes

Hope this article helped demystify the fog (at least some of it!!) around microservices. Feel free to provide your feedback and/or contact me for any questions.