Is Your Business Ready for Microservice migration?

If you relate to a large business organization, the prime question in your mind after reading the title would be- is microservices the right architecture for our project?

Well, the answer that made me write this post: it could be but are you the right organization for a microservices architecture?

Moving on to why suddenly I have started to talk about ‘Microservices’? Well, it’s better late than never and also everything has its own time to shine. The system we knew is never getting any simpler.

Recently, whilst I was working on one of our business proposals my CEO asked me of what I think about “Microservices”. The answer was pretty straight and short ‘Not So Much!’. I believe most of us reading this writing won’t disagree much on the fact that the term is inherently fuzzy, as a social effect of the increasing popularity of the architecture back in 2014/2015.

I assume the majority of the readers reside in large organization of diverse business industry and software architects in a good number. So, in this post, I summarize few guidelines for an organization to consider before thinking about moving to a microservices architecture. The text is not groundbreaking, nor is it comprehensive, in-fact technology leaders like Martin Fowler, Chirs Richardson, communicate these in almost of all their talks. However, I still see customers being oblivious to this simple truth and jump on the microservices bandwagon only to realize the hard way that they are not ready.

When reading the book “Tao of Microservices” by Richard Rodger, I went through so many conventional definitions that describe Microservice manners. We must accept that we aren’t school children, but professional software developers, and we live in the messy world of grownups. There’s no tidy definition of microservices, and any definition we choose restricts our thinking.

So, what exactly is a Microservices Architecture?

Fundamentally, based on my understanding thus far, it is an architecture where things are small islands of functionality accessible only by well-defined messages. That is the nutshell, at least.

These islands are deployed independently, and they sit atop an underlying messaging infrastructure/platform that abstracts away the complexities of load balancing, service location, etc. This provides you the ability to code simply in your services, and to obtain operational goodies including highly distributed, vertical and horizontal scalability, etc. These are traits that the underlying infrastructure provides (though you must be aware of them in your service coding).

Architects love them as they’re an effective way of separating large and tightly-coupled software monoliths into small, independent, and loosely-coupled services. These individual services should have limited scope, well-defined responsibilities and be entitled to their own data model.

This set of characteristics enforce modularity and responsibility segregation, qualities that increase the autonomy of individual development teams, as they’ll be working on tasks with well-defined borders, decoupling dependencies and reducing overlapping with other teams’ work. This kind of autonomy allows dev teams to choose the tools that best suit their needs for each problem in hands. DevOps teams should also love this approach as microservices should be easy to deploy and run in they’re own containers.

I should also mention the benefits in scalability and fault tolerance —microservices running on isolated processes are easier to scale during peaks of usage by just launching new instances of the services; the system as a whole becomes more resilient, as the single points of failure decrease: if a specific service becomes degraded or fails, the others will be able to carry on their work independently.

Symptoms of an anti-progressive Microservice organization:

Sorry for the harsh term anti-progressive but I think it’s important for companies to realize the factors which are not letting them move towards a microservices architecture. Let’s start with discussing the symptoms of organizations that may not be ready to make progress to a microservices world as yet. These symptoms highlight the behavior and culture of an organization and how it can impact their decision or move towards a microservices paradigm. While these have nothing to do with the technical aspects of a solution, these factors significantly contribute to the delays that may occur when developing a microservices type solution within these organizations:

Company profile:

The first symptom can be fairly obvious, it can be evaluated from the company profile and business domain whether a company would move to adopt a newer paradigm quickly. For example, a 50-year global organization with an average employee force of 10+ years retention will have much bigger challenges to adopting a new technology option as compared to a local mid-size company. Additionally, domains like manufacturing, health care incorporate various legal and compliance norms which can make decision and approval processes slow.

Who’s the boss:

In my experience, a dynamic C-Exec driving the change and adoption strategy is always more influential that a hierarchical board or middle-level managers. Wait, what has this to do with MicroServices? Let’s take an example: The CEO of a company initiated using a chat platform for company-wide communication and encouraged its adoption to make it a success. A Developer from the IT team who was doing his personal evaluation posted an idea about a cool feature in Docker that can simplify multi-stage deployment and how it can save the project team time. The Developer Head saw the post and started a small team to see value in the idea, and if can be re-used, that led the incubation of a team to validate the concept, and they realized some instant saving for newer projects. The structure and organization of a company significantly influence the choices and hence the ability to transform into a microservices favorable organization.

Product life-cycle:

Any existing product company is always seeking improvements and efficiencies however the type of industry they work in can influence the culture the teams drive regarding releases and deployments. In a Car Manufacturing plant, a typical release cycle was 1-2 year(s) including a 6-month assembly line testing. It works well for equipment, hardware perspective but, because of the culture, the IT team also followed the same model, so the software release cycles were also aligned with model releases. Now, one of the tenants of a microservices architecture is to release stuff fast and engage a continuous learning cycle. An environment, where the versions take 1-2 years will take more time to adopt a more frequent release cycle with Continuous Integration schedule.

Risk takers vs. Risk Averse:

Does the word Cloud scare the company CIO? Does your company wait till the next-next version of an OS is released before the deploy a new update? Are you still working on 2003 version of Microsoft Word? These are all signs that the organization is averse towards taking up new technologies and may not be ready for a microservices paradigm that allows developers to embrace new technologies and (if implemented correctly) allow complete technology stack changes without having any downtime to existing services.

Divided we fall:

Teams are such an important aspect of a MicroServices based culture that they need to be onboard to have a “solution” strategy and not a single team or owner strategy towards MicroServices(s).

The “Wannabe Syndrome”:

In a recent interaction, a hyperactive CIO called us to discuss their next big project that can leverage microservices since he heard that companies like Google, Microsoft, Amazon, and Netflix are leveraging it. Just because it is in the news, does not mean you can implement it in your environment. Depending on the above-discussed factors, it may take a lot of process change before we can commit to a real microservices architecture. Proper process planning and a defined roadmap need to be in place to have successful microservices architecture, this may mean changing processes, shuffling teams, hiring and firing people and purchasing new systems and services. Note that the effort may start as a single team effort to prove value. However, there should be appropriate buy-in on implementing the strategy for the “solution.” Having a half-monolith without an upgrade plan is perhaps, even more, worse and time-consuming in the long run than the monolith itself.

Note that none of the above references stereotype or categorize a particular domain or industry as not being aligned with leveraging MicroServices, these are merely personal observations and there will always be exceptions to these.

But seriously, should you really migrate?

Until now, we have identified Microservices and events as patterns that enforce modular, reactive and non-blocking applications; we’ll now discuss ways for events to be stored, queried and broadcasted to the interested services. But maybe it is time to answer the question you must be asking yourself for some time now: Should I really migrate to a microservices and event-sourcing architecture? And the answer is: Well, it depends!

A good rule of thumb to determine if an application will fully benefit from this complex architecture is to look at its target platform — does your app have requirements to run on heterogeneous client-specific platforms that you don’t have control over? Does your system require an old-fashion “next, next, next-type” installer?

If you answered Yes to the questions above, your system probably won’t benefit from the full potential of a microservices architecture as you won’t be able to monitor the platform’s health or to dynamically dimension the resources to cope with the systems’ load. On-Demand spawning of new microservice instances to respond to high traffic peaks will also be unfeasible, as you won’t be in control of the available resources and usability statistics to to do so efficiently.

Here’s another important question: does your app have high performance requirements or will be under thousands of user requests per second during large periods of time?

If this time you answered No, you probably won’t benefit much from asynchronism as you’re probably building traditional synchronous and single-user use cases.

It’s also important to notice that if you’re talking about an application with a large and old code-stack that wasn’t built around a solid and modular architecture enforcing clear separation of functional responsibilities, relying on generic APIs for internal communication, it’ll probably be more effective for you and your team to rebuild it from scratch instead of investing a lot of time breaking it apart and changing its internal flows of communication. It’s important to make a cold and impartial judgment on whether your system is worth making the move or not, as the migration process will certainly cost you a lot of time and resources.

The monolithic architecture works well for small, simple applications. However, successful applications have a habit of growing. Eventually, the development team ends up in what is known as monolithic hell. All aspects of software development and deployment become painfully slow. The solution is to adopt the microservice architecture, which structures an application as a service, organized around business capabilities. This architecture accelerates software development and enables continuous delivery and deployment of complex software applications.

Microservices Patterns teaches enterprise developers and architects how to build applications with the microservice architecture. Rather than simply advocating for the use the microservices architecture, this clearly-written guide takes a balanced, pragmatic approach. You’ll discover that the microservices architecture is not a silver bullet and has both benefits and drawbacks. Along the way, you’ll learn a pattern language that will enable you to solve the issues that arise when using the microservices architecture. This book also teaches you how to refactor a monolithic application to a microservices architecture.

Migrating a monolith into Microservices

The idea here is to perform an incremental migration, in order for it to be as smooth and painless as possible. Attempting to do it all at once will be a suicide mission— on one hand, no one in its perfect judgement will be happy to deal with a ‘big-bang’ integration that this kind of migration implies, on the other hand, no manager will postpone the features’ roadmap for 2 or 3 months so that the development team can turn the project’s architecture upside down.

The approach I recommend and that have worked well for me, is to avoid rewriting the existing production code, at least until an actual problem is found or a new feature is to be delivered. Try to start building new services around the existing system in a more reactive style of development, only rewriting the old internals if and when needed, not sooner! The image below illustrates this idea, using some facades that emulate the async behavior.

An application even complex one can be designed as a system of independent components, each of which handles a single responsibility. If we consider for a small team without extensive knowledge of the entire system design, individual microservices are still easy to build and maintain. Since microservice applications rely on modern patterns like asynchronous message-based communication, and they can be optimized to work well in cloud and container-centric environments.

Have in mind that a microservices application is a distributed system and distributed systems are intrinsically complex. That being said, don’t expect a migration to microservices and event-sourcing to be an easy task and also don’t expect to get it right after the first attempt. You’ll certainly make mistakes, but I believe they can be greatly reduced if you follow the main guidelines I describe here. By performing an incremental migration; giving room for future improvements; by carefully identifying the main use cases and mapping them to individual services with well-defined borders and responsibility; by pragmatically upgrading the current system’s data-model into an event-driven design backed by generic APIs and, finally, by enforcing reactive behavior, you’ll have a clear plan to guide you throughout the migration process and that will give you confidence not only to proceed but also to proceed without fearing future requirements for your application.

Flying high on microservices!

What, now you tell me not to use microservices!!! …..While microservices have a lot of benefits, they do not come without a cost. New ideas always great but their cost impact analysis should be immediate to understand project impact. This may seem like the old school method of validation but the idea it to vet out something that will work in production at least for a short period and will not require significant re-work or re-engineering when a new version releases. E.g. NodeJS keeps changing, is it really worth keeping up with those changes? – in some cases yes, in other cases maybe not.

It is not a silver-bullet

No Silver Bullet

There is no single development in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.

–Essence and Accident in Software Engineering

Frederick P. Brooks, Jr.
The University of North Carolina at Chapel Hill

That’s the point of the microservices architecture in the first place, if there were a silver bullet, it would be a monolith.

About the author

asma

Asma Swapna is a tech content writer at Brain Station 23 and an active open source enthusiast. She conventionally writes on the fact that interests her most. Asma's recent R&D enlists SDN, RUST lang and corporate behavior.

asma

Asma Swapna is a tech content writer at Brain Station 23 and an active open source enthusiast. She conventionally writes on the fact that interests her most. Asma's recent R&D enlists SDN, RUST lang and corporate behavior.