My goal wasn't to give specific advice to people in certain situations. My examples are hypothetical; maybe I didn't make that clear.
Instead, the point of the article was to motivate you to go actually make sales, create value, and build relationships. None of these things require a developer. Do I know who you should specifically call to test the market in a given context? No; that's your problem to figure out. The point is that you CAN figure it out.
As mentioned in another comment, I managed a Google SRE team that help run Borg for 5 years. I'm good friends with several of the folks who are rebuilding it using Mesos at Twitter. They are all insanely awesome people.
Let's say you have a Rails stack (app server + DB) that you want to deploy for testing in 3 different datacenters. If that works out, you then immediately need to deploy 10,000 instances each to 10 different datacenters. Oh yeah, and the storage needs to be distributed and universally available, in case any of the servers crash. Performance testing reveals that you can't have more than 10 servers per rack, otherwise you saturate the rack switch. You also need to account for power distribution redundancy, shifting traffic loads, etc.
Oh, and you want to do this with a single configuration that's manageable by a team of 3-4 people and have deployment be entirely automated and monitored.
The complexities behind this problem are simply enormous, almost too much to even comprehend. I am proud of the work we did at Google to attempt (yes, attempt) to solve this problem, and I know my friends at Twitter are doing great work as well. I'm mostly just happy that I can finally talk about it and that the badasses that do this work can get some credit.
I think that in the end, Google's greatest gift to the world will be all the experience and knowledge that they put into the minds of the world's best engineers that worked on big stuff there over the last ten years or so.
Those people are building truly amazing things now based on that (for lack of a better term) incubator for the wider industry.
The stuff that has been built directly by Google is tremendous, to be sure. But the fundamental understandings that have come out of their R&D to do it will benefit everyone across the entire industry. It's magical to watch.
I managed a Google SRE team that helped run Borg for 5 years, so I'm pretty familiar with this. You can certainly run multiple application servers on one machine using virtualization. What isn't easy is automating where the applications are deployed, in an elastic, constantly shifting way that deals with massive numbers of machines and constantly changing hardware.
Cheap hardware crashes. It crashes all the time. Furthermore, the application's needs themselves change all the time, depending on traffic curves and processing needs. The dynamic needs of Google's (and presumably Twitter's) completely heterogeneous application stacks don't lend themselves to simple virtualization and over-the-counter software. This is an incredibly tricky bin packing problem that was never quite solved in my 5 years at Google.
I don't know a lot about the "distributed frameworks" you mentioned, so perhaps they do this too. I kind of doubt it. If it were as easy as you think, I'm sure my friends at Twitter would be using what you mentioned.
It isn't always the software. Having open, controlled, customizable hardware can offer a huge advantage over what you're able to purchase from Cisco/Juniper/etc.
Also, a software switch allows you potentially massively scale the number of ports on a single switch.
Quick correction: only Redfin has MLS access (as they are a broker). As far as I know, Zillow and Trulia have very limited MLS access, and largely get their listings from the brokerages themselves.
Well, the obvious case is a "safe monkeypatch", where you want to add some functionality to a class, but only if it hasn't already been added (maybe by some third module).
I think this could more easily allow for the use of multiple support libraries (like ActiveSupport) without having to worry about them clobbering each other.
forgive my ignorance, and I'm not familiar with ruby or ActiveSupport, but how does that solve the problem? Wouldn't different module's be expecting the method to be implemented in a certain way, and this would would have the method implemented, but not the version they expect?
Well, any time you have conflicting libraries, you have a potential monkeypatching conflict, but depending on the case, you might want to implement a method, but only if it hasn't been implemented yet. For example, consider that we have our application, and it uses the "foo" library (which provides a "bar") method, but it might also use the "baz" library (which provides an optimized "bar") if baz is installed.
Currently, you have to attempt to load baz before you load foo, and then not load foo's implementation of bar, if baz loaded successfully. In the future, you could just prepend foo, and so if baz was already loaded, it doesn't overwrite its optimized implementation. If baz wasn't loaded, then when it does load, it would overwrite the prepended implementation properly.
This just frees you up from having to worry so much about load order. It's not a huge feature, but it's a nice little quality-of-life change.
I was involved on a project which were actually two very similar applications.
What we did was create one gem for each specific special behavior of the app, were we declared some methods as extension points which the base app should call, in that scenario prepending methods would be useful, we could declare dummy empty methods to be overwritten later on by a module.
What we needed to do because of the lack of prepending modules was that each module implementation should implement all of the extensions points even when it was not needed, so, some times we had some dummy empty methods on one of the specific modules, i would have preferred to have those dummy methods on the main project itself.
Hey, fellow Charlottean here! I've found a similar situation here, where my SF network still exists but isn't quite as useful as it was when I was living there.
