BlueStripe Blog

Shaking Up Systems Management

Service-Oriented Problem Solving - Shutting Down the Bridge Call

IT Operations, SOITO

It's Tough to be Strategic When Your Pants are on Fire

IT Operations, SOITO

Application Performance Management (APM) is STILL Broken

APM, APM is Broken, Application Management, Application Performance Management, IT Operations

Monitoring Third-Party Services and FIX Transactions

Application Management, FIX Protocol

Comments

Analytics and APM - Big Data or the Right Data?

APM, Analytics, Big Data, Gartner, APM Digest

2012 - Record Growth and Continued Innovation at BlueStripe

Complete Visibility - Cracking the Genetic Code of the Transaction (Last in a Series)

Comments

Application Performance Management Tools and Complexity (3rd in a Series)

Infrastructure Complexity (2nd in a Series on Transaction Monitoring)

Managing Enterprise Transactions (1st in a Series)

Transactions are the common link between customers, Lines of Business serving those customers, and IT Operations.

That’s how our recent whitepaper Managing Enterprise Transactions begins. In it, we highlight three main points:

• Infrastructure complexity exists in all enterprises, and has become the main source of transaction performance problems
• This complexity breaks Application Performance Management (APM) and transaction management tools, leaving them blind to how transaction performance is affected by heterogeneous components and middleware
• BlueStripe has invented a new approach that tracks transactions across complex infrastructure without invasive code changes or network taps

In the next few blog posts, I’m going to talk about each of these, and how our FactFinder Transaction Performance & Availability Monitoring software makes it possible for companies to overcome the challenge of managing complex applications and delivering on service level requirements.

Download our recent whitepaper Managing Enterprise Transactions to learn more: http://bluestripe.com/resources/whitepapers/complex-transactions

Transaction Monitoring, Transaction Monitoring Whitepaper, Vic Nyman

Comments

What's Killing APM?

Over at InformationWeek, it seems somebody else has seen the light about APM being broken. Dave Wittman has a well thought out article titled “What’s Killing APM?” He examines several potential reasons leading to APM tools failing their owners, such as:

• IT teams don’t have time and resources needed to make these tools work properly
• APM tools can’t adjust to the requirements of Cloud apps (in Public OR Private Cloud)

Dave ultimately captures the essence of the problem in a single statement:

“As app environments become more dynamic and lifecycles for apps shorten, the substantial effort required for APM isn't worth the already iffy results it provides.”

It’s nice to see somebody else understands what we saw when we started BlueStripe:

• APM tools require a huge amount of manpower to setup, configure, and maintain
• Dynamic application structures make it impossible (not difficult, impossible) to understand all the relationships that exist in real time – unless you have tools that specifically tie transactions, applications, and infrastructure together
• Most APM tools specialize in specific code platforms (Java, .Net) and therefore miss critical components of complex application environments

The column is a must-read for any IT professional dealing with service delivery and IT Operations, as it includes some survey results on the behavior and attitudes of application users.

I must completely disagree with Dave’s conclusion, though. In a nutshell, he says APM should be scrapped for component-by-component self-health reporting. The industry has tried this silo-based approach for the last thirty years – and has failed. Why? Because to properly manage these systems, a tool MUST be able to “connect the dots” between Transactions, Applications, and Infrastructure. That means understanding how any specific infrastructure component impacts transaction performance.

This Wednesday (November 14th), Forrester’s Eveline Oehrlich and I will be talking about this very point. Join us to see how the next generation of IT Management tools can and must deal with complex dynamic application systems.

APM is Broken, InformationWeek, Vic Nyman Webinar

Comments

Reasons Why APM Deployments Fail - Because APM is Broken

In his 2004 book “The Wisdom of Crowds,” James Surowiecki promotes the idea that the combined intelligence of a group will often greatly exceeds that of the individual.

APMDigest has produced a “wisdom of crowds” type article about problems to look out for with APM deployments. In the article “15 Top Reasons Why APM Deployments Fail” they asked several experts in the field to describe the biggest problems with APM deployments. The result is a good rundown of considerations for companies when considering an approach for their application and transaction performance monitoring programs.

Many of the vendors consulted (including BlueStripe – I’m quoted in item #11) provide input that highlight key areas where their products are strong. Each input covers one specific problem, which the article groups into 15 categories. Reviewing these, the 15 categories can be consolidated down to 4 main points:

1. Avoid Silo-based thinking – focus on the entire application infrastructure rather than on individual components
2. Build for a dynamic environment
3. Limit the overhead of the monitoring program – both in terms of physical and human resources
4. Focus on relevant, actionable results

None of the vendors advocated for all of these points – but we should have. All four are key to success with application performance management, and all four are central to how we build out FactFinder software.

Most APM tools can’t address all four values, however. Most traditional APM tools are by definition silo-based, as they provide a deep dive into the code for specific tiers within the application infrastructure but don’t see beyond their specific tier. Also, most have trouble with dynamic changes to the application infrastructure footprint. So how do you find an APM tool that is – well – not really an APM tool?

To be blunt, that’s why BlueStripe exists. Our transaction-centric application management tool, FactFinder, breaks through silo barriers to follow transactions wherever they go. That allows us to find problems in any silo, as well as make sure that the transaction and application maps we build are always accurate and adjust to changes in real time.

To learn more about BlueStripe’s application management capabilities (and see them in action), watch our recent webinar about our new offering, FactFinder v7.

FactFinder v7 Released This Week

FactFinder v7 Release Notes

This is a big week for BlueStripe – we released our newest Transaction monitoring product version – FactFinder v7. Like most vendors, we’re proud of what we’ve built, and are eager to tell you about it.

Increasing complexity of dynamic application infrastructure is the big money problem that every enterprise-scale company faces. When we surveyed CIO’s earlier this year, we learned that 84% of Fortune 1000 companies have 5 or more different technologies in their application infrastructure. Further, Gartner’s Cameron Haight recently stated that “73% of CIOs say infrastructure complexity is either “high” or “out of control”.

All this complexity means that monitoring application health by using the broken APM model won’t work. It’s critical that companies be able to manage their applications by looking at their transactions as they flow across the infrastructure rather than at isolated points along the way.

That’s why we’re excited about FactFinder v7 – we’re introducing the first solution that automatically tracks each individual transaction, across all the different components both in the data center and across the cloud, without any changes to the code or the transactions themselves.

That’s right – no code changes, and complete transaction visibility across the whole variety of infrastructure components – web tiers, application servers, middleware, databases, mainframes, even Private and Hybrid Cloud.

Here’s how it works. FactFinder v7 includes TransactionLink, a collection of different technologies for tracking individual transactions both inside each node and in the network – between nodes. In high volume systems, there can be hundreds of thousands of transactions in play at any given time. Rather than tag each one, we’ve developed the approach of using the unique characteristics of each transaction (think payload content, date/time stamp, place of origin, etc.) to develop a unique identifier for each transaction – similar to reading the transaction’s genetic code.

This isn’t easy to do, but the payoff for end users is tremendous.

With TransactionLink, FactFinder users can now see the transaction path through the infrastructure of every transaction. In addition, we also provide the time spent on station for each node and connection, and automatically flag the bottleneck points. So when transactions are slow, FactFinder automatically shows you where the bottleneck is – and then also provides drill-down into the server stack to start the troubleshooting.

With this newest update to FactFinder, companies can reduce their application risk. The effort and time spent fighting fires is reduced, as most of the people currently on bridge calls no longer need to be invited to join. IT Teams can be certain that upgrades won’t break their existing applications, and that new applications will behave as advertised when put into production. Finally, when things do break down, they have a dynamic picture of the application system, of the transactions as they flow through the system, of the bottlenecks within the system, and the ability to drill down into the server stack to fix the problem.

FactFinder v7 is a huge leap forward - we're pretty proud to bring this out into the world.

FactFinder, Vic Nyman, v7, Transaction Monitoring

Comments

APM is Still Broken

Several months back my colleague Vic Nyman stirred up some controversy with his blog post titled “APM is broken. It’s time someone said it.” Vic’s point was that code-level analysis tools are not appropriate for systems-level problem solving.

Recently, the truth of Vic’s argument hit home in a brand new way. We see a lot of RFI’s from companies that need transaction-level visibility into their application systems. Looking at these, only a small fraction of the questions from the potential buyers are about how we would go about solving their problems. More than 80% of the questions focus on how difficult it would be to manage the solution.

Customers have clearly been through a difficult time – and this highlights for us everything that is wrong with APM tools today. Care and feeding of your monitoring tools shouldn’t require more effort (meaning FTEs, servers, consulting costs – in short your op-ex and cap-ex budgets) than the applications that they are supposed to help you manage.

At BlueStripe, we build our FactFinder software with the idea that implementation and management of our solution should be easy. So we build it from the ground up for rapid implementation – with the result that our typical full enterprise-wide install takes less than 1 day. Our footprint in the datacenter is extremely small – unlike some solutions that create new data warehouses to manage. And we don’t require extensive post-sale customization, meaning the cost of the license is the cost of the solution.

APM tools are still broken. If you’d like to avoid these traps, give BlueStripe a look.

Comments

Cloud Management: Public, Private, and Hybrid - oh my!

We have another customer announcement out this week – this time about LaFarge using FactFinder for transaction performance and availability management. LaFarge, a leading building materials company, is using FactFinder to manage their production applications. Like our other recent customer announcements (Husqvarna Group, Raymond James, Jackson Hewitt, etc.), the LaFarge announcement is about proactive monitoring and problem solving in IT Operations.

But an interesting aspect of today’s announcement is how Lafarge is using FactFinder to monitor ERP, in this case running on a Vblock environment. Vblock (VMWare software, Cisco hardware, and EMC storage all wrapped up with a bow on it) can be thought of as a “Private Cloud in a Rack.” Developments like Vblock make rapid deployments, well, more rapid – but they also create visibility issues for IT Operations that hinder their ability to manage application service levels. When problems occur, these teams are practically blind to meaningful data in a Private Cloud environment.

LaFarge provides a good illustration of the shortcomings of the typical approach to application troubleshooting when any flavor of Cloud is involved. In small, simple applications, the system footprint may include just a handful of servers. Manually checking log files and rebooting is manageable in this environment. In complex production applications, the system footprint can include hundreds of discrete nodes. Throw in the Cloud-based environment and the old way of identifying problems breaks down.

In LaFarge’s case, they had a mixture of physical and virtual servers. After considerable effort of attempting to identify the source of a transaction slowdown, the project was put on hold. When FactFinder was brought in, the team from LaFarge could see that their transaction slowdowns were occurring only with the virtual servers. They could then drill into the server stack and identify the error – quickly leading to resolution of the problem.

As companies deploy more enterprise-scale applications and incorporate private and hybrid cloud models, transaction visibility will only increase in importance.

Why the Big 4 Management Vendors Don't Have You Covered

I speak with our customers quite a bit. In particular, I meet with people from hosting teams, test teams, development, support – all the way up to CIOs and CEOs. I’m often asked about the “Big 4” – usually around how BlueStripe integrates with a Big 4 solution (like IBM’s CMDB – a subject for a future post). Sometimes, though, I’m asked why these companies, with seemingly unlimited resources, can’t get transaction monitoring right.

That’s a good question. The answer is simple.

To the Big 4, Transaction Monitoring is merely a point solution for a specific technology – usually created from a peripheral point product (like Java or End User tools), and then proclaimed to be a “Transaction Monitoring Solution.” Big 4 vendors operate two-tiered portfolios, the upper tier consisting of broad solutions like Frameworks, Dashboards, and Data Warehousing. The point products are merely supporting tools for the “bigger picture” sale. So there’s no incentive to invest in making these tools perform properly.

You and I, of course, know that Transaction Monitoring is fundamentally different. Deep visibility into transactions is a central requirement for effective performance & availability management. The problem is that transaction systems involve more than just Java App Servers – they also include Web Servers, Messaging Middleware, SAN Arrays, and much more (even mainframes).  An effective Transaction Monitoring solution must see how all those systems are involved, how transactions perform in each tier, and how each tier services transactions.

The pace of change in the infrastructure, itself, is putting a spotlight on this problem. There have been so many application technology changes in the past few years (even in this year), that there’s just no way for the products in Big 4 portfolios to adjust (many of their solutions are acquired – and more often than not, innovation peaks just before the acquisition closes).

It’s not time to drop your Big 4 frameworks. But when it comes to Transaction Monitoring, start with somebody that understands how important transaction visibility is to overall IT Management.

Comments

Why IT Operations Has To Step Forward Again

For years, the team on the hook to guarantee the availability of production applications was IT Operations. A decade ago, as new web platforms emerged, unstable new application code was causing problems. Development and app support teams had to take a large role in helping keep applications available in production. Those application code issues have largely stabilized, but a new challenge has emerged—dynamic infrastructure.

When I talk to IT executives, I ask them a simple question: Are 80% of your application problems coming from the code? Or are 80% problems coming from the systems hosting them? I keep hearing the same thing: problems are coming from unexpected environment issues or changes gone bad. One day it's a database update that didn't go as planned. The next it's a misconfigured load balancer, and then after that it's an under-provisioned VM. There's only one team equipped to handle this array of problems: the team responsible for keeping those infrastructure systems available.

It's time for Operations to step forward again as the leader on keeping applications available.

To do so, IT Ops teams are going to have to prove that they can improve what matters most—the reliability of users' transactions. But the job of managing the infrastructure hosting those transactions has never been harder. The production environment has become dynamic with virtualization, cloud, and SOA, and these new technologies only add to the long list of what Operations already has to manage.

Monitoring tools should be the IT Ops manager's best friend. Unfortunately, monitoring tools are typically focused on the technology parts (the servers, databases, code, network, etc.) rather than on the big picture. There needs to be a way to see the complete picture of the users' transactions as they flow across the infrastructure, even as the infrastructure dynamically shifts. Without this view, the team responding to problems is left relying on reboots or getting on bridge calls with SMEs.

For Ops to take back leadership in application availability management, we have to move to monitoring that puts the infrastructure in the right context: the impact on users' transactions.

Gartner Releases New Real-Time Infrastructure Hype Cycle

The challenge and importance of IT Service issues are being more widely recognized. When I blogged recently about APM and the challenges to operations teams, a surprising number of you jumped on the topic—in a good way.

Now…Gartner has gone further. They have released a new Real-time Infrastructure Hype Cycle in which they highlight the challenges of IT Service Root Cause Analysis in dynamic, real-time operations environments.

According to Gartner, IT Service Root Cause Analysis is providing high value to IT organizations that do it, but most have not adopted it yet. That means there is an opportunity for most corporations to gain significant value…especially since viable solutions exist.

We thought Gartner's take on the topic matched what we are hearing from our customers. IT Service Root Cause Analysis is one of the fundamental strengths of BlueStripe. And when our customers adopt it, it becomes one of their strengths.

BlueStripe enables an end-to-end view that monitors IT Service Transactions and bridges them to the platforms and real-time infrastructure serving them. This allows our customers to follow transactions, including individual transactions, to rapidly determine where problems are happening. Since getting to the root cause of an IT Service disruption is the goal, we don't stop at pinpointing the failing tier…we go on to drill-down through the platform stack to identify root causes in application code, VM configurations, storage systems, rogue systems management agents, core OS resources, and shared services like DNS.

As important as code monitoring, network monitoring, and transaction monitoring are, they are falling short of the total view that IT Ops needs—Gartner is saying it's time for an “end-to-end view” to how transactions interact with the complex mix of thousands of applications and real-time infrastructures that support them—a view for which BlueStripe is the best choice. (But then, maybe I am a little biased!)

Comments

Infrastructure Complexity: The Problem That Will Not Go Away

After my "APM is Broken" post, I've been amazed at just how many of you agreed that infrastructure complexity is the big issue causing IT availability problems.

The rise of infrastructure complexity has become the main source of application performance problems. The surprising thing is that it doesn't take many different kinds of components interacting to cause problems.

When we surveyed 126 IT execs from the Fortune 1000 a few months ago, 84% of those we surveyed had at least five technologies in their applications, and 64% had 7 or more different technologies! According to a survey Gartner conducted, 73% say their infrastructure complexity is either "high" or "out of control."

How Complexity Causes Performance & Availability Problems

Remember your last outage, where customers couldn't login or sales orders were randomly dropped? You can thank complexity for how hard it was to get to the root cause of the problem, because complexity causes outages in two ways:

First, it increases the opportunities for problems to emerge. As the number of nodes and components grows in the architecture of an application, the number of interactions between them grows exponentially. Where there are more components, more different types of technologies, and more points of interaction, there will be more problems.

Second, it makes the management of the transaction harder. The IT Ops staff needs to understand, configure, and monitor the health of all of those different technologies.

Without monitoring tools that can map the transactions to the underlying infrastructure, this task is virtually impossible—even worse…61% of those we surveyed said their tools didn't support all the different technologies in their applications, leaving them completely blind on segments of their transactions!

Transaction monitoring is the way to get a handle on complexity

The way to keep your complex transactions reliable is to see when they're failing and then to trace the failure back to its source. If the goal of IT infrastructure is to deliver transactions, then the way to manage complex infrastructure is to see when transactions are slow or failing and to trace their execution, hop-by-hop, through the infrastructure to the point of failure. That's what transaction monitoring from BlueStripe does.

This transaction tracking cannot miss part of the transaction path—it's essential to track transactions through each piece of the infrastructure to detect problems. Transaction monitoring must embrace complexity, tracking transactions through load balancing (used by 56% of survey respondents), across message buses and brokers (44%), in virtual or cloud environments (57%), out to third parties, or even into CICS and IMS systems (17%).

As Forrester's J.P. Garbani has said, "If you aren't managing everything, you aren't managing anything."

Click here to view the full survey results.

BlueStripe Blog, Vic Nyman, APM is Broken

Comments

Top 4 Application Management Challenges Plaguing IT Ops

We recently surveyed 126 IT Operations executives from the Fortune 1000 about their application management strategies. Their responses sent a clear message: IT Ops is on the hook for the performance of transactions and the systems they depend on, but to do so they need to overcome 4 key challenges:

1. It takes too long to resolve business-impacting problems

It's not that Operations teams are not up to the task of delivering business-critical services; the problem is that infrastructure complexity is growing out of control. We'll discuss this phenomenon in detail in next week's post.

The rise of this complexity causes the process of resolving user-impacting slowdowns and outages to take too long. In fact, complexity causes the next 3 problems, which are symptoms of the first.

• Traditional management tools do not provide a complete view of transactions and the systems they depend on
• So, IT Ops pieces together a picture by relying on costly, inefficient bridge calls
• Without a view of transactions and their supporting systems, Ops gets surprised that users are having problems—instead of catching them early

Let me explain:

2. Management tools only show part of the picture

Traditional tools report that transactions and applications are slow, or that a particular system is in trouble. They do not give Operations a simple way to see, in one place, how transactions are performing as they cross multiple systems, nor how each system is supporting the end user experience.

3. Dependence on bridge calls for firefighting

Because their toolsets don't provide a single view to cross-tier transactions and the systems they depend on, Ops doesn't have a complete picture of the application they're troubleshooting. To piece together the picture, they have to convene a bridge call with subject-matter experts (SMEs). Bridge calls are slow and costly: the search for group consensus among competing hunches prolongs the time it takes to troubleshoot, all the while wasting resources by drawing SMEs away from their work.

4. Reacting to users calling in instead of proactively resolving issues

Since IT Operations doesn't have a simple view to transactions and their supporting systems-and are instead relying on time-consuming bridge calls-Ops only has time to react to the latest user complaints. The time pressures force the team to depend on reboots and recycling app servers instead of finding and eliminating the root cause. Constantly reacting leaves the team unable to have any time to proactively solve emerging issues before users are significantly affected.

Transaction monitoring tools can help

For IT Ops teams suffering from these challenges, there is a solution. Transaction monitoring tools from BlueStripe can provide a simple, automatic view of transactions and the infrastructure they depend on. With this clear visibility, Ops can see where transactions get stuck and why problems are happening—overcoming the bridge calls and slow problem resolution that keeps them reacting to fires instead of proactively avoiding issues.

Stay tuned: next week, we'll discuss how infrastructure complexity is harming transaction performance and what you can do about it.

Click here to view the full survey results.

Comments

FactFinder: What IT Operations Has Been Looking For

Since we started BlueStripe, I’ve had the privilege to speak with hundreds of enterprise IT Operations executives. Their fundamental challenge has come through loud and clear: they are tasked with ensuring the performance of transactions, but are frustrated with having to do it with silo-oriented tools. Unfortunately, surprise performance problems repeatedly crop up because transactions cross many IT silos, and the paths those transactions follow across the infrastructure change dynamically. What do IT Operations folks need? A transaction-aware, IT Operations-friendly performance management product. That’s why BlueStripe built FactFinder. Here’s what I mean:

Transactions first

Let’s face it: transactions are really what IT performance is all about, and you need to follow their breadcrumb trails hop to hop through your entire dynamic IT infrastructure. That is now possible with FactFinder, our breakthrough management tool that automatically follows transactions wherever they go. FactFinder solves several key problems for IT Operations:

• What systems support my transactions? No more consulting outdated Visio charts or architects to determine which systems support the transaction. We map out the entire transaction path—for any application, across messaging middleware, back to the mainframe, and out to 3^rd party services.
• Where are my transactions getting stuck? Our transaction monitoring pinpoints exactly which server, and which component on that server, is the source of transactions slowness, cutting problem resolution time by 90% on average.

Where transactions meet systems

When a problem emerges, you’ve got to do more than just know where the slowdown is. You also must understand why it’s slow. In order to help Operations teams do this, FactFinder unites transaction monitoring with just enough visibility into the layers of the underlying systems to determine the root cause—whether it's Java, a VM, a database, a storage drive, a SQL query, or a CICS transaction. We’ll give you enough incontrovertible evidence to enable the handoff to the correct administrator or developer.

This view to the intersection of transactions and the systems they depend on is critical now that dynamic, shared infrastructure has become the primary cause of performance problems. Ever had performance issues that seem to mysteriously go away before they can be isolated, only to come back later? FactFinder nails those kinds of problems every day!

In FactFinder version 6, which was released today, we continue our theme of providing just enough visibility for IT Operations to identify which administrator owns a problem by adding in platform management for WebSphere, WebLogic, and their JVMs. Now, if WebSphere is shown to be a bottleneck, Operations can see whether an admin can fix the problem by adding capacity or whether it’s a code problem that must be assigned to development—all without the burden of maintaining or interpreting a code-level developer tool!

A lighter touch for IT Operations

Our company has a deep devotion to building products that fit within the unique constraints of IT Operations teams. Therefore, we built our monitoring to be automatic, so that it can be easily installed and maintained by the Operations team. We don’t require developers—or vendor consultants—to change the code or build instrumentation for our tool. We don’t require you to have an architect-level understanding of your transactions, nor do we require you to get network teams to install devices. Additionally, our software maintains itself by dynamically updating when any change happens—new code is released, a server goes down, a virtual server suddenly moves to a new virtual host, etc.

Version 6 and Beyond

I’m very excited to tell you that Version 6 hits the market today! What’s next for BlueStripe? You can rest assured that we will remain laser-focused on giving IT Operations what they need to run transactions and their supporting systems well, in a way that’s automatic and easy to manage.

BlueStripe Blog, Chris Neal

Comments

5 APM Demands from IT Operations Execs

Wow. The responses to our post last week (“APM is broken”) have been wonderfully positive. Thank you. I was skeptical that anyone would care what I had to say, but lots of you who are involved in Operations & Support sent us emails and LinkedIn messages not only thanking us for what we said, but in many cases saying it far better than I did. Additionally, some of the APM vendors didn't like what I had to say—a sure sign that it needs to be said.

To advance the discussion, I thought that many of you might appreciate hearing some of the feedback we've been getting from Ops execs over the last few weeks. The 5 comments below are both representative of your feedback as well as slightly anonymized to protect the innocent.

IT Ops APM Demand #1: Give me a tool that shows me my transaction performance across any and every tier

As one IT Ops exec told me recently, “I'm responsible for a login transaction that crosses more than 10 systems. When it's slow I need to see which of those systems is the source of the problem. I need to see the whole transaction—across our messaging middleware, into our private cloud environment, and into legacy applications. Showing me a few of the parts isn't good enough.”

IT Ops APM Demand #2: Give me root cause analysis for every system in my transaction

“What APM vendors need to realize,” said a VP of IT Operations at a major healthcare company, “is that problems can come from anywhere. We've seen slow DNS resolution bring down our application, users getting errors in one application because another was slamming the database…we've even seen the anti-virus software slowing down users because it was updating its definitions file on every machine… in the middle of the afternoon. Where's the tool that can see all that?”

IT Ops APM Demand #3: Don't make me rely on developers and code-level developer tools

From an executive at a Fortune 500 financial services firm: “I shouldn't have to keep a couple developers—or worse, vendor consultants—on my payroll to keep my APM tool instrumented where it needs to. And I certainly shouldn't have to pay to use a developer tool in production just to tell me if WebSphere is running OK.”

IT Ops APM Demand #4: Give me a tool for managing cross-domain performance, not just silo failures

From a major consumer bank: “We're good at knowing when one of our servers completely died. We're not good at knowing where things slowed down. We have been looking to get to that level of maturity for years, but haven't found a tool to get us there.”

IT Ops APM Demand #5: Stop selling me a dozen products duct-taped together

“I'm tired of vendor sales reps coming in here and telling me I can get end-to-end visibility to my transactions…by buying 8 separate management tools,” said one exec. “Making me pay for 8 different tools duct-taped together with an APM tool is just more of the same.”

At BlueStripe, we're committed to serving Operations and Support teams. We know that they need a new kind of management… one that goes beyond the current APM choices. Your feedback above made that pretty clear.

We built our FactFinder product to be a single view to cross-domain transactions, the application platforms that run them, and infrastructure they depend on. This gives you the visibility to follow transactions across the most complicated of environments…. and see not only where the transactions go, but to see where they get stuck and why.

The feedback from you guys is probably best represented by an SVP at a large financial services firm who replied to my co-founder, Chris Neal, with: 

“You summed up my frustration over the past 2 years in just a few paragraphs—APM is broken! I fought and lost this battle at my company. For our private cloud they went with [a well-known code-level tool] because the CTO was a former developer and more interested in debugging. There is a huge opening for a tool like yours for Ops to use.”

I couldn't agree more.

APM, BlueStripe Blog, Vic Nyman

Comments

APM is broken. It's time someone said it.

I talk to IT Operations executives every day. They're fed up. These execs are on the hook for business-critical services, but their APM tools aren't helping them.

They're tired of APM vendors like CA/Wily, Compuware/Dynatrace, AppDynamics, and OpTier selling code-level developer tools as IT Operations management solutions.

IT Ops execs are right to be angry. Ops shouldn't have to use tools designed for developers. Plus, the problems Ops has to solve are far broader than just Java & .NET.

Unfortunately, IT Ops execs haven't had an alternative to code-level tools…until now. 

BlueStripe is fixing APM for IT Operations. We've developed a groundbreaking way to track cross-tier business transactions and the infrastructure they depend on. We give Ops teams the data they need to solve problems and break their reliance on developers, architects, and SMEs.

We're not the only ones that have realized something's broken. Gartner recognized our "alternate, Operations-centric" approach by naming BlueStripe both an “APM Innovator” and a “Cool Vendor in APM”.

How did a great idea like APM go wrong?

The co-founders of BlueStripe were early employees at Wily, the original code-level APM company. When Wily started over a decade ago, every enterprise was moving their business online using a new application platform: Java. Unfortunately, the early Java platform and the new applications written for it were suffering from growing pains.

APM's indispensible role was to help organizations identify these code and architecture-oriented problems where they were found…in QA environments and sometimes in production. I am proud to have had a small part in building and refining APM. It helped a brilliant web technology emerge.

But code-level APM doesn't work for today's IT Operations challenges. We know. We built it. We didn't intend for it to be used this way.

Today's challenges require something new

After a decade of APM, the Java platform is much more stable…but business services aren't. 

Complex infrastructure has replaced Java as the number one source of transaction problems. Overall, the infrastructure has become more dynamic and varied. Transactions now depend on intense levels of virtualization, clustering, and service architectures. It's gotten so bad that when Gartner polled attendees at its Data Center conference in December, 79% said they had "high" or "out of control" infrastructure complexity.

For many of our customers, a single Login transaction may touch dozens of systems before returning a result to the user. So, a problem on any one system can cause the entire transaction to take too long or to fail.  To manage this, Ops has to be able to see where these transactions are going, where they get stuck, and why.

You can't use last generation's code-centric approach to solve today's dynamic infrastructure challenges.

Vic Nyman, BlueStripe Blog, APM

Comments