Juju vs Openshift

Tue Jun 27 17:34:12 UTC 2017

Juju doesn't have to be responsible for translating the model into the
underlying substrate.

The Charms have always been responsible for interpreting the model. t's the
Charms that figure out what it actually means to "connect Wordpress to
MySQL". This has allowed Charms to become very smart, without adding any
complexity in Juju core.

We should to the same for the workload level, and a process container is
just a workload running on top of a container platform. I created a
proof-of-concept of this here: https://jujucharms.com/u/
tengu-team/limeds-core/

[image: Inline afbeelding 1]

A limeds container running on a Docker engine. The container is sent over
the relationship. It's up to the Docker charm to figure out how to run it.
Now that a docker container is part of the model, we can do a bunch of cool
stuff like connecting loadbalancers, databases and other stuff to the
docker container: https://jujucharms.com/u/tengu-team/limeds-bigdata/

[image: Inline afbeelding 2]

We can swap out the Docker Charm and put Kubernetes in its place because
it's the Charm that decides what it means to run a Docker container. We're
extending Kubernetes with support for this: https://github.com/tengu-team/
layer-kubernetes-deployer

Charmers suddenly get the power to support new container management
platforms such as openshift or swarm. No change in Juju core needed!

I think such an approach is the only way to be able to keep up with the
rapidly changing landscape, because let's be honest, containers
orchestrators aren't the first, nor will they be the last hype. *Any
"assumptions" Juju makes about containers will probably not be true in a
few years time*. Already Kubernetes is creating multiple ways to
dynamically reconfigure containers at runtime... Do we really want to keep
updating Juju core when any of these assumptions change? The only
assumption Juju should make is "I have no idea what to do with this, so
I'll just let the Charms figure it out".

Only a single change in Juju core is needed: create the concept of a
virtual "workload" charm that can communicate with other charms but doesn't
have access to any os.

2017-06-27 14:23 GMT+02:00 Rick Harding <rick.harding at canonical.com>:

> I think the reason it's challenging, and that you're seeing different
> tools for different systems, is that each time you want to model something
> you have to make sure you can translate the model into the underlying
> substrates clearly and precisely. To date, Juju hasn't expressed a model on
> the process container world because Juju's model is built upon a set of
> promises that it can make sure each supported substrate can fulfill.
> OpenStack, public cloud, MAAS, etc all have these nice primitive ideas that
> are similar enough that a model can be expressed and then put into place
> onto those different substrates but the promises of the model still hold
> true.
>
> As we've looked at expanding the model to support things like process
> containers there are challenges and opportunities. The immutability of the
> containers breaks a bunch of Juju promises, such as the adaptability when a
> relation is made between applications. There's work that needs to be done
> such that a model can either make clear the differences (say you can model
> applications as well as process containers as different ideas in the model)
> or you need to update and close the gaps between the substrates.
>
> I think you're right on point and that we're aligned on the idea that you
> construct a model of what you want and then allow the system to go and make
> it reality. I think the trouble that we're currently in, and that you're
> finding as you look at options, is that there's a gap at the moment that
> needs to be closed. Folks are trying to say that we're all techies and love
> using the right tool for the right job, and currently there are some things
> that go great into process containers, some things that do better in
> machine containers, and some things that really want to be on raw hardware
> to operate at their best. Over time we hope Juju will expand to help define
> the model across each of those scenarios.
>
> On Tue, Jun 27, 2017 at 12:13 PM Giuseppe Attardi <
> giuseppe.attardi at garr.it> wrote:
>
>> OK, but since I have been asked to help prepare a roadmap for the next 3
>> years for the evolution of cloud services and infrastructure for the
>> Italian public administrations, I need to have both a clear picture of the
>> current situation and to make an educated guess at the most promising
>> technology directions.
>>
>> My feeling is that one should promote a declarative modelling approach to
>> cloud deployment, where one specifies the architecture model he wants to
>> achieve, not how.
>> A workflow engine takes care of generating an actual deployment plan that
>> leads from the current to the desired state.
>> Google director of network architecture, Bikash Koley, explains in this
>> video why they use this approach in managing their world-wide network
>> infrastructure (aka zero-touch networking):
>> https://youtu.be/5N7QS5vP68o?t=13m01s
>> The approach is quite similar to Juju for cloud applications.
>> Openshift uses deployment on containers apparently in a similar fashion.
>>
>> One really wants to hide the details of the underlying IaaS
>> infrastructure to users making deployments.
>> Hence OpenStack could still be the platform foundation, but developers
>> and users should deal with declarative deployment models and tools.
>>
>> An automated deployment engine based a declarative modelling for a
>> container platfrom seems what one should want.
>>
>> —
>>
>> On 27 giu 2017, at 09:39, Tom Barber <tom at spicule.co.uk> wrote:
>>
>> Hey Giuseppe
>>
>> Having worked in the data sector for a while now whilst keeping an eye on
>> container tech, for now at least I'd keep deploying data services to
>> baremetal for a number of reasons, docker container discovery for one. Juju
>> hadoop on services vs hadoop on containers is a bit of a no-brainer
>> currently. That said of course data on containers support well improve but
>> for now I'd stick to the basics.
>>
>> My 2 cents.
>>
>> Tom
>>
>> On 27 Jun 2017 8:32 am, "Giuseppe Attardi" <giuseppe.attardi at garr.it>
>> wrote:
>>
>> Some Italian public administration are considering purchasing cloud
>> services for Big Data analytics deployed on Openshift.
>> How this solution would compare with using a Kubernetes cluster deployed
>> through Juju?
>> More in general, what is the strategic outlook of container platforms vs
>> virtualization platforms?
>> Are the former ones going to overcome the latter?
>>
>> --
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju
>>
>>
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/
>> mailman/listinfo/juju
>>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170627/9c530c65/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 19899 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170627/9c530c65/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 45817 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170627/9c530c65/attachment-0001.png>