Best practices for application migration to public clouds interop presentation

© 2013 Cloud Technology Partners, Inc. / Confidential
1
Erik.Sebesta@cloudtp.com / 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 examples
Replatforming
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 system
Legacy app with single tier business logic
... has an external dependency that cannot be reached from
the cloud platform
No network path to resource available
Requires 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 library
Unsupported 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 Amazon
Google App
Engine
Verizon
Terremark
CenturyLink
Savvis
Microsoft
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 examples
Replatforming
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?
Migration
Governance
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_ClassL
oader_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.
MINOR
RULE_FILE_ClassL
oader_SystemRes
ource
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
MINOR RULE_FILE_File Avoid using 'java.io.File'.
BLOCKER
RULE_FILE_FileOu
tputStream
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_FileRe
ader
Avoid using java.io.FileReader.
*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.ComUnregisterFunctionA
ttribute 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

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
Erik.Sebesta@cloudtp.com / Chief Architect and Technology Officer (CATO) / May 6, 2013

Best practices for application migration to public clouds interop presentation

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Best practices for application migration to public clouds interop presentation

Similar to Best practices for application migration to public clouds interop presentation (20)

Recently uploaded

Recently uploaded (20)

Best practices for application migration to public clouds interop presentation