This message was deleted.

The mission of my platform is for hospitality so I tried not to provide any choices. Might be rare and odd. If they don't like it the developer or architects can use one of the VMs to build it all yourself if you want.

How do you typically go about making this available to developers?

A collection of repositories that I call service templates that provide out of the box “hello” world examples that include CI/CD pipeline. The example can be extended to customize AMI, docker container. It includes how to manage secrets, config, etc… To get a new project off the ground in the right direction that can push all the way to “stage” you just clone a repo and follow the steps to initialize the project. For each language (node.js, python, etc…) and each deployment target (serverless, or fargate or EKS) we have an example repo to clone from. This is just one example.

Same we have git repos as service templates which teams can clone. We are working towards scaffolded templates using some tools in Backstage

Thank you @Chris Burton and @Andre Marcelo-Tanner! A further question: how do developers get infrastructure in your use cases? Is there a central tool, or do they create it themselves?

We have been using Terraform and modules and templates since we were small but now that we are 100+ Engineers it really poorly scales and were looking to centralize this, maybe still in Terraform but we're not sure yet. What we do know is that making every engineer do Terraform like a Pro is not scalable We have SOC2, HIPAA etc compliance reqs too

Yeah, that makes sense. How do you envision the centralization? Would you want to abstract Terraform away? Or rather provide some Higher level “large” modules that contain all the resource for a particular architecture?

Could this be helpful? https://docs.sourcegraph.com/notebooks

@Rafa Alvarez As @Andre Marcelo-Tanner mentioned sometimes regulatory constraints can be a factor. For each organization the right answer can be different. In my current situation where engineering team owns almost the whole stack. They can request new accounts and use the service catalog (built with terraform/terragrunt) which covers 90% of their use cases with patterns for hosting serverless, containers, static sites, APIs. In other organizations we had regulatory separation of duties where teams didn’t have as much control over production but had a dev sandbox and worked with SRE team which had established patterns and SLAs for various requests. One option with terraform is to create production grade modules and reference architecture example (gruntwork.io) that allows for fast templating with built in production readiness. I highly recommend you at least check out the gruntwork.io service catalog and infrastructure catalog approach if using terraform. Using this approach has created a situation in which teams write very little terraform and benefit greatly from re-usability. In this the teams learn to re-use the service catalog modules that have built-in guardrails for production readiness. (for example it is impossible to deploy a database to a public subnet). This helps because they just need to learn the service catalog and not all of terraform. There is no value in everyone creating boilerplate things like production VPC in terraform from scratch every time. You might want to check out spacelift.io (I haven’t used it but hear great things) We run services to scan code and environments for security issues (such as orca, and other security services that route findings directly to team responsible). This allow us to provide teams more responsibility while maintaining security. Hope some of this info helps 🙂

Wow @Chris Burton thanks! This is amazing detail. And, yes, we’ve been looking at spacelift.io! They are indeed very exciting

Glad it helps 🙂