We are thrilled to share our knowledge on the Salesforce.com platform. We are starting this with the first blog post on Force.com Architecture, this is the 1st part in the series on this topic. Please stay tuned for the rest of the post.
Cloud Computing
Since the turn of the millennium, cloud computing has revolutionized the landscape of the IT world because it provides enterprise-grade computing resources that are affordable and instantly available. Clouds provide straightforward access to IT resources—you just access as many resources as you need when you need them, and never have to deal with the complexities of managing all of the underlying mechanisms that provide those resources. Life is suddenly a lot simpler and easier with cloud computing.
Multitenancy
Multitenancy is the fundamental technology that clouds use to share IT resources cost-efficiently and securely. Just like in an apartment building—in which many tenants cost-efficiently share the common infrastructure of the building but have walls and doors that give them privacy from other tenants—a cloud uses multitenancy technology to share IT resources securely among multiple applications and tenants (businesses, organizations, etc.) that use the cloud. Some clouds use virtualization-based architectures to isolate tenants; others use custom software architectures to get the job done.
The multitenant design of a cloud service can have a dramatic impact on the application delivery and productivity of an IT organization, yet most CIOs, CTOs, system architects, and developers who use clouds don’t give it a second thought because it’s all magic that transparently happens behind the scenes. This paper presents an “under the hood” look at the unique underlying design of core Salesforce Platform technology, Force.com.
Force.com Architecture Overview
Force.com is the proven cloud application development platform that powers many popular salesforce.com cloud applications (Sales Cloud, Service Cloud, etc.), as well as custom applications that customers build to satisfy their specific business requirements. The following sections provide you with an overview of key aspects of the platform’s design.
Multitanant Kernel
Force.com is a modern Platform as a Service (PaaS) that are built for cloud computing, with multitenancy inherent in its design. A quick way to understand what makes Force.com unique is to consider the following figure that compares a traditional application development platform with Force.com’s multitenant approach.
At the heart of all conventional application development platforms beats a relational database management system (RDBMS), most of which were designed in the 1970s and 1980s to support individual organizations’ on-premises deployments. All the core mechanisms in an RDBMS—such as its system catalog, caching mechanisms, query optimizer, and application development features—are built to support single-tenant applications and be run directly on top of a specifically tuned host operating system and raw hardware. Without significant development efforts, multitenant cloud database services built with a standard RDBMS are only possible with the help of virtualization. Unfortunately, the extra overhead of a hypervisor typically hurts the performance of an RDBMS.
METADATA-DRIVEN KERNEL
An inherently multitenant platform such as Force.com, which is designed specifically to service a cloud, is difficult to build because it must be reliable, scalable, customizable by tenants, upgradeable without downtime, secure, and fast. But how can you keep tenant-specific data secure in a shared database so that one tenant can’t see another tenant’s data? How can one tenant customize various schema objects and an application’s user interface in real time without affecting the functionality or availability of the system for all other tenants? How can the system’s code base be patched or upgraded without breaking tenant-specific schemas? And how will the system’s response time scale as tens of thousands of tenants use the service?
It’s difficult to create a statically compiled system executable that can meet these and other unique challenges of multitenancy. Instead, a multitenant cloud-oriented platform must be dynamic in nature, or polymorphic, to fulfill the individual expectations of various tenants and their users.
For these reasons, Force.com’s core technology uses a runtime engine that materializes all application data from metadata—data about the data itself. In Force.com’s well-defined metadata-driven architecture, there is a clear separation of the compiled runtime database engine (kernel), tenant data, and the metadata that describes each application. These distinct boundaries make it possible to independently update the system kernel and tenant-specific applications and schemas, with virtually no risk of one affecting the others.
POLYGLOT PERSISTENCE
Force.com integrates and optimizes several different data persistence technologies to deliver transparent polyglot persistence for all your applications and devices. With Force.com, you don’t have to deal with the complexity of trying to integrate, manage, test, and support several systems, and you only have to code to a single API, no matter which type of persistence is optimal for a given situation. The following figure is an overview of a sampling of Force.com’s persistence technology.
At the heart of Force.com is its transaction database engine. Force.com uses a relational database engine with a specialized data model that is optimal for multitenancy. The next section of this paper explains more about this schema.
Force.com also uses other persistence technologies to deliver fast, scalable performance for various operations. For example, to further hone application response times, Force.com employs a search engine (separate from the transaction engine) that optimizes full-text indexing and searches. As applications update data, the search service’s background processes asynchronously update tenant- and user-specific indexes in near real time. This separation of duties between the transaction engine and the search service lets applications efficiently process transactions without the overhead of text index updates and at the same time quickly provide users with accurate search results.
Now that you have a general idea of the key architecture components that make up the underlying mechanisms of Force.com, it’s time to learn more about the structure and purpose of various internal system elements that make up the data model that supports the transaction engine.
In the next part of this post, we’ll discuss Force.com Data Model.
References: Force.com White paper series