Nice & succinct problem definition for why ACLs are so important for everyone:
> Let me show you an example. You have a Redis instance and you plan to use the instance to do a new thing: delayed jobs processing. You get a library from the internet, and it looks to work well. Now why on the earth such library, that you don’t know line by line, should be able to call “FLUSHALL” and flush away your database instantly? Maybe the library test will have such command inside and you realize it when it’s too late. Or maybe you just hired a junior developer that is keeping calling “KEYS *” on the Redis instance, while your company Redis policy is “No KEYS command”.
Without ACLs we need to rely on command renaming or completely isolating databases to guard against errors. ACLs sound complicated but they're actually a solid user experience improvement.
The tldr here is that this is a nice recounting of personal experience interviewing with Uber and being frustrated by it, pointing out the many warning signs seen in the interview about a toxic work culture.
The post was prompted by the phenomenal writeup by Susan Fowler on her year working with Uber. If you can read only one, certainly read hers. If you can read only two, consider reading Susan's twice as it's exceptionally good writing. This is a nice (not exceptionally original) personal account of a bad interview experience.
> even for a small company, $8k/year is admittedly a small fraction of one engineer
This is certainly true, but overlooks the fact that many major products start out as experimental projects, and $8k/year is a significant investment for an experiment.
If there's a reasonable upgrade path from traditional databases like MySQL and Postgres this shouldn't be a big deal, but if the answer is "rewrite your app" it will probably be a friction point for adoption.
Capital expenditures might shed some light on this. I don't think there's enough public data to be clear but in 2015 Amazon (4.8B), Google (9.9B) and Microsoft (5.9B) were at least on the same order of magnitude in terms of CapEx, whereas other major "datacenter" companies like Rackspace (475M) are much smaller.
I don't think you can draw any definitive conclusions from this, but calling it a class of size 1 or 2 is probably an overstatement of Google (+/- Amazon)'s advantage over Microsoft at least.
Lots of downvotes here – any explanation? The GP uses the phrase "the phenomenon itself" referring to the Kantian term "Ding an sich", which (as applied to phenomena) is just a logical error...
Tangential, but why do people write things like "even after adjusting for inflation" when discussing long timespans (40 years in this case)?
Is there any reason to not adjust for inflation? The "even..." in the sentence suggests that the author is being liberal with potential critics when it would seem only rudimentary to acknowledge inflation when discussing a 40-year timespan. A typical (new) car cost ~$4.5k in 1977 in the US....
Author here. I completely agree. Embedded gists didn't have this annoyance when I wrote the article. I figured GitHub could be relied on to not change things up too much, but that's what I get for depending on an external service...
Lots of useful, successful things appear to be magic (especially in their selling points). Early Heroku is a great example in this space.
I didn't see anything in the initial premise of otto that was technically untenable. We could speculate about the "challenges" - the scope was too wide/unbounded, it was open source, it was a distraction from other company goals, it didn't gain enough early traction - but that's simply speculation without details from the creators.
It's too bad (and uncharacteristic of mitchellh) that this post is so light on specifics. Were the "previously unknown challenges" simply that not enough people adopted Otto? Or were there actual technical hurdles?
The premise of Otto isn't clearly flawed, so it would be interesting to see specific challenges - even if it's just "the problem space is way too big and not enough people wanted it"
> Languages are faster, development times are shorter, and chips are WAY faster.
This is due to Moore's law, not the software design choices that the article bemoans. Those $30k/month Sun servers were many times faster and cheaper than the earlier machines they replaced as well.
It doesn't need to be compared to anything to be called a mess. dpkg/rpm have been widely useful, but package and dependency management is still a PITA.
Even if you are genuinely curious, such inquiries from a boss/"authority figure" can easily come off as threatening, so tread very carefully with advice like that.
You get lockin issues with any vendor - even server colocation :)
AppEngine is a great tool for a great price. It scales smoothly with an affordable increase in pricing.
Heroku is sort of famous for getting too expensive at large scale. Their advantages are their ecosystem (most of the additional services listed in the OP can be installed quickly, and you're still only billed by Heroku), and their UIs which tend to be easy to understand and operate.
Their total costs between Heroku and Redis infrastructure are less than $3000. I don't think you'd be able to hire a devops engineer for less than $30k, anywhere.
It's surprising to me that people think they're spending a lot on infrastructure when they spend $800 on fonts, etc. When you drop the payment processor charges (which are per transaction) they're at $7k to run a site with a lot of functionality for a year. Seems pretty reasonable.
Is that a different question than "why you failed?" from the GP?