Apps.gov = Huge Step Forward for Cloud Computing

Please see my latest post at The Cloud Option about federal government cloud computing: Apps.gov, FISMA compliance, Salesforce, and Google.

Enterprise Demand Driving Vendor Consideration of Internal Clouds

Please see my latest post at The Cloud Option about an emerging micro-trend in cloud computing platforms—the licensing of PaaS platforms for use in private data centers.

Introducing The Cloud Option Blog

I have moved my blogging activity over to The Cloud Option blog. Please follow me there, although I will continue to announce new posts in this blog as well.

Live Webinar Announcment: Multitenant Magic: Under the Covers of the Force.com Data Architecture

For those of you interested in Force.com and multi-tenancy issues, you won’t want to miss this. Craig Weissmann, Chief Software Architect of Force.com, is going to give a live webinar about the inner workings of Salesforce.com’s Platform as a Service (PaaS) offering. This presentation is based on the recent paper that Salesforce.com hired me to write for them.

Transparent Data Encryption: Experience from the Trenches

The Oracle Technology Network just published my latest article, titled Transparent Data Encryption: Experience from the Trenches. If you plan to use Oracle or back up databases using public cloud-based services such as Amazon.com’s EC2 or S3, then you will probably have special interest in this article because you will no doubt want to use Oracle’s TDE feature to encrypt any of your existing sensitive data before exposing it to a public cloud.

The Force.com Multitenant Architecture

Here is the link that I promised for the white paper that I wrote for the folks at Salesforce.com. The abstract for the paper reads as follows:

“Force.com is the preeminent on-demand application development platform in use today, supporting some 47,000+ organizations. Individual enterprises and commercial software-as-a service (SaaS) vendors trust the platform to deliver robust, reliable, Internet-scale applications. To meet the extreme demands of its large user population, Force.com’s foundation is a metadata-driven software architecture that enables multitenant applications. This paper explains the patented technology that makes the Force.com platform fast, scalable, and secure for any type of application.”

I hope that everyone finds it very useful and informative.

Introducing EquiVol

The generic application that I’m proposing for my cloud/PaaS/DbaaS application platform study is called EquiVol. The EquiVol application keeps track of the monthly open and closing price for a given publicly traded equity on a United States stock exchange. Besides being helpful with my stock trading endeavors, I believe that the EquiVol application will be able to flesh out a number of the capabilities of various cloud-based options for building applications.

The steps that I have identified so far for building EquiVol are as follows.

1. Declare the data model for the application, including the tables and indexes.

2. Declare the business logic, including the data integrity constraints, as well as the procedural logic (functions and triggers).

3. Bulk load sets of data into the application’s tables.

4. Build a web-based interface for manual data entry and reporting, including data entry forms, text reports, and graphical charts.

5. Integrate the application’s database with web services that provide access to pre-built logic.

6. Expose some of the application’s logic as web services so that other applications can reuse components of interest.

7. Implement business intelligence functions to analyze data.

8. Schedule jobs that automatically process data, such as analyzing data or sending email alerts to application subscribers.

The other interesting thing that I’ll be attempting to do is try to port the EquiVol application from one platform to another. Should be interesting. If you have any suggestions, please forward them along. Meanwhile, I’m going to get going on my Force.com implementation of EquiVol.

Multi-Tenant Times

I know, I know. I don’t have a very good track record updating my blogs. But now it’s time for me to change all of that. My main problem is that I get involved in projects that are all-consuming, and neglect my desire to regularly share my thoughts on Software as a Service (SaaS), Database as a Service (DbaaS), and cloud computing.

My most recent job was to author a technical white paper for the folks at Salesforce.com that explains the internal plumbing of the multi-tenant architecture that supports Force.com. If you are interested in multi-tenancy and how Force.com is engineered, you don’t want to miss this document. This paper is being printed for distribution at the DreamForce08 Conference. I also drafted an accompanying presentation that VP/Cheif Architect Craig Weissman will deliver at the conference. When I have links to the paper and presentation, I’ll update this post.

So what’s next for me and this blog? The overall objective is to provide you with information that you will be able to use to compare and contrast various Platform as a Service (PaaS) solutions, and hopefully make the right choices for you and your projects. Here are the details of my plan.

• Design a generic, easy-to-understand, yet full-featured application.
• Implement the application on various PaaS/DbaaS offerings.
• Demonstrate the capabilities, strengths, and weaknesses of each PaaS.

As I do this and the posts gain visibility, I’ll imagine that I’ll collaborate with the more eager vendors that wish to comment on my understanding of their products. I also look forward to constructive comments from readers that will help improve the information that I publish. Eventually, everyone will be able to use this blog as a reference library that will be invaluable for understanding application developement and administration for PaaS and DbaaS.

Database as a Service (DbaaS) Product Directory Published

I haven’t had time to post the past few days because I took a short trip to New York City. What an impressive place to visit! So much to see and do. Museums, buildings, shows, people watching, and don’t forget some of the best restaurants on the planet.

When you get a chance, take a look at the very first version of my Database as a Service (DbaaS) Product Directory. I’ll be using this directory to review, explain, and compare the DbaaS products in future posts. If you have anything to add or edit, use the comments form at the bottom of the page to get in touch with me. If you are a vendor and would like to schedule a product tour with me, feel free to use the same method to get in touch with me.

What Exactly Is Database as a Service?

To make sure that we are all starting from the same point, I thought it would be prudent to clearly define the term “Database as a Service” (DbaaS), at least as I see it. As of the time that I wrote this post, there were no related pages at Wikipedia about Database as a Service or DbaaS. So I guess that means my options are wide open. But rather than coin my definition of Database as a Service at the beginning of this post, I’d prefer to explain some of my initial thoughts around DbaaS and then end the post with a concise definition. And I’d very much like to hear feedback from you to shape further discussions going forward.

The Principles of Database as a Service

Software as a Service (SaaS) has become all the rage in recent years for many reasons. For example, SaaS is attractive to the customer because it shifts the onus and cost of hardware and software deployment and maintenance from the customer to the vendor. SaaS also provides many benefits to the vendor, who can now develop and maintain the application on a single platform and see instantly how customers use features of their application. For a more thorough definition of SaaS and its benefits, try starting with Wikipedia’s page on SaaS.

DbaaS is nothing more than a focused realm within the greater field known as SaaS — it’s the delivery of database software and related physical database storage as a service. For something to be categorized as “Database as a Service,” I believe that it must meet the following three requirements.

• The service must be available to the customer on-demand, without any requirement for the installation and configuration of any hardware or software up-front.
• The service must be paid for by the customer on an as-used basis, without any requirement for a long-term contract or up-front payment. Examples of this might be monthly subscriptions per user, CPU usage, transactions, or storage (or some combination of the these).
  
• The provider is responsible for managing the service, without any requirement for the customer to maintain, upgrade, or otherwise administer their database.

Disagree? Did I miss any? Please give me your feedback.

Other Features of DbaaS

As future posts will detail, the DbaaS offerings that are starting to appear from various vendors provide many features that, while useful, are not necessarily core requirements for something to be classified as “Database as a Service.” For example, some DbaaS offerings are part of a bigger platform that’s delivered as a service (Platform as a Service, or PaaS), including an integrated development environment (IDE) for building and deploying co-located applications. In contrast, other service providers deliver just the database (without the platform) and expect that you will use your preferred language (Java, .NET, PHP, whatever) and toolset to build applications that are executed completely independent of the database service. One DbaaS might be based on a relational database management system (RDBMS) and expect your applications to use SQL for database access, while another might be based on some other type of database technology and have it’s own proprietary application programming interface (API). These few examples are just a smattering of features that I’m seeing today from emerging DbaaS. To help you understand this new technology space, I intend to produce future posts and eventually a set of comparative summaries that explain and contrast the features of various DbaaS offerings.

My Definition of Database as a Service

So, to end this post, let me give you my concise definition of Database as a Service.

A managed service, offered on a pay-per-usage basis, that provides on-demand access to a database for the storage of application data.

Again, I welcome everyone’s feedback.