451–460 of 558 posts
Earlier quoted context omitted.
And isn’t Wasm supposed to (some day) free us from the need to pick JS for the front end?
Unfortunately, that doesn't seem the way WASM is going. It's been 5 years and we still can't access the DOM without going through JS.
Rust, for example, has a huge package with interfaces for every DOM function.
Earlier quoted context omitted.
There is nothing stopping you from hosting your own OpenStack, managed k8s, and all that, on your own hardware. You would need a good reason to not let someone else deal with all of this though.
For a small enough company you could even just use use k3s + offsite backups. Once you grow large enough you can setup machines in 2-4 locations across the land mass where your users exist. If you have enough than a hardware fault in one isn't an emergency and you'd be able to fly out to fix things if needed. Realistically, on all flash, you are very unlikely to need to maintain anything on a server for a few years a…
Earlier quoted context omitted.
I think it still bears repeating.. I've seen projects fail or take 10x as long due to choosing to go with k8s day 1 instead of starting with even a basic VM. It may be easy enough to get k8s itself setup. However, without an in-house expert sat within the dev team, all the access/permissions to resources to/from the cluster were hell. NFS disk Read/Write, S3 Read/Write/List, RDS DB access, Kafka access, corp network…
It’s not like vms have magical simplicity guardrails. I run all my personal stuff in K8s because it’s what I know and it’s all pretty set it and forget it. If it really is that simple, or your comfortable with Ansible great! but I’ve seen lots of issues on VMs with mountains of custom deploy scripts, or OS’ that can’t be upgraded, or manual configurations people don’t understand.
Well, with Kubernetes this became container images versions and operator versions that can't be upgraded. Though I agree with your in general.
Earlier quoted context omitted.
Right.. But scale? I've seen places hire a dev that write all the OPS stuff and they scaled awesomely.. I mean if they had purchased 100servers full time on amazon, they would have spent a fraction of the cost to scale, but they could scale. In 5 years I think they've never once had to reach even near the 100servers. At the same time. I can scale heroku to 500 servers, and still be under the cost of one ops person. I…
> At the same time. I can scale heroku to 500 servers, and still be under the cost of one ops person. I can make that change and leave it there. I can do that all in under 30 seconds. Oh. And CICD is built in as a github hook. Even with blue-green deploys. And then Heroku shuts down. If you're building something that needs to scale up rapidly if it succeeds, k8s is worth thinking about. Either you don't succeed, in w…
Yes, if your application looks like a web application that is cache friendly, k8s can really take you a long way.
Earlier quoted context omitted.
> I know of such a case, where a single engineer could leverage the helm chart open source community, and set up a scalable infrastructure, with prometheus, grafana, worker nodes that can scale independently of web service, a CI/CD pipeline that can spin up complete stacks with TLS automated through nginx and cert-manager, do full integration tests, etc. I found that to be quite impressive, for one person, one year,…
> They used the work of others to get to the result. Should everyone go back to assembly on bare metal, then?
Earlier quoted context omitted.
But you could also have 2 people working on React Native and have 1 person each for getting it to play nice with iOS/Android, and eliminate the need for an extra engineer.
And end up with a subpar product because of your decision to use terrible tech that can't hold 60 FPS while scrolling a list
Doesn't look like the author knows what he is talking about. His point about early stage startup should not use K8S is fine. But the next advice about not using a different language for frontend and backend is wrong. I think the most appropriate advice is to choose a stack which the founding team is most familiar with. If that means RoR then RoR is fine. If it means PHP then PHP is fine too. Another option is to use…
Choosing more than one language as a startup can become really expensive quickly. As long as your tribes are small, chances are high that you one day run out of. e.g., python developers while you still have a lot of Java guys (or vice versa). This introduces unnecessary pain. (And obviously, you should have used Rust or Haskell from the get go for everything.) The sole exception to this rule I would make is javascrip…
Doesn't look like the author knows what he is talking about. His point about early stage startup should not use K8S is fine. But the next advice about not using a different language for frontend and backend is wrong. I think the most appropriate advice is to choose a stack which the founding team is most familiar with. If that means RoR then RoR is fine. If it means PHP then PHP is fine too. Another option is to use…
I don't think their advice about not using it in a startup is correct either. You just need to somewhat know what you're doing. I know of such a case, where a single engineer could leverage the helm chart open source community, and set up a scalable infrastructure, with prometheus, grafana, worker nodes that can scale independently of web service, a CI/CD pipeline that can spin up complete stacks with TLS automated t…
So if you already know Kubernetes, then great, use it. Leverage your existing skills. If you don't, then just use Heroku or fly.io or whatever, or go with AWS if that's your competence. Maybe revisit in a year or two and maybe then you'll have funding to hire a devops person or time to spend a week or two learning to do it yourself. Right now you want to get your SAAS MVP in front of customers and focus on the inevitable product churn of building something people want to pay for. The same advice goes for anything else in your stack. Do you know it well enough? Do you need it right now? Or is there a "good enough" alternative you can use instead?
Earlier quoted context omitted.
I very much agree with you. I must have been unnecessarily critical in my initial comment, I did not mean it as a rant, more like an observation about where-we're-at towards what seems an inevitable conclusion to me. Sorry that came out wrong, clearly I got carried away. In asking if "Kubernetes is a red flag signalling premature optimisation", you correctly explain why we're yet on the "yes" side for the typical web…
>My unspoken contention was that eventually, we move to a world where k8s-like infra is the de facto norm for 99% of infrastructure out there, and on that road we move to the "no" side of the initial question for e.g. web agencies (meaning, we've moved one notch comparable to the move from old-school SysAdmin to DevOps maybe, you know those 10 years circa 2007-2018 or so). This is very very hard to parse BTW. I don't…
Essentially I mean: scalable infra may be premature optimization today in a lot of cases, but eventually it becomes the norm for pretty much all systems.
You could similarly parse the early signs of a "devops" paradigm in the mid-2000's. I sure did see the inception of the paradigm we eventually reached by 2018 or so. Most of it would have been premature optimization back then, but ten-ish years later the landscape has changed such that a devops culture fits in many (most?) organizations. Devops being just one example of such historical shifts.
I anticipate the general k8s-like paradigm (generic abstractions on the dev side, a full 'DSL' so to speak, scalable on the ops side) will be a fit for many (most?) organizations by 2030 or so.
I hope that makes sense.
Earlier quoted context omitted.
> I'll make these four lines of code a function in case I need to call it more than once later on - you know, what if that's needed? The code example is not always right. Beware, if you know it will be needed, you might as well make it a function now. Likewise if you think probably it will be needed, why not make it a function now? It’s not a good review comment or rejection to say “yeah but I don’t want to do that b…
> Sure, but what if you are just being lazy and you don’t appreciate what it should look like long term? I wasn't aware that some devs have a side hustle as fortune tellers? On a more serious note, you should take a look at Sandi Metz's "the wrong abstraction". https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
A simple example. If you are making a multi-page website that contains a header on all pages, you can separate the header into a component from the get go, instead of duplicating the header for each page and then abstracting it in the future (where it starts to become more work).