gshx

Thanks for the bullets. This is a good list but some of the points like "Easily scalable" and "DB support" are not cheaply available in any runtime and require careful attention to detail as well as domain-specific thinking. IMHO, the JVM already does a lot of heavy-lifting in this regard.

This looks very good. At the moment, for the jvm, there are not a lot of features above simply building services using netty and the protobufdecoder/encoder. Similarly, http2 goodness is also already available in netty.

This translates exceptionally well to fields other than basketball, as well. I wish this "magically gifted engineer just needing to work 3hrs a day making e'thing look so easy" profile goes away.

One big challenge is the expense that is otherwise avoided via usage of connection pooling. Without the hack to keep the backing containers alive, tearing down and restarting them is expensive and wipes out all hot path optimizations made by JIT compilers besides having to reestablish connections and pay the handshake prices. Apart from the simplest of use-cases at this time, imho this is not an efficient model if sustained performance and low latency are of interest.

Reminded me of all the hours spent debugging with dbx. Turns out, even after all the yrs, they are still quite similar.

Does anyone have real prod scale numbers - even order of magnitude concurrency would be helpful. We're obviously very wary of trying out new and young data stores.

Your point is well-taken. This qn comes up often enough for similar use cases and hence I asked if someone has data to support an arg. Considering the criticality of Zk in the larger stack and our success and operational expertise with it, it has to take significant convincing to switch to something like etcd.

The following two paragraphs from the etcd project site seem to hint that they're trying to target overlapping use cases: "Your applications can read and write data into etcd. A simple use-case is to store database connection details or feature flags in etcd as key value pairs. These values can be watched, allowing your app to reconfigure itself when they change.

Advanced uses take advantage of the consistency guarantees to implement database leader elections or do distributed locking across a cluster of workers."

Does someone have any benchmarks or comparisons with Zk? We have run it for many yrs without a problem and are very happy with it. Would be interested in hearing from anyone who switched from zk->etcd for distributed locking, presence, leader election type idioms and ran it in prod for a few months/yrs and their takeaways.

Care to give some examples how? For me, Eclipse has remained very stable. Maybe we are using them for different languages and/or things.

Go-lang is good but not as mature. Other than that, there's C++ and Erlang/Elixir. Not a whole lot of mature choices out there. For most of the critical production grade systems that need to be secure, have to scale and perform predictably, you don't want to blaze the trail.

Would also be interested to hear more about the "deployment nightmares with Zookeeper". For us, it has to be one of the most stable pieces of 3rd party server software we run.

Very nice, now that we have some good competition in this space - kafka, ddl and wormhole. If only Fb can open src wormhole, there will be some good related systems software to choose from and contribute to.

You're right. I was mostly commenting on the common idiomatic ways ppl differentiate streams vs queues. Indeed, it can be used in both scenarios.

It can be used as a queue but the bigger benefit is for streaming use cases. One of the key differences, among others, is that streaming assumes somewhat faster consumers as opposed to queueing. There's also the pub-sub use-case which is generally considered separate from that of a queue (considered a point to point transport).

I have had good results with Yourkit. And so far in my experience, that is the only profiler that has been able to survive profiling busy services running large heaps. ymmv.

Can you cite some examples? Did these companies decide to run containers on vm's or just bare metal? In the latter case, they shouldn't need 3 to 4 times more hardware. Your point on capacity planning is well taken. Capacity will always be finite and especially critical to put an upper bound on if doing container based services with multi-tenancy.

There are other concerns to keep in mind, eg. the upgradability of storage to use next gen cards that use 3d nand, etc. I'm sure they thought through a list of concerns before going this route.

Not at all, cost/TB of S3 is much higher compared to what you can build provided you know how to build it yourself.

The other problem with Lambda is that you cannot keep persistent connections in a connection pool. It is after all, designed for statelessness. This can be considerable cost for doing calls to other business services (http connection pools) or infra services like databases that all maintain persistent connections.

Content and programming are still quite limited. There are a few good original shows. Also, they keep adding a lot of movies with poor ratings (rotten tomatoes). There's definitely potential for some disruption in this space. Also, some more competition from others would be nice.

Agree with your comment wholeheartedly. My comment was mostly around business information flow to the market since that's regulated due to various reasons.

For one, this: "makes it easy for all employees to.." work with business insights data is usually inaccessible to everyone for a reason.

A lot of the agents typically don't point out any of those things anyway. They're incentivized to make the deal and really paid by the Seller. If both the Buyer and Seller were paying, that might be an altogether different story and it might actually work out better. Having gone through the buying/selling process a few times, I would much rather deal with an unbiased automated system.

If Zillow can solve the "problem" of putting all the docs (disclosures, inspections, offer docs, title docs later on, etc) up with the listing along with making a network of handymen (to help out with prettifying a house for sale), most buyers and sellers will be happy to pay them 0.5-1% instead of the seller having to pay the agents 4-5%. There's generally not a whole lot of work in buying or selling a house including agents doing events like open houses and helping with "discovery" and the buyer-seller matching problem. The offer process itself is also quite simple and can be done online. That said, the one benefit of an open house/tour hosted by a neutral party, is that it lets potential buyers easily assess a house without having a biased seller in attendance. This can also be managed and does not really require a real estate agent. Zillow and similar services like Trulia have a fantastic market opportunity in front of them.

Running multi-region services has associated costs. It's also non-trivial engineering effort to convert most services to a multi-region setup. It's definitely worth the investment though. Another option is to run multi-region on the same provider (like AWS) without using proprietary services like DynamoDb but maybe something similar like Cassandra.

Seems like too much fluff - both the acquirer generating it and the acquisition itself. It would be helpful to see why/where one would use node.js when other platforms support many more workloads well than just pure I/O bound ones. In the "enterprise middleware", going native (C++) or managed (JVM/CLR) brings with it a much richer ecosystem alongwith a more robust runtime that can better support other workloads that entail for example cpu binding. It's hard to see a real need for node.js as it seems to not do anything significantly better than other platform options.

Amzn seem to have it: http://www.amazon.in/s/ref=nb_sb_noss_2?url=search-alias%3Da...

HBase also did well. They need to blog about it. There was a related jira ticket I read through: https://issues.apache.org/jira/browse/HBASE-9719

Also, an old blog entry from yammer engg. blog: http://old.eng.yammer.com/call-me-maybe-hbase/

Agree, it should be easier. After registering, think it's possible to sign-in to most of the adsk systems via either the email/passwd or adsk-id/passwd combination.

Might want to start here: http://www.autodesk.com/campaigns/stingray