BLOGDevOps

How to make Terraform Self-Service

In recent years, the demand for self-service cloud provisioning has grown tremendously. Self-service is a paradigm that enables developers

Category
DevOps
Time to read
9 minutes
Published
May 20, 2024
Author
Jon Shanks

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.

Key Takeaways

Self-service cloud provisioning has surged, empowering developers with faster deployment and improved velocity.

Effective self-service requires suitable tooling to reduce developer upskilling.

Kubernetes standardises workflows, simplifying application lifecycle management.

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.

Dismantling the Barriers to 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.

What Is Terraform?

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.

Using Terraform to Smooth Out Self-Service Cloud

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.

Benefits of Terraform for Self-Service

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:

  • A catalog of commoditised infrastructure services to help meet on-demand provisioning
  • Increased agility and reduced bottlenecks by providing developers the ability to provision their own self-service infrastructure securely
  • Reduced dependency on DevOps, cloud, and platform engineers. Allows businesses to meet internal cloud demand without scaling the platform team
  • Faster delivery since there is no operator bottleneck
  • Enables automation and consistency across cloud environments
  • Improved security oversight since security checks and balances predefined the delivery method
  • Reusability of the same cloud modules across all projects, removing cloud module and cloud configuration sprawl.
  • Consistent ways of working with a common interface for developers, moving that to Kubernetes

Appvia Terraform Controller

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:

  • Enabling developers to self-serve application dependencies, independent of the DevOps and platform teams
  • Ensuring that developer self-service aligns with the company policies by allowing platform teams to enforce technical controls
  • Providing visibility by showing the cost estimates before creating the resources
  • Centralising cloud security policies used in continuous integration pipelines, giving defence depth at both build and run time
  • Increasing the searchability of cloud modules in your organisation by developers, so they can find which modules exist in the business across all major clouds
  • Kubernetes auto-generation to transform Terraform modules into Kubernetes manifests
  • Implementing security and protecting cloud credentials by adding policies on the configuration of resources
  • Providing simplicity by keeping the Terraform configuration simple and easy for existing modules to consume
  • Standardising on Kubernetes as a way for developers to have cloud application dependencies and deploy their applications
  • Maintaining central visibility of a team’s infrastructure in one place, from application through to cloud

Conclusion

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!

Related Posts

Related Resources