Juju Reloaded
Last week a new release of juju saw the light and I think its time to do a small writeup of what I like about it.
I started working at Canonical almost three years go, on the juju team. What drove me to the job was not the company, even though it has a long standing track record of FLOSS related work.
Two aspects originally attracted me from juju:
- Its a big project in Go and I really wanted to get more into it.
- It proposes a new way to think at devops and the concept of big software.
A bit of backstory.
Now, I have been a sysadmin full or part time for a big chunk of my career. I end up changing areas of interest mainly because I realized something about sysadmining, each new thing you need to learn spreads you thinner. Its not like you know Apache and then Nginx becomes the thing and you swap one for another, you need to keep a certain level of expertise in both. For some time I found it to be manageable, I could master a certain amount of apps and settle for a reasonable level of knowledge for the rest. Time passed and I realized that the stack kept growing and I needed to specialize in some of the niches of the now growing DevOps which was not really practical if you live where I do, our access to tech is not excelent and whatever you do, if you want to be in the best possible position to achieve your potential must be remote. At the time, remote sysadmining was not much of a thing, racks needed wiring and banging and yelling in person.
And then, after a few years as a dev, The Cloud (a.k.a other people’s computers) enters the scene.
A bright new path for people with The profesion formerly known as sysadmin inclinations was open. A mirryad of orchestration tools where booming and one could dump the administrative knowledge into endless deployment snipets. Well that was not enough for me.
The same issue arose, I could write snipets about the software I mastered and cargocult snipets about the software I did not I was basically collage master of sorts.
Finally “what I like about you”
And then, I glanced at juju’s promise, which was exactly what I wanted.
- Declarative Vs Imperative: juju proposes to declare your model, a model that best represents your sofware needs instead of rigid step list.
- Packaging knowledge with clear edges: A charm, the smaller unit of logic in juju, is literally a bag of distilled knowledge, your charm installs all that you require with the best possible setting (you can find various charms for a same application tuned for different uses) and it will know how to scale in the best way for that application and finally will export the relevant endpoints to connect with it.
- Clear definition of interactions: given the proper edges exposed by the charms, your model can limit itself to express relations between them only for the relevant parts (for instance you want wordpress to only relate for the http part with nginx and both charms know it and will do that kind of relation for you).
- Scaling of knowledge: this is perhaps the more important part, as software grows in complexity (see the big sofware mention above) you either need to spread yourself thinner and know too little about too much or find a way to leverage other people’s knowledge in a comoditized way that allows you to aquire as much as possible without lowering quality, given that a charm basically is knowledge and juju itslef has deep knowledge about the underlying cloud providers you are getting the best possible knowledge about each part of your software and can focus on whatever your part is and what drives value for your product.
In conclusion, software is becoming big, that is a fact, there is no way back given the scale of users and networks. Juju has the potential of being one of the big players here with the ability to package know how, scale knowledge and deploy your one model representation in many environments with equivalent outcome. The one common language that juju proposes is a fine representation which I expect will gain momentum among big software players and I hope to be there to add my fair share.