Microservices Use Cases

DZone 's Guide to

Microservices Use Cases

The benefits of microservices are irrespective of the domain. Read what industry experts say about microservices use cases.

· Microservices Zone ·
Free Resource

To understand the current and future state of microservices, we spoke to 25 IT executives from 21 organizations. Consistent with the early adoption of the technology, the answers to our questions were diverse. We asked respondents, "What are some real-world problems being solved with microservices?" Here's what they told us:


  • The biggest and most relevant use case is fraud detection. Build out ML models and put them in line with microservices, load balancing and deploy multiple models within the rendezvous model for ML and model deployment.
  • We work with FinServ if developers own entire service dev teams blur lines. Now engineers do ETL. Fault detection apps need to access the server. It looks a lot like ETL but microservices to detect fraud. Use cases blur the line between business value and core IT infrastructure. Formerly a cost center, now an Agile microservices team is no longer a cost center — it's providing value to the business. 

Digital Experience

  • We deal with many domains financial, healthcare, telecommunication. Provide a digital experience for the end user. Have a consistent view for everything they are dealing with. Healthcare is using IoT to connect and communicate with devices, remote patients, and clinics. Make decisions based on the information they’re getting back. E-commerce has quite a few. The benefits are irrespective of the domain.
  • We are focused on solving workflow automation challenges. Consider that while microservices are designed to focus on a single business capability and to be developed and deployed independently of other services, core end-to-end business processes typically span multiple microservices. These multiple services need to collaborate to achieve the desired business outcome. For instance, an e-commerce company that’s fulfilling a customer order needs to process a payment, then fetch items, then ship the items--and each of these different steps might be carried out by a different microservice. The company’s users and customers get what they want only when the end-to-end process is completed successfully. A modern workflow engine that orchestrates long-running, cross microservice workflows while also giving visibility into these flows addresses a critical gap in current tooling. It’s important to note that it’s possible to run such a workflow engine embedded in each microservice and to split a business process defined in BPMN into the respective parts owned by each service. Using an embedded engine, you’re sure to avoid introducing a BPM monolith into your architecture--we believe this concern is one reason developers avoid orchestration even though it can ultimately make their lives much easier. This orchestration pattern is one that applies to many different use cases in many different industries, and here are some specific examples. Zalando, one of the largest e-commerce companies in Europe, uses us to orchestrate their order fulfillment process. MEDIAGENIX, a provider of a broadcast management platform used by media companies such as Disney, Discovery, Viacom, and the BBC, uses us to orchestrate content onboarding for a video-on-demand product. 
  • The Miami HEAT app is a prime example of how microservices “done right” creates an amazing experience in the real world. Operationally, the Miami HEAT benefits from the speed and efficiency that microservices bring to their mobile solution and its deployment cycles. For their primary audience – their fans – the Miami HEAT have been able to create a highly engaging app that uses microservices for everything from personalization to analytics. The app blends physical and digital services and uses our unique, microservices-driven integration architecture to create this award-winning fan experience.


  • The real challenge is the agility around making an easy change to a process -- like the creditworthiness of a customer. Data scientists can make changes to model quickly versus entire SFDC. With microservices, as long as don’t violate the contract, four variables in one answer out, you can make changes in hours. Take one service, expose it, you’re able to make changes in hours versus months.


  • There is an API enablement use case. The ulterior motive organizations have today is do as much possible in one go. API-first initiative converts everything to microservices. We can use microservices as a vehicle to get to digital transformation. We wrap a core transactional platform with a new set of technologies and statically analyze microservices code.

  • T-Mobile took a look at our platform with microservices on top doing Agile development. T-Mobile took their payment system, the heart of their business and broke apart the microservices they wanted and started iterating on it. They saw they could make changes during the day with advanced release processes seeing benefits at the heart of their business.
  • We see the benefit of moving to microservices in every domain good example is diagnostic approaches. It's growing into AI/ML, big data more complex data analytics engines. As more capabilities are added, smaller, more focused components provide value to clients and users more quickly.
  • We are mostly using microservices internally for more effective development at our small start-up. We are effectively developing from scratch in just under a year. Applying microservices to the OS itself allows us to do defense in depth. What we’re doing on a device we guarantee customers if one device is compromised it does not compromise the entire system. We use microservices to isolate functionality from a security standpoint. Every microservice is a unikernel running in the hypervisor, communicating via the hypervisor.
  • Ability to update parts of large apps by only updating some and not others. Greater agility. When fully invested in microservices philosophy developers learn best practices around making apps more stateless and horizontally scalable.  The benefit is you get applications that are more scalable and because the orchestration system makes it easy to scale apps by creating more replicas in response to higher demand and because there are many replicas running on multiple machines your application becomes more resilient to failure.
  • We now have the ability to do horizontal clustering effort. We are an on-premise product. We store data people are uncomfortable putting in the cloud, clustering horizontally without configuration. We focus on application functionality versus scaling. Big gains are being made by greenfield applications as it allows them to accelerate development and write better code from scratch. Some customers are taking a hybrid approach. They can wrap microservices API layers around mainframe style architecture and code modern apps on top of that. We can do a lot of things fast without interruption. People layer APIs between pieces of large applications, one by one chipping away at things you want to modernize (Martin Fowler). You can run these things with hundreds and thousands of services. There are more moving parts. You have to be good at testing. Forces you to get it right. Not burdened by legacy code that isn’t testable. Can always improve the process make it easy to evolve, add functionality, it's easier to fix a problem when applications are loosely coupled. Encourage people to start coding right.
  • You are responsible for a service and its reliability. As reliability degrades it needs to be refreshed. Twilio reduced MTTR by 95% by finding out about issues quickly and real-time monitoring and notifications about microservices and microservice dependencies and how downstream performance is affecting your application. Reduces needle in a haystack. We stitch together a full lifetime of microservices’ requests. Gameday firefighting is a typical use case. Companies and developers also benefit from long-term workforce optimization. We enable developers to use statistical data to determine where problems lie. Improve average performance over 50% for the critical use case. Distributed tracing helps identify performance bottlenecks.
  • Expanding is the only way to maintain development velocity. Carve out specific development areas to small independent teams. Run some experiments. AMD testing over a new functionality. Try out new things or test something with customers.
  • In the financial industry, the ways microservices help are to increase visibility into the organization with 30-year-old technology, highlight redundant or unused systems, complex ways to talk to each other, get visibility through marketing.
  • We enable people to practice and scale CI/CD with containers and K8s a first-class citizen in the environment and that enables developers to address the ills we are looking to increase the velocity to address. Enabling microservices development with CI/CD, deliver apps faster, deliver value faster. We touch the whole lifecycle of development and integration. We are in a unique position to observe what is happening throughout the SDLC. Enabling CD from gathering requirements through production. Our goal is to help developers implement CI/CD to get to the end to deliver more value faster, gain/maintain competitive advantage, increase productivity, reduce cost, with happier developers. Use CI/CD to build a better world. Stop doing boring repetitive things that don’t add value – automate.
  • Some of our clients are extending existing applications with microservices to enable new features on top of an existing application. With this strategy, businesses do not have to do a full re-architecture and rewrite an existing application while still receiving some benefits of microservices.
  • Most successful organizations focus less on this is microservices and are focused on improving the performance of teams. Proxy metrics are 1) number of deployments per day, 2) how quickly you can get a code change from Git commits to production, 3) MTTR, 4) how often are you experiencing failures. Successful teams are the ones looking at those metrics. Take an iterative approach to improve the process to improve KPIs. Testing, the capability to do deployments more confidently and promote from one environment to another, how do we monitor, how do we improve implementation and go faster. Make improvements from a delivery capacity. Then they get to a point where they feel comfortable with their changes and think they can build new services that can live around this system. Platform capabilities improve cycle time for the monolith.
  • Our customers run the gamut from just beginning their microservices journey to operating relatively sophisticated architectures delivering real efficiencies. The most interesting are large financial institutions that deliver all new functionality using microservices while maintaining and continuing to leverage legacy applications through API-based integrations. They’re able to provide new, all-digital products and services because they can better respond to customer needs, without needing to rip and replace.
  • One interesting use case would be attribution: as the team grows the number of commits in each release of the monolith goes up. This means that when something goes wrong it becomes more difficult to pinpoint the issue. As we break pieces of the monolith, the mean-time-to-detection of issues starts to drop as it’s easier to detect performance problems, memory leaks, and other issues in smaller units, especially since each release in a microservice has fewer changes in it.

Here’s who we spoke to:

microservices ,software architecture ,software development

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}