Earlier quoted context omitted.
it feels like the "refactor" was the way to improve
I love reading people saying this. Try a couple of thousand DB tables evolved organically. Nope not happening.
So it wasn't purely cloud/renting racks issue
91–100 of 140 posts
Earlier quoted context omitted.
it feels like the "refactor" was the way to improve
I love reading people saying this. Try a couple of thousand DB tables evolved organically. Nope not happening.
So it wasn't purely cloud/renting racks issue
The marriage of an all arm64 dev env and a Graviton op env is a match made in heaven. Everyone please do this so we collectively fix all the things to work with this. :-)
My take, is that you want to cheer Arm on in this space, not because there is some huge technical advantage, or the arch meets your fancy or whatever, but because it is adding another competitor to the space. One that brings its own baggage, but having three+ competitors competing to be the best (intel/amd/various arm vendors) is a good thing for the industry.
But the blank fanboyism is just harmful, the mid 2010's with all the Intel fanboys talking up Intel, while they screw everyone with low clocked server processors limited to 2 cores copy pasted in their laptops when you could buy a freeking phone with 8 cores, is what you get when one company gets to much market share or too far ahead of everyone else. The same thing is going to happen if gravaton becomes the dominate platform, except its going to be a case that you won't be able to buy competitive onprem hardware, or any number of other shortcomings. Or like the Mac a piece of hardware which isn't technically locked down, but also will likely always have subpar support running any operating system not shipped by apple, and could be locked down tomorrow without affecting their business one bit.
So, careful what you wish for. You want competitors that show the giant monopoly that maybe designing a processor for an actual laptop is advantageous over shoveling whatever leftovers from the hyperscalers happen to exist. You also want competitors that show up and pack 2x the cores at 1/2 the price. Or competitors that show up with huge power hungry processors that are pushing the limits of single threaded, high Ghz processors, or 500W GPUs because that is what some people need/want.
Another easy cost-savings switch is telling Terraform to create EC2 root volumes using gp3 rather than gp2 (gp3 is ~10% cheaper and theoretically more performant). The AWS API and Terraform both still default to gp2 (last I checked), and I wonder how many places are paying a premium for it.
Earlier quoted context omitted.
What do you want to know? It was a prototype. I was trying to learn Rust (didn't succeed), but I did manage to hack together a message queue that used HTTP for client interaction. I'd previously written a SQL database message queue in Python which worked with Postgres/MySQL and SQL server. This worked well but it was not fast enough for my liking. My goal was to build the fastest and simplest message queue server tha…
It seems very diplomatic of you to say you found Rust hard to learn, rather than that it was hard to make Rust do what you wanted. You seem very clear on what you wanted to do.
The resulting code worked but was garbage and at the end of the day Rust had not clicked for me and being fluent in it still felt a distant goal.
I love the idea of Rust but I don't like the implementation.
I'm hoping in time there will be a new language created that has the memory and thread safety of Rust but is 50 times more simple.
Earlier quoted context omitted.
At $dayjob I found an unused box in the cloud running an expensive database engine. It was idle for months, created to be used by a consultant on a project that had wound up. The consultant had quit his consultancy on top of this. I was told under no uncertain terms not to even think of touching this VM because “the budget has been approved”. I was shocked at the flagrant waste of money and assumed it was a one-off a…
FWIW, in these situations you're better off proposing: "I'm going to reuse this VM, to help our ... fleet scale better." That way your management continues to use their allocated budget, and your real prod systems work slightly better (also will eventually require less additional $ to scale up - helping the company i.e. shareholders). The thing to remember: You would assume all middle management really manages are a…
Heh, I tried that too! I found a lot of setups using old HDD disks that were at 100% of their IOPS limits and CPUs that were idle. When they were built, Azure didn't have Premium SSD, so that's forgivable. I offered to rearrange where the expenditure goes, such that they have newer and faster CPUs, Premium SSD, but fewer cores which means a reduction in licensing costs. Cost neutral while improving their performance and capacity.
That got a very firm "Nope! Nope! Nope!" from most (but not all) teams as well.
> As such middle management has to say "we need to do more with less", but they are promoted based on these numbers going up!
I came to the same conclusion. Many project managers or product owners introduced themselves in the first meeting by proudly proclaiming the huge size of their operation. I.e.: "The system I'm responsible for is a multi-million dollar project with a small army of developers!"
I've also noticed that there's a tendency to exponentially blow out complexity of what ought to be a trivial system for the same reason. Something that could be static HTML on an S3 bucket or Azure Storage Account turns into a microservices monstrosity draped across three clouds and four external SaaS services.
Those resumes don't pad themselves.
Cloud cost optimisation is underrated. In the companies I've worked in nobody has really given a shit (at least not under normal economic circumstances). In the industry there's a strong avoidance of ARM compute instances for no good reason. If I were building from scratch today I would definitely go with Graviton.
This. We have three people entirely dedicated to reducing costs. As for avoiding ARM, we do only x86-64 because corporate security policy demands that we have Windows laptops so that some box ticking overlord can fill out a security policy compliance form. That means we're stuck limping along with docker and WSL2. Every single engineer in the org has an arm64 machine at home already and wants a proper computer at wor…
Cloud cost optimisation is underrated. In the companies I've worked in nobody has really given a shit (at least not under normal economic circumstances). In the industry there's a strong avoidance of ARM compute instances for no good reason. If I were building from scratch today I would definitely go with Graviton.
At $dayjob I found an unused box in the cloud running an expensive database engine. It was idle for months, created to be used by a consultant on a project that had wound up. The consultant had quit his consultancy on top of this. I was told under no uncertain terms not to even think of touching this VM because “the budget has been approved”. I was shocked at the flagrant waste of money and assumed it was a one-off a…
One of my managers was a champion at that, taking scraps from everywhere for undercover projects. One of the few who managed to get things done in a highly bureaucratic company. Also helped by the fact he is good at picking competent people.
I found graviton to be a mixed bag. It was certainly extremely fast when using the very high end instances and I tested it successfully using a Rust based message queue system I was writing and it got some ridiculously fast number like 8 million messages a second, from memory, using the fastest possible graviton instance (this was about 18 months ago). I did try to switch some of my database servers to it a couple of…
I'd argue just find a different cloud provider. GCP, Azure, Supabase, Cloudflare etc if you want managed services. If you want a mix of managed services and raw compute, look more at Fly.io, Linode, Digital Ocean perhaps? I have found AWS being the "cheapest" or even "reasonable" in the cost department to be slimmer every year.
They've had senior staff on HN justifying security lapses that commenters were describing as a "clownshoes operation".