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
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:
- Versioning with Git 🌳
- Maintain separate infra in different branches
- Diffs & blames for infra changes
- Self-Documenting Config Files 📝
- View all infra components in a single file
- Clickable links to find information on each component
- 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!
Top comments (6)
Is it only me or it would be more beneficial to just create plugin/modules for such systems as terraform, ansible and so on?
I think for people who are already familiar with those systems it could be more beneficial, but we wanted to create something that any developer can user, regardless of their skill level. We will, however, also support custom Docker files & HELM charts, so you will still have a lot of flexibility if you are familiar with the devops side of things. Thanks for your feedback!
Maybe not just you but I've seen devs struggle with both, as well as similar tooling for K8s. This sounds like a more Heroku-like experience.
Not just you, I agree with you.
I feel this would’ve been a great candidate for the Open Application Model (OAM). Are there any reasons for not using it for your use case?
One thing that separates Diploi from many other services is that we fully support cloud development environments. That is actually the whole reason we decided to create Diploi in the first place. A lot of the existing standards, like OAM, are really only meant for running apps, not developing them. While you can run development containers with OAM, the spec is not designed for that use case, making it difficult to adapt.