Microservices: Should You Consider It?

If you’ve been around in the web development industry, chances are that you’ve heard about microservices architecture and its benefits, such as enabling independent and heterogeneous services to be built by independent teams that can scale differently.

This is the first article of a three-part series that offers some advice that can help you decide whether or not to switch to a microservices architecture. We’ll review the pros and cons of both microservices and monolithic. In the second and third parts of the series, we’ll discuss how to move to a microservices architecture and how to deploy microservices on Amazon Web Services (AWS). 

Microservices in a Nutshell

In a nutshell, microservices is an architecture that proposes to implement applications as a set of small, loosely interconnected services. This means that instead of running a software as a big, single running process, you’ll have several specialized processes that provide services via API (usually on HTTP) or Pub/Sub mechanisms. This is so that they can talk to each other in order to offer different features. If you want to learn more, check out Adrian Cockcroft’s articles and talks.

Microservices vs. Monolithic

Monolithic vs. Microservices

We have defined microservices architecture already, but why was this approach created? The answer is: monolithic issues. In monolithic architecture, the application is conceived as one big artifact, meaning that all the capabilities offered by the application live in the same codebase; and, at running time, the application gets mostly executed within the context of a single, large operating system process. Let’s discuss some of the benefits and drawbacks of both options.  

Benefits of Monolithic Architecture

• For a new project, this approach is easier to pick up, as the codebase in new projects is small. Also, implementing CI/CD pipelines for a monolithic application is way simpler than for a distributed system.
• Monolithic architecture is easier to maintain while the codebase is still small, and making any adjustments or adding new code should not be hard for your team.
• Since all the components are highly coupled, debugging is less complicated—all the transactions or workflows in your application happen within a few processes.
• Keeping data consistency is painless due to the fact that all the application’s artifacts will most likely have access to the same data source. There won’t be any need for syncing data.
• DevOps efforts will be focused on one application only.

Drawbacks of Monolithic Architecture

• Once your business grows, your codebase will increase, meaning that maintaining or adding new features will be more complicated. 
• If any of your modules needs to scale, you will have to scale the whole app. 
• When your codebase gets big, the time needed to boot (i.e., restart the app) will be greater.
• With a big codebase, new developers will spend more time implementing features, as understanding how the application works will be harder. Thus, the delivery will be impacted. 
• There are less opportunities to use the latest software tools, as once you get started with a stack, it’s really hard to change it.

Benefits of Microservices Architecture

If you look at the drawbacks of monolithic, basically, when the project grows, scaling is a painful task — and that is precisely what microservices aims to solve. Some of the benefits of this architecture are:

• By having several independent services, you can scale one of them without touching or updating others.
• You can split your team into more specialized subgroups, so each of them only takes care of a singular component.
• Your team’s workflows and delivery speed will be independent of each other, allowing them to deploy at different periods of time without affecting the global application’s behavior.

Drawbacks of Microservices Architecture

As others have mentioned, microservices is not a silver bullet. It has some disadvantages, such as:

• It introduces more complexity to the infrastructure, as well as to the CI/CD pipelines required for the deployment. Thus, more DevOps time will be required.  
• Teams can get so specialized that they lose sight of the application’s bigger picture. In other words, teams could start behaving as isolated islands.
• It requires more coordination for deployments because of the dependencies between teams and services.
• More efforts for data sync will be required since best practices recommend that every service should have its independent data store. Your application may get data redundancy.
• Debugging and finding errors will be more complex, since many services could be involved for a single transaction. Take a look at the monitoring options for microservices on AWS (CloudWatch, X-Ray, etc).

Click here to go to Part 2 of this series.

As an AWS Advanced Consulting Partner, Media Temple can help you get the most from your AWS cloud. Reach out anytime.