devopsy.kinsta.cloud

Tag: apm

DevOps Chats: Jim Gochee, Chief Product Officer, New Relic

In this DevOps Chat we speak with Jim Gochee, Chief Product Officer, New Relic. In his role at New Relic, Jim has seen years and years of evolution in digital transformations. Jim and I spoke about a number of topics including about how to succeed with DevOps, the rise of SRE and APM. Great discussion all around.

As usual, the streaming audio of our conversation is below, the transcript follows that. Enjoy.

Audio

Transcript

[su_pullquote align=”right”][su_custom_gallery source=”media: 122025″ link=”post” target=”blank” width=”200″ height=”200″ title=”never”]Jim Gochee
Jim is New Relic’s Chief Product Officer, overseeing the teams that design, build, and deliver New Relic’s products. He has a passion for building world-class products and loves technology – especially when it’s well architected, scalable, and fast. He takes great pleasure in helping New Relic’s customers analyze their technology and build great digital experiences. Prior to New Relic, Jim was the Chief Architect for the Wily Technology division of CA, where he was the technical lead for Introscope, an industry-leading web application performance monitoring solution. Prior to that, he was Chief Technology Officer for an internet-based trading system for the wholesale food industry. Jim also spent four years at Apple, Inc. and three years at Connectix Corporation working on VirtualPC. He holds an A.B. in Computer Science from Dartmouth College.[/su_pullquote]Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud and you’re listening to another DevOps chat. Today’s DevOps chat features Jim Goci of New Relic. Jim, welcome to DevOps chat

Jim Gochee: Hey, Alan, how are you? It’s good to be here.

Shimel: Thank you, it’s good to have you here. So, Jim, let’s get some stuff out of the way here, a little housekeeping. What exactly is your role at new relic?

Gochee: Yeah, Alan, so I oversee all of product development and that includes engineering, product management, design as well as operations. So pretty much the whole shooting match.

Shimel: Fantastic. And Jim, I was talking to you off-mic before we started today, we haven’t done a good job frankly of covering New Relic at devopsy.kinsta.cloud but when we first launched, which is going on five years ago, New Relic was already a well-established player in the DevOps market and is certainly even more established now.

But why don’t you give our audience maybe just a quick little history to bring us up to where New Relic is today.

Gochee: Yeah, absolutely. We’ve been around actually for ten years, Alan. So we just had our tenth-year anniversary party just a couple of weeks ago if you can believe that. So, 2008, and when we started, we were focused on Ribyon Rails, monitoring the backend services, grew the product portfolio over time to include other languages.

But mostly sold to small companies, startups, companies that got bigger like Air B&B. But really, it was a couple years ago we started to pivot more into the enterprise and that was a very exciting time for us.

We were already getting pulled into bigger and bigger companies at a project level and then we found ourselves being kind of drawn in organically to more and more groups to the point where these big companies were wanting to have more of a formal relationship with us, from a sales perspective.

So we built out an enterprise sales team and have been really focused there. So maybe, in one way, while you haven’t seen a lot of us in the last couple of years as we’ve been pretty heads down, focusing on the needs of the enterprise market. But what I’ll also say is we’ve been releasing a lot of product as well in the last a couple of years and the biggest thing that we did is we rounded out our offering to include an infrastructure monitoring component.

And that really complicates, not complicates, but it complements our offering at the application layer as well as the end user layer. So at this point, we have a pretty comprehensive portfolio of offerings that cover that full stack.

Shimel: Very cool, very cool indeed. So Jim, I would imagine in your role around product and everything you’re doing at New Relic, you get to talk to more than a few customers, yeah?

Gochee: Well, I do and I just feel so blessed, Alan, because this is an incredible time to be in technology. So I’ve seen a few really interesting times in tech. I think the first was when the Internet really started to get mainstream, back in the mid-’90s, but what’s really interesting now is this thing that you hear a lot about which is digital transformation.

And we all feel it, which is we want a relationship with the companies that we do business with, we want a relationship via our mobile phones or the web browser. And so a lot of companies are trying to figure out how do they have that new customer relationship, right? And how do they come up with new ways of engaging with their customer?

And then, of course, again, companies like Air B&B completely rethinking business models, companies like Uber, and so it’s just a really fascinating time to be in the tooling space that supports and assists a lot of these digital transformations that are going on. So, yeah, we definitely see a lot of interesting things.

Shimel: Excellent. So, Jim, one of the themes that we have run into here recently at devopsy.kinsta.cloud is this idea that somehow people thought digital transformation and DevOps transformation was gonna be easy. And they’re a little bit taken aback.

You know, you speak to them, the first kind of foray into it it’s like, you know, this is hard. And I feel like saying no one promised you a rose garden, right? If it was that easy everyone would be doing it already. Are you seeing any of that?

Gochee: Well, you know, Alan, in fact, we do see a lot of that but I would say is this, I guess I see the full continuum. I see the early adopters and the enterprise to DevOps. I mean, DevOps, you guys have been around for five years and we’ve been doing it for 10 and it’s early to do when you start a company that way.

In other words, when you start a company and you have a DevOps organization already, it’s easy to grow and keep doing that. But when you’re a traditional enterprise and your operations team is very siloed from your development teams, to bring those two together is a pretty big task, right? And you hear a lot about the cultural challenge involved, and that’s very real.

The thing I’d like to ask, the question I ask when I go into one of our customers and I’m not familiar yet with really where they’re at in the journey, I ask them one simple question. Who takes pager call? And if it’s still the operations team that’s taking pager call, then normally they’re still complaining that the developers don’t care, the developers are very isolated, and you see those silos still in place.

And it’s really not until a development team, then with the help of operations, people like SREs embedded on that team, it’s really not until that happens where I would really see the crossing of the chasm into more of a true DevOps model.

Shimel: Absolutely. You know, you mentioned SREs, Jim, and that’s another area where we’re just seeing it, man, it’s blowing up, right, in terms of companies hiring SREs, incorporating SREs on to their ops team. Many people have gone as far to say SRE puts the ops in DevOps. What are your feelings around the SREs and that?

Gochee: Well, what I like about the SRE role is Google wrote a book about what they believe it is. And so while that probably just applies to Google and nothing’s ever as perfect as it seems, they clearly define these are the things that this role does.

And this is why these things are important, and it’s a real philosophy and it’s a real mindset, and they wrote it down and these are all things that other people had been doing in various ways. But I think the SRE role, it got really clarified what exactly it is.

And so I am starting to see this more and more as well, and it’s not like SRE is a new concept; again, Google’s been doing it for a very, very a long time but I just feel like it’s kind of catching on.

I can tell you ourselves we’ve been doing DevOps for a long time but just in the last year, we’ve really formalized around SREs as well and we got a vice president of site reliability engineering, we converted people’s titles over, we got really crisp about exactly what are you doing.

We’re trying to figure out right now whether central versus embedded or a hybrid of the two approaches, so you know, how to organize SREs and how do they really attach into development teams? There’s still plenty of work to do even that we’re looking at, but I think this is helping the industry really figure out a model that they can work with.

Because that’s the biggest thing I see, Alan, is people want to transform to be more agile into DevOps and to use the Cloud, but they don’t really know how to do it, right? They don’t really have a good playbook for it yet.

Shimel: I agree with you 100 percent. It’s interesting you guys are eating your own dog food with that.

So, Jim, in many ways, New Relic, sort of, if you will, pioneered what we call APM, you know, and we recently did—it got too big but it was a DevOps tools primer, just trying to at least draw it so that the taxonomy of categories—and certainly APM, but APM itself has become so intertangled in this whole software development life cycle. Is that still where New Relics thinks they play?

Gochee: Yeah, so it’s a great question. We like to say that we’ve democratized APM; in that, we created a service that anybody could subscribe to, download our agent, install it into an application code, relaunch your application and now you’ve got your data showing up on our screens.

The technology around APM, though, has been around a lot longer but we were the first to bring it to everybody in a very transparent selling model, right, and again try it before you buy it. And we have by far, in a way, the most users in this APM category. These categories are funny things though, yeah, applications here but there’s also end user, there’s synthetics, now there’s infrastructure tier.

It’s all kind of collapsing and probably the markets sort of get renamed after a while. One of the things that we like to say that we think we have is a digital intelligence platform, digital intelligence just means data about everything that’s part of your digital system, all the code running, all the infrastructure that’s running.

And so at the end of the day, if you want to be agile and deploy a lot code and make a lot production change, you need to have data that tells you that things are still working correctly about all the different pieces of your infrastructure, right?

And without that data, you’re flying blind and so, flying blind, it’s okay if you deploy code once every six months, you can fly blind for a little bit while you sort out any issues. But if you’re deploying code every day, you’ve got to have real-time data about what’s happening in order for that to be successful.

Shimel: Sure do, sure do. And Jim, when we talk about the move to the enterprise, I think that’s one of—not that startups or non-enterprise customers don’t use data or that they do fly blind. They don’t. That’s not the case at all. But when you go to the enterprise and you start thinking about enterprise-class functionality, right, is when you start realizing what—really, things have got to be locked down, right?

There’s got to be sort of—I mean, sometimes it can be overprocessed and overcomplicated but you can’t just fly by the seat of your pants as much. And I think products like New Relic, they can’t help but bring some of that regimentation to a company.

Gochee: Absolutely, no, I mean your point’s really well-taken. When you’re a smaller company, you can take more risk, you don’t have to do things the right way, you know. That’s common. When you’re bigger company, you have a lot more experienced people who are used to having better tooling, better processes, better governance, right?

Because there’s a lot at stake. I mean, these are some of the largest companies in the world who are betting their future on their digital projects, and those projects have to function and they have to work. So, I don’t know, can I tell you one story, Alan?

Shimel: Sure.

Gochee: It’s a few years old now but do you remember when healthcare.gov first launched?

Shimel: Yes, I do.

Gochee: It first launched and the thing didn’t really work. It was hung and broken and the president was like apologizing to the nation, right? This is an example of we looked at each other and we’re like this is the highest-profile example of a web project gone awry.

Shimel: [Laughs]

Gochee: Yeah, right, I mean the president has to apologize for poor web performance and –

Shimel: At least we had a president who apologized then, but go ahead.

Gochee: That’s another story altogether.

Shimel: That’s a whole other story.

Gochee: The president brought in a team from Silicon Valley to help fix that site. I forget Mikey’s last name from Google. Anyways, they brought New Relic in and then we gave them the data to help sort that out, and then from now on, we have been the tool of record for how that system has been performing. And they’re just 1 of 15,000 customers that we have.

Shimel: Interesting. But that’s a classic example of it, too. That was done probably, frankly, without the necessary requirements in laying it all out there. Jim, let me ask you a question. From your catbird seat, what do you see at the future of the market here?

Gochee: Yeah, so just in terms of digital transformation and digital customer experience, that’s absolutely gonna be powering the whole economy and tech sector in particular for the next five to ten years. Cloud, the move to Cloud, the opportunities you can get by some of the Cloud services.

In particular, Amazon is really blazing the trail in just the sheer number of services they offer the market, changing how people can build and deploy software, it’s incredible. So we see a continued explosion in software and digital experiences, and then that drives companies like us, we offer tooling in this area that really helps companies move more quickly, have a better customer experience. And so I mean, I think the whole category of tech and DevOps and Agile and tooling, observability is a trend, SREs, all of this is gonna continue to have a lot of strength and a lot growing over the next five or ten years. I just absolutely believe that.

Shimel: Excellent, Jim, as I mentioned to you, when we first got started here, 15 minutes goes really quick. I think we’re probably closer to 20 at this point but it’s okay. Maybe we can have you back on here at New Relic and a DevOps chat because we would like to stay on board with everything that’s going on there. But in the meantime, thanks for being a guest on this episode of DevOps chat, Jim.

Gochee: Alan, it’s been enjoyable, thank you so much for having me. I’m happy to come back on as well

Shimel: Absolutely, we’ll make you a regular. Hey, that was Jim Gochee, Jim runs products and a bunch of other things over at New Relic and this was another episode of DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud. I hope to see you soon on another chat soon, everyone. Take care.

— Alan Shimel

April 9, 2018
How APM Benefits DevOps

Thanks to the efforts of DevOps teams, rapid application and feature development are increasing the pace of innovation and having an increasing impact on business revenue. Top-performing DevOps teams are key contributors to year-over-year revenue growth of 25 percent or more, according to Enterprise Management Associates (EMA), thus increasing the value of IT. Application performance monitoring (APM), when used throughout the development life cycle, is a significant contributor to the success of these top-performing DevOps organizations.

APM: Not Just for Production Anymore

Frequent application changes, virtual environments, complex infrastructures, distributed data and cloud services are making production apps more difficult to support. We all know that it is cheaper to catch and fix bugs and performance problems earlier in the development process. Yet, 70 percent of organizations still use a collection of disconnected, manual troubleshooting processes, and they rank this manual troubleshooting as the single biggest bottleneck in their continuous delivery pipeline. According to EMA research, “APM solutions can substantially mitigate the challenges generated by high rates of production change.”

Say, for example, a piece of code is running slowly during development or QA. The assumption that it’s the code’s fault triggers a rewriting process that doesn’t ultimately solve the problem, delays feature delivery and may introduce new issues. Details available from APM show that an underlying dependency, such as the Java Virtual Machine, is becoming saturated by a completely different process—details that are very difficult to correlate with silo-based tools and manual processes.

There is a saying that you can’t manage what you don’t measure. While many organizations use APM to measure the performance of production environments, shifting application performance monitoring left into the development environment enhances application performance and stability. Using APM throughout the development life cycle helps teams track down elusive performance problems, enabling earlier debugging of performance bottlenecks, higher confidence of achieving production SLAs and enhanced insight into feature adoption.

Earlier Debugging of Bottlenecks

Using multiple, domain-specific performance monitoring tools ends up trapping critical information in different silos. Consequently, troubleshooting potential issues is very resource-intensive, requiring experts from multiple domains to analyze the outputs and correlate the results into something actionable. Developers are pulled into production troubleshooting more often, slowing the pace of innovation and delivery. Mean times to repair get longer and longer, impacting SLAs and overall user experience.

Testing application performance during development, using the same tools that monitor the production application, helps identify bugs and bottlenecks when they are cheaper and easier to fix. Analytic features trace transactions from user to back-end, detecting potential load problems. Real-time, code-level diagnostics understand dependencies and watch all components, including containers and microservices, exposing code, SQL, networks, system resources and web services to detailed evaluations. Barriers between silos become transparent, improving communications and reducing time to resolution of issues that cross team or department boundaries.

Higher Confidence of Achieving SLAs in Production

Performing QA tests with unintegrated legacy tools is still a common practice in many organizations. These tools are often tied to physical concepts such as servers and networks, not the highly transient and virtualized production environment of clouds, services and VPNs. As a result, teams struggle to get a clear picture of potential issues under real-world conditions. Developers again get pulled into production troubleshooting, working to reconcile development and QA data and results with the production APM system.

Including application performance monitoring during automated load testing gives DevOps a better prediction of code behavior in production. Performance analytics that cross all infrastructure components quickly validate the desired production SLAs. REST APIs make it faster and easier to collect and analyze APM data, thereby improving collaboration between teams during troubleshooting. Some APM tools can automate the correlation of logs to application activity, removing the need for manual correlation and speeding problem identification and resolution. Overall, instead of guessing at the relationship between testing and production performance, application performance monitoring provides better simulation of real-world conditions, improving confidence and reducing time to deployment.

Enhanced Insight into Feature Adoption

Deploying apps more often, with better performance and stability, only leads to enhanced digital experiences if customers like and use the new features. Users do not always behave as expected, even with thoroughly researched enhancements. Focusing on metrics such as availability and response time, while important, means missing out on useful information. Without understanding the details of end user adoption, IT is unable to quantify a new feature’s contribution to revenue, productivity, satisfaction and other valuable business objectives.

Continuously monitoring user experience is essential to getting timely insights on usage trends, response times and overall user satisfaction. For instance, identifying high- and low-performing features or the most- and least-used capabilities enables better road map planning. For applications with a broad and global user base, segmenting by different groups or geographies can help pinpoint local problems (e.g., within a particular country or a subset of users), which helps DevOps teams fine-tune their apps in even the most distributed and challenging of environments. And by viewing detailed performance graphs of critical transactions, teams can quickly understand financial and productivity impacts, helping them prioritize open support tickets and application optimization efforts. Overall, user experience monitoring helps shift the DevOps team from a reactive to a proactive approach to ensuring performance.

Managing the Digital Experience

Customers and employees have high expectations of their digital experiences that must keep pace with their changing needs. DevOps practices help address these evolving customer expectations. But while frequent releases are great for the business, they are often hard on IT.

To be successful, DevOps must strike a balance between velocity and stability. However, delivering the combination of innovation, performance, and availability is a significant challenge for IT. Puppet’s “2017 State of DevOps” report states that stability (mean time to recovery and change failure rates) varies significantly between top-performing and lower-performing organizations, and it is only getting worse. Increasingly complex environments, containers, microservices and other dynamic components are difficult to monitor with traditional performance monitoring techniques.

The performance benefits enjoyed by the leading organizations are substantial. According to the Puppet report, these top-performing firms spend 22 percent less time on rework or unplanned work, deployments are 46 times more frequent, and mean times to repair 96 times faster. The inevitable result is faster innovation, better responsiveness to user issues and significantly higher customer satisfaction with the digital experience.

Integrated application performance monitoring is an essential tool that enables collaboration across IT specialties, reducing or eliminating the finger pointing and other unproductive behaviors that show up all too often in organizations with operational silos. In addition, APM improves visibility across highly dynamic infrastructures, making it possible to quantify financial impact over time and across releases. Lastly, when issues do arise, APM can help rapidly troubleshoot complex issues in production, often before they negatively impact the business or user’s digital experience.

Application performance monitoring in DevOps is the modern choice of innovative organizations that want to deliver the best digital experiences to their customers, without having to choose between speed and quality.

— Steve Brar

February 8, 2018
LightStep Unveils APM for Microservices

Various forms of application performance management (APM) platforms have been around for some time. But with the rise of microservices many IT organizations are discovering that legacy APM platforms were not designed to handle the volume of software modules or the rate at which those modules are updated. But LightStep, a startup founded by former Google employees and flush with an additional $29 million in funding, is positioning itself as the first APM written from the ground up for microservices environments.

LightStep CEO Ben Sigelman says regardless of where software modules and components get deployed, LightStep [x]PM is capable of monitoring and troubleshooting performance issues across all web and mobile clients, monoliths and microservices.

Most of the demand for LightStep [x]PM, he says, is being driven primarily by microservices based on containers such as Docker. But the APM platform itself can support both microservices and legacy monolithic applications. That creates an opportunity to rationalize APM platforms as organizations make the shift to microservices while continuing to need to support existing legacy applications running in a production environment, Sigelman says.

Twilio, Lyft, Yext, GitHub and DigitalOcean are already using LightStep [x]PM, which traces its roots back to Dapper, an always-on distributed tracing system that Sigelman developed at Google in production environments. A decentralized architecture enables LightStep [x]PM to continuously analyze 100 percent of transactions across all services. A statistical engine is then employed to detect anomalies, which the APM can then record and replay as part of an end-to-end tracing capability based on OpenTracing, an open API standard co-created by Sigelman and others that has now become a project administered by the Cloud Native Computing Foundation (CNCF).

Other capabilities embedded within LightStep [x]PM include support for service mesh and load-balancing technologies such as Envoy, linkerd, nginx and haproxy.

With every new era of enterprise computing, a contest occurs between startup companies such as LightStep and incumbent providers of technology platforms. LightStep is clearly trying to fill a void before incumbent providers of APM platforms can add support for microservices. Incumbents occasionally rely on their own organic efforts to upgrade their platforms, but more often they buy a startup company and then spend several years trying to unify disparate code bases.

Of course, there are many organizations that are just beginning their DevOps journey. Many of the them may not have any kind of APM platform in place. Most tend to be cost-sensitive as well, so offerings based on open-source code tend to have greater appeal.

However the APM wars play out, it’s apparent they are about to enter a new phase. The winners and losers of those wars will be determined by DevOps teams rather than C-level IT executives trying to impose a framework from on high. After all, if IT organizations have learned anything in the last few years, it’s that DevOps tends to have a more lasting impact when it comes from the bottom up.

— Mike Vizard

November 30, 2017
The Need for Speed Demands New-Era APM
Applications have become the primary conduit by which customers experience a brand, making the application experience critical to business success. As such, continuous delivery and highly available systems that deliver optimal end user experiences at lightning speed have become top priorities for organizations. Modern IT is all about speed, efficiency and customer experience. Simply put, companies that develop new applications and services the fastest will win.

That’s where containers and microservices come in. Containerized microservice applications enable organizations of all sizes to approach the ultimate goal of continuous integration and continuous delivery. This accelerates everything within the application life cycle, from initial development to component updates and new functionality.

To match the development speed that microservices and containers enable, Ops teams need tools that can also operate hyper-fast, providing an immediate understanding of the impact of changes made, real-time analysis of vast amounts of data across applications and technologies, visibility across a range of languages and infrastructures, and knowledge of how the application is performing for end users.

In fact, we are at a critical inflection point in application performance management (APM), where a generational shift is needed to keep pace with the new hyper-dynamic application architectures consisting of microservices, containers and hybrid cloud environments. To fully understand the impact of this shift, we can examine the genealogy of APM.

APM Evolution

The first generation of APM, established at the end of the last century, collected statistics and metrics out of system and application components, providing a first generation of user-defined transaction profiling by using instrumentation technology. APM 1.0 required a lot of effort to implement and maintain, but helped to monitor and analyze the performance of newly developed 3-tier applications.

The second generation of APM was driven by more distributed, service-oriented architectures (SOA) and the rise of more elastic, virtualized or cloud-based infrastructure. APM 2.0 added application topology discovery and could analyze distributed applications. User experience monitoring of web and mobile apps quickly became part of APM 2.0 as more businesses depended on the service quality of their applications. With a primary focus on application monitoring, not management, APM 2.0 required an even broader set of subject matter experts to configure and interpret monitoring data from dashboards and reports. Similar to APM 1.0, the second generation still required way too much human analysis and setup to fully understand application problems and derive actions.

The continuous change in today’s modern dynamic applications makes it difficult, if not impossible, for those older tools to keep up. Throw in additional architectural challenges such as hybrid clouds, containers and orchestration (such as Kubernetes and Mesosphere) and the picture gets murkier, all in the name of high-speed delivery. Meanwhile, the microservice architecture and development strategy spawns wide technology diversity—each engineer can choose the programing language, middleware and databases best suited to code their individual microservice. Scale, complexity and constant change is the new reality for today’s dynamic applications.

Wanted: A New Breed of APM

In this environment, traditional IT monitoring tools won’t work. These new applications use a vastly larger set of technologies, must scale dynamically and are in a constant state of flux.

In this effort to engineer for speed and efficiency, complexity and scalability have increased exponentially, requiring continuous monitoring and more visibility than ever before. As organizations embrace agile methodologies for development and containerized microservices for deployment, developers have shifted their thinking in technology choices. Developers now continually select the most optimal technology for their individual goals regardless of DevOps’s ability to configure, deploy and manage the specific technology.

With several teams across the enterprise constantly publishing new software releases, understanding the impact of these new releases and changes to the overall environment has become a significant challenge. Today there is no single source of truth assisting communication between various organizations, resulting in what seems a wild west–like environment for IT. With so many groups and technologies in play, everybody seems to be speaking a different language, especially when it comes to delivering high-quality applications. In this environment, a new breed of APM is needed that can provide a “Truth Machine”—complete with deep visibility across all application components in the technology stack.

This new breed of APM must be automatic and dynamic to deal with the ever-changing world of applications running in containerized microservices. To deliver these critical capabilities, the tool must provide real-time visibility into dynamic, containerized, microservice applications, regardless of language or infrastructure. New thinking is required to meet the challenges of these complex, large and dynamic application environments; a new monitoring and management approach that can handle dynamism by:
- Delivering real-time analysis of vast amounts of data across all applications and technologies.
- Conducting continuous discovery and automatically mapping every component, host and container, (hosted on-prem, private cloud, public cloud), to the exact architecture of complete technology stack.
- Visualizing the application architecture and delivering actionable suggestions that assure the operational health of systems and applications.
- Providing real-time accuracy to visualize, structure and identify problems immediately.
- Monitoring the complete set of diverse technologies that run in microservice environments.
- Operating in a heterogeneous environment and automating deployment across nearly all programming languages.
Artificial Intelligence for Next-Generation APM

DevOps and IT organizations are struggling to match the speed of agile development, and this is creating exponentially more challenges around new application architectures. The only constant in these modern application environments is change. Whether change is due to microservice architectures, container orchestration or simply more agile delivery execution to effectively manage microservice applications, DevOps needs up-to-date visibility, a precise picture of the application’s structure and an immediate understanding of its health. To accomplish that, DevOps must be able to apply artificial intelligence to the act of monitoring modern dynamic applications.

Rather than spending time configuring and reconfiguring monitoring tools, organizations must automate management steps with as little human setup and configuration as possible. To have complete control and visibility of their environments, regardless of language and infrastructure, organizations must use a modern application management solution that is automatic and AI-powered to deal with the ever-changing world of dynamic containerized microservice applications.

About the Author / Pete Abrams

Pete Abrams is a co-founder and the chief operating officer at Instana, the leader in application performance management for containerized microservices applications. Formerly vice president of customer centric innovation at AppDynamics, Pete has spent more than two decades in the technology industry focused on introducing new products to market and ensuring customer feedback and desired capabilities are incorporated into future product innovation. Connect with him on LinkedIn.
October 27, 2017
New Relic Extends Monitoring Reach

New Relic this week at its Future Stack 2017 conference extended the reach of its monitoring services via the release of a software development kit (SDK) that makes it possible for IT teams to monitor custom applications.

In addition, New Relic unveiled Health Map, which makes it much easier for IT administrators to correlate data collected from New Relic application and infrastructure monitoring services. Todd Etchieson, vice president of product management for New Relic, says developing Health Map was a natural next step after the expansion of its services into the realm of infrastructure monitoring. That capability should significantly reduce the finger-pointing that often occurs between developers and IT operations teams anytime there’s an application performance issue, says Etchieson.

New Relic is also adding billing and cost management features that enable customers to monitor costs in real time as well as plan for future Amazon Web Services (AWS) resource requirements. Rather than having to invoke a separate tool, users can leverage New Relic’s extensive history of relying on AWS to host its tools.

Application performance management (APM) tools from New Relic first gained prominence among developers who preferred to monitor their applications using a service. Because New Relic is deployed on AWS it’s especially well-suited to monitoring applications deployed on AWS. The company this week also announced that its monitoring tools now come with 20 pre-built integrations to AWS services including Amazon Kinesis Firehose, Amazon Elasticsearch Service, Amazon Route 53, Amazon EC2 Container Service and Amazon EC2 Container Registry.

Now Etchieson says New Relic is expanding its reach in the enterprise as organizations embrace a more integrated approach to DevOps. In fact, he notes half of its customers are already consuming multiple services. Driving that adoption is a need to roll out more applications, many of which are based on microservices enabled by containers. This fact is forcing organizations to confront their DevOps issues because of the dynamic and ephemeral nature of containers. New Relic added support for container monitoring back in 2015.

Etchieson says New Relic doesn’t necessarily care where IT organizations choose to deploy their applications. Because New Relic made its APM software available as a service, use of APM expanded considerably. The company currently has 1,700 enterprise customers, he says.

Not all those customers are very far down the DevOps path, but more than a few organizations have begun their DevOps starting with an APM tool. In fact, in many organizations DevOps is a bottom-up transformation that begins with developers seeking more information about how their applications are performing.

As DevOps continues to evolve, the divide between application and infrastructure performance monitoring tools will continue to narrow. There may be different roles inside an IT organization that require different views to address specific issues. But at its core DevOps is all about providing cross-functional IT organizations with the context needed to resolve issues faster. In almost every case, that will require correlating data across both the application and infrastructure stack.

— Mike Vizard

May 26, 2017
The devopsy.kinsta.cloud Application Performance Management Leadership Links Guide

Businesses today are largely defined by the applications they run. And to stay competitive enterprises must continuously update their software and performance issues must be identified and solved swiftly.

This drive toward more rapid software iterations and enterprise development and IT management efficiency is one of the biggest reasons why more companies have embraced DevOps and continuous integration and deployment pipelines.

But how do enterprises make certain they can continuously deploy and delivery new software apps and features and not inadvertently impact user experience? Precisely how are mistakes and failures, or app performance issues quickly identified and remedied? How are application issues managed so that there aren’t costly outages or development teams aren’t getting texts in the middle of the night for emergency software change requests? This is where application performance management (APM) comes in.

According to the market research firm Markets and Markets, the APM Market is expected to reach nearly $5 billion by 2019, up from $2.72 billion in 2014.

There is a significant intersection between DevOps and application performance management. It’s also essential for application management teams, development teams and operations teams, and needs to be integrated in many DevOps processes. In this devopsy.kinsta.cloud Survival Guide, we provide resources to help you to get the skinny on using application performance management to help more tightly integrate Dev and Ops, find the right APM tools and successfully manage today’s more complex environments with application performance management.

APM Prepares Prep Sportswear for Promising Growth – devopsy.kinsta.cloud

In this story, David Geer looks at how custom sportswear vendor Prep Sportswear is using APM to prepare for growth

14 Tools That Raise Web and App Performance – devopsy.kinsta.cloud

Asaf Yigal lists his 14 Tools That Raise Web and App Performance

Gartner Evaluates APM Tools for DevOps – devopsy.kinsta.cloud

Grab this Gartner report on APM toolsets.

5 Ways APM Can Solve Your DevOps Worries – devopsy.kinsta.cloud

To have tight control over Devop’s environments we need APM at every step, contends this post by IBM’s Payal Chakravarty. APM can help break down the Chinese wall between Dev and Ops and eliminate the finger pointing that happens during outages. Here he lists five APM best practices to enable a smooth DevOps working environment.

Continuous Monitoring: The Role of DevOps and APM – devopsy.kinsta.cloud

IBM’s Arun Biligiri discusses the intersection of DevOps and APM.

APM On-Premises or SaaS: What’s the Best Fit? – devopsy.kinsta.cloud

Which APM deployment option makes most sense for your organization? There‘s no simple answer to this question. A lot depends on your environment and requirements. This post explores the points to consider in deciding between SaaS and on-premises monitoring.

Webinar: Using APM to Turbocharge Continuous Integration – devopsy.kinsta.cloud

Check out this Webinar with CA Technologies and CloudBees to learn how APM can Turbocharge CI.

Can Your DevOps and APM Initiatives Increase Customer Loyalty?

Can APM help to increase customer loyalty, CA’s Peter Waterhouse thinks so.

— George V. Hulme

April 14, 2017
DevOps Chat: The Evolution of APM with Jonah Kowall, AppDynamics

In this DevOps Chat we speak with Jonah Kowall, VP of Market Developments and Insights at AppDynamics. Of course prior to that Jonah was a VP of Research IT Operations at Gartner. Jonah actually gave us a great overview of the evolution of APM and how the market has evolved. He also tells where we might be heading now.

It is not often you can get the lay of the land from an expert like Kowall, so I highly recommend you give this a listen.

As usual, immediately below is the streaming audio of our discussion and below that is the transcript of our conversation.

Streaming Audio

Transcript of the Conversation

Alan Shimel:                Hi, everyone. Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat. Our guest on this episode of DevOps Chat is Jonah Kowall of App Dynamics. Jonah, welcome to DevOps Chat.

Jonah Kowall:             Thanks, Alan. Happy to be here—great to speak with you and everyone else listening.

Alan Shimel:                Thank you. So Jonah, before we jump into App Dynamics, you have a—you’ve had a bit of a career already. Why don’t you share with our audience a little bit about kinda your journey to how you got here today?

Jonah Kowall:             Yeah, definitely. Well, I always knew I wanted to be a technologist and, for many years, I worked at about six or seven different startups. I co-founded one of the first content filtering companies back in the early 2000s and, you know, got acquired a couple of times.

And I kinda shifted careers a few years ago, about seven years ago, and moved into the analyst world and kinda moved away from running ops and security and infrastructure and application performance and decided to take the analyst path, and did that for about four years, which was very interesting and different, learned a lot of new skills, a lot of new muscles were built.

And I joined App Dynamics a little bit over two years ago, and I work with our       co-founder and CTO running product strategy. I do a little bit of marketing, but quite a bit of product management and kind of looking into where we’re going as a company to solve the next generation of problems that we’re starting to see in our customer base.

So that’s a little summary of where I came from and however you’d like to take it is great.

Alan Shimel:                Sure. I guess the real question is, do you know where you’re going, but we’ll come back to that in a second.

Jonah, as I spoke to you offline about, I wanted to talk to you a little bit about what I have seen, you know, as an observer of the market at devopsy.kinsta.cloud. In terms of the evolution of what used to be just a few years ago, a very kinda stable space called APM, right? We had, the APM space had a handful of players—App Dynamics was certainly one of them—who were, by the way, all doing pretty well, it seemed.

And what we’ve seen in the last few years is, you know, in the—first of all, more people joining the fray, but more than that, in the race to distinguish one from the other, many players within this space are kinda rephrasing their mission, their—not running away from APM, but their APM plus, maybe. And so we’ve seen, you know, alphabet soups of ARAs and a whole bunch of different combinations.

What’s your take on that, Jonah?

Jonah Kowall:             So, when you look back—and, you know, when I started at Gartner, there was a lot of confusion around application performance and application monitoring. And there was like a general belief that anything that monitored some kind of application or even monitored the network and tried to extract application information was, in fact, APM.

And what I kind of tried to do in my time at Gartner, and I think it sort of changed some things, was really focus APM on instrumentation of applications. So, how do we see the code, how do we get inside the application, how do we trace from end to end and really provide that visibility and the diagnostic capabilities that are really gonna be needed in today’s applications, which are incredibly complex and diverse, and consist of a lot of new technologies?

So, building that kind of visibility is really hard to do. I mean, if an APM company—and there are plenty of them that have started over the last couple years—they have many, many years before their instrumentation becomes decent, if they’re even going down that path. And the ability to extract information from a running application, without breaking it, is very, very difficult to solve. It takes a lot of time, a lot of experimentation, a lot of work with customers.

And so this market is very hard to enter into and compete with the three leaders in the space. It’s just a big challenge, and you’re looking at five to six years before these things mature, if they continue to pursue them. So what you’re kind of seeing, and what you alluded to, is that companies are trying to take a different angle and avoiding the deep instrumentation and just trying to provide SVKs and tools for developers to build those, you know, that visibility. But it’s a big challenge, because in enterprise and packaged applications, those products don’t work, and that’s really the challenge that I continually see out there when I observe the industry.

Alan Shimel:                Got it. So, you know, certain—I’m sorry, Jonah, I have a little tickle. App Dynamics, you know, in, let’s call it an immature industry, rapidly become an 800 pound gorilla, and I think we’ve all seen the proof of that in recent news around acquisitions and so forth. But I’m not gonna go there, Jonah—suffice to say, App Dynamics is a market leader in its space.

How does this evolution, if you will, changing dynamics, you know, you said you’re working on future problems—how do you think this plays into the future of App Dynamics?

Jonah Kowall:             Yeah. Well, I think that applications and technologies will continue to evolve, and you know, we’re already starting to see a lot of new application paradigms that we’re gonna have to shift a lot of our core technology to support and to essentially leapfrog what the rest of the market is able to do, and we’re hard at work doing that.

But aside from the deep, you know, introspection of software, there is also a big push for us to really understand the business, because today’s enterprises, regardless of what they do, whether it’s extracting natural resources from the earth or building cars or providing mortgages—these companies are all software companies, and their businesses depend and are driven by their software. And our goal is really to understand the business execution and the user experience of those transactions that are critical. And, in kind of taking that to the next level is really, how do we look at the outcome of software and of these business transactions as they come together.

So, our vision is not only to increase our capabilities of the core of what we do in APM, but also to really provide a lens into the business that really provides that IT business alignment that everyone talks about and everyone struggles with today. So we really see that as the differentiator in these large enterprises that are really challenged with a lot of legacy and a huge amount of demand to change their businesses.

Alan Shimel:                Got it. Got it, got it. So, Jonah, let me pivot a little bit to, there was another area I wanted to touch on with you, and that is this whole area of containers, micro-services—but containerization. Virtually every call, every briefing that I’m on, somehow or another containers make their way into the conversation. How big a focus is it over in the, in terms of product and in terms of the strategy at App Dynamics?

Jonah Kowall:             Yeah, I mean, micro-services and containers are definitely the peak hype, let’s say, of the day—there’s no question about that. And they provide a lot of benefit, but a lot of people really feel that containers and micro-services are the answer to every problem. And this is something that we’ve seen over and over in our industry where, you know, there’s a new kind of angle to an existing set of technologies that we feel is really gonna make the biggest difference. And although containers and micro-services are both important paradigms, they’re not the answer to everything.

Our customers are clearly retooling some of their applications around a micro-services architecture, and they’re definitely running workloads on containers, and these things are important for us to support, but are they more important than, you know, building core functionality to support new languages and new frameworks and really helping our customers with their more core business problems. It’s hard to say. I mean, both are clearly critical, but a lot of it is hype, and you know, the hype obviously fades as people become disillusioned with the fact that containers and micro-services don’t solve all your problems. They create a lot of new problems, and that’s just the reality of technology.

So, as an industry, we’re very over rotated to containers, micro-services, and public cloud, and you know, we’ll soon realize those aren’t the answer to all of our problems—and oftentimes, they create new problems, as well. So, you know, I think it continues to be a cycle and, you know, I really think the evolution of cloud into a decentralized model will be a pretty interesting trend over the next, you know, 5 to 10 years as well.

Alan Shimel:                Got it. I think we’ve barely scratched the surface. You know, Jonah, I was on a call previous to this and it was around software defined storage and networking and stuff, and it just—listening to it, I had such a déjà vu of sitting back in on the VMware stuff, you know, back in, I guess mid-2005, around then.

Jonah Kowall:             Yep.

Alan Shimel:                It just seems to promise so much change for us here; it’s crazy.

Jonah Kowall:             [Laughter] It always does, and you know, it comes with challenges, always, and people become kind of disillusioned, but there are benefits to those that embrace it, do it well, and you know, have the types of problems that those technologies can solve.

Alan Shimel:                Yep. Excellent. Well, Jonah, we’re just about up on our time. I’m gonna give you a surprise question here, if you don’t mind—if you can’t answer, that’s okay.

Jonah Kowall:             Sure.

Alan Shimel:                But I usually ask, the last question I always ask my guest is—recommend one book to our audience that you really think they should read to help them with their careers.

Jonah Kowall:             That is an interesting one. I actually tend to, I do a lot of traveling. I actually flew over 200,000 miles in 2016.

Alan Shimel:                Wow.

Jonah Kowall:             So, when I actually get to read, I tend to read lighter materials, or I read very deep, technical materials that kind of help with some of the product work that I’m doing. So a lot of the books I read tend to not be too inspirational, but I do really enjoy participating in some of the open Slack communities. I enjoy reading a lot of blogs and other content that tends to be fresher.

Alan Shimel:                Mm-hmm.

Jonah Kowall:             You know, I read probably about 500 blogs in my RSS feed regularly, so that tends to really be how I get information, and I do really enjoy reading some of the Google Scholar, if you set some interesting alerts up, you can get some great research papers coming out from universities that are very interesting and forthcoming, just kind of highlighting some of the next generation thinking from the educational institutions all over the world.

So that really tends to be more what I tend to read versus, you know, something that’s more career focused, I would say, or inspirational in that manner. So sorry I don’t have the best answer, but that’s what I tend to do.

Alan Shimel:                No, no—that’s fine, and that works for us. Well, Jonah, I think we—well, we are out of time, but I want to thank you for joining us today on DevOps Chat, and I look forward to perhaps having you on again in the future.

Jonah Kowall:             Sounds great. Thanks for your time, Alan, and thanks, everyone, for tuning in

Alan Shimel:                Thank you. Jonah Kowall, App Dynamics, our guest today on DevOps Chat.

                                    This is Alan Shimel for devopsy.kinsta.cloud, and we hope to see you soon on another DevOps Chat.

— Alan Shimel

March 30, 2017
DataDog Announces APM. Why You Should Care

In case you missed it, DataDog announced it has added application performance monitoring to infrastructure and business goal monitoring.

Part of my background includes a variety of clustered systems. First VMware, then OpenStack, Hadoop and its derivatives for a while, and these days the Mesos family. One of the many things I have learned along that journey is the inter-related nature of infrastructure and application. While we all know about that relationship, it goes further, I think, than most people recognize. A single degraded hard disk or loose network connection, which pushes work back out to the rest of the cluster, can drag an entire cluster to its knees.Since my time at F5 Networks taught me a metric ton about the nature of load balancing, I can say confidently that the same could happen to your load-balanced application.

The biggest frustration for me in most multi-system configurations is the inability to track enough places to quickly diagnose the problem, because your application could be brought to its knees just as easily by a memory leak. But the logs are spread across multiple logs on multiple machines, between the hardware, OS, and software, and you generally have to go looking for more information. Even if you have some of the best tools in the business, you are still looking in multiple places to find information about one problem and having to do things like sort by time to correlate events between the systems.

To be certain, other vendors are offering hardware/OS diagnostics with their APM. But DataDog’s approach, adding APM from the infrastructure side (rather than the more common reverse scenario), will offer different insights. So I’m interested in seeing how DataDog’s offering pans out.

I obviously haven’t had the chance to play with DataDog’s new functionality, but it is a space that very much interests me and one we as an industry do need more work in. So just the fact that DataDog is integrating these three monitoring layers is important. From here, it has a platform for adding things (security monitoring? Inclusive root cause analysis?) or increasing the quality and quantity of across-the-application, metal-to-user information available to Ops and for alerting. In fact, it disappoints me that actual infrastructure isn’t a core part of the APM Conceptual Framework, because the hardware under the VM that is hosting the app server for your app really does matter when performance degrades.

At a minimum, APM can help you get from problem to solution somewhat faster. If done well, it can alert you to the problem and show you where it is, helping you get from problem to solution even more quickly.

— Don Macvittie

February 17, 2017
DevOps Chat: Justin Vaughan-Brown, AppDynamics

This episode of DevOps Chats is with Justin Vaughan-Brown of AppDynamics. This was recorded just prior to the announcement of Cisco’s intent to acquire AppDynamics for about $3.7B. So sorry, folks no insight into that deal here. Nevertheless, Justin is a DevOps veteran. While at AppDynamics for just a few months, Justin has worked and helped lead several DevOps tool and consulting businesses. He has some great insights that he shares here with us.

As usual, the streaming audio of our conversation is immediately below, followed by a transcript of our conversation. Enjoy!

Alan Shimel:                Hey everyone, Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat. And our guest for this edition of DevOps Chat is Justin Vaughn Brown of AppDynamics. Justin, welcome to DevOps Chats.

Justin Vaughan-Brown:          Thanks Alan, glad to be with you.

Alan Shimel:                Glad to have you here. Justin, you are a DevOps industry veteran, if there is such thing, in a relatively short time. But you’re hanging your hat at AppDynamics now. How long have you actually been with AppDynamics?

Justin Vaughan-Brown:          I’ve been with AppDynamics since – it was the very last day of October, so kind of two to three months in now.

Alan Shimel:                Perfect, just enough to get I guess the lay of the land there. And as we spoke beforehand Justin, and as I think most of our audience, it’s been a busy two to three months, you know, between the end of the year and everything going on in the market you’ve had a good chance I would imagine to get a flavor for not only what AppDynamics is doing but really kind of where the market is heading a little bit in terms of DevOps APM and stuff like this. Correct?

Justin Vaughan-Brown:          Absolutely Alan. I think what was very interesting was – actually a few weeks after joining – was spending time with customers and partners and colleagues at App Sphere in Las Vegas in November: that was absolutely fascinating, so that was a real eye opener in terms of how APM customers – you know, those of AppDynamics are actually using DevOps and adopting it and how they’re leveraging our technology to help them in their DevOps adoption.

Alan Shimel:                Yes, I was actually at App Sphere as you know – I was at App Sphere myself and it was a great conference and it was a great customer-focused conference in that there were a lot of users there – real live users, right? – the rare, endangered live user at these conference – not a Biz Dev first and not a sales person but real users and I had some fantastic conversations myself.

Justin, I wanted to spend a moment a little bit talking about APM because sometimes when we look at software development life cycles and kind of where the action is around DevOps you know a lot of people get all hot and bothered and hyped up around configuration management, right, the puppet and the chef and the ansible and salts and these kinds of things. And then, you know, they move from configuration management to CICD and of course that’s a world unto itself.

But then when we look at let’s say post deployment, you know, okay, so now we delivered and we’re delivering continuously, but what impact is that having? How are things going? Are our customers happy? Are we delivering better products, right, and are they performing as intended?

And you know all of these things you would think would make APM sort of king of the castle, top of the heap. But a lot of times it doesn’t: it kind of gets subsumed within the whole DevOps conversation or is maybe a little bit outside.

I’m interested in what’s your opinion on that?

Justin Vaughan-Brown:          That’s an interesting perspective and I can see where you’re coming from. I think it’s possibly because, you know, from historically a lot of the vendors are more and more what you call classically the dev side and have generated a lot of interest and adoption. But ultimately we’ve seen the company grow from strength to strength, and I think what was really eye opening was – at App Sphere – was seeing how critical app dynamics was in enterprise DevOps adoption.

And I think what most particularly – you’ve hit the nail on the head there – if you look at for example the impact of those applications in production how are they actually performing, where our issues lie, where the – the apps themselves can be fine tuned and ensure that you have the best customer experience possible.

I think in the main – and this is a generalization of course now, there are exceptions – I think we’ve gone beyond the state where applications – with the exception of certain tougher cases like say, you know Black Friday and so forth where sometimes some organizations can have challenges – but in the main I think what we are seeing is most applications perform at what I would call a base level – what we’re really now into is tuning them: is identifying absolutely the tiniest little bit of latency or glaze or issues wherever they may lie so that the performance of those applications, irrespective of where they’re delivered – you know, on a tablet or mobile device, on a PC or whatever – are highly high performance, and again, irrespective of platform, operating system or so forth – all of those – I think that’s become one of the overriding demands.

And I think it’s evolved even more so now – you know, we recently launched Business IQ which actually drills it even further and actually looks at the business benefit of the application you’ve released where a consumer’s using the application, where are they located, where are they on the user journey, where are they on the purchase cycle. And you’re finding lots of consumers are going through to about to purchase and then there’s a delay in the actual purchase process as the transaction is going through or not going through.

So I think it’s definitely evolved and I think we’re seeing certainly an absolute relevance for APM now.

Alan Shimel:                Got it. Absolutely. Justin, let me – as I said earlier you’re a DevOps industry veteran though and AppDynamics isn’t your first stop on the DevOps train.

Why don’t you, if you can share with our audience a little bit – we’d like to hear your views though on – so that’s APM and what sets it apart – what other kind of – let’s look at trends in the DevOps space and maybe how it relates to APMs.

What other kind of trends are you seeing?

Justin Vaughan-Brown:          I think one of the interesting ones that we’re seeing is – you know, you’ve seen the evolution of Docker over the last kind of 18 months to 24 months, and I think that and the overall rise of containerizations in general is having a huge impact.

I recently saw an article by a bank – folks who were going to report that they’d recently issued on the – I would say the stellar rise of containerization and adoption, and it’s almost a case of, you know, there’s no going back.

So I think it’s really down now to where you’re adopting containers and to what degree, one or another, if, for example. And that’s where we’ve seen our ability to help that; for example in terms of their integrating and monitoring docker container performance easily to ensure that you’re optimizing and maximizing the potential there and that doesn’t become a black box area where you’re not getting the granularity of insights that you’re looking for. So that’s one area definitely.

I think also, you know, with cloud adoption as well, to be able to monitor across multi cloud environments – and that’s just not one vendor only, you know – as I said multi cloud – whether it’s Amazon AWS, Microsoft Azure, and so forth.

So I think there’s a need to be, you know, platform and cloud agnostic going forward. And that’s something recently I’ve seen at analyst conferences where they talked about so many enterprises now from an operations point of view being cloud brokers and then looking at not just one vendor – not being locked in – but being able to switch and change dependent on which particular application they’re working on or initiative and so forth. So I think those are two clear areas.

                                    I think the last one probably I’d highlight is micro services where, for example, the ability with APM to automatically monitor in micro services, you know, deployed in an elastic infrastructure so you can look at issues around say threat contention and then zoom in and identify and address their root causes.

So seeing all these kind of technologies orbiting around that APM can absolutely assist in the adoption. And if you adopt this properly obviously they’re hugely advantageous. If you struggle with them then they can actually set you back and you’re worse than if you hadn’t embarked on that journey. So those are three that immediately come to mind Alan.

Alan Shimel:                And I don’t disagree with any of them Justin, I think they’re all dead on.

Let me throw another – and this might be a bit of a curveball at you – but as a fellow observer of the DevOps space Justin what I find interesting is that when we first started talking about DevOps everyone sort of said, “Oh yeah, DevOps is great for startups because it’s in their DNA and they do it by – you know, not by choice: they have to. And this is – DevOps was made for these folks.”

Where you know this whole issue of “enterprise DevOps” was almost like a different animal or a different set of stripes. And you know I was always one of the ones that argued DevOps is DevOps, you’ve got to recognize who your customer is and who your organization is, but the principals of DevOps apply across small and large organizations.

But low and behold here we are now, you know, a new year and we’re a couple more years into this DevOps thing and it almost feels like DevOps is a big organization way of doing business, maybe even more so than the startups. What’s your feeling on that?

Justin Vaughan-Brown:          I think you’re absolutely spot on Alan. I mean I think we’ve both been on that journey where we’ve observed certain trends and how the markets evolved.

And if you look at, for example, at the DevOps Enterprise Summit that took place last year in San Francisco and London – both extremely well-attended – and then if you look at those agendas on both of those the vast majority from my perspective of those presenters presenting from the end user side were representing enterprise organizations – household names – in fact if anything those smaller organizations were the minority, and equally even the – you know, there’s also I think with the larger organizations it was those that were not just the, you know, the purely kind of online shop equivalents where they’ve got no legacy infrastructure that they have to deal with: a lot of these are, you know, 50-, 100-year-old companies that have been around a long time yet are making that brave journey.

And I’d like to just kind of re-quote an observation made by Gene Kim last year when he said what really impresses him is – it makes him really think of people who are being heroes within these large enterprises, within these organizations, who are, you know, probably I’d say mid-level advanced in their career and in age and during their career who are making these brave decisions, who are doing things differently: they could carry on as normal.

And in doing so they are trying different things, they are embarking on new journeys and they’re bringing their teams with them, they’re collaborating more closely.

And I think that’s – it’s those kind of – I think Gene Kim is absolutely spot on in it’s those kinds of heroes, those catalysts to change – and I think frankly DevOps is absolutely for the enterprise and will continue to be so.

Alan Shimel:                Makes sense. Justin we’re running a little low on time. Let me turn this back to App Dynamics if you don’t mind. What are you – so we’ve talked about these trends, we see the market kind of taking shape – what does it mean for AppDynamics?

Justin Vaughan-Brown:          I think it means a lot of opportunities to continue to help the enterprise customers. Most of all I think – you know, from a personal level I’m very excited by the recent release of Business IQ because I think that enables DevOps teams now to take information relating to how that application is being consumed, where and in which way of these visual user journeys – to actually then take that information and present it to the business – and that moves it from purely a DevOps conversation to a business one just to say, “Look this is – you know, we’ve all be slaving away the last couple of months on this application. Here’s the actual impact to your business; this is what’s happening, this is the value.”

And then maybe the business turns around to say, “You know what? Interestingly sales in this region are going really well but not in this region or this group of customers, you know, our gold card member carriers are absolutely loving this promotion but our silver card holders aren’t. Maybe we need to incentivize them in some way,” you know, and so forth.

So that’s moving, as I said, the DevOps teams into a more business conversation. We know about this topic such as Citizen Developers and obviously Shadow iTeam – more and more and more the businesses are being involved in these decisions, and that’s the way for DevOps to help drive that dialogue rather than being on the receiving end and taking requests from the business, that they’re actually driving that discussion which puts them in a really good position.

Alan Shimel:                Excellent. Justin, we’re just about out of time here but I want to ask you one last question and that’s the kind of question I ask a lot of our guests here on DevOps Chat.

For our audience listening out there if you had to recommend one book – and not the usual, you know, Gene Kim Phoenix Project that you would expect from a DevOps podcast – what book would that be?

Justin Vaughan-Brown:          I think I would go back to a book and a course that I took almost 20 years ago which is The Seven Habits of Highly Successful People by Steven Covey which pretty much broke down most of everything that I knew and rebuilt it another way and gave me a fresh perspective, so I strongly recommend that.

And if you’re pushed for time I think there’s some YouTube videos where you can go in and get the canned insight in 15 minutes, so that’s well worth taking a coffee break.

Alan Shimel:                Absolutely. But that’s a classic. And for any of our listeners who have not read that one it really should shoot to the top of your list.

Hey, Justin Vaughn Brown, AppDynamics, thanks for being this episode’s guest on DevOps Chat. Look forward to having you on again soon and sharing some more market insights.

Justin Vaughan-Brown:          My pleasure. Thanks very much indeed Alan.

Alan Shimel:                Okay. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. We’ll see you soon on the next DevOps Chat.

— Alan Shimel

February 13, 2017
Cognitive Analytics: ‘Operations Thinking’ for Development
In a recent blog post by my colleague Payal Chakravarty, “Synthetic Monitoring – the Start of the DevOps Monitoring Journey,” she discussed how developers, testers and operations staff all need to ensure their internet and intranet mobile applications and web applications are tested and operate successfully from different points of presence around the world.

Continuing our five-part series on “Continuous Monitoring: The Role of DevOps and APM,” this blog post will talk about how analytics can help developers earlier in the DevOps life cycle think about the performance of their applications.

Continuous monitoring is not just about detecting operational problems in production; it is about getting feedback and reassurance that code changes you’ve made have resulted in the intended operational behavior before you deploy to production.

My career DNA is development. So I know, full well, how code changes can have unintended consequences.

Remember the bad old days when development methodologies relied on a series of quality checks (code reviews, various types of tests and release validation) to catch unintended consequences? If caught at all, most operational degradations surfaced long after the offending code was submitted, because the types of validation designed to catch these problems occurred at the very end of the development life cycle, when a “stability test” was possible. These “banana skin” issues were caught late or not caught at all. Either way, clients were impacted (through release delays, increased costs or service degradation) and you were not happy.

Continuous development was great for me, personally. It forced me to look at development in a whole new light and solve the “little and often” delivery problems. It was fun, but despite best efforts, one “banana skin” remained: the stability tests in the staging environment. Just like before, it could cause a late-breaking wobble in the delivery plan to production or, worse still, issues were missed altogether.

I didn’t solve this problem well because I was still thinking like a developer—mainly because I don’t have the skills, time or the interest to think like Operations.

If cognitive analytics are applied to operation problems, you don’t need to think like Operations to benefit from Operations thinking. Your solution automatically will learn what is normal for your application; it will set dynamic thresholds and it will proactively notify you when it becomes significantly anomalous. With cognitive solutions, you can enable operations (continuous monitoring) in staging and detect anomalies long before the stability test fails or before the application hits production! All you need to do is feed it the application metrics. The good news is, your buddies in operations can show you how to do it.

I am a positive person, so I am going to use a positive development scenario:

You have made a code change to improve the performance of your application. When the code is deployed into staging, the expected operational improvement should occur (for example, a response time metric should change for the better). If you are using cognitive solutions, this anomaly (new and unusual behavior) will be detected automatically and you will be informed.
- You get the reassurance that your code changes are having the intended positive impact on the operation of the service in staging.
- You can inform your Operations team that new, anomalous behavior will be seen and why this is actually a good thing.
- Furthermore, since these changes are intentional and the solution is fully cognitive, it will learn the new “normal” over time and the anomaly will simply go away. You do not need to take any “Operations action” such as setting a new threshold level, etc.
The reverse is true, too. If you did not expect a change in a response time metric, or any of the other operational metrics, this would surface quickly, in staging, well before a test (if it exists) catches it. You rapidly can investigate this and take the necessary action before the “banana skin” moment.

Another type of “Operations thinking” that is easily enabled in staging is the ability to alert on patterns in log files.

This feature looks for patterns in logs, in real time, as files are ingested. You create the alerts. You can include alerts for the type of symptoms Operations looks for (again, talk to your buddies—they are the experts) or better still, you know the symptoms of your application starting to fail (you have investigated and fixed enough bugs!). What if you could use congitive solutions to look for these patterns continuously and proactively send you an e-mail if one emerges? Wouldn’t that be good?

Monitoring solutions have turned a corner. Before cognitive, monitoring solutions relied on Operations SMEs to carefully manage the environment. With cognitive solutions the SME is built-in, allowing developers to shift left “Operations thinking” into staging and focus on what they want to do and do best: code, code, code …

Watch a replay of the recently hosted webinar, “Learn Why We Must Shift APM Left in the DevOps Lifecycle.”

About the Author / Sinead Glynn

Sinead Glynn is an offering manager for IBM’s IT Service Management portfolio within DevOps.
Within the IT Service Management portfolio, she specializes in Operations Analytics offerings and the value they bring to both IT Operations and DevOps teams. In her 10+ years at IBM, Sinead has worked in both Development Management and Offering Management, covering both Network Performance Management and Operations Analytics-type solutions. Connect with Sinead on Twitter / LinkedIn.
September 21, 2016