In order for a public transit system to be convenient you need a LOT of density. You also need speed. The two goals are fundamentally at odds with each other. That’s why a lot of people prefer cars. No one likes traffic or emissions, and cars are way more likely to kill you, but damn are cars convenient even in urban environments.
Any plan like this can have all these numbers talking about how much space could be freed up but they need to address this fundamental problem, and this article failed to.
Now what interesting is the rise of self driving cars. I’ve often see paid parking lots and think within 20-30 years they will be out of biz. A few large operators will emerge and park their cars overnight at some owned large lot far out of the city to recharge, maintain, etc, and there won’t be much need anymore. So that could be a path to what author is talking about, long term. Of course does nothing for parking lot owners who just hold onto the property speculating...
We’ll have empty cars driving around the city to pick some up. Causing transit. It’s the same effect Uber is causing to cities. More transit and people taking less mass transit.
The scenario that I read from urbanists is that people will continue to own an autonomous car, and the car will drive you to work, drive back home to pick up your partner, drive her/him to work, drive back to pick up the kids, then drive them to school, and on and on. So more empty cars on the road.
While I see autonomous cars as a cool tech, I don’t see urbanists thinking it will solve urban planning.
Does anyone on here, who has worked on this project or internally at Shopify, feel that this project was successful? Do you think this is the first, of a long and gradual process, where Shopify will rewrite itself into a microservice architecture? It seems like the mentality behind this project shares a lot of commonly claimed benefits of microservices.
> Over the years, we realized that the “storefront” part of Shopify is quite different from the other parts of the monolith
Different goals that need to be solved with different architectural approaches.
> storefront requests progressively became slower to compute as we saw more storefront traffic on the platform. This performance decline led to a direct impact on our merchant storefronts’ performance, where time-to-first-byte metrics from Shopify servers slowly crept up as time went on
Noisy neighbors.
> We learned a lot during the process of rewriting this critical piece of software. The strong foundations of this new implementation make it possible to deploy it around the world, closer to buyers everywhere, to reduce network latency involved in cross-continental networking, and we continue to explore ways to make it even faster while providing the best developer experience possible to set us up for the future.
Smaller deployable units; you don't have to deploy all of shopify at edge, you only need to deploy the component that benefits from running at edge.
It makes more sense for us to extract things than to make everything microservice.
Storefront makes sense to be on its own service, so we are making it so.