A perspective on cloud computing and enterprise saa s applications
•Télécharger en tant que PPTX, PDF•
2 j'aime•1,043 vues
A perspective on Cloud computing and SaaS for Enterprise applications by a SaaS industry veteran. Please make sure you read the speakers notes, there's a significant amount of content there.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à A perspective on cloud computing and enterprise saa s applications
Similaire à A perspective on cloud computing and enterprise saa s applications (20)
Dernier
Dernier (20)
A perspective on cloud computing and enterprise saa s applications
- 1. A PERSPECTIVE ON CLOUD COMPUTING AND ENTERPRISE SAAS APPLICATIONS George Milliken February 8, 2012 Copyright © George Milliken and Todd Varland portions copyright their respective owners as noted in reference section
- 2. Who Am I? George Milliken, Director of Solution Delivery in CA Technologies SaaS Hosting division Manage the Database Architecture and the Service Introduction teams Provide the technical architecture and program management necessary to introduce new enterprise applications into production as Software as a Service (SaaS)
- 3. Objectives • Quickly cover some basic terms • Outline the challenge and opportunity cloud computing presents to enterprises • Talk about some things to consider as both a consumer and provider of SaaS • Emphasize key concepts
- 4. Cloud Computing is a Pervasive Topic Search Google and you get 327,000,000 hits Scholastic (K-12) Education – Articles in Cloud applications in K12
- 5. 80% of enterprises surveyed have already deployed at least one cloud service. Over 50% have deployed six or more cloud services, while maintaining legacy infrastructures. Enterprises are rapidly adopting cloud services to gain efficiencies and speed time to market for new business services Distributed Internet Virtual Cloud Mainframe 5 Image copyright © CA Technologies 2012 All Rights Reserved
- 6. What is Cloud Computing? • Extension of SaaS • Why buy when you can rent? • Cost-effective for consumers of Cloud • Highly profitable for large data centers
- 7. Economic Shift Positive TCO Shift Economies of Scale Moore’s Law Redux New Buyers (Business not IT) Opex v. Capex Departmental v. Enterprise Business Unit Decision Maker v. Central IT
- 8. Economic Shift Negative Financial Distortions Not counting capital in a sensible manner Not counting labor costs Not tracking the costs of outages Impact of Failing to Achieve Economies of Scale Tragedy of the Commons Costs need to factor in new requirements driven by cloud Are you good at running data centers? Really?
- 9. IT will be accountable for management and security across a diverse range of cloud and traditional models The New Heterogeneity Which applications do we move to which cloud models when? How do we minimize security, compliance and availability risks? How do we avoid vendor lock-in? Which operational processes do we keep, tweak or transform? How do we make sure it is all working together for business value? New Questions Fabric Converged infrastructure New datacenter Existing datacenter Virtualization Hybrid Cloud Use IaaS Traditional services Build on PaaS Use SaaS Private cloud Cloud burst 9 Image copyright © CA Technologies 2012 All Rights Reserved
- 10. SaaS Middleware Database Virtualization/ Operating System Cloud Computing/ SaaS Applications Enterprise Data Center/Private Cloud Additional complexity is created by the cloud 10 Top 5 challenges of cloud computing – Management of hybrid world – Performance monitoring – Reliability/service assurance – Automating service delivery across platforms – Security Middleware Database Virtualization/ Operating System Public Cloud SaaS Infrastructure SaaS Applications Virtualization / Operating System Database Middleware Servers Storage Networking Applications All trademarks, trade names, service marks and logos referenced herein belong to their respective companies Image copyright © CA Technologies 2012 All Rights Reserved
- 11. Storage Storage Storage Network z/OS Unix Linux Windows Network Hyper Storage Private IaaS Private IaaS Hosted PaaS Hosted PaaS Integrated L W L W Hyp L W L W Hyp W W W W Hyp Physical Virtual Cloud infrastructure layer complex technologies, many vendors and deployment models 11 Automate Manage Secure Infrastructure Layer What’s in your portfolio? Image copyright © CA Technologies 2012 All Rights Reserved
- 12. Enterprise Applications Composite Applications SaaS Applications CRM ERP Email Office Automate Manage Secure Infrastructure Layer application layer 12 What’s in your portfolio? Application Layer Automate Manage Secure Image copyright © CA Technologies 2012 All Rights Reserved
- 13. Automate Manage Secure Infrastructure Layer services layer focus on delivery and consumption of IT as a service 13 Application Layer Automate Manage Secure Technology Services Information Services Cloud Services What’s in your portfolio? Services Layer Automate Manage Secure Image copyright © CA Technologies 2012 All Rights Reserved
- 14. Cloud, Iaas, SaaS, PaaS SaaS CA Clarity Nimsoft Salesforce Netsuite Gmail SuccessFactors PaaS Force.com Heroku OpenShift Azure Cloud Amazon Google IBM IaaS Rackspace Opsource Carpathia
- 15. On Premise Delivery Model On Premise More control Traditional revenue model More customization possible
- 16. SaaS Not necessarily multi-tenant Different revenue model Trade off cost savings for loss of control Loss of control is not a bad thing Shift TCO to the vendor!
- 17. Please Point this Application at the Internet! On premise to SaaS Pit Falls Who’s the Line of Business “owner”? What’s the service catalog 2 or 3 customers is easy - 600 is hard - requires a number of systems to be in place “as a Service” Gaps (a cautionary tale) Identity, Backup, Restore, Refresh…. Metering and billing
- 18. Common “as a Service” Gaps Provisioning Refresh Usage metering Support Portal Diagnostics & instrumentation CMDB & CRM Notification Tenant Placement / Move tenant
- 19. Orchestration Required to build and deploy complex services cost- effectively More than just imaging, it’s about the fulfillment process used to deliver a defined service Involves combining business processes with technology processes to deliver a business solution Working application Billing and metering Scaling
- 20. Orchestration Vendors CA Technologies Gale Technologies TIBCO Oracle IBM Open Source Options – Check Out JuJu Puppet Chef OpenStack
- 21. Think Services Services are what matters Can you efficiently leverage the cloud to provide services? Can you move or fail a service between clouds? Can you scale up if needed (cloud burst)?
- 22. Successful SaaS Development Agile Scrum team focused on SaaS issues Be the Product Owner v. Customer More than release planning, what’s the mechanism look like? Automate everything, touch nothing (write scripts that write scripts) Consider DevOps Approach Examine your ITIL alignment
- 23. Dev Ops DevOps is a lean approach to operations Minimize the information loss during handoffs by blending teams Dev->Test->QA-> Prod Image copyright © Damon Edwards 2012 All Rights Reserved
- 24. Think Dev Ops Build internal Expertise Outsource a well-defined objective (offering) Benefits Release cycle time Software mostly works (as opposed to mostly doesn’t) Lower deployment costs Ability to instrument and measure deployment cycle Prevent “aaS” as a service gaps
- 25. Talk to Operations to Gather Operational Requirements Get Your Operational Groups Input Don’t Build Cloud Orchestration in a vacuum You have a wealth of knowledge in house Tap that knowledge to understand the operational issues you face This will greatly assist you in deciding what to orchestrate, how to do it
- 26. The Ideal – White Cloud Apps Everyone runs the same version Great new features released often Bugs are fixed rapidly (often without the user even knowing it existed) Customer Service is Exceptional
- 27. Reality the “Dirty cloud” Multiple versions in production Releases still take a long time Bugs fixes and patching complicate the service Customer Service is more complex
- 28. Why Many Company Build Dirty Clouds Central IT has power We have idle servers We think we’re good at IT But are you good at rendering a service?
- 29. Attributes of real cloud offerings Orchestrated Services Auto-provision / De-provision Pay as you go – Metered and measured service Choice can be exercised up to the point of purchase Self-service Capacity on demand API – Programmatic interface Chargeback and Showback visibility
- 30. Multiple Clouds Vendors Can Add Complexity Why would you use multiple vendors? Issues Common to Multi Vendor (or data center) situations Multiple VPNs can be a pain Integrated on call support call trees is a pain CMDB is critical
- 31. Multiple Clouds Vendors As a Strategy Prevent lock in Address regional concerns Keep your options open
- 32. What’s my SLA? Is it up? What does “up” mean? How measured? What’s planned v. unplanned maintenance? What’s the remediation for missed SLAs?
- 33. 99.9% Uptime What’s it mean? What’s it take? Practical Considerations 99.5 = 43.2 hours a year 99.9 = 8.76 hours a year (3 nines) 99.999 = 5.26 minutes a year (5 nines)
- 34. Deployment Considerations Interlocking Development Life cycles Change Control Operational Readiness Testing (ORT) What is ORT Need for ORT
- 35. SaaS Operational Readiness Testing (ORT) • Support Access to • Logs • Customer Environments • Performance Reports • Configuration Interfaces • Monitoring Systems • Alerts • Performance Testing • Batch Processing • Outside In Performance • Upgrade Testing • Upgrade to new version(s) • Migration Testing • Migrate to new version(s) / platform • Release Testing • Release process verification • Contingency Plan • Rollback during Cutover • Technical Testing • Failover / HA • End-to-End Testing • Applications/HW/SW/Network • Backup / Restore • Monitoring/Alerts • Security Testing • Log-on / Authentication / Authorization • Operations Testing • Run Books Simulation • SLA/SLO Confirmation • Compliance Readiness • Impacted Apps (e.g. CHSOPS) • Patching • Provisioning • Environment Refresh • Top 10 Service Catalog Items • Top 5 Troubleshooting Requests
- 36. Support Considerations Interlocking Support Organizations Ticket Flow CMDB
- 37. InfoSec Concerns Embedded Passwords (at rest) Password changes Personally Identifiable Information Encryption Federated Identity
- 38. Privacy Where’s my data? Who has access? Can I have access? Regional considerations Where are you? Where are your customers? Patriot Act
- 39. Compliance SAS70, SSAE16 - what is this? why it’s important, why it can be misleading
- 40. Summary For SaaS remember Product != Service For the cloud think Multi-vendor Use of ITIL, Agile and DevOps methods are pieces to the puzzle SaaS Customers expect more thank on premise
- 41. QUESTIONS?
- 42. References • Defense Information Systems Agency http://disa.mil • Above the Clouds: A Berkeley View of Cloud Computing • CA Technologies Corporate Overview Portions Copyright © 2011 CA. All rights reserved. • Guidelines on Security and Privacy in Public Cloud Computing (NIST Special Publication 800-144) http://www.nist.gov/manuscript-publication-search.cfm?pub_id=909494 • NIST Definition of Cloud Computing http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf • National Institute of Science and Technology. Retrieved 24 July 2011. "The NIST Definition of Cloud Computing". • Wikipedia “High Availability Calculations” http://en.wikipedia.org/wiki/High_availability • “Continuous Delivery” by Jez Humble http://continuousdelivery.com/ • http://www.businessweek.com/news/2011-12-15/white-house-seeks-to-spur-cloud-computing-use-by-agencies.html • “Continuous Delivery Patterns and Antipatterns in the Software Lifecycle” by Paul M. Duvall http://refcardz.com • Software as a Service: Strategic Backgrounder; SIIA 2001 • “DevOps is not a Technology Problem” by Damon Edwards http://dev2ops.org/blog/2010/11/7/devops-is-not-a- technology-problem-devops-is-a-business-prob.html
- 43. TERMINOLOGY SaaS: Software as a service PaaS: Platform as a service IaaS: Infrastructure as a service Cloud: Combination of IaaS, PaaS, and SaaS which is elastic, metered, elastic and has the illusion of infinite capacity. FISMA: Federal Information Security Management Act Hosting: a service that runs Internet servers such as an ISP ISP: Internet service provider. A company that hosts web sites and provide virtual servers in a traditional hosting mode. Single Tenant Apps: Traditional N tier enterprise application stack. Multi Tenant Apps: SLA: Service Level Agreement TCO: Total Cost Of Ownership SOA
- 44. TERMINOLOGY (CONT’D) VPN: Virtual Private Network SDLC: Software Development Life Cycle CMDB: Configuration Management Database. CRM: Customer Relationship Management API: Application Programming Interface ORT: Operational Readiness Testing ITIL: Information Technology Infrastructure Library IDM: Identity Management ASP: Application Service Provider
Notes de l'éditeur
- Thank you for the opportunity to meet with you today. I’ve worked as a consultant at Wells Fargo Bank three times over the last 15 years. Wells has always been a leader in the use of technology and a great place to work. In many ways banking applications where the first SaaS offerings and in that sense you’ve been in the cloud for years. Today I’m going to talk about Cloud computing at a high level Then touch on SaaS versus the traditional on-premise software model I’ll then go over some key concepts to keep in mind when offering SaaS Next we’ll talk about some complications that arise in SaaS for Enterprise Applications After that we’ll talk about Concerns to address as a consumer of SaaS followed by concerns for providers of SaaS I probably have more material than we have time, so please feel free to ask questions as we go.
- Discuss Service Introduction a little Service Introduction is the program management process which facilitates the preparation of people, processes and infrastructure for a new SaaS offering. A key Service Introduction activity is operational readiness testing (ORT).
- Key Concepts Focus on Managing Services not Things Focus on Avoiding lock in through multi-cloud solutions (APIs etc) Become aware of the pitfalls that affect enterprise SaaS offerings Use that awareness to plan and chose wisely when you deply into the cloud Think about new and different deployment approaches (Agile, DevOps) Think about Building feedback loops (show-backs and charge-backs)
- Cloud computing has quickly moved from a buzzword to the top of the agenda for many IT departments. Schools are teaching classes on cloud computing. The Military has cloud computing centers available now for internal use. The White House is urging agencies to adopt cloud computing. It’s true that due to security concerns the Federal government’s use of cloud computing is different and more expensive than private industry. Definitions vary but everyone agrees it’s no longer a buzzword or fad; cloud computing is a paradigm shift. Even school children are talking about the “cloud”
- IT organizations are challenged to move quickly to deploy new technologies that offer the promise of future cost and performance efficiency gains. The challenge is that they need to continue to leverage existing assets from past technology investments because many core applications and services are still rooted in legacy computing environments while simultaneously absorbing and incorporating new technologies and service delivery methodologies. Each new computing paradigm addresses challenges and deficiencies from the previous generation, however nothing ever seems to go away. And unlike previous decades, these service delivery advances are appearing much faster which further challenges IT organization’s ability to keep pace. According to a recent study by Management Insight Technologies (“The Arrival of Cloud Thinking”, November 2010) over 80% of large enterprises (1000 or more employees) have already deployed at least one cloud service and over 50% have deployed 6 or more cloud services. Automation is a key capability that can help IT organizations keep up with the rapidly changing technology landscape while leveraging their existing assets for delivering business services. Orchestration end to end is a key factor we’ll discuss later as well.
- In many ways the benefits of cloud computing are the same as SaaS. SaaS (or ASP as it was called 12 years ago) is the idea that users can shift TCO to the software vendor (or hosting service) and pay a per seat rental fee rather thank buy a perpetual license. the consumer of the service gets the following benefits: Quick start up Management of the app by skilled professionals focused on that app Benefits of scale without the scale Monthly fee instead of large upfront purchase Cloud computing offers these same benefits in the hardware space.
- In the past IT organizations attempted to manage change and complexity through single-vendor solutions to computing. The IBM Compatible PC was introduced to allow multiple vendors to compete at the hardware layer while preserving corporation investment in the software layer. Linux had a similar effect on mid-range distributed systems computing. Today, when you think about cloud computing it’s less important to pick the right cloud vendor than it is to pick the right multi-vendor strategy. You need to avoid lock in by picking strategies and tools that allow you to abstract vendor differences. Cloud computing is a fairly abstract term to some, so asking to add a layer of abstraction on top of that can be a little confusing but it may be the best approach to preserve your investment in cloud computing.
- [Click] If this slide looks confusing…that’s good. Because that’s the point. And what emerges from this complex picture is the compelling need to address the top 5 challenges of cloud computing: Management of hybrid environments, Performance monitoring, Service assurance, Automating service delivery across platforms, and Security. Adding cloud computing into the mix is like adding another layer of two to an already complex problem. Similar to the mind shift that occurred when we introduced SOA and middleware.
- This slide is showing you the continuum from legacy physical data centers on the left to the managed “puffy white cloud” vision on the right. Within your datacenter you’ve probably got a tremendous number of options from a wide variety of vendors. And even if you’ve standardized on one particular vendor or platform going forward, legacy systems, applications and services are most likely still an essential part of your infrastructure -- in some cases with mission critical implications for your business. Mergers often leave us with non-standard mission critical hardware and software. As you move to cloud options, you can select Infrastructure as a Service, Platform as a Service and private (integrated stack) and public cloud options from a number of vendors. How do you take advantage of the benefits (agility, flexibility and cost) of cloud computing at the infrastructure layer and still ensure that your service levels are met and your business users are satisfied? Where are you on this continuum? Most organizations see the benefits in moving to the right, but are still trying to grapple with managing the complexity.
- Next let’s examine the application layer; this is what your business users care about. Again, here IT organizations are dealing with a variety of options, some old, some new. They should be concerned with how to: Automate for efficiency, Manage to ensure that the specific business service is meeting the requirements of the business, and Secure to protect critical information and access to sensitive systems and data. Again, it’s interesting to consider where you are on this continuum. As you move further to the right, complexity goes up and your challenges increase significantly.
- [Click] Finally, let’s examine the challenges at the services layer. For most IT organizations, this layer may be the most challenging, because of the introduction of intelligent mobile devices. Just as with the infrastructure and applications layers, the emphasis at the access layer must be on: Automation for efficiency, Management for ensuring service delivery, and Security to protect critical business information.
- Here’s a partial list of a few well known players in each space. The lines are blurry, as in most markets some of these players have offerings in several categories. For instance Rackspace and OpSource both have cloud offerings, Google has a PaaS Offering ( App Engine)
- On Premise software is what’s now viewed as traditional (legacy) software. You get a ISO and install it. Or a team of professional services consultants fly in and install the software in your data center. On Premise allows for customization. On premise allows for feature rich products which are influenced by the largest customers. This is due to the pricing model which is based on a single large purchase of a perpetual license followed by maintenance fees. On Premise allows the customer to manage the compliance and information security aspects of the installation themselves. On Premise allows the customer greater control over maintenance.
- SaaS is Software as a service. Also known as “On Demand”. Software and data are co-located in a central data center and customers access the service via thin clients over the Internet. Considered a part of cloud computing. This is an extension of the ASP model. Single Tenant App – Like Enterprise On Premise software but the data and app are installed in a vendor data center and managed by the vendor. This is SaaS although for marketing reasons some vendors state that single tenant apps are not SaaS but this is not actually true. You aren’t buying the “app” your buying the service (i.e. SLA). Performance issues between tenants can be minimized physically in this model <explain>. Meta data is maintained outside the application. This can lead to costly inefficient operational processes. Errors in meta data can lead to customer satisfaction issues. Multi Tenant app – The there is just one copy of the app for all customers. This single instance serves multiple customers. All meta data is encapsulated in the application. Development can be more complex, particularly if the need exists to patch or upgrade customers separately. Deployment of new release is simplier. Impact of outages can be more severe since all the eggs are in one basket. There are, of course, ways to mitigate those risks. SaaS is typically sold on a subscription basis, not in a lump sum purchase. This is transforming the sales organizations which are now having to focus (and compensate) on MRR not contract value. Typically sold per seat with up charges for storage or other capacity factors. Typically less opportunity to customize although integrations are common. Users expect better faster support and quicker feature delivery and bug fix turnaround. These expectations are actually contrary to the SaaS model for enterprise software (bug fixes imply mass upgrades or multiple versions in production). There is an expectation that there is only one version in production however with enterprise software that’s often not possible due to conflicts in the vendor and customers budget and SDLC cycles. <explain>
- When you move an enterprise app to a SaaS offering you have to think about the “service” not the product. Many companies stumble here. They effectively give the ISO to an operational group and say “Point this at the Internet!” They craft a pitch for a service, fire up the sales machine and start logging sales. The “as a service gaps” are not devleoped, nor are the operational groups funded and staffed to plug the gaps. At first this is not noticeable, but later, as sales pick up, the gaps are revealed through cost and loss of customer satisfaction.
- When you move an enterprise app to a SaaS offering you have to think about the “service” not the product. Many companies stumble here. They effectively give the ISO to an operational group and say “Point this at the Internet!” They craft a pitch for a service, fire up the sales machine and start logging sales. The “as a service gaps” are not developed, nor are the operational groups funded and staffed to plug the gaps. At first this is not noticeable, but later, as sales pick up, the gaps are revealed through cost and loss of customer satisfaction. Support Portal is particularly important. Customers expect SaaS to be supported better, quicker, cheaper because the vendor has the software and the data. Therefore support must step up to directly access the customer environment and perform triage. This raises the bar for support organizations.
- Of course there is more to it than simply pointing your application at the Internet. Which leads in orchestration. Orchestration doesn’t come with the cloud automatically. What I’m referring to is orchestration of the various layers of a business solution into a unified service. Example: A new instance of an application needs to be deployed. This involves updating the CMDB, possibly a CRM system, a load balancer, spinning up one or more app servers and deploying a database or perhaps just a set of schemas into a shared database. In this case a decision about WHICH shared database has capacity will also have to be resolved. In order to answer this question information from the SLA or contract with the customer will be needed (i.e. how much storage, # users, etc). In a traditional model this would require several groups, perhaps several tickets, and an error prone (or expensive) coordination among (app sysadmins, DBAs, storage engineers, network engineers, and sales/support). With orchestration this can be performed in minutes from a web interface. This is a simple example. Orchestration of complex services deployed in the cloud requires coordination across company boundaries. Cloud APIs can ease this burden when properly applied to the problem.
- Three things are needed to build a cloud Network infrastructure Storage Servers Orchestration software allows management of the three above items efficiently
- When you consider building private clouds or moving into a public cloud you need to justify the decision. Think about that justification in terms of your services you provide to your customers. Is the cloud cheaper? (check closely) Is it safer? Higher performance? Justify the decision in business terms. This will then help guide other downstream decisions.
- The most successful SaaS deployments I’ve seen were dpeloyed by teams that had some ITIL training, and Agile approach and a DevOps mindset. No one team was perfect but they all had some blend of these methods that helped them be successful.
- DevOps as a mind set and orchestration go hand in hand. DevOps is a shift away form the silo orientation in many IT shops toward an Agile like orientation. Developers, QA and operations collaborate to delivery better services into production at lower cost and high satisfaction. DevOps is driven by, but also facilitates the use of data center automation. Bridging the gap between development and data center operations cuts the cost and time to deploy new applications. For SaaS offerings this is critical. DevOps and SaaS Agile scrum teams are how we prevent “as a service Gaps”. As a service gaps are created when the applications doesn’t meet the commitments of the service. These gaps are plugged with manual processes, trouble tickets and unhappy customers.
- Tap into the wealth of experience your operations teams can provide to the development teams DevOps is driven by, but also facilitates the use of data center automation. Bridging the gap between development and data center operations cuts the cost and time to deploy new applications. For SaaS offerings this is critical. DevOps and SaaS Agile scrum teams are how we prevent “as a service Gaps”. As a service gaps are created when the applications doesn’t meet the commitments of the service. These gaps are plugged with manual processes, trouble tickets and unhappy customers.
- On of the biggest mistakes I’ve seen happen over and over again is developers that “know” what needs to be done for operations but never spend any time studying operations or working in operations. They build the wrong things, they make GUIs where automation is needed, it can be a mess Bridge that gap The non-functional requirements are the “as a service” gaps. Example: Refresh environments <describe>
- The ideal cloud app is the one the marketers want us to envision. Unfortunately this is more likely to exist in the consumer oriented SaaS market than in the B2B SaaS market. This is due to a number of structural factors
- Enterprise apps can be tricky Multiple environments (DEV TEST PROD) Interlocking SDLC life cycles (Vendors and Yours) Interlocking change control Training required when UI changes Operational changes need to be propagated properly to offshore teams Period end blackouts on maintenance Vendors really matter -> Holiday shutdown- Are you kidding me? That’s not elastic Think about your integrations Integrations mean you are not going to have a “gmail” like experience Upgrades take time, energy and are complex, require operational readiness testing to reduce risk (see ORT) Decommissioning, no one seems to be good at it, you will pay for not decommissioning, decommissioning is risky
- You can use IT Management tools to gather your existing resources into pools and then offer them as a private cloud to your users. Before you do that think it through. Make sure you’re willing to make the shift to offering a service (and be good at it). Consider the cost of investing in software and systems to integrate legacy systems versus waiting for the next tech refresh cycle to roll out greenfield systems that are designed for this purpose.
- Multiple cloud vendors adds to the complexity of your movement to the cloud but may be worth it in the long run to prevent lock in. Also sometimes multiple vendors are required due to Geo-political issues (Patriot Act, HMRC) Points of presence Cost in certain countries Multi-vendor issues include things such as separate AD domains, need for multiple VPNs and the difficulty in inter-locking support organizations. Meta data management is difficult CMDB CRM Communications
- Many companies choose to use multiple cloud vendors as part of a strategic plan to avoid vendor lock in and encourage development of cloud bursting or hybrid solutions. This strategy also works out well if one vendor fails to meet your expectations or changes their pricing. A multi-vendor solution may be required in order to have a presence in all the geographic areas you serve.
- Here’s where things get complicated. You have to read the SLA. Typically unplanned downtime is all that counts. Planned downtime doesn’t. But a vendors planned downtime may not be compatible with YOUR PLANS. It also might not be planned very far in advance. So look closely at the SLA for these factors. How do they measure “up”. Is it ping? Or do they have a sophisticated monitoring tool that measures outside in from various locations around the world? Do you have financial penalties for missing the SLA? Do you need to claim and prove the missed SLA in order to get compensation? How will you do that? This is a big “as a service gap”.
- Let’s talk about uptime. What matters is uptime on the SERVICE not some individual component or VM. Most vendors will have difficulty moving a trouble ticket through their organization fast enough to truly meet 3 nines or 5 nines. It’s important that you also look at service degradation versus outages. How can you measure and address these issues? Is there a capability in the cloud offering to do this or do you need to build your own systems to monitor your cloud?
- Here’s some examples of the things we do in ORT for new SaaS offerings
- Many organizations are like M&Ms when it some to InfoSec. Hard on the outside soft in the middle. If this is you then think about the exposure risk and the remediation costs involved in correcting things like embedded passwords for service accounts. Make sure you examine the exposure of personally identifiable information. Two areas which are very important are information protection through the use of encryption and identity management. These are “as a service gaps” typically which can be difficult and costly to address. Unless your enterprise already has a shared solution you can leverage it’s best of IDM and encryption are designed into the service and built out as part of the service.
- You move to the cloud will naturally lead to concerns about your customers’ data. In addition to questions that you might normally expect about data protection and access there are a couple of things you need to consider that aren’t so obvious. EMEA customers typically will not allow sensitive financial or company confidential data to be stored within the US due to the Patriot Act Foreign governments often want their data stored on their sovereign territory This may affect your DR strategy This may affect your support strategy (UK government “no touch by India” policy for instance) Audit standards may different in different countries Encryption may be more complicated due to regulations The cloud is getting a little dirtier
- Compliance is not an area of expertise for me. I do have a colleague that can come in and talk about FISMA, SSAE16 and SAS70. I’d like to briefly mention that it can be very misleading. Just because a data center vendor has a SAS70 or SSAE16 doesn’t mean that your service, when placed in that cloud will suddenly be SSAE16 or SAS70 compliant. Likewise, question vendors when they state they are compliant, especially if you are using a multi-vendor solution. It pays to ask.
- Many things to factor into offering a new Service
- Microsoft Confidential
- Microsoft Confidential