Juju is an open-source framework that helps you move from configuration management to application management across your hybrid cloud estate through sharable, reusable, tiny applications called charms.
A charm is an operator. In the Kubernetes tradition, an Operator is an application packaged with all the operational knowledge required to (1) install and (2) maintain and upgrade it on a Kubernetes cluster. A charm is an application packaged with all the operational knowledge required to (1) install, (2) maintain and upgrade, and (3) integrate it with other applications, (4) on a Kubernetes cluster, container, virtual machine, or bare metal machine, running on public or private cloud.
Juju has the following components:
Juju consists of the command line tool Juju ('juju').
Visit the Juju docs to start managing charms!
Need to deploy Kubernetes? Grab the Charmed Kubernetes charm bundle! Need to deploy Wordpress on Kubernetes or on containers or virtual machines? Grab the Wordpress K8s or the Wordpress charm.
Visit Charmhub to try a ready-made charm or to find an easy place to start contributing!
The SDK consists of the ops library and Charmcraft.
ops library is a Python framework for developing charms.Visit the SDK docs to start building charms ('charming')!
Enterprise software operations in the cloud are costly and messy. One reason is because they are stuck in configuration management.
Since its inception in 2009, Juju's mission has been to offer a cheaper and cleaner solution. This solution is what we call model-driven application management.
Together, the open source community has the power to dramatically reduce costs and improve the working lives of DevSecOps, SREs, operations teams, and the teams who rely on them. But how exactly does this happen? Keep reading to learn more!
Focus on the four important business decisions and build an application to handle the execution
Juju brings business thinking to the world of application management, making it much easier to have conversations between teams about the estate, and much easier to evolve capacity allocation over time: you can easily manage multiple compute environments and lower your costs of ownership. The separation of technical and commercial concerns means the operator is reusable in very different business settings. And reuse enhances the community value of the operator and increases software quality.
Most importantly, Juju is not a ‘language for configuration file management’. It is not a successor to Puppet, Chef, Ansible, Terraform or Salt. Juju removes the requirement to invest in deep institutional knowledge of configuration details altogether, by encapsulating community knowledge in operators that handle those details automatically given a context. Moving beyond configuration management puts the focus on application management and resource allocation. It is the stepping stone to Model Driven Operations.
If each application ran completely independently, then we could share configuration management code as we know it today. The problem is that applications in the enterprise always need to be integrated with other applications. A particular business makes unique choices of combinations of applications to integrate for particular situations. Configuration management tools force us to blend all of those choices into a single tower of babel that reflects the unique landscape inside that enterprise.
Whether it is Chef, Puppet, Salt, Ansible, or Terraform – that enterprise configuration management code cannot simply be taken to another enterprise, because it mixes up knowledge of the applications with knowledge of the particular business and situations those applications are being used. Charms and Juju solve this.
Reusable packages of operations code get wider scrutiny which helps identify security issues faster. Reuse of operations code in different scenarios attracts a wider range of contributors and with that, a wider range of skills. Security is a many-layered challenge, and the breadth of participation in operator development raises the bar for all users of those operators.
Since all deployment and configuration of the application is handled by the operator, manual mistakes are fewer and easier to discover. Policy can be enforced consistently, regardless of the cloud or infrastructure being used.
Testing, continuous integration, inspection, debugging, observability and traceability are all critical capabilities in distributed systems design and development. Mechanisms for testing are essential for high quality code. The ops library enables unit testing at the code level. We also respect conventions for real-world functional and acceptance tests.
As a community, continuous integration and testing of operators across a range of substrates and scenarios ensures a high standard of quality in the portfolio. We drive automated tests of operators across the entire ecosystem as a shared project, to raise the quality of operators for all users.
We are focused on the needs of software operations experts and practitioners, with appropriate governance and mechanisms to bring the world's expertise to bear on the shared problem of application management.
Share operations and integration code
Instead of each business writing and maintaining their own scripts to manage their infrastructure, why not share operations and integrations code, through a system that works across substrates, across platforms, across operating systems and through the applications built upon them. Imagine a world where you don’t need to tweak every script, chart, or file to get your scenario to deploy, scale, or upgrade properly – because those operations are handled for you in code, created by yourself and the community around you.
What would this allow you to do? Could you focus on the logic – on the business decisions – that give meaning to those operations? Together, we can combine the knowledge of an open source expert community into shared, open source applications, which are coded to react to different scenarios, situations, and operations as you’d like them to.