Re:Silicon Valley's Soft Landing
by MaysonL on Friday January 08, 2016 @09:05PM
(#10869717)
Heard an interesting take on the unicorn state of play this weekend on Barry Ritholz's Masters in Business podcast. William Janeway (Warburg Pincus) thinks there is definitely a unicorn bubble going on, but just like the railroad bubble in the 1800's and the automobile bubble in the early 1900's and the PC bubble in the late '70s and early '80s and the Internet bubble in the '90s it will end with a lot of people losing money, quite a few making money, and a lot of companies going out of business, but with a lot of survivors and a lot of infrastructure that will fuel ongoing progress, and that this is a good thing on balance. His belief is that equity bubbles are a lot less dangerous than credit-fueled bubbles like the housing bubbles of the '00s.
[ Parent
| on HN ]
What would be the infrastructure this time? Instacart drivers at the ready...? The whole ecosystem that's been pushed seems to be being pushed precisely because there's no infrastructure involved, leading to the asymmetric cost structures so championed by PG/YC.
Re:Silicon Valley's Soft Landing
by lambdasquirrel on Saturday January 09, 2016 @12:16AM
(#10870181)
The whole devops toolchain really came of age in this bubble. The same stuff you used to build yet another instagram clone can be used for a medical analytics startup. It's how things have always been in tech. Yesterday's toys become tomorrow's tools.
Re:Silicon Valley's Soft Landing
by hkmurakami on Saturday January 09, 2016 @01:15AM
(#10870310)
I suppose cloud computing infrastructure investment would be one.=
Re:Silicon Valley's Soft Landing
by lambdasquirrel on Saturday January 09, 2016 @02:24AM
(#10870435)
I'd say it's even better than that. At my last company we used our own hardware, but we still benefited from Docker, Consul, Chef, graphana, etc. There's a lot there that is cloud-agnostic.
For example, service discovery is still service discovery. You still have, say, a hundred machines running the listeners API. Are you going to keep a manual tally of that? Or better to just start consul client from the ansible/chef provisioner, and let "dns" handle the load balancing. You can implement "connection draining" by downing the health check url before going offline on a node. Just one example, but yea, there's a lot of ease and maturity in the new services way of doing things now.