Microservices: Shattering the Monolith
Blog: Software AG Blog - Reality Check
When enterprise IT was emerging from the mainframe-dominance era, developers intentionally built systems in a monolithic way. The result was a system that was about as agile as an oil tanker is easy to turn. Today we examine how microservices, the new, agile and flexible approach to enterprise development, can shatter the monolith.
In the first of this five-part series on microservices, Microservices: Right Tool, Right Job (URL), we identified the basic concept and some of the characteristics that make a microservice different from, well, not a microservice. In this post we’ll explore the monolithic architectural style that preceded microservices – the limitations of which created the need for a new approach.
About 15 years ago, the monolithic approach gave rise to a great divide in the computing industry, between Microsoft® .NET and Java® environments. There were certain kinds of applications and development activities that best suited the Microsoft .NET world, and Java was taking a stronghold on the back-end, high-end enterprise server arena.
The programming models and practices from the past made it convenient for firms to develop applications using standardized tools offered by vendors in a way that made it difficult to avoid the monolithic situation. Also, IT operations had their own challenges and tended to lean towards standardizing on a small set of technologies that they could fund and operate efficiently. It was not uncommon to label an enterprise as an Oracle®, IBM® or Microsoft® “shop” because of this effect. Developers also didn’t have as many choices as they do today.
Depending on the platform they chose, developers would put all the pieces of an application together in a single deployment unit. That discrete unit became known as a monolithic application. All business functionality was contained in one particular packaging format, and it complied with the rules of the platform’s deployment model. This was the famous three-tiered architecture: presentation tier, server tier and storage tier. All of those tiers were implemented in a single implementation. Developers had to write all of that functionality, put it inside something like a Java® Archive (JAR) file, a WAR file or a .NET assembly, and then deploy it as a single unit.
The problem with this monolithic approach was that if any one piece of functionality needed to change, the developer had to make the change, enhancement or fix, and then redeploy the entire contents as a whole. Microservices solved that problem by separating all of the pieces of functionality to run independently. For example, instead of one deployment unit, with microservices there may be 30 deployment units, and each piece can run and be deployed independently.
This makes it possible to change any piece without redeploying the whole application and leads to a basic rule of discrete functionality within microservices—avoid dependencies between microservices.
Using microservices makes shattering the monolith look easy peasy.
Next time we’ll explore the fundamental change that caused the tipping point away from monolithic and toward microservices.
The post Microservices: Shattering the Monolith appeared first on Reality Check.
Leave a Comment
You must be logged in to post a comment.
