I explore why you might want to use messaging technologies across cloud and on premises, and what solutions that IBM offers in this space (included Message Hub, MQ, and MQ Appliance).
What is Hybrid Cloud? Simply put, Hybrid Cloud is connecting any cloud service to any other technology resource. That’s it. Whether that be connecting your service in one cloud to a service in another, to an on premises data center, etc, etc.
What is Hybrid Messaging?
Messaging is getting data from one area of your business to another
Messaging is asynchronous, meaning that if a part or the whole of your system goes down, data is not lost.
So Hybrid Messaging is moving data around your Hybrid Cloud environment to ensure that the data gets to where it needs to be, so that you can gain the most advantage from that data.
And why is Messaging important? If I write you a text or email about our trip to the cinema later, but don’t send it, then you’re not going to know that the show starts at 8pm, or that you need to leave a little earlier because there are roadworks going on that you need to avoid.
It’s the same with the systems that run your business. If your applications and systems do not communicate, things don’t happen.
So, hybrid messaging is getting data from one part of your business to another, within a hybrid cloud framework.
So, a quick history lesson…
Some of you will be familiar with the terms 1st, 2nd and 3rd generation platforms, which signify shifts in how we consume technology:
The late 1950s brought with it what is known as the ‘1st platform’. This platform, still being used today, focuses on using a centralised mainframe. These systems are known for their reliability, availability, and stability.
In the 1980s came the 2nd platform, which focuses more on a client/server relationship. Software is sold as packages that are used on distributed systems. This software doesn’t require the specialist knowledge of a mainframe engineer. Customers acquire a license, install the product, and use it. This doesn’t mean that the mainframe is dead. It still is used for businesses across the world. 2nd platform teams are technology–aligned, meaning that one team will focus on databases, another on applications, and so forth.
The 3rd platform has come into its own in the past few years, and focuses on using the agility of developing in the cloud. They use social, mobile, analytics, and cloud to access new users, data, and opportunities. The potential is huge, with the businesses able to reach trillions of IP-addressable ‘things’. Business models are aligned with business outcomes and customer experiences. As such, teams focus on a function end-to-end, rather than on a specific technology.
So where does cloud fit in? Surely this is only relevant to the 3rd platform? In reality, whilst the 3rd platform starts in the cloud, more and more, 2nd platform users are looking to extend to the cloud to improve efficiency. But why the interest? What are the advantages?
At the heart of working in the cloud is agility. Businesses using cloud can react to changing needs fast, and use this to disrupt the market. Take IoT, for example. Data from wearable devices is changing the way that people monitor health. So many people that I know own a device that measures steps, or have a watch that monitors their running habits. They can synch these to their phones, and use the data to record progress and inform future decisions.
This agility is reflected in the cost models. Rather than paying a fixed cost, users can benefit from pay as you models. Pricing models in the cloud enable users to know what they’re paying for, and to pay for more or less as the need arises.
This is linked to scalability. Users can increase or decrease resources according to need, and pay for what they use. Being able to scale means that users are not restricted by past buying choices, and can adapt quickly according to what they need.
Cloud offers self-service provisioning. This means for a lesser reliance on other parts of the business setting up the infrastructure. This is taken care of for you. The barrier of entry lower, with users able to pick up tools quickly.
Resources are available on demand. Users can choose the tools that they need and get started quickly – range of services.
And more…centralisation of resources, backup (example)…
So why not shift entirely to the Cloud? Let’s look at the strengths of working on premises.
For those who already have on premises systems, you have a wealth of resources already in place. You have invested in skills and technology. You have a lot of useful data, and systems in place that can handle them. Systems that you trust for their reliability. Much of this data can be reused, and whilst integrating with the cloud can improve efficiency, re-creating everything in the cloud rather than re-using what you already have is probably inefficient. If you are going to extend to the cloud, then it is best to consider what benefits you are trying to gain, and extend appropriately.
Keeping some on premises systems in place is useful for accessing specialist hardware. For example, appliances, or mainframe.
Whilst it is commonly believed that cloud security is as good as on premises, or better, there are some bodies that stipulate that certain data be stored on premises, or be easily shown to be in a certain location. This is common in healthcare, for example, when much of the data is considered sensitive.
The main benefit, however, is control. When your data is on premises, you control exactly what resources you use, the speed of systems, the visibility of data, etc, and can customise systems exactly according to your specifications. Whilst cloud service providers are offering more and more options and flexibility, you are reliant on the options that are offered.
To recap the relationship between the platforms, cloud and on premises systems.
On the left, applications are developed primarily on premises by teams that are technology-aligned. This is the 2nd platform. More and more, these users are looking to improve efficiency by extending to the cloud. Instead of moving everything to the cloud, users choose to use the parts that will increase efficiency.
On the right, applications are developed primarily in the cloud by teams that are function-aligned. They work agilely and push data to on premises when this is useful. This is the 3rd platform.
Both approaches use a combination of cloud and on premises. Both are examples of hybrid cloud. Later in the webcast, we will also look at a third, which actually joins both 2nd and 3rd platform together.
- The first of the solutions that I cover will talk about the option of pushing data from IBM MQ to the cloud.
- The second will be about using IBM Message Hub both in the public cloud and local/dedicated. Our data center, your cloud.
- The third will be about bridging 2nd and 3rd platform benefits by connecting the MQ side with the Message Hub one.
So what is IBM MQ?
IBM MQ is a powerful tool that’s been in the market for over 25 years. It underpins a range of industry-types worldwide.
MQ provides asynchronous messaging for a wide range of systems. Applications that are indicipherable because they were written in some forgotten language by somebody who has long since left the company can communicate with those written in the latest language by your newest developer last week. Communication is fast, and because the messaging is asynchronous, the business has the assurance that data will not be lost. With MQ, data arrives on time, in order, and once and once only. After all, who wants to receive the tennis scores out of order, or get paid twice? Well, maybe that last one…
And you can use this foundation and extend it to the cloud.
The best and easiest way of doing this is through patterns. We have made MQ available as a component as part of PureApp. You can create your own configurations, customise install, configuration and lifecycle via the PureApp console, and reduce overheads. There is also support for High Availability or Disaster recovery with multi-instance Queue Managers.
MQ is also available as an image on Amazon Web Services, and on Microsoft Azure. You could also choose to run MQ in Docker, or on Chef. The links in the presentation show you how to get started with each.
Docker: popular container service
Chef: enables scriptable deployments of MQ, which you can combine with other things, such as additional monitoring agents, for example
I’m going to take a moment to mention the MQ Appliance. That might seem a bit odd, when I’m talking about Hybrid Messaging. Some might even think of the Appliance as ‘anti-cloud’. But there are benefits of the Appliance that do sound familiar when thinking about the benefits of cloud.
Like IBM MQ, IBM MQ Appliance is an on premises enterprise offering. The appliance combines version 8 of IBM MQ with a physical appliance, simplifying setup, maintenance, and enabling customers to reduce total cost of ownership. It has the benefits of MQ, but offers them in a hardware appliance, the idea being that this is a simplified way of consuming MQ. It uses firmware updates, making upgrades simple, and reducing the impact of the upgrade process. They are pre-optimised and have no endpoints. They have high availability or disaster recovery built in, meaning that you can worry less about losing your data, and more about continuing work as normal.
This ‘out-of-the-box and ready to go’ approach is reminiscent of what cloud services achieve through self provisioning. Because it is pre-optimised and because it receives firmware updates, as with cloud services, less maintenance is required.
The first of the solutions that I covered talked about the option of pushing data from IBM MQ to the cloud.
Let’s move on to the second, which focuses on those 3rd platform businesses who want to push data from the cloud to on premises.
For 3rd platform users, we created Message Hub. Message Hub has Apache Kafka at its core, offering it as a supported service. The business gets the benefits of this technology, but can save time in setting it up, and cut down on support. We keep up to date with the Kafka community, and make updates so you don’t have to. In fact, we went live with version 0.9 before it hit the market!
Message Hub offers wide compatibility, enabling you to choose between using a REST or Kafka API to communicate. We are also working on a third option, the MQ Light API, which is based on the Oasis standard, AMQP.
(If you want to get an idea of what that will look like, search for IBM Message Hub Incubator, where this is being trialled before being incorporated into Message Hub itself.)
Message Hub is available on our Platform as a service, IBM Bluemix, which is where we house a range of services in the cloud. Message Hub is currently available in Bluemix Public, which is multi-tenant and pay as you go, and in Bluemix Dedicated. Bluemix Dedicated is a hosted cloud, running on SoftLayer. Message Hub will also be available in Bluemix Local. Bluemix Local runs in your datacentre.
The three Bluemix options give users the choice of whether to use Message Hub in the cloud, in SoftLayer, or locally on premises.
I mentioned Apache Kafka. Those who are familiar with opensource have probably heard about it. Kafka provides pub-sub messaging, and is fast, scalable, durable, and distributed by design. It was invented by LinkedIn, and then made opensource. If you search for information on Kafka, you will likely come across Jay Krepps, who will explain how the company wanted to move from what he terms as a ‘great big mess’ i.e. with lots of different systems communicating in an inefficient manner, to something more consolidated, by using Kafka. It is this technology that we’ve brought into the heart of Message Hub, and extended, by adding other communication options.
Message Hub features heavily in the 3rd platform approach, but what does Message Hub actually do?
It provides asynchronous messaging, which means that it acts as a buffer between applications, giving you greater assurance that data will not be lost. We use it to connect with other services in Bluemix, and are collaborating with various teams to make this simple. The benefits of these connection is a reduction in time and effort spent manually integrating two services to work together. If you choose a service that is connected with Message Hub, it can connect with any other that Message Hub already connects to with ease. Of course, you can work your service to integrate with Message Hub if it is not yet on that list, but be aware that as we develop, the options for simplification when connecting to other services should increase. This extensibility not only saves you time, but provides a range of tools that you can use in the form of other services.
But the chances are that you already have services in mind. Connecting them to Message Hub gives you that buffer, as well as error handling and load balancing, making that solution even stronger.
But it’s not all about Bluemix. Message Hub can connect to event sources from outside of Bluemix. This includes to MQ, which we have already covered. This connection with MQ is the way of enabling hybrid messaging in this scenario.
What are the other benefits of connecting to Message Hub? Message Hub enables developers to work in a way that is fundamentally different to how traditional 2nd platform applications have been constructed. This approach, which is prevalent amongst 3rd platform users, is called the microservices framework. Microservices allow for quick innovation, flexibility, and increased reliability. Let’s look into how that actually works…
At a very simple level, instead of building one application that you need to rewrite every time that you want to make a change, you can break it down. Applications written in a microservices framework are composed of small parts, called microservices. Developers change the part of the application that is relevant to them, agree with their team that their changes haven’t broken anything in that microservice, and integrate them. The lack of dependencies between different parts of the application mean that a change to one part does not necessarily affect the rest.
Let’s look at this in practice.
A supermarket has a great innovation. They want customers to receive offers to their mobile devices, as they walk past certain products. Changes are made to an existing application. But because of the way that the application is created, it takes time to change. And because of the interdependecies between the different parts of the application, a change can cause problems elsewhere, causing the entire thing to crash, or act in an unexpected fashion.
If, however, the application had been written in a microservices framework, the developer could have spent less time writing code because they were focusing on the one part that was relevant to the problem that they were trying to solve. In fact, if this was new function, they could have written a new microservice to handle this task. Because the code is isolated, if there are problems, they would not affect other parts of the application. Whilst that part might go down, the rest would still function.
What else can Message Hub do?
Message Hub is also particularly good at streaming analytics. As I have said, it is based on Kafka, which is often used for this very purpose, with Spark, Samza, etc. In the way that Kafka handles data, it puts them into the form of messages, and posts them to topics. Because Kafka splits topics into partitions, it can process a lot of data in parallel. Being based on Kafka, whether you want to run batch or real time analysis, or whether you want to run both in parallel, Message Hub can handle this.
And what’s the benefit? Depends on your industry, and what you want to do, but here are some examples…
So these are some of the advantages of using Message Hub.
But why have I mentioned the extensibility? Why the analytics? Do you see the number 4 on the chart? It is because in your solution you might incorporate more than one of these usecases.
We’ve covered two ways of achieving hybrid messaging so far. The first explores how 2nd platform businesses can push data that they already have to the cloud. The second focuses on 3rd platform businesses that want to push data from their cloud to on premises. Now, we’re looking at bridging the two world of 2nd and 3rd platform.
Why would you want to do this?
If you have on premises applications and want to improve efficiency, you could push to the cloud, and we’ve already explored the benefits of this. But what if you want to integrate applications developed in a 2nd platform way with those developed with a 3rd platform focus?
For example, connecting to one or more analytics engines alone is not the complete solution. It is also about what else connects to Message Hub, and where that is MQ, for example, we suddenly have the case where we aren’t simply talking about connecting Message Hub to MQ, but the analytics in the cloud, to MQ, which opens up new possibilities.
So let’s consider the benefit of using analytics with your on premises systems.
For example, take a bank that is trying to make its systems more efficient. It wants to take a copy of the transactions stored on premises and analyse them using cloud software. Of late, the bank has also invested in mobile banking, meaning that the data is coming from mobile, as well as other points.
In this scenario, the bank not only has data stored on premises that it can use to make opportunities, as well as access to new endpoints through mobile that it wouldn’t have accessed without the 3rd platform approach. With the use of analytics in the 3rd platform, the bank gets the benefit of both platforms
Or consider this scenario…
A coffee shop wants to create a loyalty scheme that is based on an app built in the cloud. It’s a great way of accessing customer data, but they already have a lot of useful customer data on premises. How do they make the most of both technologies?