With this rapid evolution of both hardware and software, the expectations we place on our databases have changed significantly.  Web applications have a different set of needs from a database than an enterprise client-server application, and alternative database technologies have sprung up to meet this need.  This doesn’t mean your web application should automatically use one of the new database technologies, but it certainly means you shouldn’t keep using the same database you have for the last twenty years without considering your options.  The hardware we run our applications on today is also dramatically different – your smartphone has a faster processor and more memory than a server did when many databases were originally authored.  Data sets are now measured in terabytes and petabytes for many applications.

If you’re still running an application with a smaller data set measured in the 10s or maybe even the 100s of gigabytes, you should probably run database software that is easy to configure, maintain, and that has a rich ecosystem of tools around it. On the other hand, if you have a big data problem it is time to analyze some of the new solutions available as open source projects.  The attached presentation provides a high level overview of a few database alternatives, but many more also exist.  It also links to the write-up about Mozilla’s Test Pilot project, where they talk about the process they used to select a database that met their needs.

Please make sure you spend the time doing the analysis, as that time spent will be inversely proportionate to the amount of time you’ll spend re-working a decision made in haste – measure twice, cut once.

The Cloud Servers API draft specification can be downloaded here.

Inside the API specification you’ll find more details about new features including the following:

• Server Metadata – You may now supply server-specific metadata at launch time that can be accessed via the API.

• Server Personalization – You may now specify files at launch time that will be injected into the server file system before startup. This is useful, for example, when inserting SSH keys, setting configuration files, or storing data that you want to retrieve from within the Cloud Server itself.
• Host Identification – The Cloud Servers provisioning algorithm has an anti-affinity property that attempts to spread out customer VMs across hosts.  Under certain situations, Cloud Servers from the same customer may be placed on the same host.  Host identification allows you to programmatically detect this condition and take appropriate action.
• Shared IP Groups – While we’ve always supported shared IPs, we’ve made this simpler with the creation of Shared IP Groups and the ability to programmatically enable high availability configurations.

We’re asking for your input by Tuesday, June 2, 2009, to be considered in the 1.0 release of the API. We encourage you to share your feedback publicly here on the blog or via Twitter. For Twitter, our team will be looking for input using the hash tag #csapi and tweets to @bpiatt.

You can also send us feedback privately by sending us an email at Cloudserver_API@mosso.com.

Thanks so much for being a part of the team, and we look forward to reading and discussing your suggestions!

Bret Piatt