Category: scaling microservices

To understand the current state of migrating legacy apps to microservices, we spoke to IT executives from 18 different companies. We asked, "What are some real-world problems you, or your clients, are solving by migrating legacy apps to microservices?" Here’s what we learned: 

You may also like: Successful Migration to Microservices: Why, When, and How

Scale

• Deploy things at a different cadence even if they share a common codebase. Able to scale services differently independent of other services. Able to communicate to users if things go down and execute canary deployments. Resilience, reliability, scalability, and fault isolation.
• The most common real-world problem we hear from customers is how they can stay relevant to their end-users and customers. In this day and age, technology is driving many businesses and acting as the front door to their company. You cannot get by with long outages or poor user experience regardless of the vertical you’re in.
• By migrating to microservices IT will enable your teams to become more innovative as they are freed up from daily mundane tasks supporting and developing on a legacy system that simply cannot compete in the competitive world we are in today. The other primary benefit customers see is scale — an elastic environment that allows your business to auto-scale takes the worry out of slow performance during critical events or peak traffic seasons. This could be a retail outlet during Black Friday/Cyber Monday, or an insurance company during a natural disaster or macro-economic changes that cause a flurry of activity on Wall Street. 
• We create value on mobile apps with external development providing an entry point to enter the data center and consume our APIs. We empower from hundreds to thousands of microservices to happen with a self-service platform for developers to publish new services and new versions as needed. All of this is automated allowing the platform team to set boundaries on what teams can do. 
• Better resource utilization on cloud platforms. Microservices architecture makes it easier to scale the computationally (or I/O wise) heavy parts of the application. 
• Our suite is the solution to security policy management. That means we often introduce support for new firewall models. Although we’ve done it many times in the past, it’s never an easy thing to accomplish. Tight model coupling makes introducing changes to the model difficult to perform safely. To overcome that we've defined a generic extensible model that’s propagated as events to the services consuming it.
• Each microservice can then transform that model to a model that more specifically represents its domain. The limited scope of use for the model means it’s easier to introduce changes gradually without the risk of breaking multiple areas at once. In addition, our customers use our product to automate changes to their security posture, and the specific use-case of the customer determines to what extent they use one module more extensively than another. The microservices architecture provides the flexibility of scaling out in a way that fits the specific use-case of each customer.

Speed

• Independence in implementation and scale grants an organization the flexibility to innovate and try new things. This makes it easier to respond to market shifts, be more responsive to customers, and occasionally shoot for the moon. When new ideas don’t work, they can get tossed without impacting other development; when they do work and adoption drives demand, it’s easy to devote additional resources. Fail fast or scale fast. 
• Innovation speed. By splitting the legacy application into microservices, you have more freedom to innovate, for example, on the user-interface or reporting, while keeping the backend and processing platform unmodified.

Flexibility

• Organizations want a unified way of managing their workloads. If they have to support legacy and microservices they may need expertise in dealing with two sets of APIs. Business just wants to consolidate into a unified way of handling workloads to reduce costs. One set of tools and command-line interfaces. Some customers decide to migrate existing virtualized legacy apps to containers to standardize on microservices API. Someone looking to reduce their VMware presence sees microservices as a way to modernize applications and move to a more open-source model that’s more cost-effective over time. 
• 1) K8s are typically being designed as your own private DBaaS. People are concerned about cloud lock-in. From a microservices standpoint, you can take the same Docker images and run in different environments. Putting the right stack and the right environment provides flexibility and portability.
  2) The core of cross-platform. Public cloud is as susceptible to outages as on-prem. If you’re set up to run cross-cloud you can move to another cloud if there’s an outage. Flexibility and agility. 
• Beyond the apparent cost savings of deploying a microservices architecture, microservices also enables decentralized data management, that is to say, it supports distributed deployment. Microservices deployed in containers allow you to re-provision any container individually, or replace, deprecate, or easily add new microservices as needed for a new feature release, a vulnerability patch, a bug fix, or to roll out any other change.
• They’re also simple to scale independently and responsively, so you can scale out based on demand for a particular service without scaling the entire application. This makes your development process more productive, agile, and cost-effective. You can respond more quickly to customer demands and deploy continuously available applications in the cloud. 
• Managing different, potentially conflicting, component versions. Some legacy applications might use a specific version of a component, such as a library, database, Web framework, programming language (Python 2 vs. 3), etc. When implementing the microservices architecture, you might not want to (time/money/ROI) update all components and microservices allow you to update some components and let some use the older version.

Financial Services

• Under the new version of their application, a client is acquiring substantial read-write like an IoT device communicating. Embarking on the cloud, K8s, DevOps they try to embark on operational excellence and improvement initiatives to achieve greater feature velocity. A financial services company is now deploying code twice a month versus twice a year. 
• In financial services, Xignite makes cool apps for users. They've moved from sharded SQL setup to us to collapse two tiers for the scale, performance, and consistency they need. 
• Some use cases naturally fit into a microservices architecture due to the series of steps that need to be taken on data. One example is in payment processing, where several distinct actions are taken, either in a serial or parallel manner. Transaction data ingestion, rules-based validations, multiple fraud detection algorithms, approval, gateway selection rules, etc., are all distinct actions that can be modeled well in a microservices architecture.
• The benefit of microservices is that any of these actions can be enhanced and expanded individually without impacting the overall operations of the system. Another example is in the industrial internet of things (IIOT) where time-series data from various devices need to be processed in several stages and then delivered to a final data store. Actions such as filtering, summarization, alerting, all can be separated out as microservices. As more functionality is added, new microservices are added to the pipeline without requiring a complete upgrade of the entire system. 
• Microservices provide easier connections to clients' customer systems, such as an insurance company that needed to collaborate with a bank to offer insurance to its customers. The insurance company needed to integrate their systems with the bank. Before having microservice-based APIs, it would take months. After implementing microservices, they completed it even before the commercial agreement was signed.
• This was a game-changer for the way the IT department perceived. For one bank, the critical factor was creating a global API so users (consumers and third-party systems) could get the same service anywhere in the world independent of the backend system is connected to. The expected rollout was 9 months on traditional technologies but using a microservices approach it was deployed within weeks.

Retail

• The majority are modernizing the microservices infrastructure of the big box retailers. Data-as-a-service exposing data APIs and running on microservices. Hardware stores creating more modular components to scale on demand especially around the holidays. Organ donation is able to reduce the time to match doctors with organs available in inventory. Another is the idea of smart agriculture soil samples for nutrients. 
• In the retail industry, Narvar is a post-purchase company trying to migrate from AWS to GCP without disrupting operations. They have data in multiple AWS databases and consolidated them with us to move. They want to be able to scale when needed (i.e., Black Friday).

Other Applications

• A customer is moving from on-prem Oracle to the AWS and hybrid-cloud. We helped them move all of their data and databases from on-prem and in data centers to new data stores and structures. There’s a ton of change management that needs to happen. The scariest is at the persistence layer. TBs upon TBs of data. Finding sane ways to ETL it over.
• We bring safety, transparency, and governance into schema and structure changes. We leverage the cloud-native or platform-as-a-service offerings the cloud vendors have. We help with the transition of the data store many months ahead of schedule. We accelerate and de-risk transitions. The easy part is how to build and deploy application bits into cloud-native, managing all of the data is the challenging part.
• It tends to be more about gaining visibility into how you are operating and comparing against legacy. Internal dev teams are tired of working with business teams or the business gets a huge OpEx bill and learns they are doing cloud wrong. Microservices with managed services is the way to reduce those costs.

Other Industries

• Plume works with ISP devices embedded in Comcast to monitor the quality of Wi-Fi. Today, every home is a mini data center.  There are multiple ISPs and geographies. Plume enabled scalability and a cloud-native platform.
• Two enterprise-level problems we are currently solving through such migrations are:
  1) A monolithic application that encompasses an entire company’s business revenue, from automotive dealership management, inventory, motor insurance, regulatory management, financial modeling etc is being slowly architected into a microservices application.
  2) Rearchitecting from a 2-tier legacy application to a microservice-based architecture on the cloud for one of the world’s best-known companies in Loyalty Management platforms and services.

Here’s who shared their insights: