God in the gnostic Logos sense: the all encompassing universe, the forces that act within it, so on.
In more current vernacular: do humans trade with the big bang? do humans trade with the expansion of the universe, and it's inevitable collapse back into the initial singularity?
I only drink when I fly. Not on trains, not on car rides, not socially, not alone in my home — only when I fly.
There is nothing to do in an airport or an airplane. It’s like solitary confinement. All you can do is eat, drink, maybe buy a shitty book from the local duty free shop, and wait out your sentence.
'There is nothing to do in an airport or an airplane.'
I get this, but I've also met some interesting people and sometimes found myself deep in honest conversation for hours at a time. I'm saying this as someone who is usually reserved to the point of being anti-social.
Whippersnapper, at one point HN was full of jolly, good fun, and filled with cracks and quips.
I quite like noduerme‘s writings, because it’s novel, raw, and most of all original. Pedantism for its own sake is not discussion — but noise. And most of all… he’s been here longer than you and still retains the original ethos of this platform (punk, create, disrupt — not curmudgeon, consume, and conform).
Name-calling, appeal to seniority, and nostalgic callbacks aren't deepening the conversation much; or likely to win anyone over.
FWIW I do appreciate hearing from another perspective. And didn't think this was a forum encouraging punk, cracks, quips, and raw thoughts. Perhaps the commenting guidelines have become to 'square' as the kids say.
A startup that outgrows an EC2 server will be making enough money to hire more people to scale the system properly than what was initially designed: trading away everything for development velocity.
Kubernetes is not the right tool for this startup. Kubernetes is what large, old-school non-tech companies use to orchestrate resources, because it’s easier to find someone that “knows k8s” (no one knows k8s unless they’re consulting) than it is to find someone that can build properly distributed systems (in the eyes of whoever is in charge of hiring).
Most startups are at least going to want to be able to deploy, scale up or down, and restart an app without downtime. I wouldn't say that's overkill.
While it's not impossible to do with a single instance, you can spend a lot of time shaving that yak. It's reasonable to pay a bit more to have that stuff handled for you in a robust way.
These reasons related to deployment, but there's also lots of value in the security aspects of the control plane.
* automatic service account for each workload
* automatic service to service auth to 3rd party services
* the audit log
* role based access control
* well defined api
* the explain subcommand
* liveness and readiness probes
* custom resources
The list goes on, but the big ones for a small team just getting started are workload identity and security.
K8S is basically another answer to Conway’s Law. Every startup I’ve worked at switched to it because then the infrastructure could map more closely to the code. Not unlike microservices at a higher level.
The old-skool approach is depending on a team of SREs or sysadmins to provision hardware for you and basically handle the deployment, which K8S plus container images basically abstract away.
Not to say that dedicating resources to platform development (k8s style) isn’t a time sink when you’re trying to build product and find a fit in the market.
In my experience, giving code preferential treatment is how you end up with complexity lunacy; so I’ll add an addendum to Conway’s Law:
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure — and which mirrors the skills of its key creators.”
K8s is designed to solve Google problems. Your startup will not have Google problems. Your startup will have Pinterest problems, or Gitlab problems, or Reddit problems — at which point you do not need K8s; you need someone who knows infra (which I expect devs to be working on distributed systems to understand).
Using K8s in a startup context is a sign of conformist thinking, detached from any critical aspect.
> The old-skool approach is depending on a team of SREs or sysadmins to provision hardware for you
This assumes that K8s won't require a "team of SREs". My experience is you need the same amount of SREs to maintain Kubernetes, probably more, because now you have a complicated control plane, a networking nightmare, then you layer that on top of resource-contention issues, security issues, cloud provider compatibility issues, buggy controllers, the list goes on.
The only thing K8s is great for is the maintainers, the consultants, and highly experienced SREs that inevitably have to be hired to clean up the mess that was created. This is my experience working in two similar sized environments, one with >1M containers, and another with an equivalent scale of bare metal servers.
Conway's law is about mapping teams to code+infrastructure (generally: areas of responsibility), not about mapping code to infrastructure. It's about people and politics.
You're right that K8S is an answer to Conway's Law: our people don't get along or can't collaborate or we have too many of them, so we will split them into team per service and force them to collaborate over network interfaces. Likewise, the infrastructure people will communicate with the other teams using Dockerfiles.
DNS records are usually set once and forget. You read the documentation once when you’re doing it, and then you basically never have to touch it again. I had to look up the difference between a CNAME and an A record, even though I’ve set them numerous times before. Not useful in day-to-day.
DNS servers: going to assume you query a DNS server that has a map of domain names to IP addresses, with basic routing via DNS records, which then resolve to a final address which is sent back. Again, never going to have to know this unless I’m a network admin.
Port-mapping: what is there to understand? I have literally never had to map ports unless I’m port-forwarding a game server I’m running on my local machine, that’s using a router to be exposed to the outside network. Literally, every cloud provider will give you an endpoint address that does not require port-mapping. If you’re setting up a company network you have to port-map, but not if you’re deploying a simple server/app. Ergo, network admin’s job.
Compilers: lol. There’s tons of languages, and tons of different compilers for each language. Then there’s distinguishing compilers, interpreters, compiler-interpreters, and transpilers. At the end of the day they take text (usually) and transform it into another form. I’ve built a compiler before (toy AST & recursive descent), but I have never needed to know about it in a CRUD context.
I'd like to take the opportunity to throw some shade at network admins because out of all companies I worked at, they have consistently been the slowest to respond when their stack is usually the most reactive to changes.
The more people that offload their knowledge to the category that should be handled by networking experts, the higher the backlog for the networking experts. Which kind of supports OP's point.
In more current vernacular: do humans trade with the big bang? do humans trade with the expansion of the universe, and it's inevitable collapse back into the initial singularity?