4 tips for deploying microservices successfully

The developer world is currently buzzing about microservices – a new modular approach to building applications. Each independent piece of your business logic is supported by a unique microservice, which is then loosely coupled with other microservices to create a complete system.

There are many great reasons for adopting a microservices architecture over a traditional monolithic single application. Building a microservice is usually fast because it only needs to contain a limited amount of your business logic, while its small size and lightweight protocols make it easier to test, deploy, maintain and update. You can also use the programming language or framework that best solves your specific use case, which you cannot do with a monolithic application.

Monolithic applications are typically hard to maintain and update as changing any part of code can impact everything else. The modular nature of microservices makes managing the overall application easier and you can test and update each component separately without affecting the rest of the application. Microservices also make the entire system more robust and reliable as if one service goes down the rest of the system will still work as expected.

Finally, using microservices makes it easy to break down the creation of any new feature or service into multiple smaller tasks. Even if they are performed on different services, your teams can work on each component simultaneously and bring together the tested versions to create the final application.

• Build new features and update existing apps faster
• Choose the best language or framework for your use case
• Test and deploy a new component without impacting the rest
• Increase resilience of the overall application

While the benefits of microservices are clear, it isn’t always as obvious how to go about putting the idea into practice. The following four tips will help your team start reaping the rewards of more modular applications.

1. Don’t go micro overnight

Implementing a microservice-based architecture is not a quick fix. If an existing monolithic application is working just fine, it’s rarely beneficial to make it more modular quickly. Instead, start using microservices on any new features you’re building, while slowly moving pieces of existing business logic into independent services, especially for applications that you know will need to scale or change soon.

Another good idea is to spend time designing a robust API that will allow your microservices to work together. Keep pushing in this direction long enough and you’ll gradually transform your old app into many smaller components that talk to each other with only a small codebase of the old monolith remaining. A few refactorings later and even this old codebase will become just another of your flexible, high-performing microservices.

2. Identify your bottlenecks

When prioritising which existing business logic should be moved to a microservice, look for the pieces that are currently the biggest bottleneck. Whether it’s performance and scaling issues or problems around testing and maintainability, if you are touching a specific part of your business logic way more often than the rest of the system, it sounds like the perfect candidate for separation into its own service.

Typically, the most common bottleneck candidates include:

• Notifier - sends lots of push notifications or emails
• Scheduler - performs some background job at regular intervals
• 3rd party fetcher - gathers data from external API
• Mobile API - provides an endpoint for your mobile apps

3. Use shared libraries for duplicate code

Lots of small independent microservices talking to each other naturally brings its own set of challenges. One of the biggest is code duplicity, especially around boilerplate code for logging and configuration. While you don’t usually need to change those parts of your app very often, if you’re having to copy and paste several files between services, think about extracting that part of your logic into a shared library.

The best way to do this is to use the package management tools of your preferred platform like NPM, Composer or Bundler, while GIT Submodules is another good option. Just beware that it’s not always possible to use a shared library if your existing monolithic application uses a different language to whatever you’re using to build your microservice.

4. Manage increased complexity with GIT repositories

While monolithic single applications are cumbersome, inflexible and hard to scale, they do have the benefit of simplicity – at least on the surface. Using microservices does mean the added complexity of managing numerous separate modules and ensuring each one talks to each other effectively. They also make testing the whole system end to end a little bit trickier. Yet even these issues are relatively easy to manage.

Putting each microservice into its own GIT repository will help maintain good organisation, especially as your team and operation grows. The small size of each repository will allow your team to maintain and update each component quickly, leaving time to deal with more complex issues. It also makes it easier for team members to review and improve the code or to use an automated code quality service like Codeac.io.

The macro effect of microservices

Microservices are a great way to reduce your technical debt so you can focus on your business and waste less time battling a monolithic codebase. Though transforming a monolithic architecture into microservices can take time and effort, especially if your existing codebase is big, the greater flexibility and reliability of a more modular approach will help your business grow faster.