What Problems Do Microservices Solve?
What Problems Do Microservices Solve?
Microservices allow for the decoupling of monolithic apps so that legacy enterprises can pursue their digital transformation.
Join the DZone community and get the full member experience.Join For Free
DevOps involves integrating development, testing, deployment and release cycles into a collaborative process. Learn more about the 4 steps to an effective DevSecOps infrastructure.
To gather insights on the state of microservices today, we spoke with 19 executives who are familiar with the current state of microservices architecture. We asked them, "What are some real-world problems you, or your clients, are solving with microservices?" Here's what they told us:
Decoupling Monolithic Apps
- One of the most powerful benefits of microservices is how they force you to break your problems down into buildable pieces. When we help our customers modernize an application, it’s frequently a matter of disintegrating a very large monolithic system into its separate moving parts. Our customers frequently begin with the belief that they must transform the entire system at once - an approach Martin Fowler calls the Big Bang. We agree with him that this is a self-destructive plan and instead guide our customers toward analyzing and transforming only the most critical pieces of the legacy system. Because microservices necessarily involve knowing how to subdivide your application into intelligent pieces, it’s very well-suited to our methodology of breaking down monoliths. When planning a legacy transformation, we frequently use this break-down aspect of microservices to our advantage as a thought device for advancing and refining a planned modernization.
- Taking applications and making them more maintainable and testable. Extend the core capabilities across a customer-facing product. Easier to manage scale.
A retailer needs to scale 5X for the inventory lookups on black Friday. Need to scale with in-memory computing. Co-locate data and business logic together. Move code to the data and process in place. Financial services and telecommunication routing – high throughput workloads with less than 50 millisecond response times. Railway transportation provider can reroute all trains in seconds versus hours. Healthcare Integrated Exchanges with a 360-degree view of the patient for real-time decision support and analytics to improve quality of care. In a pay for performance model, the physician is working to control blood sugar levels for diabetes patients.
- We provide an online marketplace where anyone can go to buy or sell pre-owned discounted gift cards. Our marketplace handles a high volume of web e-commerce transactions rapidly and securely through our microservice architecture.
- We help organizations take a wide variety of data - both structured and unstructured - and run it through sophisticated analytical models. In organizations that are not using a tool like ours, the undertaking can be tremendously difficult. Aggregation of data, getting that data to the right place at the right time, and running analytical models in real time are challenging, sometimes nearly impossible. Provenir empowers its users to integrate, orchestrate, and evaluate that data. The real-world problem that we help solve, for institutions from Tier 1 banks to startup FinTechs, is to give data scientists and analysts the ability to write models and deploy them natively so these models can run in real-time. By exposing them as microservices, these organizations can offer a decision-as-a-service or prediction-as-a-service.
- 130-year-old Unilever, for example, created a large number of microservices to support its continued growth, allowing the company to connect its e-commerce applications to the various legacy systems that support its core operations across a global portfolio of brands. Unilever is pairing its microservices architecture with API-led connectivity to drastically reduce development time for new e-commerce applications. As a result, Unilever is able to deploy three to four times faster, proving that organizations with aging legacy IT and established cultures can gain major advantages from re-engineering their applications around a microservices architecture if they use the right approach.
One of the big buzzwords in the industry right now is Artificial Intelligence. What most people in the industry actually want and need is some good automation. Jenkins has long been the tool of choice for automation around software because it provides one of the most flexible environments, but it was a pain to configure in the past. You needed knowledge of maven, a somewhat intimate knowledge of the JRE, and because it was so heavily used many large companies will have a dedicated Jenkins professional or team. Now that Jenkins ships inside of a Docker container, you don't need an expert to set it up and it makes their service available to development studios that don't have any Jenkins specialists. For us internally, any good engineer knows that 2 lines of code often represent 2 hours of research. Using a container means that we can leverage very complicated software without as much research and debugging. It's much better to experiment on a container provided to you by the developer than it is to set everything up yourself. It assists with knowledge transfer because we spend less time caught up in the minutiae of the runtime environment and more time on the actual software.
- Batch operations in a REST API: we wanted every API endpoint to stay within a maximum latency and we realized a microservice to handle batch operation in async, rate-limited, fashion. It is our micro-jewel, it takes job definitions and performs HTTP API calls and other callbacks. Anti-spam tools: a super scalable API should not access external APIs’ HTTP endpoints at high rates (let the microservice do the dirty job, let it risk a bottleneck). Also, we use them for internal stats, mailing, URL metadata fetching and many more.
- We’re just getting started helping clients make the transition. We have a lot of financial services clients all going through the process, recognizing the culture is a bigger issue than the technology. Trying to define service boundaries, domains, and breaking down the business to define the tangible scope and learn lessons that can be applied elsewhere. Microservices is a canvas. Simon Brown, “Find the balance between too much and no design.” Change from learning what and why and interested in how to get started making the change. Working with digital division start-ups. Friction between development teams who want to get apps out the door and engineering teams.
- We hide microservices with Microapps and rollup into an event-driven interface for expense reports, KPIs, service desk requests. One pane of glass powered by microservices and Microapps.
- One scenario we’re building out for an online client is a cluster of microservices that use Schema.org schemas to save all of their relevant data in an XML database. This approach gives the customer several benefits. First, they’re saving the data in the markup format to be used by their web application, making the data instantly readable by search engines. Secondly, we’re storing that data in the Figaro XML database, so the data resides in a database engine running in the microservice itself, saving network latency and dramatically boosting performance. Another great benefit is, it’s easy to load and extract data from the microservice using XQuery, which supports CSV and JSON, and lets the customer extract the data into other formats as needed. With the Nancy Framework, we can extend this support into anything else the customer requires. You don’t hear this much through the din around JSON, but it’s an exciting time to be working with XML, and especially XML databases.
- Direct line of sight to revenue. Easier to deploy multiple features in parallel. Able to show productivity and business value. More flexibility in reorganizing engineering teams.
Do you have some microservices use cases you'd like to share with the development community?
Here’s who we spoke to:
- Thomas Butt, CTO, CardCash
- Matt McLarty, Vice President, API Academy, CA Technologies
- Brian Dawson, DevOps Evangelist, CloudBees
- Lucas Vogel, Founder, Endpoint Systems
- Ali Hodroj, V.P. Products and Strategy, GigaSpaces
- Job van der Voort, VP Product, GitLab
- Kevin Sutter, MicroProfile and Java EE Architect, IBM
- Sandeep Singh Kohli, Director of Marketing, MuleSoft
- Karl McGuinness, Senior Director of Identity, Okta
- Ross Smith, Chief Architect, PITSS America
- Mike LaFleur, Director of Solution Architecture, Provenir
- Gianni Fiore, CTO, Rebrandly
- Peter Yared, CTO, Sapho
- Sha Ma, V.P. Software Engineering, SendGrid
- Keshav Vasudevan, Product Marketing Manager, Swagger/SwaggerHub, SmartBear
- Chris McFadden, V.P. Engineering and Operations, SparkPost
- Christian Beedgen, Co-founder and CTO, Sumo Logic
- Todd Millecam, CEO, SWYM Systems, Inc.
- Tim Jarret, Senior Director of Product Marketing, Veracode
Opinions expressed by DZone contributors are their own.