A zero-downtime migration to a single database server? Power fails, disks fail, even CPU fans sometimes fail and bring a single server to a halt. Somehow I would have expected at least a high-available database cluster with multiple machines for applications "serving hundreds of thousands of users".
The US seems like a pretty huge area for the number of people living there. Why do they need to build a data center 100m from a house, why not build it 1000m away?
Now we only need easy self-hosted Postgres clustering for HA. Postgres seems to need additional tooling. There is Patroni, which doesn't provide container images. There is Spilo, which provides Postgres images with Patroni, but they are not really maintained. There is a timescaledb-ha image with Patroni, but no documentation how to use it. It seems the only easy way for hosting a Postgres cluster is to use CloudNativePG, but that requires k8s.
It would be awesome to have easy clustering directly built-in. Similar to MongoDB, where you tell the primary instance to use a replica set, then simply connect two secondaries to primary, done.
From my point of view the real challenge comes when you want high availability and need to setup a Postgres cluster.
With MongoDB you simply create a replicaset and you are done.
When planing a Postgres cluster, you need to understand replication options, potentially deal with Patroni. Zalandos Docker Spilo image is not really maintained, the way to go seems CloudNativePG, but that requires k8s.
I still don’t understand why there is no easy built-in Postgres cluster solution.
> I don't understand why so many people are using [Cloudflare].
> "Let us handle all your internet traffic.. you can trust us.. []"
TLS does not help, when most Internet traffic is passed through a single entity, which by default will use an edge TLS certificate and re-encrypt all data passing through, so will have decrypted plain text visibility to all data transmitted.
It's not a k8s replacement. It's for the small dev team with no k8s experience. For people that might not use Docker Swarm because they see it's a pretty dead project. For people who think "everyone uses k8s", so we should, too.
I need to run on-prem, so managed k8s is not an option. Experts tells me I should have 2 FTE to run k8s, which I don't have. k8s has so many components, how should I debug that in case of issues without k8s experience? k8s APIs change continuously, how should I manage that without k8s experience?
It's not a k8s replacement. But I do see a sweet spot for such a solution. We still run Docker Swarm on 5 servers, no hyperscalers, no API changes expected ;-)
"Cold Storage" by American screenwriter David Koepp comes to mind, a comedy splatter novel. I don't usually read such books, but this one was funny and entertaining.
Sounds like the early days of the web, when cookies weren’t widely used.
User sessions were created with a URL query parameter, like `?sessionid=`, and every page would pick up the sessionid and include it in every link on the page.
Who are you, which legal jurisdiction is your company located in? What is your target group? Selling local or global? Every jurisdiction probably has different rules what needs to be included on an invoice.
If you serve the U.S., then you need to calculate all the different sales taxes for each state. If you serve the E.U., you need to create PDF with included standardized XML soon. Don't know about other continents.
I think invoices are not about quick and pretty anymore, but there is a lot more to consider. You should make it clear what you provide and for which target customer.
It could be a good thing to have a confirmed email in the database, in case a 3-letter-agency knocks on your door because of some highly illegal content on your site.