1. Blue Mixology

2. What is cloud?
The goal of cloud is not just to move the application onto managed infrastructure.
Goal is not just to move the application onto a managed platform.
Migration to cloud also means…

3. Broad Network Access and Resource.
What else is cloud?
Pooling – Application can be distributed across data centers around the world and share resources to minimize cost.
Broad Network Access and Resource.

4. On-demand self-service through automation.
What else is cloud?
– New versions of the application and its configuration can be deployed quickly.
Micro-services can easily be added to leverage additional cloud services.
On-demand self-service through automation.

5. What else is cloud? Rapid elasticity.
Scale up and down automatically or with the push of a button.
Scale out to different geographic locations as well.
Rapid elasticity.

6. What else is cloud? Measured Service.
Monitor application performance, usage and errors and be able to react quickly to changes.
Measured Service.

7. Getting to the Cloud Identification of current system state
Identify Cloud Architecture Approach
Migration Plan: define a phased migration plan
Implement Iteratively
Discover and utilize additional cloud features
Identification of current system state:
Current system architecture
Technology in use at different layers (J2EE, Database, Security, etc.)
Current DevOps state (automation, test, configuration management, etc.)
Current performance requirements and SLAs
Level of effort for migration of each part of the architecture
Migration Plan: define a phased migration plan
Implement Iteratively
Migrate code, configuration
Setup automated deploy, automated test
Test and evaluate performance goals
Setup common services: Auto Scaling, SSO, Persistent Logs, etc.
Repeat until migration goals are met
Discover and utilize additional cloud features

8. Identify Current System Architecture
From the system architecture we can identify:
Application
Databases
Messaging
LDAP
Web
Load Balancer
what we can migrate first…
what pieces have to be migrated together…
where we can gain most benefit from cloud…
What applications exist?
What services are in use?
What databases, messaging engines, integration busses?
What is the system of record for security?
How is networking defined between the components?
How is security between the elements defined?
Current middleware configuration can be used at this stage to identify relationsips between systems

9. Identify Technology Age of existing tech? What tech is in use?
Session dependency?
Documentation?
Security?
Enhancements &
Support?
Cloud Ready?
Level of Effort?
In the application implementation, what technology is in use?
EJBs (Stateless session beans, entity beans, etc.)
OSGi (eg: using blueprint?)
JPA, JAX-RS, JAX-WS, jsonp
How old – age of the an app can tell us a lot about cloud ready-ness
Session dependency? Does the application rely heavily on data in a session or in a cache?
Security – how is the application secured?
How is the application documented?
Are the people who wrote the application still available?
From the technology information we can identify:
Can the application run on Liberty profile without modification?
What is the level of effort to migrate the application implementation?

10. Continuous Integration?
Current DevOps State
Automation?
DevOps Capability?
Continuous Integration?
Testing Procedures?
Config Management?
Monitoring & Metrics?
Org. Change?
Team Readiness?
Level of Effort?
How far along the DevOps adoption curve is the organization?
Is application build automated? Using Continuous Integration?
Is application deployment automated?
Is application configuration managed across the SDLC? (Dev, Test, Prod)
What about automated testing? (unit, container, functional and performance)
Monitoring the app and collecting metrics?
With this information we can identify:
Is the team ready, technically and culturally, for rapid iterations?
How much of the application management is ready for the cloud
What level of effort is required to update for cloud readiness

11. Performance and SLA’s Current Performance? App Requests?
Required SLA’s?
User Expectations?
Bandwidth Reqs?
Operational Model?
Autoscale Reqs?
Performance Reqs?
Testing Reqs?
What are the expected number of requests on the application?
How does the application perform today? Heap size, jvm, cpu usage, etc.
What SLAs are defined for the application?
Response times
Uptime requirements
With this information we can identify:
What scaling configuration is required for cloud auto scale services
Cost estimates for running the app in the cloud
Defined scalability and performance testing requirements

12. Operational Readiness?
Networking
Connection Points?
Network Layers?
Security/VPN?
Network Readiness?
Regulations?
Operational Readiness?
Micro-services
Identification?
Performance Reqs?
Security Reqs?
Identify current network layers between components
Based on migration road map and plan, identify what network connections will exist between cloud and on premise components
Including considerations for Bandwidth, VPN, Security
What enterprise regulations are in place that should be considered?
What comfort level does the network team have with connections coming from the cloud to backend systems?
From this information we can identify:
Which hybrid cloud micro-services are good candidates for accessing backend systems
What performance and security considerations need to be included in the migration plan

13. Groupings of Components
Applications and databases are put into logical groups for phased migration
In this example, App 1 is a good candidate for migration and should be migrated first along with its database. Access to the second database and LDAP can be handled by hybrid Bluemix services.
App 1
Db 2
LDAP
App 2 MQ
App 3 Db

14. Identify Level of Effort
Based on input from system architecture, technology, automation and performance put together level of effort for the different possible component groups.
Build a estimated costs table for supporting the component groups​ post migration
Estimate time required for migrating each component group
Decide which applications are good candidates for migration based on:
Data sensitivity
Applications with low coupling
Applications that are customer facing
Etc.

15. Phased Migration Plan
Work with business stakeholders to create phased migration plan based on:
Component groups that are higher priority
Feasibility
Cost benefits
Total cost of ownership – today and in the cloud

16. Leverage Additional Cloud Features
Once the application is running in the cloud:
Explore additional cloud features that benefit migrated apps
Iteratively implement these additional features
For example –
The migrated application relies heavily on session state.
During migration, the Session Cache service is used to provide session caching.
To reduce costs, the use of the cache service can be removed by modifying the application implementation.

17. Guiding Principles Standard Practices Deployment automation
Able to quickly deploy new product features, fixes and enhancements to leverage cloud
Configuration management
Able to move from test to production as needed
Test automation
Provides a ‘safety-net’ to protect against regressions when optimizing and refactoring the application
Treat configuration as source
Able to ‘re-build’ an environment completely from scratch

18. Discussion

20. Sales Process Engage with Client Build Initial App Screens
Client review and feedback
Evolve Design
Client review and feedback
Close Deal
Execute Design
Transition to MS
Cloud Readiness Assessment
Technical Survey
Cloud Initiate
App Engage
Evolve Workflow
Cloud Promote
App Execute
Finalise Workflow
App Transition
Validate Security
Execute
Security
Validate Integration
Execute
Integration
Asset Extract