How Synchronous REST Turns Microservices Back into Monoliths
If you are breaking down a monolithic legacy application into a set of microservices, and if those microservices are communicating via REST (Representational State Transfer), then you still have, in effect, a monolithic application, asserted Lightbend tech lead, James Roper.
Roper laid down this heavy wisdom at the monthly New York Java Special Interest Group meeting on Wednesday, at the Viacom headquarters in Manhattan.
In the talk, Roper was a big advocate of asynchronous communication. Not surprisingly, Lightbend (formerly Typesafe) offers a Scala-based microservices platform, called Lagom, based on asynchronous communications.
Keep in mind, “asynchronous communications” is different from the commonly used term “asynchronous I/O.” Asynchronous I/O is all about not halting an operation to wait for a process thread to complete, while asynchronous communication, an artifact of microservices, is about designing a system such that one service doesn’t need to wait on another to complete its task.
“Using async communication, if a user makes a request to a service, and that service needs to make a request to another service, that communication is not going to block [the first service] service from returning a response to the user,” Roper said.
1000 times this https://t.co/557KzcmMDZ
— Chad Thomas™ (@chadcthomas) April 14, 2016
Today a good majority of microservices architectures use the REST (Representational State Transfer) protocol to facilitate communications across different services (to take the place of the object call). Although REST proved to be much easier to implement than other comms (notably the XML-based SOAP), it has an inherent disadvantage in that it is synchronous in nature, rather than asynchronous.
“A client sends a request, the server sends a response,” Roper said, describing how REST works.
One failed service can bring the whole operation to a halt.
A user-facing service made up of a series of microservices communicating synchronously may be set up so that one microservice relies on another, which in turn may rely on the third microservice, and so on. This approach works fine as long as all the services are working. But if one microservice fails, it could set off a chain of failures that would ultimately lead to service denial to the end-user, Roper explained.
Likewise, if one microservice is slow, then the response time as a whole slows down.
Using synchronous communications like REST, “from a technical perspective, we’ve just built a monolith. It doesn’t matter that all these things are separate services, the system is still behaving like a monolith,” Roper said.
(For the conversation, Roper assumed that the audience understood the benefits of a microservice architecture over a monolithic one, for all the usual reasons such as that microservices are easier to repair and reconfigure).
In asynchronous communications, a service may still rely on another service, but does not delay sending back its response because it is waiting on input from the other service. So, if one service fails, it will not affect the other services, Roper explained. “It does not impact anything else in the system,” Roper said. Bottlenecks and single points of failure are also eliminated in this design.
I understand the sentiment but disagree, they are microservices but you aren't getting the full benefit of them https://t.co/6UORzGFsml
— Mathew Attlee (@codeinabox) April 14, 2016
Using a demo of a Java-based Twitter-like service, Roper showed the audience how to implement asynchronous calls in the code in a number of ways. One approach is to have each microservice publish the information it provides whenever that information is updated, rather than waiting for another microservice to request that information. In this way, if the chat service, for instance, needs a list of “friends” of a user, it can use the latest one provided by the “friends”-dispensing microservice, rather than requesting that information from the microservice, which may or may not be running.
Asynchronous communication can have challenges in consistency, or in ensuring that the end-user gets the latest information, Roper admitted. Many social networks, such as Facebook, use eventual consistency, which makes no guarantees that each user’s newsfeed, for instance, has the most up-to-date information.
@PeterLawrey @thenewstack @jroper @lightbend @nyjavasig so then do you advocate for building system Integration off an Ent. Service Bus?
— Norman Harebottle (@normanhh3) April 14, 2016
Also, it is hard to beat the simplicity of implementing REST calls. One attendee appeared aghast at the amount of coding that needed to be done to implement asynchronous communications.
“You’re going through this to replace a real simple REST Call?” the attendee asked. Roper noted that some software, such as Apache Kafka, could handle the low-level details of asynchronous services automatically.
“With a simple REST call, your service is going down. With this, it is not,” he said.
