Matt Quinn is CTO at TIBCO in Palo Alto, California. His role includes creating a common, corporate-wide vision for all of TIBCO’s products and technologies. His past experience includes the role of global architect, responsible for delivery of some of the company’s largest implementations in transportation and logistics, energy and finance.
Originally you had public, private and hybrid clouds. Hybrid clouds were those that spanned private and public environments. Essentially, the scale out scenario or cloud burst scenario was often used to describe peak load expansion to a public cloud environment (think holiday sales promotion requiring more horsepower).
Federated cloud usually describes joining up and managing multiple public cloud environments – but there is nothing to prohibit joining multiple public clouds to a private one (so some overlap with Hybrid).
The central idea is that you have multiple IaaS and PaaS environments in the cloud. An application or a set of services may require the joining up and managing multiple PaaS and IaaS environments.
Now there are two classic scenarios:
- I have my storefront in the cloud. During peak periods, I want to quickly expand my capacity. I may choose to federate my load across multiple cloud providers both from a cost or location issue (for example: I am a US-based service, but I have an European sales promotion – I should probably choose a local cloud provider to federate my load across, etc.).
- I have multiple cloud services (think RDS from Amazon, a CDN from Akamai, etc.). I will (either for cost or functionality) choose to federate my application across multiple different clouds.
The reasons for doing it are usually either functional, location or cost-based. You can get a lot of flexibility here, as you don’t need to rely upon a single vendor to support you, so there is less vendor lock-in. However, the flexibility you gain can be at the cost of complexity. You now have multiple different SLAs, you have to manage potentially different APIs, monitoring and management and deployment approaches.
Silver Fabric (our stuff) provides a layer on top of classic IaaS. You could create a federated PaaS using multiple different asset managers talking to different public cloud assets (think Azure, EC2 and OpenStack asset managers). This would create a pool of resources managed and connected through Fabric.
Where is this is going?
Federated cloud could also be known as an orchestrated cloud – where you are not just joining up compute, storage and network services, but are also hooking up other low-level cloud services (data, CDN, messaging, integration, “Hadoop-y” things, etc.) to meet your needs. This means that not only would you be managing the individual clouds, but orchestrating services across them. You application better be somewhat cloud aware to make that happen.
Matt Quinn will speak on ‘Creating self-service, actionable context in a world of massive unstructured data sources’ at Cloud Connect in Santa Clara, CA, on April 5th.