Part 3 of the “Who Owns the End-to-End Transaction?” 6-part blog series. Throughout the next few weeks, we will be taking a close look at how various IT stakeholders benefit from end-to-end transaction visibility. Be sure to check out:
Part 1: “Why Application Support Managers Need End-to-End Transaction Visibility”
Part 2: “IT Operations and End-to-End Visibility.”
Seeing from the eyes of the customer…
Application Developers are responsible for the design, configuration, implementation, integration, and tuning of all the applications running on the network – from the interface, to the underlying components, to the various services behind them. These are all factors which inevitably affect the end user experience (EUE) and the customer’s impression of the business.
Application Developers take market and business requirements from a product manager, translate them into software requirements, implement them in working programmatic code, test it, debug it, and patch or modify it according to customer needs. Typically each member of the development team has specific skills and domain expertise, with an in-depth knowledge of one or more specific software technologies, languages and applications. There are various job titles and responsibilities within the development group but most include some part in the following duties:
- Writing program specification and software design, typically from a product requirements document
- Designing solutions to meet specific objectives or constraints
- Breaking down the program specification into its elements and composing each in a programming language of choice (e.g. C/C++, C#, Java, Python, JavaScript)
- Integrating the elements into a framework and testing each component as well as the overall implementation
- Resolving bugs and performance issues that arise from the testing by the QA (Quality Assurance) team
- Supporting deployment and configuration as required
- Responding to trouble tickets to identify bugs and resolve coding issues
- Implementing new requirements or feature requests from the product manager and/or the customer
Today’s agile application environments require more frequent code changes
An end-customer’s impression of a business is often derived through interaction with a customer-facing application deployed somewhere within the operational infrastructure of a business. Ever-increasing demands for choice, speed, convenience and security are the catalysts behind an emerging applications environment that is more agile and requiring more frequent code changes more ever before. As a result, Application Developers are constantly updating applications living within the operations environment, and becoming increasingly responsible for the EUE even after an application has left the Quality Assurance group (QA).
Poor visibility means ineffective coordination and broken remediation processes
One of the major challenges emerging for Application Developers is their limited visibility into the operations environment. When they receive trouble tickets or customer complaints suggesting an application issue, these reports can often be misleading. Without the right tools to quickly isolate the source of the problem, Application Developers may find themselves wasting hours trying to reproduce and test issues that are actually rooted in any number of causes that they have little control over:
- Inadequate allocation of IT resources (e.g. memory, network bandwidth, slow disk I/O)
- Dysfunctional or mis-configured network and IT infrastructure
- Slow or misbehaving 3rd party services
- Unpatched OS with degraded versions of requisite systems
- Interference from firewalls or security systems
- Improperly allocated virtual machines
This is why Application Developers need to share a common view with applications support, IT operations, network operations, sales engineers, and the customer – to translate what is being experienced into reproducible code-based issues that they can effectively remediate. What Application Developers need most in this agile environment is the ability to inspect, measure, and monitor all applications running within the operational environment. They also need the ability to separate the influence of the network infrastructure from the processing of each application, and to gauge the inter-play between the two.
Traditionally this has been done by instrumenting the code of each application with logging and performance probes or agents. However, there are several issues with this approach. First, the data is not easily shareable – Applications Support or IT Operations do not have the skills to interpret the results or investigate the issues without involving Application Developers. Second, instrumenting the code has limitations – performance logging frameworks are usually specific to a particular code environment such as the Java VM and cannot be applied across a diverse set of services. They do not typically have the option of adding instrumentation to 3rd party code or managed services. And, due to rising use of agile processes, there is less and less time to adequately instrument and profile the code. Finally, in many cases there is a significant performance impact associated with turning the logging on – too much to allow it to be used operationally, if at all.
Deploying network-based APM in agile environments
Network-based Application Performance Management (APM) overcomes these obstacles Application Developers regularly experience. Otherwise known as Business Transaction Management (BTM), these solutions provide the ability to continuously monitor complex, distributed applications on a non-intrusive basis. Network-based APM solutions place no load on the application services and provide both an in-depth and end-to-end view of all the components. As it starts from the network, it includes a view of the network infrastructure contribution. Since transaction monitoring reconstructs exchanges based on application protocols at the network level, it works regardless of the coding language, operating system or run-time environment. All of that means greater end-to-end visibility and improved coordination with other teams involved in the troubleshooting process.
Key metrics derived from network-based APM give Application Developers direct measurements of distributed applications and all their parts – not only into the parts they own, but also the 3rd party and managed services, virtualized infrastructure and the Cloud, network performance, and the end-user experience. Plus, transaction-based metrics provide both aggregate statistical views of overall performance and also details of particular instances with all of the application data associated with each, qualifying them according to context and outcomes. For example:
- Transaction response times on a per-service/component basis classified according to failures, complete or incomplete, function type, or any other specifics
- Concurrency rates, end-to-end or per-service, distinguished by end-user task
- Rates of errors, by type, cause, and input data
- Turns of a service per task, by functional type and output
- Average number of packets and bytes per application message by type
With network-based APM, Application Developers have visibility into the live operational application, using views that other teams share and can reference, including per-transaction detail of both infrastructure and application interactions. They can assess the EUE and relate it to specific events within the application operation. This allows them to coordinate closely with application support, rapidly triage problems as they arise, discover how they are implicated, and determine if more intensive application logging/monitoring needs to be turned on.
Application Developers are crucial to the customer experience. Like the other teams that rely on them, they need the detailed and shareable end-to-end transaction views that network-based application performance management provides to do their job effectively once the application goes into operation.
Be sure to check in next week for part 4 of this 6-part series that will explain what Database Managers gain from end-to-end transaction monitoring.
For more information on network-based APM, check out our the whitepaper and video on the Unified Transaction Model and see the blogs in the rest of this series – Who Owns End-to-End Transaction?
You can also watch the on-demand webinar or download the whitepaper titled, “Who Owns the End-to-End Transaction: Mapping IT Stakeholders to Transaction-Derived Metrics”.