What is a microservice?
Your thoughts?
A microservice is an application with a very specific purpose. This application does one thing really well. This application communicates with other microservices through well-defined APIs to create the overall solution.
The main advantages of a microservice are...
- scalability - a microservice can be scaled independently of other services in the "solution". For example, let's say you have a blog where users can log in, post, comment, and like other content. Let's say that A BUNCH of users are liking things but not many are commenting on posts. You can scale up the like service without throwing more resources at a comments service. In this way, microservices offer A LOT of flexibility when it comes to scaling.
- maintainability - a microservice is usually a smaller application that does one thing really well. It's managed by a small team and is written in a language the team knows and understands. It can easily be debugged and worked on because it is small in nature. For example, a microservice may read data from one source and write it to another destination. It does one thing and does it really well. If there are issues, it's easy to understand where they are originating and fix the problem with a microservice.
- resilience - a microservice can be brought down and redeployed without effecting the larger solution. Going back to the blog example...if the comment service goes down then the rest of the site is still running. Sure, you can't comment on things while the service is being brought back up but you don't run into problems where the whole site is down because it's a monolithic solution. Also, with container orchestration platforms like kubernetes you can replicate and restart failed services with minimal downtime (if any).
A microservice is small in scope and functionality yet easily scalable. Microservice architecture really points to service oriented architecture where in a collection of services communicate to deliver a solution.
There are pros and cons to microservices...
Pros
- Easy to scale
- Easy to develop
- Easy to release to market
Cons
- Hard to test (end to end)
- Hard to maintain state (resiliency)
- Lots of networking hops
While the world of software engineering has largely moved away from microservice based architecture, there still exists use cases and reasons to use monolithic approach. For example, if your application is in its infant stages then starting with a single application written in a single language is a more 'bootstrapped' approach to getting off the ground. You an always break out your functionality into microservices later down the line when you see what aspects of your application need scaling.
A microservice is a way of building a solution.
A microservice doesn't deliver a solution by itself.
A microservice works with other microservices to deliver a solution.
A microservice can be easily, independently scaled.
A microservice is a smaller code base that is easily maintained.
A microservice offers quick time to market with frequent deploys/rollbacks.
A microservice is not always a good thing...
A microservice can increase testing complexity
A microservice can increase design complexity
A microservice can increase monitoring complexity
A microservice is an independent, small application that communicates with other microservices through well-defined APIs.
While you could technically have a single microservice deployed somewhere that does something super awesome, the more common use case is for microservices to exist as collections as part of a larger "microservice architecture".
A microservice does one thing and does it really well. It's developed and maintained by a small team and is very loosely coupled with the other services it interacts with. In other words, a microservice shouldn't know or care the details behind how other APIs/services it's connecting to are working. It just connects to a black box that is the other services to get / send the information it needs.
A microservice is a small, independently run piece of functionality that can be independently developed, tested, deployed, and scaled.
A microservice is the most abused term in software engineering these days :)
Microservice? Nanoservice? buzz word buzz word :)
Microservice architecture solves the problems experienced with monolithic architecture. So let's start there...
What is 'monolithic'?
Applications are considered monolithic when a single service is responsible for all the processes that collectively make the application. A good example would be a blogging platform where the database (storing user info), user interface (web app users interact with the data), service layer (server which processes requests and interacts with database) are all deployed as one service.
There are several issues with this approach, the first being scalability. Let's say that users are liking lots of posts on your blogging platform but no one is commenting. If you need more processing power you have to deal with the overhead of the rest of the application that doesn't necessarily need the performance boost.
Another issue is agility. It can be harder to work on features when everything lives in the same code base. As the code base grows, developers struggle more and more with both adding and removing features. This leads to situations where deployments are an absolute nightmare. Deployments must be carefully planned and are difficult to roll back.
There is also a problem with resiliency. If one aspect of the application has issues or crashes , it can bring the whole application down with it.
Microservice architecture to the rescue.
So how do you solve these issues of resiliency, agility, and scalability? Microservices...
A microservice is less of a physical thing and more of a concept. While some microservices are super small in their functionality, they can still consume a lot of resources even at the "monolithic" level. For these reasons, it's easier to explain a microservice as a specific task that performs something in complete isolation of other responsibilities for your application.
Microservices typically exist in groups and communicate with each other through well defined APIs. These APIs allow the collection to work as a whole to efficiently deliver the end solution.
Since microservices are so small and specific to one task, they can easily be brought down, redeployed, and easily developed. The cost of error is small and allows for lots of experimentation and ultimately faster time to market (for a particular microservice).
For these reasons, microservice/event based architecture has become very very popular, especially at the enterprise level.