Cloud Management Options

In this material we address different cloud management options. The material is meant to help learners who are new to Public Cloud concepts to have an understanding about the different cloud management options that exist and what might be a proper use of each management option. This material aims to be general and not focusing overly much on any specific Public Cloud technology.

Public Cloud is all about self-service and on-demand delivery of services over the Internet. How are cloud resources created, managed and eventually destroyed then? Public Cloud vendors such as AWS, Azure, Google and OCI each provide a vendor specific Cloud Platform that is used to deliver cloud services that are managed by the customer. Cloud Platforms are not exclusive to Public Cloud vendors though. Organizations can setup and run their own Cloud Platforms as well for Private Cloud setup for example by using technologies like OpenStack.

Features of a Cloud Platform can be studied by exploring Logical Architecture of the OpenStack technology, which is an exemplar of a basic Cloud Platform. Features of the OpenStack that are of interest to us in scope of this material can be identified from Logical Architecture are the following ones:

Identity and Security - Identities and permissions.
Interfaces - Cloud management options.
Resource Virtualization - Compute, storage, network, database, containers, etc.
Resource Orchestration - Automation of cloud infrastructure deployment.
Telemetry - Operational and control plane metrics and logs.

Based on these features we can devise an illustration related to OpenStack Cloud Platform. To help us explain the Cloud Platform concept more completely we include some features present in AWS, Azure, Google and OCI Cloud Platforms to our illustration as well, so not all cloud management options listed in the illustration are necessarily found in OpenStack. I think it is nice to reflect what a Cloud Platform is and what are cloud management options without always referring to the well-known Public Cloud vendors.

As observed from our illustration we can see that main cloud management options provided by common Cloud Platforms may include the following main cloud management methods:

Management Portal - Daily cloud operations
Command Line Interface - Daily cloud operations and automation tasks
Tools - Utilities to support daily cloud operations
Management Application Programming Interface (Management API)
SDKs/Libraries - Programmatic usage of deployed cloud service features
Infrastructure as Code (IaC) - Consistent deployment of cloud resources
- Declarative IaC
- Programmatic IaC

Let us address each cloud management option in their own chapters next. Some of the things we mention about each cloud management option are based on author’s own experiences and observations, and may contain opinions that some readerers might not agree with. Keep in mind that the purpose of this material is to introduce various cloud management options to someone new to public cloud. To create a comprehensive understanding of the topic, it’s helpful to present the information in a clear, distinct way, even if some concepts are simplified for clarity.

Management Portal - Daily cloud operations

Cloud Management Portal is a web application that kind of gives remote access control over virtualized resources in hyperscaler’s data center(s). If you wonder what a web application is then let us not dwell on that for long. Suffice to say that Cloud Management Portal equals a website with user interfaces to control cloud resources.

Cloud Management Portal leverages AuthN, AuthZ and User Directory features of the Cloud Platform and offers a visual user interface for the user that is making changes to cloud resources. Let us call this user a Cloud Engineer from here onwards, because we can imagine that our imaginary user has some reason to effect changes to cloud resources and Cloud Engineer fits the description. Management Portal is used by all kinds of users for all kinds of routine tasks and monitoring so it is a common tool for day-to-day cloud operations.

Positive things about Cloud Management Portal is that it offers low entry barrier method for manging cloud resources. Sure, it isn’t the most powerful management option we could leverage, but it does come with lower skill requirements. Most often Management Portal is used for learning the cloud, troubleshooting cloud issues and very commonly it is used to observe billing and cost related information or help to effect cloud governance.

Cloud Management Portal manifests in different kind of tabulated views to different cloud resource types and often has builtin dashboards for different purposes. Cloud Management Portal is used by all kinds of users and is a daily cloud management tool, and it is notably well suited to be used by semi-technical roles.

Challenges with Cloud Management Portal come with difficulties in automation cloud management related tasks and from it being a management option that only scales in linear fashion. That means, that only way to increase ouput of our Cloud Engineers is to throw more of them at problems at hand. Cloud deployments are often quite complicated and Cloud Management Portal does not lend well to managing various systems and their development, test and production environments.

Chore: Cloud Management Portal may cause chore (mindless repetitive toil) because Cloud Engineers need to track some kind of manuals or guide documents that help them to perform repetitive tasks which inevitably lead to human errors and more chore. This is, of course, a feature of manual human work, not a fault of the Cloud Management Portal itself.

Here are main management portals for AWS, Azure, Google and OCI:

Command Line Interface - Daily cloud operations and automation tasks

Cloud Platforms offer Command Line Interface (CLI) text based user interfaces to manage cloud resources. CLIs might be the main user interface to Public Cloud in many work settings. You can effect changes to cloud resource via CLI, but you also require CLI to manage OS, containers, deployments, CI/CD pipelines, version control and the list goes on. CLI is used on Cloud Engineer’s computer or directly in Cloud Management Portal as with AWS (CloudShell) and Azure (CloudShell).

CLI is basis for many automation tasks. Scripts, events and CI/CD pipelines rely heavily on complex CLI commands. CLI commands often are parameterized and have many many parameters to rely on. That is why it is often necessary to create scripts to help to run complex CLI commands or more frequently sets of complex CLI commands. Despite the complexity, CLI is a fast user interface for experienced Cloud Engineer. Challenge for public cloud learners is the higher learning curve, but it is not an insurmountable task. CLIs provide a higher degree of control and flexibility compared to Management Portals.

CLI as a cloud management tool is excellent resource for many kinds of adhoc or mass operations, because Cloud Management Portal often lacks direct support to these kinds of tasks. Some Cloud Platforms like Microsoft Azure may have multiple different CLIs available to achieve similar kinds of outcomes. Azure supports traditional CLI for Windows, Linux and MacOS operating systems called Azure CLI. Microsoft has also developed other kind of CLI called PowerShell that is also supported by Azure. Cloud Engineer does well to learn multiple different CLIs!

Compared to Cloud Management Portals CLI as a cloud management tool of course sometimes loses in visualization capability.

Chore: There is chore involved with CLI cloud management option, because building complex CLI command sets is time consuming and error prone. Resulting scripts might be sometimes hard to develop, test, maintain and troubleshoot. Generative AI can help a lot building first working versions of complex CLI commands sets and to resolve obscure error messages!

Examples of CLIs include:

Tools - Utilities to support daily cloud operations

It is sometimes easy to forget that there are specifically built Tool applications available for cloud management. Of course many CLI commands can be also thought of as tools, but in here we specifically refer to client applications that support specific use cases. Tools may simplify or enhance interaction with some cloud resources without needing to use Cloud Management Portal.

Examples of Tools that can be used to manage cloud resources are applications such as:

AWS S3 Browser
Azure Storage Explorer
Putty
Remote Desktop Protocol
curl

These purpose built tools are useful for both developer and administrator type Cloud Engineers, because they offer a way to manage for example storage resources without relying only on the CLI, APIs or Management Console. Internally these Tools leverage SDKs and APIs to provide their functionalities.

SDKs/Libraries - Programmatic usage of deployed cloud service features (API calls via Libraries)

Software Development Kits (or SDKs) are what programmer and infrastructure specialist type Cloud Engineers use to access Service APIs and Management APIs. SDKs often manifest as a set of Libraries that can be included by Cloud Engineers to be part of applications or infrastructure deployments. SDKs/Libraries provide ability to expand applications or infrastructure deployments. SDKs are a broader concept though, because SDKs might also contain documentation, tools and sample code besides Libraries. SDKs are the often the main method for developers to interact with cloud services programmatically.

Public Cloud vendors typically offer and support SDKs/Libraries for multiple programming languages: C#, TypeScript, Python, etc.. Often these SDKs/Libraries basically allow access to Service APIs or Management APIs without need for the developer to implement direct API calls. Usage of Libraries can cause vulnerability issues with implementations, because of dependency chains where Libraries rely on other Libraries that rely on other Libraries… If there is vulnerabilities or problems in some Library somewhere in the dependency chain it might be challenging to identify beforehand and may cause vulnerabilities or build breaks!

Chore: Checking for vulnerabilities in implementations and their dependencies causes extra work for Cloud Engineers, because they need to do extra implementations to handle these issues or they need to troubleshoot issues with dependencies!

Examples of SDKs include:

Management API - Programmatic usage of deployed cloud service features (raw API calls)

Application Programming Interface (API) in cloud management context typically refers to web service APIs that work over HTTP and are used to effect changes to cloud resources (create object storage container, remove object storage container) or leverage functionalities of cloud services (upload files to object storage, download files from object storage). Cloud Engineers that are infrastructure specialists leverage Management APIs as a method of programmatically ccontrolling cloud resources.

Management APIs sames as CLIs are frequently used for automation tasks often through CI/CD pipeline. Cloud resource changes originating from build automation may use for example curl utility to make API calls. Management APIs give access to control Virtualization Platform that exist within or below Cloud Platform that lets Cloud Engineers to manage cloud resources such as virtual machines, virtual storage and virtual networks. Management APIs can sometimes be used directly, but often they are rather used via SDKs/Libraries as explained earlier.

Examples of Management APIs include:

Infrastructure as Code - Consistent deployment of cloud resources by using plain text templates or code

Declarative IaC versus Programmatic IaC

There are two basic variants of Infrastructure as Code. Declarative IaC (“Infrastructure as Configuration”) and Programmatic IaC (“True Infrastructure as Code”). There are commonalities between Declarative IaC and Programmatic IaC. First of all both types of IaC are plain text. Sure on the other hand templates are semi-structured text formats like JSON, YAML and XML and code is general purpose programming language like TypeScript, but all these text formats are just plain text. Because IaC is plain text it can be treated as source code and version controlled in Git.

Because IaC is plain text we can apply syntax and code structure validation tools to them to increase code quality and because IaC is managed in version control system we can employ practices like Issue Linkage, Pull Requests and Code Reviews with them to help effect effective change management process. In some cases IaC can also be tested as if it was program code. The defining feature of IaC is Consistency or Idempotency, which means, that once cloud infrastructure definitions have been created the environment can be deployed or updated in a way that outcome is the same no matter how many times we deploy them. With humans this is not possible, because compared to computers we are slow and error prone. Computers don’t make mistakes, except the ones we make them to make. IaC deployments of course may face transient problems during deployments so they are not 100% reliable.

Additional bonus thing related to all flavors of IaC is that it kind of documents itself, because configurations as they are can be found from files or if the configurations are parameterized we can find out the settings for example from logs.

Declarative IaC (Templates)

Declarative IaC refers to defining cloud infrastructure by using semi-structured plain text template files. This is probably the most common flavor of IaC used in companies! Focus of this type of IaC is to describe what the cloud infrastructure should look like after the deployment. Template based IaC can be less flexible than programmatic IaC, because the former often mostly consists of static configurations. Declarative IaC leverages such domain specific file formats as HCL, JSON, YAML or XML.

When using Declarative IaC state of the cloud environment and provisioining of resources is automatically managed by Cloud Platform. Template based IaC is ideal for use cases where Cloud Engineer wants to define static infrastructure with predictable desired state.

Automating deployments with template based infrastructure can be done by integrating infrastructure deployment to CI/CD pipeline, but if this is not done and deployments are done directly by Cloud Engineers using mix of IaC, build scripts and deployment scripts on their own computer this can lead to confusing unmaintanable mess. At the best of times Declarative IaC can be just as automated as programmatic IaC.

Declarative IaC is excellent when we want stable and predicatble infrastructure, but this flavor of IaC may struggle when the infrastructure becomes dynamic or requires complex logic. Reuse of code becomes from being able to copy working templates or parameterizing templates to deploy for example three versions of same environment (often development, test and production environments).

Examples of Declarative IaC (Templates) include:

Programmatic IaC (Code)

Programmatic IaC refers to defining cloud infrastructure by using general purpose programming language. This method of deploying cloud infrastructure is especially suitable for DevOps Teams that work in Everything as Code principle. For example pekkakorpi-tassi.fi web site is built with Everything as Code principle and leverages AWS CDK 2.0 Programmatic IaC. Modern web applications implemented with Everything as Code principle result in source files to be written in few as possibe general purpose programming languages:

CI/CD Pipeline: TypeScript
Cloud IaaS and Paas Resources: TypeScript
Frontend: TypeScript
Backend: TypeScript
Documentation: Markdown
Developer Environment: Docker devcontainer, JSON

Focus of Programmatic IaC is to define how to create cloud infrastructure procedurally. Flexibility of Programmatic IaC is high, because we can use general purpose programming language features such as functions, conditionals and loops. Typically Programmatic IaC technologies support multiple programming languages such as TypeScript, JavaScript, Python, Go, Java, C#. State management of cloud infrastructure maybe a little more complex than with Declarative IaC, because Cloud Engineers manage environment state directly through code, though modern tools like AWS CDK and Pulumi help automate and simplify much of this process.

Programmatic IaC is suitable for complex, dynamic or programatically driven cloud infrastructures. Default deployment method for Programmatic IaC is CI/CD Pipeline and as mentioned Programmatic IaC manifests in Everything as Code context. Programmatic IaC is also useful in scenarios where infrastructure must be conditionally deployed based on variables. Reuse of infrastructure definitions comes from ability to create libraries, functions, classes and constructs. Programmatic IaC has higher entry barrier than Declarative IaC, because using this flavor of IaC requires mature DevOps Team and programming skills from the Cloud Engineers.

Examples of Programmatic IaC (Code) include: