[colomofo]

I've built infra for a lot of different orgs over a long period of time. My recommendation is that unless (and until) you're building for scale, you Keep It Simple, Stupid (KISS).

Use an IaC system (Terraform, Pulumi, etc) to manage everything from Day 1:

1. Use a major cloud provider (AWS or GCP, probably)

2. Get a managed HTTP load balancer (ELB, ALB, whatever)

3. Package your app in a container image, and run your app on 3+ containers behind the load balancer (using on bare VMs, K8S, whatever you prefer), ideally at least 2x containers in 2x AZs.

4. Set up a managed database cluster with Postgres or MySQL and run it with multi-AZ and failover

5. Run 2x VM instances (for redundancy) for asynchronous jobs (using a message bus service or using your database as a work queue), ideally 1x in each of the AZs your database is in

6. Store any large files in cloud storage and put them behind a CDN

That's all 99% of companies will ever need to do. These are all old technologies that Just Work.

[atmosx]

I've worked with quite a few small teams in the past, part time. Never had a fleet as small as 2 VMs, more like 20-120. That's a good summary. Only thing missing that comes up always is the CI/CD workflow. I've found bitbucket's CD surprisingly _good_ once you follow the enforced pattern, especially for small teams who don't want to spent too much on release technicalities.

Then there's more nuanced things that most teams will miss early on without someone pointing the problem and the solution e.g. decouple configuration from the app, design stateless apps (e.g. 12 factor app), use secrets management easily (e.g. dynamoDB based solutions like credstash are dirt cheap, AWS secrets is okay-ish), used managed DBs (RDS is the most common choice) and more.

[aprdm]

really ? Wow.. I've never had 120 VMs to manage in any org I was part of, and have worked on fortune 500 companies !

I have provided infrastructure-as-a-service for many many baremetal/VMS/containers, but then I wasn't managing them (e.g: it was many small team's infra, not a small team of 10 people using 20-120 VMs as per OP)

[atmosx]

That didn’t come out well - by VMs I mean EKS or Swarm nodes not VMs in term of “pet” not “cattle” :-)

The number of nodes was used to run a monolith. Same deployments and all, wasn’t as complicated as it might sound (terraform to manage infra, few custom apps to talk to external APIs, etc)

These were definitely not 500 fortune companies but AFAIK all of them had some cash flow or were acquired by behemoths.

[tkiolp4]

How does a deployment look like in that setup?

[colomofo]

It depends how you deploy the app containers.

If you use a container orchestration service (ECS, GKE) then you use that system to upgrade container image with new app versions.

If you use autoscaling groups / managed instance groups, then you use that to replace VMs with new ones running containers with the new app image.

Using rolling updates, the load balancer drains connections to a container and then it is replaced.

Ideally this is done using your IaC system. So a deployment just involves changing the container image (app version) and applying the update.

[mrngilles]

I would like to have some insights about this as well

[nip]

Excellent comment and suggestion!

Very refreshing to read in this day and age where it’s not uncommon to have more micro services than paying customers.

[skor]

any reliable managed database cluster suggestions? I’m looking for mariadb or mysql, former preferred thanks

[colomofo]

Cloud SQL from GCP or RDS from AWS should both work just fine. They're just about the only companies I trust managed databases from.

[skor]

thanks