enthusiast: if you'll migrate service X from a small sets of VMs to K8s cluster (which will take N man-moths because of reasons) it will auto-scale
Old grumpy man: but the the load is low and predictable we don't need autoscale and if load will grow we will just create two more VMs
enthusiast: auto-scaling will save time in the distant and unlikely future and CTO agrees that K8s is the best way to run software so you have to migrate anyway
Because then it won't scale.
And the moment you do you run into other bottlenecks.
We're not running the DB in Kubernetes though.
For DR, Entire stack is being continually synced with a set of hot server in separate datacentre. We run a fully DR exercise yearly and it works well. It's a fairly proprietary AIX / DB2 method though so not sure you'd find value unless you're using the exact same technology stack :-/
[1] From Walden: read at https://www.gutenberg.org/files/205/205-h/205-h.htm
That's perfectly ok, if your deployment costs are irrelevant and/or your company gladly pays up your infrastructure costs without a second thought.
This is not the case in some organizations, and toggling a setting to auto scale a deployment can automatically save you thousands of dollars per month.
Would you still be so casual about infrastructure costs if you had to bankroll the extra capacity you need to add to your baseline to support peaks?
The decision process involved in managing your single-box deployment is not the same that goes in managing global deployments with dozens of instances per region. Cloud providers charge a premium, and that premium is a lot.
It's like the thermostat in your office. If you're just running an AC in a single room then you can just set it to full blast to keep it day and night at a certain temperature. Once there's a decision to cut costs then you start to talk about the best time to turn off/turn on a AC unit.
Also, deploying a new build on VMs is extremely manual compared to k8s, unless again you set up some sort of home brew rube Goldberg machine to auto deploy. It's just way better to use k8s in tandem with a simple GA workflow.
Definitely not an expert, but I get the impression that this point is a lot higher that most people assume it is.
K8s makes little sense unless you run on bare-metal. Once you jump to vms you are injecting another abstraction layer and take on a herculean level of ops without understanding what you're getting into.
I'm not sure where the check points are now, but typical points where cost jumps are desktop -> server socket, single socket -> two sockets, two sockets -> four sockets, four -> eight sockets. AFAIK, AMD EPYC isn't offered at more than two sockets, and going to four sockets used to be possible off the shelf but very expensive, and eight sockets was very expensive if off the shelf or very expensive because custom engineering. Sometimes ram costs go way up for the highest density too.
In any other situation I firmly believe the benefits Typescript brings very quickly outweigh the small amount of added complexity.
I also enjoy piling on Rust fanboys,but those of us who had to go through late night troubleshooting sessions to track issues that were ultimately caused by use-after-free issues do tend to be vulnerable to Rust's memory safety siren's song
I've been a full-stack web developer for over a decade across multiple companies and this is the first time I've seen the phrase "discriminated unions".
And the wikipedia article is horrendous. It starts with the following sentence and gets worse from there.
> In computer science, a tagged union, also called a variant, variant record, choice type, discriminated union, disjoint union, sum type or coproduct, is a data structure used to hold a value that could take on several different, but fixed, types.
It uses lots and lots of words to explain something that's very simple. If you don't already know what it is, you can't figure out which words are important.
Then after all of the theory, it dives into a binary tree example which has to be the worst possible way to explain it. If you haven't implemented a binary tree before, you don't know any idea what you're looking at. It didn't help that I implemented a linked list in college.
Also, the choice of language ensures you have no idea what the types are. I completely missed the first example was self-referential.
It's like parody of a function programmer writing an explanation for anyone who isn't a functional programmer.
I've been programming in some form or another since the late-80s. I've been paid to write code for other people for over twenty years. I haven't gone to university.
Maybe it's because I started back in BASIC, assembler, and later C that I know what that term is and have encountered it in various languages and forms several times since?
The problem with wikipedia definitions is that they have to be the definition. Some one like me would expect a link to the definition and not a tutorial. They're not written to take into account that you've been a professional programmer and have never been exposed to a computer science curriculum nor are they written for laypersons who don't know anything about programming.
It's a similar problem for functional programmers trying to explain functors, monoids, and monads: these are not terribly complicated abstractions but catering your explanation to the various audiences out there is incredibly difficult. The definitions sounds like gibberish... but with effort and education it is possible to understand and appreciate it.
https://basarat.gitbook.io/typescript/type-system/discrimina...
I'm sincerely sorry for confusing you! Discriminated unions are nice but above I was exaggerating excessively to make a point :)
10 DEFINT A-ZThey're still using modern computers, the simulation of what the actual fabric would look like was amazing and I'm sure when that old computer was new, they would've killed for something like that.
Unlike the fetishists of HN, I doubt that they romanticise their use of the old computer; it's simply the only one that works with their older equipment. You say it's "easy to maintain" but they'd still need a specialist to diagnose & fix, you can't take it to any computer repair shop. And getting certain parts would be an absolute nightmare as well. You say "everyone using the system is familiar with it" well duh...the sky is also blue, of course people that use it are familiar with it, but for an industry that is on the decline, trying to get fresh faces in to revitalise won't be helped by a computer that those fresh faces would never have even seen before. Power usage doesn't matter when the looms probably pulls tens of kilowatts or more anyway. But yeah, it is cool. Impractical, but cool and that rings true for everything that they're doing, small & bespoke manufacturing of traditional wear.
It's unfortunate, but a lot of boutique industries like this are dying in Japan at the moment.
Organizations tend to invest in their operations if there are significant improvements to be made. This includes things like dealing with problems such as the availability of cassetes, if the legacy system becomes too old to maintain in a cost effective way, if it's still possible to source parts, etc.
Digital systems are widespread because they are widespread and dirt cheap, and thus the tradeoff of increasing the complexity does add value.
They also churn, and finding people who can (and will) work on legacy systems isn't easy either. Get rid of something that worked for 40 years because everyone uses this other thing (but will use something else 10 years from now that we can't predict) is dumb unless there is a very valid reason.