SAP Hybris: Achieving Omni-channel with Application Performance

The retail industry is transforming in today’s digital age. Consumer behavior keeps evolving and online spending is skyrocketing. In addition, retail customers are looking for a blended online and in-store experience and expecting brick-and-mortar stores and online channels to be integrated through an omni-channel strategy. This requires retailers to become customer obsessed and strive to deliver personalized, convenient and seamless shopping experiences online and in the stores.

SAP Hybris omni-channel commerce is well positioned to help these customer focused retailers in their journey of digital transformation by offering a single system for managing product content, commerce operations and channels. Thus helping retailers, manufacturers and others to create a unified and seamless cross-channel experience for their customers – from online, to in-store, to mobile and beyond.

Performance monitoring of SAP Hybris E-Commerce environment is key to delivering exceptional customer experience  

Today, e-commerce, mobile applications, and an integrated omni-channel strategy are key to success for retailers. However, poor performing e-commerce and mobile applications taking over 3 seconds to respond are fatal to retailer’s reputation, brand and revenue.There are no second chances in this digital world: when you’re not available, someone else is – your competitors are just a click away. This means that ensuring flawless performance and optimizing customer experience is critical for retail success.

Although the SAP Hybris E-Commerce solution is very well positioned to help retailers by offering a single system for managing product content, commerce operations and channels, a sophisticated end-to-end monitoring solution for SAP Hybris becomes necessary to quickly isolate and resolve performance issues in order to ensure exceptional end-user experience.

Retailers deploying SAP Hybris based E-Commerce and mobile apps face many challenges as they try to effectively manage the end-to-end customer experience, including:

  • Avoiding application performance problems impacting the consumer. Technical glitches, especially during peak periods (i.e. Black Friday and Cyber Monday) impact revenue immediately as many of the consumers would be deterred from using a retailer again after a negative experience.

  • Promoting agility in software management processes. To stay ahead of the competition, retailers need to move to an agile operating model. This is essential because with the right management solutions it allows for a fast Mean Time To Resolution (MTTR) of application performance issues and enables teams to work together when developing or enhancing application offerings.

  • Securing 5 star rated mobile apps. The retail application landscape is as competitive as the industry as a whole. The number of apps in use is growing by day meaning highly responsive, convenient and usable apps are a must to secure 5 star app ratings.

  • Correlating application and customer experience data. Applications are the primary channel for customer engagement. Unfortunately, without substantial investment into building a custom analytics solution, retailers can’t get actionable insights.

SAP Hybris: Open and extensible Java based architecture

The execution environment for the Hybris platform is a Java EE Servlet Container, for example Tomcat  or VMware vFabric Server, which is also based on Tomcat but provides commercial support.

The platform and all extensions to it run within the Spring environment, which allows easy configuration of each component and provides generic logic such as security, caching, clustering and persistence.  

 

Screen Shot 2016-03-16 at 5.24.10 PM.png

 

Figure 1: Architectural overview of the hybris Commerce Suite

An extension may simply provide additional business logic without exposing a visible UI or it may also contain a Frontend Java Web Application. A natural framework choice to realize the frontend web application in hybris Spring environment is to use the Spring MVC Framework, but any Java Web Framework such as JSF or Struts may be used.

AppDynamics Application Intelligence Platform ensures flawless SAP Hybris Commerce performance

As mentioned above, the execution environment of Hybris platform is a Java EE Servlet Container and most of the extensions and front-end applications are developed using Java or Java framework.

AppDynamics Application Performance Management (APM), a module of AppDynamics Application Intelligence Platform, is one of the leading Java APM solutions in the industry. Retailers can get complete visibility into the most complex Java powered Hybris based retail and omni-channel commerce application out of the box with AppDynamics APM. With APM, end-user monitoring, infrastructure visibility and application analytics modules, AppDynamics Application Intelligence Platform integrates monitoring, troubleshooting, and analytics capabilities to provide real-time, actionable IT operational and business insights into Hybris based application performance, user experience, and business outcomes — all in real time, and all in production.

Picture1.png

Figure 2: AppDynamics Flowmap of  Hybris based retail commerce application

AppDynamics delivers a comprehensive solution to help retailers maximize their business performance. The platform embraces three key principles:

  • See faster with Unified Monitoring: Identify customer-impacting issues quickly with end-to-end business transaction monitoring.

  • Act sooner with Unified Troubleshooting: Minimize business impact with rapid problem resolution.

  • Know more with Unified Analytics: Correlate application performance to business impact.

All of this happens in real time, in production, giving retailers more visibility, understanding, and control across applications, infrastructure, and user experience. The platform offers the added flexibility of SaaS or on-premises deployment, in order to match and flex with business requirements and data ownership.

Key AppDynamics Features  

  • Automatically visualize and map Java based Hybris solution dependencies

  • Monitor JVM health and performance

  • Automatically baseline performance to alert and address  emerging issues in context of Business Transactions

  • Quickly isolate and resolve production java application performance issues at code-level depth with minimal overhead

  • Enhance Dev & Ops collaboration with role-based views and Virtual War Room

  • End to end visibility into application environment with End-user Monitoring, APM and Infrastructure visibility modules

  • Actionable insights into application performance, user experience, and business outcomes

Enterprises of every description are pursuing digital transformation to satisfy user expectations for always-on, always effective engagement, and to realize the competitive efficiencies and advantages of digital delivery. Digital Transformation is not a choice for retailers, it’s a business imperative. This means that ensuring flawless performance and optimizing customer experience is critical to retail success.

AppDynamics Application Intelligence helps retailers, including those leveraging Hybris to power their applications, take their digital strategies from good to great by ensuring mobile and eCommerce performance, allowing business, dev and ops teams to collaborate easily and automatically correlating technical performance with business outcomes. Take a walk through the platform and see how your enterprise can leverage application performance to gain the most of their applications. 

Top 10 Application Performance Problems

A transaction is defined as one or multiple threads running in or across server boundaries on multiple runtime environments. And with today’s rapid enterprise growth, the demand for high-performance transactions through software run applications is higher than ever before, which means a greater need for these threads to be run on their respective platforms efficiently, and without delay.

Principal Sales Engineer, Hugh Brien, shares some of his findings on the common application problems discovered in transaction threads and the core concepts to think about while investigating issues to ultimately optimize the end user’s experience. Some of the main findings include server configuration in thread pools, identifying a correlation between load and response times to find request overloads, I/O bottlenecks, and improper memory configurations for transaction volumes. Hugh also walks us through strategies and measures specific to Java, .NET and more to further identify potential problem areas, and how APM exposes them beforehand.

Brien also spoke on what it takes to start constructing a defined process to understand a customer’s pain points, and further clarify the best practices on how to best utilize application intelligence and avoid future troubleshooting.

Browse through the deck today!

Top 10 Application Problems from AppDynamics

Speed Kills: Every (milli)second counts [INFOGRAPHIC]

Application performance tends to be one of those things everyone knows is important, but it’s hard to put a specific number to just how important.

Earlier this year, Gartner published their findings (subscription required) from Google, Amazon, Yahoo, Microsoft, and many others that showed as performance, most notably speed, slows down, their revenue is negatively affected as well. Though not inherently surprising, what is surprising is by how much. These companies would lose millions of dollars in revenue for every fraction of a second their application slowed down. Running at anything but optimal speed was taking a chunk out of their bottom line.

We took some of these stats and created an infographic to paint the visual about how important every millisecond is in regards to your application performance, and bottom line.

Speed-Kills-8

Don’t lose millions off your bottom line, try AppDynamics for FREE today!

Insights from an Investment Banking Monitoring Architect

To put it very simply, Financial Services companies have a unique set of challenges that they have to deal with every day. They are a high priority target for hackers, they are highly regulated by federal and state governments, they deal with and employ some of the most demanding people on the planet, problems with their applications can have an impact on every other industry across the globe. I know this from first hand experience; I was an Architect at a major investment bank for over 5 years.

In this blog post I’m going to show you what’s really important when Financial Services companies consider application monitoring solutions and warn you about the hidden realities that only expose themselves after you’ve installed a large enough monitoring footprint.

1 – Product Architecture Plays a Major Role in Long Term Success or Failure

Every monitoring tool has a different core architecture. On the surface these architectures may look similar but it is imperative to dive deeper into the details of how all monitoring products work. We’ll use two real product architectures as examples.

Monitoring Architecture“APM Solution A” is an agent based solution. This means that a piece of vendor code is deployed to gather monitoring information from your running applications. This agent is intelligent and knows exactly what to monitor, how to monitor, and when to dial itself back to do no harm. The agent sends data back to central collector (called a controller) where this data is correlated, analyzed, and categorized automatically to provide actionable intelligence to the user. With this architecture the agent and the controller are very loosely coupled which lends itself well to highly distributed, virtualized environments like you see in modern application architectures.

“APM Solution B” is also agent based. They have a 3 tiered architecture which consists of agents, collectors, and servers. On the surface this architecture seems reasonable but when we look at the details a different story emerges. The agent is not intelligent therefore it does not know how to instrument an application. This means that every time an application is re-started, the agent must send all of the methods to the collector so that the collector can tell the agent how and what to instrument. This places a large load on the network, delays application startup time, and adds to the amount of hardware required to run your monitoring tool. After the collector has told the agent what to monitor the collectors job is to gather the monitoring data from the agent and pass it back to the server where it is stored and viewed. For a single application this architecture may seem acceptable but you must consider the implications across a larger deployment.

Choosing a solution with the wrong product architecture will impact your ability to monitor and manage your applications in production. Production monitoring is a requirement for rapid identification, isolation and repair of problems.

2 – Monitoring Philosophy

Monitoring isn’t as straight forward as collecting, storing, and showing data. You could use that approach but it would not provide much value. When looking at monitoring tools it’s really important to understand the impact of monitoring philosophy on your overall project and goals. When I was looking at monitoring tools I needed to be able to solve problems fast and I didn’t want to spend all of my time managing the monitoring tools. Let’s use examples to illustrate again.

Application Monitoring Philosophy“APM Solution A” monitors every business transaction flowing through whatever application it is monitoring. Whenever any business transaction has a problem (slow or error) it automatically collects all of the data (deep diagnostics) you need to figure out what caused the problem. This, combined with periodic deep diagnostic sessions at regular intervals, allows you to solve problems while keeping network, storage, and CPU overhead low. It also keeps clutter down (as compared to collecting everything all the time) so that you solve problems as fast as possible.

“APM Solution B” also monitors every transaction for each monitored application but collects deep diagnostic data for all transactions all the time. This monitoring philosophy greatly increases network, storage, and CPU overhead while providing massive amounts of data to work with regardless of whether or not there are application problems.

When I was actively using monitoring tools in the Investment Bank I never looked at deep diagnostic data unless I was working on resolving a problem.

3 – Analytics Approach

Analytics comes in many shapes and sizes these days. Regardless of the business or technical application, analytics does what humans could never do. It creates actionable intelligence from massive amounts of data and allows us to solve problems much faster than ever before. Part of my process for evaluating monitoring solutions has always been determining just how much extra help each tool would provide in identifying and isolating (root cause) application problems using analytics. Back to my example…

“APM Solution A” is an analytics product at it’s core. Every business transaction is analyzed to create a picture of “normal” response time (a baseline). When new business transactions deviate from this baseline they are automatically classified as either slow or very slow and deep diagnostic information is collected, stored, and analyzed to help identify and isolate the root cause. Static thresholds can be set for alerting but by default, alerts are based upon deviation from normal so that you can proactively identify service degradation instead of waiting for small problems to become major business impact.

“APM Solution B” only provides baselines for the business transactions you have specified. You have to manually configure the business transactions for each application. Again, on small scale this methodology is usable but quickly becomes a problem when managing the configuration of 10’s, 100’s, or 1000’s of applications that keep changing as development continues. Searching through a large set of data for a problem is much slower without the assistance of analytics.

Monitoring Analytics

4 – Vendor Focus

When you purchase software from a vendor you are also committing to working with that vendor. I always evaluated how responsive every vendor was during the pre-sales phase but it was hard to get a good measure of what the relationship would be like after the sale. No matter how good the developers are, there are going to be issues with software products. What matters the most is the response you get from the vendor after you have made the purchase.

5 – Ease of Use

This might seem obvious but ease of use is a major factor in software delivering a solid return on investment or becoming shelf-ware. Modern APM software is powerful AND easy to use at the same time. One of the worst mistakes I made as an Architect was not paying enough attention to ease of use during product evaluation and selection. If only a few people in a company are capable of using a product then it will never reach it’s full potential and that is exactly what happened with one of the products I selected. Two weeks after training a team on product usage, almost nobody remembered how to use it. That is a major issue with legacy products.

Enterprise software is undergoing a major disruption. If you already have monitoring tools in place, now is the right time to explore the marketplace and see how your environment can benefit from modern tools. If you don’t have any APM software in place yet you need catch up to your competition since most of them are already looking or have already implemented APM for their critical applications. Either way, you can get started today with a free trial of AppDynamics.

AppDynamics goes to OSCON

The AppDynamics team is in Portland, Oregon this week to showcase AppDynamics at the O’Reilly Open Source Convention. This event is a great opportunity to meet with the community and connect with thought leaders in the open source world. Stop by our booth for office hours if you’re in the area this week!

AppDynamics at OSCON

If you are attending OSCON join my birds of a feather sessions to talk about scaling PHP in the real world and quantifying the value of DevOps.

Find out more about AppDynamics and get started with a free 15 day trial.

Intelligent Alerting for Complex Applications – PagerDuty & AppDynamics

Screen Shot 2013-04-16 at 2.39.00 PMToday AppDynamics announced integration with PagerDuty, a SaaS-based provider of IT alerting and incident management software that is changing the way IT teams are notified, and how they manage incidents in their mission-critical applications.  By combining AppDynamics’ granular visibility of applications with PagerDuty’s reliable alerting capabilities, customers can make sure the right people are proactively notified when business impact occurs, so IT teams can get their apps back up and running as quickly as possible.

You’ll need a PagerDuty and AppDynamics license to get started – if you don’t already have one, you can sign up for free trials of PagerDuty and AppDynamics online.  Once you complete this simple installation, you’ll start receiving incidents in PagerDuty created by AppDynamics out-of-the-box policies.

Once an incident is filed it will have the following list view:

incident

When the ‘Details’ link is clicked, you’ll see the details for this particular incident including the Incident Log:

incident_details

If you are interested in learning more about the event itself, simply click ‘View message’ and all of the AppDynamics event details are displayed showing which policy was breached, violation value, severity, etc. :

incident_message

Let’s walk through some examples of how our customers are using this integration today.

Say Goodbye to Irrelevant Notifications

Is your work email address included in some sort of group email alias at work and you get several, maybe even dozens, of notifications a day that aren’t particularly relevant to your responsibilities or are intended for other people on your team?  I know I do.  Imagine a world where your team only receives messages when the notifications have to do with their individual role and only get sent to people that are actually on call.  With AppDynamics & PagerDuty you can now build in alerting logic that routes specific alerts to specific teams and only sends messages to the people that are actually on-call.  App response time way above the normal value?  Send an alert to the app support engineer that is on call, not all of his colleagues.  Not having to sift through a bunch of irrelevant alerts means that when one does come through you can be sure it requires YOUR attention right away.

on_call_schedules

Automatic Escalations

If you are only sending a notification and assigning an incident to one person, what happens if that person is out of the office or doesn’t have access to the internet / phone to respond to the alert?  Well, the good thing about the power of PagerDuty is that you can build in automatic escalations.  So, if you have a trigger in AppDynamics to fire off a PagerDuty alert when a node is down, and the infrastructure manager isn’t available, you can automatically escalate and re-assign / alert a backup employee or admin.

escalation_policy

The Sky is Falling!  Oh Wait – We’re Just Conducting Maintenance…

Another potentially annoying situation for IT teams are all of the alerts that get fired off during a maintenance window.  PagerDuty has the concept of a maintenance window so your team doesn’t get a bunch of doomsday messages during maintenance.  You can even setup a maintenance window with one click if you prefer to go that route.

maintenance_window

Either way, no new incidents will be created during this time period… meaning your team will be spared having to open, read, and file the alerts and update / close out the newly-created incidents in the system.

We’re confident this integration of the leading application performance management solution with the leading IT incident management solution will save your team time and make them more productive.  Check out the AppDynamics and PagerDuty integration today!

Introducing AppDynamics for PHP

PHP Logo

It’s been about 12 years since I last scripted in PHP. I pretty much paid my way through college building PHP websites for small companies that wanted a web presence. Back then PHP was the perfect choice, because nearly all the internet service providers had PHP support for free if you registered domain names with them. Java and .NET wasn’t an option for a poor smelly student like me, so I just wrote standard HTML with embedded scriplets of PHP code and bingo–I had dynamic web pages.

Today, 244 million websites run on PHP which is almost 75% of the web. That’s a pretty scary statistic. If only I’d kept coding PHP back when I was 21, I’d be a billionaire by now! PHP is a pretty good example of how open-source technology can go viral and infect millions of developers and organizations world-wide.

Turnkey APMaaS by AppDynamics

Since we launched our Managed Service Provider program late last year, we’ve signed up many MSPs that were interested in adding Application Performance Management-as-a-Service (APMaaS) to their service catalogs.  Wouldn’t you be excited to add a service that’s easy to manage but more importantly easy to sell to your existing customer base?

Service providers like Scicom definitely were (check out the case study), because they are being held responsible for the performance of their customer’s complex, distributed applications, but oftentimes don’t have visibility inside the actual application.  That’s like being asked to officiate an NFL game with your eyes closed.

ref

The sad truth is that many MSPs still think that high visibility in app environments equates to high configuration, high cost, and high overhead.

Thankfully this is 2013.  People send emails instead of snail mail, play Call of Duty instead of Pac-Man, listen to Pandora instead of cassettes, and can have high visibility in app environments with low configuration, low cost, and low overhead with AppDynamics.

Not only do we have a great APM service to help MSPs increase their Monthly Recurring Revenue (MRR), we make it extremely easy for them to deploy this service in their own environments, which, to be candid, is half the battle.  MSPs can’t spend countless hours deploying a new service.  It takes focus and attention away from their core business, which in turn could endanger the SLAs they have with their customers.  Plus, it’s just really annoying.

Introducing: APMaaS in a Box

Here at AppDynamics, we take pride in delivering value quickly.  Most of our customers go from nothing to full-fledged production performance monitoring across their entire environment in a matter of hours in both on-premise and SaaS deployments.  MSPs are now leveraging that same rapid SaaS deployment model in their own environments with something that we like to call ‘APMaaS in a Box’.

At a high level, APMaaS in a Box is large cardboard box with air holes and a fragile sticker wherein we pack a support engineer, a few management servers, an instruction manual, and a return label…just kidding…sorry, couldn’t resist.

man in box w sticker

Simply put, APMaaS in a Box is a set of files and scripts that allows MSPs to provision multi-tenant controllers in their own data center or private cloud and provision AppDynamics licenses for customers themselves…basically it’s the ultimate turnkey APMaaS.

By utilizing AppDynamics’ APMaaS in a Box, MSPs across the world are leveraging our quick deployment, self-service license provisioning, and flexibility in the way we do business to differentiate themselves and gain net new revenue.

Quick Deployment

Within 6 hours, MSPs like NTT Europe who use our APMaaS in a Box capabilities will have all the pieces they need in place to start monitoring the performance of their customer’s apps.  Now that’s some rapid time to value!

Self-Service License Provisioning

MSPs can provision licenses directly through the AppDynamics partner portal.  This gives you complete control over who gets licenses and makes it very easy to manage this process across your customer base.

Flexibility

A MSP can get started on a month-to-month basis with no commitment.  Only paying for what you sell eliminates the cost of shelfware.  MSPs can also sell AppDynamics however they would like to position it and can float licenses across customers.  NTT Europe uses a 3-tier service offering so customers can pick and choose the APM services they’d like to pay for.  Feel free to get creative when packaging this service for customers!

Conclusion

As more and more MSPs move up the stack from infrastructure management to monitoring the performance of their customer’s distributed applications, choosing an APM partner that understands the Managed Services business is of utmost importance.  AppDynamics’ APMaaS in a box capabilities align well with internal MSP infrastructures, and our pricing model aligns with the business needs of Managed Service Providers – we’re a perfect fit.

MSPs who continue to evolve their service offerings to keep pace with customer demands will be well positioned to reap the benefits and future revenue that comes along with staying ahead of the market.  To paraphrase The Great One, MSPs need to “skate where the puck is going to be, not where it has been.”  I encourage all you MSPs out there to contact us today to see how we can help you skate ahead of the curve and take advantage of the growing APM market with our easy to use, easy to deploy APMaaS in a Box.  If you don’t, your competition will…

AppDynamics & Splunk – Better Together

AppD & Splunk LogoA few months ago I saw an interesting partnership announcement from Foursquare and OpenTable.  Users can now make OpenTable reservations at participating restaurants from directly within the Foursquare mobile app.  My first thought was, “What the hell took you guys so long?” That integration makes sense on so many levels, I’m surprised it hadn’t already been done.

So when AppDynamics recently announced a partnership with Splunk, I viewed that as another no-brainer.  Two companies with complementary solutions making it easier for customers to use their products together – makes sense right?  It does to me, and I’m not alone.

I’ve been demoing a prototype of the integration for a few months now at different events across the country, and at the conclusion of each walk-through I’d get some variation of the same question, “How do I get my hands on this?”  Well, I’m glad to say the wait is over – the integration is available today as an App download on Splunkbase.  You’ll need a Splunk and AppDynamics license to get started – if you don’t already have one, you can sign up for free trials of Splunk and AppDynamics online.

Black Friday and Cyber Monday thru the eyes of an APM solution

A week has passed since Black Friday, so I thought it would be a good idea to summarise what we saw at AppDynamics from monitoring one of several e-commerce applications in production.

Firstly, things went pretty well for our customers who experienced between 300 and 500% increase in transaction volume over the holiday period on their applications. Thats a pretty big spike in traffic for any application so its always good to look at those spikes and see what impact they had on application performance.

Here’s a screenshot which shows the load (top) and response time (bottom) of a major e-commerce production application during the thanksgiving period. The dotted line in both charts represents the dynamic baseline of normal activity. You can see on Black Friday (23rd) and Cyber Monday (26th) that transaction throughput was peaking between 24,000 and 31,000 tpm on the application, spiking between 150 and 200% over the normal load the application experiences throughput the rest of the year.

Application response time during the period had one blip during the first minutes of Black Friday (9pm PCT/Midnight EST) with no major performance issues following thru into Cyber Monday. The blip in the application related to the web container thread pool becoming exhausted during peak load when the Black Friday promotions went live. Below you can see throughput was hitting 23,000 tpm.

Two business transactions “Product Display” and “Checkout” were breaching their performance baselines during that period. Looking at the average response times of 516ms and 733ms tells one story, looking at the maximum response time and number of slow/very slow transactions (calculated using SD) tells a completely different story.

Let’s take a look at the execution of one individual “Product Display” business transaction that was classified as very slow with a 66 second response time.

When we drill into the code execution and SQL activity we can see a simple SELECT SQL query had a response time of 588ms, the problem in this transaction was that this query was invoked 102 times resulting in a whopping 59.9 seconds of latency, its therefore no surprise that thread concurrency inside the JVM was high waiting for transactions like these to complete. If these queries are simply pulling back product data then there is no reason why a distributed cache can’t be used to store the data instead of expensive calls to a remote database like DB2.

Let’s look at the other “Checkout” transaction which was breaching during the performance spike. Here is a checkout which took 9.1 seconds and deviated significantly from its performance baseline. You can see from the screenshot below the latency or bottleneck is again coming from the DB2 database:

Hardly surprising given most application scalability issues these days still relate to data persistence between the JVM and database. So let’s drill down into the JVM for this transaction and understand what exactly is being invoked in the DB2 database:

Above is the code execution of that transaction and you immediately see 8.5 seconds of latency is spent in an EJB call which is performing an update. Let’s take a look at the invoked queries as part of that update:

Nice, a simple update query was taking 8.4 seconds, notice all the other SQL queries associated with a single execution of the “Checkout” transaction. The application during this performance spike was clearly database bound and as a result a few code changes were made overnight that reduced the amount of database calls the application was making. We had one retail e-commerce customer last year who found a similar bottleneck, a fix was applied that reduced the number of database calls per minute from 500,000 to a little under 150,000. While the problem may at first appear to be a database issue (for the DBA) it was actually application logic and the developers who were responsible for resolving the issue.

You can see in the first screenshot that application response time was stable throughout the rest of the thanksgiving period , no spikes or outages occurred for this customer and all was well. While every customer will do their best to catch performance defects in pre-production and test, sometimes its not possible to reproduce or simulate real application usage or patterns, especially in large scale high throughput production environments. This is where Application Performance Management (APM) solutions like AppDynamics can help – by monitoring your application in production so you can see whats happening. Get started today with a free 30-day trial.

Appman