This article was first published on Medium. You can take a look at it here
Microservices are becoming a very popular architecture design for application design. But every time someone tries to explain what a microservice is to me, I have the same question: what exactly is a microservice and how is it different than an API (if it even is different)?
Last week I described an API as an interface that allows software applications to communicate with each other. A microservice on the other hand, is a small component of a large application. The API is the interface to expose the functionality in the components (aka microservices). APIs are not microservices and microservices are not the implementation of an API. They are related, but not the same.
But what's the need for microservices, why aren't APIs good enough? Applications tend to grow overtime, becoming monolithic beasts. In these situations, the complexity of the application increases to the point where a single developer cannot fully understand the whole code base. Thus, bug fixes and implementing new features becomes more difficult and time consuming. What's worse is that these new changes may not even be made correctly because of the complexity of the application.
Another problem with monolithic applications is that they are difficult to continuously deploy because you have to deploy the whole application for one change, even if it's a small one. The time it takes to re-deploy and start-up the application cuts into valuable time, thus decreasing productivity. Additionally, these huge applications are not resilient because one bug can bring down the whole application since it is all running in one process.
Microservices solve these problems through the idea that you should break your large application into small, decoupled, independent systems that connect back together to make your application work. The total functionality remains unchanged, but the application has been broken into manageable chunks. Each chunk is a service that can be developed independently by a team focused on that service. This means that the team actually understands the code base! Thus they can write, deploy and test faster, increasing productivity. The team can choose the language they want to write in or the newest technology that they want to use without being held back by the rest of the application.
Another benefit of microservices is that each service can be deployed independently. This feature is beneficial because now development teams can use the hardware that best matches each service's resource requirements instead of having to compromise on the hardware. Independent deployments leads to scalability because each component can be scaled appropriately, enabling efficient use of resources due to changes in demand. Additionally, the microservice architecture is resilient because one component failing will not take down the whole application as the containers are independently deployed.
However, microservices are not the silver bullet to software development architecture. Like all technologies, microservices have their drawbacks as well. Microservices can become very complex due to the distributed system. Integration, deployment, testing and management of the application becomes complicated when there is an increased number of services. For example, making a change across multiple services can be a challenge because of the dependencies between the services. In a monolithic application, you can change the modules, integrate the changes and deploy in one step. Testing is also simpler because you can launch an end-to-end test with minimal effort.
In a microservice architecture however, you have to coordinate the changes between services and plan out the deployment to roll out the changes. To test your change, you have to ensure that all the dependent services are working including the service you made the change in.
Additionally, in a microservice architecture, developers have to implement some type of communication mechanism between the services. This adds overhead to the application increasing the complexity.
To summarize, the microservice architecture enforces modularity which leads to individual services that can be faster to deploy and easier to understand and maintain. As with all technologies, microservices have their disadvantages as outlined above. As a developer/architect, it's important to understand which architecture is best for your project as sometimes a monolithic infrastructure will be the right idea and other times microservices will be the answer.
This is the third post in my "What is" tech blog series. I'll be writing more every week here and on my blog!
Top comments (12)
Great description, I think you hit on all the right concepts. I'll add that there are a ton of situations where monoliths are still the right idea, and it's usually where you should start, regardless of where you want to end up. For all the benefits of microservices that you outlined, there is overhead you probably want to avoid early in a project.
Thanks Ben! You're completely right, microservices add overhead/complexity which is sometimes very unnecessary early on in a project. I've edited my post to reflect the disadvantages of microservices as well!
Good article. I'd like to add that before thinking about microservices, we should first think about basic decoupling. Is your front-end on a separate single page app? Is your database on a separate server? Also, is your existing monolith architecture configured in code (e.g. Puppet, Chef, Terraform)? How's your test coverage? These are the questions we should ask ourselves first before thinking about microservices.
I'd say no project should start as a microservices infrastructure, especially at the beginning you need a very good dev tempo and split your app in microservices almost always increases exponentially the complexity (and coste) of your project. Yes for microservices, but only with a quite big team and a mature app
There no theoretical difference between service over the network and API. Mostly the exchange format used tend to change. But carefully crafted API can be resiliant and backward compatible.
The amount of work to communicate with an API is several order of magnitude easier to code and faster to run. The last point mean that a whole set of programs where performance is a factor may not be able to benefit for some components to be spread over the network.
In particular services spread across farms and network can't afford to be too "chatty". The number of requests must be kept to a reasonable number and not slow down too much the overall process.
API on the contrary can be chatty. Hundred millions of calls literaly can be made in a second and the amount of data exchanged in a second can be in the gigabytes. If it fit the CPU cache, dozens gigabytes.
Services or micro services are tools. As you explained they are not silver bullet. On top of adding yet another level of complexity with exchange format, network errors, making deployment of a new feature spread accross many services much more complex, there are simply not a fit for all problems.
It may be easy to think you can always make smaller lighter services. But when you have already a few thousand ones, a typical cases in many big companies, the best solution to fight complexity isn't necessarilly to make them one or 2 level of magnitude smaller to have one or two level of magnitude more services. It is not easier to manage dozen or hundred thousand services than a few thousands. It may just make your network infrastructure explode and make it nearly impossible to understand how all theses micro services interreact.
Thanks for explaining difference between API and microservice. The detailed explanation about Microservice definitely cleared how Microservice can be a boon for business. Thank you for this small and useful guide for Microservice.
Nice balanced article. And Wahoowa! :)
Thank you for clarifying the difference between micro-services and API! great stuff!
any github links where one can start on developing with this paradigm
Are you able todo a follow up article on when to use which architecture?
Yes of course!
Thank you for sharing such informative content also sharing difference between API and micro services.
digitalinfoways.com/