Lots of clouds. One API. No problems!

The development of some aspects of software, in most cases, is quite predictable. One of the main trends is a constant increase in the level of abstraction.



For clarity, I will give an example with data storage systems. So it all started with the files. At the very beginning, we used only files, where we stored all our data, and accessed them directly from the program. Sooner or later, everyone got tired of it and we moved to the DBMS . The amount of routine work decreased, and we turned to the database server already through SQL queries .



But after a while it became uncomfortable too. We wanted to be able to go from one DBMS to another without major changes in the source code.

')

We developed DAL - an abstraction, where a low-level API for accessing each database was distributed to the drivers, which were connected as needed. And the user himself communicated exclusively with high-level objects, receiving requests and returning results. But after a while, this scheme ceased to give us the necessary flexibility.



PS Taking this opportunity I propose to take a look at my personal and completely non-commercial blog dedicated to technology, psychology, philosophy and personal experience: http://v673.com .







We started to create ORM , where it is no longer necessary to communicate with the database, you just need to change the properties and parameters of certain objects, and saving them to the base has already been taken on by the abstraction.



There are cloud computing. Excellent benefits that allow you to abandon the content of their servers, monitor the performance, stability of staff and backup allowed companies to give all the concerns to outsourcing, bringing their databases and files to the clouds, thereby minimizing costs.



There was a problem: How not to become attached to a specific cloud system, whether Amazon EC2 or RHEV-M is tight and, if necessary, it is easy to change the cloud provider? Judging from my story, it is easy to predict the emergence of a system that will create this abstraction. And she appeared!



Meet New project DeltaCloud from the notorious Red Hat . He was announced at a recent 2009 Red Hat Summit conference.



With the help of the Deltacloud REST API , when developing a system, you have the opportunity to lay the necessary flexibility, the ability to keep your decisions relatively independent and, if necessary, easily change the cloud provider. A Deltacloud Proxy allows developers to create their own user interfaces, monitor the status of accounts, user authorization and resource allocation.







Currently two providers are supported:

• Amazon EC2
• Red Hat Enterprise Virtualization Manager (RHEV-M)

The developers promise an increase in the list of supported providers (specifically promise the emergence of support for VMWare ESX and RackSpace), as well as the addition of ready-made libraries to avoid direct interaction with the REST API. So, for example, the library for Ruby is already ready.



At a higher level, Deltacloud Portal provides a web-based interface that allows you to view and manage instances , easily move your data from one repository to another, and conduct convenient monitoring.



By the way, the project is completely free and open-source ( LGPL , GPL ). The task of Deltacloud , according to the developers, is to protect your projects from changes to the native API and the terms of service provided by cloud providers. On the official Deltacloud website, you can also watch videos where Red Hat engineers talk about this system.



Beautiful solution and beautiful approach. The project, which is likely to be in demand in the market. It remains to wish the developers good luck, perseverance and continuous improvement of the product.



PS Friends, if someone is interested in this direction - contact me via twitter or in another way : it will be interesting for me to talk. If you are interested in any undisclosed directions in cloud issues - speak, be happy to study them and write an article about it.