The success or failure of Microservices depends on the timely and appropriate implementation of Microservices Governance ahead of adopting a Microservices architecture.

Microservices Governance is an approach or method that sets up best principles, policies, and standards that enable a successful transition to a microservices landscape. It puts in place rules and guidance that allow accountability and effectiveness to be measured, ahead of adopting a microservices architecture.

I have attempted to capture 5 mistakes to avoid in your enterprise, by making use of a robust microservices governance model.

Technology for the sake of it

Adopting a Microservices architecture is a major shift in mindset, organizational culture and team structure.

The fact that Google, Amazon, and Netflix are using a certain technology stack doesn’t necessarily mean it’s a good fit for all.

Successful Microservices implementations follow a DevOps software deployment model. This means that the team who builds it is responsible to run it, maintain it and to scale it when and where necessary.

So, the first thing to be mindful of is that you don’t adopt Microservices only because it’s the latest greatest success story to come out of the tech industry.

Becoming Tool-centric

Another common mistake is becoming overly tool-centric as opposed to considering the end results, as well as, the skills necessary for getting the best out of moving to Microservices.

Yes, tools are important. But remember, tools are a means to get to an end. In moving to a Microservices architecture, keep your end-goal in sight.

There are some great tools out there and their appeal can obscure the primary objectives for which an organization began a move to Microservices in the first place

It behooves IT organizations to escape the persistent belief that there’s a magic tool, product or resource that somehow negates the need for most of the work associated with moving to a new architectural style.

It’s difficult to know the costs

Cost is another area of switching to Microservices where underestimation is a common mistake.

Because each Microservice is independently scalable, each service requires its own exclusive infrastructure.

And with Microservices, there are a lot of moving parts, much more than with monoliths. With each service requiring its own environment, the costs soon pile up.

Services need to communicate with each other. Depending on the service design, this can mean a lot of remote calls. This higher volume of remote calls has associated (and expensive) costs in terms of network latency and processing.

Without governing guidelines to regulate cost, microservices expenditure can quickly skyrocket.

Cross-cutting capabilities

Cross-cutting concerns in Microservices are another area where organizations try to reinvent the wheel.

Concerns like logging, health checks, externalized configurations, metrics, and distributed tracing are among the architectural considerations that developers build custom solutions. If not governed, different teams tend to re-invent the wheel with similar solutions. A Service Mesh provides most of these cross-cutting capabilities and can be leveraged as part of governed Microservice architecture.

Besides these generic concerns, there are also technology-specific cross-cutting concerns. Not to mention concerns about the volume of services and technologies in a Microservices topology.

Sharing Data

Perhaps the most obvious mistake to avoid is that organizations usually want to implement their Microservice architecture using their old and trusted relational database.

Challenges can soon emerge if you have several different Microservices updating a single relational database. You run into data currency and consistency issues.

Governing principles on data sharing must be in place well before a microservices architecture is adopted.

There are all kinds of intricate and implicit dependencies between how services share and interpret data.

Because all of the microservices in an application cannot directly update or call on the main database, it’s likely that they ought to have their own database.

Depending on the complexity of the business, each Microservice’s database may have to be designed to solve questions of time delay, network availability, failures, and currency.

And you may even need to design and develop an asynchronous database network because not all services require current, up-to-date data.

Microservices Governance to the rescue

The key to resolving these issues that commonly arise when adopting Microservices architecture is in governance.

You can have governance in place in the form of standards that ensure that all the teams address concerns about cross-cutting capabilities in a uniform way.

Especially because without these standards the organization runs the risk of multiple teams approaching the task of meeting cross-cutting concerns individually. The usual result is an unmitigated mess.

The best policies realize the need for decentralized governance as far as the tools used for each microservice are concerned. These can be determined by the teams and their skillset.

However, for topics related to costs, and potential fit for the organization, although there are no magic solutions, mistakes can be avoided through governance by setting rules and standards before the adoption of Microservices.

Establishing a DevOps practice before transitioning to Microservices is a great approach that helps in determining communication strategies in advance.

It is crucial to establish best practice policies along with clear communication channels where accountability and effectiveness can be measured.

The evolution of Microservices

And just to make things more interesting, Microservices architecture is frequently mistaken for SOA (Service Oriented Architecture). This is because Microservices can be seen as the next generation of evolution from SOA.

Both software development styles may seem similar but actually there are evolved differences in Microservices architecture that aren’t found in SOA - especially in the area of communications and data storage.

SOA uses ESB (Enterprise Service Bus) messaging protocols for communications between components of an application.

Whereas Microservices communication uses lightweight messaging protocols like thrift or REST APIs.

Another major area of difference is that SOA systems share data storage by design, whereas each microservice may have independent data storage.

Not to mention other characteristics of Microservices. Like the fact that each Microservice can be deployed independently and is independently scalable.

MSA needs good governance

With proper governance in place, an organization can reap the benefits of adopting a Microservices architecture instead of changing an ineffective or outmoded application landscape for an even messier one.

Latest Posts

May 29, 2020
Remote working post-COVID-19 crisis – 4 things businesses must do
Remote working may have been enforced due to the prevailing situation for businesses around the world. However, after experiencing it first-hand, many may end up making it a logical choice...
May 22, 2020
Force Majeure and Business Continuity
I have been in the IT industry for 22 years and seen my share of challenging times we had to collectively address as an industry and overcame in due course....
May 18, 2020
7 post-COVID "must-haves" for business continuity planning
The COVID-19 pandemic has brought about a few new ways to think about business continuity planning. The traditional model for BCP was more or less relegated to the backbench because...