67 karma · joined December 20, 2010
[1] https://www.buzzfeednews.com/article/ryanmac/far-right-haven...
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!
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.
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.
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.
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!