this doesn't solve the biggest problem with multi-cloud which is data egress though. Even if latency is acceptable you would get killed on data transfer for any significant amount of data.
am I missing something?
am I missing something?
In the context of this article, I think what they are pitching is the idea that, if you are already running services on AWS, you can still leverage some of the value-added service provided by GCP (e.g., their Vision API) by fronting them with Google Cloud Functions.
So, for example, let's say you built, and are running, an ecommerce platform on AWS. Now you'd like to leverage some of Google's Vision services to make "visual recommendations of related products". You already let customers upload product images via S3. Now you can have a Lambda function forward that image to a GCP CloudFunction, have it get processed by your visual recommender system, and spit back out a list of SKUs that have a visually similar image.
I think the goal is to convince companies that you don't have to put all your eggs in one basket in terms of capabilities, rather than convince them to have availability/capacity between multiple clouds (which how I think most people would interpret the headline).
That sounds kinda like the CDN example in my case :) I guess you could amend it to say "any kind of large media files"
But even if your business does do a lot with huge media files... no reason you can't do 95% of your business on AWS or GCE, and then just offload the giant file download piece to some unlimited bandwidth server you rent.
As Google seem to be getting more serious about attracting aws converts and dual cloud deployments (eg in built aws vpc peering) I wonder if they will offer some kind of cut price data transfer to aws networks. That would be an interesting move.
Ingress is free on all major clouds, but you still have to pay to get the data out.
(I work on GCP)