How to know when gRPC is not the right choice

Recently, I was working on an article that started out with the title "5 ways enterprise architects are using gRPC in the real world." When I write this type of piece, my habit is to spend a few days scouring the internet for examples of companies using a technology I'm interested in. Then, once I identify a company, I go down the rabbit hole and learn as many details as possible about the business and how it's using the given technology. I also contact the company, asking them to verify the assertions I plan to make.

Experience has shown me that when it comes to technology, things can change pretty quickly. Today's cool technology is tomorrow's retired legacy. Thus, to make sure my writing is accurate, I always try to contact the author or company in question to ensure that the technology I'm discussing in my article is still in play.

One of the use cases I was exploring was how the continuous integration/continuous development (CI/CD) service provider CircleCI uses gRPC. It turns out that CircleCI uses gRPC as the communication conduit that allows its service to handle 4.5 million build requests per month. I discovered this statistic in a blog post by CircleCI's CTO Rob Zuber, and it caught my attention.

So, I included the CircleCI use case in the article and contacted the company asking its engineers to confirm the accuracy of the information in the piece. They were happy to respond.

CircleCI confirmed that the company is indeed using gRPC to power its messaging between agents and system services. But there was an inaccuracy: It turns out that gRPC is handling hundreds of millions of requests per hour, much more than the 4.5 million a day Zuber mentioned.

My initial reaction was, "Wow! This is really going to get readers' attention!"

Not so fast

Then the story changed. One of my statements got a surprisingly different response. Here is what I wrote about CircleCI's use of gRPC: "gRPC is fast and efficient."

Yet Dan Mullineux, a United Kingdom-based staff backend engineer at the company, responded:

"But [gRPC] is also complex and still has less library and tooling support than plain HTTP. The longer-lived connections are more fragile, and the extra tooling adds more steps into the build pipeline. CircleCI is starting to deprecate the use of gRPC between its agents and system services since compressed HTTP is just as performant (at their scale) with improved robustness and less overall system complexity."

In other words, CircleCI plans to use less gRPC in favor of plain old HTTP as its transport mechanism between its agents and business services. gRPC has too many unwarranted tradeoffs for this use case.

[ Before you start your next container development project, check out 10 considerations for Kubernetes deployments. ]

Obviously, I had to modify my article. I planned to present the CircleCI use case to demonstrate some of the virtues of using gRPC in the real world. It turns out in the case of CircleCI that the real world is much different than the world I was describing. Thus, I cut the CircleCI section from the piece. The article is now 4 ways enterprise architects are using gRPC in the real world.

Making lemonade out of lemons

As a technology writer, this was a "mic-drop" moment. But despite my initial disappointment, I've come to realize that there is some lemonade I can make from this lemon.

A tendency I've noticed in my decades of observing, writing, and programming in the IT industry is our penchant for becoming enamored with the latest new thing. It's as if we're swimming in a sea of technologies where techno-fishers cast their lines about, hoping to lure us in with the mesmerizing appeal of their latest offering. Many times we take the bait. We lunge at that shiny new thing, not so much out of a thoughtful analysis of a particular technology, but rather because of an imperative that's part of our nature. We like cool stuff.

The hazard is that we can end up in situations where we embrace a technology out of romantic appeal rather than thoughtful analysis. Such can be the case with gRPC.

[ Time is money, so read 5 ways to accelerate enterprise architecture implementation. ]

Granted gRPC has a lot going for it. It is fast. It is efficient. But that is not the whole story of real-life architecture decision-making. As CircleCI reports, gRPC can also be fragile and more complex than the alternatives. Thus, it's not always the best solution for every problem in which the need for high-speed communication over a network is a critical factor.

There are cases in which gRPC is a good solution for the problem at hand. I've written about a few of these use cases. And, there are use cases in which gRPC won't work.

Summary

Working with gRPC is not for the inexperienced. Sometimes it's just too complex for a company to handle. But determining if gRPC is appropriate for your use case is not an all-or-nothing choice. Figuring it all out is a decision you make against a spectrum with many shades of gray.

A key factor for determining when and when not to use gRPC (or any other technology) is taking the time and energy required to comprehensively assess the particular use case you're considering for it. Also key is to do an honest assessment of your company's skills, expertise, and experience to determine if the business has what it takes to implement gRPC competently in a way that mitigates as much risk as possible.

Understanding when not to use gRPC is just as important as knowing when to use it. Determining the feasibility of using gRPC includes having detailed knowledge of the technology and a clear understanding of how the technology might get used by the company that's planning to use it.