Microservices: Right Tool, Right Job
Blog: Software AG Blog - Reality Check
Microservices is a hot new buzzword for integration technology today; essentially it boils down to a type of software architecture where small, independent processes—arising from the web, wearable devices or the Internet of Things—communicate with each other by using application programming interfaces (APIs).
The term microservice, widely believed to have been popularized (if not coined) by Martin Fowler, is increasingly discussed in the digital realm and has come to represent many concepts – not all of which align with the original idea.
As with many new technology buzzwords, microservices has attracted some nay-sayers , hence the pejorative, “microservice-washing.” According to Wikipedia, microservices-washing is derived from whitewashing, “meaning to hide some inconvenient truth with bluster and nonsense.”
But microservices are not nonsense, they should actually be considered as using the right tool for the right job. The notion of a microservice, at its very core, is that each piece of a complex system is discrete, and its business functionality can be broken down into much smaller pieces. Those smaller pieces can be engineered—they can be tested and deployed—independently of trying to cross-coordinate members of a large engineering team.
In this 5-part series of posts entitled “Microservices 101” I will identify and explain what I believe to be foundational elements related to microservices and their practical applications.
Conceptually, a microservice is a portion of a complex application that is a discrete amount of self-contained business functionality, meaning the run-time server, the configuration and the business logic are deployed as a single unit. These units can be developed, tested, deployed, upgraded, retired and so on without having to deploy the entire application at the same time. Additionally, microservices can scale up or out individually as needed.
There are additional benefits that microservices offer. The independence realized by breaking down business functionality into discrete deployment units lends itself very well to the idea of using the right tool for the right job and provides better agility and more flexibility. Developers can choose any programming language, storage technology and framework that solve the problem because each part of the overall system no longer must conform to standards imposed in a “monolithic architecture.”
Microservices are not necessarily just small services; they, in fact, can be rather large depending on the functionality they provide. Even so, they are discrete and self-contained. Next time we’ll look at the IT architecture approach that preceded microservices, called Monolithic Architecture.
The post Microservices: Right Tool, Right Job appeared first on Reality Check.
Leave a Comment
You must be logged in to post a comment.
