HYTE MQ on Kubernetes

Messaging Platform-as-a-Service,
in your own Kubernetes clusters

HYTE MQ installs in your own Kubernetes clusters, on any distribution, in any public or private cloud. You control the platform. HYTE Console gives platform and application teams one place to view and manage event flows.

Schedule a Demo Contact HYTE
  • Any Kubernetes distribution
  • Public and private cloud
  • Bare metal and virtual machines
  1. Any CloudPublic cloud, private cloud, virtual machines, bare metal.
  2. Kubernetes NativeClusters that provision and connect themselves.
  3. Self-ServiceHYTE Console and a REST API for every team.
  4. Any Event FlowWithin one cloud, or across several.

Cloud vendor independence

Any cloud, anywhere

HYTE MQ works with any public or private cloud provider, with virtual machines, and with bare-metal infrastructure.

Kubernetes gives your organization one way to deploy messaging clusters in a single cloud provider or in several. Abstracting the provider keeps your messaging portable across cloud platforms.

  • Multi-cloud environments
  • Cloud vendor abstraction with Kubernetes
Private cloud AWS Google Cloud DigitalOcean Azure
HYTE MQ HELM Azure Google Cloud AWS

Kubernetes distributions

One Helm chart across cloud vendors

Helm chart deployments standardize HYTE MQ on Kubernetes from one cloud vendor to the next. You keep the ability to use each vendor's specific capabilities.

Bare metal and virtual machines

The HYTE MQ platform also runs without Kubernetes

  • Public cloud virtual machines
  • Private data center virtual machines
  • On-premises bare metal
  • IoT embedded compute

Interoperability

Kubernetes native

HYTE MQ is Kubernetes native and uses the best elements available within Kubernetes.

Benefits

  • Runs in all types of compute environments
  • Abstracts the public cloud vendor

Capabilities

  • Configuration management
  • Kubernetes Operator
  • REST API
  • Self-service console
Kubernetes HYTE MQ cluster HYTE MQ cluster HYTE MQ cluster HYTE Console Kubernetes Operator Observability REST API Configurationmanagement

Provisioning steps on Kubernetes

From a volume to a clustered, load-balanced HYTE MQ in five steps

Kubernetes brings a HYTE MQ cluster up in sequence. Configuration and clustering happen on their own.

  1. 1
    Volume added
  2. 2
    HYTE MQ container added
  3. 3
    HYTE MQ pods started
  4. 4
    HYTE MQ auto-configured and auto-clustered
  5. 5
    Load balancer provisioned

Operational best practices

Cluster connectivity that configures itself

HYTE MQ configures cluster connectivity during scaling, upgrades, and maintenance.

Scaling and upgrades

Brokers drain messages to their peers in the cluster during upgrades and scale-down, which keeps messages available.

Automatic clustering

Brokers in the same cluster connect on their own, and event flows configure across every broker in the cluster.

Security

HYTE MQ supports SSL certificate management, with optional use of cloud-vendor managed SSL certificates on load balancers.

Load balancers

A single web application reaches all brokers in a cluster and updates as Kubernetes scales the HYTE MQ cluster up and down.

Multi-tenancy

Run multiple event flows per HYTE MQ cluster, and multiple HYTE MQ clusters per Kubernetes cluster.

Multi-cluster connectivity

Connect across Kubernetes clusters for multi-cloud event flow redundancy.

Management

Self-service for the teams that own the applications

HYTE MQ gives users secured access to view and manage their own event flows.

The platform integrates with Kubernetes to automate processes and to give platform and application teams complete observability.

  • Secure access to resources
  • Delegate common tasks to application teams
  • Support message management tasks
  • Self-service API for automation
Developer Security API Automation Support
HYTE Console showing the queues on a HYTE MQ broker with message counts, memory and store usage, connections, flow control, and configuration panels.

HYTE Console

One console for your enterprise messaging platforms

Many companies run multiple messaging platforms, with application and support teams around the globe. The Kubernetes-integrated HYTE Console lets you view and manage them in one centralized application.

  • Modern web UI
  • Secured access to designated queues and topics for application teams
  • Sensible default templates
  • Customized security access (IAM)
  • Active Directory and LDAP integration
Explore HYTE Console

HYTE API

Every console function, available over REST

HYTE Console management and messaging data services are available through a REST API, so teams can automate messaging administration and testing tasks. Built-in rate limits control the flow of API requests.

  • REST-based access to all functions
  • The same secured access as HYTE Console
  • Application teams automate production tasks
  • DevOps teams run CI/CD tasks
Application 1 Application 2 { } HYTE API Applicationcluster 1 Applicationcluster 2 HYTE MQ cluster HYTE MQ cluster

Protocols and clients

Connect with the protocol your application already speaks

HYTE MQ is based on Apache ActiveMQ, which speaks open, standard messaging protocols. Application teams connect with standard client libraries in the language they already use.

ProtocolWhere it fitsTypical client languages
OpenWire and Jakarta Messaging (JMS)

Java services and enterprise applications

Java, plus native C# client libraries

AMQP 1.0

Services written in different languages, and cloud integration

Java, .NET, Python, Go, JavaScript

MQTT

Devices, registers, and edge applications

Go, JavaScript, Python, C

STOMP

Scripts and lightweight tools

Scripting languages

WebSocket

Browser and mobile front ends

JavaScript, over MQTT or STOMP

Ask which client library fits your stack

Use cases

Any event flow, in one cloud or across several

HYTE MQ supports all event flows, including multi-cloud and cross-cloud.

APIs HYTE MQ cluster Microservices

Event-driven applications

Event-driven design gives complex applications scalability, modularity, and asynchronous task execution.

HYTE MQ cluster HYTE MQ cluster Cloud A Cloud B

Multi-cloud connectivity

Share data across cloud zones and regions, so applications in different areas reach the same events.

Microservices Functions SaaS APIs HYTE MQ cluster

Messaging as a service

Integrating applications and systems requires dependable delivery of messages and events between them. Your platform team offers that to every application team from one shared platform.

Migration paths

Start from where you are

Few teams begin with an empty cluster. HYTE has a path in from the messaging you run today.

From IBM MQ

Standard messaging protocols and APIs turn most code conversion into configuration, rebuilding, and retesting. HYTE MQ integrates with IBM MQ clustering, so both run side by side while you move at your own pace.

See the IBM MQ migration path

From ActiveMQ on virtual machines

HYTE MQ moves between virtual machines, bare metal, and containers without changes to application code, so administrators can shift runtimes onto Kubernetes without pulling in development teams.

Read about HYTE MQ

From a mix of messaging products

HYTE Link bridges messaging products from multiple vendors and protocols, and HYTE Console manages them in one place while the transition runs.

Read about HYTE Link

HYTE Support

Support from engineers who work on the broker itself

HYTE supports integration technologies and nothing else, so the engineer on your case is a messaging specialist. Our engineers commit code upstream to Apache ActiveMQ, and HYTE delivers patches and contributes fixes back to the community.

Choose around-the-clock or business-hours coverage to match when your business needs it.

Explore HYTE Support

Every support package includes

  • Unlimited support cases
  • All of your ActiveMQ environments
  • Sample code for development questions
  • Architecture reviews with a tenured architect
  • Quarterly reviews of recent cases and planning

Get started

From Helm chart to running cluster

HYTE MQ installs with the tools your platform team already uses.

  • A Kubernetes cluster, on any distribution
  • Helm
  • Persistent storage for broker volumes
# Add the HYTE chart repository
$ helm repo add hyte $HYTE_CHART_REPO

# Install a HYTE MQ cluster into your namespace
$ helm install $RELEASE hyte/<chart> \
    --namespace $NAMESPACE --values values.yaml

# Watch the brokers start and join the cluster
$ kubectl get pods --namespace $NAMESPACE --watch

Questions?

Talk it through with a Messaging Platform Architect

A short conversation can make it all clear. Schedule a quick discussion or an online demo of the platform and tools.

Schedule a Demo Contact HYTE

Frequently Asked Questions

What is HYTE MQ on Kubernetes?

HYTE MQ is an enterprise messaging platform based on Apache ActiveMQ. On Kubernetes, HYTE MQ installs in your own clusters through Helm charts and works with any Kubernetes distribution in public or private clouds. HYTE Console gives platform and application teams one place to view and manage event flows.

Which clouds and Kubernetes distributions does HYTE MQ support?

HYTE MQ works with any Kubernetes distribution and with any public or private cloud provider. Helm chart deployments standardize the installation across cloud vendors, and you keep the ability to use each vendor's specific capabilities.

Can HYTE MQ run without Kubernetes?

Yes. The HYTE MQ platform also runs on bare metal and virtual machines. That includes public cloud virtual machines, private data center virtual machines, on-premises bare metal, and IoT embedded compute.

How does HYTE MQ handle scaling and upgrades on Kubernetes?

HYTE MQ configures cluster connectivity during scaling, upgrades, and maintenance. Brokers drain messages to their peers in the cluster during upgrades and scale-down, which keeps messages available. Brokers in the same cluster connect on their own, and the load balancer updates as Kubernetes scales the HYTE MQ cluster up and down.

Can application teams manage their own queues and topics?

Yes. HYTE Console gives application teams secured access to their designated queues and topics, with customized security access and Active Directory and LDAP integration. The same functions are available through a REST API, so teams can automate production tasks and CI/CD work.

Which messaging protocols and client languages does HYTE MQ support?

HYTE MQ is based on Apache ActiveMQ and speaks open, standard messaging protocols: OpenWire with Jakarta Messaging (JMS), AMQP 1.0, MQTT, STOMP, and WebSocket. Application teams connect with standard client libraries in the language they already use, including Java, C#, Python, Go, and JavaScript.

What support does HYTE offer for HYTE MQ on Kubernetes?

HYTE Support comes in around-the-clock and business-hours packages. Every package includes unlimited support cases across all of your ActiveMQ environments, sample code for development questions, architecture reviews with a tenured architect, and quarterly reviews. HYTE supports integration technologies and nothing else, and its engineers commit code upstream to Apache ActiveMQ.

Apache, ActiveMQ, and Apache ActiveMQ are trademarks of The Apache Software Foundation. HYTE is an independent contributor, not affiliated with or endorsed by the ASF. IBM and IBM MQ are trademarks of International Business Machines Corporation. Kubernetes and Helm are registered trademarks of The Linux Foundation. The AWS, Microsoft Azure, Google Cloud, and DigitalOcean names and logos belong to their respective owners and appear here only to identify platforms where HYTE MQ runs. No endorsement is implied.