3 ms·

The fact that this solution is based on nomad is a big red flag: - no updates after December - you probably won't have the right to use nomad after that - ev

by Thaxll 3y ago

The fact that this solution is based on nomad is a big red flag: - no updates after December - you probably won't have the right to use nomad after that - every providers offer Kubernetes managed solution, by using nomad now you're pushing that burden to host and manage infra since no one is offering nomad services Using Kubernetes is a huge advantage since all the dev ops tool can run on it, it's tested and everyone is using it. As for more flexible than Agones I highly doubt that, do you have example?

ForHackernews 3y ago
Kuberentes is such an overengineered disaster. In 10 years, everyone is going to wake up with a hangover and pretend they never heard of it. Anyone here built a SOAP system? Of course not, you would never.
- wbl 3y ago
  What exactly is over-engineered about it? A lot of the seeming complexity is due to solving things that completing systems didn't even try to tackle or did so incompletely. For the base case of I want to run a service and expose an http API it's pretty easy, and then you get to coexist with other services.
  - ForHackernews 3y ago
    > For the base case of I want to run a service and expose an http API it's pretty easy Are you kidding me? Before you can do anything, you need... 1. API Server 2. Scheduler 3. Kubernetes Controller Manager 4. etcd 5. Cloud Controller Manager 6. Nodes 7. Pods 8. Container Runtime Engine 9. kubelet 10. kube-proxy And then before you can even expose it on HTTP you need an ingress, kube-dns, load balancer... Oh, don't forget that you'll actually want Helm and all of its components... Meanwhile, Nomad is a single binary, and it can even run scripts and other non-containerized workloads.
    - wbl 3y ago
      If you're running it on your own setup it gets complex. However half the concepts you listed exist in Nomad also, like the container runtime engine.
    - iakov 3y ago
      As if you dont need nodes, pods and a runtime for Nomad. An ex-colleague “sold” us developers nomad once as an easier, better alternative to k8s. They used exact same arguments, and we ended up with Nomad for our test and staging environments. It was such a mess, while it covered basic “run this” scenarios fine, nothing like kustomize or helm for nomad existed back then (I doubt it exists now). The tooling was non-existent, neither were good practices or recommended setups - nobody seemed to know how to tie it into a ci/cd setup without a bunch of bash scripts to get basic stuff like templating working. Implementing any kind of edge case or a tricky requirement felt like we are doing breakthrough work since no documentation, guide or SO page covered anything but “simple setup of your nomad cluster in two steps” - nomad is simply not popular enough. That experience made me swear off any unpopular but “trust-me-bro-its-actually-good” software. Sorry for the rant, your post made me remember how pissed I was at our tech stack back then.
    - Thaxll 3y ago
      Meanwile no one offers Nomad managed service, so who create those clusters, who operate them, who keep security / upgrade on...? You go to any cloud provider they all offer managed Kubernetes solution.
deleted 3y ago
[deleted]
doctorpangloss 3y ago
It's true everyone doing anything with infrastructure should be using Kubernetes, it's over, it has won. But it's complicated. Game development uses all sorts of red flags throughout all of history. The people making successful games are talented enough to deal with the downsides of anything. Nomad specifically is used by e.g. Roblox to orchestrate. Do I think that's a good idea? No. But it doesn't mean it can't work. With regards to your specific criticism I don't think that stuff really matters, there are tons of people using tons of totally unsupported / unsupportable game engines, open source libraries, etc.
- heipei 3y ago
  I believe the it's over because tech X has thinking is at best lazy and at worst dangerous. It implies that the everyone's requirements are the same and static and that solution X has reached all of those requirements. If people blindly accepted X has won we'd be still using Perl, XML, CGI-Bin, Apache, Angular, etc. As another comment has said, I believe years from now, folks will be looking back at in disbelief at how anyone could have considered k8s to be the best solution without room for improvement or alternative approaches.
  - KronisLV 3y ago
    > I believe the it's over because tech X has thinking is at best lazy and at worst dangerous. It implies that the everyone's requirements are the same and static and that solution X has reached all of those requirements. I'm somewhat inclined to agree, because iterating on what we have and developing new tech and practices seems like a good idea (the concept of 12 Factor Apps comes to mind). However, I can't help but to wonder what this would look like, when taken to the extreme. Perhaps something along the lines of: "We are only going to use Ubuntu for the servers and Java for all of our back end services, as well as React for the front end. Nothing else, no matter how many different projects there are." And on a certain level, it makes sense: consistency and skills that carry over seem like a nice thing to have, there's even terms out there like a company being "a Java shop" and so on. That said, such inflexibility might not always be nice (e.g. trying to do machine learning in Java) but at the same time if a specific technology is in demand in the job market in most companies, you don't really get much of a choice. To return from the analogy, in the particular case of Kubernetes, you'll have to learn and use it and there's only so much free time for exploring other options. > If people blindly accepted X has won we'd be still using Perl, XML, CGI-Bin, Apache, Angular, etc For many folks, some of those might indeed be good choices. Some backup software that I use is written in Perl and is actually pretty good (BackupPC). XML can be a nice format to use and has lots of tooling available. Even SOAP wasn't necessarily the end of the world thanks to WSDL - being able to plug a file into SoapUI and getting an API that you can play around with, something that took Swagger/OpenAPI years to reproduce for REST. There's something nice to be said about the simplicity of CGI and FastCGI still makes sense with something like PHP (PHP-FPM). I actually still use Apache for hosting my personal stuff - if has most of the features you might want and with mod_md it's a bit closer to Caddy than Nginx in getting LetsEncrypt certs (ACME). If you disable .htaccess, reasoning about the config also becomes about as easy as with Nginx (nginx.conf). I've also seen Angular be used reasonably well and the "batteries included" feel of it was nice, especially when React had about 1500+ dependencies for a new project. I do personally lean towards Vue, though (oh and migrating away from AngularJS after the EOL was a pain, when that was relevant). My point is that if something is good enough for your needs and helps you put food on the table, then you can just go with that choice. Let those who prefer to experiment do so (hopefully not with your livelihood), celebrate their efforts and successes and learn from their failures, though. Kubernetes is established, Nomad is interesting, even Docker Swarm or Compose is okay.
heipei 3y ago
Counterpoint: Providers offer k8s managed solutions because it's such a pain in the ass to run yourself. Nomad is far simpler to setup, operate and upgrade. And lastly the folks that are independent-minded enough to go with the less-popular option (Nomad) are also the folks more likely to host it themselves no matter what.
kawsper 3y ago
Last Nomad release was 1.6.1 and were released July 21, 2023.

by Thaxll 3y ago

ForHackernews 3y ago

Kuberentes is such an overengineered disaster. In 10 years, everyone is going to wake up with a hangover and pretend they never heard of it. Anyone here built a SOAP system? Of course not, you would never.

wbl 3y ago
What exactly is over-engineered about it? A lot of the seeming complexity is due to solving things that completing systems didn't even try to tackle or did so incompletely. For the base case of I want to run a service and expose an http API it's pretty easy, and then you get to coexist with other services.
- ForHackernews 3y ago
  > For the base case of I want to run a service and expose an http API it's pretty easy Are you kidding me? Before you can do anything, you need... 1. API Server 2. Scheduler 3. Kubernetes Controller Manager 4. etcd 5. Cloud Controller Manager 6. Nodes 7. Pods 8. Container Runtime Engine 9. kubelet 10. kube-proxy And then before you can even expose it on HTTP you need an ingress, kube-dns, load balancer... Oh, don't forget that you'll actually want Helm and all of its components... Meanwhile, Nomad is a single binary, and it can even run scripts and other non-containerized workloads.
  - wbl 3y ago
    If you're running it on your own setup it gets complex. However half the concepts you listed exist in Nomad also, like the container runtime engine.
  - iakov 3y ago
    As if you dont need nodes, pods and a runtime for Nomad. An ex-colleague “sold” us developers nomad once as an easier, better alternative to k8s. They used exact same arguments, and we ended up with Nomad for our test and staging environments. It was such a mess, while it covered basic “run this” scenarios fine, nothing like kustomize or helm for nomad existed back then (I doubt it exists now). The tooling was non-existent, neither were good practices or recommended setups - nobody seemed to know how to tie it into a ci/cd setup without a bunch of bash scripts to get basic stuff like templating working. Implementing any kind of edge case or a tricky requirement felt like we are doing breakthrough work since no documentation, guide or SO page covered anything but “simple setup of your nomad cluster in two steps” - nomad is simply not popular enough. That experience made me swear off any unpopular but “trust-me-bro-its-actually-good” software. Sorry for the rant, your post made me remember how pissed I was at our tech stack back then.
  - Thaxll 3y ago
    Meanwile no one offers Nomad managed service, so who create those clusters, who operate them, who keep security / upgrade on...? You go to any cloud provider they all offer managed Kubernetes solution.

deleted 3y ago

[deleted]

doctorpangloss 3y ago

It's true everyone doing anything with infrastructure should be using Kubernetes, it's over, it has won. But it's complicated. Game development uses all sorts of red flags throughout all of history. The people making successful games are talented enough to deal with the downsides of anything. Nomad specifically is used by e.g. Roblox to orchestrate. Do I think that's a good idea? No. But it doesn't mean it can't work. With regards to your specific criticism I don't think that stuff really matters, there are tons of people using tons of totally unsupported / unsupportable game engines, open source libraries, etc.

heipei 3y ago
I believe the it's over because tech X has thinking is at best lazy and at worst dangerous. It implies that the everyone's requirements are the same and static and that solution X has reached all of those requirements. If people blindly accepted X has won we'd be still using Perl, XML, CGI-Bin, Apache, Angular, etc. As another comment has said, I believe years from now, folks will be looking back at in disbelief at how anyone could have considered k8s to be the best solution without room for improvement or alternative approaches.
- KronisLV 3y ago
  > I believe the it's over because tech X has thinking is at best lazy and at worst dangerous. It implies that the everyone's requirements are the same and static and that solution X has reached all of those requirements. I'm somewhat inclined to agree, because iterating on what we have and developing new tech and practices seems like a good idea (the concept of 12 Factor Apps comes to mind). However, I can't help but to wonder what this would look like, when taken to the extreme. Perhaps something along the lines of: "We are only going to use Ubuntu for the servers and Java for all of our back end services, as well as React for the front end. Nothing else, no matter how many different projects there are." And on a certain level, it makes sense: consistency and skills that carry over seem like a nice thing to have, there's even terms out there like a company being "a Java shop" and so on. That said, such inflexibility might not always be nice (e.g. trying to do machine learning in Java) but at the same time if a specific technology is in demand in the job market in most companies, you don't really get much of a choice. To return from the analogy, in the particular case of Kubernetes, you'll have to learn and use it and there's only so much free time for exploring other options. > If people blindly accepted X has won we'd be still using Perl, XML, CGI-Bin, Apache, Angular, etc For many folks, some of those might indeed be good choices. Some backup software that I use is written in Perl and is actually pretty good (BackupPC). XML can be a nice format to use and has lots of tooling available. Even SOAP wasn't necessarily the end of the world thanks to WSDL - being able to plug a file into SoapUI and getting an API that you can play around with, something that took Swagger/OpenAPI years to reproduce for REST. There's something nice to be said about the simplicity of CGI and FastCGI still makes sense with something like PHP (PHP-FPM). I actually still use Apache for hosting my personal stuff - if has most of the features you might want and with mod_md it's a bit closer to Caddy than Nginx in getting LetsEncrypt certs (ACME). If you disable .htaccess, reasoning about the config also becomes about as easy as with Nginx (nginx.conf). I've also seen Angular be used reasonably well and the "batteries included" feel of it was nice, especially when React had about 1500+ dependencies for a new project. I do personally lean towards Vue, though (oh and migrating away from AngularJS after the EOL was a pain, when that was relevant). My point is that if something is good enough for your needs and helps you put food on the table, then you can just go with that choice. Let those who prefer to experiment do so (hopefully not with your livelihood), celebrate their efforts and successes and learn from their failures, though. Kubernetes is established, Nomad is interesting, even Docker Swarm or Compose is okay.

heipei 3y ago

Counterpoint: Providers offer k8s managed solutions because it's such a pain in the ass to run yourself. Nomad is far simpler to setup, operate and upgrade. And lastly the folks that are independent-minded enough to go with the less-popular option (Nomad) are also the folks more likely to host it themselves no matter what.

kawsper 3y ago

Last Nomad release was 1.6.1 and were released July 21, 2023.