2 karma · joined August 15, 2017
Well, the problem is that a majority of people don't want to / don't have the time to learn HCL, because it's not the most effective use of their time / not worth the "investment" to do so.
Learning HCL is not very rewarding, unless you are an ops person. Learning a general purpose language language like Python, TypeScript or whatever language your company uses is rewarding both for ops and dev people (or devops people if you like that term) and typically can be used for a much wider set of use-cases.
When introducing a new language the pros and cons of doing so should always be carefully considered, however unfortunately for devops tools new languages like HCL,Jsonnet,Starlark,zillions of YAML pseudo-programming DSLs etc. are often introduced very lightly, mentioning a handful of use cases where the new language shines, but ignoring the cons and intrinsic costs (learning curve, new tools, editor integrations, package manager etc. to be built).
Terraform works great for teams where you have a strict separation between ops and dev people. The ops people will spend their time learning HCL, the dev people will learn Python, TypeScript or whatever that is. However if you are trying to truly embrace a "DevOps" model Terraform shows its flaws. Developers will either still heavily rely on ops people to "help them" even for trivial infra changes or they will write sub-par copy pasta HCL code that tends to be verbose.
TF 0.12 may have a bunch of new constructs which make it easier to reduce duplication, but the boilerplate that is required to create an actual reuse module with variables and import it (and overall awkwardness of the module system/syntax compared to any other language) vs the simplicity of creating a reuse function/file in Python/TS is like night and day. Furthermore the subpar editor support for TF makes it actually hard to follow references between modules and safely refactor code, so there is a much lower threshold at which an abstraction appears "magic"/incomprehensible in HCL, compared to typed TS/Python where you can easily follow references.
Source: ~2 years worth of Terraform (incl. 0.12) and ~1 years worth of Pulumi use within multiple companies and teams.
I'm currently reevaluating the CI/CD story for my company. We're a small startup with ~20 engineers. I would like to give you some feedback and questions on Azure Pipelines.
We're currently using gitlab.com for code hosting and CI/CD. We're in the Silver / Premium pricing tier so have most of the premium features. Our software stack is mostly on GKE Clusters on GCP and we also run gitlab runner in a GKE cluster.
We're honestly not super happy with gitlab.com due to performance, stability and UX issues - overall not super happy with the overall quality/depth of the product. That's why we're considering to make the switch to github.com and reconsider the whole CI/CD story. I evaluated about 20 CI/CD platforms, but unfortunately didn't find the perfect one. There was always at least one important feature missing or the management of the system (i.e. jenkins, concourse) would've been too much overhead for a company of our size.
My preliminary conclusion is that we should probably stay with GitLab CI/CD for now (even when switching to github.com for code hosting) since it is good on most dimensions (far from perfect though) and has low management overhead.
However I gave yesterday Azure Pipelines also a shot and liked many things I saw. My impressions were like that: Pros: - Flexible build system / environment, can run on VMs, containers, self-hosted agents etc. - Reasonably complex builds can be expressed in the yaml. - Reasonable pricing - Big plus: Very sophisticated release / deployment pipeline management. Nice sweet spot between solutions with no / limited CD support (e.g. circleci, gitlab) and complex systems like spinnaker. - very good github integration (uses checks API)
Cons: - Big con: Self-hosted agents cannot autoscale. For comparison gitlab runner k8s executor spawns kubernetes pods on demand so the infra / cluster footprint is really small in idle times during the weekend or nights. In comparison azure pipelines seems to only work with non-ephemeral agents and one has to set a fixed statefulset count: https://github.com/Azure/helm-vsts-agent - Big con: Release Pipelines are only configurable via UI instead of code - No explicit docker layer caching support (vs codefresh, circleci) - Many out-of-box integrations / features are tied to Azure Cloud, for other clouds (i.e. GCP) one has to do write custom scripts or integrations.
The two biggest cons for me are really the non-autoscaling self-hosted agents and that release pipelines are only configurable via the UI. The release pipelines only-UI problem I consider a blocker for us.
In other words: If you would allow configuring release pipelines in code we would probably switch to github.com + Azure pipelines. FYI I prefer expressing complex pipelines in a real and common programming language like TypeScript or Python3 (think Jenkins: Groovy, Airflow: Python, TeamCity: Kotlin Script etc.) over YAML, even though I can live with YAML for now.
Is your team working on enhancements to any of that and what would be the rough timeline?
Thanks!