After launching our product, our cloud setup started off simple: just one environment, a database, and a basic deployment pipeline. Fast forward a year, and we now have a more complex setup with multiple environments, various services scattered across the cloud, a partial Infrastructure as Code (IaC) implementation, and a bunch of random scripts that only one engineer understands. The architecture has evolved organically rather than being properly designed from the start. As a result, every infrastructure change feels risky, and onboarding new engineers takes way too long. For those experienced in growth beyond the startup phase, did you face a point where you needed to redesign your entire cloud infrastructure, or did you manage to clean things up gradually over time?
5 Answers
Honestly, it sounds like you need a redesign now. With how risky every change feels and the number of services you’re juggling, starting fresh with a well-planned landing zone could save you a lot of headaches. It might seem like overkill now, but it can make a huge difference in the long run.
Most companies hit a wall when they start introducing multiple environments and microservices. It's common! It might be worth considering this evolution of your systems as a new product. Document your issues and plan a path forward, even if it doesn't all get implemented immediately.
You might be facing a situation where the time spent maintaining the setup is bigger than the time spent on new developments. That’s a clear sign that technical debt is catching up with you.
A containment strategy is key. Make sure current setups don't spiral into new problems while you redesign functionality. Just prioritize which parts to tackle first, and you’ll gradually improve the architecture.
I've been in a similar situation, and the problem usually isn't the tools like Terraform but rather how the architecture was set up initially. We found success using a service to help organize our infrastructure, which allowed for a smoother transition without starting from scratch.
That’s a solid point! Using what you have to document concerns helps clarify future changes.