5 ms·

I am ready! NetBSD is running on the toaster. I think haproxy can do 10K req/s. tcpserver on the backends. I only write robust shell scripts, short and port

• tutfbhuf 6y ago
  I can see your point for small hobby projects. But enterprise web development in C++ is no fun at all. For example: "Google says that about 70% of all serious security bugs in the Chrome codebase are related to memory management and safety." https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/chrome-70-of-all-security-bugs... Developer time for fixing these bugs is in most cases more expensive, than to throw more hardware at your software written in a garbage collected language.
  • Perseids 6y ago
    True, but the alternative to C++ with that reasoning is Rust or Go (depending on your liking), not Ruby. And with both of these you can step around a lot of deployment issues, because a single server can be sufficient for quite high loads. Avoid distributed systems as much as you can: https://thume.ca/2020/05/17/pipes-kill-productivity/ https://thume.ca/2020/05/17/pipes-kill-productivity/
    • pas 6y ago
      I find that the big problems that k8s solve is the usual change management issues in production systems. What do we want to deploy, okay, stop monitoring/alerts, okay, flip the load balancer, install/copy/replace the image/binary, restart it, flip LB, do the other node(s), keep flipping monitoring/alerts, okay, do we need to do something else? Run DB schema change scripts? Oh fuck we forgot to do the backup before that! Also now we haven't started that dependent service, and so we have to rollback, fast, okay, screw the alerts, and the LB, just rollback all at once. And sure, all this can be scripted, run from a laptop. But k8s is basically that. ... And we get distributedness very fast, as soon as you have 2+ components that manage state you need to think about consistency. Even a simple cache is always problematic (as we all know how the cache invalidation joke). Sure, going all in on microservices just because is a bad idea. Similarly k8s is not for everyone, and running DBs on k8s isn't either. But, the state of the art is getting there. (eg the crunchydata postgresql operator for k8s.)
      • znpy 6y ago
        > I find that the big problems that k8s solve is the usual change management issues in production systems. This. I was in a company where devops was just a fancy marketing term, developers would shit out a new release and then it was our problem (we the system engineers / operations people) to make it work on customers' installations. I now work as a devops engineer in a company that does devops very well. I provide all the automation that developers need to run their services. They built it, they run it. I am of course available for consultation and support with that automation and kubernetes and very willing to help in general, but the people running the software are now the people most right for the job: those who built it. As I said in my other comment: it's really about fixing the abstractions and establishing a common lingo between developers and operations.
    • fxtentacle 6y ago
      It depends. If you want to be a successful indie company, avoid cloud and distributed like the plague. If you want to advance in the big corp career ladder, user Kubernetes with as many tiny instances and micro-services as you can. "Oversaw deployment of 200 services on 1000 virtual servers" sounds way better than "started 1 monolithic high-performance server". But the resulting SaaS product might very well be the same.
  • toyg 6y ago
    Rust and Go could help you there, and their deployment story is as excellent as C/C++: just compile and ship. However, their learning curve is pretty steep (particularly Rust) and most developers don’t enjoy having to worry about low-level issues, which makes recruitment and retention a problem. Whereas one can be reasonably proficient with Python/Ruby in a week, Java/C# is taught in school, and everyone has to know JS anyway (thanks for nothing, tweenager Eich), so it’s easy to pick up manpower for those.
    • Perseids 6y ago
      Do those highly available developers have the same quality as the Rust developers you could get, though? (On average.) I'd wager there is a correlation between interest in deeper topics as required by Rust and good long term design and quality. I've seen how marvelously efficient a small team of very talented people can be be. To replace them with the average highly available developers you would need far more than doubly the people and some extra manager, just because communication scales so badly. The 10x developer is a myth, but I think the 5x development team is realistic in the right circumstances. Disclaimer: Neither do I claim to be a very good developer, nor do I think you, the reader, is only average. Just given that you are reading Hackernews is a strong indicator for your interest in reflection and self improvement, regardless of your favorite language.
      • deleted 6y ago
        [deleted]
      • fxtentacle 6y ago
        The problem might be that those people interested in learning new things, solving complicated issues and building good long-term architectures are usually not too interested in sitting in a cubicle without a window. So big companies might be forced to settle for less skilled developers, simply because the top tier is doing their own thing. I assume that's also why acqui-hiring is a thing.
        • Throwaway655249 6y ago
  • pwdisswordfish2 6y ago
    That's why C++ is in brackets. :) I think the reason a hobbyist might be able to pull off something extraordinary is because he is not bound to the same ambition as a tech company. He can focus on performance, the 10K req/s part, and ignore the "requirement" of serving something large and complex that is likely full of bugs. "Developer time" is "hobby time". Done for the pleasure of it, not the money. Some of the most impressive software from a performance standpoint has been written by more or less "one man teams". I am glad I am not a tech worker. Even for someone who enjoys programming, it does not sound fun at all. No wonder there is so much cynicism.
  • roystonvassey 6y ago
    Additionally, for larger eneterprises, the operational overhead quickly grows and slows down new app development, if one is tied to a traditional server approach. Within our teams, we’ve found we can do with an (even) higher level of abstraction by running apps directly on PaaS setups. We found this sufficient for most of our use-cases in data products.
• foxhill 6y ago
  > I would say there seems to be a great affinity amongst in the tech industry for anything that is (relatively) complex. hah, i've noticed that too - specifically around k8s/deployments/system architecture too. i've taken to calling it complexity fetishisation. i think it stems from the belief/hope that, whilst they don't "google sized" data today, they need to allow for it. i'll take two toasters, please.
  • 101404 6y ago
    The reason for complexity fetishisation (great term!) is to show everybody else how amazingly smart you are. It's the infrastructure version of "clever" code.
    • fxtentacle 6y ago
      I predict that you'll get down-voted into oblivion, but I agree with you :)
    • pwdisswordfish2 6y ago
      Except to some of us it shows just the opposite.
      • collyw 6y ago
        Its starting to get depressing at my age. After nearly 20 years in the industry I think I have a knack for keeping things as "simple as necessary and no more" and managing complexity. Unfortunately interviews are full of bullshit looking at pedantic nitpicking, or stuff I learned 20 years ago in university and have never needed to use since.
        • waheoo 6y ago
          Just focus on staying relevant with new languages and ignore the hypetrain that is k8s. Its something you can learn on the job and can easily talk your way around in an interview. The older i get the more i realise the less i want in my stacks. This article listed as a benefit, frequent, multiple major updates each year, new features and no sign of it slowing down. I just cringed and wondered who the fuck is asking for this headache? Ive been working a lot with wordpress lately and the stability of the framework is spoiling me rotten.
• nonines 6y ago
  Same feeling here but I came to understand that it's the enterprise and the design by committee that brings in the complexity. K8S is developed by a multitude of very large companies. Each with their own agenta/needs. All of them have to be addressed. Thus the complexity. If you think about it they probably manage to keep the complexity to relatively low levels. Maybe because it is pushed to the rest of the ecosystem (see service meshes for example). Being pushed by the behemoths also explains the popularity. Smaller companies and workers feel that this is a safe investment in terms of money and time familiarizing with the tech stack so they jump on. And the loop goes on. Main business reason for all that though I think it's the need of Google et all to compete with AWS creating a cloud platform that comes to be a standard and belongs to no-one really. In this sense it is a much better, versatile and open ended openstack attempt.
• tannhaeuser 6y ago
  > great affinity [...] for anything that is (relatively) complex. That, and mixture of a sunken cost fallacy/lack of the ability to step back and review if the chosen solution is really better/simpler rather than a hell of accidental complexity. If you've spend countless months to grok k8s and sell it to your customer/boss, it just has to be good, doesn't it? Plus, there's a great desire to go for an utopian future cleaning up all that's wrong with current tech. This was the case with Java in the 2000s, and is the case with Rust (and to a lesser degree with WASM) today, and k8s. Starting over is easier and more fun than fixing your shit. And another factor are the deep pockets of cloud providers who bombard us with k8s stories, plus devs with an investment into k8s and/or Stockholm syndrome. Same story with webdevs longing for nuclear weapons a la React for relatively simple sites to make them attractive on the job market, until the bubble collapses. But like with all generational phenomenae, the next wave of devs will tear down daddy-o's shit and rediscover simple tools and deploys without gobs of yaml.
  • Perseids 6y ago
    > Plus, there's a great desire to go for an utopian future cleaning up all that's wrong with current tech. This [...] is the case with Rust [...]. Starting over is easier and more fun than fixing your shit. The domain I'm working in might be non-representative, but for me fixing my shit systematically means switching from C++ to Rust. The problems the borrow checker addresses come up all time either in the form of security bugs (because humans are not good enough for manual memory management without a lot of help) or in the form of bad performance (because of reference counting or superfluous copies to avoid manual memory management). But otherwise I agree with you that if we never put in the effort to polish our current tools, we'll only ever get the next 80%-ready solution out of the hype train.
    • jason0597 6y ago
      Have you tried modern C++ before switching to rust? Or were you already using it and it didn't provide all the necessary features?
      • 6y ago
• fxtentacle 6y ago
  That's kind of why people use Google Go. No memory issues, statically linked, easy cross-compile, and it can handle 10k requests on a toaster. And yes, there is less fancy companies like one where I work where we don't use Kubernetes because it's kind of overkill if all of your production workload fits onto 2 beefy bare metal servers. I can see a point in using Docker to unify development and production environments into one immutable image. But I have yet to see a normal-sized company that gets a benefit from spreading out to hundreds of micro instances on a cloud and then coordinating that mess with Kubernetes. Of course, it'll be great if you're a unicorn, but most people using it are planning for way more scaling than what they'll realistically need and are, thus, overselling themselves on cloud costs.
  • grogenaut 6y ago
    Running on only 2 servers kinda risky no? Your one hardware failure during a maint on the other away from an outage.
    • fxtentacle 6y ago
      Yes, but with the cloud I'm also only one platform issue away from not having my virtual instances start correctly. Like the one on May 22nd this year. Last year, my bare metal website had 99.995% uptime. Heroku only managed 99.98%. Of course, I could further reduce risk by having a hot standby server. But I'm not sure the costs for that are warranted, given the extremely low risk of that happening.
      • grogenaut 6y ago
        I didn't bring up the cloud but ok. Can you link the outage? A googling couldn't find it.
• tasssko 6y ago
  I think the popularity of Kubernetes is that it can run all kinds of workloads on a single platform not really its performance. I've been in Ops business for over a decade now, in my case every single customer has a completely different kind of application architecture and sometimes even with similar use cases (i.e like ecom app or chatbots etc). With Kubernetes the differences are largely irrelevant encapsulated nicely within the container. This means in my universe I can run all of our customers on a single architecture and the differences are nicely abstracted.
• mpalmer 6y ago
  > because it is not being used by well-known tech company and not being worked on by large numbers of people, it would not be newsworthy. And at this point the hobbyist might wonder, "why isn't my toaster software being used by well-known companies? where are the pull requests to add compatibility for newer toaster models?" > As a spectator, not a tech worker who uses these popular solutions, I would say there seems to be a great affinity amongst in the tech industry for anything that is (relatively) complex. I think you have it backwards. General/abstract solutions (like running arbitrary software with a high tolerance for failure) have broad appeal because they address a broad problem. Finding general solutions to broad problems yields complexity, but also great value.
  • pwdisswordfish2 6y ago
    "And at this point the hobbyist might wonder..." Not this one. :)
• siculars 6y ago
  Deploy that toaster on k8s and now you have a vc funded startup.