Multi-tenancy and Model Driven Engineering, necessary assets of a Platform-as-a-Service

Back in 2003 Nicholas Carr wrote about the similarity in evolution patterns of information technology and earlier technologies like railroads and electric power. Carr stated that as the availability of "infrastructural technologies" increases and their cost decreases, they become commodity inputs. With the current cloud-computing phenomenon IT solutions are applied and composed by organizations, but executed and managed by expert third-party providers. IT is industrializing.

I recently wrote about making software development faster, more agile, by modeling software and executing these models in a cloud, i.e. Model-Execution-as-a-Service. A lot of these "-as-a-Service" and other cloud-related terms have been introduced lately. Platform-as-as-Service (PaaS) is one of those new hype terms which is used a lot nowadays. Time to get a deeper understanding about this concept and to research how it relates to other concepts like Model Driven Software Development.

Article highlights:
  • A Platform-as-a-Service is a platform hosted by a provider and delivered as a service to customers. It facilitates deployment of applications without the cost and complexity of buying and managing the underlying hardware and software layers.
  • PaaS is a layer of cloud computing inbetween IaaS and SaaS.
  • Multi-tenancy is fundamental to PaaS as it enables developers to focus on application development rather than managing application infrastructure.
  • Model Driven Engineering is fundamental to PaaS because it enables multi-tenancy and small contracts.
  • We will see a development into the direction of Domain-Specific Platform-as-a-Service solutions.

Introducing the cloud stack

Before going into the details of Platform-as-a-Service let’s first look at the broader cloud-computing picture. Basically, cloud computing can be defined as a computing capability that provides an abstraction between the computing resource and its underlying technical architecture. Computing resources are delivered on demand and often billed based on usage. We can make a distinction among three different layers of cloud computing:

  • Infrastructure-as-a-Service (IaaS): typically a platform virtualization environment. Instead of purchasing hardware, datacenter space, and network equipment, clients buy these infrastructures as a fully outsourced service. In principle IaaS is an abstraction layer on top of hardware.
  • Platform-as-a-Service (Paas): a computing platform or solution stack provided as a service. It facilitates deployment of applications without the cost and complexity of buying and managing the underlying hardware and software layers.
  • Software-as-a-Service (SaaS): a model of software deployment whereby a provider licenses an application to customers for use as a service. The software is hosted by a service provider.

The presented layers can be seen as a layered architecture. PaaS is build on top of IaaS. SaaS is build on top of Paas. This layering can be compared to the layered stack of traditional applications: infrastructure, (application) platform, application.

Defining Platform-as-a-Service in detail

Now we have a basic idea about the context, let’s try to define what a Platform-as-a-Service (PaaS) is. A platform is a crucial element in software development. A platform might be simply defined as ‘a place to launch software’. The software is written in a language according to a contract implemented by a platform. In other words: there is a contract between a platform and the software running on it. The java platform (the JVM), for example, implements a contract including the Java programming language and lots of libraries. Another example of a platform is a business process engine. In this case the contract is much smaller and only comprises the process language (e.g. BPEL).

A Platform-as-a-Service is a platform hosted by a provider and delivered as a service to customers. It facilitates deployment of applications without the cost and complexity of buying and managing the underlying hardware and software layers. 

The previously mentioned examples of a platform directly show that the definition of ‘platform’ is quite broad. To make the definition of PaaS a bit more strict I think it is useful to list some of the essential characteristics of a Platform-as-a-Service:
  • It is a platform to launch software applications. That’s why PaaS is sometimes referred to as Application Platform-as-a-Service (APaaS) or Service-Enabled Application Platform (SEAP).
  • More specifically it is a platform to deliver Software-as-a-Service (SaaS).
  • It enables to build multi-tenant applications. Multi-tenancy is fundamental to PaaS as it enables developers to focus on application development rather than managing application infrastructure. I will explain multi-tenancy in detail in the next section.
  • In line with the previous characteristic: a PaaS should handle all infrastructure related issues like configuration, scalability, performance, security, etc.

Notice that I see PaaS as a Runtime Platform-as-a-Service, not as a Development Platform-as-a-Service. This means I don’t see online development as an essential characteristic of a PaaS. Offline development tools and PaaS can be a suitable combination too.

Multi-tenancy

Multi-tenancy is fundamental to PaaS. In a multi-tenant environment a single application can be used and customized by different organization as if they each have a separate instance, yet a single, shared stack of software and hardware is used (see Figure 1). In other words: multiple tenants (organizations, departments, etc.) use the same Software-as-a-Service running on the same codebase, database, and other software and hardware resources. A multi-tenant architecture ensures that their data and customizations remain secure and insulated from the activity of all other tenants.

Figure 1 – Multiple tenants share the same software and hardware stack
 
Most multi-tenant platforms are metadata driven. They use metadata as a way of configuring the platform and applications for each individual tenant. If, for example, the application contains a customer entity, it is possible to add additional attributes (e.g. phone number, email) to the customer entity only for one of the tenants (e.g. an organization using the application). These additional attributes are defined in the metadata, all logic and storage is based on this metadata. In principle, every part of the application can be customized for specific tenants.

What’s so special about multi-tenancy? I can customize my application for different users too! I think a platform can only be multi-tenant in a cost-effective way if it is designed so from its inception. The following characteristics are important in multi-tenancy:

  • Tenant-specific customizations are not created by copying all application logic and changing it. Only the needed changes are defined, they ‘override’ the existing logic.
  • Not only the logic can be customized, it is possible to apply tenant-specific datamodel changes too. As all tenants operate on the same database, this database need to be very flexible and metadata driven to provide different structures to different tenants.
To make the idea a bit more clear I want to compare the idea of multi-tenancy with some implementation approaches:
  • Multi-tenancy can be compared to creating subclasses in Java and injecting instances of these classes at runtime based on the tenant accessing that part of the code.
  • In a platform based on model interpretation multi-tenancy can be reached by letting model parts overwrite the core model. If the platform, for example, needs to execute a business rule, it first looks if a customized rule exists for the current tenant. If so, this rule will be executed, if not the default rule will be executed.
  • Multi-tenant data storage can be implemented by using a generic database structure and constructing queries at runtime based on metadata. See the Force.com whitepaper (pdf) for a more detailed explanation of this concept.

Platform-as-a-Service and Model Driven Engineering

One of the main differentiators among PaaS solutions is the size of the contract. I already mentioned two examples, Java and BPEL, the latter having a much smaller contract. You can go even further by defining a contract only enabling to build applications for a specific business domain (e.g. insurance, banking, logistics). Smaller contracts lead to more domain-specific PaaS solutions. I think the main advantages of a small contract are:

  • Easier to secure (no low-level API access).
  • The (programming) language can be domain-specific.
  • Abstractions in the language can directly reflect concepts from the application domain.
  • Error checking, recovery, debugging, etc. can all be domain-specific.
  • Possibility for domain-specific optimizations, i.e. optimizations based on domain knowledge.
  • Applications for a PaaS with a small contract can be created by domain experts.
  • Big differentiator compared to IaaS. A small contract means a lot of knowledge in the platform itself, meaning it isn’t that easy to build your own version on top of an IaaS provider.

As multi-tenancy is fundamental to PaaS, most Platform-as-a-Service solutions are metadata-driven. This means that the application logic is based on metadata which can be changed at runtime. This metadata can be seen as a model. Hence techniques like adaptive modeling are useful to be aware of when designing a PaaS.

Combine metadata-driven with the fact that the contract of a PaaS needs to be as small as possible, and see what you get… meta, model, domain-specific? Right, Model-Driven Engineering

I think Model Driven Engineering is fundamental to PaaS because it enables multi-tenancy and small contracts. Small contracts are only possible when high-level languages are used. Most PaaS solution use wizards to create parts of an application. They can learn a lot from Domain-Specific Language design.

Examples

I want to finish this article with a list of PaaS solutions and the language(s) you can use to develop applications targeting the platform:

  • Force.com: wizard like languages, process modeler, APEX.
  • Bungee Connect: Bungee Sky, a C-style language.
  • LongJump: wizard like languages, Java, Javascript.
  • Engine Yard: Ruby on Rails.
  • Windows Azure: C#, VB, C++, PHP, Java, Python, Ruby, and higher level services like AppFabric (service bus), SQL Azure, etc.
  • OrangeScape: Excel like language.
  • Rollbase: specific models (DSLs) for different application aspects (data, logic, UI, permissions, organization, integration).
  • Google App Engine: Python, Java.
  • VMForce.com: Java (Spring) on Force.com.
  • Mendix: specific models (DSLs) for each application aspect (rich forms, domain model, microflows, business rules, webwervices, internationalization, integration, theming, security, documents, reporting, etc.). Extensible with Java and Javascript.
Most development environments are offline, most solutions do not really emphasize multi-tenancy.
 

Conclusion

Multi-tenancy and Model Driven Engineering are fundamental to a Platform-as-a-Service. I think PaaS solutions with low-level contracts won’t have a long live.

I think we will see a development into the direction of Domain-Specific Platform-as-a-Service solutions. Both business domains (e.g. specific PaaS for insurance, logistics, etc.) and architectural domains (e.g. process engines as-a-Service, event engines as-a-Service, business rule engines as-a-Service, in principle every service type in a SOBA).

Do you have experiences with PaaS solutions? What do you think about the future of PaaS?
Photo by portal23

4 Comments Added

Join Discussion
  1. Dennis Mulder May 3, 2010 | Reply

    Hey Johan,
    Very nice post about Cloud Computing and Model Driven Exp. I follow your blog for a while now and like
    Since you are now writing about technology that I am involved in significantly I feel the pressure to respond to some of your statements.
    In the section on PaaS you mention:
    “More specifically it is a platform to deliver Software-as-a-Service (SaaS)”
    I don’t completely agree with this statement. While indeed a PaaS platform can be a great starting point for ISV’s to build SaaS solutions on top off it is also a platform to build business applications on.
    From your post it seems you are using PaaS as an acronym for the actual solutions that are build on top of the platform, or am I misunderstanding what you mean?
    In my opinion:
    1) The solutions build on top of the PaaS platform should be model driven in order to benefit from the advantages you mention.
    2) A PaaS platform it self can be model driven too in order to be agile in terms of the infrastructure and associated elasticity.
    3) Most current PaaS platforms can do a better job in providing multi tenancy support in their frameworks to build SaaS solutions. And indeed these can benefit a lot from the model driven approach.
    I am very curious what the models in PaaS platforms and solutions build on a PaaS platform would look like.
    A future post?
    Regards,
    Dennis Mulder
    Microsoft Corporation

  2. Johan den Haan May 5, 2010 | Reply

    Hi Dennis,
    Thanks for taking the time to comment. You don’t have to feel pressure ;) I’m happy to receive feedback, albeit a single line.
    > I don’t completely agree with this statement. While indeed a PaaS platform can be a great starting point for ISV’s to build SaaS solutions on top off it is also a platform to build business applications on.
    I agree. In fact, most of the example PaaS solutions I mentioned are focused on business application instead of multi-tenant SaaS solutions for ISV’s. However, business applications build on a PaaS are hosted and delivered in the ‘cloud’. They are provided as a service and hence can be called SaaS. The question is: what is the exact definition of SaaS?
    > From your post it seems you are using PaaS as an acronym for the actual solutions that are build on top of the platform, or am I misunderstanding what you mean?
    I use PaaS as an acronym for a hosted platform executing software defined in a certain language (the contract between software and platform). This language / contract should be as high-level as possible in my opinion. Hence, PaaS should use elements from MDE and DSL design to design the contract.
    I think it was confusing that I used the term ‘PaaS solution’ to refer to a Platform-as-a-Service.
    > I am very curious what the models in PaaS platforms and solutions build on a PaaS platform would look like. A future post?
    I will definitely write a future post about PaaS. However, the list with ideas is quite long, so it can take some time ;)

  3. John Verity February 26, 2012 | Reply

    Shameless self-promotion: I’ve taken a quick shot at thinking about how well MDA/MDD and the cloud may be suited for each other. I wonder if you’d agree.

  4. Johan den Haan February 27, 2012 | Reply

    Hi John,
    Good points! As stated in the conclusion of the article above I believe in a growing attention for Domain-Specific PaaS.
    I will address your closing question “What kind of PaaS do you envision?” in more detail in a future article.

Leave a Reply