In recent years, the demand for self-service cloud provisioning has grown tremendously. Self-service is a paradigm that enables developers to access the cloud resources they need.
Understanding the roles of Workload Identities, Cluster Service Accounts, IAM Policies, and IAM Roles in managing access controls within AWS environments.
Exploring real-world use cases to illustrate the importance of effective IAM policy management in securing multi-tenant environments and aligning access controls with business requirements.
Comparing manual IAM policy management with streamlined approaches, such as Wayfinder's Package Workload Identities, to highlight the benefits of automation and centralised policy management.
In recent years, the demand for self-service cloud provisioning has grown tremendously. Self-service is a paradigm that enables developers to access the cloud resources they need — such as computing, storage, and databases — and enables them to provide these resources without manual approval from infrastructure or DevOps engineers. This workflow removes friction by allowing development teams to quickly build and ship applications without ticketing systems or dedicated cloud engineering resources.
Successful companies lean into the concept of self-service. The 2020 State of DevOps Report shows that highly evolved software firms are six times more likely to use internal self-service platforms than firms at a lower level of their evolution. This trend has continued, with the 2022 Report stating that 68% of teams that have introduced self-service initiatives have improved their engineering velocity.
Cloud infrastructure tooling relies heavily on skilled cloud engineers. Shifting this responsibility to the developer typically requires significant developer upskilling, as it’s neither commodity-ready nor self-service-ready. Therefore, using the right self-service tooling is crucial.
So, how do you build a self-service delivery system for a public cloud? In this article, you’ll learn how to enhance Terraform to remove the barriers to developer self-service and increase the efficiency of cloud self-service.
The Infrastructure As Code (IaC) approach lets DevOps teams spin up resources and provision infrastructure with tools like Terraform or native cloud technologies like AWS CloudFormation, Google Deployment Manager, and Azure Resource Manager (ARM). Kubernetes also allows for extensibility beyond application deployment with operators or controllers. Users can write these to talk to the cloud providers’ APIs and provision cloud infrastructure.
Kubernetes is a container orchestration tool for managing the lifecycle of your applications. It can also manage the lifecycle of other objects that provide outcomes in and around application delivery. Some of these outcomes include managing certificates for applications, managing DNS with different DNS providers, and driving cloud resource provisioning for application dependencies, such as database or message queues.
Standardising with Kubernetes as the common interface helps bring a self-service capability to developers who are already familiar with containers and are beginning to adopt Kubernetes for application deployment and management. By bringing their application and its dependencies into the same configuration syntax, developers can work end-to-end with one tool without learning additional configuration frameworks and technologies.
Cloud automation tools often have a steep learning curve and require developers to know cloud infrastructure and security details. Moreover, the time a developer spends learning to operate these tools is time spent away from building applications. Developer self-service reduces the knowledge needed by baking in cloud engineering best practices alongside custom application requirements, shifting left the custom requirements only.
Terraform is a cloud automation tool that automates and manages your cloud or on-premises infrastructure. It uses a declarative language for automation and management, providing a domain-specific language (DSL) for cloud provisioning. The result is a common interface across multiple cloud providers. Users can provision an overall cloud outcome that meets the application’s technical requirements and the business’s security requirements by producing, consuming, enhancing, or changing Terraform modules.
Terraform uses this DSL to provision resources but keeps track of these changes by saving state in their cloud service or a database or backend provider. This state contains the current infrastructure setup that it can use as a basis for determining any steps that must occur to reach the required outcome. It determines the difference between the existing requested state and the new requested state and apply those changes.
The result is immense flexibility. Terraform provides the infrastructure and operational requirements ready for applications to consume it. It simplifies multi-cloud deployment by enabling teams to provision infrastructure across multiple clouds using the same workflow and tools. Moreover, teams can manage cloud services in a repeatable way across all of their clouds using their own continuous integration and deployment tools. Terraform automates most of the cloud-based heavy lifting so that you and your teams can avoid repetitive manual configurations.
Terraform supports multiple clouds. It can automate and manage a broad range of resources on various cloud platforms, including Amazon Web Services (AWS), Azure, and Google Cloud Platform (GCP). However, Terraform doesn’t natively provide self-serving capabilities back to teams and assumes knowledge of their DSL and cloud configuration best practices. This creates a steep learning curve for developers.
Learning Terraform and the cloud shifts focus away from the business logic, moving development time away from application delivery into cloud delivery. This resource time may suit smaller businesses that must optimise their resource footprint. However, this would significantly slow down application delivery for organisations with several teams.
Each project and application has a unique set of parameters to configure. For instance, a production Amazon Simple Storage Service (S3) storage module requires project-specific information, such as the requirements for a platform engineer or cloud expert. These include encryption, identity and access management (IAM) access roles, and operational business requirements, including backup and region. In most cases, the requirements for a developer would include the bucket name, website configuration, and whether the website is public or private, depending on the business’s security policy.
However, you can streamline these processes by providing a self-service solution that enables developers to provide inputs, letting the platform team embed general configurations (such as security settings) into the cloud modules as defaults. The tool can permit developers to input application-specific configurations, and cloud modules can encompass default configurations inherited from what the platform team globally defined. This simple abstraction layer enables teams to provide faster application delivery without requiring developers to dig into the technical details of DevOps tools. It also allows platform teams to embed security requirements into the cloud modules, reducing risk and providing a consistent way to manage cloud resources as a global set of approved configurations across all projects.
Developer self-service saves time, effort, costs, and resources, and enforces standardisation of security and best practices by automating the cloud delivery process. This automation reduces the risk of human error and provides visibility to teams as they iterate.
Here are some additional benefits of Terraform for self-service:
Many open source tools enable developers to control Terraform and Kubernetes. However, they often don’t address the consequences of developer self-service — such as the risks, costs, security implications, and lack of security checks.
In contrast, the Appvia Terraform controller (or Terranetes controller) manages the lifecycle of Terraform resources via Kubernetes and ensures that the platform team can implement policies that developers can follow via self-service. This ensures that the developers work in a environment that only platform engineers can control. Concurrently, development teams can self-serve application dependencies and have an end-to-end working application without the friction of learning cloud nuances and complexities.
The Terraform controller has several technical controls, such as the Checkov security policy, budget controls, environment defaults, and module security. These credentials can be statically defined or added to the cloud vendor via pod identity.
The many reasons to use Terraform controller include:
This article introduced the concept of cloud self-service blockers and explained some of the infrastructure-related issues in the way of self-service cloud tools. It discussed the advantages of self-service and how blockers can reduce these advantages. The article also explained what cloud Terraform is, how it works, and how you can use Terraform to remove blockers from cloud self-service and empower teams to deliver and scale in the cloud.
Although Terraform primarily focuses on the DevOps and platform engineer personas, this article also discussed how Appvia’s Terraform controller makes it easy to use Terraform for cloud services. Terraform controller lets developers independently self-serve application dependencies while ensuring they comply with the company’s policies.
To learn more about self-service cloud computing and how to securely self-serve cloud dependencies, check out Appvia!
