To me this is just a simple artifact of size & attention.
Another example of this is stuff like Bluesky. There's a lot of reasons to hate Twitter/X, but people going "Wow, Bluesky is so amazing, there's no ads and it's so much less toxic!" aren't complimenting Bluesky, they're just noting that it's smaller, has less attention, and so they don't have ads or the toxic masses YET.
GenAI image generation is an obvious vector for all sorts of problems, from copyrighted material, to real life people, to porn, and so on. OpenAI and Google have to be extraordinarily strict about this due to all the attention on them, and so end up locking down artistic expression dramatically.
Midjourney and Stable Diffision may have equal stature amongst tech people, but in the public sphere they're unknowns. So they can get away with more risk.
But I use "cloud native" in a way that actually makes sense, not the way that GCP dubbed Kubernetes and all of it's ecosystem of friends "cloud-native".
"Native" development on a desktop OS means using primitives specific to that OS. As opposed to using something like Java Applets or Electron which will give you cross-platform compatibility, but you're not developing "natively" for the platform. That has the obvious pros and cons to each way.
Kubernetes is very much the Electron way: Rely on a generic high-level abstraction that will then create awkward bindings of running on abstract generic servers - whether they're in your data center or in the cloud.
Calling that "cloud-native" is some Orwellian post-truthness. I hate it.
If you want to develop in the cloud and make the most of it, use Azure, use GCP, use AWS, I don't care (not true: AWS is the best; use AWS). Just use the cloud provider's NATIVE primitives.
Otherwise, you might as well go back to running your own data centers, what are you even doing.
(Note: i'm just some guy. You don't have to listen to me. It's just what I think)
* RDS is a managed relational database service. You got a database? We'll run it in the cloud for you. Exact same bits and bytes as you're running locally.
* Aurora is Amazon's own relational database. You can't run it yourself, only with Amazon. It can pretend to be either Postgres or MySQL. And it'll be cheaper and faster and have higher availability. But it won't be the exact same bits and bytes as your own Postgres, so there's some risks.
So far the stuff we said runs on clusters. You pick how big and how powerful and how many and in which AZ and configure how to scale it.
This has fairly pragmatic limits before at a certain point sharding and continuous horizontal scaling just gets too hard.
* Until Aurora Limitless that is which is, well probably not limitless (I don't know) but effectively.
* But you're still configuring cluster sizes and scaling policies. If you don't want to do that, Aurora has a Serverless option. It's the same Aurora but now you don't have to worry about scaling it yourself. The first version was Aurora Serverless but people said it wasn't very good.
* So they put out a 2nd one which is great and scales to zero.
* Now if you have globally distributed customers or care a lot about resiliency, you probably want your database in multiple regions. And you're going to be setting up eventual consistent updates for that. To make that easier there is Aurora Global Database, which is the same Aurora, but now with cross region replication.
* But it's not strongly consistent across regions. Aurora DSQL is. It's an even more bespoke version of Postgres. Actually it's not a relational database one at all, it just pretends to be one. But it uses atomic clocks and shit to cheat the cap theorem and give you global distribution and resiliency with strong consistency.
So in conclusion there's basically only 3 things here:
* RDS which is an unopinionated way of running a relational database in the Cloud
* Aurora, Amazon's highly opinionated relational database. That has Global, Serverless, and Limitless configuration options.
* And Aurora DSQL which is not Aurora a relational database at all but plays one on TV. But it gets to have the best of all worlds - SQL and NoSQL.
They probably should have called it something new but Aurora has good brand recognition. People know and trust Aurora.
In the long term all will probably continue to exist depending on where you are in your cloud journey. But I also expect that in the fullness of time if you're building a new Cloud native application and you don't have to worry about legacy migrations, you'll probably choose either DynamoDB or Aurora DSQL in 99.9% of cases.
Andy Jassy was the first product manager on AWS, and while there is lore debates whether he "came up" with the idea of AWS (probably not), he's been on it from the beginning and through every single product.
I don't know much about Selipsky or Garman, but Jassy absolutely was/is technical enough to get to AWS to where it was today (or know when not to get in the way of those more technical than him).
Watch any of his interviews from before he was Amazon CEO. The man knew his shit.
I'm not lecturing them for leaving. I'm lecturing them for complaining about things that it WAS IN THEIR CONTROL TO ADDRESS. More than that - it was their actual JOB to ensure.
If you were L8 then the responsibility for setting the culture is 100% on you.
L10s don't micromanage, and L7s take their cues from L8s.
If you want to have fewer meetings, you can set that culture.
If you want less fungible engineers, reinforce specialization in your OLR process.
If you don't like a process, kill it.
This is worse than than the "you're not stuck in traffic, you are the traffic." This is "you're not stuck in traffic, you are the accident creating the bottleneck".
I know a lot of people here are writing about how this can be done for small consulting companies, but I also saw it in Big Tech.
Amazon until 2022 really genuinely exemplified this. I saw it for more than a decade leading up to this. Just an unbelievable collection of people that truly Gave A Shit. Publicly we called it "Customer Obsession" and through that lens you could move mountains around here in the pursuit of Doing The Right Thing.
The first sign of trouble was 2021. Salaries skyrocketed in the industry. Amazon didn't keep up. A lot of great people left because they got obscene offers, and you know, who could blame them? Our core of "intermediate" engineers (L5 here) got decimated - why bust your ass for a promotion when you can just get a Senior offer from one of 100 over-funded Unicorns for more money than you would've made here. Sensible.
Then in 2022 the stock price dropped in half and a bunch of folks who seems like were only putting up with the bullshit as long as the stock grew indefinitely left too.
Then 2023 brought layoffs.
There's still a lot of us around that Give A Shit, but I feel like we are outnumbered more and more by those that just want to punch in and out and no longer Make History. I get it. I can't blame anyone individually. But I miss it.
The frupidity used to be a huge sore spot, but being honest, is no longer a part of the culture.
Sure, there are no catered buffets or massage chairs, but the old inflexible rigid frupid systems are all gone. Engineers get top of the line M1 Macbooks, nice monitors and good chairs. The desks are all adjustable sit/stand, not doors. You can get and expense whatever software you need. And yeah you gotta fly coach but nobody is going to bite your head off for expensing some peanuts from the mini bar at your hotel.
Sorry dude, you don't have credibility based on "Unless your willing to put up with a huge ration of shit on a regular basis, or you make it into management,"
Management at AWS arguably puts up with much more shit on a regular basis.
The ones that don't probably would if it was public about how much of a significant contribution they've made to some foundational AWS services everyone knows. I think they don't mind.
But it's the difference between an individual carpenter making a rocking chair for himself and his family, or maybe making a couple to sell to his friends, and being a structural engineer.
Bikeshedding is not a necessary antipattern to the process, but large software projects absolutely need group collaboration, and a discussion of processes, tools, and best practices.
Maybe so, but don't you think I talk to new employees? It's half of my job to support my whole team and deliver through others.
I battled those tools when I started. I watched them get better.
I've seen what new hires struggled with 5 years ago and what they struggle with 1 year ago.
Night and day.
The tools have gotten a lot better.
Here's the other ugly truth: That "40% of struggling with internal tools" may be saving the engineer 300% of time of having to implement the same from scratch themselves. Software engineering isn't all algorithms and data structures. A lot of it is just boilerplate code hooking up A to B. And better leave that boilerplate code to the internal tool that you have to figure out how to configure than implement it yourself.
Amazon has a lot of bad internal tools, but this person's experience doesn't match mine (being here for 8 years) at all
> 40% of my time trying to tame the bad internal tooling I was forced to use to submit my code, get it merged, deploy it, check logs, etc…
The tools for code submission, pull requests, pipelines, metrics, and logging are fantastic. Google is better. Most companies aren't.
I have never spent 40% of my time battling internal tools....
> 20% of my time in meetings
Developers complain when they're not invited to meetings, and they complain when they're invited. On my team we brutally introspect the value of every meeting, and if it looks like it's not delivering value, we find a new process.
> 20% of my time writing unit tests to hit the 100% coverage requirement of the codebase I worked on.
This makes no sense. This isn't a company mandate, every team is free to determine what code coverage percentage makes sense for them. Give this feedback to your tech lead, nearest Sr. SDE or PE -> 100% test coverage should never be "required"
> 10% of my time tracking down bugs in other team’s codebases for either internal tools or frameworks and trying to get them to acknowledge the problem by filing tickets.
Everyone's interpreting this as AWS is zipping every customer's S3 data and improved storage of their data with ztsd.
That's now what Adrian said, and this is not an announcement - this was a "by-the-way" from a retired Amazonian.
AWS switched our own service's log storage (in S3) from gzip to ztsd a bunch of years ago -and reduced storage costs by 30%.
This is AWS's service data (which is still exabytes) and AWS realized the efficiency.
So all the comments of "where is my 30% discount" are offbase.
Since we're sharing anecdotes and that's good enough for this thread, here's my own:
I'm a white guy - pretty much a typical one. My manager is a white guy - possibly even more typical, follow along North American Dude Stereotypes for both of us.
For most of the last 2 years, he had 8 reports - 3 managers, 3 product managers, and 2 principal engineers (me being one of them).
I was the only white guys out of 8 - the rest were all Indian.
Why?
Because the other 6 were the best people for the job. They applied for it (some external, some internal), and we hired them, cuz they were rad (and still are).
Demographically, that just happens sometimes, including all-Indian reports
Another example of this is stuff like Bluesky. There's a lot of reasons to hate Twitter/X, but people going "Wow, Bluesky is so amazing, there's no ads and it's so much less toxic!" aren't complimenting Bluesky, they're just noting that it's smaller, has less attention, and so they don't have ads or the toxic masses YET.
GenAI image generation is an obvious vector for all sorts of problems, from copyrighted material, to real life people, to porn, and so on. OpenAI and Google have to be extraordinarily strict about this due to all the attention on them, and so end up locking down artistic expression dramatically.
Midjourney and Stable Diffision may have equal stature amongst tech people, but in the public sphere they're unknowns. So they can get away with more risk.