Is microservices architecture better than monolithic architecture?

Microservices architecture has only been around for less than ten years, but we at Blocshop think – and sure, we’re a little biased 😉 – that microservices completely knock this question out of the park. Monoliths had their time, but they’re unquestionably unable to compete with microservices – and that’s why companies like Netflix, Twitter, Uber, and other giants are turning to microservices. And why we’re getting more and more clients coming to us and asking for a conversion of part or all of their aging monolithic systems.

What are the big differences between microservices and monolithic?

If you’ve got a monolith, you’ve got a big, lumbering beast of an application. Your developers will simultaneously work on the same codebase and need to coordinate all changes and deployment. Any bottlenecks or failures have the potential to bring the whole beast to its knees. Over time, it will become increasingly complex and difficult to maintain. New developers will struggle to understand how it all works. Your application will grow stale as it ages and new technology can’t be integrated.

With microservices, you have a bustling hive of separated services communicating using simple commands. Each microservice focuses on doing a single task well and the application emerges from their cooperation. You have small, lean teams that can deploy independently, and you can keep up to date with new ideas and practices because each microservice can be redesigned as needed, without affecting the rest of the application.

Why go with microservices?

If you want your application to be faster and easier to maintain, you need to make the switch to microservices. If you want smaller, more focused teams that can operate independently, you need microservices. Here are just some of the ways in which microservices will transform your business:

· Scalability: Grow as you need to. With microservices, you can scale up parts of your application without worrying about what happens elsewhere. Maybe part of your business hasn’t developed as rapidly as another part. Scale up what you need to and don’t touch the rest.

· Flexible and efficient: Want to try a new technology or programming language? That’s not a problem when your microservices don’t depend on each other. Try it out and see what happens when you roll it out. You don’t need to reengineer anything in the rest of the application.

· Maintenance and debugging: Each microservice consists of a small codebase that can be cut off from the rest of the application in the event of failure. Debugging is faster and the code can be kept tight and tidy.

· Deployment: Smaller teams that don’t need to coordinate their development means that you get faster and more robust deployment. Features and fixes get to your users as soon as they’re ready.

Blocshop’s step-by-step guide to converting from monolith to microservices

So you’ve got a monolith, but you want microservices. Where should you start? Our quick-start guide will highlight the milestones you can expect on the path to modernizing your application.

1. Carve out the simple stuff

Even if your goal is to shrink your monolith until it finally disappears and its functionality is replaced by microservices, it makes sense to start small. Identify parts of the application that can be easily carved out and built as a microservice. Not only will this provide you with some of the immediate benefits of microservices in that module, but you’ll also gain valuable experience in the planning and implementation of microservices. You’ll be able to establish a workflow for turning other parts of the monolith into services.

The first services you build might be those which are already relatively well decoupled from the monolith and won’t affect any front-end or user-facing elements. It could even be a good idea to avoid services that require a data store of any kind, so you don’t need to deal with that side of the process – yet.

2. Reduce the dependencies of the new services

You can already begin to reap the rewards of your new microservices, but only if you try to minimize their dependency on the monolith. This is easier to do if you were careful about choosing modules that could be effectively carved out in the first step. Once you have microservices that no longer depend on the monolith, they can enjoy their own release cycle, faster speeds, and keep focusing on the service they were designed to carry out.

3. Break it down vertically

At this point, you can start to look at the verticals of your monolith. You want to minimize dependencies between your microservices and one way of doing that is to have teams that completely own their microservice on every layer. Instead of team members working on a range of different services, they build and own the whole vertical, from front-end to data storage. Which brings us to step 4.

4. Break up data storage

Keeping a shared central database is going to undermine your move to microservices, so you need to break it up. Each microservice should have the freedom to determine its own approach to data storage and not have to worry about what other services are accessing and changing it. You might find that data replication is the best way to do this. Once you liberate the data, you should start to see real speed and efficiency boosts.

5. Decouple important and constantly changing elements

Even if your goal is to eliminate the monolith, there’s a cost-benefit analysis to be made. Some parts of the monolith should be replaced earlier than others, especially if they already need to be updated more frequently, or if they’re vital to the business. Identify what has changed the most and consider your business objectives when working out what capabilities need to be converted first.

6. Identify domain boundaries

Domain-driven design is at the heart of microservices and this is where it will save you from going too far with microservices. As you continue to carve out and decouple capabilities from the monolith, consider each step from the point of view of the domain that governs it. Remember that microservices that are too micro can have their own management challenges, so don’t break up a service in a single domain until your monolith is already starting to fade into the background.

7. Continue to evolve

You may never completely see that dream of the monolith dissolving into a plethora of fast, efficient microservices, or at least it may take you a lot longer than you expect. As with much of development, the process is iterative and incremental. Your application will evolve towards its final state, with each microservice serving as a step in that evolutionary process and with your teams learning more and your application becoming more effective with every step.

How Blocshop can make microservices work for you

Blocshop has been breaking monoliths into microservices since the software architectural style got its name in 2012. We know our microservices and we can walk you through the process of deciding how to make them work for you. Contact us today for a project estimate or even if you just need something explained.

Free ebook: From monolith to microservices