Your SlideShare is downloading. ×

Best practices for application migration to public clouds interop presentation

547

Published on

Best Practices for Application Migration to Public Clouds …

Best Practices for Application Migration to Public Clouds
Talk given at Interop May, 2013.

Whether you are thinking of migrating 1 application or 8000 applications to the cloud, the odds of success increase if best practices are followed. Do you know what those best practices are?

As hustler Mike McDermott said in the 1998 poker movie Rounders, “If you can't spot the sucker in the first half hour at the table, then you ARE the sucker.”

Anyone with a credit card can sit at the table of trying to move applications to public clouds. Those who want to succeed, study and learn from consistent winners. There are some hands to fold, some to play cautiously, and some to play aggressively.

This session covered best practices from helping 15 Fortune 1000 companies successfully migrate to cloud solutions.

Who should attend?
Anyone who wants to improve their odds of successfully migrating applications to public clouds.

Key Takeaways
• What are the key business considerations to address prior to migration?
• Which application workloads are suitable for public clouds?
• Which applications to replatform? Which to refactor?
• What are key considerations for replatforming and refactoring?
• What are key cloud application design concepts?

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
547
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
90
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. © 2013 Cloud Technology Partners, Inc. / Confidential1Erik.Sebesta@cloudtp.com / Chief Architect and Technology Officer (CATO) / May 6, 2013Best Practices for ApplicationMigration to Public Clouds
  • 2. © 2013 Cloud Technology Partners, Inc. / Confidential2Which applications to migrate?Which public clouds?Which applications in which public clouds?Migration types, best practices and examplesReplatformingRefactoring30 Minute Agenda10 minutes20 minutes
  • 3. © 2013 Cloud Technology Partners, Inc. / Confidential3Application Migration to Cloud Poker: Which Player Are You?Images from 1998 poker movie “Rounders”
  • 4. © 2013 Cloud Technology Partners, Inc. / Confidential4Should I Even Play? The Donkey, err… Blink TestThe application might not be a good fit if it…. Examples of topology non-compatibility... is large, single instance and/or monolithic, which cannotbe broken into servicesLarge investment accounting systemLegacy app with single tier business logic... has an external dependency that cannot be reached fromthe cloud platformNo network path to resource availableRequires local device access (sensor, camera, barcode reader)Direct user interface… is not compatible with list of approved/compatible cloudlibraries and no way to integrate with unapproved librariesoutside of the cloudApp requires a statistics library not portable to cloud platform(possible service interface?)App requires CICS interface library not supported on OS… requires specialized/dedicated:Chipset Non x86Firmware/OS Dedicated appliance, unsupported OS, cant be virtualized,etc.Storage -- that could not be mounted HSM, automated archiving & data agingPinned to CPU Assembler injection into the codeNetwork protocol Specific leased lines, portsTechnology stack Mainframe libraryUnsupported technology or library… has specialized clustering characteristics Specialized integration between app components used forredistributing load
  • 5. © 2013 Cloud Technology Partners, Inc. / Confidential5Which Games? Application Classification BucketsOn Hold /RetireMajor projects inflightLow businessvalueApplication Endof LifeLegacy, stablelimited growthplatformCommoditySoftware as aServiceProcess as aServiceData as aServiceNew commodityapplicationCloud ReadyStatelessScale outElasticityLoose couplingWeb apparchitecturePotential forCloudStatefulCOTSScale upComplianceTight couplingHard to MoveHighperformanceHigh existingdata volumeAvailabilitystrategyHarddependenciesVendor support
  • 6. © 2013 Cloud Technology Partners, Inc. / Confidential6In Which Casinos? Defining Approved Public Cloud EndpointsVerizonTerremarkPublic SaaSAmazonPaaS/IaaSMicrosoftAzure PublicPaaS/IaaSRackspace PublicOpenStack IaaSGoogle AppEngineForce.com
  • 7. © 2013 Cloud Technology Partners, Inc. / Confidential7Example of Public PaaS / IaaS Provider Comparison*Technical Requirements AmazonGoogle AppEngineVerizonTerremarkCenturyLinkSavvisMicrosoftAzureGlobal DeploymentsWebscale, Total CapacityAutoscaling, Dynamic Allocation ofCompute and StorageCloud Management ToolsSecurity CertificationsConnectivity to Legacy SystemsCompleteness of Solution (how muchstill has to be built?)TerremarkNot ready Fully ready*Marketing version of thisslide. Data not accurate.
  • 8. © 2013 Cloud Technology Partners, Inc. / Confidential8Application Characteristics• Technologies Supported• Service Level Agreements• Elasticity• Location• Security• Subscription CostEndpoint Characteristics• Technology Stack• Uptime• Scalability• Response Time• Security• BudgetWhich Games in Which Casinos? The Application Decision FrameworkCompatibilityFilterSuitability Score• Value Mapping• Weighting• Scoring (%)CompatibleEndpointsEndpoint ScoreReportsApplicationCharacteristics
  • 9. © 2013 Cloud Technology Partners, Inc. / Confidential9Endpoint Score Report (Decision)
  • 10. © 2013 Cloud Technology Partners, Inc. / Confidential10What Game Variants? Migration ApproachesMove current application tocloud with no code changes④ Portfolio RefactoringConsolidate portfolio to sharedbusiness and technical servicesin the cloud (Advanced PaaS)③ Application Refactoring② Application Migration① VirtualizationRemediate known violations incurrent code and platformRefactor selective applicationsto take advantage of the cloud(Basic PaaS)• Decomposing the application architectureand infrastructure– Discover interdependencies and supportingtools• Creating containers (P2C, V2C, packaging)• Integrating support tools• Transforming and/or migrate data• Developing assemblies and orchestrationcontrols• Replatforming plus…• Adapting the application to standardizedcloud infrastructure and PaaS• Addressing conformance issues• Aligning with cloud best practices such ashorizontal scaling, loose coupling andassuming component failure• Decomposing the application to leveragecommon components and servicesREPLATFORMING REFACTORING
  • 11. © 2013 Cloud Technology Partners, Inc. / Confidential11Migration types, best practices and examplesReplatformingRefactoringReplatforming and Refactoring20 minutes
  • 12. © 2013 Cloud Technology Partners, Inc. / Confidential12List of workloadsidentified formigrationPrep workloadfor migration VM imagesBoot ServiceCluster on CloudStagingEnvironmentDoes servicework?TroubleshootissuesStage forCloudMigrationDoes servicework?TroubleshootissuesPlatformConversionCloudMigrationTest ServiceScheduled formigration?Work with OPSto schedulePerformanceTestTestAcceptance?ProductionCutoverSystemsaccessible?Work with OPSto resolveacccessNo NoYesYesNoYesYesTroubleshootissuesNoNote: A workload is a set of servers that supportan application. Typically all the servers in aworkload would be migrated together.No YesSample Lift and Shift Cloud Migration ProcessChanging Decks? Platform Level Migration Process• Highly automatable• Any x86 sourcesystem includingolder operatingsystems• Workloads migratedtogether to minimizedisruption andreduce risk• Once the factory hasbeen created, beginparallel workloadmigrations
  • 13. © 2013 Cloud Technology Partners, Inc. / Confidential13• Supported systems– Source system must be a supported OS on the target Cloud/hypervisor platform– Potential problematic systems include Windows 2000 and earlier (VSS support), AIX anduncommon Linux platforms• Vertical vs. horizontal scalability– Applications dependent on vertical scalability may need to be re-architected forhorizontally scalable cloud IaaS• Image configuration– Choose a solution which allows you to change image configurations such as size, amount ofmemory, storage and CPU during migration• Target cloud SLAs vs. current infrastructure SLAs– Applications depending on infrastructure may need to be re-architected if the newunderlying infrastructure does not support themChanging Decks? A Few Replatforming Migration Considerations
  • 14. © 2013 Cloud Technology Partners, Inc. / Confidential14Replatforming - Unix to Linux Migration
  • 15. © 2013 Cloud Technology Partners, Inc. / Confidential15• Compiler issues– Switching compilers when moving from UNIX to Linux often requires changes to compilerflags, make files, build processes, compile and runtime directives around min/maxmemory, LargePage size, and other coding changes• Standard and 3rd party library usage (may not port)– The ANSI/ISO specifications leave some room for interpretation, and standard libraryimplementations may differ between vendors and versions.– Third party applications and drivers may not port - jdbc, video, peripherals, etc.• Database versioning and complexity– Relational database implementations vary between vendors and versions– Database schema complexity increases migration complexity• Number of integration points– Increases complexity of production migration testingRequesting a New Dealer? A Few U2L Migration Considerations
  • 16. © 2013 Cloud Technology Partners, Inc. / Confidential16Refactoring
  • 17. © 2013 Cloud Technology Partners, Inc. / Confidential17– Be a pessimist – assume everything fails and design backwards. Love your chaos monkey– Put your eggs in multiple baskets – leverage multiple providers, geographic regions and availability zones to accommodatefor local availability issues. Design for portability– Think efficiency - inefficient designs will not scale. Efficient designs will become cheaper as they scale. Kill off components orcapacity you don’t need right now– Be paranoid – design for defense in depth and zero tolerance by building in security at every level and between everycomponent. Trust no one.– But not too paranoid – not every application needs the platinum solution. Architect for different SLA’s, service tiers andsecurity levels– Manage your data – data is usually the most inflexible and complex area of your cloud and cloud integration architectures.Don’t short change the effort in analyzing and addressing the needs– Hands Off - leverage automation to increase consistency, quality and reduce response times– Divide and conquer - pursue partitioning and parallelization wherever possible. Make components as small and portable aspossible. Use load balancing between layers– Think elasticity - increasing resources should result in a proportional increase in performance and scalability. Decreasingresources should have the same effect– Be dynamic - enable dynamic configuration changes like autoscaling, failure recovery and resource discovery to adapt tochanging environments, faults and workload volumes– Stay close – reduce latency by moving highly interactive components and data near each other– Keep it loose - loose coupling, service interfaces, separation of concerns, abstraction and well defined API’s deliver flexibility– Be cost aware – autoscaling, data transmission, virtual software licenses, reserved instances, etc. can rapidly increase yourmonthly charges. Monitor your usage closely.What Playing Discipline Rules? Cloud Application Design Core Concepts
  • 18. © 2013 Cloud Technology Partners, Inc. / Confidential18AvailabilityScalabilitySecurityPerformanceDataPersistenceAgilityWhat to Consider at the Table: Cloud Application Best Practice Areas
  • 19. © 2013 Cloud Technology Partners, Inc. / Confidential19Areas Key Concerns Infrastructure Best Practices Application Best PracticesAvailability • SPOF (Single Point ofFailure)• MTTR (Mean Time toRecovery) – how longbefore it’s up?• RPO (Recovery PointObjective) – how muchdata can you lose?• Data Integrity• Disaster recovery/business continuity• Legal/ regulatoryevents• Incident response• Assume component(s) failure• Timeouts/ circuit breakers• Fast fail/ fast auto-restart• Multiple regions with geographicredundancy• Multiple availability zones• Redundant externalnetwork/internet connections• Global Load Balancing• Chaos Monkey testing• …and more• Multiple instances / clustering• Local Load Balancing• Fast fail/ fast restart• Technology standards (recoveryautomation and process reuse)• Design every component as a black boxwith a well defined API• Stateless workloads• Component connectivity automatedretry/reconnect• Rapid startup/shutdown• …and moreBest Practice Guidelines - Availability
  • 20. © 2013 Cloud Technology Partners, Inc. / Confidential20Areas Key Concerns Infrastructure Best Practices Application Best PracticesScalability • Connection volume• Transaction volume• Analytics volume• Data volume• Contention/bottlenecks• Data upload/download• Network bandwidth• Scaling both stateand behavior• Long transactions• Timeouts• Load Balancing• Compute as a Service• Virtual IP• DNS• Portable workloads• Resource pools• Autoscaling infrastructure• Reverse proxy• Thin provisioning• Capacity monitoring/mgmt• Incident management• …and more• Load balancing• Scale application with dynamic,proactive and reactive scaling• Caching• Application partitioning• Request partitioning• Data partitioning, replication,sharding• Webscale technologies: NoSQL,Hadoop, GFS• Event-driven architecture• Map/reduce, SPMD, master/worker,fork/join and other partition/parallelpatterns• …and moreBest Practice Guidelines - Scalability
  • 21. © 2013 Cloud Technology Partners, Inc. / Confidential21Areas Key Concerns Infrastructure Best Practices Application Best PracticesSecurity • Intrusion• Multi-tenancy• Physical security• Identity management• Denial of service/flooding• Data breach• Data corruption• Data integrity• Virus/Malware• Trojans/Bots• Social engineering• Incident/ compromiseresponse• Legal/ regulatorycompliance• Audit• Data ownership• Business continuity• Defense in Depth – every layerdefends itself• Zero tolerance – trust no one• Cloud provider security review /certifications• Encrypt everything: data, file,message at rest/in flight/backup• Network/host intrusiondetection, antivirus/malware• Host/OS/network hardening• Layered network security• …and more• Defense in Depth– every layerdefends itself• Sensitive activity audit trails• Data sensitivity classification• Transaction sensitivityclassification• Data and transactionsegmentation by sensitivity• Secure coding best practices• Secure code scanners• User provisioning controls• …and moreBest Practice Guidelines - Security
  • 22. © 2013 Cloud Technology Partners, Inc. / Confidential22Areas Key Concerns Infrastructure Best Practices Application Best PracticesPerformance • Constraints in compute,storage and networkperformance• Network latency• Chattiness betweendistributed components• Network contention/bandwidth constraints• Single threadedexecution• Waits/timeouts• Slow failure• Poor user experience• Inflexiblearchitecture/design• Buggy code• See scalability• Align infrastructureperformance withapplication requirements• Edge caching: CDN, Akamai,Cloudfront, Cloudflare• Monitor infrastructurecomponent performanceand wait queues• Utilize high I/Operformance computenodes• Keep dynamic data close tocompute and static dataclose to end users• …and more• See scalability• Application component/dataco-location• Data caching, http caching• Batch or bulk read/write• Asynch communication, loosecoupling• Optimistic/lazy locking• Multi-version data updates• Map/reduce, SPMD, fork/joinmaster/worker and otherpartition/parallel patterns• …and moreBest Practice Guidelines - Performance
  • 23. © 2013 Cloud Technology Partners, Inc. / Confidential23Areas Key Concerns Infrastructure Best Practices Application Best PracticesDataPersistence• Big data• Inflexible datastructures• Unstructured data• Concurrent access• Data integrity• CAP theorem• Real-time data• Data ownership• Lack of consistencybetween copies• Multiplying copies –data in the wild• …and more• See scalability, performance,availability, security• Defense in depth for data atrest/ in flight/ archive/ backup• Maintain machine images forrapid cloning/deployments• Real-time data propagation• Data audit/controls• Data lifecycle management• Data/storage tiering• Edge data caching, CDN• Master data management• …and more• See scalability, performance,availability, security• Application aware data tiering• Separate stateful and statelesscomponents• Eventual consistency• Webscale data technology:NoSQL, Hadoop, SnapLogic• Data partitioning, replication,sharding• Separate data by type: master,content, transactional, audit,analytical, etc.• …and moreBest Practice Guidelines -DataPersistence
  • 24. © 2013 Cloud Technology Partners, Inc. / Confidential24Areas Key Concerns Infrastructure Best Practices Application Best PracticesAgility • Vendor/product/cloudprovider lock-in• Software licensingconstraints• Application orinfrastructureconstraints• Tight coupling ofcomponents• Workload portability• Component portability• Reuse• Hard dependencies• Technologysupportability• Industry standards• Resource virtualization/abstraction• Technology standards• Separation of concerns –infrastructure servicedecomposition andabstraction• Separate identity and accessmanagement from theapplication and operationaltools• …and more• Industry standards• Component connectivityabstraction• Separation of concerns – appservice decomposition,operational/security separation• Cloud aligned technology stacks(e.g. open source)• Component/service reuse• Scale out applicationarchitecture• Stateless execution• Location abstraction/transparency• …and moreBest Practice Guidelines - Agility
  • 25. © 2013 Cloud Technology Partners, Inc. / Confidential25A Few Coding Rule Examples
  • 26. © 2013 Cloud Technology Partners, Inc. / Confidential26Analyzing Your Play? Cloud Coding Principles#19: Implement code profiling governance
  • 27. © 2013 Cloud Technology Partners, Inc. / Confidential27PaaSLane answers key questions about applications in the cloud.• Will they run? How much refactoring is needed?• What will it cost to optimize for the cloud?• How do I update my application portfolio over time to be more cloud-enabled?MigrationGovernanceQualityCIOs• Which applications should we migrate?• Which PaaS will be best suited to run my apps?Dev. Managers• How can we keep up with compliance& governance?• What skills are needed to migrate the apps?Developer• How can I follow all cloud and SDLC standards?Code Profiling & Effort Estimation for Application Migration to Cloud
  • 28. © 2013 Cloud Technology Partners, Inc. / Confidential28Java I/O Rules*Severity Rule Name Rule Description Rule RationaleMINORRULE_FILE_ClassLoader_ResourceLoading resource fromClassLoader may cause problemin cloud application.File operations like read and write that depend on cloud resources like localdisk, folders and path should be avoided as these resources are temporary inthe cloud. Please ignore this warning if code is trying to read configurationfiles that are integral part of the application.MINORRULE_FILE_ClassLoader_SystemResourceLoading system resource fromClassLoader may cause problemin cloud.File operations like read and write that depend on the local resources likedrives, folders and path should be avoided as these resources are temporaryin the cloud. Please ignore this warning if code is trying to read configurationfiles that are integral part of the application.MINOR RULE_FILE_File Avoid using java.io.File.File operations like read and write that depend on the local resources likedrives, folders and path should be avoided as these resources are temporaryin the cloud. Please ignore this warning if code is trying to read configurationfiles that are integral part of the application.BLOCKERRULE_FILE_FileOutputStreamAvoid usingjava.io.FileOutputStream.FileOutputStream is used for creating files. Avoid creating files in the cloud asthe underlying local disk, folders and path are temporary. Creating local files inthe cloud could result in loss of data and unexpected behavior.MAJORRULE_FILE_FileReaderAvoid using java.io.FileReader.File operations like read and write that depend on the local resources likedrives, folders and path should be avoided as these resources are temporaryin the cloud. Please ignore this warning if code is trying to read configurationfiles that are integral part of the application.*Full set of rules available in Cloud Technology Partners PaaSLane™ solution
  • 29. © 2013 Cloud Technology Partners, Inc. / Confidential29Severity Rule Name Rule Description NotesMAJORCA1409: Com visible types should becreatableA reference type that is specifically marked as visible toCOM contains a public parameterized constructor but doesnot contain a public default (parameter less) constructor. Atype without a public default constructor is not creatableby COM clients.COM should be discouraged, and newertechnology should be recommended. COM isan outdated 32bit technology, and Azure is64bit. Also COM often relies on installing thingsin the registry. While it is still possible to useold COM assemblies if additional steps are takento create some sort of interoperability betweenthe 64-bit hosting process, and the 32-bit COM,it is recommended to use newer technology.MAJORCA1410: COM registration methodsshould be matchedA type declares a method that is marked by using theSystem.Runtime.InteropServices. ComRegisterFunctionAttribute attribute but does not declare a methodthat is marked by using theSystem.Runtime.InteropServices.ComUnregisterFunctionAttribute attribute, or vice versa.COM should be discouraged, and newertechnology should be recommended. COM isan outdated 32bit technology, and Azure is64bit. Also COM often relies on installing thingsin the registry. While it is still possible to useold COM assemblies if additional steps are takento create some sort of interoperability betweenthe 64-bit hosting process, and the 32-bit COM,it is recommended to use newer technology.MINORCA1414: Mark boolean P/Invokearguments with MarshalAsThe Boolean data type has multiple representations inunmanaged code.If the cloud environment is 64-bit and there ismarshaling from 32-bit, it is a good idea to fix this toensure correct behavior of application.BLOCKER Do_not_reference_specific_IP_addressesChecks that configuration endpoint addresses arent using IPaddresses.IPs will be ever-changing in cloud environment..NET Interoperability Rules**Full set of rules available in Cloud Technology Partners PaaSLane ™ solution
  • 30. © 2013 Cloud Technology Partners, Inc. / Confidential30So Are You Ready to Play?
  • 31. © 2013 Cloud Technology Partners, Inc. / Confidential31Or Prepared to Win?
  • 32. © 2013 Cloud Technology Partners, Inc. / Confidential32To Beat the Odds, Play with a Strong Team
  • 33. © 2013 Cloud Technology Partners, Inc. / Confidential33Thank you for your time and interestErik.Sebesta@cloudtp.com / Chief Architect and Technology Officer (CATO) / May 6, 2013

×