{"id":585,"date":"2022-02-22T08:10:00","date_gmt":"2022-02-22T08:10:00","guid":{"rendered":"https:\/\/fde.cat\/index.php\/2022\/02\/22\/the-unified-infrastructure-platform-behind-salesforce-hyperforce-2\/"},"modified":"2022-02-22T08:10:00","modified_gmt":"2022-02-22T08:10:00","slug":"the-unified-infrastructure-platform-behind-salesforce-hyperforce-2","status":"publish","type":"post","link":"https:\/\/fde.cat\/index.php\/2022\/02\/22\/the-unified-infrastructure-platform-behind-salesforce-hyperforce-2\/","title":{"rendered":"The Unified Infrastructure Platform Behind Salesforce Hyperforce"},"content":{"rendered":"

If you\u2019re paying attention to Salesforce technology at all, you\u2019ve no doubt heard about\u00a0Hyperforce<\/a>, our new approach to deploying Salesforce on public cloud providers. As with any big announcement, it can be a little hard to cut through the\u00a0hyper<\/em>bolic language and understand what\u2019s going on.<\/p>\n

In this blog series, we\u2019ll demystify what Hyperforce\u00a0actually\u00a0<\/em>is from a technical perspective: how it works, and why it\u2019s so revolutionary for our customers and our engineering teams.<\/p>\n

Start with\u00a0a look at Hyperforce\u2019s architecture<\/a>.<\/p>\n

Back In My Day \u2026<\/h3>\n

Salesforce has been around for over two decades. Back in 1999, when the company was founded, if you wanted to run a public internet software service (Software as a Service, or SaaS), the first thing you had to do was to get some servers and hook them up to the internet. In fact, in the very early days of Salesforce, this literally involved running ethernet cables above Marc Benioff\u2019s bedroom door.<\/p>\n

Servers like it\u2019s 1999 (because it was!)<\/em><\/p>\n

Flash forward to about 2017, and Salesforce doesn\u2019t just have a few hundred, or even a few thousand servers \u2014 we have\u00a0hundreds of thousands<\/em>\u00a0of servers, in data centers all around the world, sharded into discrete\u00a0instances<\/a>\u00a0of the product. But even at this scale, the basic premise is still the same: we procure and control the servers on which our software runs, because \u2026 well, because we\u2019ve always done it that way.<\/p>\n

Of course, around this same time, a massive wave was sweeping the industry. Instead of every company running its own infrastructure, a handful of exceptionally high-scale providers emerged who could do the same thing entirely\u00a0as a service<\/em>. And not only that, but because of their scale, they could offer much higher levels of elasticity than anyone could achieve on their own, through having large buffer pools of available capacity and automated mechanisms to provision and set up those resources.<\/p>\n

This model \u2014 infrastructure as a service, or IaaS \u2014 is so effective that it\u2019s essentially wholly supplanted the practice of running one\u2019s own infrastructure. These days, to run software on the internet is, more or less, to run it in public cloud.<\/p>\n

So what does this mean for Salesforce?<\/p>\n

In the early to mid 2010s, when we first broached this question with a few of our bigger customers, the answer was pretty clear: \u201cno way!\u201d After all, Salesforce\u2019s priority of trust (security and\u00a0availability<\/a>\u00a0in particular) was a big reason to prefer our private infrastructure over the less well-known and newer public cloud alternatives. It seemed like an IaaS vendor\u00a0certainly\u00a0<\/em>wouldn\u2019t take as good care of our customers\u2019 precious data as we would, right?<\/p>\n

The Tides Turn<\/h3>\n

Around 2017, we started to notice a change. Not only had digital transformation accelerated (for a lot of reasons), but most companies had gotten a\u00a0lot<\/em>\u00a0more comfortable with the concept of public cloud infrastructure. In fact, most of them were now using it directly, for their systems! Hosting workloads and data in public cloud was no longer scary; it was just a fact of business, and people came to realize that the big public cloud providers offered high levels of compliance, security, and quality. It no longer struck people as an undue risk.<\/p>\n

With this in mind, we started asking our customers once again: what would you think if Salesforce ran in public cloud? And this time, the answer was much different: \u201cNot only would I be OK with it, but I\u2019d actually\u00a0prefer<\/em>\u00a0you to run in public cloud, because then my Salesforce data will be colocated with all of my other data!\u201d<\/p>\n

At the same time, another trend was contributing to our investigation of public cloud. Across the world, a growing number of data residency policies were going into effect. These policies state that for a subset of companies (for example, financial institutions in Australia or Canada), their data must be stored\u00a0within the boundaries of their home country<\/em>. Following this trend to its natural conclusion, we realized that it would mean running our own independent data centers in dozens or\u00a0hundreds<\/em>\u00a0of countries, a scenario that\u2019s economically infeasible for us and for our customers.<\/p>\n

So with these questions in mind, we started afresh and asked: what would it mean for Salesforce to run in public cloud?<\/p>\n

Free-For-All, Or Unified Approach?<\/h3>\n

Salesforce has a big engineering organization. It\u2019s composed of thousands of independent teams that each look after a subset of our products.<\/p>\n

So, one approach to moving to public cloud might have been for us to double down on that team-level independence and say, \u201cOK, everybody whip out your credit cards and sign up for an AWS account to run your service!\u201d This would have been a fast way to start, and the fact that public cloud infrastructure works as a hands-off service really promotes that kind of rapid approach.<\/p>\n

As you can probably guess, however, there are a number of problems Salesforce would run into with that mindset. Our teams are all independent, but our\u00a0products<\/em>\u00a0are deeply integrated. From our customers\u2019 perspective, there\u2019s just one Salesforce, and it needs to be a unified product that they can\u00a0trust<\/strong>. It needs to run with high availability, high security, low latency, and predictable behavior. If every one of Salesforce\u2019s thousands of independent software services was running with its own setup, its own unique accounts, and its own security practices, there would be no practical way to ensure high standards. And, more importantly, we wouldn\u2019t be able to give our customers any assurances about the quality or compliance of this infrastructure. In that case, the original concerns we heard from customers about moving to public cloud would actually be true!<\/p>\n

So with Hyperforce, we took a very different approach: unified from the beginning as a singular platform, with trust as its #1 value. In practice, this means we have a single method of, for example, creating and maintaining provider accounts, spinning up new resources, accounting for costs, and delivering software securely.<\/p>\n

Lift-And-Shift, Or Shake-And-Bake?<\/h3>\n

Above, I painted the shift from first party infrastructure to public cloud infrastructure as being somewhat transparent: it\u2019s just a change in who\u2019s leasing the servers, right?<\/p>\n

Well, it turns out this couldn\u2019t be further from the truth. In particular, the architectural realities of infrastructure\u00a0as a service<\/em>\u00a0is that hardware-level reliability is not only\u00a0not guaranteed<\/em>, it\u2019s almost\u00a0anti-guaranteed<\/em>. You simply can\u2019t run millions of servers and treat each one as a \u201cpet\u201d that requires special care and feeding. Servers come and go, often without warning, and the only safe approach is to build distributed systems that expect this instability and handle it without blinking.<\/p>\n

What this means, then, is that if you\u2019ve built a system that\u2019s predicated on the hardware being reliable, you\u2019ll have a hard time moving into public cloud. And, for better or worse, that\u2019s the position that Salesforce had evolved into. As a very data-centric application, our\u00a0relational databases are paramount<\/a>, and they need to be\u00a0rock-solid systems-of-record<\/a>. Historically, we achieved that by making them big, highly customized, and optimized to the hilt. But that approach was clearly not going to fly in public cloud.<\/p>\n

Moreover, in the two decades between when Salesforce started and now, there have been a number of systemic, industry-wide evolutions in infrastructure strategy. These new principles and mental models really do provide better ways of working, but they can be hard to \u201cevolve\u201d into from older practices.<\/p>\n

As one example, the standard practice in 1999 was that if you needed to change something in your infrastructure \u2014 say, changing a configuration on a server\u2019s network interface to achieve higher throughput \u2014 you\u2019d connect to each server in your infrastructure and make that change. If you wanted to get fancy, you\u2019d use something like Puppet to automate this process and make it more repeatable and faster, but the basic approach was the same. The problem with this, of course, is that without a great deal of discipline (and monitoring), what you end up with is a lot of\u00a0drift<\/em>. 99% of the servers might have your change, but maybe a couple were in a reboot cycle when you tried to apply it, and you didn\u2019t go back to fix it.<\/p>\n

The more modern approach (which we\u2019ll go deeper on in a future post) is to say that, instead, all infrastructure is\u00a0immutable<\/strong>, and when you want to make a change, you first put up a new version (of the server, or VM, or container) and then take down the old one. In this way, you can know exactly what\u2019s happening in production, because what\u2019s happening in production is derived 100% from source controlled artifacts (such as Terraform manifests).<\/p>\n

This is just one example, of course. There are a whole host of other related principles that you can derive from the basic forces at play (unreliable hardware, elastic provisioning, API-driven interaction). Many of these were spelled out early on by the Heroku team in the\u00a012-factor app manifesto<\/a>, and many more have come to light since as the industry has evolved.<\/p>\n

So in our transition to Hyperforce, we\u2019ve also made the commitment to not just \u201clift and shift,\u201d but instead to go through a \u201cstep function\u201d in how we manage our infrastructure resources, jumping from 1999 practices to 2021 practices in one fell swoop. We\u2019ll go deeper into all of these principles in future posts, but as a brief snapshot:<\/p>\n

Infrastructure-as-code.<\/strong>\u00a0We use artifacts under source control to dictate 100% of the setup and management of infrastructure resources.3-Availability-Zone design for High Availability<\/strong>. Instead of pairs of remote sites replicating data in preparation for large catastrophes, we rely on close-but-independent trios of availability zones.Measure\u00a0service<\/em>\u00a0health, not\u00a0server<\/em>\u00a0health<\/strong>. We elevate the perspective of our monitoring, away from concrete signals of the health of individual components, and towards aggregate measures from a client perspective on whether any service is healthy.Zero Trust<\/strong>. We assume breach, and treat every service\u2019s communication with every other service as something that needs strong identity, encryption in transit, and close monitoring.<\/p>\n

These are just a few of the principles that we think about in Hyperforce. Over the course of this blog series, we\u2019ll get into much more detail about each of these, and many more.<\/p>\n

The Upside<\/h3>\n

Of course, a transition as massive as Hyperforce is never done for purely architectural principles. The fact is, running in public cloud makes deep sense for Salesforce, and even more so for our demanding customers.<\/p>\n

The most obvious benefit is\u00a0elasticity<\/strong>. If you suddenly need more resources \u2014 say, because a marketing campaign went viral \u2014 then public cloud gives you the simple ability to request more resources, and then release them as soon as you\u2019re done with them.<\/p>\n

This comes up in surprising ways. Prior to public cloud, think about the way capacity planning happened. For many businesses, there are natural peaks to activity in the world of Sales: the quarter-end, when all the salespeople are trying to meet their numbers, and all their prospects are trying to make purchasing decisions. This is a time when the activity in our services is (and has always been) heightened. But, when you run your own infrastructure, this peak is exactly what you have to plan for. And, you have to keep all of that hardware running\u00a0all of the time<\/em>\u00a0(unless you go through the effort to decommission it and return it, only to get it again next quarter, which is clearly not any more efficient). But because of the elasticity of public cloud, and the fact that these vendors serve compute resources at a scale for the whole world, our local peak cycles are easily absorbed into their existing buffer. In other words, they spread this uncertainty across their entire client base in a way that no individual tenant can (even a big one like Salesforce).<\/p>\n

Elasticity also has an important effect on\u00a0innovation<\/strong>. If you run your own data centers, and you\u2019ve got a new idea for a service, your options are limited: you can try to run it on the same servers that are already handling traffic for your existing products (risky), or you can possibly scrounge up some leftover servers that weren\u2019t being used for anything. But barring either of those, your choice is basically to go through the\u00a0procurement<\/em>\u00a0process of getting and installing new servers. And if you\u2019ve ever worked in that space, you know that it\u2019s a process measured in months (at best), certainly not hours. But conversely, when that\u2019s handled as a service, it\u2019s a question that simply ceases to be important. Got an idea for something new? Just get a few nodes and try it. Want to scale it up as a beta? Go for it, and as long as the cost of the resources is merited, you\u2019re done.<\/p>\n

(Note, this isn\u2019t to say that capacity management disappears in the world of public cloud; quite the opposite. It becomes potentially even more important, but it works in a really different way. This is something we\u2019ll cover in a future post!)<\/p>\n

As we stated above, there are a couple of very clear direct benefits for our customers. One of them is\u00a0proximity<\/strong>: if our customer is already running workloads or storing data in public cloud, and they want to combine that with Salesforce data, or use our processing capabilities like\u00a0Salesforce Functions<\/a>\u00a0to crunch that data, or bridge between all the pieces of their application network with\u00a0Mulesoft<\/a>, then it\u2019s a distinct advantage for the Salesforce side of that equation to be running in the same public cloud region, because latencies and costs are much lower.<\/p>\n

Another is\u00a0data residency policy<\/strong>, which \u2014 as I mentioned above \u2014 increasingly requires companies to store their data in a particular geographic location. Indeed, with Salesforce as a partner and intermediary to public cloud vendors, companies have even more leverage about these aspects, as was the case in our recently announced\u00a0expansion with AWS into Switzerland<\/a>. Public cloud enables new topologies of compute throughout the world that no single provider company can match.<\/p>\n

Perhaps most importantly, though, the real benefit of moving to public cloud is\u00a0focus<\/strong>. Salesforce is a CRM company; our job is to help companies connect with their customers. Did you see anything in there about being amazing at running data centers? I didn\u2019t either. We came into being at a time when running servers was synonymous with running software on the internet, but these days, it simply isn\u2019t any more. There are so many compelling reasons to move to Hyperforce, both for us and our customers. We\u2019re excited to do it in the way that only Salesforce would \u2014 with\u00a0trust<\/strong>,\u00a0availability<\/strong>\u00a0and\u00a0security<\/strong>\u00a0at the forefront from day one.<\/p>\n

Conclusion<\/h3>\n

What we\u2019ve talked about in this post is just the tip of the iceberg. There\u2019s so much happening inside of Hyperforce that we\u2019re dying to tell you about because of how it changes the game with respect to what Salesforce can build for our customers.<\/p>\n

Be sure to keep an eye on this space for future posts where we\u2019ll go deeper into the\u00a0key architectural principles that make Hyperforce behind the scenes<\/a>. We\u2019ll discuss how we organize resources in Hyperforce, what we mean by immutable infrastructure, how that 3-Availability-Zone design we mentioned above enables high availability, why the heck zero trust actually means the opposite of what it sounds like, and more. And, we\u2019ll eventually share some of the implementation details that build on this architectural foundation to actually deliver Hyperforce, like our service mesh, CI\/CD pipelines, developer experience, and service ownership.<\/p>\n

Thanks to\u00a0<\/em>Ian Varley<\/em><\/a>\u00a0for additional contributions to this post!<\/em><\/p>\n

Follow along with the full Hyperforce series:<\/strong><\/p>\n

Behind the Scenes of Hyperforce: Salesforce\u2019s Infrastructure for the Public Cloud<\/a><\/a><\/a><\/p>\n

The post The Unified Infrastructure Platform Behind Salesforce Hyperforce<\/a> appeared first on salesforce-engineering.go-vip.net<\/a>.<\/p>\n

Read More<\/a><\/p>","protected":false},"excerpt":{"rendered":"

If you\u2019re paying attention to Salesforce technology at all, you\u2019ve no doubt heard about\u00a0Hyperforce, our new approach to deploying Salesforce on public cloud providers. As with any big announcement, it can be a little hard to cut through the\u00a0hyperbolic language and understand what\u2019s going on. In this blog series, we\u2019ll demystify what Hyperforce\u00a0actually\u00a0is from a… Continue reading The Unified Infrastructure Platform Behind Salesforce Hyperforce<\/span><\/a><\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","footnotes":""},"categories":[7],"tags":[],"class_list":["post-585","post","type-post","status-publish","format-standard","hentry","category-technology","entry"],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":870,"url":"https:\/\/fde.cat\/index.php\/2024\/05\/23\/hyperforce-behind-the-scenes-ushering-in-a-new-age-of-ai-driven-cloud-scalability\/","url_meta":{"origin":585,"position":0},"title":"Hyperforce Behind the Scenes: Ushering in a New Age of AI-Driven Cloud Scalability","date":"May 23, 2024","format":false,"excerpt":"In our latest edition of our \u201cEngineering Energizers\u201d Q&A series, we meet Paul Constantinides, Executive Vice President of Engineering. With an extensive history in the technology industry, and a 20-year career at Salesforce, Paul leads the Hyperforce Platform Services team and is responsible for developing Hyperforce, Salesforce\u2019s public cloud-native architecture\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":538,"url":"https:\/\/fde.cat\/index.php\/2022\/02\/01\/behind-the-scenes-of-hyperforce-salesforces-infrastructure-for-the-public-cloud\/","url_meta":{"origin":585,"position":1},"title":"Behind the Scenes of Hyperforce: Salesforce\u2019s Infrastructure for the Public Cloud","date":"February 1, 2022","format":false,"excerpt":"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\u200a\u2014\u200anot just the software, but the\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":679,"url":"https:\/\/fde.cat\/index.php\/2023\/02\/14\/3-ways-salesforce-boosts-developer-productivity-on-hyperforce\/","url_meta":{"origin":585,"position":2},"title":"3 Ways Salesforce Boosts Developer Productivity on Hyperforce","date":"February 14, 2023","format":false,"excerpt":"In 2018, Salesforce began development of Hyperforce \u2014 a next-gen infrastructure platform that leverages public cloud to securely and swiftly deliver Salesforce software to customers worldwide. The platform development\u2019s team priorities were focused: build Hyperforce, get it sentient, and provide cloud-native tools that drive internal product developers\u2019 innovations, empowering them\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":544,"url":"https:\/\/fde.cat\/index.php\/2022\/02\/22\/the-unified-infrastructure-platform-behind-salesforce-hyperforce\/","url_meta":{"origin":585,"position":3},"title":"The Unified Infrastructure Platform Behind Salesforce Hyperforce","date":"February 22, 2022","format":false,"excerpt":"If you\u2019re paying attention to Salesforce technology at all, you\u2019ve no doubt heard about Hyperforce, our new approach to deploying Salesforce on public cloud providers. As with any big announcement, it can be a little hard to cut through the hyperbolic language and understand what\u2019s going\u00a0on. In this blog series,\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":625,"url":"https:\/\/fde.cat\/index.php\/2022\/08\/30\/hyperpacks-using-buildpacks-to-build-hyperforce\/","url_meta":{"origin":585,"position":4},"title":"Hyperpacks: Using Buildpacks to Build Hyperforce","date":"August 30, 2022","format":false,"excerpt":"At Salesforce we regularly use our products and services to scale our own business. One example is Buildpacks, which we created nearly a decade ago and is now a part of Hyperforce. Hyperpacks are an innovative new way of using Cloud Native Buildpacks (CNB) to manage our public cloud infrastructure.\u00a0\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":688,"url":"https:\/\/fde.cat\/index.php\/2023\/03\/07\/automated-environment-build-salesforces-secret-sauce-for-rapid-cloud-expansion\/","url_meta":{"origin":585,"position":5},"title":"Automated Environment Build: Salesforce\u2019s Secret Sauce for Rapid Cloud Expansion","date":"March 7, 2023","format":false,"excerpt":"Around the world, companies must satisfy global compliance regulations or face pricey fines, where failure to comply results in 2.71 higher costs than the cost to comply. For example, Fortune 500 companies are projected to lose $8 billion per year as a result of GDPR non-compliance. In response, Salesforce created\u2026","rel":"","context":"In "Technology"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/posts\/585","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/comments?post=585"}],"version-history":[{"count":0,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/posts\/585\/revisions"}],"wp:attachment":[{"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/media?parent=585"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/categories?post=585"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/fde.cat\/index.php\/wp-json\/wp\/v2\/tags?post=585"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}