Our great sponsors
-
-
Pulumi
Pulumi - Infrastructure as Code in any programming language. Build infrastructure intuitively on any cloud using familiar languages 🚀
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
Well, it depends on the language. Some are quite good at restricting programs so that it is not possible to execute arbitrary code.
Take a look at https://propellor.branchable.com to see how Haskell might be used.
Idris might be a good candidate as well.
https://dhall-lang.org is quite interesting for these purposes as well (although it is not general purpose)
Bicep has limitations which makes it non-declarative even though it is marketed as declarative: https://learn.microsoft.com/en-us/azure/azure-resource-manag...
MSFT is trying to add features to make this better, but it is not in production yet: https://github.com/Azure/bicep/issues/10460
Additionally, Bicep does not support interacting with Azure Active Directory: https://github.com/Azure/bicep/issues/7724
So it really is not very useful. Terraform is better in almost every single conceivable way.
Author here. This is correct. I have used Pulumi and I love CDK. I think the models in Pulumi and CDK are both great, but they tend to be either too low level or too high level.
For example Pulumi has a `awsx.ecs.FargateService` class that can deploy a container to AWS Fargate, but the API is limited and you don't really have the capability to remix it into other scenarios. For example you have the capability to attach a load balancer to a service as ingress, but what if you want to attach an API Gateway, or just setup a Route53 record for direct public IP ingress?
CDK has a few more variations in what you can do but it tends to be even worse because it has class names like: `ApplicationLoadBalancedEc2Service` and `NetworkLoadBalancedFargateService`. Switching your infrastructure requires switching to an entirely different top level when you define your infrastructure.
What I am proposing with the extensions interface is that we build more a class inheritance style model, kind of like CSS, to let people mix in alternative behaviors, alternate configurations, or even attached resources in an additive way, onto the existing infrastructure as code model.
In the example prototype on Github you can see how this works: https://github.com/cdklabs/cdk-ecs-service-extensions
All types of mutations, from configuration mutations, to attached resources are just extensions that you can use the `ServiceDescription.add(Extension)` method to attach to your existing infrastructure, kind of like just layering on another CSS class onto your DOM element. I think for large and complex infrastructure this will be a more scalable, decouplable, and readable approach.
I have a similar view to yours: as soon as you need variables, imports, functions or any other type of logic ... the existing "data-only" formats break down. Over time people either invent new configuration languages that enable logic (i.e. cue or jsonnet), or they try to bolt-in some limited version of these primitives into their configuration.
My personal take is that at some point you are better of just using a full programming langugage like TypeScript. We created TySON https://github.com/jetpack-io/tyson to experiment with that idea.
did anyone adopt in production https://crossplane.io ?