sharpy

S3 bucket names are globally scoped - ie. they are literally scarce resources.

"ACeP achieves a full color gamut, including all eight primary colors, using only colored pigments."

...

I want one now :-)

I always felt that F-35B at least should have been its own design. As for A & C, there have been successful examples of naval aircraft being used by air forces too - such as F-4, and F/A-18. But trying to have a design that is also STOVL capable?

It was probably largely written by Ada programmers transitioning to C++, along with people with prior C++ experience but with no/little experience writing mission critical software.

Read-only DB. Think of it as read-only memory mapped key/value store.

It really depends on how much they want you, and how you negotiate. I recently changed jobs. I ended up getting multiple offers, and for all but 1 of them, they were willing to wait 3 weeks for me to make a decision. I was very upfront about that if they were not, I wasn't interested in them, however.

Interesting. It seems that Google IAM is very similar to AWS IAM yet very different in one aspect. In AWS, you can define exactly what subset of APIs/resources are accessible to a role, which is very flexible, but also can be very confusing. It seems Google has taken the approach of pre-defining sensible roles.

Some places I interviewed did mostly whiteboarding, but had a problem that required producing working code. One place had a standard desktop setup aside for me - with the most popular IDEs pre-installed. Another had me bring my laptop.

+1

Not to mention that often it can takes weeks for new hardware order to be approved / delivered / provisioned.

Cloud? Just dial it up... Well, if you are at Netflix scale, you probably couldn't just dial it up, and would have to work with the vendor to ensure adequate capacity was available for your use.

Right.

If you look at the API, the publish API allows you to push multiple messages in a single API call, and if that is the batching - publishing multiple messages - then yes, you and others are absolutely correct that there is no cost benefit.

But rather than publishing

{ "messages" : [ { message 1 }, { message 2 } ] }

You publish

{ "messages" : [ { container message containing both, still less than 64k } ] }

Then you've reduced your operations count by half. Cloud services like this have a per message overhead, for things like auditing and delivery tracking, which is why the pricing model is what it is.

If you are ok with having to unpack and process multiple messages at once as I've described, then it's a way to optimize against the pricing model.

They are wrapping small events into fewer larger ones. Hence the word batching.

I have 64 1k messages? Ok, I am going to put them inside a single 64k message and reduce my request count by 64x, and profit!

Just wanted to say thanks for posting this. Loved it.

That's an interesting cycle.

I had one of the IBM Deskstar (aka. Deathstar for the high failure rate). IBM sold the HDD business to Hitachi, who sold it to WD.

And now, Deskstars are as reliable as they come.

They hired me despite my not knowing any Java. I was there for close to 5 years and did my share of interviewing and I haven't seen a single instance where lack of specific programming language skill was brought up as a reason to reject the candidate. But yeh, the whole hiring process is more random than it should be.

There are different forces at play.

On one hand, one can design a service with minimum dependencies to survive other services' outages, but that means duplication of effort and increased cost, as well as slower delivery of features. Or one can focus on adding value.

It seems though, from the update, that CloudWatch is going to have some sort of caching for most recent data.

Disclaimer: I'm a software engineer working for AWS. But not on EC2.

I feel the margin number conclusion is deeply flawed for variety of reasons.

There are some questions the author cannot have answers for, that greatly change the margin numbers for EC2. A couple that comes to mind are:

1. What percentage of time are customers being charged for the available servers? 2. What percentage of instance hours are being charged at on-demand prices, vs reserved instance?

Also it completely ignores services that makes EC2 stand out from plain hosting, and adds much value, such as AutoScaling, CloudWatch, Elastic Load Balancing, OpsWorks, and Elastic BeanStalk. And believe me when I say that support cost is NOT trivial. In many cases, the number of engineer hours involved makes the support pricing look like a real bargain.

Doing so allows customers to easily view the total estimated spend, rather than having to go to each region and add it up.

Hi,

There are a couple of things that are easy to overlook when using billing metrics.

1. All billing metrics are stored in us-east-1 even for usages in other regions.

2. If you are using consolidated billing, billing metrics will be published under the linked account, and will only be visible to that account.

Hope that helps.