241–250 of 334 posts
It's probably fine, but reading about a single Postgres container in a Kubernetes cluster with backups to S3 gives me sweaty palms. I hope the author has fully tested their disaster recovery plan.
I use AWS RDS for the production DB :) The in-cluster Postgres is mainly for experiments or staging.
The author almost seems to apologize for having a django monolith. But it's worth realising that one purpose of code organisation in larger companies is to mirror the team organisation. That's a constraint on code that can interfere with the best technical architecture. You can do better with a monolith in a one-man team!
> one purpose of code organisation in larger companies is to mirror the team organisation. Sometimes, the organisational structure drives the code structure (Conway's law [0]). I've seen real world consequences of this, where the disconnected system stovepipes in a large organisation reflected the team structure of the organisation's purchasing function. The purchasing teams didn't speak to each other, so neither did…
The author almost seems to apologize for having a django monolith. But it's worth realising that one purpose of code organisation in larger companies is to mirror the team organisation. That's a constraint on code that can interfere with the best technical architecture. You can do better with a monolith in a one-man team!
> one purpose of code organisation in larger companies is to mirror the team organisation. Sometimes, the organisational structure drives the code structure (Conway's law [0]). I've seen real world consequences of this, where the disconnected system stovepipes in a large organisation reflected the team structure of the organisation's purchasing function. The purchasing teams didn't speak to each other, so neither did…
Earlier quoted context omitted.
Document everything in excruciating detail - I go so far as to record all the commands I run; and when complete o destroy the machine and start again (or use a separate system) and verify that I accurately recorded every step. You can add additional text about why you did certain things - and then store the data in a wiki or checked into git or similar so you can find it when you need it.
That's all great advice. What I find though is I don't do it enough for it not to change under me. Example: 1. Did a project on digital ocean, just ubuntu and node 2. Year later, Did a project using meteor, spent way too much time trying to get it all install with Vagrant (so all info from 1 was not useful) 3. Year later, Changed meteor setup to use docker ... so had to learn docker (so all info from 2 was not useful…
Earlier quoted context omitted.
If anything, vendor lock-in is consistently underblown .
The thing Ive learned is that a lot of people have both a vested interest and a sort of stockholm syndrome with vendors (cloud or otherwise). If you spent tons of time learning AWSs special tooling, you are going to see everything as a nail if you catch my drift. Ive seen a few particular users here spend many threads defending their choices despite the often very logical criticisms levied against the "cloud everythi…
For example?
Earlier quoted context omitted.
... a decade later: Real cloud vendor lock-in is when you have decades of code written against a [cloud vendor] and you're getting charged outrageous [cloud] rates and it would also cost a fortune migrate.[sic]
If anything, vendor lock-in is consistently underblown .
I am also a one-man SaaS (though not a successful one). The following tends to be my stack (on Google Cloud, if you will): - Cloud Run (serverless containers) - Cloud SQL (via proxy) - Cloud Monitoring & Logging (formerly Stackdriver) - Compute Engine (if necessary, e.g. websockets) - Cloud Build for GitOps (deploy on push) It's clean and simple (to me). Billing is in one place, nicely separated by projects. Monitori…
I am also a one-man SaaS (though not a successful one). The following tends to be my stack (on Google Cloud, if you will): - Cloud Run (serverless containers) - Cloud SQL (via proxy) - Cloud Monitoring & Logging (formerly Stackdriver) - Compute Engine (if necessary, e.g. websockets) - Cloud Build for GitOps (deploy on push) It's clean and simple (to me). Billing is in one place, nicely separated by projects. Monitori…
Are you happy with Cloud Monitoring? I ended up moving away from it. I find the UI to be too slow for the purpose it serves. I'm fine with a slow-ish app sometimes but not when I have to use it often and during incidents. I also had a few instances over the course of several years where policies seemed to have transparently broke because a system metric name changed. It's possible the issues were of my doing but I do…