The Age of Microservices

Microservices architecture has provoked heated debates over the past few years. Following in the tracks of cloud-based technologies, microservices edged out a new niche and developed considerably faster than many thought (and a lot slower than many had hoped). But let’s reverse back up a little—traditional architectural solutions, like SOA still get the job done and satisfy the requirements of thousands of corporations worldwide, so why venture into the unknown? Complex microservices, what exactly are they good for? Let’s have a glimpse into their modern history to find out whether or not their advantages outshine their drawbacks.

The history: A brief overview

In the past, custom web development services were constantly affected by the cost and complexity of hardware. Generally, applications were expressly sized to fit the specific hardware. However, even after breaking down the decomposition of applications, they still lacked agility and flexibility and normally consisted of three monolithic tiers – web, business logic and data.

Although such monolithic models satisfied most industry peculiarities, they had serious flaws and drawbacks. Static tiers and extremely long development cycles have almost nullified developers’ attempts to modernize, decompose or somehow alter the apps. Any minor changes, no matter how minor, required new testing and the deployment of a whole new tier. However, these changes could have lead to unexpected consequences in the tier’s functionality, which is why updates and alterations were considerably unwanted guests in these monolithic applications.

The picture changed when microservice based apps came about. As the name would suggest, microservices represent small, independent and loosely coupled modules which build the overall functionality of the app. They can be altered, decomposed and deployed independently, which in turn, gradually enhances their agility, flexibility and scale. Despite the fact that microservices represent a significant, innovative leap within the software development industry, it’s not obvious that this leap is in the right direction. So let’s go along and check out those bright and dark sides.

What’s on the bright side?

Independence and agility. These two prolific features are greatly appreciated both by developers and users. Independent modules can be easily handled separately from other components of the tier, which gradually facilitates the whole process. Additionally, and keeping in mind their impartiality, microservices are isolated from each other’s flaws. In other words, the whole application won’t be hugely affected by the failure of one of its components. Deployment also benefits from the absence of the links between modules – developers are able to fix one microservice at a time. This amount of scalability drastically increases the efficiency of both application development and deployment.

Stack and language choice. Unlike monolithic applications, microservice-based apps provide an opportunity to use different stacks and languages while you work. If you want to try a new stack or find a language that is more suited to a specific task, you don’t need to adjust the whole tier to accommodate those changes. Separate microservices can be altered using unique stacks and languages.

Better teamwork. Microservices are a real catch for the larger and possibly expanding teams. Initially, they are easy enough for any newcomer to understand their functionality and dive in headfirst. Secondly, they are flexible enough to provide independence for any nearshore or otherwise external team. While developing microservice-based apps, the team doesn’t need to work in the same room. The process can be divided into separate parts and completed independently by any one of the individual team members.

What’s on the dark side?

Multiplied modules equal multiplied costs. There’s no avoiding the fact that having the microservice-based application requires additional spending on administration and management. If you consider that your app has a lot more databases and components, the process of controlling, administration and putting it all together can become a formidable cost within your budget.

Deployment is not necessarily that easy and straightforward. It’s true that microservices are designed to facilitate the updating and the deployment of the app, yet it’s not as easy as it  seems. For instance, they may require extensive coordination amongst each block, which is vastly more complex than using a simple testing method as per the monolith app. Additionally, the process of testing is also complicated by the number of modules involved, each of which needs its very own independent testing. All in all, the more components you have… the more work you’ll receive.

It’s not necessarily a “cure-all” method. Whereby architecture of the large code bases in big corporations gets gradually simplified by the use of microservices, small enterprises may not be that lucky. Contrary to popular belief, the smaller your project is, the more complications you’ll receive when choosing microservices over the traditional monolithic base. Yet think twice. Does this modern solution correspond with your projects needs?

Microservices may be a huge step forward for your company

It’s difficult to evaluate whether microservices architecture is the future of app development services or not. It’s evident that this is an innovative and scalable technology but it can be a severe headache for developers. In essence, if your company follows the examples and guidelines of Netflix, eBay or Amazon and uses cloud based technology, then microservices may well be a huge step forward for the development of your company.  However, if your projects are simply not that complex, microservices will be nothing short of a millstone around your neck.