There are several ways you can deploy Solace PubSub+ container image, and it can be somewhat confusing when trying to select the correct approach to satisfy your short-term (trial or dev) needs, meet all of your long-term (production) requirements, and fit as well as possible into your existing deployment environments.
That’s because your needs and requirements might not be best met by your existing deployment environment. This can be because your container deployment environments may not be best suited for long term deployment of stateful infrastructure, like databases of event routing infrastructure. If that is the case you might need to decide whether to invest in a more suitable deployment model or augment the existing model to meet your long-term needs.
Keep in mind that the best solution for container deployment might be “none of the above” and a managed service via Solace Cloud might be the best fit for evaluation or even production deployment. And for some use cases, Solace PubSub+ Event Broker Appliance might be the best fit for performance, reliability and cost of ownership reasons.
After considering the options of Solace Cloud and Event Broker Appliance, the next step is to briefly explore the options for deploying Solace PubSub+ Event Broker software and the pros and cons of each approach.
Solace provides a series machine image formats for private or on-prem installation, VHD for Microsoft Hyper-V installs, OVA for VMWare installs; as well as a public cloud AWS EC2 image.
These images provide a very simple install of a Solace PubSub+ software broker with all container requirements and dependencies well thought through. The ease of install makes these a great option if you already have the required infrastructure to run, VMWare ESXi server or AWS account for example.
This approach provides a single non fault tolerant broker and possibly a single point of failure disk. So, it is very good as-is for trials and development and can be used as a foundational building block for production deployments. Keeping in mind that operationalization for day one, (make fault tolerant), and day two, (monitor, upgrade), activities will need to be implemented. Since adding things like logging or monitoring agents into the base OS or inside the container is not supported, this can however be challenging.
The machine image described above contains a Linux container image that can be directly deployed into a container runtime, (Docker, PodMan).
This option has many of the same characteristics of a machine image install; great option if infrastructure exists for test and development but challenging for productization. The advantage of installing containers is that it is lighter weight infrastructure and you can build up the base OS as you require,(as long as container requirements are met), this means you can add in you logging and monitoring agents etc. as you see fit.
Like the previously described machine images, this solution provides broker instances but does not solve the operational day one and day two requirements of being highly available and does not provide a full solution for upgrades. Additional management tooling would need to be purchased or built to bring container images to production.
Created to exemplify fault tolerant solutions in AWS CloudFormation Quickstart, Azure ARM Quickstart, GCP Quickstart, and Docker Compose example where created using the Solace PubSub+ event broker container image. This allows selection of custom base images for monitoring, logging, certificate injection, as well as disk and broker fault tolerance.
This solution is good as-is for more robust UAT testing or small production deployments where the limitations can be handled manually.
But, with is solution day two activities would still need to be integrated into Solace publicly available opensource quickstarts.
Created to exemplify lifecycle managed solution in Kubernetes.
Beyond being fault tolerant, the solution Kubernetes provides self-healing, in that failed infrastructure will be re-created and added back into the cluster. Upgrades are also gracefully handled. Kubernetes logging and monitoring are integrated with ability to track active broker and ability to monitor and restart stalled containers.
Though the solution is highly tunable there is still requirement to integrate things like certificate management which is custom to each deployment. This solution is good for situations where developers need to deploy infrastructure as code and are allowed to define exactly what that infrastructure looks like.
Created to exemplify corporate controlled deployments into Kubernetes.
The operator provided allows a central management team to predetermine what a Solace PubSub+ Event Broker will consist of and offer that solution to the users of the Kubernetes cluster in a versioned and controlled manor. The teams that use the Solace broker can deploy a complete broker-based solution as they would any other Kubernetes resource.
This solution may be too incombered for people that manage there own Kubernetes cluster, either themselves or through public cloud providers, for things like development and other non production use cases.
This reference table shows which deployment solution is the best for which use case.
|Use Case||Description||Deployment Option|
|Try before buy, |
|Docker Container Runtime or Public cloud account||AWS EC2 Machine Image|
Hyper-V Machine Image
VMWare Machine Image
|Slightly more sophisticated Cloud development, UAT||Fault tolerant||AWS Container Image Quickstart Azure Container Image Quickstart|
GCP Container Image Quickstart
|Dev/Ops in production Developers deploy infrastructure they need||Self-healing, Upgradable, Any K8s Env||VMWare Tanzu/PKS|
|Centralized corporate ownership of infrastructure deploy approved solutions||Build infrastructure based on version controlled, compossible resources. Exposed to dev teams. K8s||Solace Operator|
Ken Barr is a Senior Product Integration Architect working with the Solace CTO group. He's focused on exploring areas in which our customers would benefit from Solace innovation, then defining how these new technologies fit into Solace’s product lines.
Prior to joining Solace, Ken was a Technical Lead at Cisco Systems holding several roles in carrier core routing business units including QA team lead for initial implementations of IPv6 and bringing next generation IOS called IOS-XR to the core routing platforms. Preceding Cisco, Ken was a Communications Electronics Engineering Officer for the Royal Canadian Air Force responsible for operational management of the National Defence Headquarters Metropolitan Area Network.[position] => [url] => https://solace.com/blog/author/ken-barr/ ) )