Microservices are extremely popular these days, and for good reason. They provide a blueprint that makes it easier for developers to repeatedly create robust and scalable applications. While there is no official industry-adopted definition of microservices, there are some generally accepted attributes that make up a microservice:
Many of these attributes are interrelated – since services are to be small and single in purpose, they must communicate with each other to provide real business value, and to be independently deployable they need to be small and single in purpose. While each of these are vital attributes, the ability to communicate without being tightly coupled to one another is a critical aspect of microservices architecture.
Note: For a deeper read you can take offline, get our latest paper on event-driven microservices:The Architect's Guide to Building a Responsive, Elastic and Resilient EnvironmentSr. Architect Jonathan Schabowsky addresses the challenges of microservices architecture and shares his perspective on the modern messaging integration patterns architects can leverage.
Well-known author and developer Martin Fowler advocates what he calls “smart endpoints and dumb pipes” for microservices communication. In the past, Enterprise Service Buses ruled the SOA universe and it was common to embed orchestration and transformation logic into the infrastructure. This meant that the pipe itself was “smart” and the industry treated the endpoints as “dumb”. There were multiple problems with this approach: the tooling was complex and expensive, and it was difficult to troubleshoot when problems occurred in production environments.
Today, with microservices, the IT community has embraced the reverse approach where services own their domain-centric logic (“smart endpoints”) and only utilize the “dumb pipes” as a transport mechanism. Most communications between microservices is via either HTTP request-response with resource API’s or lightweight messaging. While these two mechanisms are by far the most commonly used, they’re quite different, so I’d like to explain when it comes to deciding between REST vs Messaging for Microservices, which scenarios call for each. It’s important to not just have each of these tools in our toolbox, but to know which to use when.Share with your followers
Representational State Transfer (REST) was defined by Roy Fielding in his 2000 PhD dissertation entitled “Architectural Styles and the Design of Network-based Software Architectures”. Dr. Fielding was a part of the process of defining HTTP, and was called upon time and again to defend the design choices of the web. Through his work on HTTP, he distilled his model into a core set of principles, properties and constraints, now called REST.
Why is that important? It is my belief that we owe a great debt of gratitude to Dr. Fielding. RESTful interactions have become vital to enterprise computing as it enables many APIs on the web today. With that said, lets define what problems REST solves best:
Most microservices architectures will have at least one of those use cases but the trick is not to fall for the Law of the Instrument –a natural cognitive bias that leads to over-reliance on a familiar tool. Abraham Maslow (the psychologist who invented the law) said: “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”
Due to the popularity of RESTful services today, I see many companies falling into the trap of using REST as an “all-in-one” tool. Certainly, some of this popularity is due to the power REST provides based on its own merits. Developers are also used to designing applications with synchronous request/reply since APIs and Databases have trained developers to invoke a method and expect an immediate response.
In fact, Martin Thomson once said, “Synchronous communication is the crystal meth of distributed software” because it feels good at the time but in the long run is bad for you. This over reliance on the use of REST and synchronous patterns have negative consequences that apply primarily to the communication between microservice within the enterprise and that in some cases are at odds with the principles of proper microservice architecture:
The solution to many of the shortcomings associated with RESTful/synchronous interactions is to combine the principles of event-driven architecture with microservices. Event-Driven Microservices (EDM) are inherently asynchronous and are notified when it is time to perform work. In many cases, asynchronous communications is how many of our daily interactions take place. Take Facebook: It would be incredibly inefficient to navigate to each friend and check to see if they have a status update. Instead we are notified when a friend has updated their status so we can go see that cute new picture of their cat. Obviously, that makes us more productive as individuals. (in our use of Facebook anyway…)
The benefits of messaging for event-driven microservices are many and varied:
Event-driven microservices should be considered more often by developers and architects as they provide the foundation to build awesome systems and applications. To learn more, check out the “microservices” section of our Resource Hub for a variety of microservices-related content.
To learn more about how message exchange patterns can unlock the full benefits and value of event-driven microservices, take a look at this blog post where I walk through through a real-world example. Additionally, in this post I compare microservices choreography vs orchestration and explain the benefits of choreography.
As Solace’s Field CTO, Jonathan helps companies understand how they can capitalize on the use of event-driven architecture to make the most of their microservices, and deploy event-driven applications into platform-as-a-services (PaaS) environments running in cloud and on-prem environments. He is an expert at architecting large-scale, mission critical enterprise systems, with over a decade of experience designing, building and managing them in domains such as air traffic management (FAA), satellite ground systems (GOES-R), and healthcare.
Based on that experience with the practical application of EDA and messaging technologies, and some painful lessons learned along the way, Jonathan conceived and has helped spearhead Solace’s efforts to create powerful new tools that help companies more easily manage enterprise-scale event-driven systems, including the company’s new event management product: PubSub+ Event Portal.
Jonathan is highly regarded as a speaker on the subject of event-driven architecture, having given presentations as part of SpringOne, Kafka Summit, and API Specs conferences. Jonathan holds a BS Computer Science, Florida State University, and in his spare time he enjoys spending time with his family and skiing the world-class slopes of Utah where he lives.[position] => Field CTO [url] => https://solace.com/blog/author/jonathan-schabowsky/ ) )