Businesses are always in a state of flux with ever-changing demands happening at a relatively fast pace. This is why microservices are becoming really popular. This application architecture model makes use of independently usable and deployable services that serve just one purpose. In order to build your application, you would just need to deploy these single purpose suites or microservices.
To explain it more clearly, you would need to go back to design concepts such as:
- Decomposition – which encourages you to separate concerns and reuse
- Shared libraries
- Components, which paves the way for process isolation or being able to host a particular component within its own process space
- Service oriented architecture, or using services rather than components.
Microservices is like SOA, only that you are using small services that have one single focus. In SOA, microservices are filed under single responsibility, and it involves lightweight and small protocols. Each service should run its own process and communicates with other services via HTTP or other similarly lightweight protocols.
Some common examples of micro services are user profiles, payment gateways, shopping carts, purchase order systems, inventory processing, caches, and queues.
What are the advantages of using microservices?
- Continuous delivery is easier.
- You have a greater degree of control when it comes to scalability.
- You retain a relationship with the product.
- You can get the best technology for your every need.
- You can add to or improve on the product you have.
Monolithic vs. Microservices
In the old days, applications have three distinct tiers:
- the user interface,
- the business logic, and
- the data tiers.
For instance, a shopping Web site is the user interface where customers make requests. The business logic tier holds the account details, products, inventory, order processing, and promotion, while the data layer holds the database where all the data is stored. If you change anything, even minor revisions, to a tier, you would have to test and deploy the entire tier. And in case these three tiers are tightly integrated, you might need to re-test and re-deploy everything in order to make one simple change.
This means that every change, no matter how small, has the potential to screw everything up, making IT and businesses resistant to changes and innovations.
With micro services, all that tiering and coupling between tiers takes a back seat. The whole system makes use of independent components and these individual components will work together to your end.
Continuing the shopping Web site example, when used in a microservices framework, there are no tiers. The shopping Web site, API gateway, internal support Web site, accounts, products, orders, inventory, and promotion are all separate micro services and each one is able to communicate directly with the others.
A change you want to make on any microservice would not affect the others, making your application more agile, which is one of the key benefits of working with microservices.
Other benefits are:
- Autonomous components that can work on their own.
- Single responsibility. It can seamlessly work together and are not tightly coupled.
- Microservices are not tied to a single platform, programming language, or technology. You can have one service written in C+ and another in HTML, and they will be able to work together just fine.
- Microservices are written, developed, deployed, patched, and updated independently.
- You can change or scale each microservice without affecting other microservices.
More than that, it allow you to develop and integrate continuously, making it possible to introduce new features to your applications at a much faster rate. No need to re-test and re-deploy everything, just the microservice you want to change. Maintaining different microservices is also much simpler than traditional applications.
Lastly, there is the expertise of your IT team. If you are developing the application in house, using microservices actually helps by letting your IT team use the programming language and technology that they are most familiar with, making coding and programming a whole lot faster because there is less of a learning curve involved.
A real life company using microservices
Movio Media is a Web based application that uses around twenty microservices. Each of these microservices runs multiple instances while at work. They communicate using JSON over HTTP and can be executed using load-balanced routers. The routers dispatch the requests to the right docker container on the host.
The company behind Movio Media found this system of microservices a whole lot simpler for their purposes.
What makes microservices better than a traditional system?
An approach involving micro services allows you to be more agile, and being able to introduce changes and improvements faster.
What’s more, the traditional approach to creating applications would require you to clone the whole app when you are scaling up. You would need to copy the entire app on any number of multiple virtual machines, servers, or containers. Not so with microservices, where you only deploy the needed microservice across different servers, virtual machines, or containers.
The traditional approach requires you to have a single central database where all services within your application would get the data. It may seem like this is a much simpler approach that having several microservices have their own set of data storage, but in reality, you will be stuck with really large tables that will be used by different services. This setup is more complex than having separate databases for each microservice you use. It might also slow down performance.
Stateless vs. Stateful Microservices
There are microservices that have non-existing or external states. The database used for these microservices are external and relational such as NoSQL or SQL Server.
When it comes to load balancing, stateless might prove to be much easier to implement than stateful ones. This is because it resembles traditional patterns.
The downside to stateless microservices is that they may be slower and have many moving pieces such as more queues and caches.
This does not happen with stateful micro services, which you can use for gaming back ends, database as a service, and data processing scenarios. Stateful microservices also allow for faster access.
Photo courtesy of Ke Dickinson (Flickr).
