Best practices for application migration to public clouds interop presentation
-
Upload
esebeus -
Category
Technology
-
view
389 -
download
2
description
Transcript of Best practices for application migration to public clouds interop presentation
© 2013 Cloud Technology Partners, Inc. / Confidential
1
[email protected] / Chief Architect and Technology Officer (CATO) / May 6, 2013
Best Practices for Application Migration to Public Clouds
© 2013 Cloud Technology Partners, Inc. / Confidential
2
Which applications to migrate?Which public clouds?
Which applications in which public clouds?
Migration types, best practices and examplesReplatforming
Refactoring
30 Minute Agenda
10 minutes
20 minutes
© 2013 Cloud Technology Partners, Inc. / Confidential
3
Application Migration to Cloud Poker: Which Player Are You?
Images from 1998 poker movie “Rounders”
© 2013 Cloud Technology Partners, Inc. / Confidential
4
Should I Even Play? The Donkey, err… Blink Test
The application might not be a good fit if it…. Examples of topology non-compatibility
... is large, single instance and/or monolithic, which cannot be broken into services
Large investment accounting systemLegacy app with single tier business logic
... has an external dependency that cannot be reached from the cloud platform
No network path to resource availableRequires local device access (sensor, camera, barcode reader)Direct user interface
… is not compatible with list of approved/compatible cloud libraries and no way to integrate with unapproved libraries outside of the cloud
App 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 x86
Firmware/OS Dedicated appliance, unsupported OS, can't be virtualized, etc.
Storage -- that could not be mounted HSM, automated archiving & data aging
Pinned to CPU Assembler injection into the code
Network protocol Specific leased lines, ports
Technology stack Mainframe libraryUnsupported technology or library
… has specialized clustering characteristics Specialized integration between app components used for redistributing load
© 2013 Cloud Technology Partners, Inc. / Confidential
5
Which Games? Application Classification Buckets
On Hold / Retire
Major projects in flight
Low business value
Application End of Life
Legacy, stable limited growth
platform
Commodity
Software as a Service
Process as a Service
Data as a Service
New commodity application
Cloud Ready
Stateless
Scale out
Elasticity
Loose coupling
Web app architecture
Potential for Cloud
Stateful
COTS
Scale up
Compliance
Tight coupling
Hard to Move
High performance
High existing data volume
Availability strategy
Hard dependencies
Vendor support
© 2013 Cloud Technology Partners, Inc. / Confidential
6
In Which Casinos? Defining Approved Public Cloud Endpoints
Verizon Terremark
Public SaaS
Amazon PaaS/IaaS
Microsoft Azure Public
PaaS/IaaS
Rackspace Public OpenStack IaaS
Google App Engine
Force.com
© 2013 Cloud Technology Partners, Inc. / Confidential
7
Example of Public PaaS / IaaS Provider Comparison*
Technical Requirements AmazonGoogle App
EngineVerizon
TerremarkCenturyLink
SavvisMicrosoft
Azure
Global Deployments
Webscale, Total Capacity
Autoscaling, Dynamic Allocation of Compute and Storage
Cloud Management Tools
Security Certifications
Connectivity to Legacy Systems
Completeness of Solution (how much still has to be built?)
Terremark
Not ready Fully ready
*Marketing version of this slide. Data not accurate.
© 2013 Cloud Technology Partners, Inc. / Confidential
8
Application Characteristics
• Technologies Supported• Service Level Agreements• Elasticity• Location• Security• Subscription Cost
Endpoint Characteristics
• Technology Stack• Uptime• Scalability• Response Time• Security• Budget
Which Games in Which Casinos? The Application Decision Framework
Compatibility Filter
Suitability Score• Value Mapping• Weighting• Scoring (%)
Compatible Endpoints
Endpoint Score Reports
Application Characteristics
© 2013 Cloud Technology Partners, Inc. / Confidential
9
Endpoint Score Report (Decision)
© 2013 Cloud Technology Partners, Inc. / Confidential
10
What Game Variants? Migration Approaches
Move current application to cloud with no code changes
④ Portfolio Refactoring
Consolidate portfolio to shared business and technical services in the cloud (Advanced PaaS)
③ Application Refactoring② Application Migration① Virtualization
Remediate known violations in current code and platform
Refactor selective applications to take advantage of the cloud
(Basic PaaS)
• Decomposing the application architecture and infrastructure– Discover interdependencies and supporting
tools
• Creating containers (P2C, V2C, packaging)
• Integrating support tools
• Transforming and/or migrate data
• Developing assemblies and orchestration controls
• Replatforming plus…
• Adapting the application to standardized cloud infrastructure and PaaS
• Addressing conformance issues
• Aligning with cloud best practices such as horizontal scaling, loose coupling and assuming component failure
• Decomposing the application to leverage common components and services
REPLATFORMING REFACTORING
© 2013 Cloud Technology Partners, Inc. / Confidential
11
Migration types, best practices and examplesReplatforming
Refactoring
Replatforming and Refactoring
20 minutes
© 2013 Cloud Technology Partners, Inc. / Confidential
12
List of workloads identified for
migration
Prep workload for migration VM images
Boot Service Cluster on Cloud
Staging Environment
Does service work?
Troubleshoot issues
Stage for Cloud
Migration
Does service work?
Troubleshoot issues
Platform Conversion
Cloud Migration
Test Service
Scheduled for migration?
Work with OPS to schedule
Performance Test
Test Acceptance?
Production Cutover
Systems accessible?
Work with OPS to resolve acccess
No No
Yes
Yes
NoYes
Yes
Troubleshoot issues
No
Note: A workload is a set of servers that support an application. Typically all the servers in a workload would be migrated together.
No Yes
Sample Lift and Shift Cloud Migration Process
Changing Decks? Platform Level Migration Process
• Highly automatable
• Any x86 source system including older operating systems
• Workloads migrated together to minimize disruption and reduce risk
• Once the factory has been created, begin parallel workload migrations
© 2013 Cloud Technology Partners, Inc. / Confidential
13
• 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 and uncommon Linux platforms
• Vertical vs. horizontal scalability– Applications dependent on vertical scalability may need to be re-architected for
horizontally scalable cloud IaaS
• Image configuration– Choose a solution which allows you to change image configurations such as size, amount of
memory, storage and CPU during migration
• Target cloud SLAs vs. current infrastructure SLAs– Applications depending on infrastructure may need to be re-architected if the new
underlying infrastructure does not support them
Changing Decks? A Few Replatforming Migration Considerations
© 2013 Cloud Technology Partners, Inc. / Confidential
14
Replatforming - Unix to Linux Migration
© 2013 Cloud Technology Partners, Inc. / Confidential
15
• Compiler issues– Switching compilers when moving from UNIX to Linux often requires changes to compiler
flags, make files, build processes, compile and runtime directives around min/max memory, 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 library
implementations 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 testing
Requesting a New Dealer? A Few U2L Migration Considerations
© 2013 Cloud Technology Partners, Inc. / Confidential
16
Refactoring
© 2013 Cloud Technology Partners, Inc. / Confidential
17
– 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 accommodate for local availability issues. Design for portability
– Think efficiency - inefficient designs will not scale. Efficient designs will become cheaper as they scale. Kill off components or capacity 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 every component. Trust no one.
– But not too paranoid – not every application needs the platinum solution. Architect for different SLA’s, service tiers and security 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 as possible. Use load balancing between layers
– Think elasticity - increasing resources should result in a proportional increase in performance and scalability. Decreasing resources should have the same effect
– Be dynamic - enable dynamic configuration changes like autoscaling, failure recovery and resource discovery to adapt to changing 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 your monthly charges. Monitor your usage closely.
What Playing Discipline Rules? Cloud Application Design Core Concepts
© 2013 Cloud Technology Partners, Inc. / Confidential
18
Availability
Scalability
Security
Performance
Data Persistence
Agility
What to Consider at the Table: Cloud Application Best Practice Areas
© 2013 Cloud Technology Partners, Inc. / Confidential
19
Areas Key Concerns Infrastructure Best Practices Application Best Practices
Availability • SPOF (Single Point of Failure)
• MTTR (Mean Time to Recovery) – how long before it’s up?
• RPO (Recovery Point Objective) – how much data can you lose?
• Data Integrity• Disaster recovery/
business continuity• Legal/ regulatory
events• Incident response
• Assume component(s) failure• Timeouts/ circuit breakers• Fast fail/ fast auto-restart• Multiple regions with geographic
redundancy• Multiple availability zones• Redundant external
network/internet connections• Global Load Balancing• Chaos Monkey testing• …and more
• Multiple instances / clustering• Local Load Balancing• Fast fail/ fast restart• Technology standards (recovery
automation and process reuse)• Design every component as a black box
with a well defined API• Stateless workloads• Component connectivity automated
retry/reconnect• Rapid startup/shutdown• …and more
Best Practice Guidelines - Availability
© 2013 Cloud Technology Partners, Inc. / Confidential
20
Areas Key Concerns Infrastructure Best Practices Application Best Practices
Scalability • Connection volume• Transaction volume• Analytics volume• Data volume• Contention/
bottlenecks• Data upload/
download• Network bandwidth• Scaling both state
and 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/parallel patterns
• …and more
Best Practice Guidelines - Scalability
© 2013 Cloud Technology Partners, Inc. / Confidential
21
Areas Key Concerns Infrastructure Best Practices Application Best Practices
Security • Intrusion• Multi-tenancy• Physical security• Identity management• Denial of service/
flooding• Data breach• Data corruption• Data integrity• Virus/Malware• Trojans/Bots• Social engineering• Incident/ compromise
response• Legal/ regulatory
compliance• Audit • Data ownership• Business continuity
• Defense in Depth – every layer defends itself
• Zero tolerance – trust no one• Cloud provider security review /
certifications• Encrypt everything: data, file,
message at rest/in flight/backup• Network/host intrusion
detection, antivirus/malware• Host/OS/network hardening• Layered network security• …and more
• Defense in Depth– every layer defends itself
• Sensitive activity audit trails• Data sensitivity classification• Transaction sensitivity
classification• Data and transaction
segmentation by sensitivity• Secure coding best practices• Secure code scanners• User provisioning controls• …and more
Best Practice Guidelines - Security
© 2013 Cloud Technology Partners, Inc. / Confidential
22
Areas Key Concerns Infrastructure Best Practices Application Best Practices
Performance • Constraints in compute, storage and network performance
• Network latency• Chattiness between
distributed components• Network contention/
bandwidth constraints• Single threaded
execution• Waits/timeouts• Slow failure• Poor user experience• Inflexible
architecture/design• Buggy code
• See scalability• Align infrastructure
performance with application requirements
• Edge caching: CDN, Akamai, Cloudfront, Cloudflare
• Monitor infrastructure component performance and wait queues
• Utilize high I/O performance compute nodes
• Keep dynamic data close to compute and static data close to end users
• …and more
• See scalability• Application component/data
co-location• Data caching, http caching• Batch or bulk read/write• Asynch communication, loose
coupling• Optimistic/lazy locking• Multi-version data updates• Map/reduce, SPMD, fork/join
master/worker and other partition/parallel patterns
• …and more
Best Practice Guidelines - Performance
© 2013 Cloud Technology Partners, Inc. / Confidential
23
Areas Key Concerns Infrastructure Best Practices Application Best Practices
Data Persistence
• Big data• Inflexible data
structures• Unstructured data• Concurrent access• Data integrity• CAP theorem• Real-time data• Data ownership• Lack of consistency
between copies• Multiplying copies –
data in the wild• …and more
• See scalability, performance, availability, security
• Defense in depth for data at rest/ in flight/ archive/ backup
• Maintain machine images for rapid 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 stateless
components• Eventual consistency• Webscale data technology:
NoSQL, Hadoop, SnapLogic• Data partitioning, replication,
sharding• Separate data by type: master,
content, transactional, audit, analytical, etc.
• …and more
Best Practice Guidelines - Data Persistence
© 2013 Cloud Technology Partners, Inc. / Confidential
24
Areas Key Concerns Infrastructure Best Practices Application Best Practices
Agility • Vendor/product/cloud provider lock-in
• Software licensing constraints
• Application or infrastructure constraints
• Tight coupling of components
• Workload portability• Component portability• Reuse• Hard dependencies• Technology
supportability
• Industry standards• Resource virtualization/
abstraction• Technology standards• Separation of concerns –
infrastructure service decomposition and abstraction
• Separate identity and access management from the application and operational tools
• …and more
• Industry standards• Component connectivity
abstraction• Separation of concerns – app
service decomposition, operational/security separation
• Cloud aligned technology stacks (e.g. open source)
• Component/service reuse• Scale out application
architecture• Stateless execution• Location abstraction/
transparency• …and more
Best Practice Guidelines - Agility
© 2013 Cloud Technology Partners, Inc. / Confidential
25
A Few Coding Rule Examples
© 2013 Cloud Technology Partners, Inc. / Confidential
26
Analyzing Your Play? Cloud Coding Principles
#19: Implement code profiling governance
© 2013 Cloud Technology Partners, Inc. / Confidential
27
PaaSLane 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?
MigrationGovernance
Quality
CIOs• 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
© 2013 Cloud Technology Partners, Inc. / Confidential
28
Java I/O Rules*
Severity Rule Name Rule Description Rule Rationale
MINOR RULE_FILE_ClassLoader_Resource
Loading resource from 'ClassLoader' may cause problem in cloud application.
File operations like read and write that depend on cloud resources like local disk, folders and path should be avoided as these resources are temporary in the cloud. Please ignore this warning if code is trying to read configuration files that are integral part of the application.
MINORRULE_FILE_ClassLoader_SystemResource
Loading system resource from 'ClassLoader' may cause problem in cloud.
File operations like read and write that depend on the local resources like drives, folders and path should be avoided as these resources are temporary in the cloud. Please ignore this warning if code is trying to read configuration files 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 like drives, folders and path should be avoided as these resources are temporary in the cloud. Please ignore this warning if code is trying to read configuration files that are integral part of the application.
BLOCKER RULE_FILE_FileOutputStream
Avoid using java.io.FileOutputStream.
FileOutputStream is used for creating files. Avoid creating files in the cloud as the underlying local disk, folders and path are temporary. Creating local files in the cloud could result in loss of data and unexpected behavior.
MAJOR RULE_FILE_FileReader Avoid using java.io.FileReader.
File operations like read and write that depend on the local resources like drives, folders and path should be avoided as these resources are temporary in the cloud. Please ignore this warning if code is trying to read configuration files that are integral part of the application.
*Full set of rules available in Cloud Technology Partners PaaSLane™ solution
© 2013 Cloud Technology Partners, Inc. / Confidential
29
Severity Rule Name Rule Description Notes
MAJOR CA1409: Com visible types should be creatable
A reference type that is specifically marked as visible to COM contains a public parameterized constructor but does not contain a public default (parameter less) constructor. A type without a public default constructor is not creatable by COM clients.
COM should be discouraged, and newer technology should be recommended. COM is an outdated 32bit technology, and Azure is 64bit. Also COM often relies on installing things in the registry. While it is still possible to use old COM assemblies if additional steps are taken to create some sort of interoperability between the 64-bit hosting process, and the 32-bit COM, it is recommended to use newer technology.
MAJOR CA1410: COM registration methods should be matched
A type declares a method that is marked by using the System.Runtime.InteropServices. ComRegister FunctionAttribute attribute but does not declare a method that is marked by using the System.Runtime.InteropServices.ComUnregisterFunctionAttribute attribute, or vice versa.
COM should be discouraged, and newer technology should be recommended. COM is an outdated 32bit technology, and Azure is 64bit. Also COM often relies on installing things in the registry. While it is still possible to use old COM assemblies if additional steps are taken to create some sort of interoperability between the 64-bit hosting process, and the 32-bit COM, it is recommended to use newer technology.
MINOR CA1414: Mark boolean P/Invoke arguments with MarshalAs
The Boolean data type has multiple representations in unmanaged code.
If the cloud environment is 64-bit and there is marshaling from 32-bit, it is a good idea to fix this to ensure correct behavior of application.
BLOCKER Do_not_reference_specific_IP_addresses Checks that configuration endpoint addresses aren't using IP addresses.
IP's will be ever-changing in cloud environment.
.NET Interoperability Rules*
*Full set of rules available in Cloud Technology Partners PaaSLane ™ solution
© 2013 Cloud Technology Partners, Inc. / Confidential
30
So Are You Ready to Play?
© 2013 Cloud Technology Partners, Inc. / Confidential
31
Or Prepared to Win?
© 2013 Cloud Technology Partners, Inc. / Confidential
32
To Beat the Odds, Play with a Strong Team
© 2013 Cloud Technology Partners, Inc. / Confidential
33
Thank you for your time and interest
[email protected] / Chief Architect and Technology Officer (CATO) / May 6, 2013