Skip to content

Background

What makes it cloud

Cloud is a way of getting infrastructure, not a place. You ask for compute, storage and networks through software, have them in minutes, and hand them back when you're done.

Four traits

If you've run VMware, Hyper-V or a similar platform, much of the technology will look familiar. An instance is a virtual machine. A volume is a virtual disk. What changes is how you get them, how you change them and how long you keep them.

Trait On a traditional virtualization platform On a cloud
Self-service You raise a request and an infrastructure team builds the virtual machine You create the instance yourself, within your project's quota
Elastic Capacity is planned and bought ahead, sized for the busiest day You add capacity when demand rises and remove it when demand falls
API-driven Most work happens in a console; automation is added on later Every resource is created through an API; the console is one client of it
Disposable Virtual machines live for years and are repaired in place Resources are created and deleted freely, and rebuilt rather than repaired

Self-service

There is no ticket queue between you and a new instance. If your role allows it and your project has quota left, you create what you need. The guard rails move from a request process to the platform itself: roles decide who can create resources, and quotas cap how much a project can use.

Elastic

Capacity follows demand. Instead of sizing a virtual machine for its busiest day and leaving it there, you run what today needs. When demand grows you add instances or move to a larger flavour, and when it drops you take them away. Billing follows the same curve, because you're billed for what exists, by the hour.

API-driven

Everything in a cloud is an API call. On Breqwatr Cloud, the Breqwatr Cloud Portal (Strata) makes those calls for you when you click a button. A command-line tool makes the same calls from a terminal. An infrastructure as code tool makes them from a file that describes what should exist. Because the API is the real interface, anything you can do once you can also script, repeat and review. GUI, API and infrastructure as code covers this in more depth.

Disposable

When creating a resource takes a minute, keeping one around "in case" stops making sense. Test environments can be built for an afternoon and deleted. A broken instance can be replaced instead of repaired. This only works when the instance itself holds nothing you can't recreate, which is the idea behind pets vs cattle.

On Breqwatr Cloud

  • Self-service: your organisation holds one or more projects. Anyone with access to a project creates instances, volumes, networks and load balancers in it, up to the project's quota. Each project has its own quota in each region. When a project needs more, you request an increase from the portal.
  • Elastic: you can add instances behind an Octavia load balancer, resize an instance to a different flavour, or add worker nodes to a BKS cluster. Usage is measured by the hour, so removing capacity reduces the next invoice.
  • API-driven: Breqwatr Cloud is built on OpenStack. The portal, the OpenStack CLI, OpenTofu and Ansible all work through the same OpenStack APIs, so an instance created with one shows up in the others. Account features such as organisations, team members and billing live in the portal.
  • Disposable: deleting an instance stops its usage. By default, an instance's root volume is deleted with it. Data you want to keep lives on separate volumes or in object storage, which outlive any one instance.

Impact

  • The time from deciding you need infrastructure to having it drops from days to minutes.
  • Spend follows use. An environment nobody is using can be deleted and built again when it's needed.
  • Changes become repeatable, because the same API call gives the same result each time.
  • The people building a workload decide how it's built. With no request queue, more of the responsibility sits with them. Shared responsibility sets out where the line falls.

Common anti-patterns

  • Lift and leave: moving virtual machines across unchanged and running them exactly as before. The workload runs, but none of the four traits are put to use.
  • Sized for the peak, forever: choosing a large flavour for the busiest day and never revisiting it. Elastic capacity only helps if something changes it.
  • Built by hand, once: building an environment entirely through the portal, with no record of the steps. It works until it has to be built a second time.
  • Kept just in case: leaving unused instances, volumes and floating IPs in place. Each one is still billed.

Further reading