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


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


3

Application Migration to Cloud Poker: Which Player Are You?

Images from 1998 poker movie “Rounders”


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


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


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


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.


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


9

Endpoint Score Report (Decision)


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


11

Migration types, best practices and examplesReplatforming

Refactoring

Replatforming and Refactoring

20 minutes


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


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


14

Replatforming - Unix to Linux Migration


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


16

Refactoring


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


18

Availability

Scalability

Security

Performance

Data Persistence

Agility

What to Consider at the Table: Cloud Application Best Practice Areas


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


20


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


21


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


22


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


23


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


24


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


25

A Few Coding Rule Examples


26

Analyzing Your Play? Cloud Coding Principles

#19: Implement code profiling governance


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


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


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

http://msdn.microsoft.com/en-us/library/ms182203.aspx







30

So Are You Ready to Play?


31

Or Prepared to Win?


32

To Beat the Odds, Play with a Strong Team


33

Thank you for your time and interest

[email protected] / Chief Architect and Technology Officer (CATO) / May 6, 2013