In this episode, we sit down and talk with Tyson Read, the Director of Product Management at Salesforce, about Event Relays, and specifically, how they can help your integration between Salesforce and Amazon. 

Tyson previously worked as a conservation biologist and in biomechanics until he transitioned into computers and coding. Tyson’s first project with Salesforce was building a mobile app with a mobile SDK to help biologists go out into the field and record different kinds of observations.

In his current role at Salesforce, Tyson works on different eventing technologies using platform events and change data capture, working on the runtime for those products and figuring out how to use events, not only to empower customers but also to actually build Salesforce products.

Show Highlights:

• Learning Python as his first language
• His introduction to Salesforce
• Different products using events right now
• Salesforce’s current partnership with Amazon in terms of eventing
• Using the AWS EventBridge for directing events to your services
• The working parts of an Event Relay
• Grouping function for channels and authentication
• How Event Relays are integrated into a flow
• Possible use cases

Links:

Connect with Tyson Read on these platforms:

• Tyson on Twitter – https://twitter.com/tysonreads 
• Tyson on LinkedIn: https://www.linkedin.com/in/tysonread/

Episode Transcript

Tyson Read:
Well actually that project and some of the other stuff that I worked on in grad school was what got me thinking about computing and code in general.

Josh BIrk:
That is Tyson Reed, a director of product management here at Salesforce. I’m Josh Birk, your host for the Salesforce Developer Podcast. And here on the podcast, you’ll hear stories and insights from developers, for developers. Today we sit down and talk with Tyson about event relays and how they can help your integration between Salesforce and Amazon. But first we go back to right after that quote, actually, to talk more about Tyson’s and scientific pursuits.

Tyson Read:
I’d done work as a conservation biologist and had done work in biomechanics before, but that was the real impetus to start getting a little bit more comfortable with Python. That said, I’m still terrible at it. I’m no good at any of this. But it at least cracked the seal and got me to start thinking about, how do you actually use computers and code to actually make stuff happen?

Josh BIrk:
Gotcha. And Python was your first language?

Tyson Read:
Yeah, yeah. Python was the language I inherited from my collaborator on that paper, who came up with all of the kinematic scripts that would take camera footage of a humming bird flying around and then reconstruct that from different angles to create a 3D representation of, how is this bird moving? How are they moving their wings? What are they doing? What’s the physics that’s happening? Then we’d use that to infer all of these conclusions.

Josh BIrk:
That is so cool. That is so cool. Okay, so Python. But then how did you get introduced to Salesforce?

Tyson Read:
Yeah. So for that story, I had come back from grad school. I was working as a conservation biologist and had a job where I was doing a lot of surveys for endangered species, where we’d need to go out and identify where all of these protected species are and figure out what needed to be done to minimize impacts to them, so if there was a construction project or some sort of maintenance going on nearby, what we needed to do to make sure that everything was okay. And we would do like thousands of these. I personally wasn’t doing thousands, but with my colleagues and a lot of contractors that we’d hire, there was just a ton of these going on every year.

Tyson Read:
And being fresh out of grad school, I found myself thinking about how we’re collecting a ton of data here that is super helpful, one, not only for informing what we did as a company, but, two, just for genuine scientific value. And the thing that was interesting in that data set was that a lot of the times you have observations that say, “Hey, I saw such and such species in this location,” but you don’t have what we call negative survey findings very often. And that was kind of the cool thing, is that we had all of these surveys where people would go out and they wouldn’t find anything, and we could log that and say, “Hey, somebody made an effort. This is how much effort they put in.” And it’s really helpful for reconstructing where all of these species might be. So I was thinking about that, and then thinking about all of this work we were doing, and all of it was managed in Excel and Microsoft Word and-

Josh BIrk:
Oh gosh.

Tyson Read:
Sometimes the results would just be a text or a voicemail that somebody would leave, be like, “Yeah, I went there. Didn’t see anything. Bye.”

Josh BIrk:
Oh wow.

Tyson Read:
Yeah. So I found myself thinking, “Geez, I really wish that we had this in an actual database that we could analyze and work with in the future.” So what we did is… I started thinking about, “How can I build a mobile app to streamline this data collection and have a database behind it to actually start analyzing it?” And that was actually how I started working with Salesforce. My first project was building a mobile app with a mobile SDK to help biologists go out into the field and record these kinds of observations.

Josh BIrk:
How did you first… Because I mean, I’ve almost done workshops with that exact scenario, trying to tell people, “This is part of the power of our platform,” kind of thing. But when did you first hear about Salesforce? Because it’s usually people who get into the CRM and business world that poke that bubble first and then start writing their applications.

Tyson Read:
Yeah. So it wasn’t something that I was really seeking out. I was looking pretty broadly to try and figure out what were different platforms that we could use. Initially some of the proposals that I looked for were all custom code. And this was the very beginning of working on any of this kind of stuff for me, so I had a suspicion that all custom was probably not the way to go. But ultimately what ended up making the difference is I got put in touch through some of the folks at our IT department with like, “Hey, here’s some people that we’re considering working with, and maybe you should kick the tires with, this whole Salesforce thing.” That’s how it got started.

Josh BIrk:
Gotcha. Very, very cool. And then how would you describe your current role at Salesforce?

Tyson Read:
Yeah, so now I’m a product manager at Salesforce, and I work on our different eventing technologies, so things like platform events and change data capture. I work on the runtime for those products. And I also work on a lot of different cross-cloud initiatives, where we’re trying to figure out, how do we use events not only to empower our customers but also to actually build Salesforce products?

Josh BIrk:
Interesting. What’s a couple of products I might not think of that are using events right now?

Tyson Read:
Yeah. So couple different ones. So a classic one that is a little bit more obvious is real time event monitoring. That is events underneath the hood. Some other ones would be related to Einstein predictions. We use events as a way to capture all of these different data changes and then feed them into data lakes where we can then come up with predictions about, hey, what needs to happen next? That’s a big one. We also will power notifications that are coming out of errors from Flow, so you can receive notifications via an event.

Tyson Read:
One that was a great story was work that we did with Vaccine Cloud. So kind of the initial rollout for Vaccine Cloud, the team was thinking about, “Hey, how do we come up with Salesforce communities that can be that kind of onboarding experience? And how do we make sure that those communities can really scale when they’re getting hit with thousands and thousands of requests coming in every minute?” If you’re standing up a community that’s supposed to serve an entire state or country, it needs to be able to deal with a lot of really high-scale, spiky traffic. And one of the things that we did under the hood to help enable that team was to come up with a way where, instead of each signup to get a vaccine translating into an immediate database query, what we did is we had it publish an event instead, and then we were able to batch process those events, so we could really kind of smooth out what that demand was and be mindful of, how many connections are we maintaining to the Salesforce database at a time?

Josh BIrk:
Gotcha. Nice, nice. So we’re going to talk a little bit about event relays and integrations with Amazon. What kind of use cases are pushing us to… Well, I guess let’s set the table for everybody. What’s our current relationship with Amazon? What kind of things are we working on with them?

Tyson Read:
Yeah, so we have a lot going on with Amazon these days. We’ve expanded the partnership that we already had with them. We announced that back at the last Trailhead DX. And when we announced this new expanded strategic partnership with Amazon, part of this is working with different clouds, like Sales Cloud and Service Cloud and Health Cloud, and part of it is going on at the platform and figuring out, how do we just make it fundamentally easier to build experiences between Salesforce and AWS? How do we make this feel a lot more cohesive for folks?

Josh BIrk:
Gotcha. And narrowing down on that, prior to what we’re going to talk to now, what are some tricks that developers were doing to try to integrate with Amazon?

Tyson Read:
Yeah. So one gambit [crosstalk 00:08:41] would have to employ. And right now, some of the things that we have in the hopper include work around data virtualization, so you can see that data in AWS without having to actually copy it. That pilot’s actually kicking off right now, where we have a pilot related to Salesforce Connect and virtualizing DynamoDB. That’s awesome.

Tyson Read:
And then in terms of eventing, the work that we’re doing there is trying to replace some of these complicated integrations that folks have had to build in the past. I want to say that this is all tried and true stuff. Folks have been building integrations against the streaming API. They’ve been using middleware tools for a long time. And it all like works tremendously at scale, but it’s also work that you have to do to get set up, and we’re really mindful about trying to lower that barrier and just make it easier for people to onboard quickly.

Josh BIrk:
Right, because we’re not talking about just simply an HTTP call here and there. These are people who are really trying to prop up their own pub/sub type model, right?

Tyson Read:
That’s exactly right. And some of the stuff that we see people struggle with sometimes is things like you’re subscribing to events coming from Salesforce, and that means you have to come up with ways to manage retries. If your service goes down, you have to have logic in there so when it comes back up it remembers where it left off and can pick back up in the stream. That’s not always the easiest thing for folks to put together.

Josh BIrk:
Right.Plus all the user interface around it, et cetera, et cetera. I assume it’s a lot of administration as well.

Tyson Read:
Yep. Yeah. And the other thing too is that after you’ve gotten your integration up and running, whether it’s one that you custom built or whether you used middleware to do it, you still have to monitor that and keep an eye on it and make sure that everything’s working. So we’re really trying to minimize that barrier for everybody.

Josh BIrk:
Right. So let’s talk a little bit about what people would be talking to over on the Amazon side. So for the unfamiliar, what’s a Lambda service, and what are some things that it’s particularly good for?

Tyson Read:
Yeah. Lambda course is great for having your serverless compute. You can spin up and run the calculations that you need. But the thing that we’re really focused on connecting to right now is AWS EventBridge. And if you’re not familiar with it, that’s a great ingestion tool for events in Amazon, and what it does is it allows you to then direct those events to whatever service you want, including a Lambda.

Josh BIrk:
Gotcha. So when you say whatever service you want, like services within Amazon, other places? What kind of options are there?

Tyson Read:
Yeah, that’s a great question. So I can’t remember the exact number of how many services within Amazon, but they’ve got well over a dozen with very easy rules that you can direct immediately from EventBridge, and a bunch more that you can also get your events to by using a Lambda as well. And then you can also use this feature in EventBridge called API destinations that allows you to send events either back to Salesforce or to any other HTTP endpoint that you want to configure it for.

Josh BIrk:
Got it. And so that takes us to one half of putting in a… I don’t want to say proper pub/sub, because as you said, people out there have really good implementations. A first-party pub/sub, so to speak. So that’s sending back to Salesforce. Now describe an event relay to me and tell me how that works.

Tyson Read:
Yeah. So event relays is really all about, how do we get events from Salesforce to Amazon in a way that’s really streamlined and make it an experience where it’s something you can just configure? You’re not having to build a CometD client. You’re not having to get that middleware. You’re making a couple API calls, and then you’ve got this relay service that can send your events, manage your subscription, and take that burden off your hands for you.

Josh BIrk:
So what’s all the working parts of an event relay? The event relay is not the message itself. It is the mechanism to send the messages out.

Tyson Read:
That’s exactly right, yeah. So it’s a new service that we’re launching, and the idea is that, in the process of setting up an event relay, we use a couple different pieces. The first is a named credential. So we use named credentials, so you can reuse those no matter what AWS service you’re trying to connect to. We can keep track of that for you. And then we also attach that relay itself to your event channels. So folks might not be familiar with event channels. They allow you to group events into a channel. So say you’ve got change events on three different objects that you want to listen to, and you want to group all of those into one channel to make it easier for your subscribers. You can use the channel to do that. You can add enrichment rules to that channel. Pretty soon you’ll be able to add filtering to it as well. And now you can also add this relay that then sends that channel to AWS.

Josh BIrk:
Got it. Is the functionality of a channel… Is it simply filtering, or does it allow me to also like, “Tell me if this channel got updated, but I don’t care if the other channel did”? Can you listen to just a channel?

Tyson Read:
Exactly. So you can listen to just a channel. So the subscriber can choose whatever events they want to listen to or whatever channels they want to listen to, so it’s kind of like a grouping function that allows us to add more stuff onto it.

Josh BIrk:
Got it, got it. So authentication is through named credentials. Is there any other options for authentication, or is that just the way to go?

Tyson Read:
That’s the way to go for now. We’re definitely going to be thinking about other routes and if there’s other things that customers are interested in, but we wanted to it to make it a consistent experience for authenticating into all of these different AWS services.

Josh BIrk:
Got it, got it. So let’s talk tooling on our side. How does this look like when I want to integrate it into a flow?

Tyson Read:
So that, I think, is the thing that’s really exciting to me, is because it really decouples the work that needs to happen in Salesforce and AWS, because if you are an admin or a developer that’s sitting in Salesforce, you can build flows that write Apex that are responding to events. And those events might be coming for Amazon. They might not be right. It’s how you set it up. And it means that you’d have a flow publish an event, that event could then be relayed to AWS, it could trigger whatever service you want in AWS, and then you could publish another event back to Salesforce that could then kick off another flow or another set of Apex.

Josh BIrk:
Got it. So if a developer can handle the Apex parts, then an administrator can pretty much set up the integration with no-code tools or low-code tools.

Tyson Read:
Yeah. So right now what we’re kicking off with is low-code. The relays that themselves are going to be configurable through Salesforce APIs. And then what we’re planning on building next is a declarative experience, so there will be a no-code experience for setting up this relay to AWS.

Josh BIrk:
Oh, wow. And what about for Apex developers? How do they talk to it?

Tyson Read:
Yeah. So for them, they’re going to be interacting with the events just like they always have. The relay itself doesn’t really change how somebody is going to build with events on platform. It just makes it easy to get those events into AWS.

Josh BIrk:
Got it. So they’re just talking simply to platform events. They’re not talking to the event relay itself.

Tyson Read:
Exactly. Yeah.

Josh BIrk:
Okay. Okay. And so I guess that actually kind of answers my next question. There really isn’t anything new Apex developers need to know before working with this.

Tyson Read:
No, no. And the cool thing is that you can set this up different ways, but one way to do it could be defining a platform event that’s going to be published whenever one of your services in EventBridge is publishing that to Salesforce, and so you can then really start building whatever you need against it, and you don’t have to worry so much about what’s going on on the Amazon side.

Josh BIrk:
Gotcha, gotcha. Do you have… I’m always trying to hedge around whether or not we can say customer names or not, et cetera, et cetera. Do you have a favorite use case that’s come out of this?

Tyson Read:
It’s still a little bit early. I mean, we’re really just starting to kick off the pilot for all of this. So part of my thing is like, “Hey, let’s check in in a couple months, and I’ll have some more exciting stuff for you.” But so far a lot of the conversations I’ve had with customers have been really energizing, I think, where folks just look at it and they just start talking about the architectural implications for them and the… I hear a lot of stories about how it’s not so much like specific use cases around how X or Y event is really going to help them. It’s more, “Oh my goodness, this is going to save me so much time on connecting these systems.”

Josh BIrk:
Nice. Do you have people that you know are going to be looking forward to retiring a lot of code?

Tyson Read:
I think so. And I think that the ones that so far we’ve had really good conversations for are people that are still really in the early stages of building all of this. They know that they need to build an integration with AWS, and now we can show up and say, “Hey, it might make sense. There’s still going to be use cases where owning your own integration is going to be the way to go. But this is one where you might not have to.”

Josh BIrk:
Right. I mean, it almost seems like cheating. You’re just sort of skipping to the end.

Tyson Read:
Yeah, yeah. And the message that I usually have for customers is, “Hey, if you already have an integration that’s up and running and you’re happy with it, that’s great. It’s working. That’s good.” If you’ve got a new project that’s in the works, that’s a good opportunity to think about, “Hey, how can you leverage some of this?”

Josh BIrk:
Yeah. I mean, I don’t know how many times I’ve said to an audience, “You don’t have to throw out all your Visualforce just yet.” If it works, it works. There’s no need to restart all over again.

Josh BIrk:
So you mentioned the pilot. We’re in the future, and it’s mid February-ish. What’s the pilot looking like for you right now?

Tyson Read:
In terms of how it works, how we get people onboard?

Josh BIrk:
Yeah. Is it going to be a developer beta? Do people have to sign up through their AE? What’s the status of the pilot going to look like in late February?

Tyson Read:
Got it. So what we’re going to be doing is kicking things off with a pilot. Yeah, we’re shooting for February to get that all started. And the process for getting involved is going to be reaching out to your AE, and then they’ll sign you up for that pilot, and then we’ll get everybody onboarded. So what we’re looking for right now is who those initial customers are that see some value in this, that want to kick the tires, that are maybe already familiar with eventing and pub/sub and want to figure out how they can put this to work. And we’re also really… I know that a lot customers can be wary of signing up for pilots, just because there’s a lot that’s… They got a lot going on, and it’s not always easy to commit resources to building against a pilot. That’s totally fair.

Josh BIrk:
Right, and you don’t know if we’re going to change everything because of findings in the pilot, et cetera, et cetera.

Tyson Read:
Absolutely. I can tell you that this is one where we’re very committed to get all of this out the door. We see this as being a really important piece for how we really bring these two platforms together, so it’s one that we’re definitely committed to getting right and is a super high priority for us.

Josh BIrk:
I mean, is there anything on the roadmap you want to give a shout out to, or do you just want to get on the road? Is it too early to even talk about roadmap stuff?

Tyson Read:
Oh, for what’s next for the relays?

Josh BIrk:
Yeah.

Tyson Read:
Yeah, I think… So roadmap stuff, we’re definitely really focused on just, how quickly can we get the service GA-ed? We know that it’s going to make a huge difference for customers and really going to make their lives easier. That’s the first immediate goal that we got to do. And then after GA, some of the stuff that I’m really passionate about is figuring out, how do we make this experience less of a low-code one and more of a no-code one? How do we make it so somebody can just go into set up, click a couple buttons, and make a process that used to take maybe a week or more in building a custom integration and make it take five minutes, 10 minutes? How do we really accelerate that?

Josh BIrk:
Nice, nice. So we talked hummingbirds, but I also wanted to poke you a little bit about the other thing that you wrote about, and it’s tied into all of this. But the title of your other paper was… Or the other… I think it might have been a blog article. But anyway, The New Salesforce Event Bus. So I’m going to admit, I’ve been guilty of literally putting a bus on a slide and referring to that as our event bus, as this big, amorphous thing in the sky that just does all this kind of stuff. But why do we need a new event bus, and what did we update with that?

Tyson Read:
Yeah, yeah. It’s a good question. So we’ve had an event bus in Salesforce for… Gosh, I think since 2015, 2014? [crosstalk 00:22:34].

Josh BIrk:
Sounds about right, yeah, yeah.

Tyson Read:
So yeah, it’s been around for a long time, and it’s gone through a lot of architectural changes over the years. And the most recent one that you’re mentioning here is that we actually built an entirely new runtime for the event bus

Josh BIrk:
Oh. Wow.

Tyson Read:
Yeah. So that’s been one of the other projects that I’ve been working on for the last couple years. And what that’s entailed has been that, for the last several years, since it was created, the runtime for the Salesforce event bus lived in our core app servers, so it’s the same core monolith that powers Sales Cloud, Service Cloud, and so much else of the platform. And we’d see just how much growth would be happening in eventing, and how often we needed to turn to it to build cross-cloud products. And that started us on a journey about thinking about, “How do we really unlock this technology and make it scale even better than it already does?” So what we did is we’ve been building this brand new, off-core runtime that is entirely its own service. And we’ve been in the process of getting that built and rolling it out. It’s been phenomenal.

Josh BIrk:
Because as you were describing earlier, eventing is occasionally kind of a dial tone, but then you can also just have these big rushes of traffic, right? You don’t necessarily want that parked right up against your other databases.

Tyson Read:
Yeah, exactly right. So we’ll see billions of events being published, and we need to make sure that we can handle that and that it’s not affecting all of the other services. So that was a big reason for why we wanted to build out an independent runtime. So, say, if we’re seeing a ton of traffic that’s coming from Marketing Cloud, we can horizontally scale and deal with that, and it’s not affecting, say, other clouds that would otherwise be relying on the same servers.

Josh BIrk:
That’s our show. Now, I did ask after Tyson’s favorite non-technical hobby. And you know what? It’s actually not Raptor banding. I know. I am as surprised as you are.

Tyson Read:
It’s been a while since I’ve done that.

Josh BIrk:
Really?

Tyson Read:
Yeah, yeah. That used to keep me pretty busy. I was a part of the Golden Gate Raptor Observatory for a couple years, which… For all the people in the San Francisco Bay Area, go check it out. It’s a great, great group of folks to work with.

Josh BIrk:
Nice. So what’s your current favorite non-technical hobby?

Tyson Read:
Gosh, I’d say lately it’s been a lot of woodworking. That’s been keeping me busy. Woodworking and wine making, actually.

Josh BIrk:
Oh really?

Tyson Read:
Yeah. Just bottled a Tempranillo a couple weeks ago.

Josh BIrk:
How much gear does wine making take?

Tyson Read:
Not that much, actually. I’m also saying that coming from the baseline of… I’m a homebrewer as well, and beer involves a lot more equipment than wine.

Josh BIrk:
That was my curiosity, because I know people have dedicated portions of their kitchen just so that their beer making talents can be not in a closet somewhere. Okay, so wine is less than beer, but you probably have to bottle it for longer, right?

Tyson Read:
Yeah. [crosstalk 00:25:55] takes a little bit longer.

Josh BIrk:
I want to thank Tyson for the great conversation and information. And as always, I want to thank you for listening. Now, if you want to learn more about this show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes, and have links to your favorite podcast services. Thanks again, everybody, and I’ll talk to you next week.