How We Solved Infrastructure as Code

Infrastructure as Code (or IaC for short) has been gaining traction recently—and for good reason. It brings with it a ton of benefits, but can often be challenging to get started with. Many cloud services still lack support for it, forcing users to navigate a maze of control panels to make changes to their infra.

At Diploi, we looked at existing solutions such as Terraform, Pulumi, AWS CloudFormation, and Azure ARM Templates but found that none fully aligned with our motto of providing a "magical development experience". While these tools are highly versatile and capable of handling almost any infrastructure configuration, they are often difficult to master and excessively verbose. Setting up a single service often requires creating multiple templates and configuration files.

As that was not the developer experience we were looking for, we decided to build our own easy-to-use IaC solution.

---

What is Infrastructure as Code?

For developers, Infrastructure as Code (IaC) essentially means replacing cloud provider management dashboards with config files. These files contain everything necessary to replicate a specific environment, ensuring that the environment your code runs on is always set up correctly and consistently.

Typically, your IaC definitions would specify the following:

• Deployment Target: Where your code will be deployed, such as AWS or Azure.
• Required Services: The services needed to support your application.
• Virtual Machine Setup: Configuring any necessary VMs and installing dependencies.
• Network Configuration: Setting up & securing the network. Provisioning domain names. Configuring DNS.
• Application Execution: Deploying and running the application code.

---

Our Implementation

We thought a lot about the best way to implement IaC into Diploi. Our solution had to be intuitive, developer-centric, and highly customizable.
We settled on a component-based model that allows users to easily configure their stack without making the config overly verbose. The more detailed config for a component, such as HELM charts and other setup files, are housed in dedicated GitHub repositories maintained by the component owners.
However, users can also specify local path for a component, enabling custom components to be seamlessly inlined within the projects repository.
This approach gives our users the best of both worlds: a simple, easy-to-use config combined with limitless customization options, including custom Docker files, HELM charts, and more.

diploiVersion: v1.0
components:
  - name: Next.js
    identifier: next
    package: https://github.com/diploi/component-nextjs#v0.0.1
  - name: Local
    identifier: local
    package: ./local-package
addons:
  - name: PostgreSQL
    identifier: postgres
    package: https://github.com/diploi/addon-postgres#v17.0

A simple Diploi config capable of replicating a complex environment.

 

These simple config files, combined with our intuitive Stack Builder, create a developer experience within Diploi that is magical ✨ and unparalleled.

---

Benefits of Our Implementation

Our implementation in Diploi comes with a long list of benefits, many of which are true for any IaC system. Here are some of the more interesting ones in a easily digestible list:

1. Versioning with Git 🌳
   • Maintain separate infra in different branches
   • Diffs & blames for infra changes
2. Self-Documenting Config Files 📝
   • View all infra components in a single file
   • Clickable links to find information on each component
3. Inlining Components 🏠
   • Include component config files directly in the local repository
   • Permanent version pinning and customizations

We’re still working on our system, so stay tuned for a more detailed explanation in the future. 😉

---

By the way, we’re currently looking for developers to join our internal testing program. If you’re interested in trying out our version of IaC before its official release, leave a comment, and I’ll get in touch!