
Google Reveals Its Cloud Computing Vision - 51zero
http://www.51zero.com/blog/google-reveals-its-cloud-computing-vision
======
mooreds
A bit breathless for my taste.

People have been trying to get rid of developers since COBOL was invented. The
issue isn't that development is hard (though it is), it's that you have to
translate human, squishy requirements that have unconsidered edge cases to
machine considerations which have no room for ambiguity.

That's what a good developer does, and that's what machine learning/serverless
architectures/4gl/COBOL can't do.

~~~
igravious
Agree with you on the article but have to part ways with you from there.

> The issue isn't that development is hard (though it is), it's that you have
> to translate human, squishy requirements that have unconsidered edge cases
> to machine considerations which have no room for ambiguity.

This is a tired old meme. And I didn't believe it when it was a young whipper-
snapper neither.

Define 'squishy'. You can't, can you?

What is it about information machines (as opposed to humans) that make them
unable to handle ambiguity?

Why can't a machine handle ambiguous input? It could defer to the operator,
did you mean this? did you mean that? It could randomly choose from a number
of possible ways to continue. It could deal in probabilities rather than only
100% certainty (both true and false are epistemic locations of absolute
certainty).

~~~
mooreds
Thanks for the feedback. I find it generally interesting because most
technical folks I've talked to have the same attitude I do. (Upvoted.)

> What is it about information machines (as opposed to humans) that make them
> unable to handle ambiguity?

Of course, if designed for ambiguity, information machines can handle it.

But in my experience, solving a problem with software first involves defining
the problem. Most problems are "squishy", in that they are ill defined. The
end user has needs and knows those needs, but hasn't thought through all the
ramifications of automation.

I've started a requirements process many a time with the question: "what do
you want this to do", and then diving down to specify each behavior, including
critical path functionality, error conditions, alternate paths, roles in the
system, performance, timeframes, and other attributes. All of these are
fundamental pieces of automating information flow, but aren't typically
considered by a non technical person. Hence my use of the term "squishy". (I
wrote a blog post in 2003 about how software crystallizes business processes:
[http://www.mooreds.com/wordpress/archives/46](http://www.mooreds.com/wordpress/archives/46)
)

And I don't know of any software process that can handle that. Even tools
designed for non developers like Excel and Zapier force users to go through
edge cases.

Finally, I'm certainly no expert on some of the new AI technologies that might
be game changers. (I did enjoy reading The Master Algorithm, which talks about
the schools of AI and some of the achievements.)

~~~
igravious
I definitely could have phrased my objections to what you wrote in a less
provocative manner. My bad. So thank you for the level-headed response to my
feedback.

> Of course, if designed for ambiguity, information machines can handle it.

I thought you were implying they couldn't. I just had flashbacks to too many
arguments with people who don't get how computers work where they claim that
machines are just ones and zeroes, on or off, black or white, and humans are
so many shades in between. What do the kids these days say? _triggered_

I didn't get that you were referring to the process of capturing user
requirements. I can see in that context why you would call that process
'squishy'. I wouldn't disagree with you on that, then it's probably a
perfectly good work to describe that open-ended, frustrating! iterative
process of discovery and refinement.

I really asked for those down-votes with the tone and manner in which I first
replied to you. :/ Let some bad news I received filter through there. _sigh_

------
tyingq
>> _“Instead of programming a computer you teach it what it [Google’s cloud]
wants to know and it learns to give you what you want,”_ explained Eric
Schmidt, software engineer and executive chairman of Google's Alphabet, Inc.

Skeptical on this. To date, nothing has even emerged that would allow non-
technical people to create the basic CRUD apps that we create over and over.
Quickbase/Filemaker/etc are somewhat close, as was the now-dead DabbleDB,
...but, most of the people using those were developers :)

If nobody has solved this, it seems a pretty big reach to say Google is going
to produce something an order of magnitude more complex.

------
fauigerzigerk
I don't get the pricing model of the leading cloud providers. Their data
transfer pricing in particular makes zero sense. Running data intensive
applications on Google's or Microsoft's or Amazon's cloud costs 10 times as
much as running them on vultr or DO. I find that huge difference baffling.

~~~
kumarm
We are looking for alternatives to S3 (for static hosting) since price of data
transfer is way too high in all 3 leading cloud services. Any suggestions?

~~~
teh
[https://www.backblaze.com/b2/cloud-storage-
pricing.html](https://www.backblaze.com/b2/cloud-storage-pricing.html) is a
bit cheaper but you'll still pay $50 / terabyte. Using DO just for data might
work but then you can't run fast computations on your data.

~~~
amorphid
Clarification. B2 costs $5/TB for storage ($0.005/GB stored * 1000 = $5/TB
store), and $50/TB for downloads ($0.05/GB downloaded * 1000 = $50/TB
downloaded).

------
outside1234
What a joke - if this is what Google's vision is for the cloud then it is
clear they have no idea who their customers are and what they want (hint:
Enterprises)

------
kinai
NoOps...how about no?

------
sudo-i
I have a vision of ending up with a long legged Swedish blonde model, doesn't
mean it will happen though...

------
vicpara
Google App Engine is rubbish compared to most of other PaaS or SaaS providers.
Rubbish because of the unreliable infrastructure (instances that get quickly
out of sync), slow reads and writes, memory footprint your instances are
allowed to have so that Google scales better and their API usability.

I really doubt they will be able to come up with something meaningful.

~~~
matt4077
I'm not orchestrating a 1000k-node cluster, but for my needs, the google cloud
has been excellent. It seems they are doing something right if they're
attracting Linode/DO customers like me and AWS customers at the same time.

From the benchmarks I've seen, their computing instances also over much better
perfomance/$ than AWS, especially in IO.

(But I have no experience with app engine so we could both be right)

~~~
astazangasta
>I'm not orchestrating a 1000k-node cluster

Is this right? Do you really mean 1 million nodes? Even if only 1000 nodes,
who are the people using the high end of computing power, and for what?

~~~
matt4077
Let's put it this way: I am indeed not orchestrating a 1 million node cluster
and the statement is therefore technically true, which some say is the
superior truth anyway :)

------
clebio
Off-topic, I know, but what a stellar example of a sanitized, neutered
corporate website. The picture of light bulbs on the About Us page.... bravo,
you faceless, "elite" consulting company, bravo.

