
Red Hat Cloud Forms migrating to IBM Cloud Pak - theonelinuxway
https://blog.christophersmart.com/2019/12/19/red-hat-crippling-cloudforms-product-and-migrating-users-to-ibm/
======
robszumski
I work at Red Hat and I think your conclusion here is wrong, but I understand
how you arrived there. I'm not involved with Cloud Forms directly, but its
future was in flux before the IBM acquisition and making it part of the IBM
Cloud Pak means that it will have a solid future with resources from IBM and
Red Hat. And better yet, happening in the open source ecosystem.

~~~
jacobsee
Agreed. I don't think this is something that came from IBM... This is rooted
in decisions that were being made before the acquisition was even announced.

------
freedomben
Disclaimer: I work for Red Hat (but not on Cloud Forms)

I don't have any inside info, just grapevine and rumors, but this is not that
unexpected and doesn't have a ton to do with the IBM acquisition either. Cloud
Forms is complicated to use and not that popular. Its head was already on the
chopping block.

I am not worried that IBM is going to start killing Red Hat products or
"cannibalizing" them. IBM is going to adopt more Red Hat tech, and Red Hat may
start using more IBM stuff internally, but I don't see big changes coming.

~~~
oso2k
Disclaimer: I interviewed/hired/work in the same group with FreedomBen at Red
Hat.

There's been lots of internal talk over the last 3 years of what to do with
CloudForms. The customers who love it, REALLY love it and do amazing things
with it. And our internal training group had the world's largest CloudForms
installation(s), so we really ate the dog food. But you really do need to be
of certain sizes to "grok" CloudForms value proposition.

------
Spooky23
That’s a dramatic title. Geez.

All of these console of console products are way complicated and expensive.
IBM needs to keep theirs because it is used for their power platform and
zlinux.

People who want to do the single pane of glass thing are probably better off
with VMWare if they want to move workloads around or terraform if they want a
recipie type system.

------
eb0la
Openshift is _the_ platform of choice for IBM products on linux right now.

The new IBM Cloud Paks run on Openshift (both for x86 and system Z hardware).

~~~
keyle
(Openshift)

------
policypaul
Really disappointing to start seeing this after all the assurances that were
made during the merger about strong support for open source.

~~~
jethro_tell
This happens every single time. Founders that don't want to see this can't
have their cake and eat it too. It just doesn't work like that.

~~~
btown
Well, if you have a _reliably_ profitable business,
[https://en.wikipedia.org/wiki/Dividend_recapitalization](https://en.wikipedia.org/wiki/Dividend_recapitalization)
and similar lesser-known options can allow founders to retain control while
providing liquidity. You can't have your cake, eat it too, and have the cake
be made out of air... but you can pick two out of three.

~~~
jethro_tell
This is true, but many(most?) of these companies aren't in that strong of a
place yet. Red Hat might have been but a side effect of the investor driven
rocket growth model is that even if you're setup to have a strong company, you
often don't have the position to make these kind of deals.

------
gnufx
I've not found anyone who has used them both, but if you're worried about
Cloud Forms going away or dropping things, and don't want just ManageIQ, maybe
look at OpenNebula. It seems to be something like tractable
OpenStack+ManageIQ, from the point of view of someone who hasn't either of the
latter. [https://opennebula.org](https://opennebula.org)

I'd be interested if anyone can compare and contrast.

------
fractalf
Who really uses RedHat? (serious question) ..I haven't used it since the 90's
and can't evem begin to grasp why they are such a big player. What does it
offer that other distros don't?

~~~
NikolaNovak
Enterprises.

We don't consider large-scale boring ol' enterprises much in HN; but I
wouldn't be surprised (I have no data one way or another) if boring RHEL
instances in boring Enterprise/Government datacentres and clouds doing boring
things outnumber shiny linux instances in more glossy usage.

What does it offer - support. And support is important when you have something
important, when you need to hold somebody accountable, when your core
expertise or market value is not patching and fixing your backoffice software
yourself, or when you simply need to pass an audit, security policy,
regulation, etc.

Also, stability. Not in the software/OS stability sense (although it's pretty
good there); but in the "I'm going to put RHEL on my roadmap and invest in
education and processes and procedures and documentation and ecosystem based
around it, because I believe it'll still exist in 10+ years, which is the
timespan some of my projects and certainly my company are based on".

(Edit - I mean, hell; Enterprises run _AIX_ , which many of you kids will have
to Google;). And for what it needs to do AIX is freakin' awesome. And for most
other things it's wildly inappropriate and ineffective:)

~~~
all_blue_chucks
Listen, you are entirely right, but in a backward-looking way. The entire
industry is moving in the direction of lambdas/functions and containers. The
value of OS support is racing toward irrelevancy.

~~~
mroche
Which industry, there’s no blanket all-encompassing “industry”? There are
still those who don’t live purely the web. Every place I’ve worked at has used
RHEL (public university and Film/VFX/animation), and it’s for the exact
reasons as written above and sibling/child comments.

Do we integrate with/use cloud and container solutions for services that align
with that? Yep. But you can’t just dismiss the foundation, no matter how
recursively down the chain you need to go, that it all runs on just because
you don’t have to deal with it (“you” in the general sense).

~~~
all_blue_chucks
The IT industry. Companies that aren't primarily focused on technology tend to
lag years behind the tech sector with tech adoption, but they follow
eventually.

~~~
jm4
Not really. At least not always. No offense, but you sound like someone
relatively new to IT (as in a few to several years). Stay in this field long
enough and you see history repeating itself. After you witness a few cycles
you will have a completely different perspective.

Some of these companies - I’m excluding the ones that are just hopelessly out
of date and out of touch - simply have different needs. This is especially
true when a significant portion of the tech - maybe the majority - faces
inward. There’s not much value in elastic cloud computing when your workload
is relatively stable over a period of years and it’s running a bunch of back
office stuff that’s not part of your company’s product.

~~~
all_blue_chucks
20 years in tech at leading companies here. Nobody is building new workloads
on the old model. I'm not talking about fad following startups here.

It is a simplification to the point of being wrong to say everything in tech
is cyclical. Some things are in some ways, but for the most part we progress
forward, not back.

You seem old and out of touch. No offense. But when people aren't able to keep
up they sometimes invent fantasies that their skills will remain relevant
forever. That's never really been true unless you actively search out
confirmation bias and ignore the vast majority of what's happening in the
field.

~~~
jm4
I stand by my previous comment. I was like you once, thinking everyone else
who isn’t on the bleeding edge is an out of touch idiot with an outdated,
irrelevant skill set. There’s a time and a place. It really depends on your
requirements. Maybe your experience has been more focused so that you haven’t
had to deal with much with more diverse requirements. Or maybe you’re not the
guy on the hot seat who risks budget, company performance and people’s jobs
with tech decisions. Call me a dinosaur. I don’t care. I use the right tool
for the job whether it’s new or not.

------
acd
I think Open source will win in the long run. Simply because there are more
software engineers working on open source software than there is on closed
software. So from an economic standpoint closed software cannot compete. This
is true of even very large corporations.

Hopefully IBM will open source Spectrum scale / GPFS general parallel file
system and integrate that with Red Hat.

~~~
robertfw
> there are more software engineers working on open source software than there
> is on closed software

I would have thought that the opposite is the case; most engineers work on
closed source software

~~~
mixmastamyk
Not in areas where it has become a commodity.

------
thenewnewguy
It might be better to use the linked post's title?

------
mathattack
From one “audit as a profit center” vendor to another. They’re both brands
milking their glorious past at the expense of the present.

------
theonelinuxway
CloudForms is Red Hat’s supported version of upstream ManageIQ, an
infrastructure management platform. It lets you see, manage and deploy to
various platforms like OpenStack, VMWare, RHEV, OpenShift and public cloud
like AWS and Azure, with single pane of glass view across them all. It has its
own orchestration engine but also integrates with Ansible for automated
deployments.

As best I can tell, their CloudForms updated Statement of Direction article
(behind paywall, sorry) shows that Red Hat is killing off support for non-Red
Hat platforms like VMware, AWS, Azure, etc. The justification is to focus on
open platforms, which I think means CloudForms will ultimately disappear
entirely with Red Hat focusing on OpenShift instead.

We made a strategic decision to focus our management strategy on the future —
open, cloud-native environments that promote portability across on-premise,
private and public clouds.

CloudForms updated Statement of Direction However to me this is still a big
blow to users of the platform, where I’m sure most will have at least some
VMWare to manage. Indeed, when implementing CloudForms at work and talking to
Red Hat, they said that their most mature integration in CloudForms is with
VMWare.

According to the Red Hat article, CloudForms with full platform support is
being embedded into IBM Cloud Pak for Multicloud Management and users are
encouraged to “migrate your Red Hat CloudForms subscriptions to IBM Cloud Pak
for Multicloud Management licenses.” Red Hat’s CloudForms Statement of
Direction FAQ article lays out the migration path, which does confirm Red Hat
will continue to support existing clients for the remainder of their
subscription.

So in short, CloudForms from Red Hat is being crippled and will only support
Red Hat products, which really means that users are being forced to buy IBM
instead. Of course Red Hat is entitled to change their own products, but this
move does seem curious when execs on both sides said they would remain
independent. Maybe it’s better than killing CloudForms outright?

We can publicly say that all our products will survive in their current form
and continue to grow. We will continue to support all our products; we’re
separate entities and we’re going to have separate contracts, and there is no
intention to de-emphasise any of our products and we’ll continue to invest
heavily in it.

Jim Whitehurst as Red Hat CEO

~~~
oso2k
Disclaimer: I'm a Red Hat Consultant.

The TFA linked RH Article [0] is "paywalled" behind a "free cost" user
registration. You just need a valid email. I've copied the text from that
article

    
    
       As customers accelerate and scale their open hybrid cloud initiatives, management becomes
       increasingly essential. Given this requirement, we made a strategic decision to focus our
       management strategy on the future -- open, cloud-native environments that promote portability
       across on-premise, private and public clouds. With this strategy update, the roadmap for
       Red Hat CloudForms is summarized in three key points:
    
       1. To date, Red Hat CloudForms has managed both open source and proprietary technologies.
       2. Moving forward, Red Hat CloudForms will continue to directly support open Red Hat platforms
       like Red Hat OpenStack and Red Hat Virtualization. As of March 1, 2020, Red Hat will no longer
       offer NEW CloudForms subscriptions for non-Red Hat platforms. For renewal options, please
       see CloudForms Statement of Direction FAQ.
       3. For non-Red Hat technologies (VMware, AWS, Azure, etc.), IBM is embedding CloudForms in
       their Cloud Pak for Multicloud Management and will be working in the ManageIQ community
       (upstream for CloudForms). Beginning March 1, 2020, IBM will also be offering an easy migration
       path from Red Hat CloudForms to this Cloud Pak.
    
       Red Hat will continue to work in CloudForms’ upstream community, ManageIQ, to support our
       offerings. For management of non-Red Hat products, IBM is also working in the ManageIQ
       community and embedding CloudForms support in the IBM Cloud Pak for Multicloud Management. For
       Red Hat CloudForms customers interested in managing heterogeneous environments, IBM is
       offering an easy migration path from Red Hat CloudForms to this IBM Cloud Pak.
    
    
    

[0]
[https://access.redhat.com/articles/4639821](https://access.redhat.com/articles/4639821)

------
jakemal
The headline is extremely editorialized and attempts to steer the discussion
in a very specific direction. Can the mods change the title to match the
article headline?

~~~
dang
Is the article title accurate? What's an accurate and neutral title?

It obviously needs to be changed, but I'm not sure what to change it to.

~~~
robszumski
How about "Red Hat's Cloud Forms is migrating into an IBM Cloud Pak"?

~~~
dang
Ok, let's try that. Thanks!

Submitted title was "IBMs Cannibalization of RedHat Begins". That broke the HN
guidelines by editorializing
([https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)).
Accounts that do that eventually lose submission rights on HN, so please don't
do that.

------
hugi
IBM is a company that designed a human cataloging systems for the nazis for
extermination purposes. I sincerely hope you love working for them.

edit: I’m not sure why I’m getting downvoted, I just stated a known fact. Did
I do something wrong?

~~~
dang
Your comment broke the site guidelines badly, being both extraneous flamebait
and a personal attack. Please review
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)
and stick to the rules in the future. You've broken them frequently, and if
you keep doing so we're going to have to ban you.

Using people's employment information to attack them is particularly bad for
HN, since it disincentivizes users to show up and talk about their work, which
is likely to be the thing they know the most about. That would make HN
strictly worse, so it's a no-brainer not to allow comments like this.

[https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20disincent&sort=byDate&type=comment)

We detached this comment from
[https://news.ycombinator.com/item?id=21830516](https://news.ycombinator.com/item?id=21830516)
and marked it off-topic.

------
buzzkillington
I for one am happy that RedHat is dying.

The most contentious and unfriendly projects in the Linux ecosystem are run by
its employees and the interests of the rest of the community run directly
counter to those of RedHat and by extension it's employees: software that
doesn't need a gaggle of engineers to run vs software that you have to buy a
subscription for.

If software is so easy to build, run and debug that you don't need support for
you won't buy support for it. Every enterprise I've been at in the last 10
years had CentOS for the engineers who knew their way around Linux and RHEL
for those that didn't. It was completely up to you which one you chose. The
only push to anyone buying RedHat was how impossible it was to build your
projects without someone holding your hand or wasting days reading
documentation.

~~~
a1369209993
I just wish they'd died soon enough to take systemd and wayland down with
them; it doesn't look like that's going to happen.

~~~
buzzkillington
I seriously doubt there will be the manpower to keep pushing those projects
once the money dries up. They are not intrinsically interesting and their
implementation leaves a lot to be desired of.

There will be yet another huge mess left for the distros to deal with then
things will be back to normal in two or three years with everyone remembering
why the Unix philosophy is important and that 'this time it isn't different'.

~~~
mixmastamyk
Am open to improvements but not going back to a shell-script-based boot,
thanks.

~~~
JdeBP
The predecessor for systemd on Fedora was upstart, not van Smoorenburg init.

~~~
loeg
Somewhat briefly, sure. Upstart was used in Fedora, _in SysV compatibility
mode_ , from 9 (2008-04)[0] up until 15 (2010-10)[1], or about 2.5 years.

Fedora prior to 2008 used classic Redhat runlevel init (what you're calling
Smoorenburg). From the first release in 2003, through Fedora 9. So we have 4.5
years of "SysV init" followed by 2.5 years of Upstart in "SysV init"
compatibility mode.

That said, your comment isn't especially responsive to GP; both Upstart and
Systemd in Fedora continued to use a bunch of shell scripts to define startup
actions. It wasn't until the systemd unit file conversion efforts[2] around
2012 that Fedora largely moved to services defined as data in "INI"-style
configuration files.

GP's "shell-script-based boot" is not an unfair way to characterize Fedora's
boot process prior to (and including the early history of) systemd in Fedora.

[0]:
[https://fedoraproject.org/wiki/Features/Upstart](https://fedoraproject.org/wiki/Features/Upstart)

[1]:
[https://fedoraproject.org/wiki/Features/systemd](https://fedoraproject.org/wiki/Features/systemd)

[2]: [https://fedoraproject.org/wiki/Features/Systemd-unit-
cleanup](https://fedoraproject.org/wiki/Features/Systemd-unit-cleanup)

~~~
JdeBP
Miquel van Smoorenburg never worked for Redhat that I know of. It was not a
"Redhat init" as you call it. Indeed, it wasn't even _init_. The things that
we are talking about are _rc_ , not _init_ , in the van Smoorenburg system.

Nor was there the sort of exclusive "compatibility mode" that you are
envisaging in order to make your argument that mixmastamyk was referring to
Upstart. Upstart could employ van Smoorenburg rc scripts, but that was not a
_mode_. Upstart was still event-driven with job files. The van Smoorenburg rc
scripts were run via what was just another job file. Were your argument valid
for Upstart, it would equally be valid for systemd's mechanism for invoking
van Smoorenburg rc scripts, and you would have to say that _systemd is shell-
script-based boot_ , which really makes a nonsense of mixmastamyk talking
about "going back" to it from systemd.

Quite clearly, going back to Upstart is _not_ what mixmastamyk was talking
about, which not least can be seen from xyr comment written, next to yours, 4
days beforehand.

