Blog ›Hazelcast Deployment Topology Considerations: To Embed or Not?

By Sharath Sahadevan

Senior Solutions Architect

Sharath Sahadevanis a Senior Solutions Architect with Hazelcast.In his role, he educates clients on Hazelcast and helps them be successful in adopting Hazelcast in their applications. He was awarded a patent -Systems and methods for monitoring payment transactions for fraud using social media. He has previously worked for Pivotal ( now acquired by VMware ) and MasterCard.

View all blogs by the author

Jan 5, 2021

Back to Blog

Hazelcast Deployment Topology Considerations: To Embed or Not?

Many thanks to Tom O’Connell who co-authored this blog.

Hazelcast can be deployed in two topologies – namely Embedded and Client-Server. In this blog, we lay out the differences between the two topologies. 

Embedded Architecture: 

Hazelcast is embedded in the application and runs in the same process.

 

Embedded Deployment

 

Client Server Architecture:

 


Client/Server Deployment

 

 

 

 

 

 

 

 

 

 

Item

Embedded

Client-Server

Language Support

Java only. 

Any supported language (Java, Python, go, .Net etc). 

Ease of onboarding and Operations

Easier to adopt and operate. Application and Platform owned by the same team.

App and Platform may be owned by separate teams.

Separation of Concerns

Application and Hazelcast are running in the same JVM.

Optimize the Hazelcast cluster separately. Cluster can be scaled as needed independent of the application.

User Code Deployment

 Since Hazelcast is embedded in the application, all application classes are available.

Application Classes (Runnable, Callable, EntryProcessors) may need to be deployed on the Hazelcast cluster.

N.B. Hazelcast has introduced Generic records ( beta in 4.1 ) that can eliminate the need to deploy domain classes on the client-side.

Number of Applications

Better if only one application is using Hazelcast.

No noisy neighbor issues caused by other applications.

Better if multiple applications are using a shared Hazelcast cluster.

Memory Use

Storage will compete with application objects for Java heap. HD storage lessens reduces impact.

Client JVMs support application object heap consumption.

Scaling
  1. Effective scalability may be limited by our ability to partition the data. 
  2. It is not possible to scale storage and processing separately.
  1. Client data access is location agnostic.
  2. Processing and data scale independently. 

 

Conclusion

We hope this article helps you with your decision on your deployment architecture as you embark on your journey with Hazelcast. 

Keep Reading