Migrating WebLogic workloads to the cloud

# CaaS

0. Containerize the app - PAS ... zero changes to the app - research - Weblogic standalone. Single inbound route. Stateful workload => volume services on PCF. Docker images.
1. Containerize the app - PKS ... zero changes to the app - Use existing Helm charts or operators to run on PKS - Weblogic clustered https://github.com/oracle/weblogic-kubernetes-operator/blob/master/site/design.md

#PaaS

2. Using a buildpack - Weblogic buildpack https://github.com/pivotal-cf/weblogic-buildpack
3. Using a buildpack - TomEE buildpack - Runs JavaEE. YMMW if there is a lot of ORCL specific deployment descriptors and API usage
4. Using the Java buildpack - Java Buildpack - Bootify the app and replace all EE framework usage with corresponding Spring components and frameworks - some changes - very well understood - and recipes exist for ALL mods EJB Migration
5. Using the Java buildpack - Package up the app as a fat app in WebLogic and then run it simply as a jar with the JBP. - experimental but could yield replatforming with 0 changes. same restrictions as PAS apply.

# FaaS

- Does not apply

#VM 

7. BOSH to deploy Weblogic as a release. BOSH release for weblogic
8. Ansible, chef recipes ...

# Bare Metal

9. Run as-is today on servers with NO virtualization.

GKE-on prem, Azure on-prem , AWS on-prem

All the major clouds are coming to a datacenter near you*. You can get Google, or Azure megascale in your own house datacenter. You can start taking advantage of the cloud platforms to improve and shift your workloads to the cloud and get the benefits of being cloud native. The cloud will be a force function for innovation and change in your organizations allowing you to finally throw away the yolk of agilefall or wagile or DAD or Scrum whatever has kept you behind. Your software can eat the world. You will no longer be threatened by the millennial's of Silicon Valley. 

wait a minute ... there is something missing here !! ... 

Humans. Where is the human cloud ? Where is the Cloud Native Transformation as a service. Where is the Platform as a Product Service. Where is the Domain Driven Design as a Service. Where is the SRE as a service. Where is the Outside-in product thinking as a service. Where is the  Training as a service. Where is the Incident Management as a Service. Where is the Busting Canonical Domain Model as a service. Where is decomposing monoliths as a service. Where is the Refactoring databases as a service. Where is Decomposing UIs as a service ? Where is the Outcomes as a service ? Where is the Human as a Service. 

Remember that the human aspect of the cloud is the biggest force function enabler that will enforce the razor focus on outcomes rather than technology envy. As I sit here reflecting on all the technology choices that are passing through > microservices, serverless, kubernetes, cloud foundry, the million choices from CNCF,  please remember the cloud revolution needs to be customized to your needs and not the other way around. 

Pick and chose the boring technology choices available that get the job done and allow you to reach your objectives and key results. Do not forget that the ultimate goal is increased frequency software releases, reduced change failure rate, reduced lead and cycle time to iterate fast and converge on the right outcome. 

So yeah please install PCF, gke, aws, openstack, vmware , azure or whatever but remember software is a means to the end and it is the END that has always to be kept in mind unless your core business is the business of software itself. 

* I have money on AWS-on-prem being announced this ReInvent. 

Day 2 Application Operations

What are the set of practices you need to inculcate and internalize to keep your app alive in production ? Here is a checklist that can help ...

1/ Use spring boot actuators in production … AppManager has secret sauce integrating with actuator allowing for easier management  and visibility of your app of PCF. all your actuator endpoints

2/ When it makes sense add custom health indicators that add to the default health indicators

3/ Add spring cloud sleuth to your classpath dependencies so that you can visualize the call flow across microservices threads with zipkin in PCF Metrics http://docs.pivotal.io/pcf-metrics/1-4/using.html

4/ Plug a syslog drain to the end of the Firehose using the appropriate nozzle like https://docs.pivotal.io/partners/splunk/index.html

5/ Emit application or domain level metrics using Micrometer https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready-metrics.html

6/ Starting PCF 2.2 you can configure alerting and autoscaling on any custom app metric. Custom rules for autoscaling.

7/ Use VisualVM and sister tools from the JVM to get deeper insight particularly for performance issues. Here is a good article on setting up VisualVM with an app running on Cloud Foundry. Furthermore the ability to take threaddumps and heapdumps is critical in analyzing performance issues specifically How to generate Java Application thread dump from Cloud Foundry container and How to generate and download Java Application heap dump from Cloud Foundry container and How to know if an app is responsible for high CPU in a Diego Cell and how to find it

8/ Leverage canaries to understand the quality of the app and then scale up with Blue/Green. concourse-pipeline.

9/ Create a SLI/SLO dashboard to get immediate visibility into your error budgets and uptime.

10/ Practice an outage handling event and run through debugging common scenarios like OOM, hangs, deadlocks using cf-ssh, and boot actuator endpoints. Create a program around incident response management.