Entire white papers have been written to describe what goes on under the hood of Salesforce and the Force.com platform, and this section is not intended to go into that level of detail.
There are a number of key concepts that developers have to grasp about the platform in order to understand why we have to develop applications the way we do. Four of these concepts are outlined here.
Every Salesforce Customer Uses Shared Infrastructure
Salesforce is built on what we refer to as a “Multitenant Architecture.”
Multitenancy – where many customers share the same infrastructure and database – is what enables Salesforce to deliver its application and services to tens of thousands of customers running on the same version of Salesforce.
A common analogy used to describe multitenancy is owning a house vs. renting a condo. In the days before cloud computing, IT had to maintain the computing infrastructure that drove the performance and availability of custom and packaged software applications.
Just like owning a house where you could tear down walls, build out additions, or add new infrastructure services such as electrical or plumbing, owning the infrastructure enabled IT to tune or upgrade the underlying infrastructure to scale software applications.
With Salesforce, we don’t own the house anymore. Salesforce is like a highrise where thousands of tenants rent condos. While these condos are beautiful and spacious, we now have to adhere to constraints that we never did when we owned a house.
We’re given four walls and we have to learn to live within them. We can use any infrastructure services we want to, but since we are sharing these services with thousands of other tenants, there are limits in place to prevent any one tenant from hogging them all.
Why does multitenancy matter to us as developers? Because without it, we would have to spend a great deal of our time maintaining infrastructure and software releases. By having every customer on the same hardware and the same version of the Salesforce application, we no longer have to worry about all of the moving pieces that make up the underlying architecture.
When we moved from our house to our condo in the sky, Salesforce took over handling the infrastructure, allowing us to shift our focus to developing innovative applications that take full advantage of the power of the underlying platform and help our organizations or clients do business in new ways.
With three releases to Salesforce and the Force.com platform happening each year, multitenancy also enables a virtuous cycle of innovation where end users and developers get access to upgraded features and functions every few months.
While many developers new to Salesforce and Force.com may see the constraints of a mutitentant architecture as a roadblock, learning to embrace these constraints and live within resource limitations is a fundamental conceptual leap that developers have to make in order to have any success with Apex.
The Force.com Platform is an Abstraction of the Underlying Infrastructure
Another concept that Salesforce developers have to grasp is that of abstraction. Abstraction of the underlying multitenant architecture is what gives each individual Salesforce customer the freedom to customize an instance of Salesforce and make it their own.
Not to oversimplify, but Salesforce is essentially a massive Java application sitting on top of a massive Oracle database. This does not do the beauty and power of the underlying multi-tenant architecture justice, but for the sake of learning how the platform works, all we need to know is that Salesforce is a large scale web application built on a large scale relational database.
Why don’t we need to know specifics about the complex inner-workings of the Salesforce platform infrastructure? Because the details don’t matter. What type of server hardware does Salesforce use? It doesn’t matter. What flavor of UNIX does Salesforce run on? It doesn’t matter.
The only thing we as developers need to know is that we never get direct access to infrastructure resources – all requests for access to processing, memory, network and database resources have to be passed through Force.com.
The Force.com platform is an abstraction of its underlying infrastructure, and our job as Salesforce developers is to learn how to design, build and deploy procedures and applications that leverage the capabilities of the platform in an optimal and effective manner.
We can’t just “throw hardware” at code problems anymore. We have to write code that makes the most effective use of the resources that we are given.
Apex is an Abstraction of the Force.com Platform
The Apex programming language is what enables developers to write code to leverage Salesforce and the Force.com platform as a driver of business innovation. When declarative “point and click” solutions do not go far enough to meet business requirements, we can meet those requirements programmatically with Apex.
Apex is not a general purpose programming language. Unlike Java, which will run on any underlying platform given the necessary virtual machine, Apex is a proprietary language that is tightly coupled with the Force.com platform. You can’t run Apex anywhere other than on Force.com because the language was built from the ground up as an abstraction of the Force.com platform.
Being tightly coupled with Force.com presents both challenges and opportunities. The number one challenge that developers run into is that programmatic access to the Force.com platform using Apex code is governed by limits on access to processing, memory, network, database and other resources. Learning how to live within these constraints can be difficult when coming from other languages where limits on resource usage are not inherent to the platform.
On the other hand, Apex has total awareness of the data model and configuration for the Salesforce instance that it runs in, and knowing how to leverage the myriad classes and interfaces that have been built specifically to ask the Force.com platform to perform operations on our behalf is fundamental to being an effective Apex developer.
Salesforce Development is Metadata-Driven
What is metadata? Metadata is simply data that describes other data – metadata is what gives your data context, whether it’s data about your customers or data used for application configuration.
The Salesforce metadata-driven architecture is what enables abstraction of the underlying infrastructure and database, which is what enables the multitenant architecture, which in turn enables the tens of thousands of Salesforce orgs to be running on the same version of the Salesforce application yet support the unique customization needs of each individual customer.
For example, if you were to look at a detail page for an Account record, you would see field labels that describe the data stored in that field, and the user interface would render HTML elements such as date pickers or dropdown lists based on the data type of the field. Even the data to describe the sections that appear and the placement of each of the fields on the page layout is stored as metadata.
The metadata-driven architecture of the Force.com platform allows Salesforce developers to reuse common pieces of functionality provided by the platform to create new applications, and the data that describes how each of these “building blocks” of functionality should work is stored as metadata in the same database that stores all of our business data.
Taking a metadata-driven approach to application development means having to write and maintain less code. While it may seem paradoxical to developers new to the Force.com platform, the goal of every Salesforce developer should be to use “clicks” instead code and develop applications declaratively wherever possible, with the metadata for these declarative customizations stored in the Force.com database.
When declarative development options have been exhausted and Apex code needs to be written, the Apex language itself provides built-in capabilities to assist developers with working with metadata.
Learning how to use metadata to describe the schema and configuration of a given Salesforce instance is a key skill to master. Apex provides many system classes to help developers ask the Force.com about itself for the purpose of creating further abstractions of the Force.com platform in our own code to promote reusability and reduce hard-coding to specific instances of the platform.