Speaking today at Data Centre World, ElasticHosts CEO Richard Davies will explain how ElasticHosts and Peer 1 have partnered to address the “Cloud Crunch” and deliver on-demand cloud services with 100% availability and scalability.
Speaking today at the Campbell-Lange Workshop Forum on Open Source and Cloud Computing for design companies, ElasticHosts CEO Richard Davies will explain how “cloud computing offers the potential for design businesses to move their core software and computing services to internet-based providers who can scale these services to meet variations in demand”.
Speaking at CloudCamp London today, our CEO, Richard Davies, will share our vision of “How cloud will change your company”, as previously presented at Powered by Cloud in February.
Using the example of a life insurer which uses a hosting cloud, SaaS CRM and an infrastructure cloud, we describe the benefits which they reap.
We believe that:
CEOs, CIOs and CTOs must act now to understand this fundamental shift in IT, and to make sure that their business emerges strengthened through leading their industry into cloud, rather than weakened by faster smaller competitors.
Speaking in the closing session of Powered by Cloud today, our CEO, Richard Davies, will share our vision of “How cloud will change your company”.
Using the example of a life insurer which uses a hosting cloud, SaaS CRM and an infrastructure cloud, we describe the benefits which they reap.
We believe that:
CEOs, CIOs and CTOs must act now to understand this fundamental shift in IT, and to make sure that their business emerges strengthened through leading their industry into cloud, rather than weakened by faster smaller competitors.
ElasticHosts recently released our HTTP API. In the course of system integration for our products, evaluating our competitors’ APIs and designing our own, we came to a clear view on what makes a great HTTP or web services API. Like many things in computing, it comes down to KISS: Keep It Simple, Stupid — simple for the users, that is!
Simple syntax means making it easy for any user with a standard tool to call the API. If you can’t call the API with curl from a single line of shell then your API is not good enough. This rules out many of today’s cumbersome XML-RPC and SOAP APIs, although you will want XML as an option for users who are using XML-friendly languages.
We believe in:
Choice of syntax: Different users will find different syntax most natural. At the unix shell, space-deliminated text rules. From Javascript, you’ll want JSON. From Java, you may want XML. Some tools parse x-www-form-encoded data nicely. A great HTTP API makes every command available with data in all of these formats for all of these users, specified with either different URLs or MIME content types. (OK, we admit that we’ve only released text/plain ourselves so far, but the rest are coming very soon!).
Don’t reinvent the wheel: Smart people designed the internet. There are good existing mechanisms for security (e.g. SSL/TLS), authentication (e.g. HTTP auth), error codes (e.g. HTTP status codes), etc. Use them, and don’t invent your own, unlike one UK payment gateway who invented a simple XOR encryption which is vulnerable to a known plaintext attack and didn’t fix it when we pointed this out!
Simple semantics means having a small number of powerful, orthogonal commands. If your API needs a 300 page document to explain it then something is wrong. Equally, your users shouldn’t even be aware of the artificial abstractions and data structures which you invented inside your software.
We believe in:
Few powerful orthogonal commands: For your API users, each call adds overhead, both in code and response times. Produce a few powerful calls which do the work of many smaller ones. In our case, our API has a single call for “server create”, where this would take many calls with some of our competitors’ APIs: starting the server, associating a static IP, associating persistent storage, etc.
No artificial abstractions: API users don’t care how you wrote your software, and shouldn’t have to know or change their calls when you change your design. Try as hard as you can to hide your internal structures from the user unless it’s absolutely necessary to expose them. In our case, a cloud infrastructure platform provides virtual server hardware, and we let users configure this as they would real hardware, choosing an amount of RAM, specifying which hard disk is on which IDE bus, etc. We don’t invent “instance types” and we deal with mapping the well-known hardware descriptions to how the virtualization platform sees them.
Immediate response where possible: All of our API commands are synchronous, and they usually complete within seconds of all input data arriving. If we can do this for a cloud infrastructure platform, then surely you can for your application?
Happy New Year, and may your 2009 APIs be good ones!
For CloudCamp London today, we are sharing an overview of “How clouds can and will differ”.
We believe that even within cloud infrastructure there are significant differences between providers, based on:
ElasticHosts will be the second UK-based cloud infrastructure provider to launch — and we believe that our UK physical location will make us extremely attractive for UK-based customers, due to:
