Get Started

Get Started

These guides demonstrate the operational flexibility and speed of the Hazelcast In-Memory Computing Platform. Set-up in seconds, data in microseconds. Operations and developer friendly.

Hazelcast IMDG

Find out for yourself how to get a Hazelcast IMDG cluster up and running. In this Getting Started guide you’ll learn how to:

  • Create a Cluster of 3 Members.
  • Start the Hazelcast Management Center.
  • Add data to the cluster using a sample client in the language of your choice.
  • Add and remove some cluster members to demonstrate the automatic rebalancing of data and back-ups.

Hazelcast Jet

Learn how to run a distributed data stream processing pipeline in Java. In this Getting Started guide you’ll learn how to:

  • Start a Hazelcast Jet cluster in your JVM.
  • Build the Word Count application.
  • Execute the application wit Jet.
  • Push testing data to the cluster and explore results

As a next step, you will be able explore the code samples and extend your setup more features and connectors.

Announcing the Hazelcast Community License

January 30, 2020

Today, Hazelcast is moving to a three-license software licensing model: 

  1. Apache 2.0 for the core of our systems, consistent with our history
  2. A new source-available Hazelcast Community License
  3. A proprietary license for selected Enterprise operational features, consistent with our history

The license model change will have no impact on users and is only intended to prohibit service wrappers from making the software available as a service.

As an open core software company, our licensing to this point has been Apache 2.0 and a proprietary license for selected Enterprise operational features.  

The licensing change applies on a go-forward basis to Hazelcast IMDG 4.0 and Hazelcast Jet 4.0 and subsequent versions.

Hazelcast Community License

The Hazelcast Community License is identical to the Confluent Community License 1.0, which includes an Excluded Purpose designed to prevent service wrapping. 

“Excluded Purpose” is defined in the license as making available any software-as-a-service, platform-as-a-service, infrastructure-as-a-service or other similar online service that competes with Hazelcast products or services that provide the software.

The software remains open, or source available, in the Hazelcast GitHub repository

The decision to make this change

I have written previously on Hazelcast’s view of open source, which I wrote in response to the introduction of the Commons Clause rider. I was not in favor of it as it was confusing and seemed to try to extend the Apache License while still appearing to be an Apache License. I have also written previously in my essay Open source needs to protect itself from Service Wrappers about the threat posed to the open core business model from service wrapping.

We were largely on the sidelines of this debate as we had not been service wrapped. However, in November 2019, we were notified by one of the cloud providers that they were in the process of service wrapping Hazelcast. 

Over the last two years, the community has become more educated on the threat to the open core business model and come to accept the necessity of these changes, which has prompted these license changes. Moreover, many well-known enterprise open source companies have adopted their own source-available licenses.

I had been hoping that some standard licenses would emerge and was looking to the Open Source Initiative (OSI) for action. Many conversations and email threads later, it is clear that the OSI does not wish to extend the meaning of open source to prevent service wrapping. This is unfortunate as the need is there. Instead, we are facing a proliferation of unique licenses from each open source company, making it harder for users to use open source and creating work for corporate lawyers. So as to not add to the burden on users, with permission from Confluent, our Hazelcast Community License is identical to the Confluent Community License 1.0, with the names changed and the place of arbitration being San Francisco, nearest to our office rather than Santa Clara. Perhaps we will see a new open core standards body emerge.

The move to the cloud

I have had many conversations with customers about their plans for migration to the cloud. For infrastructure software like Hazelcast, the future they hope to get to is to be able to use that infrastructure software in the cloud, but not have to manage it themselves. They want a first-class managed service that is easy and convenient. 

For Hazelcast, they want advanced security and the ability to run multi-zone, multi-region, multi-cloud across vendors, and hybrid with on-premises. 

I have seen it argued that because the open core companies are not providing these managed services, it is left to the cloud providers to do so. That may have once been the case, but not anymore. At Hazelcast, we introduced Hazelcast Cloud Developer in March 2019. This is a simple, single-region version that runs in Kubernetes on shared EC2 instances, and has a free edition. It is great for developers who want to get started quickly on Hazelcast. 

Since then, we have been working on our enterprise version, Hazelcast Cloud Enterprise, which went EA on AWS in December 2019. The chart below shows the features in each.

The point is, we plan to fully service the needs of our customers in the cloud, on the cloud of their choice. 

For customers wishing to do some management themselves, we also offer Docker and Kubernetes helm charts and operators. We also distribute Hazelcast in the enterprise OpenShift and Cloud Foundry PaaS offerings.

We don’t want to succeed in this effort only to find ourselves competing with a cloud provider who has invested zero in the development of the software. We would rather partner with the cloud providers by making an excellent managed service for each of their platforms.

More Information

I have answered questions we foresee in our Hazelcast Community License FAQ. If you have any questions not answered there, please feel free to contact me via Twitter at @gregrluck

About the Author

About the Author

Greg Luck

Greg Luck

Chief Technical Officer

Greg Luck is a leading technology entrepreneur with more than 15 years of experience in high-performance in-memory computing. He is the founder and inventor of Ehcache, a widely used open source Java distributed cache that was acquired by Software AG (Terracotta) in 2009, where he served as CTO. Prior to that, Greg was the Chief Architect at Australian start-up Wotif.com that went public on the Australian Stock Exchange (ASX:WTF) in 2006. Greg is a current member of the Java Community Process (JCP) Executive Committee, and since 2007 has been the Specification Lead for JSR 107 (Java Specification Requests) JCACHE. Greg has a master's degree in Information Technology from Queensland University of Technology and a Bachelor of Commerce from the University of Queensland.

Latest Blogs

Hazelcast IMDG 4.0 is Released

Hazelcast IMDG 4.0 is Released

Redis Load Handling vs Data Integrity: Tradeoffs in Distributed Data Store Design

The One Beam to Rule Them All

The One Beam to Rule Them All

View all blogs by the author
Open Gitter Chat