Monolithic vs Microservices

by Dan Kelly

on November 28, 2017

A Monolithic, single-codebase approach is the classic way of building web applications. But, this way of doing things is now being (quite literally) broken down and replaced by a new, more manageable and scalable architecture called Microservices.

Choosing the right software architecture is profoundly important for business. The right choice can improve your products, save you money, and even help everyone on your team get along better. Many problems you’ve had for years will improve, and others will simply cease to exist.

Here we’re going to look at the microservices method of software development, giving you a feel for how it works, how it’s different from a monolithic approach, the advantages and benefits, the tradeoffs, and how you can get started.

The Monolithic Way

You can think of a monolithic architecture as the traditional way of doing things. It basically means building an entire application in one codebase consisting of a database, server-side application, and client-side user interface. It’s the most intuitive way of building applications, and until recently by far the most popular.

Now the world is making the shift to scalable, cloud-based applications, and this change is exposing cracks in the monolithic model. Applications can get extremely complex, expensive to scale, slow and painful to deploy, and vulnerable to bugs that drag down the entire system.

Microservices - Breaking things Down

Microservices is the idea of breaking down that big, monolithic application into a collection of smaller, independent applications. For example, a simple ecommerce website might be broken down into:

  • The front-end user interface
  • A user account service
  • A shopping cart service that stores the items currently in the cart
  • An inventory service that checks available items

All of the code for each of these is completely separated, each having their own logic and database. When these individual applications need to communicate or exchange information, they do so through defined methods called APIs (Application Programming Interfaces). E.g. the shopping cart service might want to consult the inventory service to check if an item is available before adding it to the cart.

This approach seems strange at first, but it’s actually an awesome way of doing things with a ton of benefits. It lays the foundation for more maintainable, scalable, and robust web applications that you and your team will love to build.

The Benefits of Microservices

Breaking down an application into independant pieces has a few key benefits:

  • Smaller parts are easier to understand
  • Each microservice can be deployed and scaled independently
  • A fault in one microservice won’t bring the whole application down
  • You can choose the right technology stack for each microservice
  • Teams can work in parallel to get things done faster

The first benefit is that microservices are much smaller and simpler than a larger, monolithic application. This means it’s easier for developers to understand and, more importantly, get right. Microservices are designed around business initiatives, so a team can really focus on perfecting it without worrying too much about other parts of the application.

Having each microservice logically separated from the others means they can be deployed and scaled independently from the others. If your website has a promotion and gets a sudden rush of signups, the front end and the user authorization engine might get hit particularly hard that day. With a microservices architecture, you can scale up just those services rather than the entire application. Scaling horizontally in this way can save you money on expensive on-demand cloud resources.

Another advantage is that a fault or bug in one microservice won’t directly affect other parts of the application. If something does go horribly wrong, that microservice can just bow out gracefully and let all the other parts of the app keep working as normal. Rolling back to an older version is also easier.

Each team also has the luxury of choosing whatever languages and tools they want for their job without affecting anyone else. This goes for hardware too. A microservice that is particularly database intensive can be placed on a system with good access to a database.

Lastly, developers and teams can work in parallel to get changes to production faster. Teams can test and deploy a new version of their microservice on their own schedule. Scaling your development team is as simple as hiring another independent team for a new microservice. Amazon has thousands of teams building microservices. Smaller codebases also mean faster compiles, builds, and deployments.

Add all these together and it’s easy to see why microservices is such a strong trend.

Trade-offs

Of course, as with every method of building software, there are tradeoffs. The big one for microservices is that now you are building a distributed system, which comes with a few challenges:

  • Communication between services can get difficult, especially with unreliable services
  • Writing automated tests and creating consistent test environments for multiple tests is hard
  • There isn’t an easy way to recreate conditions where a bug occurred
  • Communication between the services can slow things down
  • Orchestrating multiple instances of different services requires good use of automation and continuous delivery tools

Another problem you might have is that now all developers are responsible their features, and nobody is safe from a late night support call.

Making the Switch

So is it possible to switch from a monolithic to microservices without starting from scratch? Is it worth it? Big names like Netflix, Amazon, and Twitter have all shifted from monolithic to microservices and have no intention of going back.

Changing architectures can be done in stages. Basically, extracting microservices one-by-one out of your monolithic application until your done. Emerson Loureiro gives a great description here of how his company Gilt made the switch. He calls it “strangling the monolith”.

A good architecture choice can transform your applications and organization for the better. If you’re thinking about switching over, let us help you get started today.

LEARN MORE