Source – news.sys-con.com
IDC estimates 60% of worldwide enterprises are migrating existing applications to the cloud. With the promise of greater flexibility, a reduction in overhead, and the potential for significant cost savings, it’s a logical decision. But instead of performing a “lift and shift,” – simply moving an existing application to a cloud platform – many businesses use the migration period as an opportunity to modernize the architecture of their applications.
What’s more, in a survey by NGINX, over 70% of organizations say they’re adopting or exploring microservices for their new architectures – and with good reason. Breaking a monolithic application into manageable microservices allows development teams to rapidly respond to an ever-evolving set of business requirements, choose the right technology stack for each task, and readily provide support for a variety of delivery platforms, including web, mobile, and native apps.
However, adopting microservices as part of your cloud migration isn’t always easy. Below are three common challenges we’ve seen enterprises face, and solutions to help mitigate these risks.
Challenge 1: Identifying what needs to be migrated to microservices
Before you can begin breaking your application out into individual microservices, you need to first understand its full scope and architecture. This can prove challenging as many times the overarching view of the application is based on “tribal knowledge” or cobbled together from a collection of disparate tools. Sometimes a more holistic view may be available, but is based on outdated information which does not reflect the current architecture of the application.
You need to find a solution that will help you discover and map every component, dependency, and third party call of your application. This solution should help you understand the relationship of these pieces and how each impacts your application’s behavior and user experience. Armed with this information you’ll have a clear picture of what needs to be migrated, and will be able to make more informed decisions regarding the architecture of your microservices.
Challenge 2: Ensuring your microservices meet or beat pre-migration performance
To ensure your application runs smoothly post-migration, and that user experience was not negatively impacted, you need a way to compare performance metrics from pre and post-migration. This can be extremely difficult as the architecture of these two environments (with the changes to hardware and the move to a distributed architecture) can look drastically different. To make things even more difficult, the monitoring tools supplied by individual hosting providers give insight into only a small portion of the entire architecture, and have no way of creating a more holistic set of data.
To combat these issues and establish a consistent baseline by which to measure your performance and user experience, you will need to capture key user interactions (often referred to as business transactions), prior to beginning your migration. The business transactions are likely to remain the same through migration whereas other metrics may change as you take different code paths and deploy on different infrastructures. Armed with baseline data about your business transactions, you can easily compare the performance of your pre and post-migration environments and ensure that there is no impact to your user experience or overall performance.
Challenge 3: Monitoring your new microservice environment
With large monolithic applications running a single codebase on a few pieces of hardware, two or three tools could once provide complete, straightforward monitoring of application and infrastructure performance. However, with the introduction of microservices, and the potential for each service to implement its own solution for technology stack, database, and hosting provider, a single service may now require a greater number of monitoring tools than the entire application once did. And microservice monitoring brings specific challenges: they are often short-lived, which means monitoring over a longer period of time can be more complicated; and there may be more pathways through which the service is reached, potentially exposing issues such as thread contention.
Finally, while development teams previously didn’t require a monitoring solution which took infrastructure into account, the move to DevOps and the reliance on cloud native technologies means this factor can no longer be ignored.
The goal then becomes finding a unified monitoring platform that supports all of your environments, regardless of language or technology stack. This solution must collate metrics from across your application and infrastructure into a single source of truth, and allow for correlation of those metrics to user experience.
Are you ready?
AppDynamics has been helping customers like Nasdaq, eHarmony, and Telkomwith their cloud migration and microservice adoptions. Schedule a demo to see what AppDynamics can do for you.
