Cmg app migration ppt

0 views
337 views

Published on

no need g

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
0
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Originally, I pictured the difference between a typical datacenter app an the ideal SaaS app as a two-dimensional continuum, and that you could add more and more SaaS qualities to you app to make it more SaaSy.
  • But then I realized that it is not a linear continuum. Rather there are various different aspects or characteristics that a SaaS application exhibits, and your application might be strong in one area and week in others. Thus these diagrams are better at describing the differences in apps and the SaaS ideal.In the diagram, I used one spoke for each of the 5 NIST characteristics which are covered in the next section, and a 6th spoke that combines the other characteristics that I have observed. (Sorry, but 6 spokes already challenged my drawing ability, there was no way I was going beyond that!)For each spoke, the center of the hexagon means that the application does not exhibit that characteristic, while the outer edge of the means that the application fully exhibits that characteristic. A dot is placed on the line to identify the amount of that characteristic found in the app. Then lines is drawn between adjacent dots and the indie is filled in. The resulting polygon visual describes the capabilities of the application. A perfect SaaS application is of course a full-sized hexagon.
  • Issues:The typical process to enable a new employee to access an application is very manual. It involves middle-men, usually the manager and the help desk. Often the notification that the access has been granted goes back to the manager (who initiated the request), and the manager informs the employee.The process is fairly slow. It may take hours (or days) for the ticket to get processed and the employee granted access. May organizations perform this task before the employee is hired.What happens if you need to handle 100s or 1000s of requests per hour?Finally, this process assumes low volume, perhaps only a few requests per day. (Note the backlog that happens when graduates or summer interns are all hired within a few days of each other.)
  • For self-service, the user can request access to the application. Usually, the user browses to the application and clicks a Register button. This kicks off some automation which performs the necessary tasks to register the user with the application. The last step of that process is to send the user a “welcome” email telling the user how to access the application. At times, this email contains a confirmation link that the user must click on to finish the registration process.The benefits are that this process is fully automated, happens in a matter of minutes, and can handle a high volume of requests.One issue with this process is that if there are access restrictions to the application. For example, not everyone should be granted access to the payroll application. In such a case, the automation might require a manual approval step.
  • There are multiple ways that your application is accessed:Users can access it via a browserOther application can access it via web servicesOther applications can access it via other IPC mechanisms, such as direct sockets, remote EJB method calls, messaging, etc.
  • When the application is moved into the cloud, browser and web service access will still work because they use ports 80 and 443, both of which are usually open in the corporate firewall and in the cloud’s firewall. But access via other ports, such as the ones used by messaging, Enterprise Java Beans (EJBs), and other protocols will be blocked by the firewalls.Also, you will want to avoid unencrypted access. Thus use https only, not http, and encrypt the web services.
  • There are multiple ways that your application is accessed:Users can access it via a browserOther application can access it via web servicesOther applications can access it via other IPC mechanisms, such as direct sockets, remote EJB method calls, messaging, etc.
  • Once in the cloud, the application will be accessed by a number of different types of devices. And you will no control over what else the user might have on the device (anti-virus, apps, etc.). And many users will want to access the app using mobile devices such as smart phones and tablets.Ensuring that the browsers available on mobile devices work with your application is a good first step, but even better would be to have an app that loads onto the device that provides native access to your application.
  • If you offer your application services to multiple tenants, you will have to keep the data separated. Acme employees should not be able to se Apex data, and vice-versa.[click]But consider the added value if you provided a Business Intelligence service that worked on the combined data from all tenants. This would enable small and mid-size business to more effectively compete with larger businesses by making use of a larger pool of data for business analytics.
  • In the first model, each tenant gets their own VM running the application and their own database.
  • In the second model, each tenant gets their own VM(s) running the application, but they share a common database. Of course, the data still must be separated.
  • In the third model, the tenants share the VM(s) running the application, but they each have their own database.
  • In the fourth model, the tenants share the VM(s) running the application and their data is in a single database. The application must ensure that the data remains separated and there is no crossover, even if data from multiple tenant appear in a single table. Usually, the database schema includes a tenant identifier and all queries are structured to return only data related to the tenant.This is the most desired state because all of the resources are shared across all tenants, thus greatly reducing the cost to the application owner.
  • Animoto is the poster child for cloud delasticity. They developed an application that takes you photos and a music selection and automatically creates an interesting music video. Their service really took off when the added a Facebook application, especially when the Facebook app automatically created a video.Note that the application supports highly parallel processing – each music video request runs on its own.
  • How should you deploy your application into the cloud?You could choose an IaaS solution. This would be very similar to deploying your application in a VM within your data center. With IaaS, you get an VM running an OS, but in the cloud. The major difference is that the storage space assigned to the VM is very small and is intended to hold only configuration information, not application data. Cloud provides therefore provide other storage mechanism where your data can be held. This might require some changes to your application.On the other hand, if you go the PaaS route, you are looking a having to rewrite your application using one of the APIs/frameworks supported by the PaaS vendor. In some cases this might be easy (ex: you have a .Net app you want to move to Azure, or a Spring app you want to move to a cloud build on VMWare), or it migth be difficult.Another thing to consider with PaaS is that you are then locked into the vendor’s cloud, unless you can find another cloud that supports the same API/framework.There are efforts under way to create a common cloud API, but most of those APIs are for cloud and application management. Thus the API is useful for IaaS deployments, but does nothing regarding the framework differences in PaaS offerings.
  • Depending on who your users are, certain of the NIST characteristics will be of higher priority for your or your users. The chart given about is a rough estimate and of course your specific concerns might yield other priorities. But here are some examples:If deploying your app to a private cloud accessible only to your employees, self service is probably a low-importance item because on-boarding of employees is not handled that often. In other words, the user population is usually fairly stable. On the other hand, self-service becomes highly important if your users are the general plugin accessing your app in a public cloud.In general, measured service is of low important because you can always charge a flat fee. This way you don’t have to provide and sophisticated monitoring or measuring software, nor a portal for users to see their usage. Of course, if you want to charge per usage, the importance increases.Also, as you increase the scope of the users of your app, from your company’s employees, to employees in other companies (perhaps providing your app as a service to those companies), to the general public, the importance of each characteristic increases.
  • If you have a virtualized environment, you can probably fairly easily move the individual VMs in a cloud. Most cloud vendors will accept your VMs and run them.Alternately, if you have a virtual environment in your datacenter, and you want to convert to a private cloud, the cloud vendor might be able to place their cloud management solution into your datacenter, effectively bringing the cloud to your virtualized environment. We did this in the Unisys datacenter, replacing the existing virtual machine management infrastructure with the Unisys Secure Private Cloud management infrastructure.
  • Now that we have looked at the various characteristics of a SaaS application, what is the right blend of characteristics for your application? You don’t have to provide all of the characteristics, and you don’t have to provide the full characteristic. But as you decide which characteristics are important to your app (and to your customers), you will have identified the shape of your application. And perhaps you can initially meet the shape in the upper left and eventually move to the shape in the lower right.
  • Cmg app migration ppt

    1. 1. Migrating Applications to the CloudPeter Johnson (peter.johnson2@unisys.com)CMG ‘11, Washington, D.C.7 December 2011Session 454, Paper 1033
    2. 2. AbstractSo you have decided to move one or more of your enterpriseapplications to the cloud. What are some of the migration issuesthat you should consider? Which applications are a good fit for thecloud? Could you possibly offer your application as a Software as aService (SaaS) solution? This paper looks at these questions andmany more to help you understand the various possibilities whenmoving an application to the cloud and to help you better preparefor that migration. © 2011 Unisys Corporation. All rights reserved. Page 2
    3. 3. Agenda• Introduction• Cloud Reference Model – On Demand Self-Service – Broadband Network Access – Resource Pooling – Rapid Elasticity – Measured Service• Other Considerations – IaaS vs PaaS – Who are Your Users? – Networking Issues – Expect Failure – Licensing Issues – Application Lifecycle and Processes – From Virtualized to the Cloud © 2011 Unisys Corporation. All rights reserved. Page 3
    4. 4. Introduction• You have an application running in your datacenter – You want to run the application in the cloud • What does that mean?• Researched numerous cloud SaaS offerings to see what make them tick – Handling large numbers of users, large amounts of data – Understanding issues they encountered and overcame• Examined how the NIST definition of cloud computing applied to SaaS © 2011 Unisys Corporation. All rights reserved. Page 4
    5. 5. How SaaS(y) is Your App? Typical Idealdatacenter SaaS app app Is your app here? Or is it here? © 2011 Unisys Corporation. All rights reserved. Page 5
    6. 6. How SaaS(y) is Your App? Datacenter self service App network access Idealmeasure resource SaaSservice pooling self network service app access elasticity other measure resource service pooling elasticity other © 2011 Unisys Corporation. All rights reserved. Page 6
    7. 7. Agenda• Context• Cloud Reference Model – On Demand Self-Service – Broadband Network Access – Resource Pooling – Rapid Elasticity – Measured Service• Other Considerations – IaaS vs PaaS – Who are Your Users? – Networking Issues – Expect Failure – Licensing Issues – Application Lifecycle and Processes – From Virtualized to the Cloud © 2011 Unisys Corporation. All rights reserved. Page 7
    8. 8. Typical On-Boarding Process 2. Manager notifies IT, via: 1. New employee is hired • email • web page • ITSM ticket 4. Employee informed5. Employee (usually via email)accessesapplication Issues: • Manual process • Slow (hours) 3. IT grants user access, via: • Low volume • updates Active Directory • other © 2011 Unisys Corporation. All rights reserved. Page 8
    9. 9. Self-Service On-Boarding Process 1. User requests access Application registration page or portal Benefits: 5. User uses app • Automated • Fast (minutes) • High volume Issues: • Access restrictions 2. On-boarding4. User sent automation invoked “welcome” email 3. user Script registered Runbook App code © 2011 Unisys Corporation. All rights reserved. Page 9
    10. 10. Other Self-Service Considerations• No access to Active Directory with public cloud – Use database for registered users• Registration can be handled by a separate application – Might need a new home page• Think about how to unregister users – Accumulation of data users no longer care about © 2011 Unisys Corporation. All rights reserved. Page 10
    11. 11. Agenda• Context• Cloud Reference Model – On Demand Self-Service – Broadband Network Access – Resource Pooling – Rapid Elasticity – Measured Service• Other Considerations – IaaS vs PaaS – Who are Your Users? – Networking Issues – Expect Failure – Licensing Issues – Application Lifecycle and Processes – From Virtualized to the Cloud © 2011 Unisys Corporation. All rights reserved. Page 11
    12. 12. Network Access in Data Center http, https web service sockets, EJB, messaging, etc. © 2011 Unisys Corporation. All rights reserved. Page 12
    13. 13. Network Access in the Cloud disallow http access http, https encrypt web service blocked by firewall sockets, EJB, messaging, etc. © 2011 Unisys Corporation. All rights reserved. Page 13
    14. 14. Network Access in Data Center standard corporate desktop with preloaded applications standard corporate laptop with preloaded applications © 2011 Unisys Corporation. All rights reserved. Page 14
    15. 15. Network Access in the Cloud desktops & laptops running: • Windows • Mac OS X • Linux • Variety of browsers Netbooks Smart phones tablets Action plan: 1) Ensure browser works with your application 2) Provide native mobile app (UI probably written from scratch) © 2011 Unisys Corporation. All rights reserved. Page 15
    16. 16. Agenda• Context• Cloud Reference Model – On Demand Self-Service – Broadband Network Access – Resource Pooling – Rapid Elasticity – Measured Service• Other Considerations – IaaS vs PaaS – Who are Your Users? – Networking Issues – Expect Failure – Licensing Issues – Application Lifecycle and Processes – From Virtualized to the Cloud © 2011 Unisys Corporation. All rights reserved. Page 16
    17. 17. Data Sharing and SeparationAcme Inc. Business Intelligence Service Acme Inc. data Apex Ltd.Apex Ltd. data © 2011 Unisys Corporation. All rights reserved. Page 17
    18. 18. Multi-Tenancy Models - #1Acme Inc. Each tenant has own VM(s) and own database Acme Inc. Application does not data need to be tenant awareApex Ltd. Apex Ltd. data © 2011 Unisys Corporation. All rights reserved. Page 18
    19. 19. Multi-Tenancy Models - #2Acme Inc. Each tenant has own VM(s) but they share the same database Acme Inc. Application needs to be data tenant aware, but only for database access Apex Ltd.Apex Ltd. data © 2011 Unisys Corporation. All rights reserved. Page 19
    20. 20. Multi-Tenancy Models - #3Acme Inc. Tenants share the VM(s) but each has own database Application needs to Acme Inc. be tenant aware dataApex Ltd. Apex Ltd. data © 2011 Unisys Corporation. All rights reserved. Page 20
    21. 21. Multi-Tenancy Models - #4Acme Inc. Tenants share the VM(s) and the database Application needs to Acme Inc. be tenant aware dataApex Ltd. Apex Ltd. data © 2011 Unisys Corporation. All rights reserved. Page 21
    22. 22. Agenda• Context• Cloud Reference Model – On Demand Self-Service – Broadband Network Access – Resource Pooling – Rapid Elasticity – Measured Service• Other Considerations – IaaS vs PaaS – Who are Your Users? – Networking Issues – Expect Failure – Licensing Issues – Application Lifecycle and Processes – From Virtualized to the Cloud © 2011 Unisys Corporation. All rights reserved. Page 22
    23. 23. Elasticity Poster Child - Animoto EC2 Servers in Use Time (interval between text is 16 hours) Reference: http://aws.typepad.com/aws/2008/04/animoto---scali.html © 2011 Unisys Corporation. All rights reserved. Page 23
    24. 24. Elasticity Considerations• Existing applications can benefit from scale down, making resource available for other tasks• To scale up, application must be architected for it – Use multiple tiers – Use stateless design – Use distributed design• Database considerations – Use a NoSQL database for data that doesn’t need transactional semantics – Consider caching and/or sharding• Does your cloud provide automatic elasticity (EC2), or do you have to check in your application (Azure) © 2011 Unisys Corporation. All rights reserved. Page 24
    25. 25. Agenda• Context• Cloud Reference Model – On Demand Self-Service – Broadband Network Access – Resource Pooling – Rapid Elasticity – Measured Service• Other Considerations – IaaS vs PaaS – Who are Your Users? – Networking Issues – Expect Failure – Licensing Issues – Application Lifecycle and Processes – From Virtualized to the Cloud © 2011 Unisys Corporation. All rights reserved. Page 25
    26. 26. Measured Service Considerations• Who gets billed?• How will you bill? – Per request? – Request processing time? – Per megabyte moved/stored? – Flat rate per month/year?• If billing per use or by volume, provide portal where customer can check on current usage © 2011 Unisys Corporation. All rights reserved. Page 26
    27. 27. Agenda• Context• Cloud Reference Model – On Demand Self-Service – Broadband Network Access – Resource Pooling – Rapid Elasticity – Measured Service• Other Considerations – IaaS vs PaaS – Who are Your Users? – Networking Issues – Expect Failure – Licensing Issues – Application Lifecycle and Processes – From Virtualized to the Cloud © 2011 Unisys Corporation. All rights reserved. Page 27
    28. 28. Application Deployment: IaaS or PaaS? Microsoft Azure IaaS rewrite Google AppEngine Spring, etc. © 2011 Unisys Corporation. All rights reserved. Page 28
    29. 29. Who are Your Users? Importance of NISTCharacteristics Employees Low Medium Low Medium LowCompanies Other Medium Medium Low Medium Low Public High High High High Medium (Your mileage may vary…) © 2011 Unisys Corporation. All rights reserved. Page 29
    30. 30. Networking Issues Network UsageIf you have a single application running on a box, what is the network usage? Virtual LANIf you have a dozen VMs on a box, now Each VM has its own LAN, no what is the network usage? visibility of traffic of other VMs. Datacenter Access No Broadcast Support Most private cloud vendors provide Might require config changes forVPN access so that you can hook your Java EE app servers apps back to the datacenter. © 2011 Unisys Corporation. All rights reserved. Page 30
    31. 31. Expect Failure: What Could Go Wrong? App or VM crashes Datacenter goes down Solution: Run multiple Solution: Distribute app among copies, load balancer data centersTrunk line goes down Database goes downSolution: Replicate apps and Solution: Cache data updatesdatabases between regions © 2011 Unisys Corporation. All rights reserved. Page 31
    32. 32. Licensing IssuesDoes your application use software that comes from a third-party?Does your license agreement allow you to run the that software inthe cloud?• Issues: – Software locked down to MAC/IP address – License billed by machine size (e.g. CPU count) • Is that physical machine or virtual machine? – Can you fire up extra copies? (might need more for elasticity) • Will you be billed for actual copies used or potential copies? – Can you migrate the software from one cloud to another? Using open source software will help you avoid these licensing issues. © 2011 Unisys Corporation. All rights reserved. Page 32
    33. 33. Application Lifecycle• How do you introduce changes/fixes/new versions? – Some SaaS providers use rolling updates – Most SaaS provides perform regular updates (weekly, daily, even hourly), rather than major infrequent upgrades• How do you test the app? – Many cloud vendors provide desktop simulation tools • Google AppEngine SDK • Microsoft Azure SDK • etc. – Set up some tests systems in the cloud © 2011 Unisys Corporation. All rights reserved. Page 33
    34. 34. From Virtualized to Cloud © 2011 Unisys Corporation. All rights reserved. Page 34
    35. 35. Conclusion: What’s the Shape of Your App? self network service accessmeasure resourceservice pooling self network service access elasticity other measure resource service pooling elasticity other © 2011 Unisys Corporation. All rights reserved. Page 35
    36. 36. Peter Johnson (peter.johnson2@unisys.com)CMG ‘11, Washington, D.C.7 December 2011Session 454, Paper 1033 © 2011 Unisys Corporation. All rights reserved. Page 36

    ×