Just the other day, I was reminiscing on my early childhood days in the 1980s. For those of you who lived through the 1980s, you will remember it as a very interesting time—big hair, big houses, and the beginning of the technology revolution. As a child, we grew up having the traditional toys such as Legos, trucks, and dolls, but we also started to be influenced by innovations in entertainment such as Nintendo, CDs, and LaserDiscs.
We didn’t have iPads, on-demand TV, or the internet, but it is funny that even with all these advancements in technology, the toy I so fondly remember was a simple one I played with in preschool. It was a colorful cube with differently shaped holes in each of the sides that allowed for similarly shaped blocks to be inserted into the cube. I sat with this toy for hours, inserting and removing blocks. It was a classic educational toy parents used to help kids learn about shapes, problem-solving, and pattern recognition.
What Toys Can Teach Us About Tech
The other thing this toy taught me represented a physical manifestation of the old adage, “You cannot fit a square peg into a round hole.” What this toy taught me was that sometimes, no matter how hard you try, you cannot force something that was made one way to fit into a hole that was made another way.
This lesson has stayed with me since that time. Even if I forget once in a while, I am reminded of it the hard way. Like the time I ordered that Halloween costume that was “one-size-fits-all,” which meant one-size-fits-small, which is not me.
Single Approach Solutions or “One-Size-Fits-One”
I was recently reminded of this lesson again in my professional career, working with the plethora of messaging technologies that provide communications infrastructure for application integration, stream processing, event-driven architectures, and so much more. For many years there was a movement by messaging service providers to become the one-size-fits-all solution for digital communication.
This approach was manifested in solutions standards such as Java Message Service (JMS, now Jakarta Messaging), Apache ActiveMQ (AMQ) and Advanced Message Queuing Protocol (AMQP), and even Message Queuing Telemetry Transport (MQTT). Each one of these standards set out with the goal of providing a common approach to solving the challenge of digital communications. Unfortunately, standards like JMS and AMQ/AMQP fell into the trap of one-size-fits-all and strived to be everything to everybody. MQTT started down this road but quickly learned from past standards mistakes and realized that a path to one-size-fits-all leads to one-size-fits-one.
There are so many examples of this truth throughout our history. The nirvana of having a single approach to solving all problems has baffled even our greatest minds, including Einstein and Hawking at the macroscale. So to think that we can have a single solution to digital communication is at the very least flawed and, at the very most, arrogant.
Purpose-Built Communications and the Power of Choice
This is why TIBCO has, for many years, taken the approach of providing purpose-built communications infrastructure in its messaging technologies. That isn’t to say we haven’t embraced standards, open-source, and proprietary solutions. On the contrary, we have brought all those approaches together to allow for flexible choice in the size, flavor, and color of communications needed for a given set of applications.
If you’re building an event-driven architecture, look at Apache Kafka or Apache Pulsar. If you’re building an Internet of Things (IoT) sensor network, look at Eclipse Mosquitto. If you’re building a real-time low latency application, look at TIBCO FTL. For transactional data delivery, check out JMS in TIBCO Enterprise Management Services (EMS). For RESTful services, there’s eFTL. The key to TIBCO’s approach to messaging is that one-size does not fit all, and building your enterprise on a single solution like Apache Kafka for digital communication only pigeonholes you into a one-size-fits-one approach.
While this lesson that I learned as a child has driven my and TIBCO’s approach to messaging communication over the last 30 years, others sometimes have to learn this lesson the hard way. That said, it seems like the idea that one-size doesn’t fit all is resonating throughout the messaging community. Take, for instance, one of my former TIBCO colleagues, who is now Field Chief Technical Officer (CTO) at Confluent. When asked on LinkedIn if Apache Kafka makes sense as the communications vehicle for market data distribution, they gave a clear and definitive “No.”
Flexible Approaches and Thinking About the Future
This is where we need to be when it comes to messaging infrastructure—realizing that one solution doesn’t meet all application requirements. Having purpose-built solutions that can meet those requirements, and allowing for those solutions to be brought together seamlessly, is the key to enabling application developers to build solutions where the communications channels are flexible and can evolve as demand changes.
Why build a solution on a platform that only supports a single approach, such as Apache Kafka or AMQP? Why not build a solution on a platform that provides a flexible approach that allows for using multiple solutions that can meet the specific requirements at hand and allow for growth in the future?Why build a solution on a platform that only supports a single approach? Why not build a solution on a platform that provides a flexible approach for using multiple solutions that can meet specific requirements and allow for growth in the future? Click To Tweet
That is why TIBCO Messaging includes six components with best-of-breed approaches for high performance and low latency communications, event and data streaming, web and mobile front end support, transactionality and standards support, IoT, and much more.
To find the messaging option that’s the best fit for your business, check out our deep dive into the pros and cons of Kafka, Pulsar, and other messaging technologies in this whitepaper.