1.1 The Salesforce Platform, Cloud Computing & Multi-Tenancy

The Salesforce Platform, Cloud Computing & Multi-Tenancy

Quick Summary: Cloud computing eliminates on-premises hardware maintenance by providing computing resources over the internet. Salesforce delivers turnkey business software (SaaS) and an extensible application runtime (PaaS) via a multi-tenant, metadata-driven architecture. Automated governor limits protect shared infrastructure, and three seasonal releases occur annually with zero customer downtime.

Cloud Computing Service Models: IaaS, PaaS, and SaaS

Cloud computing is the delivery of computing services—including servers, storage, databases, networking, software, analytics, and intelligence—over the internet. Instead of purchasing, installing, and maintaining physical servers in on-premises server rooms or corporate data centers, organizations subscribe to virtualized computing capacity managed by specialized cloud providers.

To understand how Salesforce fits into modern cloud computing, you must understand the three foundational cloud computing service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).

+-------------------------------------------------------------------------+
| SaaS (Software as a Service)                                            |
| End-user business applications (Sales Cloud, Service Cloud)             |
+-------------------------------------------------------------------------+
| PaaS (Platform as a Service)                                            |
| App runtime, database schema, automation engine (Lightning Platform)    |
+-------------------------------------------------------------------------+
| IaaS (Infrastructure as a Service)                                      |
| Physical servers, hypervisors, storage clusters, network backbones      |
+-------------------------------------------------------------------------+

1. Infrastructure as a Service (IaaS)

Infrastructure as a Service provides basic computing infrastructure: physical or virtual servers, data storage, and network firewalls. Under an IaaS model, the cloud provider manages the physical data center hardware, power, and physical security, but the customer remains responsible for installing, configuring, patching, and maintaining the operating system, database software, middleware, and application runtime environments. Common examples of IaaS providers include Amazon Web Services (AWS EC2), Google Cloud Platform (Compute Engine), and Microsoft Azure Virtual Machines. While Salesforce utilizes secure, enterprise-grade infrastructure to host its services, end customers and administrators never interact directly with bare metal servers or operating system command lines.

2. Platform as a Service (PaaS)

Platform as a Service provides a complete hardware, operating system, and software framework that developers and administrators use to build, test, deploy, and scale custom applications without managing the underlying operating system or server hardware. In the Salesforce ecosystem, this capability is known as the Lightning Platform (historically referred to as Force.com). With the Lightning Platform, organizations can build custom database objects, design user interfaces, configure complex automated business flows, and write custom code (Apex and Lightning Web Components) directly within a pre-configured, scalable cloud environment. The customer controls the application logic and data model, while Salesforce manages operating system patches, database performance tuning, hardware upgrades, and network scaling.

3. Software as a Service (SaaS)

Software as a Service delivers fully functional, turnkey software applications hosted entirely in the cloud and accessible over the internet via a standard web browser or mobile application. The vendor manages the entire stack—from the physical servers and storage up through the application user interface. End users simply log in with their credentials to manage business operations. Salesforce's primary business applications—including Sales Cloud for opportunity tracking, Service Cloud for customer case management, and Marketing Cloud for engagement campaigns—are premier examples of SaaS. Organizations subscribe to user licenses and immediately gain access to mature enterprise business tools without executing software installation scripts.

---

Multi-Tenant Cloud Architecture

At the core of the Salesforce platform is multi-tenant cloud architecture. In conventional on-premises software or single-tenant cloud hosting, each customer operates an isolated server running a dedicated copy of the software and database. Upgrading or maintaining that software requires individual installation projects for every single company.

In contrast, multi-tenancy is an architectural model where multiple distinct customer organizations—referred to as tenants or orgs—share common physical and logical computing infrastructure, application servers, database instances, and network connections.

The Apartment Building Analogy

A helpful analogy for multi-tenancy is an apartment building:

• In a single-tenant model, every company owns a detached, single-family house. Each company must replace its own roof, service its own furnace, maintain its own plumbing, and pay for separate security. Upgrades are expensive and time-consuming.
• In a multi-tenant model, each company rents a private luxury apartment in a modern high-rise building. All tenants share the same central infrastructure: the building foundation, elevator banks, electrical grid, plumbing systems, and main security entrance. However, every tenant has their own secure front door, deadbolt lock, and private living quarters. One resident cannot peek into another resident's apartment, nor can they access another resident's private property.

Data Isolation via Organization IDs

Despite sharing underlying database tables and hardware clusters, customer data isolation is absolute and non-negotiable. Salesforce enforces strict data segregation at the software layer. Every database table in Salesforce includes a system-controlled column storing a unique 15- or 18-character identifier known as the Organization ID (OrgID). When a user logs in and queries data, the Salesforce database engine automatically and invisibly appends a filter restricting the query to that specific OrgID. It is programmatically impossible for a user or process from Tenant A to query, view, or modify the records belonging to Tenant B.

Advantages of Multi-Tenancy

1. Continuous Economy of Scale: Salesforce manages database optimization, disaster recovery, hardware replacements, and operating system security patches for all tenants simultaneously, reducing administrative overhead.
2. Democratized Innovation: A non-profit or small business with five users operates on the exact same world-class computing infrastructure and receives the exact same platform updates as a Fortune 50 enterprise with 200,000 users.
3. Reliability and Disaster Recovery: High availability, redundant server clusters, automated backups, and multi-region failover capabilities protect all tenants equally.

---

Governor Limits: Safeguarding Shared Resources

Because computing power, memory, database query threads, and network capacity are shared among multiple tenants on a common server cluster, the platform must guarantee that an inefficient transaction or an infinite loop written by one company cannot degrade performance for neighboring organizations.

To prevent resource monopolization, Salesforce enforces Governor Limits. Governor limits are strictly enforced runtime execution thresholds that restrict how many computing resources a single business transaction can consume.

+--------------------------------------------------------------------------+
|                     Salesforce Execution Engine                          |
|                                                                          |
|   [Tenant Transaction] ---> [Governor Limit Monitor] ---> [Database]     |
|                                     |                                    |
|                           Limit Exceeded?                                |
|                            /              \                              |
|                          Yes               No                            |
|                           |                 |                            |
|             [LimitException: Rollback]   [Commit Transaction]            |
+--------------------------------------------------------------------------+

Key Governor Limit Metrics

Governor limits monitor and cap various operational parameters during synchronous and asynchronous execution, including:

• Database Queries (SOQL): Limits the number of SQL-like queries a single transaction can issue against the database (e.g., maximum 100 queries in a synchronous transaction).
• Database Records Retrieved: Limits the total number of records retrieved by queries (e.g., maximum 50,000 records per transaction).
• Database Manipulations (DML): Limits the number of insert, update, or delete operations executed (e.g., maximum 150 DML statements).
• Total CPU Execution Time: Limits the maximum processor time a transaction can consume on Salesforce servers (e.g., maximum 10,000 milliseconds for synchronous operations).
• Heap Size: Restricts memory allocation for storing variables, record collections, and objects during execution.

What Happens When a Governor Limit is Exceeded?

If an automation, custom script, or complex workflow breaches a governor limit, the Salesforce engine immediately terminates the transaction. It throws an uncatchable runtime exception (System.LimitException) and initiates a complete database rollback. Any records created, updated, or deleted earlier within that specific transaction are completely reverted to their prior state. This strict enforcement guarantees that buggy or runaway logic in one tenant's org can never slow down, freeze, or crash the shared infrastructure for other tenants.

---

Metadata-Driven Architecture

A central question many newcomers ask is: If thousands of organizations share the same underlying database, how can each customer create custom objects, add custom fields, design custom page layouts, and configure automated validation rules without breaking the database or corrupting other companies' data?

The answer lies in Salesforce's metadata-driven architecture.

In the Salesforce ecosystem, there is a total structural separation between three layers:

1. Core Platform Code (System Engine): The compiled, proprietary code written by Salesforce engineers that manages data storage, security algorithms, user interface rendering, and application execution.
2. Metadata (The Blueprint): Data that describes data. Metadata consists of configuration definitions, schema structures, field types, formula logic, page layout arrangements, and automation workflows. Metadata contains no customer business records; it defines how records look, behave, and validate.
3. Tenant Data (The Content): The actual business records entered by users, such as customer names, phone numbers, email addresses, and closed sales opportunity amounts.

+-------------------------------------------------------------------------+
| USER INTERFACE LAYER: Dynamically rendered in browser                   |
+-------------------------------------------------------------------------+
| METADATA BLUEPRINT: Custom fields, validation rules, page layouts (XML) |
+-------------------------------------------------------------------------+
| CORE PLATFORM ENGINE: Multi-tenant execution runtime                    |
+-------------------------------------------------------------------------+
| DATABASE STORAGE: High-density multi-tenant storage partitioned by OrgID|
+-------------------------------------------------------------------------+

How Metadata Works in Practice

When an administrator navigates to the Object Manager and creates a new custom currency field called Expected_Commission__c on the Opportunity object, Salesforce does not execute a standard SQL ALTER TABLE statement on the physical database. Executing database schema modifications across millions of shared records would lock tables and introduce catastrophic downtime.

Instead, Salesforce simply writes a new row in a universal metadata catalog. The metadata catalog records that for this specific OrgID, on the Opportunity object, there exists a currency field named Expected_Commission__c. When a sales representative opens an Opportunity record in Lightning Experience:

1. The platform engine queries the metadata catalog to see what fields, layouts, and rules apply to that user's organization.
2. The engine queries the multi-tenant database to retrieve the raw data values matching that record ID and OrgID.
3. The engine dynamically combines the metadata blueprint with the raw data to render a clean, tailored web page in the user's browser.

Why Metadata Guarantees Backward-Compatible Upgrades

Because all customer customizations live purely as metadata decoupled from the core execution engine, Salesforce engineers can completely rewrite, optimize, and modernize the underlying platform code without touching customer configurations. When Salesforce deploys a platform upgrade, customer metadata remains intact, ensuring that existing custom fields, validation formulas, and automated flows continue functioning seamlessly.

---

Seasonal Releases: Spring, Summer, and Winter

Salesforce delivers regular technological innovation through a predictable, zero-downtime release model. Unlike legacy enterprise software suites that required multi-year upgrade cycles, costly consultant engagements, and extensive server downtime, Salesforce delivers three major seasonal releases every year:

• Spring Release: Typically deployed between January and February.
• Summer Release: Typically deployed between May and June.
• Winter Release: Typically deployed between September and October.

Key Principles of the Release Cycle

• Automatic Deployment: Releases are applied automatically by Salesforce to all customer environments during scheduled weekend maintenance windows. Upgrades require no manual software installations, file downloads, or server reboots by customer administrators.
• Inclusive in License Fees: All platform releases, security enhancements, and new core features are included automatically as part of the standard subscription cost.
• Backward Compatibility: Because of the metadata-driven architecture, existing custom fields, Apex classes, custom components, and workflows remain fully functional after every seasonal release.
• Sandbox Preview Windows: Approximately four to six weeks prior to a production release, Salesforce provides a Sandbox Preview. Organizations can refresh or designate test sandboxes to run the upcoming release version early. This allows administrators and quality assurance teams to test critical business processes, verify integrations, and explore new platform features before production orgs are updated.
• Release Readiness Resources: To help organizations prepare for upcoming changes, Salesforce publishes detailed Release Notes several weeks in advance. Additionally, Trailhead provides seasonal Release Readiness trails, badges, and live video broadcasts highlighting the most impactful administrative and developer enhancements.