Behind the Scenes of Hyperforce: Salesforce’s Infrastructure for the Public Cloud

Salesforce has been running cloud infrastructure for over two decades, bringing companies and their customers together. When Salesforce first started out in 1999, the world was very different; back then, the only practical way to provide our brand of Software-As-A-Service was to run everything yourself — not just the software, but the servers, storage, networking devices, cooling, etc.

Of course, in the years since then, massive changes have swept the industry. In recent times, companies like Amazon, Microsoft and Google have begun offering infrastructure as a service (IaaS), providing all of the same infrastructure components (servers, storage, networking, etc.) in an abstracted, self-service way. These days, nearly everyone who runs web software at scale leverages IaaS in some way (including most of our customers, too!).

So, in order to leverage the scale and agility of the world’s leading public cloud platforms, our Technology and Products team has worked together over the past few years to build a new generation of infrastructure platform for Salesforce — one that uses cloud-native tools, deployment patterns, security, and processes, and is available across all of our product lines. We call this architecture Hyperforce.

Hyperforce isn’t just an incremental evaluation of our infrastructure — it’s a complete step function change that will bring the most modern, scalable, and secure development practices to every engineering team at Salesforce. At its core, Hyperforce is based on five key architectural principles: Immutable Infrastructure, Multi-Availability-Zone Design, a Zero Trust approach to security, the idea of Infrastructure-As-Code, and the commitment to starting with a Clean Slate. To give you a sense of what Hyperforce really is, and why it’s so transformative, let’s take a closer look at each of these principles.

Immutable Infrastructure

When we create infrastructure resources in Hyperforce (containers, services, networks, etc), those resources are immutable. This means that once the resource is in place, rather than making patches or changes to it directly in our production environment, we replace it wholesale with an updated version. This approach maintains a predictable state by eliminating configuration drift. “Immutable” doesn’t refer to the contents of our services, of course — your Customer 360 data changes constantly with the flow of your business. But by making the underlying constructs of the software we use to store and process that data immutable, we can better manage the flow of change to our own software systems in a predictable and stable way.

Multi-Availability-Zone Design

We take advantage of multiple availability zones (AZs) in the public cloud to guarantee high availability. Compute resources (like services or data storage technologies) are deployed across (at least) three availability zones within a given region, which are close enough in physical proximity to act as a single system, but cleanly separated so that they don’t share any single points of failure, like power systems, air conditioning, network connections, etc. This pattern allows services to withstand the inevitable occasional fault (like a hardware failure, or power supply interruption) and continue to be available. We carefully monitor every service in Hyperforce to ensure high availability.

Zero Trust

“Never trust, always verify.” With Hyperforce, we’ve standardized all of our best security practices, ensuring they are automatically and consistently applied. Zero Trust architecture means that there is no implicit access to resources in the system, even from other components that are ostensibly part of the same system; rather, all request paths are explicitly authenticated and authorized, and all data is encrypted, both at rest and over the wire. On top of that, we employ the principle of least privilege to ensure operators who need access to production get that access in an elastic, just-in-time (JIT) way, with the right level of privilege, and automated removal of that access after a period of time.

Infrastructure as Code

In Hyperforce, rather than having operators directly edit configuration or run setup tasks, we manage infrastructure using explicit metadata artifacts that are kept under source control. This reduces the risk of introducing a vulnerability or bug through human error, and it guarantees that changes to our infrastructure follow the same lifecycle as any other part of our software system — validation, peer review, automated testing, staging, and gradual rollout.

Clean Slate

By default, many companies take a “lift and shift” approach to running in public cloud; they make the minimum set of changes needed to their software so that it’ll be possible to run it in public cloud infrastructure. From the beginning of the Hyperforce project, though, we took a different approach. Salesforce has been around for over two decades, and naturally during that time, we’ve accumulated some infrastructure practices that we’d be just as happy leaving behind. So Hyperforce was our chance to completely re-envision those practices in a cloud-native way, with uncompromising security and availability as the non-negotiable bedrock of our approach.

Of course, these five principles work in tandem with the mature operational practices we already use everywhere else — like ubiquitous system monitoring, active detection and response to security threats, etc — to bring Salesforce’s infrastructure to entirely new levels.

What this means for our customers

Hyperforce enhances our ability to deliver performance at B2B and B2C scale, offer built-in trust, provide local data residency, and ensure backwards compatibility.

Hyper-Scalable

On any given day, Salesforce customers deliver an average of 2.6 billion marketing messages, create 4 million leads, log 19.7 million customer service conversations, and generate more than 80 billion AI predictions. And on Black Friday 2020 alone, Commerce Cloud powered more than 10 million orders.

A shared set of foundational components and multi-tenant environments on the public cloud enable us to leverage economies of scale to drive down operational costs. Cloud elasticity means we’re able to use customer demand, like the number of leads, opportunities, or accounts, to indicate when a capacity increase or decrease is needed.

Built-in Trust

Security was baked into the Hyperforce architecture from the start through its universal authentication architecture — principles, pathways, and processes that create security by default. Every part of the Hyperforce architecture was built with security in mind, leveraging Salesforce’s world-class security team to reduce the risk of malicious attacks, and detect anomalous activity immediately.

Local Data Residency

Through Hyperforce, customers around the world can choose to store data in a particular physical region to support compliance with regulations specific to their company, industry, and local government. Building on the public cloud enables the business to be where the customer is by reducing the time to build in-region from months to weeks. And, we provide tools to allow customers to discover applicable data standards and set up and manage their Salesforce org with confidence that they are in compliance with data residency requirements. Our engineering teams prioritize a cloud-agnostic approach so that we don’t preclude the ability to stand up infrastructure with different cloud providers, so that we can always extend our geographical reach.

Future-proof

All the architectural decisions we’ve made ensure that every Salesforce app, customization and integration will continue to run seamlessly on Hyperforce. For many of our customers, insulation from underlying technology changes is one of the key benefits of using a Software as a Service provider like Salesforce. The engineering rigor on our side makes changes completely seamless to our customers.

What this means for our engineers

An exciting thing about this cloud native architecture is that most of the features and functionality that enable customer success with Hyperforce also boost developer agility. Our emphasis on building shared services means that engineering teams can focus on building the features their customers need and want rather than on maintaining infrastructure. Hyperforce unlocks innovation because it’s easier than ever for an engineer to experiment with an idea. Our architectural evolution prepares us for continued growth, scale, and a changing global landscape — it puts us in the best position to do what we do best: to bring companies and customers together.

The rest of this blog series will share more of the behind-the-cloud details about this tremendous engineering effort.

Behind the Scenes of Hyperforce: Salesforce’s Infrastructure for the Public Cloud was originally published in Salesforce Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read More

Published
Categorized as Technology