Smart Endpoints. Smart Pipes. Smarter Microservices.
Overview:
This is the second post in a series on microservices. Read our previous post on the service computing environment: The Ephemeral Life of Dockerized Microservices.
The use of microservices is a growing trend in application development because it provides an answer to the overhead incurred by monolithic applications. The practice of breaking apart application components into independent services introduces more moving parts to manage, however, requiring a robust communication method in order to keep services and data in sync. The idea is to decouple services without derailing your application.
The common thought within the microservices community is that only the endpoints need to be smart, not the pipe itself. The endpoints being the services that produce and consume messages, and the pipe being the inter-service communication layer. For example, a registration service captures user information, validates the data, and then encrypts the payload before delivering to an account service. The account service then decrypts the payload and writes it to a database. In passing the message from the producer to the consumer, the pipe performs no additional work other than its delivery.
While removing any logic from the communication layer is a step in the right direction, there is still a need for smarts in the transport – it’s just how smart that makes all the difference.
Table of Contents:
Achieve Cloud Elasticity with Iron
Speak to us to find how you can achieve cloud elasticity with a serverless messaging queue and background task solution with free handheld support.
Queue all the Things
A key exercise in building out a microservices application is deciding what components to decouple – the general thought being independent processes that run outside of the immediate user response loop. These could be background jobs, long-running tasks, or data processing services. Asynchronous processing allows for asynchronous communication, with the message queue as the broker between services.
Get Smart
A "dumb" pipe in the world of message queues is one that provides no more than a mere transport layer. This is certainly a step up from passing data over pure HTTP or TCP/IP as the queue can still act as a buffer when consumers can't be reached or are overloaded, however, there's little to no insight into what goes on while in motion. Business is far too data-driven these days to overlook its transit – with the continued proliferation of connected devices only increasing the sheer volume of data being passed around. Imagine losing an order from a billing service to a fulfillment service – just the possibility is unacceptable from a technical and business perspective.
Persistence is a key trait that makes a message queue evolve from being “dumb” to being “smart”, but what does that really mean? Message queues are not databases or caches in the traditional sense but can provide persistence by writing to disk during the queue process. The general pattern is to write once, read once, and then delete when acknowledged by the consumer. The acknowledgment, or ack, is a critical step in ensuring the persistence is working as it’s intended.
There’s more to being "smart" than just message persistence, though. Messages should be delivered once and in a first-in-first-out (FIFO) manner. To put that into relevant terms, consider an airplane seating system – client applications produce a request, while the service checks availability and associates an open seat with the user. If the system does not consume those requests one by one in their intended order, it could lead to errors in how it makes those reservations... and angry passengers. Okay, bad example, but you get the idea.
Iron.io Serverless Tools
Speak to us to learn how IronWorker and IronMQ are essential products for your application to become cloud elastic.
Thanks for subscribing! Please check your email for further instructions.
About Performance
Many open-source message queue products aim to be the most performant with throughput as the key benchmark (messages/second). While certainly not a metric to ignore, we have yet to encounter a business use case where throughput outweighed reliability. Modern hardware and software have made the difference all but negligible in asynchronous messaging patterns, with network latency being the more important metric that has any noticeable impact on performance requirements.
We have continued to optimize the performance of IronMQ, while maintaining the reliability expected from our customer base. A "smart" message queue such as IronMQ that is persistent by design with one-time FIFO delivery provides the right balance between durability and simplicity that is in line with the microservices architectural style.
The Next Word
We've now covered service computing and communication in this series – stay tuned for the next post where we bring it all together with an API gateway.
To get started with IronMQ for free, sign up for an account today. It's the "smart" thing to do 😉
Find this interesting? Discuss on Hacker News
Unlock the Cloud with Iron.io
Find out how IronWorker and IronMQ can help your application obtain the cloud with fanatical customer support, reliable performance, and competitive pricing.