Prior to joining Blis Digital, I worked a lot with Enterprise customers with very mature Azure environments. Infrastructure as Code was the norm there, manual configurations were the exception.
At Blis, it works a little differently. Blis' customers are fast and ambitious, so they innovate quickly and give less priority to setting up the infrastructure. That makes sense, given their focus on time to market, but it's exactly why I'm now part of the Blis team: because it standardizes your infrastructure and thus prevents bugs and unpredictability, IaC actually contributes to the rapid launch of new features.
At least if you start at the right time.
In that regard, in my experience, there are 2 possible situations:
Scenario 1: Manual configuration works properly
The first scenario I encounter regularly: the software runs in the cloud, but we have configured everything manually. So that works great. You may be surprised, but I would not easily advise such a company to change everything and switch to IaC. Because that can be a complex process and not without risks, while the expected benefits for a stable solution do not outweigh it.
That will be different when an investor suddenly comes in there who starts investing heavily in international marketing. Or, for other reasons, a thousand new customers suddenly join, the data center has to move, or a software license expires. These are situations where you are forced to take a critical look at your infrastructure anyway. And then you discover that a manually set up environment makes it difficult to scale up and make changes quickly.
Then it suddenly becomes interesting to work with IaC.
Partners who set requirements
IaC can also suddenly become relevant for these companies if they start working with suppliers that offer their services in the cloud. Or when customers' resell 'their software and make it part of their own services. In fact, as a software maker, you will then become PaaS (Platform as a Service) supplier. In both situations, infrastructures are not only becoming more complex, predictability, scalability and stability are also becoming much more important.
Finally, it is also possible that we at Blis Digital set requirements for how the infrastructure is configured. That's what we do when customers ask us to maintain their Azure environment for them. We can only do this cost-effectively if the environment is very standardized and stable. So then IaC is the only option.
Scenario 2: greenfield
In the second scenario, for me, IaC is a no-brainer: companies that are just starting to build software in the cloud. If you're starting a new digital product now, there's simply no good reason not to define your infrastructure in code. Even if your solution is small and simple. Then the IAC file will initially fit on your screen without scrolling and you can just take it with you from the start. You'll enjoy that a lot later.
Lastly
So IaC is not an end in itself, but a means of making your infrastructure manageable, scalable and predictable. The right time to start depends on your situation. Are you just starting out? Then start using IaC right away. Do you already have a running environment? Then wait for the right time, such as a major change in your organization, to make the switch. After all, your infrastructure should help you achieve your goals, not vice versa.
.jpg)
