{{announcement.body}}
{{announcement.title}}

TechTalks With Tom Smith: The Future of Microservices Migration

DZone 's Guide to

TechTalks With Tom Smith: The Future of Microservices Migration

Faster application adoption and transition, easier to manage, and serverless microservices.

· Microservices Zone ·
Free Resource

Migrating turtle

Microservices aren't the only things that migrate!


To understand the current state of migrating legacy apps to microservices, we spoke to IT executives from 18 different companies. We asked, "What’s the future of microservices from your point of view - where do the greatest opportunities lie?" Here’s what we learned: 

You may also like: Integration Key to IIoT Success

Faster Transition

  • Adoption confirms there are a lot of benefits. Greenfield apps will be designed for mobile and cloud. Enterprises will look at changing or end of life for legacy apps. New apps for new use cases. Followed by modern apps to replacing legacy apps. 
  • Many organizations are still considering. They will continue to revolve around the business problem they’re trying to solve they will reorganize around smaller organizations/projects. Move the timetable from imagination to delivery to almost real-time.

Cloud

  • Advances in containers and container orchestration are going to be force multipliers for microservices. Coupled with API gateways, Cloud infrastructure, and Service meshes, containers allow different versions of each microservice to coexist, allowing for greater monetization of invested effort, per-customer variations in business functionality as well as seamless integration in DevOps pipelines.

Ease of Management

  • Ultimately everything is a microservice. “Micro” can be misleading. Microservices have been around for a long time as service-oriented architecture. The future will not look different from the past. It will become easier to manage a suite of microservices and have visibility and management across the suite. Istio enables linking. Make an app work with a lot of microservices will be easier. 
  • The greatest opportunities are in the next set of problems after the migration is complete — debug, troubleshoot, monitor, and secure. All of those problems are made worse because microservices-based apps tend to have a lot more moving parts.  If you look at the ecosystem you see more companies specializing in one of those problems, there’s a whole industry popping up around the operations of microservices. 
  • There is an opportunity and problem as environments get bigger — how do we manage the complexity and the cattle. We need to educate on how to interact with environments and find problems more quickly. From cloud providers, we see more adoption of services to do that management.

Serverless

  • The immediate thing is hybrid cloud and multi-cloud. Think about that first. The second thing for app transformation is data transformation. We will want to put data inside containers. Start thinking about container-native databases. Geographic distribution of microservices – how to route across different geographies and integrate data. Using serverless technologies to minimize your footprint. Open source is playing a big indirect role in all of this. People want transparency and the ability to make fixes.
  • Microservices will only get more emphasis in IT teams as a result of their increasing association with other popular technologies/techniques such as stream processing, in-memory computing, machine learning and artificial intelligence, containerization, and serverless computing. These technologies all complement each other and will define new architectures that enable ongoing digital transformation strategies. Microservices will ultimately become a standard best practice that naturally comes as a result of using these other modern technologies (i.e., Apache Kafka, Hazelcast, Docker, Kubernetes, etc.).
  • Building composite applications derived from independent, loosely-coupled, domain-driven capabilities exposed via APIs grants an incredible level of freedom and flexibility. Applications can now be built to change: functionality can be provided by different teams (or even organizations) and can be swapped in and out quite easily. Exploring SaaS or serverless models for these services becomes a potential game-changer in the way that IT is managed, potentially reducing overall costs.
  • This can be a loaded question. Ten years ago, the big push to move to the cloud was all about moving the datacenter. Now we see this as a much different approach to break apart monolithic application into small pieces that help you drive a rapid development cycle at a much greater scale. Who would have been able to predict 10 years ago that a serverless environment would be the top mindset? The future of microservices really enables developers to focus on what’s most relevant to the business while being able to take advantage of parts that are already built for them. I see this becoming easier for the developer as we progress.
  • 1) Microservices are critical for parallel programming, DevOps, and the cloud to grow. 2) Need to keep microservices focused on being independent pieces of code that fulfill small, specific purposes. 3) On-premises systems are great endpoints for many microservices. 4) The architecture is the critical part to get right. Otherwise, each microservice will get bloated. 5) Serverless is maturing and will become an alternative path to microservice architecture.
  • Microservices can provide faster innovation and development times and provide better resource utilization. I would consider the microservices architecture for new applications and projects, but also take into consideration the R&D team’s capabilities and competences. Another aspect to consider is the Serverless computation. That might be a better alternative for some application domains.

Other 

  • Listen it will take a lot to learn what’s going on. Understand how orchestrations work, CI/CD, there's a lot of ramping up to do. Start by educating yourself and then how to integrate the legacy and microservices so you can make a gradual transformation.
  • The enterprise will be the biggest beneficiary. The ability to incorporate business logic lets the business focus on where their expertise is. Chattiness of an app can drive usage fees way up. Think through serverless or create microservices that run inside a VM to manage costs.
  • Service-to-service communication and adoption of event-based microservices. Event-based will be use cases to propagate the state in a consistent way. For every order, we create there will be an invoice and it will be an event.
  • While microservices can be used in any industry, right now it makes the most sense to adopt them in organizations that use agile development methodologies and need to make changes to customer-facing applications quickly. Industries such as financial services already have an agile development environment and a customer base that demands innovation and rapid delivery, and therefore benefit greatly from the adoption of microservices. Industries that require services to be always available, reliable, and responsively scalable based on real-time demand benefit from a move to microservices.
  • As the ecosystem around K8s grows and matures, more and more aspects of delivering and operating enterprise software become commoditized. Huge engineering efforts may be replaced with off the shelf solutions. The promise of a service mesh to raise the resilience and agility bar and transform how services are written currently comes at the price of managing a mass of unwieldy configuration and increased overhead. A more programmatic approach to managing configuration instead of templating YAML resources may be the key.

Here’s who shared their insights:

Further Reading 

TechTalks With Tom Smith: VMworld Hybrid Cloud and Multicloud Conversations

Microservices Migration Use Cases

Topics:
microservices ,adoption ,transition ,managing microservices ,serverless

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}