Many organizations are looking to make the decision between adopting a single-account model, or a multi-account model for supporting their cloud environment. This article walks through the typical cloud journey for organizations initially adopting a single-account model and discusses the challenges that come along with that approach. Frequently, cloud teams begin with the single account model with a small team, working on a shared goal. They start with a few people in an account, just trying things out, with the intent of "fixing" it later. However, it often never gets changed because it instantaneously becomes production, and new workloads just get added on.
The next level of progression becomes something of a shared office. Now that a few "Proof of Concept" projects have been completed, more people start getting moved in. More hands are in the pot now, and knowledge sharing on configurations becomes harder. How does one person keep their lunch safe in the office refrigerator? You don't. So now, some rules need to be introduced. Everyone's intent is good, so you start ending up with sticky notes on your monitor saying "Don't touch XYZ settings or the guy on the 4th floor will send me a nasty email because I'm breaking his application." As a result, you end up with a lot of mess hanging around, and teams start wondering how this will be managed as the environment scales and more people are added.
Sometimes, it's a matter of taking an entire data center migration, performing a lift and shift, and moving into a single account because of the perception that it simplifies the migration process. An on-premise model has effectively been recreated with one key exception - now that you've migrated, you're giving increased access to DevOps teams and Application teams in order to achieve the agility promised by the cloud.
Then, we move to a hosted services model. Perhaps this includes a handful of accounts such as Dev, Test, and Prod that are centrally managed and shared by different teams and projects. The central team manages the party, and anyone needing services needs to get in line. Unfortunately, this bottlenecks the innovation process. The central team, while wanting to be helpful, just gets in the way and slows the down the organization's agility. Your application team that needs the ability to do a hotfix on demand, now has to wait weeks to get something into production. And, this doesn't change the fact that if there is a malicious actor in the mix, they still have access to everything.
The true nirvana is a multi-tenant model - a big apartment building with each team or application getting their own apartment. Projects operate with independence and isolation, with agreed rules and services (and exceptions when needed). Cloud providers give us a multi-tenancy model to begin with, and we can use that to our advantage. By separating all of our workloads into distinct accounts, we create a hard blast radius around each person, each group, or each team. Then, we can focus our efforts on services that accelerate and coordinate how we operate across those isolated applications, rather than troubleshooting and managing down technical debt of issues incurred supporting or unwinding the single-account model.
We believe that you need to adopt the multi-account model on to prevent many of the issues that come along with growth through the single-account model. At the point that you begin bringing in other teams or applications, make the split to multi-account immediately. The single-account model may seem attractive at first but can cause significant problems later. And, reworking the model at scale is a painful process, and often nearly impossible to justify from a time and cost perspective. Even if you're already well invested in the single-account model, take the time now to make the shift to multi-account.
Contact us to learn more about the benefits of choosing a multi-account model for your cloud, or to understand how Turbot Guardrails can help you manage your multi-account cloud at scale. Or, schedule a demo to see Turbot Guardrails in action.