7 ms·
Ask HN: Infra people in small companies, what does your infra look like?
Hi all !
I'm just wondering how an infra would look like in a small company, with 1 person dedicated to the infra, and around 10 devs working on a monolith.
I'm guessing that a lot of people will have a lot of different opinions. Just how many possibilities could we see there ? And how would those impact the business and the devs job ?
- iamflimflam1 3y agoOften what you end up will have been driven by the founder CTO or first technical hire. And it will be whatever they had most familiarity/experience with. For a monolith and size you are talking about a sensible approach would be pretty minimal infra. The app would be hosted on a managed service (e.g cloud run, elastic beanstalk, app engine etc…) along with some kind of managed database service. You might also see a kubernetes cluster being used - generally happens if that’s what the original devs knew. Adventurous places may have the monolith deployed on serverless which can be pretty cost effective. Heroku like services are also still popular. In my previous place we had the monolith on cloud run. Anything more complex than the above would to me be a bad smell - unless there were some very good reasons.
- mrngilles 3y ago> In my previous place we had the monolith on cloud run. How was managed a new deployment ? Could anyone push a new version ? Did it go through CI/CD ? And about CI/CD, did you have something vaguely resembling it ? Was it all hosted ? > Anything more complex than the above would to me be a bad smell - unless there were some very good reasons. Yes, you would probably not need something more complex in that case, but then again, some companies with 5 devs start with microservices
- iamflimflam1 3y agoAll through CI/CD running on GitHub actions. There's really no excuse nowadays for not having good CI/CD processes. We could have used googles cloud build, but the team knew GitHub actions well.
- colomofo 3y agoI'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.
- alxmng 3y agoA $40/mo VPS. Caddy web server. Supervisor to restart automatically. Git to deploy. CI using GitHub actions which build, run tests, and push to server on success. Automatic VPS snapshots and a cronjob to backup the DB to cloud storage. DB runs on the same box. This has worked for years with practically zero maintenance.
- oops 3y ago> A $40/mo VPS. > This has worked for years with zero maintenance. Do you apply security updates, e.g. for Caddy, the OS, db, etc.?
- alxmng 3y agoYeah, every so often I spend 5 minutes and run apt upgrade. I don't think the DB has ever been upgraded because there's no reason to. It's not exposed to the Internet anyway.
- chatmasta 3y agoYour DB doesn't need to be connected to the internet for untrusted users to have a path for interacting with it. I assume your application sends queries to it, for example. And users give your application the parameters for those queries. And that's when things are working as expected. All it takes is for one of your non-DB services to be compromised, and an attacker can now connect to the DB on localhost. That's why it's best practice to put a secure password on your DB even if you only expect connections from local services. And yes, you should upgrade it too... or at least apply security patches.
- aprdm 3y agoDigital ocean with NGINX in a VM, web app in another and Postgres in another... will take you very far, just take backups and deploy all with ansible
- dyeje 3y agoWith 10 devs on a monolith, I probably wouldn’t dedicate anyone to infra. Use a PaaS like Render or Aptible, focus on shipping product.
- jamarty2 3y agoThe cheapest. In our case that’s a rack in a datacenter, a SAN, MAAS, VMs, terraform, and chef.
- comprev 3y agoAs simple as possible, provisioned via IaC, and backed up with clear documentation. Your replacement will thank you, and so will management for a smooth transition.