uji

AWS/Amazon might be great for customers but it's a horrible place to work. Having worked in AWS for 3 years, almost all services are half baked, tech debt filled in all parts of the code. But hey, we never see any issue? It's because it has army of oncallers who are manually running commands and fixing issues.

I used to work in one of the DB services and we used to get 20+ pages (sev2) every day. Due to insane amount of pages every day, we used to have daily on-call rotations.

High Level Features:

1. VMs are dual-stack.

2. Subnets can have either GUA or ULA addressing along with IPv4.

3. Subnets are /64 and VMs get /96 address.

4. ULA addressing is useful for intra VPC traffic.

5. GUA addressing is useful if internet facing connection is required.

6. VMs can have multiple IPv6 NICs.

Looks like pretty good news. Have worked in AWS before. So AWS is very famous for making money using open source products without contributing upstream.

One very good example is Amazon redis. Amazon figured out that redis asynchronous replication didn't work at scale so instead of fixing issues upstream they chose to develop Amazon redis in house and monetized it.

https://aws.amazon.com/memorydb/

Enhanced version means patched made by AWS. https://aws.amazon.com/elasticache/redis-details/

It is already supported. https://cloud.google.com/compute/docs/ip-addresses/configure...

yes. you can use /64 subnets to define your broader level firewall rules.

This is very true. It doesn't lead to PIP always but whole amazonian culture makes it difficult for the person to stay in team/company.

Writing COE is kind of admission of guilt and I have definitely seen promotions getting delayed. During perf-review, lot of times managers of other teams raise COE has a point against the person going for promotion.

Have worked at AWS before, and I can attest to this. Whenever we had an outage, our director and senior manager would take a call on whether to update the dashboard or not.

Having 'red' dashboard catches lot of eyes, so people responsible for making this decision always look at it from political point of view.

As a dev oncall, we used to get 20 sev2s per day (an oncall ticket which needs to be handled within 15 mins) so most of the time things are broken, its just that its not visible to external customers through dashboard.

ex-AWS employee here. I worked in one of the managed services (can't say which one because it might reveal my identity). In Managed services, instances are created in AWS VPC so employees have access to underlying VM.

We have used that capability to get stats about the type of customer workloads, and devised feature products based on that.

Having worked at amazon for 3 years. I don't find it surprising. Amazon, in general, is known for not taking good care of its employees. My experience has been as SWE and its a well know fact of there that if you and your manager don't get along then you have limited time to move to a different team or company before you get PIPed.

A better comparison would be between Azure and GCP, both of them provide office suite (SAAS) to customers.

Google recently released its side of the numbers (https://cloud.google.com/blog/topics/inside-google-cloud/how...)

Related to https://twitter.com/thousandeyes/status/1062102171506765825

https://twitter.com/thousandeyes/status/1062102171506765825

Great to see google open sourcing its internal cpp libraries.

This totally sounds like it can happen at Amazon. I worked at Amazon for sometime and for the first time in my life, I saw a grown up man crying because his manager was relentlessly shouting on him. I have never seen this level of heated arguments in a workplace.

Given that WA state doesn't have income tax. I am assuming it must be quite difficult to introduce city income tax. What exactly are the issues here?

Worked in an AWS team, and the biggest issue was constant fire-fighting and oncall/operational load. Code quality is really bad across all teams in AWS due to constant prioritization of features over stability. We use to get 20 pages a day, and it was very common to get 2-3 pages in the middle of night. It was horrible and yet management didn't pay much attention on fixing it. At the end devs starting leaving the team one by one. Recently I heard that the team hired twice the number of devs to reduce frequency of oncall rotation.

It seems this service is targeted towards specific applications where write traffic is somewhat independent between 2 regions. However, you can shoot yourself in foot, if 2 regions are trying to update the same row, because of eventual consistency.

how many NICs can you attach to these?

I have observed the same. In my masters, Chinese friends were asked to join meetups and classes for improving english speaking. When I asked how they cleared Toefl(https://www.ets.org/toefl), which is required along with GRE score for getting admissions into US university, they mentioned its very easy to buy these scores. Somebody appears on their behalf in the test.

I don't agree with this article. Lets say a company was managing a mysql like database by themselves which would require a full time database maintainer doing all sorts of devops work. However, if company moves to AWS and starts using RDS, it might only need a part time db maintainer. So company indeed save some devops work like pushing security patches, monitoring etc.

This is certainly good for India. I predict, over time, cash-less transactions in India will increase, as more companies start investing in cashless transactions.

Is Amazon comfortable enough to create single point of failure. What if DDB goes down assuming they run same stack for both retail and AWS?

Terminal support? To be fair, sublime text is great and I use it sometimes, but if your job requires you to work over ssh then vim definitely beats all modern editors.

I agree with rothbardrand@ here, I recently moved from AWS. Amazon is very top-down where developers are heavily managed by their immediate managers (and thats why they need so many MBAs). Our team of 15 engineers had 4 managers, who would push engineers to the edge to meet deadlines. From what I observed, this leads to very high turnover rate, and teams with lot of junior engineers who are asked to assume roles of previous project leads. New hires are brainwashed about increase ownership and responsbility. But after some years, they all realize the game and move over to different company.

Seems like this limitation has been for long time (since 2009). Curious to know how everyone has been using ELB. To me, ELB seems to be an unfinished product. It must be painful to first predict heavy load on your application and then notify AWS well in advance.

After nytimes articles, Amazon seriously has started improving its culture. Managers though still have same mindset of treating employees as replaceable resources. This is one instance after the article came out. My pregnant friend one day sent an email that she would be WFH as she isn't feeling well. Manager replied back that this is not acceptable and you should give a week of notice for your plans.

This might be okay in other fields, but in tech WFH is considered a perk and companies don't care as long as you do your work.

All vendors are trying to lock-in in their cloud ecosystem and differences between their service offerings makes it very difficult to run same benchmarks on all of them. This put customers in dilemma: which vendor to use or if they should migrate to other.

Good or bad thing?

I don't think this is completely true. I was with AWS for 3 years as SW engineer and was working around 12 hours until I decided to switch. AWS has pretty messed up softwar services with lot of technical debt. Rather than fixing these, AWS relies on oncall (pager duty) to mitigate production issues. My team use to get 200 pages a week.

GCloud recently updated their free-tier (https://cloud.google.com/free/). They provide $300 credit which can be used for any product in GCP, and some services when used within quota are always free. So you might want to give GCP a try for your low-traffic side projects.