Over the past few months we have been busy putting the finishing touches on our cloud computing platform. Rather than taking the usual technology approach and announcing the platform when it was ready, we decided to take a more agile service development approach by engaging with existing customers and prospects and evolving the platform with their input. So today, we are announcing both the general availability of our cloud platform, which we call Carpathia InstantOn™ and discussing the solutions we have built for real customers. We believe this approach has led to something rather special.
It should be no surprise to folks who have been reading my previous posts, that Carpathia Hosting believes that blending dedicated and cloud technology leads to the best solution for customers both in terms of capabilities and price. Allowing dedicated infrastructure to request capacity from a cloud, or enabling synchronization between the cloud and dedicated is a non-trivial task. We developed Cloud Orchestration to make this possible.
So what is cloud orchestration? It’s an interface that sits on top of both our cloud computing and dedicated infrastructure inside the Carpathia Services Platform (CSP™). Its purpose is to blend resources based on a number of criteria such as SLA’s, predicted capacity spikes, CLI, API, disaster-recovery events, etc. It’s also a series of Carpathia Hosting-developed virtual machine images that provide the glue to make this possible. For example, we have a virtual machine that can monitor the performance of dedicated infrastructure. When certain conditions are met, it automatically provisions more compute resources in the cloud and then removes them when the demand subsides. We also have virtual machines that provide load balancing, layer3-7 switches, and firewalls with capabilities to automatically reconfigure to support more application virtual machines as they are provisioned.
In addition to virtual machines that respond to dynamic events, we also developed a number of virtual machines that allow dedicated infrastructure to make use of cloud storage. Both at the object file store level, in our case it’s as simple as mounting a filesystem. The underlying OS on the dedicated hardware has no knowledge it’s talking to a cloud or the cloud is providing multiple copies of its data for both availability and performance reasons. Our block storage solution is also very interesting, allowing for local storage for day-to-day operations for virtual machines. We extended this capability by creating a virtual machine that republishes block storage in the form of a virtual NAS appliance to dedicated and cloud resources.
More importantly, the above techniques have been used to build some very unique solutions for real customers. A couple of quick examples.
We built a transcoding cloud that takes video content in one form and encodes to another (i.e. mpeg to Flash). To simplify its use and integration into dedicated infrastructure, the customers simply drop a mpeg video clip into a directory called “incoming” which is mounted on their collection servers. The cloud detects this, spawns a new VM which collects the file encodes and writes the resulting Flash-formatted video to a directory called “outgoing”. The file systems both live inside our object-based storage solution. The virtual machines that provide the encoding are optimized for cores/memory to provide the most efficient encoding solution. As more files are dropped, more VM’s are instantiated by the orchestration layer to keep up with demand.
Another solution we engineered provides a load test solution powered by the cloud. We use apache jmeter built into a custom virtual machine. As one virtual machine reaches capacity for load testing, the orchestration layer creates more. This capacity management is fed into a single jmeter test console that can now generate thousands of concurrent connections.