
Managing heterogeneous environments with ManageIQ - tenderlove
https://lwn.net/SubscriberLink/680060/c0650cff2e612670/
======
kseifried
I hate to say this but I think we need solid abstraction of the cloud
providers otherwise you'll end up locked into one, and that probably won't be
much fun in the long term.

~~~
ghaff
Ultimately you need to make the choice about whether you're going to write
applications in a way that make use of elements (like language frameworks)
that are portable across providers along with the fairly standard software
defined services.

Today, there is abstraction across a number of those standard services but, if
you look at AWS for example, there's a _lot_ of AWS-specific services that
you're going to have to reimplement--largely from scratch--if you move off
AWS. That may be a rational bet for some companies to make if one or more of
those services provide a lot of value. But I'd hope it's a bet that they make
deliberately rather than falling into it and waking up one day to discover
that they have no practical way to move providers.

~~~
geertj
My view/hope is that at least for basic application level services, that the
abstraction is going to be provided by containers and their orchestration
platforms (e.g. Docker/Kube). It can credibly give you scaling, data
persistence, network isolation, service discovery, load balancing, and with
some work, a database (when packaged in a container with a persistent volume).
An app using only these basic services basically has zero cloud lock-in.

On top of this there are many additional useful services that AWS, GCP and
Azure provide. Using those does indeed give you some level of lock in, but
only when these services are not available as a generic TCP/IP services (or
not performant when accessed from a different cloud). This is where
application designers need to make a trade off.

~~~
ghaff
Agree 100%. In addition to language frameworks, as you say, you also have
orchestration, application definition, failover, storage persistence, etc.
services that can be made largely portable between providers. Containers,
while probably not necessary, likely help by letting you decompose things and
package them up in a way that you can move them between providers.

------
awinter-py
[http://manageiq.org/pdf/ManageIQ-0-Lifecycle_and_Automation_...](http://manageiq.org/pdf/ManageIQ-0-Lifecycle_and_Automation_Guide-
en-US.pdf)

you know you're getting real value when the docs explain pull-quote
conventions and PXE provisioning before listing the product's features.

What does this actually do?

