SAN JOSE, Calif. — The API World conference provided a good deal of advice and direction for those interested in taking their monolithic software architectures toward a more distributed, microservices-based architecture, particularly in regard to microservices messaging protocols.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Let’s look at some of the revelations and instructions provided to conference attendees related to microservices, including how to move beyond REST and some of the latest and greatest messaging protocols and architectures worth watching.
Moving beyond REST
There was buzz at API World 2017 about the use of REST as the standard messaging protocol for microservices. While REST has been popular, members of a panel session focused on the evolution of microservices messaging protocols suggested organizations are — and should be — ready to explore other options for messaging.
“People were not happy with RESTful APIs, because there is a pattern mismatch,” said panel member Fran Mendez, lead engineer at the London-based API support platform provider Hitch. “Even [with] web sockets, you need to have a great connection to make them match. That’s why people are looking at other options for event-driven.”
How Reactive can help
Mark Makary, CTO and president of Logic Keepers, a technology adviser company based in Frisco, Texas, spoke to conference attendees about the potential drawbacks of depending on a traditional blocking REST architecture for microservices and how moving to a Reactive nonblocking, event-based architecture may help.
“After people are going through the [microservices] journey, they run into problems where the system is not very responsive,” Makary explained. “We are getting used to apps getting very responsive, and this is part of the user experience.”
Makary explained there are three potential drawbacks on performance: I/O and database blocking, monoliths and performance management, and poor internal and external endpoint management. By moving toward a Reactive architecture, he said, organizations can make their applications more responsive, elastic, event-driven, asynchronous and nonblocking.
Consider gRPC, Kafka and GraphQL
One suggestion was for people to start exploring gRPC, an open source remote procedure call system initially developed at Google. Varun Talwar, product management lead at Google, explained that since this protocol uses HTTP/2, it allows for what he called “a very polyglot way for people to communicate.”
“GRPC can help with streaming, client-side streaming, server-side streaming and getting messages back,” Talwar explained. “A lot of people in the REST world found that hard to do.”
The discussion also shifted toward a conversation about the use of Kafka, an open source stream-processing platform, mainly due to its fault-tolerant nature of delivering messages.
“You can ensure that [Kafka] is reliable on two or three brokers,” said Mike Sample, director of technology and principal developer at Hootsuite, a social media management platform provider in Vancouver, B.C. “They can store two or three partitions … it’s very robust.”
Panel members also touted the advantages of using GraphQL, a data query language developed internally by Facebook, as an alternative to REST architecture, particularly for distributed development teams.
“Organizations can have spread-out development teams … [GraphQL] can really help with that,” explained panel member Ryan Blain, CTO at Atlanta-based Arvata.io. “It has to be thought of as an API gateway, and that gateway can reach out to different services.” Blain warned, however, that tooling for GraphQL may be relatively immature.
Taking it all home
Attendees of API World reacted positively to the microservices session, particularly to the panel discussion about microservices messaging protocols.
“My favorite one was actually the panel, the discussion about what the different communication protocols between the microservices are and why we would use one over the other,” said Hema Rajashekhara, a senior application developer at the financial services company Capital Group.
Rajashekhara said she is actively looking for more information about microservices messaging protocols to help mitigate performance issues as they transition toward microservice implementation.
“One thing that I’m concerned about is performance and communicating between the different microservices and how it’s going to affect performance,” she said. “So, to hear the differences between gRPC and Kafka is something that I’m going to take back and see what’s best to apply.”
Other attendees, such as Barb Honken, a systems integration analyst at Blackfoot, particularly gravitated toward the discussions about the use of the GraphQL language for microservices.
“I didn’t come here thinking I wanted to learn more about GraphQL,” Honken said. “But now I do.”