Blue Mixology

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…

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.

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.

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.

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

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

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

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?

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

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

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

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

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.

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

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.

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

Discussion

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