How to improve your multicloud, self-service workflows with Mist

Christos Psaltis profile pic

Woman using self-service machine

One of the best ways to increase your team's velocity is to provide self-service workflows for any infrastructure required during development, QA, and testing. Everyone should be able to come in, get the resources they need, and proceed with the work at hand in just a few seconds. The simpler the process, the bigger the productivity gain.

Unfortunately, this is easier said than done. In many cases, providing a streamlined experience for developers puts a lot of burden on the shoulders of DevOps and Platform teams. Especially in organizations with multicloud setups, the situation can quickly get out of hand.

Who has control over which resources? How do we avoid breaking the bank when people spin up instances all over the place and then forget them running? How do we simplify the provisioning process so developers don't have to deal with an endless amount of configuration options and ops don't have to deal with supporting them?

In this post, I will go over how Mist can help you address such issues in a quick and easy way. In summary, it all comes down to Mist role-based access controls (RBAC) and constraints. You can think of Mist's RBAC as a cross-cloud IAM service. Each team can have its own set of rules that apply across your entire inventory with just a few clicks.

On top of RBAC, you can then set up advanced policies by combining four types of constraints:

  • Cost constraints allow you to impose cost quotas. They help you stay οn budget and avoid unpleasant surprises in your cloud bills.
  • Expiration constraints allow you to enforce machine leases and take action automatically, shutting down and/or destroying machines, after the lease period has lapsed. Expiration constraints help you reduce machine sprawl and avoid long forgotten VMs running in vain for months.
  • Size constraints give you control over the amount of resources a new or resized machine can have. Size constraints help you avoid a fleet of unnecessary XL instances in AWS or a KVM host with all its resources dedicated to a single VM.
  • Field constraints let you hide and/or suggest reasonable defaults for all provisioning options. Field constraints help you simplify the machine provisioning process for your end users.

Please keep in mind that Mist RBAC and constraints are available only in Mist Hosted Service (HS) and Mist Enterprise Edition (EE).

The easiest way to get started is to sign up for a 14-day free trial of Mist HS. Alternatively, you can book a call for a 30 minute demo.

Multicloud RBAC

Mist's RBAC enables the management of user permissions across infrastructure; public and private clouds, containers, hypervisors, and bare metal servers. Each organization can have any number of teams, each with different access policies.

RBAC policy example
RBAC policy example

For example, let's assume that you are running infrastructure on AWS Frankfurt region and DigitalOcean. You can enforce the following policy for your Dev team:

  • Read-only access to AWS Frankfurt.
  • Full access to DigitalOcean.
  • Full access to all machines tagged as "dev" on AWS Frankfurt AND DigitalOcean.
  • When a member of the team creates a new machine, it will be automatically tagged with the "dev" tag.

For more details you can check out RBAC's documentation.

Cost constraints

Cost constraints, or cost quotas, help you stay within budget and avoid unpleasant surprises in your cloud bills.

Mist supports cost quotas per team and organization. Quotas are checked when users attempt to create, start or resize machines. Mist will compare the current run rate with the relevant quota. The requested action will be allowed only if the run rate is below the quota.

Cost constraints example
Cost constraints example

For example, with cost constraints you can implement the following policy:

  • The Dev team must spend less than $500 per month on machines.
  • The total run rate of all machines in the organization must be less than $2,000 per month.

For more details you can check out our docs on cost constraints.

Expiration constraints

Expiration constraints, or machine leases, help you reduce machine sprawl and avoid long forgotten VMs running in vain for months.

Mist can automatically turn off or destroy machines when their expiration period lapses. Before this action happens, it can also notify relevant team members over email so they have the chance to take action.

Expiration constraints example
Expiration constraints example

For example, with expiration constraints you can implement the following policy:

  • Machines created by members of the Dev team must be set to expire in less than 30 days.
  • By default, machines will expire in 7 days.
  • When a machine expires, Mist will automatically destroy or stop it.
  • The default action will be to automatically destroy the machine.
  • The owner of the machine will receive an email notification 1 day before the machine expires.

For more details you can check out our docs on expiration constraints.

Size constraints

Size constraints help you control the amount of resources a new or resized machine can have. This way, you won't end up with a fleet of unnecessary XL instances in AWS or a KVM host with all its resources dedicated to a single VM.

Some clouds allow you to choose the size of your machine from a list of predefined sizes. Others, allow you to completely customize the amount of CPU cores, RAM and disk a machine has. Mist's size constraints can be applied on both types of clouds.

Size constraints example
Size constraints example

For example, let's assume that your RBAC policy allows members of your Dev team to create machines only in AWS Oregon and Linode. You can apply the following size constraints:

  • In AWS Oregon, team members will be able to use only t3-small and t3-medium sizes.
  • In Linode, team members will be able to use any size except the very big Dedicated 512GB.

For more details you can check out our docs on size constraints.

Field constraints

With constraints on fields you can hide and/or suggest reasonable defaults for all provisioning options. This helps you simplify the machine provisioning process for your end users.

Below is Mist's default create machine web form for DigitalOcean. As you will notice, you need to provide several details. Some are optional and some are required. The required fields are noted with an asterisk (*).

Default machine create form
Default machine creation form

With field constraints you can e.g.:

  • Hide all optional fields to simplify provisioning.
  • Allow only the use of an Ubuntu 21.04 x86 image.
  • Hide the image field since there will be no other options available.
Machine create form after applying filed constraints
Simplified machine creation form after applying field constraints

For more details you can check out our field constraints docs.

Conclusion

Self-service workflows in multicloud setups should not be a pain. In this post, I went over how Mist can help you implement a number of complicated scenarios in a quick and efficient way.

We will be happy to assist with setting up your own policies and answer any questions you might have. Reach out to support@mist.io or book a call via calendly.