Concepts and Terminology¶
The Scalr application is organised into 3 levels of login access that are known as “Scopes”. These scopes provide a hierarchy of access, functionality and object inheritance that enables a customer to match Scalr to their organisational structure, and to manage, control and monitor their deployments of cloud based infrastructure. The 3 scopes are as follows.
The following diagram shows the high level hierarchical relationships between the 3 scopes.
Within the application you will also see references to 3 lower scopes where aspects of Scalr can be configured. These are perhaps better thought of as the context within which something is defined and therefore visible. These 3 additional scopes apply to 3 items, Scripts, Orchestration Rules and Global Variables as each of these can be defined at each of these additional scopes and are inherited by, or become visible at relevant lower scopes.
- Role Scope - Items created within the context of a Role at any of the 3 main scopes. These are inherited by Farm Roles based on the Role.
- Farm Scope - Items can be created at Farm level and are inherited by all Farm Roles in the Farm.
- Farm Role Scope - The lowest level of item definition, visible only in the Farm Role where they are defined.
To be able to manage your cloud infrastructure Scalr needs to be able to connect to the APIs of the clouds that you use. Each cloud is different in the way it authenticates API access. Some require the generation of Access Keys and configuration of permissions and policies inside the cloud, whilst others simply authenticate with username and password. Whatever the method these authentication details must be stored in Scalr as Cloud Credentials.
Cloud credentials can be configured at both the Scalr and Account scopes and are then available to all lower scopes. Once they are configured Cloud Credentials are then linked to Environments so that end users can configure and manage cloud infrastructure.
See Cloud Configuration and Credentials for details on configuring cloud access and Cloud Credentials.
Accounts are the core of implementing a federated IT organisational structure in Scalr. An Account brings together the configuration resources, access permissions (ACLs) and governance policies that are applicable to to an organisational unit within an enterprise, thus ensuring consistent and suitably managed use of cloud environments. Accounts typically map to Business Units within an enterprise and are further sub-divided into Environments for the different teams and/or functional areas within the BU, such as Dev, QA, Sales etc.
There can be multiple Accounts within Scalr and these will be created by the Scalr administrator.
An Account administrator will be responsible for managing and configuring the following aspects of Scalr.
- Cloud credentials
- Governance Policies and Resource Quotas
- Users, Teams and Access Control Lists
- Account level Orchestration rules
- Cost Management
For details on configuring Accounts see Account & Environment Configuration.
Environments are the scope at which cloud infrastructure is configured and run. An Account can have multiple Environments that correspond to functional areas, different cloud providers or whatever structure makes sense for your business. Typically Environments are set up in line with application life cycles for specific applications and also possibly by geographical region. Each environment is linked to one or more sets of cloud credentials and one or more end user teams will be granted access at various levels to the Environment.
Application developers, architects etc work within Environments to configure, develop and test applications. These applications are configured in “Farms” which combine Roles, cloud services and orchestration rules together to create easily transportable application infrastructure that can be shared with other Environments, can be deployed across different clouds and set up to scale automatically based on the varying demands of each different deployment. Once a Farm has completed development and testing it can be published as a Service Catalog application for self service consumption by other Accounts and Environments.
Multiple teams can login to each Environment and the users functional capability can range from IT sophisticated DevOps users that build applications, through to minimal access Service Catalog users who simply login to launch applications (with one click) that they wish to use.
Menu for a full access Environment user:
Menu for a Service Catalog Environment user:
For details on configuring Environments see Configuring Environments.
Images and Roles¶
Images (aka, AMI, template etc) are the main building blocks for building cloud infrastructure in all clouds. Images are used to create servers in a cloud. Scalr also indirectly makes use of Images stored in the clouds, but in order to do this it requires a record within it’s own internal meta data of every image that can be used. Thus an image in Scalr is simply a unique registration of an image that exists in a cloud. Images are used indirectly through Roles and Farm Roles within Scalr. There are three broad types of image.
- Images provided by Scalr that include Scalr’s agent called Scalarizr. These Scalr images are ready made to provide the full functionality of Scalr as the agent enables control and monitoring functions. Scalr images are currently available in AWS, GCP and Azure.
- Base images provided by the cloud provider, such as AWS’s AMI’s
- Images users have created from customized servers with additional pre-installed software and configurations.
Base and user created images can easily be imported into Scalr and converted to scalarized images through the Scalr UI.
Roles provide an abstraction layer over the top of the images. Within Scalr a Role is the reusable building block for provisioning servers through Scalr. A Role can be associated with multiple similar images from multiple clouds. All similar images linked to a role will have the same base operating system and version, and the same pre-installed software and configuration. This may or may not include Scalarizr, but all images in a role must be the same in this respect. The effect of this abstraction is that any user can potentially chose which cloud to use when launching a farm/application and they will get exactly the same features and behaviour. A role can also include a set of orchestration rules and global variables which ensures consistent configuration of an server regardless of which Farm it is used in and which cloud it is deployed in.
Roles tie together:
- One or more similar (i.e. with the same OS) Images, located in different clouds or locations.
- Automation, through Orchestration Rules.
- Configuration, through Role-Scope Global Variables.
Images and Roles can be configured at all three scopes within Scalr and are inherited by the lower scopes. Roles can link to Images from the same or higher scopes. Images and Roles can only be edited at the scope where they were created, but they can be cloned at lower scopes and the can be promoted from lower scopes to higher scopes.
For details on working with Images and Roles see Images and Roles in Scalr.
Farms and Farm Roles¶
A Farm is the collection of Roles, Orchestration rules, network configuration, cloud services and much more that defines the desired deployment state of a cloud based system. A Farm can include any number of Roles that work together to provide a service, such as a basic 3-tier app that includes a load balancer, a web app layer and a database layer. The Farm can include all the required automation to bootstrap servers with the required software and auto discover the related services being provided by other roles, e.g. registering web app servers with the load balancer.
When a Role is added to a Farm this is known as a “Farm Role”. A Farm Role is analogous to a ‘tier’ in an application stack, such as the Webapp, Load Balancer or database tier. A Farm Role inherits all the attributes of the Role itself but extends the configuration to include selection of clouds, locations, network, security groups, additional orchestration rules etc. In other words it turns a role into something that can actually be deployed as a functioning server in the cloud. The Farm Role can also be parameterised through the use of Global Variables to enable end users to make choices about certain aspects of the deployment at the time it is launched
Desired State Engine¶
The underlying principle behind a Farm configuration is that it defines the desired state of a deployment. When a Farm is launched Scalr’s Desired State Engine (DSE) begins a continuous cycle of monitoring the cloud infrastructure to determine if the Farm is in the desired state or not. If any variance from the desired state is identified Scalr will take action to address this. At initial launch this will cause all the required servers to be started. During later cycles the DSE may detect the need to both stop and start servers. If a Farm is reconfigured to reduce the maximum number of servers for a role then any extra servers will be terminated. This can also happen with Auto Scaling as demand changes.
Reconfiguring a running farm can result in servers being stopped and started. Take great care when reconfiguring farms that are for business critical services.
For details on configuring Farms and Farm Roles see Farm Configuration.
Service Catalog and Applications¶
Scalr provides a cloud self service capability through the Service Catalog. Non IT users can be given Service Catalog access to Scalr to enable them to request and launch pre-configured applications and services at the click of a button. A Service Catalog entry is simply a service offering that has been created from a fully developed and tested Farm. Developers can publish their Farm at any time to enable other teams and users to request Applications from these Service Catalog entries, and thereby rapidly deploy cloud services without the complexity of making requests through Central IT. The Service Catalog based applications are controlled by the governance and security policies in the Policy Engine in the same way as the original Farms.
Service Catalog offerings can also be parameterised to allow end users some limited choices when requesting an applications, such as which cloud and locations to use, choice of instance sizes and networks etc.
Service Catalog offerings are publish at the Environment scope but can be prompted to Account and Scalr scope.
For details on publishing Service Catalog offerings see service_catalog.
Scalr includes two separate features for analysing and managing the cost of using cloud services.
Cost Analytics provides comprehensive management and reporting capabilities across all three scopes as follows.
- Scalr scope
- Definition of Cost Centers and Projects for aligning expenditure to organisational budgets.
- Custom Price Lists for internal clouds and to override default price lists from public clouds.
- Conditional price Markups to allow the addition of cost overheads to per instance.
- Definition of Budgets and associated notifications to enable close control of expenditure.
- Comprehensive reporting across all Accounts and Environments.
- Account Scope includes a subset of the features available at Scalr scope and provides cost visibility only for the individual Account and it’s Environments.
- Projects can be defined
- Budgets for Account level projects
- Account and Environment level reporting
- Environment Scope only has reporting capability limited to the individual Environment and it’s Farms.
Cost Manager is a new feature that is currently under development and released in preview mode only. Cost Manager’s role will be to take cost management to the next level by providing guidance on right sizing and ultimately provide the ability to automate right sizing and cost saving actions.
For more details on the cost control features of Scalr see Cost Analytics.
The Policy Engine is the Core of Scalr’s ability to ensure consistent and repeatable implementation of governance, compliance and security policies across all Accounts and Environments. The Scalr Policy Engine sits between users and the clouds, validating their actions but at the same time allowing users to continue to take advantage of the speed and flexibility enabled by Cloud services, without increasing risk for your organization. Scalr lets you enforce policies for an entire Environment, such as restricting instance types, restricting networks or mandating security requirements. Each policy is defined by its type, which describes the goal of the policy, optional conditions that limit the scope this policy will apply to, and for some policy types that need it, additional configuration settings.
When you provision a new Policy Group in an Environment, all user interaction with Scalr will be validated by the Policy Engine. We also validate all actions from Scalr to clouds with the policy engine as well. New Policies do not automatically apply to running farms. They will only be fully taken into account for Farms launched after the enforcement of the policy. For previously running Farms, Scalr will not terminate existing instances that violate newly enforced Policies, but will not allow for violation of the policy in the future.
Example: If a policy disables t1.micro instance type in an environment but a Farm has a Farm Role configured to use this type, existing servers will not be terminated but no new instances will be launched until configuration is updated to an allowed instance type. If there is autoscaling configured, Scalr will throw an error stating that the instance type is not allowed.
For details on configuring the Policy Engine see Policy Engine.
Users, Teams and Access Control¶
Users, Teams and Access Control Lists (ACLs) are the authorization and functional control components of Scalr.
Access Control Lists define the functional aspects of Scalr that are available to individual Teams. ACLs can range from granting full access to everything, through total Read Only access and on to very limited functionality, such as for a Service Catalog user.
Teams group users together to provide them with access to environments and to apply a common ACL to all team members. Users can belong to multiple teams.
Users are individuals who login to Scalr. Users can be designated as Administrators which will give them access to the Scalr scope. Users can either be authenticated within Scalr or Scalr can be configured to authenticate against an external system via LDAP or SAML. A user is a unique entity in Scalr and can be given access to multiple Accounts and multiple Environments via team membership.
For details on configuring Users, Teams and ACL’s see Users and Teams.
Global Variables are a key value store built in to Scalr and are stored encrypted in the main Scalr database. They are used to pass configuration data from the Scalr User Interface down to your Servers. Global Variables can be defined at all scopes of Scalr. They can be defined as simple single values, validation lists or JSON objects.
Within the Scalr UI certain fields support Global Variable Interpolation. These fields can be set with the name of a Global Variable rather than an actual value. The actual value used is then determined from Global Variable at the time of execution, e.g. when launching a farm. Fields that support Global Variable Interpolation are marked with .
For details on configuring Global Variables see Global Variables.
Orchestration is the process of provisioning, configuring and managing servers in the cloud. In it’s simplest form orchestration is just the act of provisioning and starting a server from a given Image and later terminating that server. However Scalr provides a sophisticated Orchestration engine that defines rules for event based script execution, or scheduled execution of scripts on running servers. Through this engine the entire life cycle of a server can be customised by performing actions such as installing software on startup, performing service auto discovery and adjusting configs, scaling, external integrations and much more. There are more than 10 built in events that can trigger orchestration rules and all scopes can also define custom events that can be triggered via scripts, API calls and through the UI.
Orchestration rules can be defined in Roles so that they apply to all related Farm Roles in any Farm. Additional Orchestration rules can also be defined on Farms and Farm Roles where they they have the added capability to execute scripts in servers for other Farm Roles within the Farm.
Scripts in Scalr are used in conjunction with Orchestration and can also be executed on a on-off basis if required. Scripts can perform ANY action that is valid within the context that they are run and can be written in any scripting language including shell, python, perl and Power Shell (for Windows). They are written exactly as you would normally write scripts, and they have access to all the Global Variables that exist within the context of the Farm Role that the target server is running in. Scripts can be defined at all scopes within Scalr.
For details on working with Scripts see Scripts.
Webhooks, Endpoints and External Integrations¶
Scalr supports integration with external systems through the definition of Webhooks and Endpoints. Endpoints identify external systems that support inbound Webhook payloads. Typically these are systems such as IPAM systems to allocate and mange IP addresses, Config Management systems to register infrastructure and allocate hostnames, or Service Management systems to provide approval mechanisms.
Endpoints and associated with Webhooks in Scalr. The Webhook defines the the Farms and Events for which the Webhook will be triggered and the user data that is passed to the external system. Webhooks defined at the Scalr or Account scopes will apply to all Farms in the lower scopes.