The Cloud is sexy. It's the current shiny thing. It's the popular trend.
Reality is that cloud tech is simply a resurrection of service bureaus
from years back. That's not a judgement pro or con. But if your business
opted to move AWAY from the service bureau then why do you want to
RETURN by way of the Cloud?
Cloud is nothing more or less than outsourcing.
Outsourcing makes a lot of sense for a whole lotta reasons. And
sometimes it doesn't.
I recommend a hybrid approach in all cases: think carefully about what
you will and will-not outsource.
I was with Voltage Security for 7 years. Their centerpiece is
format-preserving-encryption. Many of our customers wanted to migrate
selected workloads to the cloud. It's a great use case for FPE, and in
those situations I advised that they go ahead and move processing to the
cloud while keeping the keys on-prem.
When considering a cloud migration, be diligent to peel-back the emotion
(discomfort) of moving certain computing work off-site and consider the
factual risks. If the risks are low, then go! If the risks outweigh,
then stay.
I really appreciate the experience Steve recounts. So many of these
projects have failed to account for hidden costs and other such factors.
I've personally encountered some and witnessed too many from a distance.
Here are some points:
* break it down into smaller chunks (move a few applications or
services at a time, not all at once)
* avoid re-write (if you've got working COBOL, don't convert it to
Java, for example)
* consider architectural needs (if you're on Z, should you continue on
Z?)
* be open to re-compile (if you're using Linux on Intel, you might do
fine with Linux on ARM from your cloud service, maybe)
* beware beneficiaries (if someone is getting a hefty bonus on the
deal, they might not be objective, or "follow the money")
* own what matters most (retain control of your actual business, maybe
keep crypto keys on-prem, just one example)
* get it in writing (ensure that all parties recognize and "sign" the
requirements, deliverables, and margins), and speaking of margin
* build-in some margin (there WILL BE overruns, prepare for a percentage)
* get objective help (a consultant or several or even a contracted
partner)
Regarding architecture, Z is initially about that awesome hardware. But
you might need z/OS itself, for which you can get a range of supporting
hardware and/or emulation.
Lance mentions DB2, and we know that "DB2" on AIX is not the same as DB2
on MVS.
Regarding re-write, there's no code more reliable than that which has
been vetted over years (decades) of use. New code always has bugs. A
re-write will therefore introduce bugs.
This must of course be considered in context: if you're changing the
system then you might uncover old bugs never seen before.
I'm surely missing something important. But this is a forum, so someone
else might see what I missed and chime in. :-)
-- R; <><
On 8/30/23 10:17, Steve Thompson wrote:
I do not have any experience with "cloud" mainframe per se. I do have
experience with CaaS (Compiling as a Service). Contact me off line if
you want into on that.
I do have experience with outsourced mainframes having worked for ACS
when they were in the biz.
Per that experience, I predict that the initial costs will be
wonderful and about 5 years out the costs will be above what was
expected with a consideration of migrating back to in house (prem).
Just based on how things went with ACS and some of its competitors
where we had entities come in and go out.
Steve Thompson
On 8/21/2023 2:22 PM, Lance D. Jackson wrote:
List,
Has anyone had experience (good or bad) with migrating their
mainframe Db2 workload from on-prem to the cloud?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
