Juju and cluster managers (like mesos)

Mon Nov 30 15:13:56 UTC 2015

Adding Artyom from DataArt who has a lot of very clever ideas about this
and recently created a cool autoscaling demo.

I'm interested in any follow up given to your work. I share your
frustration at containers systems using a so called "orchestration" when
the orchestration is really some basic hooks.
The consequence of these systems is a total absence of portability between
techs (moving from k8s to Swarm or worse Mesos requires a lot of rewriting
the core and even sometimes rebuild some of the containers to adapt to the
service discovery APIs). Something that Juju wants to address really well.

My path so far is to create specific injection charms for k8s and others
(Swarm so far). By talking only to the current leader, you kind of create
this abstraction you are talking about.
That means you can then expose configuration to scale out & in the service
by calling the Juju API to reconfigure the service itself.
Not a complete solution, but a starting point. The issue with it is that to
comply with Juju models, I have to create an injection charm per app, which
is additional work on top of containerizing for example.
The LXD provider will certainly help in that space, even more when/if LXD
become first class citizen in "Container Orchestration Tools".

As for monitoring, some charms expose monitoring hooks that can be consumed
by other specialized services. As a consequence you can easily integrate
not only with service spawned by Juju, but also external systems. However,
monitoring is an expression of the operation and not the model, therefore
"can not" be operated by Juju.

Scaling should not depend on Juju either in our current vision. It's not an
expression of a model, but rather of how to operate the model. Therefore,
this task should stay outside of Juju, even if it can be operated via
Juju's APIs (scale out / in, potentially rolling upgrades in the future).

++
Sam

--
Samuel Cozannet
Cloud, Big Data and IoT Strategy Team
Business Development - Cloud and ISV Ecosystem
Changing the Future of Cloud
Ubuntu <http://ubuntu.com>  / Canonical UK LTD <http://canonical.com> / Juju
<https://jujucharms.com>
samuel.cozannet at canonical.com
mob: +33 616 702 389
skype: samnco
Twitter: @SaMnCo_23
[image: View Samuel Cozannet's profile on LinkedIn]
<https://es.linkedin.com/in/scozannet>

On Mon, Nov 30, 2015 at 2:47 PM, Merlijn Sebrechts <
merlijn.sebrechts at gmail.com> wrote:

> Hi all
>
>
> I'd like to start a discussion about how Juju can fit into cluster
> managers like Apache Mesos and Kubernetes.
>
> Currently, Juju fits nicely into this story as a way to setup these
> cluster managers. Payloads continue on that idea with Juju as a manager of
> a cluster manager. However, I'm a lot more interested in Juju on top of a
> cluster manager, where the cluster manager would be a provider Juju uses to
> deploy services on.
>
> Juju provides an awesome way to model complex services in a modular and
> re-usable way. The relationships allow for much more complex interactions
> between services than what the "service discovery" in Kubernetes and Mesos
> allows. Service discovery allows for a service to say "I need the IP's of
> these services" but that's pretty much it. No flexible adaptable
> infrastructure where services change their behavior depending on what they
> are connected to. It basically stems from the same mindset that brought us
> tools like Chef and Puppet: One company with a big dev team that creates
> services for internal use only.
>
>
>    - Cluster managers are very good at scheduling "dumb" workloads.
>    They're a datacenter kernel, they don't care what runs in the container. At
>    best, they provide a way for two containers to communicate (service
>    discovery).
>
>
>    - Juju is very good at configuring applications. It changes services
>    depending on how they are connected. Juju for the most part doesn't care
>    where services run, only how they are connected.
>
>
> Combine these two and you could get an awesome PaaS that can run a lot
> more than "dumb" 12-factor apps. It bothers me to see frameworks like
> Kubernetes use the terminology "service orchestration" when all they do is
> connect static services. Juju is on to something with its dynamic
> relations, but it seems not many people have caught on...
>
> I see two possible paths to integrate Service Orchestration with Cluster
> management (scheduling):
>
>
>    - *Support cluster managers in Juju as providers.* This might be hard
>    to do since Juju's units require an OS-level container, not a process
>    container. Step 1 would be LXD support in Mesos/Kubernetes?
>
>
>    - *Write cluster management extensions on top of Juju.* Basically
>    recreate the scheduling, failover and scaling functionality of
>    Kubernetes/Mesos in Juju. There seem to be some people in the Juju
>    ecosystem who are working on their own version of this. I've seen some
>    people who are trying to automate the up/down scaling of services. Maybe it
>    might be good to bundle these efforts and make a generic framework for
>    this?
>
> Juju can encapsulate installation and configuration best-practices.
> Wouldn't it be great if Juju could encapsulate monitoring, scaling and
> scheduling best-practices too? Maybe by making bundles smarter? (Just
> imagine: a Hadoop bundle with builtin monitoring and scaling that scales
> the workers up/down depending on the need)
>
> *Now I'm curious to see what you guys think about this. *Do you think
> there is a need to integrate Juju with "datacenter kernels"? What is
> Canonical's vision about this? What does the community think?
>
>
>
> Kind regards
> Merlijn Sebrechts
>
>
>
>
>
> --
> 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/20151130/b317615e/attachment.html>