If you work in the world of software, chances are you’ve most likely heard about microservices and the buzz around them. They have become incredibly popular in today’s tech industry, but there tends to be some confusion between them and another buzz word – APIs. So what’s the difference and what’s all the fuss about?
What’s a microservice?
“Microservices architecture is an approach in which a single application is composed of many loosely coupled and independently deployable smaller services.” – IBM
Okay, so what does this mean? In the world of programming, the traditional software architecture of yesteryear has been the monolithic architecture, where the entire application is one centralized code base structured with the 3 common layers – UI, business logic, and data access. Microservices, on the other hand, is a departure from this traditional approach, where instead of one centralized code base that contains absolutely everything, it is broken down into smaller, independent and loosely coupled pieces of software (or services), hence the name.
Further reading: Microservices: Modernizing the Monolithic Legacy
What’s an API?
“API is the acronym for Application Programming Interface, a software intermediary that allows two applications to talk to each other. Each time you use an app like Facebook, send an instant message, or check the weather on your phone, you’re using an API.” – Mulesoft
An API is a set of endpoints that provides functionality to the caller (you as the user or your own software) without knowing how that functionality is implemented. Most modern APIs are RESTful, and there are plenty of public APIs that we can integrate with our own software, such as Google Drive, Twitter and Amazon S3.
API and Microservices fusion
Hopefully, these terms are more distinguishable – essentially, you have an architecture pattern (microservices) and an interface to allow communication between components (API). The way these two work together is that APIs will more than likely form part of a microservice architecture, where each microservice will have its own API, allowing communication between a client and the service and between the services where necessary
So what’s all the fuss about microservices?
Microservices have become increasingly popular, but why is that the case? To understand its rise in popularity, we need to understand some of its key aspects and the advantages that they bring:
- Single responsibility – each microservice is responsible for one thing and one thing only. This will aid in reducing complexity, as it will be a smaller piece of software that will be more maintainable.
- Loose coupling – this means that each microservice is independent of all the others and any changes in one microservice should not affect any of the other microservices.
- Fault isolation – with each microservice being an isolated and independent piece of the application puzzle, if something goes wrong, it will remain isolated to that microservice and will not bring the entire application down.
- Tech flexibility – since each microservice is its own independent piece of software, you can use any technology stack that you and your team deem appropriate.
- Faster deployment – each microservice can be independently managed and deployed when required without waiting for the entire application to be ready like in the case of the monolithic style application.
When do I use them?
Usually, when you have a rather large application and want it to be decentralized and modular to achieve scalability, flexibility and better maintainability. Though the microservice architecture brings many benefits, they can bring some challenges too, therefore choosing the microservice architecture will depend on your requirements and available resources. Careful consideration needs to be given as to whether this is the right path for your application and if you will gain enough value from it.
When you want to allow communication between your software and other systems to provide the functionality to the consumer through a set of secure and reusable commands. There are different types of APIs to suit different requirements. APIs form part of the microservices architecture, but APIs aren’t exclusive to microservices.