Microservices vs Monolithic Applications — Why You Should Consider Microservices

What are Microservices and Monolithic Applications

Microservices is a fork of the service oriented architecture(SAO) that enforces the idea of building loosely coupled systems. The whole system is made up of little services that, when brought together, works as an application.

Monolithic applications, on the other hand, can be seen as a single application where the client access code, data layer, and the business logic are combined together to form a single application.

Dive Deeper Into Microservices and Monolithic Applications

The problem:
Microservices aim to solve a problem that arose when larger companies started having thousands of lines of code. This was problematic because making changes to a single line of code required redeploying the whole application.

This led to fewer updates, because the whole process of deploying these changes was very complicated. As a result, some companies only rolled out updates once or twice a year.

Microservices to the rescue

On the other end of the spectrum, the Linux system was getting better and the technology required to build loosely coupled systems was on the verge of being released. This lead to a total reconsideration of how applications are being built.

Why build full software that is highly coupled when we can make it a simple standalone service that solves a single business logic?

Although there have been implementation modules and packages in monolithic applications that abstract functionality and give simple APIs to access those functions, they also rely on other modules for this to work — which brings us back to the issue of highly coupled applications.

The major disadvantage of monolithic applications are

1. No restricted size
2. Longer development time
3. Inaccessible features
4. Fixed technology stack
5. Highly coupled application
6. Failure on one part could break the entire application
7. Scaling usually requires duplication of the entire code base
8. A simple change could result in rebuilding the entire application

Microservices push for splitting larger applications into smaller bits that have

1. High cohesion: Does one thing and does it perfectly — only changes for one reason. (SOLID PRINCIPLE)
2. Autonomous: Services should be independently changeable and deployable.
3. Business Domain Centric: Services should represent a single business function.
4. Resilient: Services should embrace failure and degraded functionality, —meaning there should be a plausible alternative when services fail.
5. Observable: Things like system health, logs, and errors should be monitored.
6. Automated: Testing, deploying, monitoring, and artefact building should be automated, since a full application might contain tens to hundreds of services.

How small is a service:
There is no universally accepted formula for how small your service should be. Services should be within a bounded context that solves a single business logic.

Microservices push you to see your applications as real-life models and build services based on those models eg. adding food to cart (cart service), checking out (check out service), and getting an invoice (invoice service).

Bounded context should be as big as it needs to be in order to fully express its complete ubiquitous language —
Vaughn Vernon, author of Implementing Domain-Driven Design

Just because a service has to be small doesn't mean it shouldn't fulfill the business context.

Microservices Benefits

Using microservices architecture gives you abilities and advantages over the highly coupled monolithic application. With microservices, your services will be:

1. Technologically agnostic: Use the right tools for the job. Monolithic tends to force you to use a particular stack/technology and microservices doesn't.
2. Independent data storage: Makes using the appropriate database for the given feature easy to do.
3. Independently change: Because services are small, replacing the whole system is simple and almost free.
4. Independently deployable: Although microservices are small, they should be deployable without dependencies. That's why enough thought needs to be put into thinking about how to create services that are standalone and autonomous.

Summary

Although I've stated the pros of microservices over monolithic applications and this article may seem biased, I should state that switching to microservices will require a drastic change in the way you develop software. To manage and scale services, high level automation is required, and so is a change in organizational culture and communication.

Organisations which design systems ...are constrained produce designs that are exact copies of their communication structure —
Mel Conway

Most likely, the way Netflix adopts microservices might be different from the way you or your organization chooses to. This is all determined by the communication structure and the problem that needs to be solved.

There is more to the underlying core that makes microservice architecture work. This requires a lot of sophisticated tools. However, don't worry, there are lots of Open Source and enterprise level solutions out there.

The thought process and work put into deciding what processes and tools to use and aligning your teams to certain key values will help improve productivity, organisation, and culture. Embracing change and putting together the whole system can be a pain — which leads to another buzz word, DevOps.

My advice is to start by building a monolithic application and then finding ways to break it into single self-deployable services. If you decide to take the microservices way, I would suggest a book called Building Microservices by Nginx.

This covers detailed topics on organizational culture and tools for managing, automating, deploying, communicating, and monitoring multiple microservices, even across multiple platforms. This book is a great place to begin from when starting or migrating existing application to microservices.

Conclusion

Microservices is not a golden ticket for building highly scalable and available applications. The question you should be asking yourself is: do I need to use the microservices architecture?

I'll be talking more about DevOps and microservices in the future. You can follow me. If you have any information to add, feel free to comment below. Any comments are greatly appreciated.