Updated March 2024

In this article we discuss the misconception that managed Pulsar services need to be hosted on a third party platform to ensure stability and high performance.  And we outline the important components that are missing from third party hosted Pulsar, along with increased security risk.

With hosted Pulsar you lose control over how many people have access to your data. And you are unprotected against the hosting company changing its security practices.

Fully managed Pulsar services, hosted directly in your internal environment (AWS, Azure, GCP, or on-prem), still ensures the peace of mind that comes from third party hosted Pulsar without the loss in data ownership, speed, and data security. Learn about managed Pulsar in your environment.

Pros & Cons of Hosted Pulsar

A commonly held misconception is that hosting on a third party’s environment will give that third party greater authority over ensuring uptime. This simply isn’t true.

The idea that hosted Pulsar leads to better uptime falls apart for two reasons.  

Firstly, maximizing Pulsar uptime has more to do with good communication between the service provider and the customer than any other factor.  

For instance, staying informed about current and projected business and technical needs allows a good service provider to anticipate changes that need to be made to the Pulsar deployment. 

Additionally, having comprehensive monitoring in place to review Pulsar and operating system performance 24/7 provides critical insight into increased demand and maintenance needs. Neither of these factors are dependent on Pulsar being hosted by a third party.  

Secondly, a service provider can comprehensively manage Pulsar as a service in your environment (cloud or on-prem). This requires limited access to your architecture.

Companies with the most sensitive use cases – such as healthcare, government contractors, and financial institutions – prefer this approach because it increases the security of their data while still providing fully managed Apache Pulsar.

Limitations of Hosted Pulsar

When you hand over Apache Pulsar hosting to a third party, you are inherently compromising on four critical factors:  speed, data authority / data security, ownership, and pricing.

Speed:  Allowing a provider to host your Pulsar implementation in their cloud introduces unnecessary latency. In contrast, building Pulsar alongside your infrastructure reduces latency.

Security: With Pulsar hosted on a third party’s cloud, your data is exposed to additional risk for breach. You lose control over how many people have access to your data. And you are unprotected against the hosting company changing its security practices.

Ownership:  When locked into a vendor it’s difficult and costly to change how you manage Pulsar. Additionally, you are subject to their limitations, such as which versions of Pulsar are supported.

Pricing:  By hosting your Apache Pulsar service in their environment, hosted Pulsar can charge you more in cloud fees because the host provider is incentivized to increase cloud costs and over-build your cluster.

Managed Pulsar in Your Environment

Fully managed Apache Pulsar in your environment (AWS, Azure, GCP, or on-prem) looks much the same as hosted Apache Pulsar.  You still get all of the benefits of a hosted solution, including:

  • Apache Pulsar platform built by an expert Pulsar engineer
  • 24/7 monitoring, alerting, and help desk
  • Uptime guarantees

In addition, Dattell’s Pulsar service includes critical elements often omitted by third party hosted Pulsar:

  • Manual optimization of your implementation for your specific use case
  • Training for your staff
  • Preventative maintenance of your cluster(s) to ensure uptime and avoid disruption of service
  • Meet all of your security goals, including authorization, authentication, and encryption

Discover more from

Subscribe now to keep reading and get access to the full archive.

Continue reading

Scroll to Top