In a couple of weeks time I will be speaking with Peter Chittum at the London Salesforce Developers Group about Salesforce Evergreen. Evergreen is Salesforce’s upcoming Functions as a Service offering, and as part of my planning I began thinking about my experiences with other FaaS toolkits and what it all means. The more I thought about it the more I got to thinking – hasn’t Salesforce had a FaaS offering for years? Aren’t apex future methods actually a FaaS framework? Let’s discuss.
What are functions as a service?
We’ve all heard of the other various *aaS things offerings. SaaS now dominates the world of software products (very few products are now not SaaS) and most organisations are moving their IT to a mix of IaaS and PaaS offerings.
FaaS offerings then are an extension of the premise – first we offer you all the software as a service, then we offer you the platform to build applications as a service, then the infrastructure to run your own applications and tools and finally a stripped back way of just running a code function. No other setup, just here is my function, it takes in these parameters and does this.
The serverless paradigm
The biggest problem for a lot of the PaaS and IaaS offerings in my opinion is that a server is still involved somewhere. You still needed someone to do patches and updates and security and all the associated overhead that comes with a server.
None of these server racks for me!
Now as a confession – I’ve been almost 100% Salesforce focussed for that long, my mind boggles a little bit about setting up a server, or honestly that people still do so. I still do it occasionally but it’s very rare now. However, in previous lives as a developer it was one of the key tasks in setting up a solution. I still occasionally do work requiring a server be configured and every time it makes me miss the Salesforce platform. Salesforce is arguably the original serverless platform with none of the setup work needed. Granted this is all a lot simpler with containers and other orchestration tools now, but there is a big reason that the serverless paradigm has gained so much traction. And as a Salesforce developer you have always been a serverless developer.
The Future Method – Salesforce Functions as a Service?
Let’s now talk about whether future methods in apex are a functions as a service framework or not?
An apex future method is always defined as a static method returning void and can take in primitives or collections of primitives as parameters. An example is below:
@future
public static void updateMyAccounts(Set<Id> accountIds) {
//retrieve my accounts using the ids and process
}
When you invoke this method, Salesforce places the job on the queue to be run when resources become available. The job runs asynchronously and this allows it to both have its own execution context and a greater set of governor resources than a standard apex execution context.
So at a high-level, this seems a bit like a FaaS framework. We can define discrete functions that run in their own execution context. Check. In terms of scaling, this is not bound by resources i.e. servers but by events. For us an event is how often you call the method, up to a limit for the org. If you were using only future methods this would be a minimum of 250,000 calls in a 24 hour period which is a good volume for most Salesforce applications. Yes this means our execution scaling isn’t completely dependent only on event scaling, but they are very tightly linked.
A pure FaaS solution would have event based scaling completely with a pure pay as you go model. Salesforce doesn’t support such models and so this will always be an area where future methods cannot be a FaaS framework completely. That said however, having an effectively free tier of 250,000 methods a day, giving a total of 7.5 million executions a month is a very big chunk to work through.
Asynchronicity — A Waiting Game
The big area where future methods fall apart as a FaaS framework however is their completely asynchronous nature. Most popular FaaS frameworks have 2 models — synchronous invocation (e.g. a webservice call) or asynchronous invocation (e.g. an event through a pub/sub messaging queue like Amazon SNS). Future methods are purely asynchronous and as such don’t offer the synchronous execution nature provided by other FaaS frameworks.
Checking to see if my method has executed
In my experience they are almost always run instantly when called, however this is merely anecdotal and not a guarantee. Salesforce themselves do not provide any expectation of time until execution other than “when resources become available”. As such using future methods will only ever allow us an asynchronous invocation model.
We also have some best practice practical limitations around the future method. For example, adding more than 2000 calls to an org’s asynchronous queue will cause there to be a brief hiatus whilst methods from other orgs are processed. This includes batch, scheduled and queueable apex and so is a limit we could readily hit in a larger instance or deployment.
Adding a Synchronous Option
We could tweak this by separating out our actual code logic into a synchronous and an asynchronous option, like shown below.
public static void updateMyAccounts(Set<Id> accountIds) {
//retrieve my accounts using the ids and process
}
@future
public static void updateMyAccountsAsync(Set<Id> accountIds) {
updateMyAccounts(accountIds);
}
Here we have just created a synchronous version of our function which can be called by any apex and runs in sequence, and is delegated to by our asynchronous version. This is a useful pattern to enable us to reuse code in multiple places, but can leave us with a few problems.
Firstly, we would lose the separate execution context for the synchronous call that we get with our future method. This means that we would not have a separate independent set of governor limits with which we could run our functions.
Because of this, we also now have a decision to make and monitoring overhead to add. When should we use the synchronous vs asynchronous versions? How do we monitor appropriately the need to move from synchronous to asynchronous because of governor limit usage?
Initially this is a small hurdle but as we grow our usage is something we need to consider carefully. We are also not using only the future method framework now and instead have allowed our function to be called inline which means we have started “rolling our own” so to speak.
In Conclusion
So in conclusion, can we think of Salesforce future methods as a Functions as a Service framework in apex? The answer is kind of.
If we have discrete pieces of work which can be executed in an asynchronous fashion, then we can consider future methods as a very powerful tool for us to separate our code out into discrete functions for processing. For synchronous needs however this will not work and so we need to either do a hybrid approach as above or wait for Salesforce Evergreen to see what that offers.
We also have other tools at our disposal now such as platform events. I have discussed previously at Dreamforce how platform events can help deliver microservice based architectures on the platform, however the asynchronous pub/sub model again means it is not truly a FaaS framework.
I hope you enjoyed reading this thought exercise as much as I did writing it and thinking about the implications. I would love to know any thoughts you have, you can reach me on Twitter here