In the past few years, microservice architecture has been getting a lot of attention. With the simplicity, scalability, and fault tolerance of microservice architecture, companies are migrating over. Chances of you encountering this software architecture will be high in the future. So, in this post, I want to briefly go over what is microservice architecture and what you can expect as a developer working with it.
What Is Microservice Architecture in a Nutshell
Microservice architecture is an architectural pattern that structures an application as a collection of loosely coupled services that provides business capabilities. Each of these services has well-defined interfaces and operations that are exposed and enclosed and are self-contained by providing a single business capacity. The communication within microservice follows a smart endpoint and dump pipes approach, which means it uses a simple communication protocol like REST (representational state transfer) and the endpoint does some processing when it receives data. Since each of the services is self-contained, they also have their own database and the data is kept consistent with data duplication. One of the big selling points to microservice is that it removes coupling so duplication is preferred over coupling.
Pros of Microservice
Here is a non-exhaustive list of pros of microservice architecture:
- Gives developers the freedom to independently develop and deploy services
- A service can be developed by a small team
- Each service have its own codebase
- Easy integration and automatic deployment
- Simple to understand
- Easy to scale
- If one service is down, the others will continue to work
- Do not need to rebuild the entire application, only the service that change needs to be rebuilt and deployed
Cons of Microservice
Here is a non-exhaustive list of cons of microservice architecture:
- Testing can be complicated since it is distributed
- Additional complexities from mitigating fault tolerance, network latency, dealing with a variety of message formats and load balancing
- Emphasis on duplication might result in duplicated effort
- Additional effort to implement a mechanism of communication between the services
The Software Developer’s Role in a Microservice Architecture
With microservice architecture, each service will likely have a dedicated team. What this means for you as a developer is that you’ll end up in one of these teams. Most of your time will be spent on supporting and improving that service which can lead you to become a domain expert in the particular area that the service encompasses. You’ll also be working with an isolated codebase from another service that is part of the same application. This means you don’t need to be concerned with coupling and it makes your development time easier.
Microservice architecture is still new so the organizations you work for might not have adapted to it yet or they might be in the process of transitioning. In such a situation, you might find yourself stuck working with a monolithic app that is divided up but is still really a monolithic app. This is where it gets complex because now you need to deal with the issues of microservice in addition to a monolithic app. Although I haven’t touched on monolithic app, the one major drawback it has would completely counter what microservice is all about. When one thing fails in a monolithic app, then everything is down.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
To get in touch, follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.
If you’re interested in learning more about microservice architecture, here are some useful resources: