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.
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)
AppEngine is a somewhat clunky experience because of the walled garden nature it presents. For example, you can't write to a local filesystem in the way that you normally would, no listen sockets, etc.
And, while I don't have as drastic an opinion as others, there are operational issues. The most recent one was mysteriously disappearing outbound emails. These are worse than they should be, because there's no real way to escalate and get someone's attention, even if you're willing to pay for it. The support model is not the same as for the newer Cloud services.
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 :)
I work on Google Cloud Platform, and I don't see any of the things you mentioned about App Engine. If you want a larger memory footprint, I suggest you look at the Flexible Environment (formerly Managed VMs), which lets you use any size VM you like.
We also have new Cloud Platform client libraries for many languages - start at https://cloud.google.com/docs/ for Go, PHP, Java, Python, .NET, Ruby and Javascript (Node.js)
App Engine hasn't stood still. I'd encourage you to take another look.
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.
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).
>It could randomly choose from a number of possible ways to continue. It could deal in probabilities rather than only 100% certainty.
Essentially this is how humans operate already. How many times a day do you have minor but insignificant misunderstandings with people? Probably quite often, especially if you are in a foreign country and yet we all get along just fine.
Because, that's the parent's whole point: that the same (they can't be defined or at least defined easily) holds for those "squishy human requirements".
>What is it about information machines (as opposed to humans) that make them unable to handle ambiguity?
Obviously the fact that they only follow specific instructions at their lower level, and thus any ambiguity has to be explicitly translated to a non-ambiguous set of commands.
A fellow human does this translation automatically in their mind (and even they, not always perfectly).
>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).
Most of these sound recipes for disaster in any practical application...
And even that's besides the point, since all of these need to be programmed just as well as non ambiguous commands, but with more branching and special casing -- again explaining why handling ambiguity is hard.
Oh, and "randomly choose from a number of possible ways to continue" sounds like Clippy from hell...
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 )
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.)
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
Computers can handle rigidly defined boundaries of doubt and uncertainty, if they are programmed to. However, the larger the areas of doubt and uncertainty, the harder the program is to write. So perhaps more accurately we could point out the totality of the system of software creator (including not just developers but everybody involved) and the machines still have trouble with squishiness and ambiguity.
Machine learning is a powerful tool, but it's hardly "fire & forget", after all. Even a smarter machine is still only upgrading one part of the system as a whole.
Understanding, correctly, what an underspecified system should do is a strong AI problem (in most cases, at least). All (or nearly all) unbuilt systems are underspecified (as well as many built ones). We do not yet have strong AI. Hence, we have developers who will continue to collect paychecks for the foreseeable future (your "tired meme").
> 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?
Your focus on "ambiguous input" misleads you. The difficulty is more like ambiguous output.
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.
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.
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?
Depends very much on your requirements. If this is data that is rarely changing, and that you have complete copies of, that is exactly what S3 is not good for. In that case: Any dedicated host that's cheap and with reasonable latency (or put a CDN in front). Two copies for failover/ha if you need it.
If you pay more than 20% of the advertised rates of AWS bandwidth, you're being robbed. 10% or less is doable.
If you need durability guarantees, consider if the cost problem is storage or bandwidth. If the problem is bandwidth costs (in other words: your data set is small and accessed often), store at S3 or Backblazer or similar, and place a server or two at a cheap bandwidth host with Nginx and aggressive caching policies.
I've done this for a couple of customers who did not trust other data storage options with their data, and you can rent a server + multiple TB of transfer for a fraction of a the cost of 1TB transfer from S3....
Look into IPFS, interplanetary file system. You still need machines to serve files. However, the system has some definite advantages:
1. A file/directory is referred to its immutable hash.
2. A request for a specific hash is made to the network, not a single machine.
3. All machines that have that hash can swarm-download, like bittorrent
4. All communication is point-to-point encrypted
5. For backend, you can mount IPFS directly to the file system, via /ipfs and /ipns
The gist behind this is allows you to create a backend CDN of whoever is cheapest right now, and then load the images on your webpages (as gateways). It's still alpha, but so far my stability (and others running it) have shown that this system can easily handle large archives (800GB and up).
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)
>>“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.
32 comments
[ 2.6 ms ] story [ 83.6 ms ] threadI really doubt they will be able to come up with something meaningful.
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)
And, while I don't have as drastic an opinion as others, there are operational issues. The most recent one was mysteriously disappearing outbound emails. These are worse than they should be, because there's no real way to escalate and get someone's attention, even if you're willing to pay for it. The support model is not the same as for the newer Cloud services.
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?
We also have new Cloud Platform client libraries for many languages - start at https://cloud.google.com/docs/ for Go, PHP, Java, Python, .NET, Ruby and Javascript (Node.js)
App Engine hasn't stood still. I'd encourage you to take another look.
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.
> 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).
Essentially this is how humans operate already. How many times a day do you have minor but insignificant misunderstandings with people? Probably quite often, especially if you are in a foreign country and yet we all get along just fine.
Turning squishy requirements into something specific enough to actually design a solution around is a pretty important step in any project.
Is that supposed to be a counter-argument?
Because, that's the parent's whole point: that the same (they can't be defined or at least defined easily) holds for those "squishy human requirements".
>What is it about information machines (as opposed to humans) that make them unable to handle ambiguity?
Obviously the fact that they only follow specific instructions at their lower level, and thus any ambiguity has to be explicitly translated to a non-ambiguous set of commands.
A fellow human does this translation automatically in their mind (and even they, not always perfectly).
>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).
Most of these sound recipes for disaster in any practical application...
And even that's besides the point, since all of these need to be programmed just as well as non ambiguous commands, but with more branching and special casing -- again explaining why handling ambiguity is hard.
Oh, and "randomly choose from a number of possible ways to continue" sounds like Clippy from hell...
> 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 )
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.)
> 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
Machine learning is a powerful tool, but it's hardly "fire & forget", after all. Even a smarter machine is still only upgrading one part of the system as a whole.
Underspecified.
Understanding, correctly, what an underspecified system should do is a strong AI problem (in most cases, at least). All (or nearly all) unbuilt systems are underspecified (as well as many built ones). We do not yet have strong AI. Hence, we have developers who will continue to collect paychecks for the foreseeable future (your "tired meme").
> 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?
Your focus on "ambiguous input" misleads you. The difficulty is more like ambiguous output.
It seems like it's written for extremely rich grandmothers who go to board meetings for the dessert table.
They might be a little out of touch, but no too out of touch to vote, and their vote counts.
Honestly, if you're writing for people at the top, this is an enviable style of writing.
I really wish more people knew about them. They are great.
If you pay more than 20% of the advertised rates of AWS bandwidth, you're being robbed. 10% or less is doable.
If you need durability guarantees, consider if the cost problem is storage or bandwidth. If the problem is bandwidth costs (in other words: your data set is small and accessed often), store at S3 or Backblazer or similar, and place a server or two at a cheap bandwidth host with Nginx and aggressive caching policies.
I've done this for a couple of customers who did not trust other data storage options with their data, and you can rent a server + multiple TB of transfer for a fraction of a the cost of 1TB transfer from S3....
Look into IPFS, interplanetary file system. You still need machines to serve files. However, the system has some definite advantages:
The gist behind this is allows you to create a backend CDN of whoever is cheapest right now, and then load the images on your webpages (as gateways). It's still alpha, but so far my stability (and others running it) have shown that this system can easily handle large archives (800GB and up).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.