Large enterprise customers tend to buy "enterprise" grade hardware. Which, these days, is mostly just a fancy case with a label stuck on the front and a warranty. Amazon doesn't run expensive hardware, they run cheap hardware, and mark it up enough as a "cloud service" to make a good profit but still undercut the expensive hardware vendors. Essentially, you're paying Amazon for a warranty. If you're spending $100M/year on hosting you should be able to run your own cloud for less than AWS charges you but in order to do that you need to let go of the enterprise vendor security blanket.

Have you ever really looked at what cloud services provide? You would like to believe that if a physical server at Amazon goes down that you're just fine - the fact is that no, you're probably pretty screwed. Even worse if they lose an "availability zone". And those are just hardware failures. Just wait until they f-up a software release. When I spec'd data centers we would typically require at least two different carriers with no common points of failures for internet connectivity. Are you doing that with your cloud providers?

Cloud services are not as robust as they are portrayed to be. In order to reach that level of robustness you need to engineer your applications to fail-over between servers and availability zone and even cloud service providers.

Uber has different levels of service. This appears to be a crackdown on "UberX" which lets anyone drive for extra cash. There's also "Black Car" which uses limousine services (i.e. "Town Cars") which are licensed and insured. That probably remains legal unless there is some problem with them picking up fares anywhere.

We used Uber Black Car and regular taxis in San Francisco recently. San Francisco taxis have really gone to the dogs - we had one driver who did nothing except talk on the phone and swerved in and out of traffic. The limo drivers were much nicer, the cars were nicer and the price was about the same.

I think you're thinking of Single Stage To Orbit (SSTO). DC-X was pretty cool and had a strong possibility of working until they gave it to NASA who promptly broke the prototype and then poured billions of dollars into VentureStar only to give up before ever completing a vehicle.

SSTO is pretty marginal. You do need a high mass fraction to pull it off. The DC-X people thought they could but they never got far enough along to actually have it happen. However, multiple stages is proven technology and the first stage, especially, has usually got some margin.

In any case, we can armchair quarterback all day with no effect. SpaceX is actually DOING which is damned impressive to me.

Salt water is a big problem - the SpaceX plan appears to be to land the booster back at the pad, though, not in the water. No one has ever gotten a booster to fly back after a launch before, so that's a pretty big score for them.

It's easy to say "can't, too expensive, why are you wasting your money?" - the fun thing here is that SpaceX is wasting their own money, not the government's (the government is paying for the launches but not the experimental part). Maybe they'll be right, maybe they'll be wrong. However, they are trying and that's pretty exciting.

Probably not. Datacenters don't employ very many people. It's easy enough to fly in specialists to set them up and debug the really ugly problems.

Montana's total population is just slightly above 1 million. SF Bay Area is more like 7.4 million with a much higher percentage of tech workers. So, no, Montana isn't going to be the next tech hub because there aren't enough workers there. Might be a place for DC's if there's enough bandwidth.

Thank you!

I read a few of those long long ago but don't remember many plot details except maybe for some anti-Force sloths. Were Han, Luke and Leia in those novels and if so, how old were they? That may be part of the problem in adapting them.

Really? Apple nearly went out of business in the late 90's because of that business model. You can only go for big margins when your products offer major value over the competition.

Code fixes are all fine and well but where the real thought needs to be going is how to verify these protocols. The basic problem with security is that "working" doesn't mean "secure". Most people focus on testing for "working" and given the bugs that have shown up in OpenSSL and its cousin in the last month or so, the problem is not that they don't work (that is, interoperate and transmit data) but that they have corner cases and API holes that are major security concerns. Some real thought needs to be put into the testing of secure systems and how to verify that they not only "work" but are actually secure.

This is a good point. There are times and places where adversarial relationships are good. Just bringing different viewpoints in is good.

A colleague said to me once, "You're the only VP I've ever known who installs equipment." I'm always amazed at how out of touch "senior" people can get. And besides, when we get new toys I want to see them working NOW.

There's definitely truth to what he's saying but it cuts the other direction as well. Having your lead guru developer swapping disk drives on a machine isn't the best use of his time. However, I've also seen environments where the developers can't/won't/aren't allow to do the system admin tasks and wind up waiting around or being frustrated when their development systems have a problem. Likewise, with QA - I've seen developers that will just toss any old crap over the wall and expect QA to catch all of their bugs. And, developing tests is often software engineering, often complex software engineering that needs an experienced developer to establish at least the outline of how everything works.

Personally, I expect any developers I'm working with to have at least basic sys admin abilities and know how to setup/fix any other part of the stack they might touch. Those skills should be used when working with the dev systems and in establishing the base line for production. I would then expect that someone who is more specialized in those other roles to actually setup and run production and also be available when the developers get in over their heads on system admin, hardware troubleshooting, etc. In the same way I would expect a systems admin to at least be able to write a script to automate something and not go running to the developers for everything.

For test development, I always like to set groups against each other and develop the test suite for each other's code. Most people are a lot more comfortable and eager to break someone else's code than they are their own.

The article focused on how Amazon cuts hardware costs. The first step there is a big one - once you let go of buying name brand hardware, especially for storage, the price drop dramatically. So dramatically, in fact, that hosting (largely electricity, cooling and network connectivity) becomes the major cost in the equation. Amazon is pushing for extremely high density, however, that has a ripple effect throughout your whole datacenter design. If you're not in a high cost area, you might ask why focus on density because floor space is relatively cheap.