News for hackers. Stuff that matters.
Re:Introducing Cloud Spanner, a Global Database Service by cjmcqueen on Tuesday February 14, 2017 @02:12PM (#13646207)
I would disagree about the character of the situation. This isn't about people putting eggs in a few baskets, it's that it's more efficient to have centralized chicken coops instead of every family in the world owning their own chickens.

Now, you could play with that analogy further and see some issues as well, but I don't think the issue here is centralized failure; all these data centers/"clouds" are at least good. The Cloud is about businesses focusing on core business and not supporting functions.

[Disclosure, I work on the Google Cloud team, I'm biased]

Re:Introducing Cloud Spanner, a Global Database Service by hueving on Tuesday February 14, 2017 @07:03PM (#13648534)
>focusing on core business and not supporting functions.

Having a devops team with the necessary expertise in Google Cloud or AWS is still a supporting function. You've just traded one skill (managing physical servers) for another (managing proprietary virtual resources).

Re:Introducing Cloud Spanner, a Global Database Service by euyyn on Tuesday February 14, 2017 @07:57PM (#13648832)
But hopefully a smaller team, and one that keeps diminishing in size over the years if the trend continues. At least for the same level of service (in availability, security, etc.).
Re:Introducing Cloud Spanner, a Global Database Service by aaronblohowiak on Tuesday February 14, 2017 @02:29PM (#13646362)
Monocultures are efficient, but not healthy ecosystems in the long term.
Re:Introducing Cloud Spanner, a Global Database Service by cestith on Tuesday February 14, 2017 @04:54PM (#13647559)
Let's look at your metaphor. It's more efficient for the raising of a large overall number of chickens. It's less efficient when I need fast access to a single egg.

Hence we get caching. There's the farms, then the inbound warehouses, then the distribution centers, then the grocer, then our refrigerators by the dozen or dozen and a half. When your local cache is empty of eggs, though, it requires a trip back out to the grocer to get an egg even if you need nothing else that trip. Then you generally have to buy at least half a dozen if not a dozen or more eggs just to get the one you wanted.

If I have my own couple of hens, I can go out into the yard and get an egg. If that's the whole of my fetch list, it's much more efficient for this single egg to have the hens laying right out back.

This whole few baskets metaphor breaks down from another point of view, though, when we consider that by the very nature of using a globally distributed hosted service we're actually eliminating a single basket problem. Yes, there's not much choice among just Google, Amazon, and Microsoft. (That they are the only options is a bit of a strawman, but lets grant this one legs.) However, putting just your own employees in charge of all your infrastructure in just your own datacenter(s) in just PostgreSQL or just MySQL is another single-basket problem. Spreading it out so that someone else gets to manage the hardware and the service and replicating your data widely within that service is from that point of view more baskets. You get more datacenter baskets, more employee baskets, and more software baskets. Using standard SQL means you can move among compliant software later, too, so you're not as tied to those baskets.

Now, back to your coop analogy. What's stopping me from having my application talk to Cloud Spanner and a local database proxy (or a work queue that sits between the app and the DB or whichever) so I can use Google's reliability for transactions and my local cached replicant for query speed when I'm querying older data? Why can't I keep a few eggs around?

Also, why would I be scared of Google or Amazon "having my data"? Why would I put sensitive data into my own database in plaintext and then replicate it among multiple datacenters that way?

Re:Introducing Cloud Spanner, a Global Database Service by CaptSpify on Tuesday February 14, 2017 @03:09PM (#13646672)
> it's that it's more efficient to have centralized chicken coops instead of every family in the world owning their own chickens.

Only if the owner of the chicken-coop has everyone else's best interests in mind. Protip: They don't.

The Cloud isn't about efficiency, it's about data control. Getting people's systems and data into Google/AWS/etc helps with data mining, vendor lock-in, etc. Often times that can be efficient, but also it often isn't.