Skip to content
This repository has been archived by the owner on Apr 24, 2023. It is now read-only.

Main Concepts

Daniel Murrmann edited this page Jun 15, 2021 · 4 revisions

To realize the capabilities the implementation of Cloud Yourself builds up on the following main concepts:

Multi Tenancy

The System is able to manage multiple tenants. Each tenant contians a number of cloud accounts and configuration data for the Cloud Provider. The data of each tenant is completely separated from the data of each other tenant.

Cloud Provider Independence

Cloud Yourself is desigend to be independed of a specific cloud provider and can be extended to other cloud providers in the future. Currently the focus of the implementation is on Microsoft Azure.

Cloud Account

The system defines the term of a Cloud Account as a repository containing native billing entities of the various cloud providers (e.g. an Subscription in case of Microsoft Azure). While creating a new Cloud Account it has to run through an approval process. During this approval process the later owner of the Cloud Account gets the approval from specific responsible employees or departments (e.g. Controlling for spending the money for the consumed resources) to host workloads within this cloud account. After the Cloud Account is approved the owner and other authorized employees can create an arbitrary number of native billing entities (e.g. Azure Subscriptions) even from different cloud providers in its account. This way you can divide workloads on different billing entities even from different cloud providers but on enterprise side you have all that in one Cloud Account.

Managed Resources

The system provides the concept of Managed Resources. Managed Resources are preconfigured templates for cloud resources or a collection of cloud resources which a user can easily deploy and that can be easily be integreated into the enterprise infrastructure. Typicaly such managed resources should also already be approved by the enterprise data protection, cybersecurity and/or compliance departments. By approving the templates for Managed Resources in advance the company can save work time for their emplyees because no spaparate approval process is necessary for such resources after deployment. Cloud Yourself takes care about such Managed Resources, makes sure those resources are repeatable deployed with the very same settings as in the template and prevents wrong configuration by the employees by applying proper access rights.

Examples of managed resources:

1. Storage for strictly confidential data

  • An enterprise has special requirements to a cloud storage account so that it may contain strictly confidential data (e.g. Encryption, Key Length, etc.).

2. Virtual Machine

  • An enterprise has special requiremnts for a virtual machine to be able to integrate it into their active directory.

3. Network

  • An enterprise has special requirements for a virtual network (or a VPC in case of AWS) to be able to link it to the enterprise WAN. (e.g. no bridge to a public IP can be buid).

With Manged Resources you can set those settings in a native cloud provider template (e.g. ARM template in case of Azure) let them deploy through Cloud Yourself in a repeatalbe and deterministic way. If supported by the cloud provider, Cloud Yourself can not only deploy resources but also constraints or policies. For instance, if you want to prevent public IP addresses in accounts wich contain a network connection to your WAN, Cloud Yourself is able to deploy not only the template but also a set of correspondig constraints (e.g. Policies in case of Azure).

As open as Possible

To provide the full feature set and power of a cloud provider to the users Cloud Yourself does not restrict any features of a cloud provider by default. If you create a Cloud Account with a billing entity inside (e.g. a Subscription in case of Azure), the subscription is as close to the default settings of the cloud provider as possible or as specified by the enterprise. If you later deploy a Managed Resource to your account (e.g. a company connected virtual network(Azure) or VPC(AWS)) and the enterprise has configured some restrictions for such a managed resource (e.g. public IP addresses are forbidden in case my account contains a company connected virtual network (Azure) or VPC (AWS)) only then your account starts to get some company defined restrictions.

Clone this wiki locally