I am wondering if the future of multi-cloud lies in a third party entity managing real-time auctions for cloud services.<p>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.<p>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.<p>3. The bidder with the lowest price wins the auction, sends back credentials to start deployment<p>4. The developer can start the deploy with the infrastructure provided by the lowest bidder!<p>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.<p>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.
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.
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.<p>am I missing something?
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.<p>(full disclosure: my startup, Armory.io, builds enterprise features on top of Spinnaker)
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?<p>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.<p>[1]<a href="https://cloud.google.com/functions/" rel="nofollow">https://cloud.google.com/functions/</a>
Why would you want the resulting uptime (u1 * u2) plus the added egress costs for cross cloud chatter?<p>Cross cloud just seems like a bad idea all around.<p>Edit: Maybe for a migration?
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.<p>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.