Microservices: benefits and drawbacks (part 2)

5 min read >

Microservices: benefits and drawbacks (part 2)

Advanced Technologies

This post is the second part of our Quick guide on when to use microservices and when not to.

Which companies should use microservices

From our experience, microservices are mainly employed when clients want to develop or rewrite an application for which they forecast uneven growth. That can happen when a certain business segment is expected to grow, or change radically. Such a situation calls for changes in just some functionalities of the software solution.

The modular approach is also useful when creating complex, scalable solutions from scratch. A large e-commerce platform, for instance, can be separated into microservices for client accounts, transactions, and products. They can each be developed by a separate team, with different technology stacks and appropriate languages.

Another cause for the use of microservices is when the client wants to develop with multiple teams in parallel, in different locations of the world.

Certain organizations, by nature of their business, are a better fit for microservices, even in their core operations. They are usually companies with large sets of clients, users, or communication endpoints. Among them are FMCG retailers, financial institutions, telecom operators, social media apps, media publishers, IoT data aggregation platforms, and more.

Benefits of microservices

Here is a minimal list of the main advantages of using a modular solution.

  • Simplified development. Several autonomous teams of back-end and front-end engineers can simultaneously build different modules of the solution, using diverse programming languages or database platforms.
  • Operation reliability/ Operational continuity. Once the solution enters production, it can continue to operate even if one of the modules fails or suffers a security breach.
  • Easier maintenance. Modules can be updated separately, without the need to build and implement full-fledged versions of the entire platform.
  • “Non-captive” maintenance. Also known as knowledge base mobility. Modules can easily be handed over to new teams for maintenance and support, along with the related knowledge. That is harder to achieve with large, monolithic applications.
  • Organizational scalability/Faster go-to-market. Different teams can work in parallel on the various components, shortening the go-to-market time.
  • Programming diversity. Code is not limited to one technology.
  • Scaling. Microservices provide scalability for specific parts of the business, without the need to change the entire software architecture in case of a spike in certain operational segments.
  • Plug-and-play capability. Modules can be replaced independently with better, faster, newer versions with minimum impact on the overall solution.
  • Refactoring-ready. The whole solution can be easily refactored later on when business and technical requirements change.

Drawbacks of microservices

And here are some of the reasons why modular is not always the new black.

  • Increased operational complexity of the overall solution, caused by the interdependence of various modules
  • Increased intricacy in assembling business reports that rely on data from diverse modules
  • Possible issues might appear related to the atomicity of operations
  • Possible operational problems caused by the need to start separate applications simultaneously
  • An increase in potential points of failure, caused by the network complexity and a higher number of interactions
  • Challenges derived from creating the architecture, from system monitoring and aggregation of logs.

At Tremend we have had the experience of implementing microservices for several of our clients. One of them is a large telecom operator with several million customers. Another one is a leading European retailer with major operations in Romania. We have created microservices architectures using technologies such as Apache Kafka, Spring Boot, Consul, Hystrix, and Java RX. While building the architecture, our engineers created test environments for the clients, who continuously tested the codebase as it grew. They used tools such as Doker or Rancher, which simplified the deployment process significantly.

Read more about our experience with microservices in the first part of this post.

And of course, if you need support in deciding between microservices or monolithic architectures for your organization, feel free to say hello@tremend.ro.

Tremend software solutions include the full range from online stores to complex software for the banking industry. For over 11 years we have developed for the Internet of Things, e-commerce platforms, enterprise solutions, embedded software, CRM, CMS, ERP integration, and custom software. Over two million users benefit from solutions developed by our team of software engineers.