This has to be the worst take on IAC organization I have ever seen. I would have never thought someone would try to apply the osi model to infra code management.
How long does it take to deploy a new service with this approach? A week?
How long does it take to deploy a new service with this approach? A week?
> Be kind. Don't be snarky. Converse curiously; don't cross-examine. Edit out swipes.
> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
Given that, how is one supposed to reply critically to such a post? I'm genuinely curious and open to suggestions, as it's something I'm clearly not good at.
Link to or describe a better approach and explain specifically why it's better.
Your only specific part was that it's slow to deploy a new service which for most organizations is somewhere on the bottom of their priority list. In fact many organizations probably prefer slow deployments as that implicitly discourages unnecessary services and infrastructure bloat. That in turn lowers the long term maintenance burden and technical debt. Five hundred services that are in reality owned by no team or whom no one knows about are not what you want in an organization.
These Reddit level comments don't belong on this site.
It is in some cases required to do some version of this as the vendor API support does not allow for proper feedback when an operation is complete so it needs to settle.
Or, building docker images which run each time and take a long time / resources unnecessarily (I believe Pulumi have a fix for some version of this).
If your stacks are deployed via CI/CD, it’s not really a big deal to deploy 10x stacks in sequence, or just.
This may be overkill for a lot of projects but it’s valuable insight from a respected organization / individual.
What's next, real world data to back up their claims? Research papers offering corroborating evidence?
This is the internet, we don't do that here.
Avoid splitting this up as it introduces too much complexity. The IAC code should be very simple such that any dev can pick it up just coming off the tutorials.
Company I'm in has 3 layers and dozens of stacks and it's made the whole thing impossible to reason about. No one wants to touch it anymore which means we now have a Platform team that screws around with this chap for months on end.
Note: Lee Briggs works for Pulumi as a Principal Platform engineer so its in their interest to make this too complicated.
> Start with a common stack with all your common stuff
> application stacks with stuff that specific to some application
So... layers! Right then.
ding ding: we have a winner
Everyone gets here eventually and you can just fight over stuff like “is an alb shared regional or app specific”
Infra should be simple as possible, and the simple infra should inform simple app design.
I bet we have far more instances under our name than the people that write this article, and yet we have nowhere near that level of complexity in our IaC definitions. And yet, somehow we manage. I guess we are immature?
We however had the advantage of building IAC from ground up and had the time to do it properly.
My challenge at $dayjob is that it takes months to spin up a new cloud service because they’re new.
Either a new app that wasn’t on the cloud before — in which case the templates need extensive customisation.
Or, new app in the sense that the devs just cracked open Visual Studio and have no idea yet what they actually need from the cloud.
I get maybe 10-20 copies of a template (dev/tst/prd + ha/dr), and then I have to start from the beginning.
Guidance on how to maximise reusability would actually be very useful.
Unfortunately, in the real world, this seems difficult. Many small variations in requirements tends to make abstractions leaky.
For example, one vendor requires active-passive load balancing for licensing reasons. Millions of dollars worth of licensing reasons. Neither AWS nor Azure support anything but active-active in any of their load balancers. (They do in DNS, but for various reasons that won’t work for us.)
Another “new” app (industrial air quality monitoring) is actually from the stone ages and doesn’t support PaaS databases or even 3 of the 4 clustering modes available in IaaS. So a custom load balancer solution is required… just for it.
This is the issue. Everyone that loves the cloud and says it’s simple has easy mode turned on: cookie cutter clones they can stamp out for many identical customers or whatever.
Some people play the game with “big government” difficulty.
Happy to talk through the setup we're using and some other setups I've seen work if you're interested, but it's quite extensive.
Our current setup is heavily inspired by the work Gruntwork (not affiliated) are doing. I highly recommend taking a look at how they do it and even subscribing to their service if the need is there. They provide pre-built modules for basically any usecase.
So far I’ve struggled to get any real modularity.
The biggest issue I’ve had is that every assumption I’ve made has been violated.
So either modules must be fully generic — saving no work at all — or make assumptions and then not be reusable.