How gRPC is enabling Salesforce’s unified interoperability strategy
Challenge
The leader in customer relationship management software, Salesforce supports more than 150,000 organizations with its customer success platform and other products. Behind the scenes, “the big thing we’re trying to establish is a unified interoperability strategy across the company,” says Ryan Michela, Principal Engineer, Service Mesh Team. “One of the pain points we’ve had with JSON-based integrations in the past is it that they require a lot of negotiation on each side and can be brittle to backwards incompatible changes.
Solution
Deciding between gRPC and REST-type services, the team went with gRPC in 2016 because “through protocol buffers, it has a backwards compatibility built in from the beginning and establishes a very strong contract between components,” says Michela. “We really liked gRPC for the contract-driven development practices and some of the other technical features that it offers over basic HTTP and JSON.”
Impact
Service mesh and gRPC “have been fantastic for distributing service contracts so that teams can have a very well-understood, well-defined interface between each other over the network, whereas JSON and REST tend to be more fluid and leave a lot more open to interpretation,” says Michela. Plus, as a binary protocol over HTTP2, gRPC has an advantage over REST, a text protocol over HTTP1. For Salesforce, says Michela, “HTTP2 has given us more flexibility in designing streaming services and push notification-type services where we wouldn’t be able to do that as easily with HTTP1.” Though the impact is hard to quantify, Michela believes that developer velocity has been improved as teams have evolved their services with maintaining backwards compatibility.
Projects used
By the numbers
Gained flexibility in designing streaming services and push notification-type services
Developer velocity improved
Dramatic changes made with just a handful of people on the team
The leader in customer relationship management software, Salesforce supports more than 150,000 organizations with its customer success platform and other products.
On the technology side, “the big thing we’re trying to establish is a unified interoperability strategy across the company,” says Ryan Michela, Principal Engineer, Service Mesh Team. “One of the pain points we’ve had with JSON-based integrations in the past is it that they require a lot of negotiation on each side and can be brittle to backwards-incompatible changes.”
The company began looking at gRPC in 2016. Comparing it with REST-type services, the teams saw a big benefit in how “gRPC has a backwards compatibility built in from the beginning through its protocol buffers and establishes a very strong contract between components,” says Michela. “We really liked gRPC for the contract-driven development practices and some of the other technical features that it offers over basic HTTP and JSON.”
Another factor was the fact that gRPC is a polyglot framework. “We’ve acquired companies, so we don’t have the luxury of a codebase written in a single programming language,” says Michela. “So gRPC helps us by being available for all the languages we use.”
After doing some basic experimentation with the technology, a group of representatives from many of the different companies and major product lines at Salesforce came to a consensus that gRPC was the way to go. “Once we had a feel for how it works, we concluded that gRPC met our technical requirements,” says Michela. “It just had a particular balance of strengths and weaknesses that aligned well with what we’re trying to accomplish. I like gRPC because it’s self-contained, it’s got good support, and Google’s banged on it really hard and made it a very solid technology.”
Google’s commitment to gRPC as part of its public cloud strategy was also an important factor. “Having that really strong support from the community and particularly from a corporate supporter was important,” he adds.
Salesforce engineers had to do very little to make gRPC work within the organization. “One of our goals has been as we move towards cloud native to be as vanilla with our open source technologies as possible,” says Michela, “so rather than trying to take an open source project and fork it and adapt it to our needs, we made an effort to adapt our needs to the common way of doing things.”
“In a sense, gRPC just works. It solves a very specific problem, it solves it well, and it solves it without fuss. We knew we made the right choice because we didn’t have to fight with it.”
— RYAN MICHELA, PRINCIPAL ENGINEER, SERVICE MESH TEAM AT SALESFORCE
The only customization was building a small layer on top of gRPC to make it easy to use in some of Salesforce’s other code frameworks and “lock down some of the configuration options,” says Michela. “Out of the box, it has a great deal of configuration options, most of which our application developers don’t need to be fiddling with.”
To simplify gRPC code generation, Michela maintains the Salesforce gRPC contrib library, which includes some protocol-buffer code generation based in Java, and the Reactive gRPC library, a set of stubs for bridging the gRPC protocol with Rx, Java, and Spring Reactor libraries.
Salesforce has been using gRPC and service mesh for about two and a half years, growing to multiple things in production. “There have been some growing pains around internal testability and rapid development, but gRPC has generally been very, very good to us,” says Michela. “It has been fantastic for distributing service contracts so that teams can have a very well-understood, well-defined interface between each other over the network, whereas JSON and REST tend to be more fluid and leave a lot more open to interpretation. So having that strongly-typed interoperability layer over the wire between teams has been very helpful.”
“We’re doing the whole CNCF platform. We’ve got a Kubernetes-based stack, and we’re working on getting Istio up and running with Envoy and gRPC, bringing all of those different pieces together.”
— RYAN MICHELA, PRINCIPAL ENGINEER, SERVICE MESH TEAM AT SALESFORCE
Plus, as a binary protocol over HTTP2, gRPC has an advantage over REST, a text protocol over HTTP1. For Salesforce, says Michela, “HTTP2 has given us more flexibility in designing streaming services and push notification-type services where we wouldn’t be able to do that as easily with HTTP1.”
Though the impact is hard to quantify, Michela believes that developer velocity has been improved as teams have evolved their services with maintaining backwards compatibility. “In a sense, gRPC just works,” he says. “It solves a very specific problem, it solves it well, and it solves it without fuss. We knew we made the right choice because we didn’t have to fight with it.”
With gRPC in place, Salesforce is well-equipped to keep building its cloud native platform. “We’re doing the whole CNCF platform,” says Michela. “We’ve got a Kubernetes-based stack, and we’re working on getting Istio up and running with Envoy and gRPC, bringing all of those different pieces together.”
The technology has proven to be a great enabler. “We’re just a handful of people,” says Michela. “What says a lot about the power of open source and the CNCF technologies we’re working with is that we’re able to accomplish a dramatic amount of change within our company without having to reinvent the wheel.”