Salesforce Architecture: A Complete Guide Tutorial | CHECK-OUT

Salesforce Architecture: A Complete Guide Tutorial For FREE | CHECK-OUT

Salesforce Architecture Tutorial

About author

Vignesh (Associate Director - Cloud Architecture )

He is a Proficient Technical Expert for Respective Industry & Serving 11+ Years. Also, Dedicated to Imparts the Informative Knowledge to Freshers. He Share's this Blogs for us.

Last updated on 19th Jul 2020| 3599

(5.0) | 16547 Ratings

What is Salesforce Architecture?

Salesforce delivers a highly customized experience to the customers, employees, and partners of an organization. Such a platform is used to customize standard functionality and create custom pages, components, apps, etc. Also it is done faster, mainly because of the superb architecture on which it is built. Below is a brief introduction to the Salesforce Architecture

  • Instance- This is a set which includes a set of system, network, and storage infrastructure, of both share as well as non shared.
  • Superpod – It is a set which includes a set of system, network, and storage infrastructure moreover including outbound proxy servers, load balancers, mail servers, SAN fabric supporting multiple instances. Superpod provides us with service isolation which is inside a data center so that the problems with shared or even complex components cannot impact each and every instance in the data center.
  • Org ( that is “ Organisation”) – this refers to a single customer of the Salesforce application. Each and every trial started on  www.salesforce.com or developer.force.com swaps a new organization. org is an element which is highly customizable and can have a distinct number of security customizations, record visibility and sharing settings, UI look and the feel, triggers, workflow, customer object, custom fields on standard salesforce.com CRM objects. an org can be supportive to any one of the million licensed individual customer, portal user account, and Force.com website user accounts.
What is Salesforce Architecture?-Salesforce Architecture Tutorial

The architecture of Salesforce overview – What is Salesforce

  • Sandbox – Let’s take an example where Salesforce.com services take host full copies organizations for the customer application development purposes. Costumers can use this software and the platform and can have full application development lifecycles. These check environment for the costumer for the testing against their application before developing changes into their real production org.

    Subscribe For Free Demo

    [custom_views_post_title]

    Objects in Salesforce

    Salesforce has 3 primary types of objects:

    1. Standard Objects: These are objects that are already established within Salesforce when you first boot it up. These are things like the Account Object, Lead Object, and Contact Object.
    2. Custom Objects: These are objects your business will create based on your unique needs. So, if you run an event planning business, you may want an Events Object. 
    3. External Objects: These are custom objects that map data outside of Salesforce.

    These objects are basically data containers. And you can structure them using fields and records. To be clear, custom objects in Salesforce give you more functionality than a simple Excel spreadsheet. Beyond the relational features, custom objects in Salesforce generate custom layouts, and you can quickly set up reporting and analytic functionalities in each custom object.

    Fields in Salesforce

    Fields are your columns in Salesforce. Standard objects in Salesforce will come with prebuilt standard fields. And custom objects will also come with 3 standard fields automatically.

    These are:

    • Identity: This contains a 15-character unique data identifier for each record. The identity field is the key field in Salesforce. The data here is unique to each dataset, and it’s a core component of Salesforce’s relational structure (which we’ll get to in a bit).
    • Name: This is simply the name of the record. It can be a number or a name.
    • System: These are read-only and usually tell you the last time the record was touched. So, it will be something like LastModifiedByID.

    These fields are in EVERY Salesforce object — regardless of type.

    Beyond these fields, there are custom fields. Each custom field will have a data type associated with it. So, these could include checkboxes, formulas, dates, or a number of other things. 

    Records in Salesforce

    • Once you’ve defined an object and its fields, you can create records on that object. So, if you wanted to add a new account to the Leads Object, you would create a new record in Salesforce, fill out the pre-defined fields, and then you would have your record.
    • Like rows in databases, records attribute data to a unique identifier (a.k.a, the Identifier Field). Let’s say that you have a customer who your Sales team determines is a lead. They can create a new record in Salesforce under the Leads Object. That record is given a unique ID that associates all information that the sales team member plugs into the record with that particular account.

    The Two Types of Relationships in Salesforce

    • Lookup relationships: These are relationships that allow you to “lookup” related objects from within an object itself. This is the most basic relational link within Salesforce.
    • Master-Detail relationships: This is identical to lookup relationships with one big difference. Master-Detail relationships share a hard relationship. So, one object is a master object the other is a detail object. The master object controls the detail object. So, let’s say that you had a Master Object of Accounts and a Detail object of contacts. If you deleted Accounts, it would delete all of your contacts. These can get hyper-complex and create intricate webs of object There are a few other types of relationships that fall under the umbrella of these two relationships. These are:
    1. Self-relationships
    2. External lookup relationships
    3. Indirect lookup relationships
    4. Many-to-many relationships
    5. Hierarchical relationships
    6. relationships.

    The Core Architecture of Salesforce

    The architecture of Salesforce can be put into layers for better understanding. The purpose and function of each layer is described in detail in the below stated paragraphs- 

    What Are The Differences Between Sugarcrm & Salesforce?

    The Core Architecture of Salesforce-Salesforce Architecture Tutorial

    1). Multi-Tenant

    Multitenancy is an incredible word for influencing you to sound like a geek at supper parties, all things considered, all it implies is that you’re sharing your assets. Salesforce gives a central arrangement of administrations to every one of its clients in the multitenant cloud. Regardless of the span of your business, you gain admittance to a similar registering power, information stockpiling, and central features. Whereas a customary single-inhabitant application requires a committed arrangement of assets to satisfy the necessities of only one association, a multitenant application can fulfil the requirements of numerous occupants (organizations or divisions inside an organization, and so forth.) utilizing the equipment assets and staff expected to oversee only a solitary programming case. 

     Multi-Tenant-Salesforce Architecture Tutorial

    2). Metadata

    In Metadata-Driven Architectures multitenancy is viable just when it can support applications that are dependable, adaptable, upgradeable, secure, and quick. It’s hard to make a statically ordered application executable that can meet these and another one of kind, difficulties of multitenancy. Characteristically, a multitenant application must be dynamic in nature, or polymorphic, to satisfy the individual desires of different inhabitants and their clients. Thus, multitenant application plans have developed to utilize a runtime motor that produces application parts from metadata—information about the application itself. In an all-around characterized metadata-driven engineering, there is an unmistakable division of the ordered runtime engine (kernel), application information, the metadata that portrays the base usefulness of an application, and the metadata that relates to each occupant’s information and customizations

    3). API

    On a very basic level, APIs enable diverse bits of programming to interface with each other and trade data. On the off chance that it sounds sort of theoretical, just take a quick glance at the PC you’re working on right at this moment. You can presumably discover a progression of connections of different shapes and sizes that help various types of associations. These resemble the equipment form of APIs. You don’t need to know how the USB port functions. You should simply understand that when you connect your telephone to a USB port, it passes data to your PC.

    APIs are comparable. Without knowing the subtle elements, you can interface your applications with different applications or programming frameworks. The fundamental innovation deals with the specifics of how data goes all through the framework. 

    The architecture of Salesforce can be put into layers for better understanding. The purpose and function of each layer is described below −

    Trusted Multitenant Cloud

    Here multiple instances of one or multiple applications operate independently in a shared environment. The instances are referred as tenants and they logically separate from each other while physically remaining in the same hardware. It is called trusted because of both its robust nature and high security.

    Scalable Metadata Platform

    The metadata driven platform makes it easy for customization and scaling up as the amount of data or concurrent user instances increase.

    Enterprise Ecosystem

    The Enterprise Ecosystem of Sales is very large as a large number of partners contribute by creating and maintaining applications in this platform.

    CRM and Related Functionality

    Salesforce includes all aspects of CRM in its list of features and also extends it by providing features for creation of apps and integrating analytics, etc.

    Few Basic Pointers 

    There’s a great deal of information to unload here, yet how about we simply stick around the most critical points-

    • Salesforce is a cloud-based organization. All that they offer lives in the trusted, multitenant cloud systems.
    • The Salesforce platform is the establishment of their administrations. It’s controlled by metadata and made up of various parts, similar to information administrations, computerized reasoning, and powerful APIs for improvement.
    • All their applications sit on the platform. Their prebuilt contributions like Sales Cloud and Marketing Cloud, alongside applications that you manufacture utilizing the platform, have a steady and powerful functionality.
    • Everything is integrated within the Salesforce system. Their platform advancements like Einstein predictive intelligence and the Lightning system for improvement are incorporated with all that they have to offer and all that you manufacture

    Stats (As Of August 2013)

    • 17 North America instances, 4 EMEA instances and 2 APAC instances
    • 20 sandbox instances
    • 1,300,000,000+ daily transactions
    • 24,000 database transactions per second at peak (equivalent to a page view on other sites)
    • 15,000+ hardware systems
    • > 22 PB of raw SAN storage capacity
    • > 5K SAN ports

    Software Technologies Employed

    • Linux for development and primary production systems
    • Solaris 10 w/ ZFS
    • Jetty
    • Solr
    • Memcache
    • Apache QPID
    • QFS
    • Puppet, Razor
    • Perl, Python
    • Nagios
    • Perforce, Git, Subversion

    Hardware/Software Architecture

    Logging In To The Salesforce.Com Service

    • We maintain a pool of servers to handle login traffic for all instances. A handful of servers from many (but not all) instances accept login requests and redirect the session to the user’s home instance. This is what happens when you log in via login.salesforce.com.
    • Customer traffic starts with our external DNS. Once a lookup has successfully returned the IP address for an instance, standard Internet routing directs it to the appropriate datacenter.
    • Once the traffic enters our network in that datacenter, it is directed to the load balancer pair on which that IP lives. All of our Internet-facing IPs are VIPs configured on an active/standby pair of load balancers.

    Inside The Instance

    The load balancer directs the traffic to the application tier of the given instance. At this tier, we service both standard web page traffic as well as our API traffic. API traffic makes up over 60% of the traffic serviced by our application tier overall. Depending on the needs of the customer’s request, it will be directed to additional server tiers for various types of backend processing.

    Core App

    • The core app tier contains anywhere from ten to 40 app servers, depending on the instance. Each server runs a single Hotspot JVM configured with as much as a 14 GiB heap, depending on the server hardware configuration.
    • The batch server is responsible for running scheduled, automated processes on the database tier. For example, the Weekly Export process which is used to export customer data in a single archive file format as a form of backup.
    • Salesforce.com offers a number of services including basic and advanced content management. We have a content search server and a content batch server for managing asynchronous processes on the content application tier. The content batch servers schedule processing of content types, including functions such as rendering previews of certain file types and file type conversion.

    Database

    • The primary data flow occurs between the core app server tier and the database tier. From a software perspective, everything goes through the database so database performance is critical. Each primary instance (e.g. NA, AP or EU instances) uses an 8 node clustered database tier. Customer sandbox (e.g. CS instances) have a 4 node clustered database tier.
    • Since salesforce.com is such a heavily database-driven system, reducing load on the database is critically important. To reduce load on the database tier, we developed ACS — API Cursor Server. This was a solution to 2 problems which enabled us to improve our core database performance significantly. First, we used to store cursors in the database but the deletes were impacting performance. Second, after moving to using database tables to hold cursors, the DDL overhead became a negative impact. Thus was born the ACS. ACS is a cursor cache running on a pair of servers, providing a method to offload cursor processing from the database tier.

    Search

    • Our search tier runs on commodity Linux hosts, each of which is augmented with a 640 GiB PCI-E flash drive which serves as a caching layer for search requests. These hosts get their data from a shared SAN array via an NFS file system. Search indexes are stored on the flash drive to enable greater performance for search throughput.
    • Search indexing currently occurs on translation servers which mount LUNs from storage arrays via Fibre Channel SANs. Those LUNs make up a QFS file system which allows single writer but multi-reader access. Like most other critical systems, we run these in active/passive with the passive node doing some low priority search indexing work. It then ships its results to the active partner to write into the QFS file system.
    • The translation occurs when these same LUNs are mounted read-only from a group of four NFS servers running Solaris 10 on SPARC. These SAN mounted file systems then are shared via NFS to the search tier previously described.

    Fileforce

    • We maintain a tier of servers that provide object storage, similar in concept to Amazon’s S3 or OpenStacks’ Swift project. This system, Fileforce, was developed internally to reduce the load on our DB tier. Prior to the introduction of Fileforce, all Binary Large Objects (BLOBs) were stored directly in the database. Once Fileforce came online, all BLOBs larger than 32 KiB were migrated into it. BLOBs smaller than 32 KiB in size continue living in the database. All BLOBs in Fileforce have a reference in the database so in order to restore Fileforce data from backups, we have to start a database instance based on a database backup from the same restore point.
    • Fileforce includes a bundler function, developed to reduce the disk seek load on the Fileforce servers. If 100+ objects smaller than 32 KB are stored in the database, a process runs on the app servers to bundle those objects into a single file. A reference to the bundled file remains in the database along with a seek offset into the bundle. This is similar to Facebook’s Haystack image storage system but built into an object storage system.

    Support

    Each instance contains various other servers for support roles such as debugging application servers and “Hammer testing” app servers in the app tier, hub servers which monitor each instance for health and monitor servers running Nagios. Outside of the instance itself reside supporting servers like storage management, database management, log aggregation, production access authentication and other functions.

    Future Directions

    • On the database tier, we’re carefully examining several options for data storage systems. We’re also evaluating higher speed, lower latency interconnects such as Infiniband for our cluster interconnects with our existing database solution.
    • In the future, we expect to make the search hosts do all reads and writes. We are in the process of rolling out Apache Solr for search indexing. Solr runs locally on our existing search hosts. The SAN, NFS servers and SPARC based indexer hosts will all go away which will lead to a dramatic reduction in complexity of the entire search tier.
    • Our application container was previously Resin but over the last year, we’ve been migrating to Jetty. We’re also in the midst of a hardware refresh of our application tier hardware which will increase RAM sizes anywhere from 30% – 266% and introduce Sandy Bridge processors into our stack.
    • I hope this overview of the salesforce.com technology architecture and stack has been interesting and informative. Please leave a comment if you’re interested in additional guest posts deep diving into other parts of our expansive technology infrastructure. Thanks for reading!

    SALESFORCE PLATFORM

    SALESFORCE PLATFORM-Salesforce Architecture Tutorial
    • The Salesforce Technical Architect is critical to the shared success of our project teams and our Technical Services group. Working with best of breed consultants, you will be able to contribute and participate in many activities including solution design, sales, delivery, team leadership and importantly – thought leadership.
    • Successful Salesforce Technical Architect’s not only have a depth and breadth of understanding in technology, but are also able to maximize technology’s benefit by applying business value in context and communicating solutions and options to various levels within our client’s organizations. Individuals who are innovative, creative, curious, detailed, and solution driven are best fits for this role. Our Salesforce Technical Architects stay on the cutting edge of the fastest growing technology stack today, bringing the best solutions our top enterprise clients.

    Opportunities currently available in our offices in:

    • Chicago, IL
    • Los Angeles, CA
    • Minneapolis, MN
    • New York, NY

    Opportunities currently available in:

    • Open to remote locations

    KEY RESPONSIBILITIES:

    • LMA: Lead, Manage, and hold Accountable direct reports and project team members
    • Drive requirements gathering sessions with the client’s technical team and discuss functional requirements with the internal and client teams
    • Evaluate multiple feasible options for a solution and present to the client, guiding them toward the most optimal solution
    • Proficiency in the following technical artifacts (for current and future states): Data Model / ERD, System Landscape, Integration Orchestration Design / Process Flows, Sequence Diagrams, etc
    • Consult internal and client teams on Salesforce best practices
    • Responsible for the overall technical architecture and corresponding deliverables through a project’s lifecycle
    • Document and present technical requirements through various communication channels, including client 
interface
    • Provide thought leadership in technical areas of expertise to promote best of breed culture in Technical Services
    • Provide consultative services to all levels of business and technical people at leading enterprise customers to enable them to make confident decisions for their company
    • Guide the development team in the appropriate use of technology
    • Strong understanding of, and experience working in, Agile/Scrum teams
    • A strong understanding of Salesforce platform technologies

    Conclusion

    Salesforce architecture is not a surprising result of any random series of hit and trial experiments. Every feature of its architecture has been carefully planned and placed right where it requires to be. If you get a hand at its architecture you can understand most of its functionality.

    Name Date Details

    14-Oct-2024

    (Mon-Fri) Weekdays Regular

    16-Oct-2024

    (Mon-Fri) Weekdays Regular

    12-Oct-2024

    (Sat,Sun) Weekend Regular

    12-Oct-2024

    (Sat,Sun) Weekend Fasttrack