Migrating to the Cloud – Is Application Performance Monitoring still required?

Editor's Notes

• #3: RICK
• #6: For our webinar today, we shall discuss about Cloud APM, the ways to avoid the common mistakes about APM during your cloud journey. When you look into a cloud monitoring solution, what you may need to look at.
• #7: Cloud adoption is increasing at a rapid pace. IDC estimates that global end-user spending on cloud services will exceed $1.3 trillion within the next five years. The organizations increasingly rely on cloud services to operate their business. So it is important to monitor and manage the performance of applications deployed on the cloud. This is where cloud performance monitoring comes in. Cloud performance monitoring or cloud APM is the process of tracking the performance of applications delivered from the cloud. We use different offering from cloud providers like Infrastructure as a service or platform or software as a service. We tailor all together to offer our business services to our customer. Does the application perform well, as we expect? We need to track its performance to answer ourselves. <CLICK> Our recent survey with DevOps institute says that 67% of the users were using hybrid infrastructure. 21% of them were moved to cloud completely. This migration does not happen in a day. Different trials and testing were involved behind this migration. <CLICK> Surprisingly 71% of them were unhappy with the native performance capability of cloud providers. <why people are not happy? Does not monitor onprem/have gaps in functionality/only provides basic functionality/multi-cloud support not available/expensive?> Let’s talk about some interesting perceptions later. So this is where cloud APM becomes prevalent.
• #8: <click> User experience metrics are important for cloud performance monitoring as they provide an indication of how well an application is performing. At the same time, detailed application and infrastructure metrics are required if performance slowdowns are detected and additional diagnosis is necessary for troubleshooting. There are hundreds of cloud services offered by service providers like AWS, Microsoft Azure, and others. Cloud performance monitoring must collect and analyze key performance indicators for all the services used by an application – e.g., if an EC2 instance is used to host an application, is the CPU credit balance of the instance sufficient? Or, could the application be slowing down because of insufficient CPU credit balance? Infrastructure metrics in a cloud environment usually focus on usage. At the same time, they should also include indicators that highlight whether the resources allocated are under-provisioned.
• #9: <CLICK> Cloud migration provides you different challenges. 25% of the respondents said that they need to handle more complaints from app users than in the past. 38% of them says, monitoring the user experience is very important. 40% of them realized that executive management is concerned about application performance problems. <CLICK> The monitored metrics are to be analyzed and correlated with each other. Then only you can determine the root cause of a problem. You may have nginx to load balance the requests. The application may be running in number of containers, which then connect to the database in paas. How quickly the operations team arrive at root cause is a key for successful cloud migration. <CLICK> Cloud performance monitoring also includes the ability to take actions to resolve issues and get the applications operating well. Learn from the lessons! <CLICK> But do you have analytics screen do achieve this? <CLICK> Does the native monitoring metrics enough? You may need to validate; do they give silo views or end to end view? How many of you realized that you take data from cloud - native monitoring tools and correlate them manually? In this case, a unified cloud APM will reduce your burden.
• #10: <Click> Cloud migration happens for different reasons technically and commercially. Engineers migrate hoping that they can get increased agility. Their scalability will improve. And they can get high availability easily. Commercially management feels comfortable in paying OPEX. As the services are outsourced, they think there are less things to manage. Some of them think that it is easier to manage the apps. They do not need the tools and expertise of on-prem to manage the apps on the cloud. Yes, you are solving some of your problems here. You may believe the cloud provider’s native tools will help them for all problems. Is it real? Does it help to identify all blackspots? May not be.
• #11: <Click> You do not have visibility to entire infrastructure when you move to cloud. We know that. Underlying infrastructure is hidden. Shared among different clients. We are happy as they provide SLAs. <CLICK> SLA is for the cloud service availability. Not for your applications. Because identifying the problems in your applications is your responsibility. Right? The buggy application code, slow SQL queries, SAML authentication, payment gateway problems… you have good probability of problems occurrences. <CLICK> Changes to the underlying cloud infrastructure will influence the application’s performance <CLICK> Your cloud application may serve more load than it is initially designed for. So you should know when cloud resources are insufficient.
• #12: <CLICK> If you think you can get rid of the tools when you move to cloud, you may need to plan in a better way because… The environment is dynamically changing. <CLICK> Your logs, trace files, KPIs, configuration changes etc are dynamically scaling in and out. You need to open your eyes wider. <CLICK> So even after you move to cloud, you need a unified cloud APM to have a better control among your applications. It will help you to be proactive in finding out the problems. When the problem happens, the tool should help you in a better way to find out the root cause.
• #13: Many of us use auto-scaling. That is a great selling point for public cloud providers. <CLICK> You may spawn additional instances of your web/app/database servers when the load goes high. Interestingly we have observed it is not the user load that forces you to multiply always. Application bottlenecks gives a false alarm to cloud platform, as if the application is loaded. For example, the application may be consuming too much of CPU because it is running unnecessary threads. It may be leaking memory. So It may be taking high amount of RAM. If the auto-scaling spawn new instances because of this kind of problems, are ready to pay a high subscription cost every month?
• #14: 48% of respondents to our APM survey reported that they are using containers in the cloud. The same ratio is 32% for on-prem. So, containers are growing. Container technology is introducing new blind spots that APM tools need to handle. Your user may be complaining about slowness. You may not know which nginx container, which SpringBoot application or Azure App services, which RDS supported his transaction. Then how will you identify the root cause of the slowness? Having cloud native resources monitoring or disjoined user experience and application monitoring provided by your cloud providers for additional cost may lead you to manual correlation. <Click> So Auto-scaling does not guarantee the application performance always. A Cloud APM is required to know of how auto scaling is working and to alert IT staff if excessive scale-outs are happening or if a scale-out is triggered by a problem with in an application.
• #15: Cloud migration will protect you from normal hardware failures and other unexpected outages within an availability zone. You don’t need to maintain load balancers, firewalls and servers in your data center. Managed service (Amazon RDS or Azure Database) will reduce the burden on your team. At the same time you need to realize that the cloud service provider is not responsible for any faults in your application logic. Like any other large organization, cloud providers also experience downtime and regional disasters.
• #16: <Enter> Just deploying your applications in the cloud does not guarantee high availability. A cloud APM may help you to achieve High availability because …… <have visibility when application crashes due to application problems> <that tracks the outage in your cloud region or availability zone> <it give you better visibility and proactiveness. It helps you to diagnose your application quickly> <helps to manage your SLA> <risk of downtime is lower> You need to incorporate additional mechanisms to ensure high availability. Depending on the criticality of the application, your SLAs, and your cost budget, you can choose the appropriate HA configuration to ensure high availability. Cloud native tools may not help much during this scenario. You may need to have a DR environment, where multi-cloud technology can help you. <Enter> You may have scripts to redirect your users to your DR site. Such scripts can be invoked by your cloud APM as a corrective action or self-healing.
• #18: Fact: In our survey, 71% of respondents indicated that the built-in cloud monitoring tools were not sufficient for their needs. It is natural. <relate with customers, give example>Some of them are using multi-cloud. Some of them have on-prem workload as well. Unfortunately, they can view only one sight with their two eyes! I mean, there are so many consoles to track. Each cloud provider gives their own monitoring console. On-prem has different console. Finally correlation becomes manual! Built-in cloud monitoring tools require elaborate set-up and are time-consuming to operate. We are not talking about resource utilization metrics like CPU or Memory consumption. When it comes to application monitoring, the scope becomes complex. Those tools also lack all the capabilities of a complete application and infrastructure monitoring tool.
• #19: Some of us try to replicate our on-prem success story to cloud. <CLICK> To some extent this works. You can monitor the EC2 VMs, databases etc. <CLICK> But the problem comes when you start using more and more cloud native technologies like RDS, beanstack, app services etc. <CLICK> Your monitoring tools should be cloud-aware. <CLICK> They should support auto-deployment of monitoring agents, auto-discovering your cloud subscriptions, auto-managing them. It should apply machine learning techniques to do the auto baselining and auto correlation. When the problem happens, it should do the self-healing. <CLICK> When you move to cloud, the monitoring tool should support high support. <CLICK> Capacity computation for on-prem workload and cloud work loads are different. So your on-prem monitoring techniques may not be work for cloud.
• #20: So ladies and gentlemen, a best on-prem monitoring tool may not be a best cloud monitoring tool. For a cloud success story, you need to prepare well to choose a monitoring solution, that are well integrated with multiple clouds. It should also help you to bring your on-premise work load. It will help you to achive the ONE SCREEN – that is unified monitoring.
• #21: So as a summary – <CLICK>We shall avoid common mistakes while we move to cloud. <CLICK>Cloud migration does not remove the monitoring responsibility from you. <CLICK>Auto scaling does not guarantee the performance. A faulty code with auto-scaling can have adverse effect on your cloud cost. So monitoring your production application is super important. <CLICK>Your cloud can go down. You may need to think about multi-region, multi-cloud techniques to succeed. <CLICK>Monitoring cpu and memory is not enough. The additional app monitoring techniques provided by your cloud operator may give you silo view. So prepare for unified Cloud APM with auto-correlation. <CLICK>A best on-prem monitoring tool may not yield you similar success in cloud. <CLICK>Monitoring the dynamically changing cloud application is really complex. Unified view will save your MTTR.
• #22: While choosing cloud monitoring tools, here is my checklist. Ensure it offers unified view among multi-cloud <Recall single medicine slide> Ensure it can include your on-prem work load as well. Else, you may need to run behind different consoles. It should support most of the cloud-native platforms like RDS, beanstalk, app services, Office 365 etc It should have inbuilt analytics of cloud usage It should monitor user experience. It is important. It should provide automated root cause analysis to isolate the problems easily. It should support cloud native features like auto-scaling, auto-deployment, auto-discovery, auto-configuration. It should be secured. It should cost you more. You should not be surprise you at the end of the month. It should monitor the cloud billing cost and predict your monthly cost.