It’s not about seams in 2d but 3d curved surfaces.
OpenCascade’s kernel forces you to deal with periodicity in topology (the shape structure), while Parasolid handles it in geometry (the math). A cylinder is mathematically continuous because there's no actual "seam" where it starts and ends. But in OpenCascade there’s a seam from 0 to 2π and this seam edge becomes a real topological entity that every algorithm has to deal with.
In Parasolid the cylinder is periodic so when you query a point at U=2.1π, the kernel just knows that's equivalent to U=0.1π. The periodicity is a property of the surface math, not the shape structure. It’s not using polygons/edges/vertexes but a system of equations to calculate the surfaces.
This is why boolean ops fail so often in FreeCAD: it’s asking the kernel to intersect with an artificial edge that shouldn't exist. The seam creates edge cases in intersection calculations, makes filleting near seams a nightmare, and complicates things. Parasolid's implicit handling requires smarter surface evaluation code upfront, but then everything else just works.
Be the first hire, working with me, combining LLMs, geometry, and manufacturing in a high-agency, high-trust environment. You’ll have significant ownership over your work, freedom to experiment, and direct influence on the direction of the product.
A wide range of technologies to work with: vllm / React / Postgres / CGAL / OpenCASCADE / Eigen / express
I am about to start a project. I know I want an event sourced architecture. That is, the system is designed around a queue, all actors push/pull into the queue. This article gives me some pause.
Performance isn't a big deal for me. I had assumed that Kafka would give me things like decoupling, retry, dead-lettering, logging, schema validation, schema versioning, exactly once processing.
I like Postgres, and obviously I can write a queue ontop of it, but it seems like quite a lot of effort?
Kafka also doesn't give you all those things. E.g. there is no automatic dead-lettering, so a consumer that throws an exception will endlessly retry and block all progress on that partition. Kafka only stores bytes, so schema is up to you. Exactly-once is good, but there are some caveats (you have to use kafka transactions, which are significantly different than normal operation, and any external system may observe at-least-once semantics instead). Similar exactly-once semantics would also be trivial in an RDBMS (i.e. produce and consume in same transaction).
If you plan on retaining your topics indefinitely, schema evolution can become painful since you can't update existing records. Changing the number of partitions in a topic is also painful, and choosing the number initially is a difficult choice. You might want to build your own infrastructure for rewriting a topic and directing new writes to the new topic without duplication.
Kafka isn't really a replacement for a database or anything high-level like a ledger. It's really a replicated log, which is a low-level primitive that will take significant work to build into something else.
(and possibly Flink/RisingWave/Arroyo somewhere in order to do some alerting/incrementally updated materialized views/ etc)
this seems "simple enough" (but I don't have any experience with Redpanda) but is indeed one more moving part compared to MQTT -> Postgres (as a queue) -> Postgres/Timescaledb + S3
Questions:
1. my "fear" would be that if I use the same Postgres for the queue and for my business database, the "message ingestion" part could block the "business" part sometimes (locks, etc)? Also perhaps when I want to update the schema of my database and not "stop" the inflow of messages, not sure if this would be easy?
2. also that since it would write messages in the queue and then delete them, there would be a lot of GC/Vacuuming to do, compared to my business database which is mostly append-only?
3. and if I split the "Postgres queue" from "Postgres database" as two different processes, of course I have "one less tech to learn", but I still have to get used to pgmq, integrate it, etc, is that really much easier than adding Redpanda?
4. I guess most Postgres queues are also "simple" and don't provide "fanout" for multiple things (eg I want to take one of my IoT message, clean it up, store it in my timescaledb, and also archive it to S3, and also run an alert detector on it, etc)
if you need a durable log (which it sounds like you do for if you're going with event sourcing) that has those features, i'd suggest apache pulsar. you effectively get streams with message queue semantics (per-message acks, retries, dlq, etc.) from one system. it supports many different 'subscription types', so you can use it for a bunch of different use cases. running it on your own is a bit of a beast though and there's really only one hosted provider in the game (streamnative)
note that kafka has recently started investing into 'queues' in KIP-932, but they're still a long way off from implementing all of those features.
A standalone Pulsar, is actually a great way to learn Pulsar. It is one command to get started: bin/pulsar standalone
It can also be used in production. You do not have to build a distributed Pulsar cluster immediately. I have multiple projects running on a standalone Pulsar cluster, because its easy to setup and requires almost no maintenance. Doing it that way makes compliance requirements for isolation simpler and with less fights. Everyone understands host/vm isolation, few understand Pulsar Tenant isolation.
If you want a distributed Apache Pulsar cluster, be prepared to work for that. We run a cluster on bare metal. We considered Kubernetes, but performance was lacking. We are not Kubernetes experts.
If you build it right, the underlying storage engine for your event stream should be swappable for any other event stream tech. Could be SQLite, PSQL, Kafka, Kinesis, SQS, Rabbit, Redis ... really anything can serve this need. The right tool will appear once you dial in your architecture. Treat storage as a black box API that has "push", "pop" etc commands. When your initial engine falls over, switch to a new one and expose that same API.
The bigger question to ask is: will this storage engine be used to persist and retain data forever (like a database) or will it be used more for temporary transit of data from one spot to another.
I think my system is sort of both. I want to put some events in a queue for a finite set of time, process them as a single consolidated set, and then drop them all from the queue.
> I had assumed that Kafka would give me things like decoupling, retry, dead-lettering, logging, schema validation, schema versioning, exactly once processing.
One thing I learned with Kafka and Cassandra is that you are locked in to a design pretty early on. Then the business changes their mind and it take a great deal of re-work and then they're accusing you of being incompetent because they are used to SQL projects that have way more flexibility.
Perhaps I do. I know that I don't want a system defined as a graph in yaml. Or no code. These options are over engineered for my use case. I'm pretty comfortable building some docker containers and operating them and this is the approach I want to use.
If what you want is a queue, Kafka might be overkill for your needs. It's a great tool, but it definitely has a lot of complexity relative to a straightforward queue system.
>You should engage with the arguments the other side makes.
The arguments are "Protect the children.", "Catch terrorists.", "Catch criminals.".
Those arguments have been engaged with for decades. They are purely emotional arguments. Anyone who still pushes those arguments forth is most likely doing so with ulterior motives and cannot be reasonably "engaged" with.
For what its worth the anti-encryption/anti-privacy laws have caught terrorists in the UK. My company provides data storage for their dragnet and handles various requests and Ive seen first hand 4 different instances where the UK gov watching everyones internet activity led to terrorists being caught.
This number by itself means nothing as the other variables are unknown.
How many terrorists were not caught by these systems?
How many would have actually done these actions instead of just talking about it? How many could have been caught with just standard police work?
Without knowing these variables then there is no way to say if these systems are particularly good at catching terrorists.
I wouldnt go as far as saying it means nothing, but I agree that the story certainly isnt simple. Was just pointing out that "catch terrorists" isnt a purely emotional argument. Would the terrorists be caught anyway? We'll never know, but theres no way you can say they would for certain. Personally I dont think catching a few terrorists is worth giving up privacy but other people disagree.
> Without knowing these variables then there is no way to say if these systems are particularly good at catching terrorists.
I dont think we can ever figure this out since no one is willing to run an rct when it comes to counter terrorism
> anti-encryption/anti-privacy laws have caught terrorists
This is undoubtedly so; but much turns on the trust in government. In this U.S., the president, himself a documented profligate liar, just invited an equally untrustworthy unelected person into the halls of government to vacuum up whatever data he pleased. Maybe trust in the UK government is higher.
Collecting data is often not the problem. The problem is how to evaluate it and use it to direct the use of finite law enforcement or counterintelligence resources.
But to your point, let's not forget congressional republicans rushing a SKIF on capitol hill with their mobile devices out in clear violation of policy (and common sense.) I am relieved by the fact that Trump and Musk do not seem to understand what they can use sensitive information for (other than perhaps to sell or give away to foreign governments and businesses.)
I think my point is good intelligence comes from stitching together numerous data points and often traffic analysis is as good (or better) than content analysis. And maybe that the overwhelming majority of elected officials have no conception of how intelligence is collected and evaluated.
Low hanging fruit. The smart ones likely aren't being caught now.
Moreover, it's only a matter of time until the criminal fraternity all catch up and are on the same wavelength. That's when all but the dumbest know exactly what not to do or say on the net.
The Internet is still comparatively young and like everyone else those who've evil intent are still learning exactly how it works. I'd bet money that it won't be long before a 'bestseller tome' of definitive what-not-to-dos cirulates amongst this mob.
The question is at what level will law enforcement's catch have to fall before it has to turn to other methods.
Let's not ignore the full history here. That is a bad faith argument. It was a crime to use expensive encryption 30 years ago, but a lot of decisions were made to allow it. Today, every single one of those old caveats about child porn, drugs, money laundering, terrorism, (both domestic and international) and criminal acts in general all have stories where weaker encryption would have saved hundreds and hundreds of lives. We have to recognize this or we're just arguing past each other.
I'm not sure how this is answers my question at all.
How many whistleblowers would have been killed without a secure way to blow the whistle? How many journalists and journalist sources would have been killed? Etc. These people aren't using the USPS for good reason.
Point being, you are only doing one side of your calculation and presenting it as a full argument. But it's just a bad argument unless you calculate both sides.
That's a different question. You asked how many people would have been harmed if weaker/no encryption was the standard. The USPS is a message system where federal employees are able to intercept suspicious content, and there is no built-in encryption for mail. Voting by mail is a great example of how a critical message can be sent without relying on encryption. Whistleblowers can still encrypt documents on a flash drive, and drop it into a mailbox. There is nothing stopping them from doing so.
I don't really want to hash this same thing out for the... At least hundredth time. You're not going to convince me, I'm not going to convince you, and we'll both just leave less happy if we keep going.
>Whistleblowers can still encrypt documents on a flash drive, and drop it into a mailbox. There is nothing stopping them from doing so.
The only thing I want to highlight for your consideration is that the USA is not the entire world. The USPS, even if it were perfect, does not exist in the overwhelming majority of the world. People talk to people across borders.
(Also, with some of the proposed laws, encrypting the USB would be illegal)
And no service offering encryption has existed since 1755? Because that is required for your argument. Otherwise you simply send unimportant stuff via USPS and sensitive/secret/important stuff via non-USPS.
My vote, my taxes, my REAL-ID driver license, passport, credit cards, phone SIM, checks, 401k statements, etc. have very recently been sent via USPS. Do you consider this unimportant stuff?
A bit of a nit-pick. 30 years ago was 1995. It was not a crime to use PGP in the US in 1995. What PKZ was charged with was exporting the encryption technology (or allowing it to export itself by putting the code on an anonymous FTP server.) The Bernstein case was similar in that it was the export of the machine-readable code the government objected to, not it's domestic distribution. The right for researchers to publish text describing algorithms had earlier been recognized by the court (which is why Martin Gardner could describe the RSA cryptosystem in Scientific American in 1977.)
>> You should engage with the arguments the other side makes.
> The arguments are "Protect the children.", "Catch terrorists.", "Catch criminals.".
> Those arguments have been engaged with for decades. They are purely emotional arguments. Anyone who still pushes those arguments forth is most likely doing so with ulterior motives and cannot be reasonably "engaged" with.
Oh come on. Why do you think a "purely emotional arguments" are illegitimate? Are you some galaxy brain, coldly observing humanity from some ivory tower constructed of pure software?
Nearly all positions people take are, at their core, "emotional." And the disagreements that result in "arguments" are often really about differing values and priorities. You might value your "freedom" more than anything and are willing to tolerate a lot of bad stuff to preserve strong encryption, some other guy might be so bothered by child sexual abuse that he wants to give it no encrypted corner to hide in. You're both being emotional.
Those are both reasoned arguments. The emotional argument would be "some guy is so bothered by sexual abuse he wants to ban lightbulbs because once he heard about a lightbulb in the context of an abuse". The "solution" is not really a solution, but the emotional person does not really care about solutions, he's too emotional to think straight.
>The the GP was using "emotional" to dismiss the kind of arguments
I'm dismissing arguments that are designed to appeal to (and manipulate) the emotions of the person listening. Such as the three examples I gave, which are, in almost every case, used to win an argument without having to consider any possible nuance of the situation.
Often, it's a completely thought-stopping appeal, because everything is simply countered with "so you don't care about children". Or, in your case, subtlety alluding to me being tolerant of CSAM (which was wildly inappropriate, albeit a great example of why I generally just don't talk to people who use those types of arguments).
Apparently that makes me galaxy-brained or whatever, though. ¯\_(ツ)_/¯.
> I'm dismissing arguments that are designed to appeal to (and manipulate) the emotions of the person listening.
My point is that's pretty much all arguments, except maybe some very obtuse ones no one really cares about.
> Or, in your case, subtlety alluding to me being tolerant of CSAM (which was wildly inappropriate, albeit a great example of why I generally just don't talk to people who use those types of arguments).
That's not what I was doing. I was giving an example to show it's a trade-off driven by priorities and values. But if you want to be super-logical about it, supporting strong privacy-preserving uses of encryption necessarily implies a certain level of tolerance for CSAM, unless you support other draconian measures that are incompatible with privacy. Privacy can be used for good and bad.
>My point is that's pretty much all arguments, except maybe some very obtuse ones no one really cares about.
There is a distinct difference between a person having emotions while arguing, and using an appeal to emotion as a rhetorical tactic. I do not agree that "pretty much all arguments" contain an appeal to emotion (again, as a purposeful fallacious rhetorical tactic), even though all arguments obviously will have people feeling some sort of emotion.
Even looking through this entire thread, most of the disagreements here do not contain appeals to emotions.
I'm sure that any book on logic and rhetoric from the last few centuries would explain it better than I can. The wiki page has some good explanations and examples as well.
> Clearly the pressure on government to write these laws is coming from somewhere
Software surveillance vendors.
> Chat control: EU Ombudsman criticises revolving door between Europol and chat control tech lobbyist Thorn
> Breyer welcomes the outcome: “When a former Europol employee sells their internal knowledge and contacts for the purpose of lobbying personally known EU Commission staff, this is exactly what must be prevented. Since the revelation of ‘Chatcontrol-Gate,’ we know that the EU’s chat control proposal is ultimately a product of lobbying by an international surveillance-industrial complex. To ensure this never happens again, the surveillance lobbying swamp must be drained.”
The problem is LEOs (and associated industry) claiming that enforcement is impossible without the ability to obtain cleartext.
This is a lie: obtaining cleartext just makes enforcement vastly easier and more scalable. If crims have encrypted mobile phones, you can still point a microphone at them.
Honestly, I had always assumed LEO wanted access to decrypted message content so they could sell it to advertisers. I mean sure, you could catch a criminal or two, but with all that non-criminal data, just imagine how much off-the-books revenue you could accrue by selling it to the AdWords guys.
The other side being, for instance, the surveillance lobby that pushes for chat control laws in the EU? The "arguments the other side makes" are pretty clear at this point, and nothing to do with the "think about the kids" really, not sure engaging with them is the point.
> Something is a crime if society determines that it should be so. Nothing more.
According to The New Oxford Companion to Law, the term crime does not, in modern criminal law, have any simple and universally accepted definition.
Society also determined it was ok to use a firehose on black people, so I think the best we can say is that the term Crime has nothing to do with Morality, and people who conflate the two need to be looked at with suspicion.
> You should engage with the arguments the other side makes.
I don't. I think most arguments about crime require one-side to act in bad-faith. After all: The author doesn't actually mean that Encryption isn't illegal in some jurisdictions, they mean that it shouldn't be. You know this. I know this. And yet you really think someone needs your tautological definition of crime? I don't believe you.
The arguments are mostly that they dislike what can be accomplished via math. “The laws of mathematics are very commendable, but the only law that applies in Australia is the law of Australia” isn't exactly an 'argument' so much as an insistence.
The article does address the flaws in some of their arguments (encryption inconveniences law enforcement, think of the children) by pointing out that the average person and children are kept save from criminal elements by encryption.
The arguments from the other side are of the "think of the children" and "tough on crime" variety. They are purely emotional and if you try to dispute them they just respond with "so you don't care about children?". It's like trying to argue with a religious person on matters of faith, you're just not very likely to convince them.
I called the ICO a few years ago asking how to comply with an ex-employee GDPR data request for access to their emails. Their recommendation: read them all to determine which contained personal data.
When I told them I (as a 5 person business) obviously don't have time to go through 1000s of old emails they reacted with surprise to the amount of emails. I guess they don't send many. They didn't offer any other solution.
As others have mentioned this org is a tax on all UK business.
Yeah, this. The easiest way to comply with the GDPR is not to store personal data. The second easiest is to delete it as soon as it is no longer required (this includes from backups!)
Do you actually want those emails to be unearthed during a lawsuit 5 years from now?
At least one firm I worked with had a mandatory 180-day delete of any correspondence not specifically tagged for archival, and the stated reason was to prevent all their random conversations being exposed during discovery if they were prosecuted.
I long for a US-like entrepreneurial attitude here in the UK. Business people here think that they are playing zero sum games. Everyone looks to the govt for funding and direction.
I am reflecting on Deepmind. This company saw the AI revolution before anyone else. London based. They did an amazing job. Sold to Google. The problem is that long term the growth and money now goes back to the US. Maybe the UK is just too small to produce world leading companies.
The UK already has world-leading companies (as do many smaller countries), but it's very very hard to produce planet-scale wide-appeal consumer companies dur to market size. Even if it does happen, the temptation to appeal more and more to the US market is irresistable.
I'm sure it's not nothing, but to what extent does it matter that Alphabet is headquartered in the US? Deepmind seems to still be based in Kings Cross - and London benefits.
> I can't see how it can take 4 months to figure it out.
Well have you ever tried moving a company with a dozen services onto kubernetes piece-by-piece, with zero downtime? How long would it take you to correctly move and test every permission, environment variable, and issue you run into?
Then if you get a single setting wrong (e.g. memory size) and don't load-test with realistic traffic, you bring down production, potentially lose customers, and have to do a public post-mortem about your mistakes? [true story for current employer]
I don't see how anybody says they'd move a large company to kubernetes in such an environment in a few months with no screwups and solid testing.
Took us three-four years to go from self hosted multi-dc to getting the main product almost fully in k8s (some parts didn't make sense in k8s and was pushed to our geo-distributed edge nodes). Dozens of services and teams and keeping the old stuff working while changing the tire on the car while driving. All while the company continues to grow and scale doubles every year or so. It takes maturity in testing and monitoring and it takes longer that everyone estimates
It sounds like it's not easy to figure out the permissions, envvars, memory size, etc. of your existing system, and that's why the migration is so difficult? That's not really one of Kubernetes' (many) failings.
Yes, and now we are back at the ancestor comment’s original point: “at the end of the day kubernetes feels like complexity trying to abstract over complexity, and often I find that's less successful that removing complexity in the first place”
Which I understand to mean “some people think using Kubernetes will make managing a system easier, but it often will not do that”
It's good you asked, but I'm not ready to answer it in a useful way. It depends entirely on your use cases.
Some un-nuanced observations as starting points:
- Helm sucks, but so does Kustomize
- Cluster networking and security is annoying to set up
- Observability is awkward. Some things aren't exposed as cluster metrics/events, so you need to look at, say, service and pod state. It's not easy to see, e.g. how many times your app OOMed in the last hour.
- There's a lot of complexity you can avoid for a while, but eventually some "simple" use case will only be solvable that way, and now you're doing service meshes.
Maybe "wrong" is the wrong word, but there are spots that feel overkill, and spots that feel immature.
I'd argue that Kustomize is the bee's knees but editor support for it sucks (or, I'd also accept that the docs suck, and/or are missing a bazillion examples so us mere mortals could enlighten ourselves to what all nouns and verbs are supported in the damn thing)
> how many times your app OOMed in the last hour.
heh, I'd love to hear those "shell scripts are all I need" folks chime in on how they'd get metrics for such a thing :-D (or Nomad, for that matter)
That said, one of the other common themes in this discussion is how Kubernetes jams people up because there are a bazillion ways of doing anything, with wildly differing levels of "it just works" versus "someone's promo packet that was abandoned". Monitoring falls squarely in the bazillion-ways category, in that it for sure does not come batteries included but there are a lot of cool toys if one has the cluster headroom to install them
It largely depends how customized each microservice is, and how many people are working on this project.
I've seen migrations of thousands of microservices happening with the span of two years. Longer timeline, yes, but the number of microservices is orders of magnitude larger.
Though I suppose the organization works differently at this level. The Kubernetes team build a tool to migrate the microservices, and each owner was asked to perform the migration themselves. Small microservices could be migrated in less than three days, while the large and risk-critical ones took a couple weeks. This all happened in less than two years, but it took more than that in terms of engineer/weeks.
The project was very successful though. The company spends way less money now because of the autoscaling features, and the ability to run multiple microservices in the same node.
Regardless, if the company is running 12 microservices and this number is expected to grow, this is probably a good time to migrate. How did they account for the different shape of services (stateful, stateless, leader elected, cron, etc), networking settings, styles of deployment (blue-green, rolling updates, etc), secret management, load testing, bug bashing, gradual rollouts, dockerizing the containers, etc? If it's taking 4x longer than originally anticipated, it seems like there was a massive failure in project design.
2000 products sounds like you made 2000 engineers learn kubernetes (a week, optimistically, 2000/52 = 38 engineer years, or roughly one wasted career).
Similarly, the actual migration times you estimate add up to decades of engineer time.
It’s possible kubernetes saves more time than using the alternative costs, but that definitely wasn’t the case at my previous two jobs. The jury is out at the current job.
I see the opportunity cost of this stuff every day at work, and am patiently waiting for a replacement.
> 2000 products sounds like you made 2000 engineers learn kubernetes (a week, optimistically, 2000/52 = 38 engineer years, or roughly one wasted career).
Learning k8s enough to be able to work with it isn't that hard. Have a centralized team write up a decent template for a CI/CD pipeline, Dockerfile for the most common stacks you use and a Helm chart with an example for a Deployment, PersistentVolumeClaim, Service and Ingress, distribute that, and be available for support should the need for Kubernetes be beyond "we need 1-N pods for this service, they got some environment variables from which they are configured, and maybe a Secret/ConfigMap if the application rather wants configuration to be done in files" is enough in my experience.
For sure but that's the job of a good ops department - where I work at for example, every project's CI/CD pipeline has its own IAM user mapping to a Kubernetes role that only has explicitly defined capabilities: create, modify and delete just the utter basics. Even if they'd commit something into the Helm chart that could cause an annoyance, the service account wouldn't be able to call the required APIs. And the templates themselves come with security built-in - privileges are all explicitly dropped, pod UIDs/GIDs hardcoded to non-root, and we're deploying Network Policies at least for ingress as well now. Only egress network policies aren't available, we haven't been able to make these work with services.
Anyone wishing to do stuff like use the RDS database provisioner gets an introduction from us on how to use it and what the pitfalls are, and regular reviews of their code. They're flexible but we keep tabs on what they're doing, and when they have done something useful we aren't shy from integrating whatever they have done to our shared template repository.
> 2000 products sounds like you made 2000 engineers learn kubernetes (a week, optimistically, 2000/52 = 38 engineer years, or roughly one wasted career).
Not really, they only had to use the tool to run the migration and then validate that it worked properly. As the other commenter said, a very basic setup for kubernetes is not that hard; the difficult set up is left to the devops team, while the service owners just need to see the basics.
But sure, we can estimate it at 38 engineering years. That's still 38 years for 2,000 microservices; it's way better than 1 year for 12 microservices like in OP's case. Savings that we got was enough to offset these 38 years of work, so this project is now paying dividends.
Comparing the simplicity of two PHP servers against a setup with a dozen services is always going to be one sided. The difference in complexity alone is massive, regardless of whether you use k8s or not.
My current employer did something similar, but with fewer services. The upshot is that with terraform and helm and all the other yaml files defining our cluster, we have test environments on demand, and our uptime is 100x better.
Memory size is an interesting example. A typical Kubernetes deployment has much more control over this than a typical non-container setup. It is costing you to figure out the right setting but in the long term you are rewarded with a more robust and more re-deployable application.
> I don't see how anybody says they'd move a large company to kubernetes in such an environment in a few months with no screwups and solid testing.
Unfortunately, I do. Somebody says that when the culture of the organization expects to be told and hear what they want to hear rather than the cold hard truth. And likely the person saying that says it from a perch up high and not responsible for the day to day work of actually implementing the change. I see this happen when the person, management/leadership, lacks the skills and knowledge to perform the work themselves. They've never been in the trenches and had to actually deal face to face with the devil in the details.
Canary deploy dude (or dude-ette), route 0.001% of service traffic and then slowly move it over. Then set error budgets. Then a bad service wont "bring down production".
Thats how we did it at Google (I was part of the core team responsible for ad serving infra - billions of ads to billions of users a day)
Using microk8s or k3s on one node works fine. As the author of "one big server," I am now working on an application that needs some GPUs and needs to be able to deploy on customer hardware, so k8s is natural. Our own hosted product runs on 2 servers, but it's ~10 containers (including databases, etc).
Yup, I like this approach a lot. With cloud providers considering VMs durable these days (they get new hardware for your VM if the hardware it's on dies, without dropping any TCP connections), I think a 1 node approach is enough for small things. You can get like 192 vCPUs per node. This is enough for a lot of small companies.
I occasionally try non-k8s approaches to see what I'm missing. I have a small ARM machine that runs Home Assistant and some other stuff. My first instinct was to run k8s (probably kind honestly), but didn't really want to write a bunch of manifests and let myself scope creep to running ArgoCD. I decided on `podman generate systemd` instead (with nightly re-pulls of the "latest" tag; I live and die by the bleeding edge). This was OK, until I added zwavejs, and now the versions sometimes get out of sync, which I notice by a certain light switch not working anymore. What I should have done instead was have some sort of git repository where I have the versions of these two things, and to update them atomically both at the exact same time. Oh wow, I really did need ArgoCD and Kubernetes ;)
I get by with podman by angrily ssh-ing in in my winter jacket when I'm trying to leave my house but can't turn the lights off. Maybe this can be blamed on auto-updates, but frankly anything exposed to a network that is out of date is also a risk, so, I don't think you can ever really win.
