Salesforce Functions: New ‘Heroku-like’ Technology for Salesforce Developers

Share this article...

Earlier in the year, I attended the London Developer Trailblazer Community group event with Wade Wegner. Wade is a senior product manager at Salesforce and has done lots of exciting work in the past with the latest and greatest Salesforce technologies, including SFDX.

This event was ‘fireside’ style, held at the Salesforce Tower in London, in which the attendees asked many questions about all things related to Salesforce. The questions focused on a very exciting new technology that promises to appeal to many developers: Salesforce Functions (previously called Evergreen).

“Conga”

Overview of Salesforce Functions

Given below is a high-level summary of some of the main items discussed in the meeting. Please refer to the forward-looking statement (also known as ‘safe harbor’) from Salesforce, here, before making any purchasing decisions.

  1. Salesforce Functions will offer many of the same features offered by Heroku; such as the concept of buildpacks, add-ons, private and public spaces, etc.
  2. A key differentiator of leveraging Salesforce Functions instead of Heroku is that you will be able to apply the concept of containerisation more natively to the Salesforce platform.
  3. Salesforce Functions pricing is yet to be determined and will be in the developer preview mode soon. The best person to speak to about this is your Account Executive. It is not clear yet whether Salesforce Functions will follow the Heroku cost model of ‘pay for what you use’, or if it will have a fixed price.
  4. Salesforce Functions will be built on open standards.
  5. The underlying infrastructure of Salesforce Functions is Amazon Web Services.
  6. Salesforce is not looking to phase out Apex  –  it is still a hugely important language. On the contrary, discussions are being held at Salesforce to make Apex a language that can be run off the platform. Nonetheless, there is a sense that JavaScript will continue to grow in importance amongst developers within the Salesforce ecosystem.
  7. Discussions are on in Salesforce to ‘sunset’ the developer console tool and workbench  –  there are plans to provide compelling alternatives (besides those already being offered in VSC and other plugins like Illuminated Cloud).
  8. During TrailheaDX Salesforce highlighted a new Salesforce tool called Code Builder. Currently in pilot, Salesforce intends to build this feature up, to offer a single ‘go to’ place to do all of your Salesforce development. A deeper demo on this feature can be found here.
  9. Another new tool, Runtime Engines is also in the development stage, designed to complement Salesforce packages. These environments are similar to scratch orgs but are clones of specified sandboxes. This should make it easier for customers to transition to a packaging development model, due to awareness that use of SFDX in complex situations can make things messy as a result of many different dependencies.
  10. Async cloning will create a new way to provide sandboxes as quickly as possible is in the development stage.
  11. There are plans to provide encryption at REST as a standard. At the moment, one has to pay for this feature as a Salesforce Shield add-on. The downside of encrypting at REST (having to use SOSL instead of SOQL in some use cases) is being ironed out.

Future Vision for Developing on the Salesforce Platform

The session was super-helpful  and  being able to speak freely and candidly to senior Salesforce product managers and developers matters a lot. There are so many cool features and ideas that are being developed and experimented with within Salesforce.

The main theme is enabling developers to develop and deploy code easily, smoothly, and quickly as possible.

Salesforce Functions is a very interesting approach from Salesforce. The two key points of preserving context and security, two big things that are much harder to maintain when you move off the platform, are massive wins that should further enhance developer productivity.

From a strategic perspective, it feels that Salesforce has made a smart move as it will surely appeal to developers that come from a non-Salesforce background. Historically, it felt that the focus had been on Salesforce specific technologies, but now, with LWC, VSC extensions and Salesforce Functions, there is a real push from Salesforce to lower the entry barrier for predominantly non-Salesforce developers.

“developers are the new drivers, they just don’t know it yet”

– Bob Martin, author of Clean Code

Recently, I’ve been listening to Bob Martin a lot (the author of a very popular book : Clean Code) and in one of his seminars he says “developers are the new drivers, they just don’t know it yet” (or something to that effect). The point is that whereas in the ‘old world’, Sales and Marketing made most of the decisions, in the ‘new world’ the engineering department is dominant. Salesforce is aware of this and knows that by betting big on providing new features that appeal to any developer, the natural outcome is that Salesforce as a service, platform, infrastructure and now as a function, will grow in popularity.

If you are new to Salesforce and are curious to find out more, one of the best resources will be to check out the events at Trailblazer Community Groups. Listening to videos from the Salesforce YouTube channels or reading Trailhead modules is fantastic but there’s nothing quite like being there in person.

If you’re interested to find out more about Salesforce Functions, check out the TDX20 Salesforce Functions trail by Peter Chittum on Trailhead.

Leave a Reply