1 / 36

Migrating Applications to the Cloud

Migrating Applications to the Cloud. Peter Johnson ( peter.johnson2@unisys.com ) CMG ‘11, Washington, D.C. 7 December 2011 Session 454, Paper 1033. Abstract.

ross
Download Presentation

Migrating Applications to the Cloud

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Migrating Applications to the Cloud Peter Johnson (peter.johnson2@unisys.com) CMG ‘11, Washington, D.C. 7 December 2011 Session 454, Paper 1033

  2. Abstract So you have decided to move one or more of your enterprise applications to the cloud. What are some of the migration issues that you should consider? Which applications are a good fit for the cloud? Could you possibly offer your application as a Software as a Service (SaaS) solution? This paper looks at these questions and many more to help you understand the various possibilities when moving an application to the cloud and to help you better prepare for that migration.

  3. Agenda • Introduction • Cloud Reference Model • On Demand Self-Service • Broadband Network Access • Resource Pooling • Rapid Elasticity • Measured Service • Other Considerations • IaaSvsPaaS • Who are Your Users? • Networking Issues • Expect Failure • Licensing Issues • Application Lifecycle and Processes • From Virtualized to the Cloud

  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

  5. How SaaS(y) is Your App? Typical datacenter app Ideal SaaS app Is your app here? Or is it here?

  6. How SaaS(y) is Your App? Datacenter App networkaccess self service Ideal SaaS app resource pooling measure service networkaccess self service other elasticity resource pooling measure service other elasticity

  7. Agenda • Context • Cloud Reference Model • On Demand Self-Service • Broadband Network Access • Resource Pooling • Rapid Elasticity • Measured Service • Other Considerations • IaaSvsPaaS • Who are Your Users? • Networking Issues • Expect Failure • Licensing Issues • Application Lifecycle and Processes • From Virtualized to the Cloud

  8. Typical On-Boarding Process • 2. Manager notifies IT, via: • email • web page • ITSM ticket 1. New employee is hired 4. Employee informed (usually via email) 5. Employee accesses application • Issues: • Manual process • Slow (hours) • Low volume • 3. IT grants user access, via: • updates Active Directory • other

  9. Self-Service On-Boarding Process Application registration page or portal 1. User requests access • Benefits: • Automated • Fast (minutes) • High volume • Issues: • Access restrictions 5. User uses app On-boardingautomation invoked User sent“welcome”email userregistered ScriptRunbook App code

  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

  11. Agenda • Context • Cloud Reference Model • On Demand Self-Service • Broadband Network Access • Resource Pooling • Rapid Elasticity • Measured Service • Other Considerations • IaaSvsPaaS • Who are Your Users? • Networking Issues • Expect Failure • Licensing Issues • Application Lifecycle and Processes • From Virtualized to the Cloud

  12. Network Access in Data Center http, https web service sockets, EJB, messaging, etc.

  13. Network Access in the Cloud disallow http access X http, https encrypt web service X blocked by firewall sockets, EJB, messaging, etc.

  14. Network Access in Data Center standard corporate desktop with preloaded applications standard corporate laptop with preloaded applications

  15. Network Access in the Cloud • desktops & laptops running: • Windows • Mac OS X • Linux • Variety of browsers Netbooks Smart phones tablets Action plan: Ensure browser works with your application Provide native mobile app(UI probably written from scratch)

  16. Agenda • Context • Cloud Reference Model • On Demand Self-Service • Broadband Network Access • Resource Pooling • Rapid Elasticity • Measured Service • Other Considerations • IaaSvsPaaS • Who are Your Users? • Networking Issues • Expect Failure • Licensing Issues • Application Lifecycle and Processes • From Virtualized to the Cloud

  17. Data Sharing and Separation Acme Inc. BusinessIntelligenceService Acme Inc. data Apex Ltd. data Apex Ltd.

  18. Multi-Tenancy Models - #1 Acme Inc. Each tenant has own VM(s) and own database Acme Inc. data Application does not need to be tenant aware Apex Ltd. Apex Ltd. data

  19. Multi-Tenancy Models - #2 Acme Inc. Each tenant has own VM(s) but they share the same database Acme Inc. data Application needs to be tenant aware, but only for database access Apex Ltd. data Apex Ltd.

  20. Multi-Tenancy Models - #3 Acme Inc. Tenants share the VM(s) but each has own database Application needs to be tenant aware Acme Inc. data Apex Ltd. Apex Ltd. data

  21. Multi-Tenancy Models - #4 Acme Inc. Tenants share the VM(s) and the database Application needs to be tenant aware Acme Inc. data Apex Ltd. Apex Ltd. data

  22. Agenda • Context • Cloud Reference Model • On Demand Self-Service • Broadband Network Access • Resource Pooling • Rapid Elasticity • Measured Service • Other Considerations • IaaSvsPaaS • Who are Your Users? • Networking Issues • Expect Failure • Licensing Issues • Application Lifecycle and Processes • From Virtualized to the Cloud

  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

  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)

  25. Agenda • Context • Cloud Reference Model • On Demand Self-Service • Broadband Network Access • Resource Pooling • Rapid Elasticity • Measured Service • Other Considerations • IaaSvsPaaS • Who are Your Users? • Networking Issues • Expect Failure • Licensing Issues • Application Lifecycle and Processes • From Virtualized to the Cloud

  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

  27. Agenda • Context • Cloud Reference Model • On Demand Self-Service • Broadband Network Access • Resource Pooling • Rapid Elasticity • Measured Service • Other Considerations • IaaSvsPaaS • Who are Your Users? • Networking Issues • Expect Failure • Licensing Issues • Application Lifecycle and Processes • From Virtualized to the Cloud

  28. Application Deployment: IaaS or PaaS? Microsoft Azure Application PaaS ? SQL Azure IaaS rewrite Google AppEngine data data Spring, etc.

  29. Who are Your Users? Importanceof NIST Characteristics Measured Service Network Access Resource Pooling Self Service Elasticity Low Medium Low Medium Low Employees Other Companies Medium Medium Low Medium Low High High High High Medium Public (Your mileage may vary…)

  30. Networking Issues Network Usage If you have a single application running on a box, what is the network usage? If you have a dozen VMs on a box, now what is the network usage? Virtual LAN Each VM has its own LAN, no visibility of traffic of other VMs. Datacenter Access Most private cloud vendors provide VPN access so that you can hook your apps back to the datacenter. No Broadcast Support Might require config changes for Java EE app servers

  31. Expect Failure: What Could Go Wrong? Datacenter goes down Solution: Distribute app among data centers App or VM crashes Solution: Run multiple copies, load balancer ? Trunk line goes down Solution: Replicate apps and databases between regions Database goes down Solution: Cache data updates

  32. Licensing Issues Does your application use software that comes from a third-party? Does your license agreement allow you to run the that software in the 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.

  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

  34. From Virtualized to Cloud

  35. Conclusion: What’s the Shape of Your App? networkaccess self service resource pooling measure service networkaccess self service other elasticity resource pooling measure service other elasticity

  36. Peter Johnson (peter.johnson2@unisys.com)CMG ‘11, Washington, D.C. 7 December 2011 Session 454, Paper 1033 Thank you! Questions?

More Related