1. Turbocharge Your Business with a High Performance Cloud How Medtronic’s CareLink® Cloud Application Delights Doctors Worldwide Anshu Agarwal – Vice President of Marketing Keynote Systems Brent Pierson– Senior Principal IT Technologist Medtronic
8. Scheduled and emergency downtime for maintenance may not be considered in downtime calculations.
9. Proof of unavailability is the customer's responsibility. Documenting that proof can be time-consuming, and the results may be open to interpretation.
Credit Card Index - The standard Keynote Credit Card Web Transaction begins by the measurement agents entering the credit card’s respective Web site through its credit card home page 2) logging on to a credit card account. (Keynote has established standard consumer credit card accounts at all measured credit card companies.)The transaction then looks at the recent charge info in the account. The next step in the transaction is to log out. Demonstration accounts or other non-standard accounts are not used for these measurements.Retail Electronics - The standard Keynote Online Retail transaction begins by entering the retail´s Web home page searching for an itemadding it to the shopping cartproceeding to check out without logging on to an account.Apparel – The standard Keynote Online Retail transaction begins by entering the retail´s Web home page and searching for an item, adding it to the shopping cart, and proceeding to check out without logging on to an account.
3 factors to understand why cloud apps behave badly:App Construction – 50 to 60 objects on a page; it take a tollConnection Speeds – we need to understand what are the speeds of our users (eg., Plex Systems, ERP mfg systems, realized that its customers were regularly in 2G zones)Cloud Architecture is often a hybrid - Public Cloud (at top) involves db and storage interfacing with private clouds
Cloud Infrastructure – public, private, hybrid models – all require SLAs and benchmarksOrganizational Boundaries – not a trivial problem for those of you working across multiple office or regions; maybe the business made some (outsoucing/app) decisions that you are now just finding out aboutBusiness Transactions – It’s not about pages, but transaction steps users go through. As with the B2C examples, we need to understand how long it is taking to complete a typical taskRich UIs – More flash, JS cause slow downs; there are ways to solve using asynchronous transactions End Users – Mobility, great, but it makes them a moving target “why can’t I get the same access at all times?”Devices – device/browser combo more important than ever
Further you are, the more latency. But having multiple data centers is expensive.
Networks are complex and with the cloud as a tool it helps to think of these different elements different logical components, each which requires monitoring. Your network will have many if not all of these. Logical components include:Users – who and where? DSL? T-1 Office? Int’l mobile (oh and how about those telecom costs?)CDNs - helping deliver content . . . Consistently?Private Clouds – One of our customers has taken 1 data center our of several and move it into the cloud (i.e., cloud platform)Intra Cloud communication, e.g. between geographical distributed locations and regional data center clusters3rd parties who can deliver content direct to your users and/or to your serversPublic CloudsNOC(s): Must be able to communicate with your clouds, especially critical when spawning new resources on an as needed basis. And triage quicklyNeed to address these elements
Needs to be bullet proof, just has to be upPatient follow-up with a focus on clinic efficiencyIt’s not a website or cloud svc, it’s a patient system – that’s what Medtronic’s commitment to patientsProduct quality not svc levels
Latency issues – external service provider (CDN) accelerationNew product demands requiring reach outside the datacenterComplexity of deployment – global, many service providersCustomer demand faster response but more platforms (mobile challenge)
1 – monitoring Medtronic service providers (e.g., messaging) from inside the DC2 – monitoring application (DC) from proximity to end user3 – integrating all monitoring data into EMS for diagnostics (where is the problem occurring?) and smart alerts
1) Monitor as frequently as possible and from many locations2) Monitor while you are conducting ‘real world load testing’ (not inside the lab)3) Performance varies across browsers and devices