Cisco (AppDynamics) is Named a Leader in Gartner’s Magic Quadrant for the Sixth Consecutive Year

Today, Cisco (AppDynamics) was named a Leader in Gartner’s 2018 Magic Quadrant for Application Performance Monitoring Suites for the sixth year in a row. We were also positioned highest among 15 vendors for ability to execute – something we’re incredibly proud of.

Since joining AppDynamics over a year ago, one of the things I love most about the team is how closely we listen to customers.  Whether it is about cloud migrations, digital transformation, or improving the speed of doing business, our customers’ feedback inspires us to keep innovating faster every day.

We believe Gartner’s recognition is a reflection of the innovations we’ve made over the last year that are dedicated to helping customers achieve more visibility, confidence, and agility.

Take, for example, our introduction of the next generation of Business iQ, Business Journeys, which links multiple, distributed business events into a single view that shows the way customers actually interact with a business. Businesses can now shape their digital experiences to match the real-time needs and expectations of their customers.

And as more connected devices continue to spread in both the consumer and enterprise worlds, we also launched IoT Monitoring to give businesses the ability to glean insights into end-user behavior across any number of devices.

Then there’s the massive task of drawing real-time insights from the high volume of data we collect. We needed help here, and we got it with Perspica Technologies. We doubled down on our machine learning capabilities with the onboarding of Perspica to help advance the domain-expertise needed to quickly turn data into business-aware insights.   

This was just a glimpse of our milestones in over the last year. We believe being named as a leader for APM Suites in Gartner’s Magic Quadrant for the sixth consecutive year is a big honor, but we’re nowhere near slowing down. So stay tuned – you’ll want to see what we have in store.

Learn more

Download your complimentary copy of the 2018 APM Suites Gartner Magic Quadrant report now.

Gartner Magic Quadrant for Application Performance Monitoring Suites, Will Cappelli, Sanjit Ganguli, Federico De Silva, 19 March 2018. Cisco (AppDynamics) was included as AppDynamics from 2012-2016. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and is used herein with permission. All rights reserved.

Getting Started with Containers and Microservices

Get Ahead of Microservices and Container Proliferation with Robust App Monitoring

Containers and microservices are growing in popularity, and why not? They enable agility, speed, and resource efficiency for many tasks that developers work on daily. They are light in terms of coding and interdependencies, which makes it much easier and less time consuming to deliver apps to app users or migrate applications from legacy systems to cloud servers.

What Are Containers and Microservices?

Containers are isolated workload environments in a virtualized operating system. They speed up workload processes and application delivery because they can be spun up quickly; and they provide a solution for application-portability challenges because they are not tied to software on physical machines.

Microservices are a type of software architecture that is light and limited in scope. Single-function applications comprise small, self-contained units working together through APIs that are not dependent on a specific language. A microservices architecture is faster and more agile than traditional application architecture.

The Importance of Monitoring

For containers and microservices to be most effective and impactful as they are adopted, technology leaders must prepare a plan on how to monitor and code within them. They also must understand how developers will use them.

Foundationally, all pieces and parts of an enterprise technology stack should be planned, monitored, and measured. Containers and microservices are no exception. Businesses should monitor them to manage their use according to a planned strategy, so that best practice standards (i.e., security protocols, sharing permissions, when to use and not use, etc.) can be identified, documented, and shared. Containers and microservices also must be monitored to ensure both the quality and security of digital products and assets.

To do all of this, an organization needs robust application monitoring capabilities that provide full visibility into the containers and microservices; as well as insight into how they are being used and their influence on goals, such as better productivity or faster time-to-market.

Assessing Your Application Monitoring Capabilities

Some of questions that enterprises should ask as they assess their application-monitoring capabilities are:

  • How can we ensure development and operations teams are working together to use containers and microservices in alignment with enterprise needs?

  • Will we build our own system to manage container assignment, clustering, etc.? Or should we use third-party vendors that will need to be monitored?

  • Will we be able to monitor code inside containers and the components that make up microservices with our current application performance management (APM) footprint?

Do we need more robust APM to effectively manage containers and microservices? And how do we determine the best solution for our needs? To answer those questions and learn more about containers and microservices—and how to effectively use and manage them — read Getting Started With Containers and Microservices: A Mini Guide for Enterprise Leaders.

This mini eBook expands on the topics discussed in this blog and includes an 8-point plan for choosing an effective APM solution.

Go to the guide.

Attaining Nirvana: The Four Levels of Cloud Maturity

Cloud adoption is atop every CIO’s priority list, and for good reason. Technology stacks are advancing at lightning speeds. Application architectures of the past decade are aging fast and being replaced with modern, public and private cloud-based ones. But while cloud adoption is inevitable, the vast majority of organizations are still searching for an effective application migration strategy, notes Gartner.

If you feel like you are falling behind the competition in your cloud journey, there’s no need to panic. A structured and comprehensive migration model, combined with a smart investment strategy, will go a long way toward ensuring success. Our cloud maturity model is based on insights we’ve gleaned from hundreds of conversations with CIOs about their cloud adoption strategies, as well as numerous customer migrations we’ve supported successfully. We’ve identified common patterns—or “maturity levels”—in the adoption process. By understanding this maturity model, you may find it easier to develop your own cloud strategy.

Below we describe four levels of cloud maturity. It is important to note that progression does not require adopting every level along the way. Some organizations skip levels, jumping from Level 1 to Level 3, for instance, and bypassing Level 2 altogether. Not all organizations need to end up at Level 4, and most will have different applications in their portfolio at different levels of maturity at the same time. For example, since customer-facing apps that generate revenue need to be the most agile and responsive, it makes sense to migrate them to Level 3 or Level 4, which are optimized for rapid application delivery and scale. On the other hand, older apps in maintenance mode can be kept at Level 1 or Level 2 without incurring too much additional investment. Also, keep in mind that companies are adopting a DevOps operational philosophy to accomplish these transformational tasks (more on this below).

Hybrid apps, where parts of the application continue to run on-premises due to immovable mainframe systems or data gravity—Dave McCrory’s concept where data becomes so large it’s nearly impossible to move—are a reality as well.

Level 1: Traditional Data Center Apps

Traditional data center apps run in classic virtual machines (such as VMWare) or on bare metal in a private data center, and are typically monitored by the IT Ops team. There are pros and cons to these architectures and deployments, of course. Advantages include total control over your hardware, software, and data; less reliance on external factors such as internet connectivity; and possibly a lower total cost of ownership (TCO) when deployed at scale. Disadvantages include large upfront costs that often require capital expenditure (CapEx), as well as maintenance responsibilities. They also result into longer implementation times that begin with hardware and software procurement before any code is written. Given these drawbacks, it’s quite likely that by 2020 a corporate “no cloud” policy will be extremely rare.

Level 2: Lifted and Shifted Apps

Given the cloud’s promise of elasticity and agility, nearly every IT organization has embarked on a cloud adoption journey. Those who haven’t actually started migrating their production workloads are definitely prototyping or experimenting in this area. However, cloud migration seldom runs smoothly. Oftentimes an organization will take the same virtual machines it was running on-premises and “lift and shift” them to the cloud. The target environment is typically a public cloud provider such as Amazon AWS, Microsoft Azure, or Google Cloud, or at times a private data center configured as a private cloud.

A sound migration strategy? Not really. Despite the expected cost savings of this approach, a company often finds it’s far more expensive to run its applications in the cloud in the same way it did on-premises. The large VM configurations that these applications were architected for are very expensive in the cloud. In other cases, the underlying infrastructure lacks the support it had on-premises. For example, some application servers relying on multicasting capabilities to communicate with each other, no longer work in the cloud when purely lifted and shifted. These shortcomings demand an application refactoring.

Lastly—and perhaps most importantly—these traditional data center applications were written with certain hardware reliability assumptions that may no longer be valid in the cloud. On-premises hardware is typically custom built and designed for higher reliability, whereas the cloud is built on a tenet that hardware is cheap and unreliable, while the software layer delivers application resiliency and robustness. This is another reason why application refactoring becomes necessary.

Level 3: Refactored Apps

Once an organization realizes that some of its lifted-and-shifted applications are fundamentally hamstrung in the cloud, it needs to refactor its apps. Several modern platforms that are purpose-built for running apps in cloud environments are a perfect choice for refactored programs. These modern platforms generally include application platform-as-a-service (PaaS) technologies or cloud native services. The typical PaaS technologies include Pivotal Cloud Foundry, Red Hat OpenShift, AWS Elastic Beanstalk, Azure PaaS, and Google App Engine. The cloud native offerings include hundreds of managed services offered by AWS, Azure and Google Cloud, such as database, Kubernetes, and messaging services, to name a few.

In a traditional data center apps environment, the IT organization is responsible for deploying, managing, and scaling the application code. By comparison, these modern platforms automate tasks and abstract out a lot of complexities; applications become elastic, dynamically consuming computing resources to meet varying workloads. The modern approach frees the IT organization from maintaining something that has no intellectual property benefit to its business, allowing it to focus on business problems as opposed to infrastructure issues.

Level 3 is where organizations begin to see signs of the cloud’s true potential. This is also where companies can dabble in container technology, and start to build the organizational muscle to run apps in modern architectures. However, not all is perfect in this world; organizations need to use caution when adopting some cloud-native services, which can result into vendor lock-in and poorer application portability—a top priority for some companies.

And while it may appear the cloud journey is now complete, obstacles remain. Refactored apps are often the same code from monolithic apps, only broken down into more manageable components. These smaller components can now scale automatically using PaaS or cloud-native services, but their code was not originally architected for truly modular, stateless deployments that would make them linearly scalable. Yes, a car may run faster after getting a custom performance chip upgrade, but in order to negotiate race-track turns at high speeds, it needs to be built from the ground up for high performance.

Level 4: Microservices—the Nirvana State

Microservices, as the name suggests, is an architecture in which the application is a collection of small, modular and independently deployable services that scale on demand to meet application workload requirements. These services are usually architected either using container and orchestration technologies (Docker and Kubernetes, or AWS, Azure, and Google container services) or serverless computing (AWS Lambda, Azure Functions, or Google Functions).

The reason this level is regarded as the “Nirvana State” is because applications built on microservices architectures are ultra-scalable and fault tolerant, ensuring an ultra-responsive and uninterrupted end-user experience of the application. Organizations can distribute smaller services to nimble DevOps teams, which run independently and enjoy the freedom to innovate faster, bringing new features to market in less time.

It requires a big commitment, though: a company must either rearchitect its applications from the core, or write all new applications with the microservices approach.

While these granular services offer many benefits, and the individual services are simpler to manage, combining them into broader business applications can get complicated, particularly from a monitoring and troubleshooting standpoint.

Where DevOps Fits In

Although this maturity model explores cloud adoption through a technology lens, organizational evolution is absolutely critical to the success of the adoption journey. Moving from siloed Dev and IT organizations to a more DevOps model is absolutely critical for achieving all the benefits of the higher levels of maturity.

A DevOps team generally consists of 8 to 10 people, including developers and site reliability engineers (SREs). Each super-agile team is responsible for only a few services, not the entire application. Teams take great pride in the responsiveness of their services, as well as the speed at which they deliver new functionality. The key tenet here is: You build it, you own it, you run it! That’s what makes DevOps different from the traditional Dev and Ops split.

Nirvana Takes Time—and Hard Work

Cloud adoption is a journey where the adoption of microservices on cloud platforms (public or private) can lead to greater agility, significant cost savings, and superior elasticity for organizations. The road may seem treacherous at times, but don’t get discouraged! Everyone is on the same path. The global IT sector is poised for another year of explosive growth—5.0 percent, CompTIA forecasts—and is embracing fast-paced innovation. Taking a considered approach and adopting DevOps practices is the fastest way to achieving the Nirvana State.

Learn more about how AppDynamics can help you on the path to cloud maturity.