Subscribe for updates on posts
Be the first to read the latest news

Microservices: benefits and drawbacks (part 1)

April 24th, 2017 by Silviu Stefanescu in Software Development, Tools

A quick guide on when to use microservices and when not to

microservices

Which do you think works better for your company – one big machine that does all the jobs, or several sleek tools that deal with various parts of your business? No surprise here, the consultant’s answer would be “It depends.” Well, for once, the consultant might be right.

For decades, the mainstream approach of software design has focused on replicating business operations with their own digital versions. For not so long, however, it has become clear that one do-it-all solution can be too rigid. As the business changes, big omnipotent tools may painfully fail to meet new requirements.

The reason is that businesses are fluid, while monolithic software is not. And this is where microservices come into play.

Microservices – “A software system that has been separated into smaller modules that interact with each other. […] The foundation of microservices is a standard programming interface (API) that enables each module to communicate with another. The advantage of microservice architecture is that each microservice can be independently updated with patches and enhancements without affecting the entire system.”  – PCMag Encyclopedia

That is just a way of describing how, for instance, PayPal’s “Make a payment” button is powered by a separate module that is maintained by a dedicated team. Similarly, the “User Reviews” sections of Amazon and Netflix websites have their own distinct apps in the background. Those are just some of the better known companies that use microservices to drive their business platforms, alongside other household names like Uber, Comcast Cable, Ebay or SoundCloud.

While definitely not ubiquitous yet, the technology is on the rise.

According to a 2016 survey by Lightbend, more than 30% of 2,151 queried IT professionals are already running microservices in production, with another 20% “seriously piloting” microservices for ultimate production deployment. And NGINX, which asked about 1,800 IT professionals, found that 70% of organizations are investigating microservices, if they are not already using them.

At Tremend we recommended microservices to some of our clients, based on a thorough assessment of benefits. There have been cases too when we considered the modular option for our customers, but chose not to use it. And that is because microservices, while offering several clear advantages, may not always be better than a monolithic architecture.

Here are some of the things we have learned.

What to take into account when choosing microservices

It helps to start with some of the questions a business should ask before considering microservices for their company.

 

  1. First, how loosely coupled are the business entities? The more loose they are, the more suitable the modular architecture becomes.
  2. Then, how uneven will the company growth be, in terms of various business divisions? The more uneven, the stronger the case for microservices.
  3. Another issue is how can the business processes be separated? A very important one, when defining microservices.
  4. And what kind of reports will the software produce?  Also important when creating the communication API that microservices will use.

These are just some of the variables that build the case for either modular or monolithic platforms. The good news is that decision does not have to be one way or another. There is always the midway option. It consists of a main solution that handles most operations and a few attached microservices that cater to specific operational tasks.

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 second 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.

Be the first to read the latest news:


You might also like

Microservices: benefits and drawbacks (part 2) This post is the second part of our Quick guide on when to use microservices and when not to. Which...
Developing with microservices for a full stack eCommerce solution The Problem - or Why Not a Classic Architecture Developing an entire application from scratch may look...
Software prototyping: how does it work? There is no innovation without risk. And no success without several prior failed attempts. Testing a...
Perelman’s CigarCyclopedia for Android now available Perelman's guide is now available in Android Market. See it here: http://www.cyrket.com/p/android/com.deviceiq.cigarcyclopedia2010/ As...
.

2 Responses

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

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

  2. Developing with microservices for a full stack eCommerce solution Says:

    […] Read more about the advantages of using microservices here. […]

Leave a Comment

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