Cloud (substrate)
See also: How to manage a cloud
To Juju, a cloud (or backing cloud) is a resource that provides machines (instances), and possibly storage, in order for application units to be deployed upon them. This includes public clouds such as Amazon Web Services, Google Compute Engine, Microsoft Azure and Kubernetes as well as private OpenStack-based clouds. Juju can also make use of environments which are not clouds per se, but which Juju can nonetheless treat as a cloud. MAAS and LXD fit into this last category. Because of this, in Juju a cloud is sometimes also called, more generally, a substrate.
Contents:
Supported clouds
Cloud differences
While Juju aims to make all clouds feel the same, some differences still persist depending on whether the cloud is a machine cloud or a Kubernetes cloud or a specific cloud as opposed to another.
Machine clouds vs. Kubernetes clouds
Juju makes a fundamental distinction between ‘machine’ clouds – that is, clouds based on bare metal machines (BMs; e.g., MAAS), virtual machines (VMs; e.g., AWS EC2), or system containers (e.g., LXD) – and ‘Kubernetes’ clouds – that is, based on containers (e.g., AWS EKS).
See more: Machine
While the user experience is still mostly the same – bootstrap a Juju controller into the cloud, add a model, deploy charms, scale, upgrade, etc. – this difference affects the required system requirements (e.g., for a Juju controller, 4GB vs. 6GB memory), the way you connect the cloud to Juju (add-cloud + add-credentials vs. add-k8s), what charms you can deploy (‘machine’ charms vs. ‘Kubernetes’ charms), and – occasionally – what operations you may perform and/or how (e.g., enable-ha is currently supported just for machine controllers; scaling an application is done via add-unit on machines and via scale-application on K8s).
See more: Tutorial, Juju How-to guides
Juju’s vision is to eventually make this distinction irrelevant.
Cloud foo vs. cloud bar
As a Juju user you will sometimes also notice small differences tied to a cloud’s specific identity, beyond the machine-Kubernetes divide.
This usually affects the setup phase (the information you have to supply to Juju to connect Juju to your cloud, and whether Juju can retrieve any of that automatically for you) and, later on, the customisations you can make to your deployment (e.g., small differences in configurations, constraints, placement directives, subnets, spaces, storage, etc., depending on the features available / supported for a given cloud).
See more: List of supported clouds >
<cloud name>
Last updated a month ago.