[wplug-internet] PaaS, instead of Hosting? -- New Linode upgrade available

[Bryan J Smith]

On Mon, Apr 28, 2014 at 10:51 AM, Bryan J Smith <b.j.smith at ieee.org> wrote:
> On Mon, Apr 28, 2014 at 9:13 AM, Justin Smith <justin at adminix.net> wrote:
>> Before you brought this up, I had never bothered to look into OpenShift even
>> though I'd heard the name mentioned before. Not sure if anyone else in the
>> group has worked with this.
>
> OpenShift solved an immediate need for Red Hat's customers, especially
> Middleware (JBoss).  It provided a way to instantiate multiple stacks
> on the same host OS, but contain them via cgroups, SELinux, etc...  As
> a natural byproduct, other languages and different database stores
> could also be provided.  RHSCL came out and allows different, newer
> upstream version languages and database releases, that Red Hat will
> maintain backports on for several years.
> OpenShift "just works" today and doesn't require a lot of integration
> or development.  Cartridges are easy to create and deploy, hence it's
> popularity with a growing number of Middleware customers, and for even
> non-Java solutions.  LXC support, with libvirt abstraction, was always
> planned for RHEL7 and an eventual RHEL6 backport.  Now Docker is
> pretty much the direction everyone wants to go, including Red Hat.
> RHEL7 will have it, and there will even be a special release --
> "Atomic" -- that is a very minimal host for containers.  There will be
> more limited Docker solution backported to RHEL6.

Once again, I want to clarify I'm not suggesting OpenShift as "the"
PaaS solution, if a PaaS solution is under consideration.  There are a
lot of PaaS solutions out there, several using LXC or container-like
approaches.  This includes dotCloud, the company behind Docker, who
offer their own PaaS too.  Many PaaS solutions do "just work," and
OpenShift is not the only one.

I only mention OpenShift if people want a Platform based on RHEL+RHSCL
versions of languages, databases, etc... that are maintained multiple
years with backports so the ABI/API changes are mitigated because the
versions are not rebased.  Some people consider this as a bonus (don't
have to rewrite code), while others view it as a limitation (not
always the latest), although the latter is less of an argument with
RHSCL adding newer languages and database versions, all while they are
maintained for years and not rebased.

This includes if anyone wants to prototype or even have Red Hat host
portions of the next WPLUG or any other site on a RHEL+RHSCL PaaS.

-- bjs