Azure Container Service is now generally available

Finally Azure container services in here

IBM Bluemix Message Hub @Interconnect 2016

IBM is working hard to add more services to its Bluemix PaaS portfolio. Here I will share what I have learned about one of the Bluemix service called Message Hub @Interconnect 2016 in Las Vegas, NV this week.

IBM’s Message Hub based on Apache Kafka is a scalable, distributed, high throughput message bus to integrate Cloud applications. Main scenarios described for Message Hub is that, it 

·      provides cloud messaging for Bluemix services

·      allows building apps in a microservices framework

·      helps to be the channel to stream data to analytics engine available in Bluemix

Message Hub offers broad compatibility via 3 APIs: REST, Kafka and MQ Light (AMQP)

When using Message Hub one need to consider the following:

·      Kafka REST API allows producing messages and creating consumers. But, for more flexibility and performance one should use a Kafka client.

·      Message Hub is based on Kafka 0.9 which brings TLS-secured connections for clients, so the earlier high-level consumer cannot be used. The newer Kafka 0.9 consumer is the way to go.

I couldn’t get a good answer for their recommendation on when to use message hub (think SOR vs. SOE).

They also talked about providing a connector (message connect) to integrate on-premise messaging to the cloud-based Message Hub. Message Connect connects event sources that live outside of Bluemix directly to Message Hub.

Although Message Hub supports MQ Light API (AMQP protocol), making it JMS compliant is not on their roadmap. But they are willing to work on it if customers ask.

Packaging and productizing message hub for deploying in a private cloud or on-premise environment is also not on their roadmap. But if customers ask for it then they might do it.

All things considered, I think it’s huge that IBM is using Kafka as the backbone of their cloud messaging. They have taken the open source Kafka and added more QOS capability on top of it. It would be interesting to see what improvements they make over time.

Are you looking for using Kafka in your solution architecture? Would you be interested in using Message Hub or deploying and managing your own Kafka clusters? What’s your decision matrix? 

IBM Message Hub - IBM's Kafka in the cloud

Interesting to see that IBM building it's cloud native messaging platform backed by Kafka. It supports AMQP wire protocol with Kafka through the MQ Light API. When can we expect JMS support?

Watson and Cognitive Business Operations

Watson and Cognitive Business Operations in the age of the digital transformation and customer engagement.

IBM Messaging Technologies @Interconnect 2016

Looking forward to talk to Jens, Rob and Peter @Interconnect 2016

IBM MQ in Docker

MQ finally comes in docker!

IBM Cloudant, NoSQL database-as-a-service

IBM Cloudant is a NoSQL JSON document store that’s optimized for handling heavy workloads of concurrent reads and writes in the cloud; a workload that is typical of large, fast-growing web and mobile apps. You can use Cloudant as a fully-managed DBaaS running on public cloud platforms like IBM SoftLayer or via an on-premise version called Cloudant Local, that you can run yourself on any private, public, or hybrid cloud platform you choose.

IBM Business Process Manager on Cloud

Reinvent how work gets done with IBM Business Process Manager on Cloud

AMQP - the middleware equivalent of HTTP

JMS is an API specification of messaging for Java platform. The problem is that JMS API standardization is limited to only Java platform. And in reality, enterprises today have applications written on many other languages/platforms (e.g. COBOL, .NET, Node.js, Ruby, Python, etc.) including Java. Moreover, over time developers will use new languages as new technologies become available and new applications will be written to solve a particularly new problem. How can then it’s possible to set the infrastructure service providers and the developers free so that the choice of messaging client and the message broker does not become the limiting factor for cross-platform interoperability for application integration? The answer could be the emerging Advanced Message Queuing Protocol (AMQP).

According to AMQP.ORG, The Advanced Message Queuing Protocol (AMQP) is an open standard for passing business messages between applications or organizations.  It connects systems, feeds business processes with the information they need and reliably transmits onward the instructions that achieve their goals. It does that by implementing a wire-level protocol that can be thought of as the complement of an API. Instead of defining functions and creating libraries, AMQP defines the conversational byte sequences that pass over a network to make things happen. AMQP delivers the middleware equivalent of HTTP while leaving it up to others to provide implementations. Thus, AMQP is an open Internet protocol for reliably sending and receiving messages that make it possible for everyone to build a diverse, coherent messaging ecosystem.

Currently, some of the AMQP supported commercially available messaging products are: MQ Light and IBM MQ 8 by IBM, RabbitMQ, JBoss A-MQ by Red Hat, Apache Qpid, Azure Service Bus by Microsoft, etc.

This page gives a good overview of how AMQP is differentiated from other middleware standards.

However, AMQP lacks the API standards that JMS provides. And it might be a while before API standards for AMQP on a specific programing platform emerges. Until then the system designers would have to determine – What is more important? Cross platform interoperability of messaging or messaging middleware agnostic implementation of application integration through the use of standard API specification?