
Going Multi-Cloud with Google Cloud Endpoints and AWS Lambda - blopeur
https://cloudplatform.googleblog.com/2017/04/going-multi-cloud-with-Google-Cloud-Endpoints-and-AWS-Lambda.html
======
jknz
I am wondering if the future of multi-cloud lies in a third party entity
managing real-time auctions for cloud services.

1\. The developer sets up some requirements: number of instances, X amount of
CPU power, Y amount of memory, Z amount of storage, B amount of bandwidth, or
other characteristics. These requirements are sent to the third party.

2\. Cloud vendors (the "bidders") receive the characteristics needed by the
developer. Each of them bid by providing a price per hour for the given
characteristics.

3\. The bidder with the lowest price wins the auction, sends back credentials
to start deployment

4\. The developer can start the deploy with the infrastructure provided by the
lowest bidder!

All this may happen in less than one second, similarly to the auctions that
happen when advertisers bid for displaying an ad when someone visits a
webpage. This would need a massive standardization across cloud vendors, a
system of penalties when the infrastructure provided by the bidder does not
satisfy the characteristics, etc.

This does not too far fetched to me. It also make it easier for new cloud
providers to start selling, and lower prices for developers.

~~~
paulddraper
Unlikely.

IaaS providers differentiate themselves on performance and price, but also
reliability, networking details, auxillary services, tooling, API
intelligibility, and support.

Cloud agnosticism sounds like a worthy goal but 9/10 it's the wrong move as it
reduces you to the lowest common denominator.

~~~
dotancohen
Even 9/10 of the cloud market is huge, and it's growing. I do see the OP's
vision happening.

Don't forget that Apple's initial goal in the phone market was 1%.

------
luhn
This is not multi-cloud as it is commonly defined: Simultaneously handle
workloads with multiple cloud vendors, to prevent lock-in to a single vendor.
Rather, this is passing workloads between AWS and Google to leverage the
advantages of each. A useful strategy, but the title is a bit misleading as it
goes against the colloquial definition of multi-cloud.

~~~
pasbesoin
Trans-cloud, as opposed to multi-cloud?

~~~
dmourati
Inter-cloud?

~~~
tyingq
I'd go with cross-cloud.

------
doppenhe
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?

~~~
tlarkworthy
In my experience egress is not the biggest cost though, it's compute and
storage. Are my workloads the outliers?

~~~
brianwawok
For most people not running a CDN or Netflix I would also expect to see CPU or
Ram the bottleneck.

~~~
_jal
Really depends on the business model. I modeled different deployment scenarios
for a product for a small company, and egress pricing broke the economics for
the ones involving cloud providers. (It was principally concerned with hires
images.) That was some time back and I know pricing has come down, so that may
be different now.

~~~
brianwawok
> It was principally concerned with hires images

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.

------
techcofounder
A (potentially) better approach to going multi-cloud is to use a CD tool like
Spinnaker (spinnaker.io), which Google and Microsoft both support - and
Netflix supports the integrations to AWS.

(full disclosure: my startup, Armory.io, builds enterprise features on top of
Spinnaker)

~~~
alpb
You’re right, however this article is not talking about deployment tools. It's
about setting up a serverless/lambda runtime pipeline between AWS and Google
Cloud. As far as I know, Spinnaker does not do anything for your application
runtime.

------
thawab
why would Google write a blog post about AWS lambda while they have cloud
functions in beta?[1] why would i use google endpoint with AWS lambda instead
of AWS API gateway?

Going "multi cloud" using AWS lambda with AWS API gateway and Google cloud
functions with endpoints is a blog post I'm interested to read.

[1][https://cloud.google.com/functions/](https://cloud.google.com/functions/)

~~~
nothrabannosir
I don't know about google cloud endpoints, but AWS gateway is an absolute
nightmare. Configuration is awful and communicating errors from backend to
client is a travesty. The lowest of the low hanging fruit to compete with AWS
on. If GEP is remotely coherent it will be a clear win.

~~~
sheeshkebab
Yeah, API gateway was written as some hack it seems (or maybe they used some
third party ESB or a soa framework and slapped cloudfront on it). All the
swagger extensions to configure it, these 200 status codes for 500 errors -
its all barely usable.

Just take your own rest backend and put cloudfront on it and it you'll have
more functionality and as much or more scalability and security, for an "api".

------
tyingq
Why would you want the resulting uptime (u1 * u2) plus the added egress costs
for cross cloud chatter?

Cross cloud just seems like a bad idea all around.

Edit: Maybe for a migration?

~~~
discodave
Imagine somebody that wants to get the features of EC2 and the features of
BigQuery or some of Googles ML stuff.

~~~
tyingq
I suppose. The downsides seem large enough that I would try and find
alternative implementations such that I could do it in one cloud. Or ar least
something that highly minimized cross provider dependencies and expensive data
xfer.

You're fighting the purpose built intention of the cloud to make it costly and
clunky to move data out.

------
peterjlee
Wouldn't this make your service less reliable since downtime in either cloud
service can cause your service to be down?

~~~
tyingq
Yep. Your new uptime is u1 x u2.

Like .99 x .99 == .9801

It's raid 0, like striped disks.

------
MichaelBurge
Seeing all those services hooked together gives me the willies. It sounds like
a right PITA to debug, and chaining them together in serial for a single
request multiplies the chance of an error even if each individual node is
pretty stable.

I guess it's okay for a demo though. They're probably not setting an example
so much as trying to throw as many services together to show off the
technique.

~~~
zackmorris
Ya the only way I could ever see this being maintainable is if it's
declarative. It takes a tremendous amount of boilerplate and configuration to
perform what comes down to a one liner in any functional language or a formula
in any spreadsheet. I think I would be more interested in a transform that
converts a series of goroutines to lambda functions or something.

------
djhworld
TL;DR - call services on GCP from your AWS lambda functions using Cloud
Endpoints.

------
cdnsteve
Flask app :)

------
dimitar9
this is just ridiculous

------
pdog
Why?

~~~
hobofan
The first paragraph tells you why.

~~~
tyingq
Sort of. _" Spread Critical Workloads"_ is somewhat silly to me. The uptime
will be lower than the worse of the two clouds, complexity higher, and cost
higher due to egress for cloud to cloud.

I do get the use case for actual multi-cloud, where there aren't cross cloud
dependencies.

This setup seems unwise though. Maybe as a short term migration pathway, or
similar.

------
rynop
clickbait. I don't consider this multi-cloud

