ClusterOps Challenges and How AIOps Can Help

The container revolution may be only a few years old, but it shows no signs of slowing. Organizations are placing an ever-widening variety of workloads in containers, and managing them with resource managers like Mesos and container orchestrators like Kubernetes. Cluster operations, or ClusterOps, is a discipline that evolved from middleware engineering. It helps enterprises deploy varied workloads to a resource manager or orchestrator, ensuring their systems are resilient, secure and available.

Not long ago, the middleware engineer was seen as the mystic gatekeeper between application infrastructure and scale. Tuning an application server or message broker required years of skills and institutional know-how. But as the number of purpose-built systems required to get an application to production slowly began to rise, those engineers who specialize in tuning specific application infrastructure components grew ever more scarce.

Today, middleware engineers are moving into ClusterOps roles. This is a logical evolution, as middleware experts have spent many years preparing for the container revolution. They’ve become the modern day architects and administrators of platform-as-a-service (PaaS) or container orchestrators—the gatekeepers of workloads. But despite their impressive credentials, ClusterOps engineers face the daunting challenge of having to support a growing number of complex platforms.

Forest for the Trees

Something I write about a good bit is the fog of development—essentially, the complexity of grasping the big picture when you’re mired in minutiae. If you’re a ClusterOps engineer, the fog settles in when you need to understand more and more of the stack, but have far less time to work on your projects. Unfortunately, the fog of development can lead to people pointing a finger—maybe at you—when their pet project goes astray.

As much as we strive for parity across our environments, the growing variety of workloads makes it challenging to monitor, maintain and repair problems with yesterday’s tools. You can’t, for instance, truly simulate a production system on a laptop, even a powerful one. With technologies like Minikube—or for the adventurous, Kubeadm-dind—you can attempt to mimic higher environments. However, modern workloads, such as machine learning workloads at scale, require far too much firepower and can’t be simulated effectively on a PC.

ML and ClusterOps: This Might Hurt a Little

Machine learning workloads not only tax system infrastructure, but also the skills of ClusterOps engineers. Due to intense infrastructure demands and the sometimes short-lived nature of spikes in ML workloads, resource managers need to react quickly by spinning up and down much-needed resources to address surges in demand.

Resource managers can be customized to support very specific workloads. There are purpose-built resource managers such as Apache Yarn for big data ecosystems, or generic resource managers like Apache Mesos, which supports a wider variety of workloads. Of course, businesses may find themselves dealing with multiple distributed system technologies and, again, it’s hard for engineers to find time to master these new platforms.

What If We Could Learn Systematically?

We can’t master everything, nor should we try. You don’t know what you don’t know is very much a reality, and humans simply aren’t very good at identifying gaps in their knowledge. So imagine if the enterprise platform itself could teach you the challenges it’s facing? With the rise of AIOps, it can. Disparate workloads of all types can benefit from a platform that provides instructive feedback and semi-to-fully autonomous action.

This isn’t a futuristic concept. Global companies and consumers are already working with automated systems every day. From the rapid growth in automobile automation to enterprise-level intrusion-detection picking out needle-in-a-haystack anomalies, automated systems are reducing the stress and strain on human experts.

Automation can help with the technology-adoption curve, too. Organizations might be reluctant to take on new technologies because of the uncertain ROI. With AppDynamics AIOps, however, the insights gleaned from multiple platforms and systems can feed into the Central Nervous System, providing systematic improvements and enhancing team knowledge. At AppDynamics, we’re excited to be at the leading edge of the AIOps revolution.

AIOps—Luxury or Necessity?

Artificial intelligence (AI) and machine learning (ML) were first discussed by classical philosophers attempting to describe how the human brain works as a mechanical manipulation of symbols. Fast forward to the 1940s, and scientists began to explore AI and ML with mathematical reasoning and the introduction of the programmable digital computer. But even after the renewed interest in AI and ML, these concepts didn’t resonate with enterprises until many years later.

Was it because companies didn’t understand the importance of AI/ML, or that they simply didn’t grasp how the technology worked? Whatever the reason, times have changed and today’s enterprises are embracing AI/ML in a big way. Global spending on artificial intelligence systems will reach $35.8 billion in 2019, and more than double to $79.2 billion in 2022, IDC forecasts.

Defining AIOps

Gartner defines AIOps as the combination of “big data and machine learning functionality to support all primary IT operations functions through the scalable ingestion and analysis of the ever-increasing volume, variety and velocity” (the 3Vs) of IT-generated data. An AIOps platform collects data from multiple sources—regardless of the 3Vs—and makes sense of it all in real-time, correlating historical and real-time data as it relates to the business in an automated fashion.

So, logically speaking, which of today’s enterprises would opt out of automated data analysis? (Hint: none.)

Why You Need AIOps

With terabytes of data flowing from multiple devices to myriad destinations—the edge, cloud, and datacenters—IT teams increasingly are challenged to find, fix and forecast issues at a faster pace than ever before. For this reason, enterprises are exploring AI/ML solutions and looking to implement AIOps platforms.

AIOps can enhance a broad range of IT operations processes, including performance analysis, anomaly detection, IT service management and automation, and event correlation and analysis. It’s a boon for enterprises that need help with common IT issues—reducing MTTR, increasing efficiency, decreasing downtime and more.

AIOps, in fact, has become a necessity for every business, as creating an autonomous IT environment is no longer a luxury. The advantages of using mathematical and logical algorithms to derive solutions or forecast issues before outages affect the customer experience—or hurt the bottom line—is top of mind for most CEOs. With a market opportunity of $2.55 billion and growth expected to top $11 billion by 2023, AIOps in the enterprise is no longer a question of if but when.

The central function of an AIOps platform is to ingest data from multiple sources regardless of source or vendor, and to enable analytics at two points: Real-time analysis upon data ingestion, and historical analysis of stored data. Additionally, the AIOps platform stores the acquired data and provides access to this information, while initiating an action or next step based on the result of its analysis.

Some examples of top enterprises implementing AI/ML today:

 

AIOps platforms enhance IT operations by combining big data, machine learning and visualization to deliver greater insights. It’s time to add this necessity to your enterprise’s shopping list. Learn how the AppDynamics AIOps platform can help your business succeed in an automation-driven world. 

Successfully Deploying AIOps, Part 3: The AIOps Apprenticeship

Part one of our series on deploying AIOPs identified how an anomaly breaks into two broad areas: problem time and solution time. Part two described the first deployment phase, which focuses on reducing problem time. With trust in the AIOps systems growing, we’re now ready for part three: taking on solution time by automating actions.

Applying AIOps to Mean Time to Fix (MTTFix)

The power of AIOps comes from continuous enhancement of machine learning powered by improved algorithms and training data, combined with the decreasing cost of processing power. A measured example was Google’s project for accurately reading street address numbers from its street image systems—a necessity in countries where address numbers don’t run sequentially but rather are based on the age of the buildings. Humans examining photos of street numbers have an accuracy of 98%. Back in 2011, the available algorithms and training data produced a trained model with 91% accuracy. By 2013, improvements and retraining boosted this number to 97.5%. Not bad, though humans still had the edge. In 2015, the latest ML models passed human capability at 98.1%. This potential for continuous enhancement makes AIOps a significant benefit for operational response times.

You Already Trust AI/ML with Your Life

If you’ve flown commercially in the past decade, you’ve trusted the autopilot for part of that flight. At some major airports, even the landings are automated, though taxiing is still left to pilots. Despite already trusting AI/ML to this extent, enterprises need more time to trust AI/ML in newer fields such as AIOps. Let’s discuss how to build that trust.

Apprenticeships allow new employees to learn from experienced workers and avoid making dangerous mistakes. They’ve been used for ages in multiple professions; even police departments have a new academy graduate ride along with a veteran officer. In machine learning, ML frameworks need to see meaningful quantities of data in order to train themselves and create nested neural networks that form classification models. By treating automation in AIOps like an apprenticeship, you can build trust and gradually weave AIOps into a production environment.

By this stage, you should already be reducing problem time by deploying AIOps, which delivers significant benefits before adding automation to the mix. These advantages include the ability to train the model with live data, as well as observe the outcomes of baselining. This is the first step towards building trust in AIOps.

Stage One: AIOps-Guided Operations Response

With AIOps in place, operators can address anomalies immediately. At this stage, operations teams are still reviewing anomaly alerts to ensure their validity. Operations is also parsing the root cause(s) identified by AIOps to select the correct issue to address. While remediation is manual at this stage, you should already have a method of tracking common remediations.

In stage one, your operations teams oversee the AIOps system and simultaneously collect data to help determine where auto-remediation is acceptable and necessary.

Stage Two: Automate Low Risk

Automated computer operations began around 1964 with IBM’s OS/360 operating system allowing operators to combine multiple individual commands into a single script, thus automating multiple manual steps into a single command. Initially, the goal was to identify specific, recurring manual tasks and figure out how to automate them. While this approach delivered a short-term benefit, building isolated, automated processes incurred technical debt, both for future updates and eventual integration across multiple domains. Ultimately it became clear that a platform approach to automation could reduce potential tech debt.

Automation in the modern enterprise should be tackled like a microservices architecture: Use a single domain’s management tool to automate small actions, and make these services available to complex, cross-domain remediations. This approach allows your investment in automation to align with the lifespan of the single domain. If your infrastructure moves VMs to containers, the automated services you created for networking or storage are still valid.

You will not automate every single task. Selecting what to automate can be tricky, so when deciding whether to fully automate an anomaly resolution, use these five questions to identify the potential value:

  • Frequency: Does the anomaly resolution occur often enough to warrant automation?
  • Impact: Are you automating the solution to a major issue?
  • Coverage: What proportion of the real-world process can be automated?
  • Probability: Does the process always produce the desired result, or can it be impacted by environmentals?
  • Latency: Will automating the task achieve a faster resolution?

Existing standard operating procedures (SOPs) are a great place to start. With SOPs, you’ve already decided how you want a task performed, have documented the process, and likely have some form of automation (scripts, etc.) in place. Another early focus is to address resource constraints by adding front-end web servers when traffic is high, or by increasing network bandwidth. Growing available resources is low risk compared to restarting applications. While bandwidth expansion may impact your budget, it’s unlikely to break your apps. And by automating resource constraint remediations, you’re adding a rapid response capability to operations.

In stage two, you augment your operations teams with automated tasks that can be triggered in response to AIOps-identified anomalies.

Stage Three: Connect Visibility to Action (Trust!)

As you start to use automated root cause analysis (RCA), it’s critical to understand the probability concept of machine learning. Surprisingly, for a classical computer technology, ML does not output a binary, 0 or 1 result, but rather produces statistical likelihoods or probabilities of the outcome. The reason this outcome sometimes looks definitive is that a coder or “builder” (the latter if you’re AWS’s Andy Jassy) has decided an acceptable probability will be chosen as the definitive result. But under the covers of ML, there is always a percentage likelihood. The nature of ML means that RCA sometimes will result in a selection of a few probable causes. Over time, the system will train itself on more data and probabilities and grow more accurate, leading to single outcomes where the root cause is clear.

Once trust in RCA is established (stage one), and remediation actions are automated (stage two), it’s time to remove the manual operator from the middle. The low-risk remediations identified in stage two can now be connected to the specific root cause as a fully automated action.

The benefits of automated operations are often listed as cost reduction, productivity, availability, reliability and performance. While all of these apply, there’s also the significant benefit of expertise time. “The main upshot of automation is more free time to spend on improving other parts of the infrastructure,” according to Google’s SRE project. The less time your experts spend in MTTR steps, the more time they can spend on preemption rather than reaction.

Similar to DevOps, AIOps will require a new mindset. After a successful AIOps deployment, your team will be ready to transition from its existing siloed capabilities. Each team member’s current specialization(s) will need to be accompanied with broader skills in other operational silos.

AIOps augments each operations team, including ITOps, DevOps and SRE. By giving each team ample time to move into preemptive mode, AIOps ensures that applications, architectures and infrastructures are ready for the rapid transformations required by today’s business.

Successfully Deploying AIOps, Part 2: Automating Problem Time

In part one of our Successfully Deploying AIOps series, we identified how an anomaly breaks into two broad areas: problem time and solution time. The first phase in deploying AIOps focuses on reducing problem time, with some benefit in solution time as well. This simply requires turning on machine learning within an AIOps-powered APM solution. Existing operations processes will still be defining, selecting and implementing anomaly rectifications. When you automate problem time, solution time commences much sooner, significantly reducing an anomaly’s impact.

AIOps: Not Just for Production

Anomalies in test and quality assurance (QA) environments cost the enterprise time and resources. AIOps can deliver significant benefits here. Applying the anomaly resolution processes seen in production will assist developers navigating the deployment cycle.

Test and QA environments are expected to identify problems before production deployment. Agile and DevOps approaches have introduced rapid, automated building and testing of applications. Though mean time to resolution (MTTR) is commonly not measured in test and QA environments (which aren’t as critical as those supporting customers), the benefits to time and resources still pay off.

Beginning your deployment in test and QA environments allows a lower-risk, yet still valuable, introduction to AIOps. These pre-production environments have less business impact, as they are not visited by customers. Understanding performance changes between application updates is critical to successful deployment. Remember, as the test and QA environments will not have the production workload available, it’s best to recreate simulated workloads through synthetics testing.

With trust in AIOps built from first applying AIOps to mean time to detect (MTTD), mean time to know (MTTK) and mean time to verify (MTTV) in your test and QA environments, your next step will be to apply these benefits to production. Let’s analyze where you’ll find these initial benefits.

Apply AI/ML to Detection (MTTD)

An anomaly deviates from what is expected or normal. Detecting an anomaly requires a definition of “normal” and a monitoring of live, streaming metrics to see when they become abnormal. A crashing application is clearly an anomaly, as is one that responds poorly or inconsistently after an update.

With legacy monitoring tools, defining “normal” was no easy task. Manually setting thresholds required operations or SRE professionals to guesstimate thresholds for all metrics measured by applications, frameworks, containers, databases, operating systems, virtual machines, hypervisors and underlying storage.

AIOps removes the stress of threshold-setting by letting machine learning baseline your environment. AI/ML applies mathematical algorithms to different data features seeking correlations. With AppDynamics, for example, you simply run APM for a week. AppDynamics observes your application over time and creates baselines, with ML observing existing behavioral metrics and defining a range of normal behavior with time-based and contextual correlation. Time-based correlation removes alerts related to the normal flow of business—for example, the login spike that occurs each morning as the workday begins; or the Black Friday or Guanggun Jie traffic spikes driven by cultural events. Contextual correlation pairs metrics that track together, enabling anomaly identification and alerts later when the metrics don’t track together.

AIOps will define “normal” by letting built-in ML watch the application and automatically create a baseline. So again, install APM and let it run. If you have specific KPIs, you can add these on top of the automatic baselines as health rules. With baselines defining normal, AIOps will watch metric streams in real time, with the model tuned to identify anomalies in real time, too.

Apply AI/ML to Root Cause Analysis (MTTK)

The first step to legacy root cause analysis (RCA) is to recreate the timeline: When did the anomaly begin, and what significant events occurred afterward? You could search manually through error logs to uncover the time of the first error. This can be misleading, however, as sometimes the first error is an outcome, not a cause (e.g., a crash caused by a memory overrun is the result of a memory leak running for a period of time before the crash).

In the midst of an anomaly, multiple signifiers often will indicate fault. Logs will show screeds of errors caused by stress introduced by the fault, but fail to identify the underlying defect. The operational challenge is unpacking the layers of resultant faults to identify root cause. By pinpointing this cause, we can move onto identifying the required fix or reconfiguration to resolve the issue.

AIOps creates this anomaly timeline automatically. It observes data streams in real time and uses historical and contextual correlation to identify the anomaly’s origin, as well as any important state changes during the anomaly. Even with a complete timeline, it’s still a challenge to reduce the overall noise level. AIOps addresses this by correlating across domains to filter out symptoms from possible causes.

There’s a good reason why AIOps’ RCA output may not always identify a single cause. Trained AI/ML models do not always produce a zero or one outcome, but rather work in a world of probabilities or likelihoods. The output of a self-taught ML algorithm will be a percentage likelihood that the resulting classification is accurate. As more data is fed to the algorithm, these outcome percentages may change if new data makes a specific output classification more likely. Early snapshots may indicate a priority list of probable causes that later refine down to a single cause, as more data runs through the ML models.

RCA is one area where AI/ML delivers the most value, and the time spent on RCA is the mean time to know (MTTK). While operations is working on RCA, the anomaly is still impacting customers. The pressure to conclude RCA quickly is why war rooms get filled with every possible I-shaped professional (a deep expert in a particular silo of skills) in order to eliminate the noise and get to the signal.

Apply AI/ML to Verification

Mean time to verify (MTTV) is the remaining MTTR portion automated in phase one of an AIOps rollout. An anomaly concludes when the environment returns to normal, or even to a new normal. The same ML mechanisms used for detection will minimize MTTV, as baselines already provide the definition of normal you’re seeking to regain. ML models monitoring live ETL streams of metrics from all sources provide rapid identification when the status returns to normal and the anomaly is over.

Later in your rollout when AIOps is powering fully automated responses, this rapid observation and response is critical, as anomalies are resolved without human intervention.  Part three of this series will discuss connecting this visibility and insight to action.

Successfully Deploying AIOps, Part 1: Deconstructing MTTR

Somewhere between waking up today and reading this blog post, AI/ML has done something for you. Maybe Netflix suggested a show, or DuckDuckGo recommended a website. Perhaps it was your photos application asking you to confirm the tag of a specific friend in your latest photo. In short, AI/ML is already embedded into our lives.

The quantity of metrics in development, operations and infrastructure makes development and operations a perfect partner for machine learning. With this general acceptance of AI/ML, it is surprising that organizations are lagging in implementing machine learning in operations automation, according to Gartner.

The level of responsibility you will assign to AIOps and automation comes from two factors:

  • The level of business risk in the automated action
  • The observed success of AI/ML matching real world experiences

The good news is this is not new territory; there is a tried-and-true path for automating operations that can easily be adjusted for AIOps.

It Feels Like Operations is the Last to Know

The primary goal of the operations team is to keep business applications functional for enterprise customers or users. They design, “rack and stack,” monitor performance, and support infrastructure, operating systems, cloud providers and more. But their ability to focus on this prime directive is undermined by application anomalies that consume time and resources, reducing team bandwidth for preemptive work.

An anomaly deviates from what is expected or normal. A crashing application is clearly an anomaly, yet so too is one that was updated and now responds poorly or inconsistently. Detecting an anomaly requires a definition of “normal,” accompanied with monitoring of live streaming metrics to spot when the environment exhibits abnormal behaviour.

The majority of enterprises are alerted to an anomaly by users or non-IT teams before IT detects the problem, according to a recent AppDynamics survey of 6,000 global IT leaders. This disappointing outcome can be traced to three trends:

  • Exponential growth of uncorrelated log and metric data triggered by DevOps and Continuous Integration and Continuous Delivery (CI/CD) in the process of automating the build and deployment of applications.
  • Exploding application architecture complexity with service architectures, multi-cloud, serverless, isolation of system logic and system state—all adding dynamic qualities defying static or human visualization.
  • Siloed IT operations and operational data within infrastructure teams.

Complexity and data growth overload development, operations and SRE professionals with data rather than insight, while siloed data prevents each team from seeing the full application anomaly picture.

Enterprises adopted agile development methods in the early 2000s to wash away the time and expense of waterfall approaches. This focus on speed came with technical debt and lower reliability. In the mid-2000s manual builds and testing were identified as the impediment leading to DevOps, and later to CI/CD.

DevOps allowed development to survive agile and extreme approaches by transforming development—and particularly by automating testing and deployment—while leaving production operations basically unchanged. The operator’s role in maintaining highly available and consistent applications still consisted of waiting for someone or something to tell them a problem existed, after which they would manually push through a solution. Standard operating procedures (SOPs) were introduced to prevent the operator from accidentally making a situation worse for recurring repairs. There were pockets of successful automation (e.g., tuning the network) but mostly the entire response was still reactive. AIOps is now stepping up to allow operations to survive in this complex environment, as DevOps did for the agile transformation.

Reacting to Anomalies

DevOps automation removed a portion of production issues. But in the real world there’s always the unpredictable SQL query, API call, or even the forklift driving through the network cable. The good news is that the lean manufacturing approach that inspired DevOps can be applied to incident management.

To understand how to deploy AIOps, we need to break down the “assembly line” used to address an anomaly. The time spent reacting to an anomaly can be broken into two key areas: problem time and solution time.

Problem time: The period when the anomaly has not yet being addressed.

Anomaly management begins with time spent detecting a problem. The AppDynamics survey found that 58% of enterprises still find out about performance issues or full outages from their users. Calls arrive and service tickets get created, triggering professionals to examine whether there really is a problem or just user error. Once an anomaly is accepted as real, the next step generally is to create a war room (physical or Slack channel), enabling all the stakeholders to begin root cause analysis (RCA). This analysis requires visibility into the current and historical system to answer questions like:

  • How do we recreate the timeline?
  • When did things last work normally or when did the anomaly began?
  • How are the application and underlying systems currently structured?
  • What has changed since then?
  • Are all the errors in the logs the result of one or multiple problems?
  • What can we correlate?
  • Who is impacted?
  • Which change is most likely to have caused this event?

Answering these questions leads to the root cause. During this investigative work, the anomaly is still active and users are still impacted. While the war room is working tirelessly, no action to actually rectify the anomaly has begun.

Solution time: The time spent resolving the issues and verifying return-to-normal state.

With the root cause and impact identified, incident management finally crosses over to spending time on the actual solution. The questions in this phase are:

  • What will fix the issue?
  • Where are these changes to be made?
  • Who will make them?
  • How will we record them?
  • What side effects could there be?
  • When will we do this?
  • How will we know it is fixed?
  • Was it fixed?

Solution time is where we solve the incident rather than merely understanding it. Mean time to resolution (MTTR) is the key metric we use to measure the operational response to application anomalies. After deploying the fix and verifying return-to-normal state, we get to go home and sleep.

Deconstructing MTTR

MTTR originated in the hardware world as “mean time to repair”— the full time from error detection to hardware replacement and reinstatement into full service (e.g., swapping out a hard drive and rebuilding the data stored on it). In the software world, MTTR is the time from software running abnormally (an anomaly) to the time when the software has been verified as functioning normally.

Measuring the value of AIOps requires breaking MTTR into subset components. Different phases in deploying AIOps will improve different portions of MTTR. Tracking these subdivisions before and after deployment allows the value of AIOps to be justified throughout.

With this understanding and measurement of existing processes, the strategic adoption of AIOps can begin, which we discuss in part two of this series.

Think 2019: Embracing the Cognitive Enterprise

Twenty years ago, companies were just beginning to leverage the internet to revolutionize the way they do business. Much has changed since then, of course, with a scrappy online bookseller emerging to become the world’s second largest e-commerce company and one of the biggest cloud providers—not to mention having one of the highest market caps in the financial world.

So what’s next? At Think 2019, a lot of discussion centered on IBM’s concept of the cognitive enterprise, one that uses artificial intelligence and distributed technologies such as blockchain to power—and disrupt—the markets of the future.

Bridging Cloud Native to Your Enterprise

KubeCon + CloudNativeCon might be the epicenter of Cloud Native and Kubernetes, but IBM Think isn’t far off. More than 70 sessions at Think 2019 involved Kubernetes in some capacity, with over 140 Cloud Native technologies represented. A popular topic at the conference was how Cloud Native could enhance traditional enterprise applications, particularly as businesses look to rearchitect their platforms to meet increased demand. This makes sense, as a key component of the cognitive enterprise is the ability to proactively meet customer and system needs.

Is Your Enterprise Cognitive?

Ignoring the cognitive enterprise today might prove as big a strategic blunder as missing the e-business bandwagon back in the 90s. But the path to cognition isn’t easy. For starters, building confidence in artificial intelligence takes time, as enterprises start to adopt technology that impacts their customers and operations.

To keep up with constant change, we need to be more cognizant of the problems our clients face. But replatforming and adopting complex technology is no mean feat. Decisions around paying off technical debt vs. future feature capabilities are not easy for product owners. Validating how/if change is impacting our business is an art form, with the objective and subjective merging. For instance, does providing a better customer and user experience lead to a higher conversion rate?

AppDynamics has the capability to track this customer journey—from mobile phone to mainframe—a fact highlighted by Jonah Kowall, AppDynamics Vice President of Market Development and Insights, in his excellent Think 2019 session. We enable your enterprise to proactively monitor, analyze and repair issues across a large swatch of your application infrastructure.


Jonah Kowall’s IBM Think session

Artificial Intelligence Goes Mainstream

The historic 1990s chess matches between human and machine—Garry Kasparov vs. IBM Deep Blue—showed that a computer could beat the best chess player in the world. Artificial intelligence has come a long way since then, with modern enterprises embracing AI/ML technology in a big way. Today, deep learning frameworks are some of the most popular open source packages available. At Think 2019, the number and variety of vendors featuring AI/ML capabilities, from robotic process automation to AppDynamics’ AIOps, showed just how far artificial intelligence has advanced in the enterprise.

AppDynamics Looks Forward with AIOps

As organizations start to navigate the cognitive enterprise, they’ll need to make many critical decisions when upgrading and rearchitecting their platforms. AppDynamics is embarking on an AIOps journey to help businesses strengthen their consumer and enterprise portfolios with cognitive technologies. We are excited to continue and deepen our IBM partnership, and to help each organization become a cognitive enterprise.

AppDynamics and Cisco To Host Virtual Event on AIOps and APM


To mark the two year anniversary of Cisco’s intent to acquire AppDynamics, the worldwide leader in IT, networking, and cybersecurity solutions will join AppDynamics for a one-of-a-kind virtual launch event on January 23, 2019. At AppDynamics Transform: AIOps and the Future of Performance Monitoring, David Wadhwani, CEO of AppDynamics, will share what’s next for the two companies, and lead a lively discussion with Cisco executives, Okta’s Chief Information Officer, Mark Settle, and Nancy Gohring, Senior Analyst at 451 Research. At the event, we’ll talk through what challenges leaders face and how they’re preparing for the future of performance monitoring.

Technology Leaders to Weigh In On the Impact of AI and the Future of Performance Monitoring

Today, application infrastructure is increasingly complex. Organizations are building and monitoring public, private, and hybrid cloud infrastructure alongside microservices and third party integrations. And while these developments have made it easier for businesses to scale quickly, they’ve introduced a deluge of data into the IT environment, making it challenging to identify issues and resolve them quickly.

APM solutions like AppDynamics continue to lead the way when it comes to providing real-time business insights to power mission critical business decisions. However, recent research has revealed a potential blind spot for IT teams: A massive 91% of global IT leaders say that monitoring tools only provide data on the performance of their own area of responsibility. For IT teams that want to mitigate risk as a result of performance problems, and business leaders who want to protect their bottom line, this blind spot represents a huge opportunity for improvement.

The Next Chapter in the AppDynamics and Cisco Story

As application environments continue to grow in complexity, so does the need for more comprehensive insight into performance. But technology infrastructure is simply too large and too dynamic for IT operations teams to manage manually. Automation for remediation and optimization is key–and that’s where innovations in artificial intelligence (AI) have the potential to make a huge difference in monitoring activities.

So, what does the future of performance monitoring look like?

Join us at the virtual event on January 23, 2019, to find out. David Wadhwani, alongside Cisco executives, will make an exciting announcement about our next chapter together. During the broadcast, we’ll also feature industry analysts and customers as we engage in a lively conversation about the emerging “AIOps” category, and what impact it will have on the performance monitoring space.

You won’t want to miss this unique virtual event.

Register now for AppDynamics Transform

 

Gartner Report Reveals Why Your APM Strategy Needs AIOps

Is application performance monitoring (APM) without artificial intelligence a waste of resources?

It turns out, the answer may be yes. Gartner’s newly released report, Artificial Intelligence for IT Operations Delivers Improved Business Outcomes, reveals that using artificial intelligence for IT operations (AIOps) in tandem with APM might be the key to optimizing business performance.

So why exactly do AIOps and APM make such a powerful pair and, perhaps more importantly, how can you start applying an AIOps mindset to APM in your own organization?

AIOps and APM: Great Alone, Better Together

Application performance monitoring (APM) is the key to proactively diagnosing and fixing performance issues, but a new study from Gartner reveals the many incremental benefits IT teams can derive from leveraging AIOps in conjunction with APM. Adding artificial intelligence into the mix gives IT and business leaders visibility into the right data at the right time to make decisions that maximize business impact. The power of AI in relation to APM is that most APM environments generate massive quantities of data that humans can’t possibly parse and derive meaning from fast enough to make it useful. Through machine learning, we can ingest that data, and over time, develop intelligence around what matters within an application ecosystem. As Gartner reveals, “AIOps with APM can deliver the actionable insight needed to achieve business outcomes such as improved revenue, cost and risk.”

Consider the process of assessing customer satisfaction based on customer sentiment data and related service desk data. Without using both AIOps and APM, infrastructure and operations (I&O) leaders might come to the conclusion that customers are delighted based on fast page load times. But by using AI to also ingest and analyze data from order management and customer service applications, I&O leaders can find correlations between IT metrics and business data such as revenue or customer retention. This level of insight offered by AIOps allows business leaders to make informed decisions and prioritize actions that will quickly improve customer satisfaction and, ultimately, the bottom line.

Applying AIOps to APM

Here are three ways I&O leaders can leverage AIOps together with APM to achieve incremental benefits—the step-by-step technical strategies for which can be found in Gartner’s new report:

1. Map application performance metrics to business objectives by using AIOps to detect unsuspected dependencies.

AIOps can be used to help measure IT’s activities in terms of benefits to the business—such as an increase in orders or improved customer satisfaction. To do this, I&O leaders should start by collaborating with key business stakeholders to identify the mission-critical priorities of the business relative to applications. Next, acquire the data supporting the measurement of these selected objectives by capturing the flow of business transactions such as orders, registrations and renewals. After inspecting their payloads, you can then use AIOps algorithms to detect patterns or clusters in the combined business and IT data, infer relationships, and determine causality.

2. Expand the ability to support prediction by using AIOps to forecast high probability future problems.

“AIOps provides insight into future events using its ability to extrapolate what is likely to happen next, enabling I&O leaders to take action in order to prevent impact,” Gartner states. As such, I&O leaders should take advantage of the many ways machine learning algorithms can provide value: predicting trends, detecting anomalies, determining causality and classifying data. Use AIOps algorithms to predict future values of time-series data such as end-user response time, engage in root-cause analysis of predicted issues to determine the true fault, and take preventative measures to prevent the impact of predicted problems.

3. Improve business outcomes by applying AIOps to customer and transaction data.

The pattern recognition, advanced analytics and machine learning capabilities of an AIOps solution can extend APM’s historical insight into application availability and performance to provide business impact. By using AIOps’ machine learning capabilities—including anomaly detection, classification, clustering and extrapolation—you can analyze behavior (e.g., customer actions during the order process) and relate that behavior to events afflicting the underlying IT infrastructure. Use the clustering and extrapolation algorithms contained within AIOps to detect unexpected patterns or groupings in your data and predict future outcomes. From there, you can correlate IT problems with changes in business metrics and establish how changes in application performance and availability impact customer sentiment.

Augmenting APM with Artificial Intelligence

The verdict is in and the evidence is compelling: AIOps is the key to maximizing the business impact of your APM investment.

Using AIOps together with APM can help I&O leaders more effectively align IT and business objectives, expand the ability to support prediction, and improve business performance. Leveraging AIOps can take your APM strategy to the next level, giving IT and business leaders the deep insight they need to make decisions that increase revenue, reduce costs, and lower risk.

Application performance management is already a critical tool that belongs in every IT leader’s toolbox, and AIOps is a game-changing technology set to transform APM and IT operations in a major way. As one analyst recently wrote for Forbes, “AIOps is gearing up to be the next big thing in IT management…When the power of AI is applied to operations, it will redefine the way infrastructure is managed.” In today’s competitive business landscape, companies need an edge to survive and thrive—and it seems APM with AIOps might just be the golden ticket.

Access the Full Research

For more exclusive insights into Gartner’s research on why—and how—you should apply AIOps to APM, download the report Artificial Intelligence for IT Operations Delivers Improved Business Outcomes.

Gartner, Artificial Intelligence for IT Operations Delivers Improved Business Outcomes, Charley Rich, 12 June 2018

AWS re:Invent Recap: Freedom for Builders

AWS re:Invent continues to build momentum. Amazon’s annual user conference, now in its seventh year, took place last week in Las Vegas with more than 50,000 builders on hand to share stories of cloud successes and challenges. The atmosphere was exciting and fast-paced, with Amazon once again raising the bar in the public cloud space. And AWS, which unveiled a plethora of new capabilities before and during the show, continues to delight and innovate at a rapid pace.

Are We Builders?

In his opening keynote, AWS CEO Andy Jassy shared a new theme that reverberated throughout the event: software engineers are now “builders,” not “developers.” Indeed, the internet recently has been ablaze with discussion and debate on this moniker shift.

Whether you see yourself as a builder or developer, Jassy helped categorize builders into different personas for enterprises that either like or dislike guardrails. (In AWS, a guardrail is a high-level rule that prevents deployment of resources that don’t conform to policies, thereby providing ongoing governance for the overall environment.)

If you like guardrails you could easily implement machine learning labeling with SageMaker. Not a fan of guardrails? AWS still focuses on core compute, which helps autoscale, for example, the exact number of GPUs a machine learning process needs with Amazon Elastic Inference. Still, the question remains: Are we builders or developers? The debate likely won’t end soon, but one thing is certain: the lower bar of entry for application infrastructure gives us the freedom to pick the best building blocks for our AWS environments.

Simplifying Cloud Migration

Depending on where you are in your cloud migration journey, the move to a public cloud vendor could cannibalize your development stack. AWS certainly has lowered the bar of entry, making diverse application infrastructure available to more individuals and organizations. In fact, you potentially could build a robust API without writing a single line of code on AWS.

Freedom to Transform

Another builder-related term popular at re:Invent was “freedom.” The most notable example was the series of announcements for databases evolving to Amazon Timestream, a managed time series database—check out the hashtag #databasefreedom to learn more. Regardless of whether you agree or disagree with Jassy’s “builder” designation, today’s enterprise is ripe for transformation. Partnering with AppDynamics can help you become an Agent of Transformation.

AWS in Your DataCenter

Some big news from the show made migrating your datacenter to AWS even more tangible. AWS has partnered with VMware to introduce AWS Outposts, an interesting proposition that seems to address the one place AWS was not reaching—the physical datacenter. Microsoft Azure has a similar product in Azure Stack, a combined software and hardware offering with the established management capabilities of VMware. Innovation in both platforms is sure to drive greater competition.

A Driverless Future

The dream of autonomous vehicles has been building ever since the first automobile hit the road. For re:Invent attendees who used Lyft to get around, this dream is now far more real. Lyft partnered with Aptiv to provide autonomous transport up and down the Vegas Strip, allowing those who opted in to be taken from session to session in a self-driving car.

Amazon Web Services also garnered a lot of buzz by introducing AWS DeepRacer, a scaled-down autonomous model race car. This isn’t just another toy, however. DeepRacer is a great tool for teaching machine learning concepts such as reinforcement learning, and for mastering underlying AWS services such as AWS SageMaker. Coupled with the large number of autonomous rides powered by Aptiv, many attendees will no doubt be inspired to use DeepRacer to study up on ML concepts.

AppD at re:Invent


AppDynamics’ Subarno Mukherjee leading an AWS session.

AppDynamics Senior Solutions Architect Subarno Mukherjee led an AWS session called “Five Ways Application Insights Impact Migration Success.” Subarno offered great insights into the importance of the customer and user experience, and how it impacts the success of your public cloud migration.

AppDynamics ran ongoing presentations in our booth throughout the show, covering the shift of cloud workloads to serverless and containers, maturing DevOps capabilities and processes, and the impending shift to AIOps.

Attendees showed a lot of interest in our Lambda Beta Program, too. Feel free to take a look at our program and, if interested, sign up today!

AppD Social Team

The AppDynamics social team was in full swing at re:Invent. From handing out prizes and swag to helping expand the AppDynamics community, we had a great time meeting our current and future customers. AppDynamics and AWS also co-hosted a fantastic happy hour at The Yardbird after Thursday’s sessions.

See You Next Year

We were thrilled to be a part of this year’s re:Invent. The great conversations and shared insights were fantastic. We’re looking forward to expanding our AWS ecosystem and partnerships—and to returning to re:Invent in 2019!

 

 

AIOps: A Self-Healing Mentality

The first time I began watching Minority Report back in 2002, the film’s premise made me optimistic: Crime could be prevented with the help of Precogs, a trio of mutant psychics capable of “previsualizing” crimes and enabling police to stop murderers before they act. What a great utopia!

I quickly realized, however, that this “utopia” was in fact a dystopian nightmare. I left the theater feeling confident that key elements of Minority Report’s bleak future—city-wide placement of iris scanners, for instance—would never come to pass. Fast forward to today, however, and ubiquitous iris-scanning doesn’t seem so far-fetched. Don’t believe me? Simply glance at your smartphone and the device unlocks.

This isn’t dystopian stuff, however. Rather, today’s consumer is enjoying the benefits that machine learning and artificial intelligence provide. From Amazon’s product recommendations to Netflix’s show suggestions to Lyft’s passenger predictions, these services—while not foreseeing crime—greatly enhance the user experience.

The systems that run these next-generation features are vastly complex, ingesting a large corpus of data and continually learning and adapting to help drive different decisions. Similarly, a new enterprise movement is underway to combine machine learning and AI to support IT operations. Gartner calls it “AIOps,” while Forrester favors “Cognitive Operations.”

A Hypothesis-Driven World

Hypothesis-driven analysis is not new to the business world. It impacts the average consumer in many ways, such as when a credit card vendor tweaks its credit-scoring rules to determine who should receive a promotional offer (and you get another packet in your mailbox). Or when the TSA decides to expand or contract its TSA PreCheck program.

Of course, systems with AI/ML are not new to the enterprise. Some parts of the stack, such as intrusion detection, have been using artificial intelligence and machine learning for some time.

But with potential AIOps use cases, we are entering an age where the entire soup-to-nuts of measuring user sentiment—everything from A/B testing to canary deployment—can be automated. And while there’s a sharp increase in the number of systems that can take action—CI/CD, IaaS, and container orchestrators are particularly well-suited to instruction—the harder part is the conclusions process, which is where AIOps systems will come into play.

The ability to make dynamic decisions and test multiple hypotheses without administrative intervention is a huge boon to business. In addition to myriad other skills, AIOps platforms could monitor user sentiment in social collaboration tools like Slack, for instance, to determine if some type of action or deeper introspection is required. This action could be something as simple as redeploying with more verbose logging, or tracing for a limited period of time to tune, heal, or even deploy a new version of an application.

AIOps: Precog, But in a Good Way

AIOps and cognitive operations may sound like two more enterprise software buzzwords to bounce around, but their potential should not be dismissed. According to Google’s Site Reliability Engineering workbook, self-healing and auto-healing infrastructures are critically important to the enterprise. What’s important to remember about AIOps and cognitive operations is that they enable self-healing before a problem occurs.

Of course, this new paradigm is no replacement for good development and operation practices. But more often than not, we take on new projects that may be ill-defined, or find ourselves dropped into the middle of a troubled project (or firestorm). In what I call the “fog of development,” no one person has an unobstructed, 360-degree view of the system.

What if the system could deliver automated insights that you could incorporate into your next software release? Having a systematic record of real-world performance and topology—rather than just tribal knowledge—is a huge plus. Similar to the security world having a runtime application self-protection (RASP) platform, engineers should address underlying issues in future versions of the application. In some ways, AIOps and cognitive operations have much in common with the CAMS Model, the core values of the DevOps Movement: culture, automation, measurement and sharing. Wouldn’t it be nice to automate the healing as well?