Microservices: benefits and drawbacks (part 2)

May 2nd, 2017 by Silviu Stefanescu in Software Development, Tools

Postare microservicii 2This 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, products. They can each be developed by a separate team, with different technology stacks and appropriate languages.

Another case 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.

microservices benefitsBenefits of microservices

Here is a minimal list of 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.
  • Organisational 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 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 microservicesDrawbacks 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 with 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, 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 over microservices or monolithic architectures for your organisation, 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.


You might also like

Microservices: benefits and drawbacks (part 1) A quick guide on when to use microservices and when not to Which do you think works better for your...
TechTalks@Tremend with Mircea Marghidanu, lead developer at Unity3D Mircea Marghidanu, lead developer at Unity3D was our guest at Tech Talks@Tremend for a presentation on...
Avoid Spring circular references and over eager type matching using lazy initialization Circular dependencies between beans managed by Spring is usually caused by a logic error, but it may...
Apache Derby versus Hypersonic SQL There are several limitations and problems of Apache Derby as noted in the previous post (http://blog.tremend.ro/2006/10/03/about-the-maturity-of-apache-derby/),...
.

One Response

  1. Microservices: benefits and drawbacks (part 1) Says:

    […] Microservices: benefits and drawbacks (part 2) […]

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.