SOA & WebLogic - Lift & Shift to the Cloud

Copyright © 2017, eProseed and/or its affiliates. All rights reserved. | Confidential
SOA & WEBLOGIC:
LIFT & SHIFT TO THE CLOUD
Simon Haslam
Bruno Neves Alves
eProseed
1
Middleware & Integration SIG
28th September 2017, London

Copyright © 2017, eProseed and/or its affiliates. All rights reserved.
Simon Haslam
Technical Director and Partner
CTO Group
UKOUG volunteer & speaker since 2001
Oracle ACE Director (Middleware & SOA)
2
ABOUT US
Bruno Neves Alves
Technical Director and Partner
CTO Group
Presenting at UKOUG since 2014
Specializing in SOA/BPM
22 Oracle Specializations… and counting.

3 Membership Tiers
• Oracle ACE Director
• Oracle ACE
• Oracle ACE Associate
bit.ly/OracleACEProgram
500+ Technical Experts
Helping Peers Globally
Connect:
Nominate yourself or someone you know: acenomination.oracle.com
@oracleace
Facebook.com/oracleaces
oracle-ace_ww@oracle.com

AGENDA
How SOA/WebLogic on-premises compares to SOACS/JCS
Migration approaches
AppToCloud
CI/CD Pipelines with Developer Cloud Service
1
2
3
4
4

COMPARING
SOA/WEBLOGIC ON-PREMISES
WITH SOACS/JCS
5

(RECAP) WHAT IS JCS?
JCS:
– WebLogic Server instances, optionally Oracle Traffic Director instance(s)
– Runs on Oracle infrastructure
• Typically located in Oracle data centres but option for Oracle infra to be in your DC
– “Classic” IaaS with Shared or IP Network
– Base WebLogic (and web tier) platform is provisioned automatically
– You have to keep installation “supportable”
– Subscription based service
• Metered: pay by OCPU (Intel core) per hour or per calendar month
• Unmeted: commit to fixed number of OCPU for a year
6

(RECAP) WHAT IS SOACS?
SOACS:
– SOA Suite in various flavours (SOA/OSB/B2B or MFT or Insight Analytics)
– Same as JCS though except behind on some features
• IP Networks on JCS last year, same to SOACS in August 16 release
• Oracle Stack Manager (supported JCS from start, not yet SOACS)
7

TERMS (AND A FEW TOOLS!)
Deployment
• Platform to top of app
Provisioning
• Bare metal up to platform
8
make
(and many, many more!)
Note: container technologies (e.g. Docker) and DevOps approach are blurring this distinction
Application
Platform
Infrastructure

SIMPLE JCS COMPARED TO SIMPLE WLS
9
• Characteristics:
– Web tier (usually)
– Single-node
– No usually shared storage
optional
OTD
Oracle Cloud software firewall
Adm
Svr
1
Mgd
Svr
Reasons for having OTD, even for a single node cluster:
• Enhanced security (OTD has good track record)
• Reduces attack surface (web server cf app server)
• A cluster of 1 can be expanded online later

MULTI-NODE JCS CF TYPICAL EDG
• Characteristics
– Load balancing & web tier
– Multi-node
– Shared storage
10

MULTI-NODE JCS CF TYPICAL EDG
• Load balancing
• OTD in place of OHS
– Second node possible (identical config)
– No multi-case VRRP failover
• Shared storage
– Use JDBC for JMS and JTA
11
OTD
optional
OTD
Oracle Cloud software LB
JCS has same WLS topology as EDG
except for admin server failover

HOW DIFFERENT IS SOACS FROM JCS?
• Pretty much the same
– Underneath it (currently) fully provisions JCS then extends to SOACS
– JCS been available for longer than SOACS
• How is it different?
– Stack Manager is not yet available for SOACS
– Cloud consoles differ (e.g. patching)
– SOACS provisioning is an extra layer on top of JCS so you have fewer options during
provisioning (e.g. can’t change domain name)
• Basically the same though
12

PROVISIONING CHOICES COMPARED
• On-premises
– Manual
– DIY-scripted
– General purpose tools, e.g. Puppet + orawls*
– Enterprise Manager Cloud Control MWaaS
• Cloud
– Automated via manual consoles
– Automated via REST APIs
• APIs offer orchestration options (e.g. Stack Manager, 3rd party tools)
13
* See my OUGN 17 presentation
https://www.slideshare.net/Veriton/driving-devops-for-oracle-with-the-orawls-puppet-modules

POST-PROVISIONING FOR EITHER CLOUD OR ON-PREMISES
• Security
– Certificates, security & trust
– Authentication providers
– Probably extra admin users
– VM users (SSH keys etc)
• Shared persistent stores when clustered and state in middle tier
• Next step, deployment… all app level resources, e.g. JDBC, JMS etc
14
Note: DR is further work…

MIGRATION APPROACHES
15

WHAT DO WE MEAN BY “LIFT AND SHIFT”?
• Jargon
– ideally a straight transfer from one location to another
– “move” rather than upgrade/migrate/change
• Term is used loosely!
16

DATABASE CONSIDERATIONS
Users with a WebLogic tier almost invariably has an
associated Database tier
– Don’t separate Application from Database over high latency links!
➢If you are moving your WebLogic tier you have to co-
ordinate this with a Database move too
➢Exception is stateless middle tiers, such as integration
products like OSB and SOA (SOA if no state)
17
DB WLS
WLS
WLS

ANALOGY
• Compare with how we upgrade on-premises systems:
18
In Place
No new target env
Longer downtime
Greater risk
More complex roll-back
Less change in process possible
Side-by-side
Pre-preparation of target env
Switchover so shorter/~0 downtime
Greater cost – two sets of envs
Roll-back = switch back
Changes to topology etc easier
• Lift and shift to Oracle Cloud is comparable to side-by-side
– will almost certainly involve an upgrade or change of version
– approach determines how much of the pre-preparation advantages you have

TOOLS
• Depends on layer you are moving
– Virtual Machine: could use Oracle Ravello if going to Oracle Cloud
• Nearest thing to true lift and shift – hosts, networks, OS stays the same to WebLogic
– Application migration tools
• AppToCloud – packages up application artefacts and configuration of resources
• Enterprise Manager Cloud Control, or Oracle Virtual Assembly Builder (deceased?),
can introspect platform and generate a model to recreate – working at IaaS layer
though
– Existing automation may already make migration tools unnecessary
19

• Side-by-Side provisioning
• Smoke Testing (Connectivity, Backup/Restore, etc)
• Instance drained down
• DB Export from deprecated instance for reporting
• App Resources and Baseline Configuration (Partly
Automated)
• Automatic Deployment of latest artefacts from CI
Artefact Repo
• Final cut-over: shut down composites, switch over
backend, smoke test, switch over DNS, test, bring up
services
• Shutdown and Delete Old Instance
• Ask Oracle Support and CSM to confirm deletion
20
SIDE-BY-SIDE MIGRATION EXAMPLE
SOACS 12.1.3, needed new for unmetered 12.2 &
because no SOACS 12.1 to 12.2 upgrade route
v12.2.1
v12.1.3
DBCS
DBCS

APPTOCLOUD
21

APPTOCLOUD OVERVIEW
• AppToCloud tooling released ~Autumn 2016
• Application database migration is separate
• Downloadable java-based tool that you run on your on-prem
Admin Server
• Oracle JCS can create an instance from AppToCloud output
• One-way only: On-premises App -> Oracle Cloud
22

STEPS
1. Check pre-requisites (run tool to check)
2. Run health check
3. Export domain to jar file -> upload to Storage cloud
4. Create JCS instance from the file Storage cloud
5. Import app artefacts from the file in Storage cloud
6. Post configuration
23

APPTOCLOUD RESTRICTIONS & CONSIDERATIONS
• JCS only
• You need to consider database carefully – various options (e.g. DataGuard) but you
typically want middle & database tiers in same DC at all times
• Your target will always be on WebLogic 12c
– Your app needs to be regression tested against 12c if still on 11g
– Even if you are on 12c JCS has specific versions/patch levels you should check
• Single WebLogic domain with only single cluster allowed in one move
– Migration from multiple source domain clusters is possible but into separate JCS instances
• Source domain cannot be JRF (except for restricted JRF) (there’s no FMW repo
migration). => Rules out SOACS. (imagine dehydration store migration though!)
• Source must be either non-MT or single global MT domain
• Source must be healthy (active deployments, health MS, etc)
24

SIMON’S UPGRADE TOOL PARADOX!
“Those with most to benefit from an upgrade tool probably don’t need it!”
- me
25
Many
Few
Low
App/env complexity
High
NumberofEnvironments
✓


DEVELOPER CLOUD SERVICE
26
Continuous Delivery to Cloud
Illustration by Nhan Ngo, Product Owner at Spotify on the Continuous Delivery process
described by Jez Humble and David Farley in the Continuous Delivery book

DEVELOPER CLOUD SERVICE
27
Developer

FUNCTIONALITIES

On-Prem
Servers
REUSE YOUR EXISTENT ON-PREM ASSETS ON CLOUD
IDEs Cloud
Instances
Task
Management
Code
Review
Development
Automation and Continuous
Integration
Release
Pipeline Management

SUMMARY
33

SUMMARY
• SOACS/JCS compares to well-configured on-premises SOA and WebLogic installation
– Easier, automated provisioning with pre-set sizing & topologies
– All JCS instances include FMW Infra for OPSS etc (so need a DBCS instance)
• Migration options to Cloud
– Side-by-side - clean re-deploy or use a tool
– AppToCloud offers entire domain migration including apps and resources; note cluster restriction
• CI/CD Pipelines with DevCS
– DevCS is mostly pre-integrated with JCS & SOACS
– Free with PaaS so opportunity to adopt modern tooling rather than DIY
– DevCS is easy to set up
– Reuse your existing on-premises CI assets on DevCS smoothly
34

SOA & WebLogic - Lift & Shift to the Cloud

SOA & WebLogic - Lift & Shift to the Cloud

More Related Content

What's hot (20)

Similar to SOA & WebLogic - Lift & Shift to the Cloud (20)

More from Simon Haslam (20)

Recently uploaded (20)

SOA & WebLogic - Lift & Shift to the Cloud