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.
- 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).
- 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 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.
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.
- 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
- 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.
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.
- 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.