Simple Workload & Application Portability (SWAP) - Presentation

This is the presentation I gave on my paper at the IEEE INFOCOM '14 CrossCloud workshop in Toronto on 28 April 2014, along with a demo of the experimental implementation of the protocol.

In it I proposed that we adopt the same strategy as was used for Internet email to break down the cloud computing silos — a HTTP-based "lowest common denominator" protocol called "Simple Workload and Application Portability (SWAP)".

Transcript

1. Sam Johnston (@samj) <samj@samj.net> Simple Workload & Application Portability A simple “lowest common denominator” approach to hybrid, multi- and inter- cloud portability over HTTP
2. Definitions ❖ Cloud computing: Migration from products to services! ❖ Hybrid cloud: Multiple deployment modes (public, private, legacy)! ❖ Multi-cloud: Multiple cloud providers (AWS, Azure)! ❖ Intercloud: Global cloud of clouds (Internet)
3. Open Source ❖ Uses copyright against itself (“copyleft”)! ❖ Ensures certain freedoms for software vendors & users! ❖ Software traditionally delivered as products & installed! ❖ Conveyance of software triggers license clauses! ❖ Software delivered as services is not conveyed! ❖ “Fixes” trigger licenses on access to software (AGPL)
4. Open Cloud ❖ Open Cloud Initiative established to define Open Cloud! ❖ California non-profit modeled on Open Source Initiative! ❖ Essentially the same, only for services, not products! ❖ Community consensus process (Open Cloud Principles)! ❖ Logo licensing for branding products & services
5. Open Cloud Principles ❖ In order to be branded “Open Cloud” you must use:! ❖ Open Formats: User data in open standard formats! ❖ Open Interfaces: APIs defined by open standards! ❖ There must be multiple interoperable implementations! ❖ At least one implementation must be Open Source! ❖ e.g programmatic access to data in transparent formats
6. Problem ❖ Cloud stacks typically expose proprietary interfaces! ❖ Interfaces for one feature set not compatible with others! ❖ Standards are not well/widely implemented! ❖ An unimplemented standard is just a specification! ❖ Existing standards try to do too much! ❖ They actually don’t go far enough (e.g. extensibility)
7. Adaptors ❖ Expose a single API with support for multiple backends! ❖ Expose all features of all clouds or some subset (which?)! ❖ “Impedance mismatch” with functionality mismatch! ❖ For example, thin vs thick list of cloud resources! ❖ Which programming language/s do you support?! ❖ Example: Open DataBase Connectivity (ODBC)
8. New Management Interfaces ❖ Existing approaches involve standards for management! ❖ Must be feature complete or they will hide functionality! ❖ Implementing all features for all clouds is infeasible! ❖ Safe extensibility is easier said than done (registries?)! ❖ Example: Open Cloud Computing Interface (OCCI)
9. Proprietary Management Interfaces ❖ Adopt an existing “de facto standard” interface! ❖ Amazon Web Services often proposed, but:! ❖ Evolution, API & client copyright, patents, formats! ❖ Cements single vendor as custodian of standards! ❖ Only one to innovate; others must follow the leader! ❖ Example: Microsoft Word document (DOC) format
10. Case Study: Internet Email ❖ Early electronic mail services silos (like cloud today)! ❖ Gateways implemented for inter-silo message transfer! ❖ No attempt at standard management APIs! ❖ Rather lowest common denominator protocol defined! ❖ Simple Mail Transfer Protocol (SMTP)! ❖ Rapidly adopted by servers, now a required feature
11. Lowest Common Denominator ❖ What’s needed for hybrid/multi/intercloud portability?! ❖ Ability to enumerate available resources! ❖ Ability to transfer resources (ideally CRUD)! ❖ Supporting functionality (encryption, AAA, etc.)! ❖ SWAP is SMTP for cloud computing
12. Simple Workload & Application Portability ❖ Use HTTP rather than reinventing the wheel (ala SMTP)! ❖ Provides authentication, encryption, scaling, etc.! ❖ Support arbitrary formats defined elsewhere (ala SMTP)! ❖ Identify formats using Internet media types (MIME)! ❖ Support arbitrary workloads, not just virtual machines! ❖ Most activity today is in platform services (PaaS)
13. Operations ❖ Create: Upload a resource to the cloud (PUT)! ❖ Retrieve: Download a resource from the cloud (GET)! ❖ Update: Efficiently update resource in situ (PATCH)! ❖ Delete: Remove a resource from the cloud (DELETE)! ❖ Advanced functions: COPY/MOVE (WebDAV)! ❖ For migrating remote workloads (e.g. 2/3/4G)
14. Enumeration ❖ Define an entry point to enumerate (tcp/25 for SMTP)! ❖ Use /.well-known/swap (defined in IETF RFC5785)! ❖ How do we return results?! ❖ Thick list: Define a new JSON format (in vogue)! ❖ Thin list: Return a simple list of URLs, resolve each! ❖ PROPFIND (WebDAV): Use existing HTTP standard! ❖ Would we want/need to fix WebDAV?
15. Experimental Enumeration ❖ Thick list! ❖ Simple JSON format! ❖ Still proprietary! ❖ Still requires parsers! ❖ Quickly gets complex
16. Proposed Enumeration ❖ Define a generic approach for enumerating directories! ❖ Only possible today using WebDAV (PROPFIND)! ❖ Inefficient, insecure, poorly implemented, XML-based! ❖ Look at text/uri-list (RFC2483), WebDAV (RFC2518)! ❖ Create HTML or JSON based directory listing standard! ❖ JSON more easily allows inclusion of e.g. headers
17. Proposed Resolution ❖ Not yet possible to resolve a resource, only retrieve it! ❖ Should be able to interrogate out-of-band metadata! ❖ Normally requires separate descriptor resource! ❖ But HTTP already has a metadata channel (headers)! ❖ Add Category, Attribute & Link (RFC5988) to headers! ❖ Already done: draft-johnston-http-category-header-02
18. Experimental Implementation ❖ Written in Google’s Go language! ❖ Trivial implementation today; bare bones, lacks error checking etc.! ❖ Needs to be pluggable (e.g. backends for different cloud APIs)! ❖ Will be released under a suitable Open Source license (e.g. Apache)
19. Adoption ❖ Implementation of any new protocol carries a cost! ❖ SWAP is Simple — cost of implementation very low! ❖ Provide patches for Open Source stacks (e.g. OpenStack)! ❖ Lobby vendors of products & services to incorporate! ❖ Deploy SWAP gateways into target clouds! ❖ Basically a “trojan horse” for uncooperative vendors
20. Next Steps ❖ Experimental implementation (becomes reference)! ❖ Specification document/s (IETF RFC?)! ❖ Multiple interoperable implementations! ❖ Interoperability bakeoff in open cloud lab/s! ❖ Production implementation in public cloud services! ❖ Evolution of protocol to support advanced functionality