I agree that the result of these APIs can be a dumbing down of your cloud infrastructure. IMHO, the major challenges inherent in having multiple cloud providers with differing APIs is absolutely not writing code to use them, rather:
- infrastructure management
- workflow process security
- credential security
- offline workflow (local emulation) support
- cost comparisons
- performance observation / guarantees
- SLA
- recognition of disparate legal jurisdictions where required
- managing nontrivial inter-service build and live dependencies
- complex or non-standard network topology support (ie. not "single default route to the internet" or "single default route to the internet, secondary route to cloud provider specific renamed VLAN concept")
- embedding real time failover
Keeping all of the above out of the way of regular programmers who just want to write cloud provider neutral services is the real challenge. None of these libcloud/libvirt type solutions ever target the above, which mostly border on operations concerns.
I am now working on the second functional prototype of a system that I believe goes a long way toward resolving these issues by taking a broader, more operations-centric perspective on the evolving norm of multi-provider cloud infrastructure within companies that may include remote developers, require offline development support, and still need to maintain higher standards of trust and security.
Those curious can browse the presently rather obtuse documentation at http://stani.sh/walter/cims/ .. I am considering asking my company to allow me to open source it.
Right now we have storage providers for LVM and ZFS, and support for an internal, high availability corosync/pacemaker cluster + LXC based cloud provider in addition to a range of popular commercial ones. Very interested in feedback and/or experienced/motivated help.
Keeping all of the above out of the way of regular programmers who just want to write cloud provider neutral services is the real challenge. None of these libcloud/libvirt type solutions ever target the above, which mostly border on operations concerns.
I am now working on the second functional prototype of a system that I believe goes a long way toward resolving these issues by taking a broader, more operations-centric perspective on the evolving norm of multi-provider cloud infrastructure within companies that may include remote developers, require offline development support, and still need to maintain higher standards of trust and security.
Those curious can browse the presently rather obtuse documentation at http://stani.sh/walter/cims/ .. I am considering asking my company to allow me to open source it.
Right now we have storage providers for LVM and ZFS, and support for an internal, high availability corosync/pacemaker cluster + LXC based cloud provider in addition to a range of popular commercial ones. Very interested in feedback and/or experienced/motivated help.