vivekl

Don't hold having an MBA against Jassy :). I have been in those ops meetings at AWS when Andy Jassy and Charlie Bell used to hold court. There wasn't much MBA-speak there. Jassy can burrow through deeply technical issues, spot fundamental flaws and process a monumental amount of information on the spot - skills they sure as hell don't teach at any B-school I know of...

This problem would have been even more pronounced if running from a co-lo/non-cloud entity. Imagine getting a court-ordered shutdown or confiscation of servers for evidence etc. Frankly you would expect a "high"-profile/controversial service like Parler to have at least conceived of the possibility of a take-down from a cloud service and had a plan in place for it. Amazon had already cut ties with Gab last year [1] so this should not have been a huge surprise.

[1] https://www.buzzfeednews.com/article/ryanmac/far-right-haven...

We reported this issue back in 2018 to AWS! In our case it was exacerbated because of a NAT through which traffic to the cross-AZ loadbalancer would flow. As mentioned in the article, the client side is free to reuse ports as long as the destination in the tuple is different - as would be the case for cross-AZ NLB.

We reduced the severity of this by randomizing port mappings on the NAT but that just reduces the probability. They claimed that it was a high priority issue for them back then but seems this is still in the wild - insane!

While AWS has ruffled a bunch of feathers with their Elasticsearch and Kafka managed offerings which can be easily construed as attempts to steam roll the respective open source-first entities, I am actually quite impressed by the mechanism that Azure has employed with Azure Managed Applications: https://docs.microsoft.com/en-us/azure/managed-applications/.... Hashicorp recently announced their collaboration with Azure to bring forth managed consul offering using this: https://www.hashicorp.com/blog/announcing-consul-service-on-...

This in my opinion is the right way to solve the problem, i.e. provide the customers that want a managed offering the means to get a managed version directly from the entity most active behind the project, (e.g. Hashicorp) while getting the most from the cloud provider's infrastructure. I would be willing to trust Confluent or Hashicorp with operating/managing my Kafka or consul cluster but taking another dependency on their respective cloud offerings should be of concern.

I am quite surprised that its Azure that has shown creativity here while AWS and Google have limited themselves to offering marketplace AMIs/images at ridiculous markups.

I am an SDE with Amazon having worked across AWS and the retail side. I have done over a hundred interviews in the past 2 years for SDE loops. Each of these involved a debrief led by bar raisers. I have yet to experience a "veto" by a bar raiser as outlined in this article. As far as I have experienced, the bar raisers' questions are not typically any more complicated or harsher than other interviewers. The main role of the bar raiser is in fact during the debrief, i.e. after the interviewee has completed the interviews.

At Amazon candidates are evaluated on an array of competencies. In addition to technical competencies, particular attention is paid to Amazon's leadership principles (the fact that these are displayed right at the careers page: http://www.amazon.com/b?node=239365011 should highlight how important these are in the culture). I love that culture-fit and leadership qualities play as big a part as technical abilities in Amazon's decision making process unlike what I have seen in some of the other companies people mention in the same breath as Amazon. In my experience a good bar raiser acts as an unbiased advocate for the greater good of the company. As a result, they are NOT from the same team with the open position (this doesn't mean that an accountant is judging an engineering candidate or vice-versa mind you, they just happen to be from a different org) which allows them to look-past the immediate need the team might have which could blind them to some of the obvious flaws in the candidate. In some ways they are also acting on behalf of the candidate by ensuring the match works both ways. I have seen several situations where the bar raiser determined that the "team" or the "role" were poorer fit for the candidate than the other way around and went out of their way to facilitate a correction.

That said, there is no question that good bar raisers are just as, if not harder to come by than good employees! It is a thankless, demanding assignment to take. I have met some absolutely amazing bar raisers and some others that are just darn right atrocious. Considering how quickly Amazon is growing, they definitely need more of them but that risks damage through poorer ones entering the system.

With apparently 5 mn users, Microsoft just paid ~$200 per user... C.R.A.Z.Y. This just beat Instagram to a pulp as the yard stick for ridiculous valuation. When do I see an Oatmeal comic on this?

Watched the video. It appears MS is making a magnetic keyboard! ...And you get some sort of a tablet with it.

I think the problem also depends on what kind of virtual disk you end up using. Let me ellaborate:

I dont think the problem is purely buffered vs. unbuffered IO. The guest operating system will have performed some block coalescing anyway so the block requests will often NOT be 4K chunks but should have slightly larger granularity. However, if you use a COW based virtual disk layout like QCOW2 which I guess is standard in KVM, you may see additional scattered IO.

I think it is weird to be using COW virtual disk layouts on a file system that natively supports COW as is the case with BTRFS. I would be curious to see what the performance of raw sparse files on BTRFS is vs. qcow2 etc.

Hats off to the Xen developers like Jeremy Fitzhardinge and others that persevered despite what was quite stiff resistance from the Linux community initially! Just to clarify, the major stumbling block was the Dom0 - Xen's privileged domain which has normally been a fairly heavily customized Linux kernel. A number of the DomU/guest components were already in the mainline for a while. Then the core Dom0 components went in around 2.6.37. And now all the PV backend drivers etc. are now in as well, paving the way for a vanilla Linux kernel to be a fully functional dom0 under Xen.

Having watched the back-and-forth between the Xen and Linux community over this inclusion business a bit, I feel the delay has actually been worth it in hindsight. Linux's pvops abstraction is clean and impartial. With this Linux has support for at least 3 virtualization technologies out of the box: KVM, Xen, and lguest. Also, a lot of the jagged edges in the Xen dom0 patches have been smoothed in this process.

This is also great news for private and public Xen-based deployments as well as companies such as Oracle, Suse and others that built their own virtualization platforms on top of Xen. Trying to get supported, well-tested drivers for new hardware working with Xen has often been a major pain point and required significant engineering resources. This was a major reason why Ubuntu switched to KVM officially (Red Hat led the charge here but that was mostly because they bought Qumranet - the company that built KVM). With this Xen is significantly more maintainable and I expect to see at least some of the distros to re-include xen as a virtualization option fairly soon!

Clearly you mean oracle here. Being an ex RH-er I can tell you RH sees great value in centos. It keeps small shops on the RH reserve even if they don't pay for a support contract - yet. Oracle has recently tried to position itself as an "enhanced" rhel especially wrt the kernel and this seems like an attempt by RH to make things a bit harder for them. I don't agree with the move though - you don't want to follow oracle down such slippery slopes...