This message was deleted.

We like Terraform. It’s cloud agnostic so you can use it with multiple clouds if/when you get there and there’s a wide ecosystem of provides that let you manage a wide variety of services. We manage AWS, Snowflake, Elasticsearch and many more with it

Thanks Harel. Do you actually also use it to provide your cloud landing zone? So is there basically some Terraform executed when a new Cloud Account is created and Governance and Security Rules and whatever else is needed to get successfully started with the cloud account is applied to that new account?

Hi Stefan. This is a great question and (disclaimer 😉 ) since I am working for a company where we build Cloud landing zones for companies we are spending a lot of time on the topic as well. In my opinion there are two aspects here: what should the landing zone look like/contain and how can you establish it. In the case of Azure they describe what they see as best practice for the "what" as part of the CAF and they basically tell you to build something like this here. It is a multi-subscription setup and from past experience I know AWS advertises a similar model (multi-account setup etc.).

@Stefan Tomm, we have TF code that will create an account and all the needed security / rules in it. Having said that, our accounts are pretty static and we deploy multiple services in them so that might not be the exact use case you’re looking for.

Thanks @Philipp Bussche for the detailed response! What i am actually wondering is that building a landing zone seems like a super big and complex topic to apply at your company. And that can actually result in slowing down or even completely abandoning the cloud adoption at many companies. For sure, big enterprises like big banks with tough governance requirements really need to put a lot of effort into building their landing zone. But i think there are also many companies out there who could live with an opinionated landing zone setup that ist just sufficient for them and not highly customized. Do you think for that case AWS Control Tower (regarding implementation perhaps done via AFT) or Azure landing zone accelerator (https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/implementation-options#azure-landing-zone-accelerator-approach) solve the problem for them and they can get a working landing zone in place within a few days? Or do you have the experience that actually all companies have to put several months into building their custom landing zone?

Hi again. If your company is happy with what Azure or AWS or GCP would recommend as a default setup then you can grab the infrastructure code they have prepared, run it and you are (almost) done. There are some companies however who like to customize and with them you typically spend more time then. Regardless of the size of the company I would however always recommend to go with a multi-account/subscription setup where you seperate some of the concerns.

@Stefan Tomm This is by request since account creation happens infrequently. But inside the accounts we trigger TF code constantly to deploy changes as needed. We found that GitHub actions on PRs work well for this, but you can trigger the run from pretty much everywhere that has the permissions.

Thanks Philipp, i am totally with you regarding the multi-account setup. And i do see that the hybrid networking is a special challenge and always requires some custom effort. For now i would have one last question. We at meshcloud are not only setting up our own landing zones at the moment, but we are also thinking about whether there is something we can provide that simplifies landing zone setup. To me it seems like at least AWS and Azure (and most likely also GCP) provide some great opinionated ready-to-go landing zones you can easily start with and evolve further over time. But is there some tedious, repetitive work that must be done at multiple customers and you are actually missing some tooling around that could simplify this work?

Here in Pismo, we use Terraform to launch new environments. Everything is built using modules and can be mounted depending on requirements, contracts, and clients. We decoupled in three different levels: AWS Infrastructure (aka network), AWS EKS (Kubernetes with all platform services, production-ready), and finally the installation of APIs, the last part depends on the Engineering team because they manage the role lifecycle of APIs (you build it, you run it).

Hi @Fortunato. This also sounds like a great automation you have applied at Pismo. So if a team at your company wants an AWS account that is pre-configured to support a compliant multi-region setup it takes 5 days to set it up? Where is this time actually spent? Getting input from the customer on how to individualize this setup? Or does execution of the automation take that long? Is there anything missing for you or does Terraform + AWS AFT provide everything you need to make your platform team and your customers happy?

Hi @Stefan Tomm, internally we serve the platform as a product.. the engineering team just consumes the resources, they don’t need to know where they are running (VPCs, network, connectivity, etc.) their goal is just to take care of the apis. We divided the SRE team in different teams: SRE-DevOps: • CI/CD • Automations • Toil • Observability SRE/Platform: • Cloud Providers • Network • Kubernetes • Istio SRE/DBA: • Databases