Hacker Newsnew | comments | show | ask | jobs | submit | latch's comments login

Yes, it is.

"If you’re used to designing and deploying applications in your own data centers, you need to be prepared to unlearn a lot of what you know."

Which is it? Did it save them money because they didn't have to "build their own redundancy and failover" or did they have to build a bunch of custom tools like Chaos Monkey because "I knew to expect higher rates of individual instance failure in AWS, but I hadn’t thought through some of these sorts of implications." ???

From reading Netflix' blog, it's clear that it was a huge learning and engineering effort. That cost has to be taken into account and added to the fact that across many AWS offerings, you're looking at as much as a 10x price / performance penalty versus dedicated or collocation. I'm unconvinced that they couldn't have done it cheaper and better through more transitional approaches, and moreso that it's a meaningful indicator for anyone else.

AWS has been massively innovative. But it's much more expensive, and a huge part of their business is sales and getting CXOs onboard, not necessarily providing good value.

-----


"That cost has to be taken into account and added to the fact that across many AWS offerings, you're looking at as much as a 10x price / performance penalty versus dedicated or collocation."

This.

The pricing is especially egrerious in bandwidth charges which for AWS are almost pure profit.

Amazon is only cheap if you don't use it.

-----


I've heard that the prices are egregious only in bandwidth charges and that other things were not as bad. Does anyone have concrete numbers to compare?

-----


Not sure that I buy into the argument that negotiating salary is "competitive thinking". The goal is to reach a compromise that everyone is happy with, which, to me, seems rather cooperative.

-----


Tangentially, what's impressive about Shanghai's metro is how quickly it became the longest. It essentially went from nothing to the longest in 15 years.

Compared to the 20 years it took the Big Dig, or my own home city which has been talking / debating / purchasing / cancelling / assessing / suing re mass-transit, it really is an impressive achievement.

-----


not to mention that it's so little memory that you can treat the live version as read-only and swap in new versions.

-----


No. It could be simple ignorance. Or an accident.

In your world, what is it at worst? Criminal? Capital?

-----


Agreed that it could be either of those things. I'm not trying to excuse criminal behavior at all, rather stating that if one puts an unauthenticated database on the internet, it's going to be compromised. For software professionals, my opinion is that to do so would be negligent.

-----


An ignorance is an excuse for compromising your company or customer's data in exactly what situations? Let's just all cover our eyes and not look, then the data will be safe I'm sure.

-----


Of course it depends on the context. I don't know if it's reasonable to expect a small family clinic, therapist, or dental office to secure their client information. It seems that people just mass scan the internet looking for already known vulnerabilities.

However, if it's a mid-sized business handling important information, like payment information, then I do think there ought to be a standard of dutiful behavior, because otherwise who pays for the externalities?

-----


It could also be leftover testing systems that haven't been torn down yet, with nothing interesting in them. The internet is full of them.

-----


KFC is definitely more popular than McDonalds in Asia. Chicken and pork are much more popular than beef. I've always assumed it had to do with the stupendously inefficient nature of beef in terms of cost & land.

-----


I went to KFC the other day, since the McDonald's next door was way too busy. KFC doesn't always do better than McDs, at least in Beijing.

-----


Beef is also taboo in India.

-----


McPaneer sandwich index?

-----


Did you mean to say that they are quite UNexpensive? (because they are)

-----


Your sibling posts pick much, much stronger arguments.

"This is not a peace. It is an armistice for twenty years"

-----


It isn't XHTML. Closing <p> tags are optional (which is true for many tags). You don't even need opening HTML, HEAD or BODY tags.

-----


That's only true in very specific cases: https://developer.mozilla.org/en/docs/Web/HTML/Element/p

The start tag is mandatory. The end tag may be omitted if the <p> element is immediately followed by an <address>, <article>, <aside>, <blockquote>, <div>, <dl>, <fieldset>, <footer>, <form>, <h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <header>, <hr>, <menu>, <nav>, <ol>, <pre>, <section>, <table>, <ul> or another <p> element, or if there is no more content in the parent element and the parent element is not an <a> element.

-----


And "there is no more content in the parent element" applies here.

Actually, what you call "very specific cases" are in fact, well, all reasonable cases. That list consists of all block level elements that can appear in `body`, so the statement could be reworded, that "<p> cannot contain any block-level element, so any inline element after <p> falls in, any block level element ends opened <p>".

Funny fact is that presence of optional end tags means nearly nothing for HTML parsers used in current browsers, they just ignore them. Some border cases regarding white space exists, or at least existed in the past, but in general, if you feed browser with document

    <!doctype html><html><head><title>a</title></head><body><table><tbody><tr><td><p>b</p></td></tr></tbody></table></body></html>`
or

    <!doctype html><title>a</title><table><tr><td><p>b</table>`
makes absolutely no difference. Both will result in exactly same DOM tree, both are "100% valid W3C HTML documents".

-----


I'm a fan of Go and have been using it for a [relatively] long time across various large and small systems.

I really like it.

To me, what's been abundantly clear is that: it's a horrible choice for types of apps a lot of people are using it for. Specifically, systems where ror/django/express/php have traditionally excelled at. I'd say "CRUD", but that's too narrow. The expressiveness and productivity of dynamic languages continues to awe me. This is particularly true for web systems that, on one end, deal with the object-relational mismatch and on the other transforms and outputs json or html.

Go's great, but it feels like we've forgotten some of the pain-driven lessons Hibernate and their ilk taught us.

-----


This is sort of the conclusion I've come to in the last few weeks as I think about and research in preparation for my next startup. I learned to code with C / Perl in the late 90's, moved to scripted/interpreted "web" languages like ColdFusion, PHP, RoR, JS, and about a year ago I finally decided to build a toy project with Go for Google App Engine. I found the process really instructional, but ultimately pretty frustrating. I fall very much into the author's second camp; it's not the language for me, for what I want to use it for. I'm building a pure web app, with very little systems orchestration need (outside standard devops). Go seems like a great fit for building Docker, but a poor fit for building AirBnB. Especially at first, when I'm likely to be the only programmer for 12-18 months, it seems to me that Go is a poor choice to begin with. It loads too much technical debt (probably the wrong term) onto our startup at a time when we need to move fast and break things. If we are hugely successful and we end up with 20 programmers in 3-5 years, then maybe it'll be time to re-architect key microservices in golang. Until then, I think RoR makes the most sense for us.

I've been looking for someone to verbalize this train of thought for a few weeks.

-----


I keep wondering whether the lack of generics is in part intended to make people not even try and implement Hibernate but to accept using a lower level of abstraction instead.

-----


Please tell me more about the pain-driven lessons Hibernate and their ilk taught us

-----


We learned that you can't configure your way out of impedance mismatches. You can certainly make your life easier, but only at the cost of also making it harder.

You essentially need language-level support for dealing with data at your boundaries. Even with Java's strong reflection (Go's reflection is horrible) capabilities and generics (and C# extending that with lambdas and expression trees), there's still tremendous friction and boilerplate configuration and code.

Consider Dependency Injection, an ilk. In most (all?) dynamic languages, DI is a language concern, as opposed to a library concern. By having support for it within the language, the problems DI frameworks attempted to solve in Java (or C#) via messy configurations, legalese-like unit tests and quantities of code dedicated to nothing but the infrastructure of the codebase, simply vanishes. Now people are going to Go and discovering the awesomeness of interfaces.

-----

More

Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: