deitcher

I like the idea, but I wonder if it will ever take off. So many "build in your preferred language, publish to some other" platforms have been released, it is hard to keep track.

I will admit that html+css is a relatively good (set of) language(s) to describe a UI, and JS is the way to tie the dynamism together and provide client-side logic. But is it better than just learning the native version for each platform?

I have used this in the past with success. It does its job.

The headline makes me think of NoSQL. The NoSQL (poor nomenclature) movement came about because of limitations with decades-old SQL. I don't think such problems exist with REST, which is still fairly young.

More importantly, REST created a relatively clean and clear API that almost anyone can understand for any service. Sure, it does vary, as it is not "standard", and every site has their own resources and paths, but the learning curve to a new API is dramatically lower.

Yes, absolutely. Which means you need to architect and run expecting failure, which is so much different than traditional apps. (I am calling architectures 10 years old, "traditional"; that is funny.)

"by the way, your rack is on fire." LOL!

You are 100% correct. That is why the article explicitly listed it as an assumption, and that the advantage for public cloud over private hardware is even better once you account for that.

@jasode, actually, that is the exact point of the article. Non-Moore's-Law-subject costs are, at a bare minimum, 60% of the fully-loaded costs, probably more. All of that means that AWS costs should drop much slower than Moore's Law, about 60% slower. And yet, they keep dropping at a fast clip. Most of that would be due to Amazon's innovation and scale on everything beyond Moore's-Law-subject components.

I think we are agreeing.

Excellent. I like the numbers - it took a long time to hunt down numbers, the GigaOM article would have helped - but it is the underlying costs beyond the hardware that make it so.

@amelius, I haven't though of software from that perspective. App servers, Web servers, databases and a lot of middleware have gone down that path.

Have you written it up? I would like to see a write-up on that.

Yes, definitely. But it is cheaper to have sufficient admins to manage 100 VM instances, than sufficient admins to manage 100 VM instances plus the underlying 20 physical servers and 3 switches and 2 routers and 2 firewalls and storage arrays and...

I always found beyond a certain scale that AWS was not cheaper, but lately I am questioning even that. Next client who is considering going public cloud, I will need to redo my spreadsheets.

OK, but who pays for 4K 30fps at $600 other than pros?

I wish they could have done things like this when I was learning signals and transforms as an undergrad. But interactive didn't really exist in the early 90s.

I never considered that point. Do AWS prices fall slower than Moore's law, and do they fall slower than the prices of the underlying equipment?

I have managed a goodly number of AWS implementations and considerations ("should we do it or not?"). AWS was cheaper in most cases not because of bare metal vs AWS, but because of the sheer efficiency of scale, and not having to hire staff and expertise to manage all of the infrastructure.

Hmm... you just inspired a new post. Thanks, noelwelsh!

I think the Motorola and Xiaomi effects are more severe. It is one thing to compare a $500-600 Samsung S5/S6 vs $600-800 iPhone 6/+. It is a whole other to compare a $150-200 Moto E/G vs $600-800 iPhone.

There are also ecosystem effects. Apple vs Android is Apple ecosystem (iMessage, FaceTime, history of app purchases, etc.) vs Android, but at a price premium that (a) is only 1.5-2x and (b) is generally better hardware and software. If it is worth 1.5-2x is arguable.

GoPro vs a competitor is a 3-5x premium for something that is nearly completely interchangeable.

Depends who the investors are. I know some really first-class ones... then again, I know some dumb ones...

"bad code is often immortal." I have to remember to quote that!

And that is the key IMHO. Closed-source requires enough commercial incentive by one firm to look at it. Open-source requires enough incentive in the aggregate across many problem, each of whom may have their own reasons... and who cares what they are.

Most bugs I have seen figured out have been a collaborative effort. One person finds one part, which leads to the next person figuring something else out, etc. Much harder to do when it is just your job, and you may not even be paid for this work.

Eh. Investors invest in lots of companies, some of which make pretty bad mistakes. I think Superfish should be forced to wither on the vine because of this - and especially because it pawned off responsibility by saying, "hey, it was those guys, not us!" as should Lenovo ("it is just theoretical!"), but I doubt the investors explicitly backed something with the intent to break security. Few do.

I write a technology business article a day; darn near impossible to come up with good titles daily. Still, I'd rather have a good title, then an awful title, and only last a boring title.

I take it back. Lenovo could be even more stupid. Did you see the comments by their CTO about how their problems are just "theoretical"?

I made up the title and I still had to laugh!

In all seriousness, how stupid could Lenovo really be?