Hi Simon, Answers inline.
Best Regards, Dmitrii Shcherbakov Field Software Engineer IRC (freenode): Dmitrii-Sh On Mon, Jul 17, 2017 at 4:44 AM, Simon Lafrenière < [email protected]> wrote: > Hey, > > This seems like a good initiative. I want to know more. > Good stuff. > > If someone could explain to me for what reason I could get paid using juju > charms that would help me understand what I could do with this for clients. > The idea might be that you would sell Juju models: could be an entire architecture comprised of multiple related applications on multiple machines instead of just having images with templates. It used to be the same with software on a single machine: at first we had flat assembly language code, then high-level languages, static libraries, loadable dynamic libraries (which could be used by multiple processes on the same host). But now we need to model connections and data exchange on different hosts - cannot just ship a single package with libraries anymore for it to be enough. --- JAAS is getting there in a certain way for providing hosted Juju controllers for you to be able to use models on different public clouds without having your own infrastructure. https://jujucharms.com/jaas In terms of providing models and services related to them, I think Spicule is a good example to look at. http://spicule.co.uk/2017/07/07/data-processing-with-spicule-data-engine/ https://youtu.be/WNs5vA3Pljg?t=1251 https://www.youtube.com/watch?v=akpiHie0QEs https://lists.ubuntu.com/archives/juju/2017-April/008887.html You could also do charm maintenance services: e.g. if a customer wants to have a certain functionality in charms and wants continuous support with new versions released, tests etc. you could easily qualify this as an engineering effort which should be paid for. --- In essence, Juju itself is a client-server type of software to remotely execute arbitrary code based upon certain events and send data across different agents on used machines. https://github.com/juju/juju/blob/develop/doc/architectural-overview.md# juju-components The other part is charms which is that arbitrary code that gets executed and acquires certain context from Juju about a particular event that triggered the execution. This is what is called the 'operational' code that does everything you would do manually in an alternative situation. The difference between one-shot deployment tools is that charms are executed based on different lifecycle events and are applications in a certain sense: they can get quite complex in handling config changes, relation events, upgrade events, periodic update status events, storage events and leadership events. https://jujucharms.com/docs/2.2/developer-event-cycle#hook-event-cycle This is where, as a developer or a company you can bring in your expertise in providing the right application-specific operational code to manage applications or models that customers need. Juju will not do that for you on its own - it is a system that allows you to do it via the primitives it provides but all of the application-specific work is coded in a charm. >From a charm developer's point of view you see this: Juju agent -> executes a file with an event name (can be anything really in terms of a programming language) -> control gets to your own code. What is used a lot now: classic charms: Juju agent -> *hooks.py file -> a decorated function gets executed + charm-helpers library + your own library code calls reactive charms: Juju agent -> charms.reactive main function -> hooks and reactive handlers + charm-helpers library + your own library code calls I am oversimplifying because there are other features out there but this is the most basic thing to realize. If you need an analogy, Juju would be similar to a complex responsive GUI application: - you have a main loop that decides which operation to do next (e.g. a user clicked a button, or pressed something on a keyboard so you need to handle that) - events have custom handlers that act upon them in a custom way You could also compare Juju to an MVC type of application but more distributed as there are many machines involved. For a single unit, it could be something like that: Model - a context you get from Juju and relation data; View - a set of actions to perform on a target machine or configs to render; Controller - a charm code that operates on the model's data to present a view. > > I usually develop sites based on container images but I want to know for > what else I could use this for. > Are there lists of use cases and problems solved ? > If you have a single image with a template, you cannot model relations between services easily. You just have a one-shot template rendering code which prepares your container image but oftentimes this is not enough. A simple example would be a desire to scale a model like this: load-balancer -> web servers -> database backend You could also add something like a charm that automatically gets a TLS certificate from Let's Encrypt. Things get more complicated if you want to deploy something like OpenStack or Kubernetes. This is a simple model of OpenStack (non-HA): https://jujucharms.com/openstack-base/ k8s: https://jujucharms.com/canonical-kubernetes/ https://jujucharms.com/big-data https://jujucharms.com/u/prometheus-charmers/prometheus/ > > Can I power devices and do iot type of projects ? > I can't see why not. Juju is written in golang and is easy to run on any operating system. Like I said before, Juju unit agents do remote code execution and connect to a controller via TCP so no hard requirements in terms of running code on IoT devices. The question is how small is the target IoT device and how to provision those devices because Juju allocates machines via a cloud API and with bare-metal servers we do it with MAAS which in turn provisions via PXE boot over a network. For IoT devices the provisioning scenario needs to be figured out if you want to deploy charms onto IoT devices via Juju. Although, if you only care about providing infrastructure for your IoT devices and not using them as a management target for Juju you do not care as much - just deploy your infra and point your devices at it. > > Is it about serving programs to user and teams of programmers ? > Not 'serving' in terms of just deployment - more like modeling and operating which includes deployment. > > can I connect maker type electronic projects and charms so that my arduino > or raspberry py get to execute code and produce outcomes ? > If you put a Juju agent there - yes. > > Who could I work with to experiment doing fun stuff with juju charms ? > https://jujucharms.com/community IRC channels at freenode.net #juju #juju-gui #juju-dev > > Is there a list of videos of people showcasing their realizations with > juju charms ? > You can have a look here: https://www.youtube.com/channel/UCSsoSZBAZ3Ivlbt_fxyjIkw > > Thank you for reading and good day ! > > > > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/juju >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
