“Any application can be built with multiple microservices. For example, in an e-commerce application, there can be multiple microservices: orders, inventory, dispatch, billing and so on. We should be able to develop, deploy and maintain each of these microservices with minimal dependency on each other.”
As an analogy, think of your mobile bank that offers different services. These include:
- Current accounts
- Savings accounts
- Fixed deposits
- Retirement plans
Each is a stand-alone service with its own product. If one happens to be hacked, you have alternatives. The bank survives.
In short, Microservices, as defined by Sam Newman in his book: Building Microservices, are small, autonomous services that work together.
For the simplest analogy, think of a giant who’s much too massive to move around the factory and nimbly maneuver tasks. He needs a score of helpers with each assigned one discrete slice of his job, so the giant’s work can be achieved faster and more efficiently.
That giant is our traditional monolithic application for software that's built as a single unit. It integrates a client-side user interface, a server side-application, and a database. In other words, it contains all the functions for all the business activities the application performs.
It’s cheaper, easier and needs less manpower to deploy, among other benefits. But if one part malfunctions, the entire system is impacted. On the other hand, when too large, the infrastructure becomes too complex to manage and update.
Repercussions include development delays, poor application performance and crashes that potentially cost companies customers and money.
That’s where microservices hops in.
In Microservices, each engineer concentrates on one particular part of the application, while applications “communicate” with each other, just as individual workers on an assembly-line system do.
To use a business example from Prabath: If the dispatch microservice is down, you can still get the e-commerce application to function. At the same time, to make a code change in the orders microservice, you do not need to change or redeploy the other microservices as you would if they're all in one unit.
Here’s How Microservices Works
The application will want to process the order as well as to update the inventory, so the orders-microservice will talk to the inventory microservice — and to update billing, the orders-microservice will also talk to the billing-microservice.
How do Microservices Communicate With Each Other?
Through application programming interfaces (APIs) that define the kinds of calls or requests that can be made, how to make them, the data formats that should be used, the conventions to follow, and so forth. Most microservice applications also use containers, like Docker or Kubernetes, to store their software.
Microservices is perfect for DevOps, where developers and operations engineers work together seamlessly to produce higher-quality software faster. In this way, Amazon releases new code every 11.7 seconds, while Netflix deploys new code thousands of times per day.
6 Points of Microservices
All microservice applications are:
The size of two pizzas according to Jeff Bezos — making them cozy enough to manage.
They interact through API
Bounded by contexts
Microservices should be independent of each other, bounded by their own differences.
Each should be separately developed and regulated. Each has its own task.
Each has its own power, unlinked from central authority.
Built with automated processes
Each has its own standardized modular blocks of code for individual processes that can be plugged in for a cleaner more efficient build.
According to Prabath: “The key driving force behind microservices is the speed to production. One should be able to introduce a change to a service, test it and instantly deploy it in production. Microservice architecture helps achieve this. Then again a monolithic is not evil — you should pick whether you want to follow microservice architecture or not based on your requirements.”
Why Are People Moving to Microservices?
Benefits that organizations incur from deploying microservices include:
You can add (and move around) building blocks as your business scales.
Better fault isolation
If one microservice fails, the others continue to work
Increased business agility
Since failure of a microservice affects only one particular module, engineers can afford to experiment and “fail fast”.
Simplified debugging and maintenance
Each block can be scanned, improved and changed individually without upsetting the entire system.
Companies can update individual services without needing to insert time and cost to dismantling the entire appreciation.
What Are the Drawbacks of Microservices Applications?
There are always the drawbacks, aren't there? With microservices, these include:
Microservices architectures can be complex
While individual microservices may be easier to understand and manage, the application may end up with more moving parts that could create its own problems.
A microservices approach requires careful planning
Because all the microservices in an application have to harmonize, it takes careful planning to break down all the dependencies.
Multiple microservices may offer bad actors more opportunities
Multiple applications with their conglomeration of operating systems and languages give cybercriminals more “soft targets” to hack.
You may have little control over third-party microservices
Many microservice architectures are associated with external third-parties. These third-parties may change their APIs at any unknown moment, affecting your application.
Proper sizing of microservices is critical and hard to calculate
Microservices have to be sized just so to avoid the issues of monoliths, on the one hand, and the complexities of tiny dependencies, on the other.
Where Do We Go From Here?
According to a 2017 survey by software vendor LeanIx, more companies move to microservices with the years. Companies that have adopted the system include Netflix, Google, and Amazon, among other tech leaders.
In fact, LeanIx found that of the 118 companies it surveyed, those that used microservices deployed new software releases five times faster than those that retained their traditional monolithic applications.
But — and this is important to remember — microservices is not a one-size-fits-all solution.
“Microservices is certainly a great option for your company, but you need to pick whether you want to follow microservices design principles based on your requirements. Microservices architecture brings a lot of flexibility to your system design — but unless you have the right level infrastructure in place, you won't be able to get the full benefit of it,” said Prabath.
“I think we should pick the right architecture for our system based on our requirements,” Prabath concluded.
Of those that didn’t deploy microservices, SoftIx found it was largely because they were ignorant on the topic. Given that Microservices is, currently, all the buzz, we hope this article makes you an exception.
How Can I Learn More about Microservices?
The best way to learn more about Microservices is by understanding its basic concepts and starting to implement them while building your own applications.
Here are some helpful resources to start reading:
(2015, O'Reilly Media, Inc.) for building, managing, and evolving microservice architectures.
GOTO 2014, Microservices
(Video, co-produced: Martin Fowler).
Principles Of Microservices
Microservices Security in Action
(2020, Manning) teaches readers how to secure their microservices applications code and infrastructure.
Microservices for the Enterprise
(2018, Apress) provides a comprehensive understanding of microservices and how to use microservices in real-world scenarios.