I absolutely agree with the first part of this advice.
As to the assertion that complexity is not worth worrying about, I could not disagree more. I have watched projects fail time after time because of complexity, dependencies, and lack of budget.
Managers should encourage their engineers to spend time trying to simplify architecture and reduce code, infrastructure, and package dependencies. Smart engineers can learn to think simply over time, but this will not happen automatically. (I plead guilty to gravitating toward complexity in the early part of my career, but I have since learned better.)
Managers should place emphasis on using existing patterns wherever possible rather than re-inventing the wheel. Practicing laser focus on delivering value, evaluating solution dependencies with an eye to keeping things simple, and accurately modeling the problem domain in question.
Rather than trying to fight with engineers about implementation approaches, managers should try to guide engineers toward arriving at these conclusions themselves. I have also found that stressing simplicity as a key performance metric for engineers is a useful tool.
> I have also found that stressing simplicity as a key performance metric for engineers is a useful tool.
Some of the smartest engineers I've ever worked with produce code that is so well crafted it feels simple when you look at it, but it's actually extremely clever.
I think the conversation about "clever", "smart", "volatile" programmers tends to align the axis of _code_ complexity with cleverness, but often the cleverness is in finding the perfect simple solution.
"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better." -- Edsger W. Djikstra
Complexity sells better because it's cheaper. This is not the, "look at this novel abstraction I wrote and proof of its correctness with respect to our specifications," kind of "complexity" that folks often mean. It's the hand-waving, just add the simplest patch you can to make it work for the business problem at hand, type of complexity. The kind of complexity that ends up with giant balls of "really simple" code that nobody understands entirely anymore.
It sells better for all the usual reasons that driving slightly over the speed limit gets you where you're going a little faster. It's only a problem if you get caught or cause a collision.
Your comment touches on the awol concept of clarity in this conversation: "The quality of being coherent and intelligible".
Balls of mud are the very essence of simplicity (in one sense) yet lacking any clarity.
Clarity is a (bad sort of) hot commodity in an immature yet rapidly developing technical field. In our field this is exacerbated by the fact that the entire field can be viewed as a monument to the peter principle (but thankfully the imposter syndrome is there as a collective salve for us all.)
I think highly intelligent engineers that can penetrate the essence of a problem and come up with effective & coherent conceptual models are a valuable but (in places) untimely assets. My recommendation to such engineers (who also wish to be responsible team members) is to recognize the cognitive impedance mismatch and broaden the 'scope' of the solution to include the human element, and descend to norm if necessary. The ultimate goal is to serve a broader goal, and fighting against impedance mismatch is un-/counter-productive.
My personal red line is the 'big ball of mud' teams.
A couple of points:
1. Cloud Run is more analogous to AWS App Runner than Fargate.
2. Cloud Run isn't a great analog to lambda. Lambda is built to host functions. Cloud Run is built to host applications. Lambda is more analogous to GCP Functions.
3. Cloud Tasks should probably be built with EventBridge + Lambda or EventBridge + StepFunctions or EventBridge + ECS.
I don't profess to be a GCP expert so it's hard for me to make a judgement call on what's better. I can, however, say that most of this post ignores some of the real serverless power provided by AWS. AWS AppSync, AWS API Gateway, DynamoDB, CloudFront Functions, Lambda@Edge. It also makes comparisons that are not very fair.
Huh. I had this long call with our AWS Account Reps (+ Support Engineers) the other day and no one mentioned App Runner! This is the first I've heard of it. Looking at it now.
Ah I see, launched originally in May 2021. That's probably why they weren't aware of it. Yes, this looks cool. Very much what I was looking for.
The differences that I can see are...
* AWS App Runner lacks an advertised free tier. Not a big deal for all but the smallest projects though.
* AWS App Runner bills rounded up to the next second, whereas GCP Cloud Run rounds up to the next 100 millisecond.
* AWS App Runner doesn't charge per request (?!), whereas GCP Cloud Run charges $0.40/1M requests.
* AWS App Runner has fewer CPU/RAM configuration options. The lack of low end options may be a blocker for us.
* It's cheaper than GCP Cloud Run - $51.83 @ vCPU/1GiB, but 2GiB minimum, in Runner vs $69.642 @ 1 vCPU/1GiB (v1) $97.50 @ 1 vCPU/1GiB (v2) in Cloud Run.
* I'm confused by the networking model. In App Runner, you have to make an ENI for your App Runner service to access your VPC? Weird. There's some extra cost there I think.
Things that I can't determine based on the documentation...
* Does App Runner support committed use discounts?
* Does App Runner throw a SIGTERM before shutting the container down? I hope yes but I can't find docs on it.
* Is there a file system accessible on App Runner and is it just in memory or is there actually a disk to write to?
* The quotas & limits page on App Runner feels incomplete and I'm left with a lot of questions about it.
* Is there an SLA?
* In fact the documentation for App Runner just feels a little incomplete.
It looks like AWS definitely wants App Runner to be the answer to Cloud Run, but to me, it feels like it's not quite there yet.
It's also weird, that ECS Fargate lets you run a container without thinking about the server that it runs on, and App Runner does too, just with a few extra things. Why is it a whole separate service? Why didn't they just add it onto Fargate?
Re: Other services. I've only heard of API Gateway, DynamoDB and Lambda@Edge; I'll have to spend time investigating the other ones. Thank you for mentioning them!
I know this is an old thread now, but I just came back to it and thought to dig in a bit. First thing my Googling hit was this, which provides a good comparison of App Runner and Fargate
Do you have a source of Magnus accusations? He seems to have withdrawn relatively quietly, perhaps consciously trying to refrain from cheating accusations.
Hikaru was less reserved on the other hand. He called Hans's post-game interview analysis sub-2700 level after Hans Neiman badly mis-evaluated several positions.
Yeah I think he's being very professional instead of just throwing out accusations; let the arbitrators call that.
I'm not at all into chess (only through the odd HN post where I get out-nerded left, right and center), but I can imagine it ends up being a very analytical thing, where the experts or analysts can spot whether someone is playing like a human or a computer. And I also think they can't add "noise" (e.g. human mistakes) to it either, that'll either throw the computer off, OR it'll look "uncharacteristic".
Not a member of this forum, but wanted to help a bit here.
First off, computers are (especially in complex positions) ridiculously stronger than humans, like your average family car can't keep up with a Ferrari. In less complex games (like an endgame with fewer pieces) top-10 players can definitely play 20 perfect moves in a row, in an attacking game that's harder. A player like Niemann is not really expected to reach that level in a game like this.
A second point is how much time you spend on each move. If you play a move with big consequences (say sacrificing material, or violating a principle) you would generally think longer. A computer doesn't see it that way and might spot "instantly" that this move wins material 7 moves down the road, where even a World Champion will check his analysis before playing that.
So playing too perfect and playing too fast in critical positions are both red flags. In Online chess, they often use this to grade your moves, and flag you if you go over certain thresholds, especially if you have a lower "rating".
Hans Niemann did both of this (too fast and too good) and then after the game was not really able to explain his thought process afterwards. None of this is hard evidence, but they are red flags, and if you add that Niemann has been caught before in online chess... that's so many red flags it would make the CCP proud.
Hope that helps a bit! So no, there is no very analytical thing, which does mean we need to be a bit careful and leave the option open that Niemann maybe just really liked this move on general grounds, got lucky it worked, and has learned of his previous mistakes. It could definitely happen.
Nothing really throws the computer off. It is objectively much better than any human at evaluating any position, not just the types of positions computers get into.
This isn't true. 10GB is the limit on docker backed lambda function sizes. Layers are capped to 256MB just like lambda functions.
A couple of weeks ago, I tried to deploy a lambda function that created Azure Subnets in python, and the Azure client was 265GB alone. My layer creation api call failed because of this.
That's considered part of the team strategy in F1 to maximize the chances of getting both drivers and constructors championships. Team orders of this kind are issued at almost every race.
We don't consider it a "flaw" in soccer when one player passes the ball to another so they can score, and F1 blurs the line because there are both teams and individual standings. In singles badminton, though, it's supposed to be all about individual performance.
Quite frankly, it's an absurd comparison, and I'm not even a fan of sports.
A football team does not have a fraction of its players qualified to participate in a championship. There is no podium. The goalie is doing a completely different job from the striker.
There are team races, eg rowing, where one person cannot win and the other lose.
From what I see, F1 and other races are individual races! It just happens that individuals belong to the same organization, and therefore the organization forces some logistics shenanigans that go against the sport.
It is not. F1 drivers flouting the instructions are merely subject to consequences of insubordination at team level. Their whole lives are not erased from the national record and they are not subject to nation-level excommunication.
Controversy in 2002, now a normal accepted part of the sport. To the point of Verstappen openly saying to his team on public radio “Cmon guys now we’re really losing silly amount of time” when team orders didn’t happen fast enough. He had to wait 2 laps.
Here's a write up of me fine-tuning ModernBert for regression to try beat the market.
I hope you all enjoy!