Micro-service Architecture : Moving Away From Monolithic

Why did monolithic create problems?

We saw a change in software design patterns from the time when internet had just come into being and every industry from newspapers to banking wanted to be a part of this technological revolution to ramp up their customer base, to now when internet has become a “necessity” rather than “distinction” for your business. Since then, applications have increased from being just a simple form where you can subscribe for a daily newspaper to having millions of people reading digital content online.

With both, increased requirements and demand, it was becoming difficult to scale the applications. For instance, consider an application with say 5 features, 2 of which are high compute features and others may be less resource demanding. Now you can start by designing a monolith code where all features are separated logically but are packaged together and deployed. This scenario works just fine when you start a new product and have small customer base. Managing deployments, versioning, is much easier in such a case and specially works just perfect when you have a small development team.

Fault Tolerance: Now consider scaling this to 1000 times the demand if not million. All of a sudden, you need to make the whole deployment HA. Even if only one of the feature has more resource needs and/or faces a fault, the whole application goes down and poor dev-ops guys get the heat.

Even if only one of the feature has more resource needs and/or faces a fault, the whole application goes down…

Versioning: Lets say you need to upgrade one of the features, the whole application needs to have a version upgrade. This becomes difficult specially for a large agile team where changes are made every now and then and each feature runs at different pace. Even if you maintain separate repositories for these features, the deployment versioning gets extremely complicated.

…upgrade one of the features, the whole application needs to have a version upgrade.

Reuse: Most big companies have some features used across many applications. In such a case, the only option you are left with is to copy the code across these applications and have them deployed separately for each use case.

…copy the code across these applications and have them deployed separately for each use case.

The revenge of Micro-services

These and many more problems led to the introduction of the more flexible, developer friendly architecture of designing applications. Now each application consists of several sub applications (called “micro-services”) and were developed and deployed independently. These micro-services could talk to each other using RPC protocols or Rest Endpoints instead of functional calls as in monolith era, keeping each of them independent and reusable.

It suddenly started making sense that each feature could have different target audience and demand load and needs to be scaled accordingly. Remember the infamous “Uber Account Deletion Scam”? Uber too, like many other, had scaled services based on their loads. Since deleting an account wasn’t considered one of the popular service in the company, it was scaled to handle very low level to requests. Little did they know, that people would create a mass movement to delete their user accounts and their service would crash. (Please, Oh please, use auto-scaling capabilities from your infrastructure!)

Now, even if some of the features went down (happens all the time) for any reason, the application would still be running for the end user with all the other features since every thing is hosted independently. Each feature development can now run at its own pace, keeping yourself backward compatible. If feature X was more popular in Europe than in Eastern countries, I can still scale it differently based on region/usage.

Conclusion

Best way to architect your application? Start by having a monolithic codebase, but make sure you separate it logically either by feature or re-use capability. Each feature can still call other features using functional calls, but there has to be least amount of code dependencies b/w them. When the time comes, and you have large, diverse user base, you need to invest around 10% more time to separate those as micro-services and get ready to cater to your users.

Please share your views on how, why and if using mircroservice architecture is the right thing to do.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s