[DISCUSSION] Renaming Ignite's product category

classic Classic list List threaded Threaded
9 messages Options
dmagda dmagda
Reply | Threaded
Open this post in threaded view
|

[DISCUSSION] Renaming Ignite's product category

Igniters, 

Throughout the history of our project, we could see how the addition of certain features required us to reassess the project's name and category.

Before Ignite joined the ASF, it supported only compute APIs resembling the MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a distributed in-memory computing engine". Next, at the time of the project donation, it already included key-value/SQL/transactional APIs, was used as a distributed cache, and significantly outgrew the "in-memory computing engine" use case. That's how the project transitioned to the product category of in-memory caches and we started to name it as an "in-memory data grid" or "in-memory computing platform" to differentiate from classical caching products such as Memcached and Redis.

Nowadays, the project outgrew its caching use case, and the classification of Ignite as an "in-memory data grid" or "in-memory computing platform" doesn't sound accurate. We rebuilt our storage engine by replacing a typical key-value engine with a B-tree engine that spans across memory and disk tiers. And it's not surprising to see more deployments of Ignite as a database on its own. So, it feels like we need to reconsider Ignite positioning again so that a) application developers can discover it easily via search engines and b) the project can stand out from in-memory projects with intersecting capabilities.

To the point, I'm suggesting to reposition Ignite in one of the following ways:
  1. Ignite is a "distributed X database". We are indeed a distributed partitioned database where X can be "multi-tiered" or "memory-first" to emphasize that we are more than an in-memory database. 
  2. Keep defining Ignite as "an in-memory computing platform" but name our storage engine uniquely as "IgniteDB" to highlight that the platform is powered by a "distributed multi-tiered/memory-first database". 
What is your thinking?


(Also, regardless of a selected name, Ignite still will be used as a cache and grid, and we're not going to stop appealing to those use cases. But those are just use cases while Ignite has to figure out its new identity ... again).
 

-
Denis
vkulichenko vkulichenko
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Renaming Ignite's product category

My vote is for the "distributed memory-first database". It clearly states that Ignite is a database (which is true at this point), while still emphasizing the in-memory computing power endorsed by the platform.

The "in-memory computing platform" is an ambiguous term and doesn't really reflect what Ignite is, especially in its current state.

-Val

On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]> wrote:
Igniters,

Throughout the history of our project, we could see how the addition of
certain features required us to reassess the project's name and category.

Before Ignite joined the ASF, it supported only compute APIs resembling the
MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a
distributed in-memory computing engine". Next, at the time of the project
donation, it already included key-value/SQL/transactional APIs, was used as
a distributed cache, and significantly outgrew the "in-memory computing
engine" use case. That's how the project transitioned to the product
category of in-memory caches and we started to name it as an "in-memory
data grid" or "in-memory computing platform" to differentiate from
classical caching products such as Memcached and Redis.

Nowadays, the project outgrew its caching use case, and the classification
of Ignite as an "in-memory data grid" or "in-memory computing platform"
doesn't sound accurate. We rebuilt our storage engine by replacing a
typical key-value engine with a B-tree engine that spans across memory and
disk tiers. And it's not surprising to see more deployments of Ignite as a
database on its own. So, it feels like we need to reconsider Ignite
positioning again so that a) application developers can discover it easily
via search engines and b) the project can stand out from in-memory projects
with intersecting capabilities.

To the point, I'm suggesting to reposition Ignite in one of the following
ways:

   1. Ignite is a "distributed X database". We are indeed a distributed
   partitioned database where X can be "multi-tiered" or "memory-first" to
   emphasize that we are more than an in-memory database.
   2. Keep defining Ignite as "an in-memory computing platform" but name
   our storage engine uniquely as "IgniteDB" to highlight that the platform is
   powered by a "distributed multi-tiered/memory-first database".

What is your thinking?


(Also, regardless of a selected name, Ignite still will be used as a cache
and grid, and we're not going to stop appealing to those use cases. But
those are just use cases while Ignite has to figure out its new identity
... again).


-
Denis
ptupitsyn ptupitsyn
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Renaming Ignite's product category

Agree with Val, even experienced developers have a hard time understanding
what "in-memory computing platform" really does.

"distributed memory-first database" is right on point.

On Thu, Sep 17, 2020 at 8:30 AM Valentin Kulichenko <[hidden email]> wrote:
My vote is for the "distributed memory-first database". It clearly states
that Ignite is a database (which is true at this point), while still
emphasizing the in-memory computing power endorsed by the platform.

The "in-memory computing platform" is an ambiguous term and doesn't really
reflect what Ignite is, especially in its current state.

-Val

On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]> wrote:

> Igniters,
>
> Throughout the history of our project, we could see how the addition of
> certain features required us to reassess the project's name and category.
>
> Before Ignite joined the ASF, it supported only compute APIs resembling the
> MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a
> distributed in-memory computing engine". Next, at the time of the project
> donation, it already included key-value/SQL/transactional APIs, was used as
> a distributed cache, and significantly outgrew the "in-memory computing
> engine" use case. That's how the project transitioned to the product
> category of in-memory caches and we started to name it as an "in-memory
> data grid" or "in-memory computing platform" to differentiate from
> classical caching products such as Memcached and Redis.
>
> Nowadays, the project outgrew its caching use case, and the classification
> of Ignite as an "in-memory data grid" or "in-memory computing platform"
> doesn't sound accurate. We rebuilt our storage engine by replacing a
> typical key-value engine with a B-tree engine that spans across memory and
> disk tiers. And it's not surprising to see more deployments of Ignite as a
> database on its own. So, it feels like we need to reconsider Ignite
> positioning again so that a) application developers can discover it easily
> via search engines and b) the project can stand out from in-memory projects
> with intersecting capabilities.
>
> To the point, I'm suggesting to reposition Ignite in one of the following
> ways:
>
>    1. Ignite is a "distributed X database". We are indeed a distributed
>    partitioned database where X can be "multi-tiered" or "memory-first" to
>    emphasize that we are more than an in-memory database.
>    2. Keep defining Ignite as "an in-memory computing platform" but name
>    our storage engine uniquely as "IgniteDB" to highlight that the
> platform is
>    powered by a "distributed multi-tiered/memory-first database".
>
> What is your thinking?
>
>
> (Also, regardless of a selected name, Ignite still will be used as a cache
> and grid, and we're not going to stop appealing to those use cases. But
> those are just use cases while Ignite has to figure out its new identity
> ... again).
>
>
> -
> Denis
>
stephendarlington stephendarlington
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Renaming Ignite's product category

In reply to this post by vkulichenko
I think this is a great question. Explaining what Ignite does is always a challenge, so having a useful “tag line” would be very valuable.

I’m not sure what the answer is but I think calling it a “database” devalues all the compute facilities. "Computing platform” may be too vague but it at least says that we do more than “just” store data.

On 17 Sep 2020, at 06:29, Valentin Kulichenko <[hidden email]> wrote:

My vote is for the "distributed memory-first database". It clearly states that Ignite is a database (which is true at this point), while still emphasizing the in-memory computing power endorsed by the platform.

The "in-memory computing platform" is an ambiguous term and doesn't really reflect what Ignite is, especially in its current state.

-Val

On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]> wrote:
Igniters,

Throughout the history of our project, we could see how the addition of
certain features required us to reassess the project's name and category.

Before Ignite joined the ASF, it supported only compute APIs resembling the
MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a
distributed in-memory computing engine". Next, at the time of the project
donation, it already included key-value/SQL/transactional APIs, was used as
a distributed cache, and significantly outgrew the "in-memory computing
engine" use case. That's how the project transitioned to the product
category of in-memory caches and we started to name it as an "in-memory
data grid" or "in-memory computing platform" to differentiate from
classical caching products such as Memcached and Redis.

Nowadays, the project outgrew its caching use case, and the classification
of Ignite as an "in-memory data grid" or "in-memory computing platform"
doesn't sound accurate. We rebuilt our storage engine by replacing a
typical key-value engine with a B-tree engine that spans across memory and
disk tiers. And it's not surprising to see more deployments of Ignite as a
database on its own. So, it feels like we need to reconsider Ignite
positioning again so that a) application developers can discover it easily
via search engines and b) the project can stand out from in-memory projects
with intersecting capabilities.

To the point, I'm suggesting to reposition Ignite in one of the following
ways:

   1. Ignite is a "distributed X database". We are indeed a distributed
   partitioned database where X can be "multi-tiered" or "memory-first" to
   emphasize that we are more than an in-memory database.
   2. Keep defining Ignite as "an in-memory computing platform" but name
   our storage engine uniquely as "IgniteDB" to highlight that the platform is
   powered by a "distributed multi-tiered/memory-first database".

What is your thinking?


(Also, regardless of a selected name, Ignite still will be used as a cache
and grid, and we're not going to stop appealing to those use cases. But
those are just use cases while Ignite has to figure out its new identity
... again).


-
Denis


ggwiebe ggwiebe
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Renaming Ignite's product category

I agree with Stephen about "database" devaluing what Ignite can do (though it probably hits the majority of existing use cases). I tend to go with "massively distributed storage and compute platform"

I know, I didn't take sides, I just have both.

Cheers,
  Glenn

On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <[hidden email]> wrote:
I think this is a great question. Explaining what Ignite does is always a challenge, so having a useful “tag line” would be very valuable.

I’m not sure what the answer is but I think calling it a “database” devalues all the compute facilities. "Computing platform” may be too vague but it at least says that we do more than “just” store data.

On 17 Sep 2020, at 06:29, Valentin Kulichenko <[hidden email]> wrote:

My vote is for the "distributed memory-first database". It clearly states that Ignite is a database (which is true at this point), while still emphasizing the in-memory computing power endorsed by the platform.

The "in-memory computing platform" is an ambiguous term and doesn't really reflect what Ignite is, especially in its current state.

-Val

On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]> wrote:
Igniters,

Throughout the history of our project, we could see how the addition of
certain features required us to reassess the project's name and category.

Before Ignite joined the ASF, it supported only compute APIs resembling the
MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a
distributed in-memory computing engine". Next, at the time of the project
donation, it already included key-value/SQL/transactional APIs, was used as
a distributed cache, and significantly outgrew the "in-memory computing
engine" use case. That's how the project transitioned to the product
category of in-memory caches and we started to name it as an "in-memory
data grid" or "in-memory computing platform" to differentiate from
classical caching products such as Memcached and Redis.

Nowadays, the project outgrew its caching use case, and the classification
of Ignite as an "in-memory data grid" or "in-memory computing platform"
doesn't sound accurate. We rebuilt our storage engine by replacing a
typical key-value engine with a B-tree engine that spans across memory and
disk tiers. And it's not surprising to see more deployments of Ignite as a
database on its own. So, it feels like we need to reconsider Ignite
positioning again so that a) application developers can discover it easily
via search engines and b) the project can stand out from in-memory projects
with intersecting capabilities.

To the point, I'm suggesting to reposition Ignite in one of the following
ways:

   1. Ignite is a "distributed X database". We are indeed a distributed
   partitioned database where X can be "multi-tiered" or "memory-first" to
   emphasize that we are more than an in-memory database.
   2. Keep defining Ignite as "an in-memory computing platform" but name
   our storage engine uniquely as "IgniteDB" to highlight that the platform is
   powered by a "distributed multi-tiered/memory-first database".

What is your thinking?


(Also, regardless of a selected name, Ignite still will be used as a cache
and grid, and we're not going to stop appealing to those use cases. But
those are just use cases while Ignite has to figure out its new identity
... again).


-
Denis


Saikat Maitra Saikat Maitra
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Renaming Ignite's product category

Hi,

My thoughts are similar to as Denis and Val mentioned like Apache Ignite - "A Memory Centric Database".

It aligns to current features of Apache Ignite as mentioned in the below post.


Regards,
Saikat 

On Fri, Sep 18, 2020 at 9:02 AM Carbone, Adam <[hidden email]> wrote:
So when I came across Ignite It was described as an In Memory Data Grid

So one way to look at this is who do you fashion as Ignite competing against?

Are competing against Redis, Aerospike - In Memory Databases

Or are you more competing with

Gigaspaces - True In memory Compute platform

And then you have like of

Hazelcast that started as a Distributed Hash and have gained some features...

On thing that I think is a differentiator that isn't being highlighted but Is  unique feature to Ignited, and the primary reason we ended up here; The integration with spark and it's distributed/shared Datasets/Dataframes.

I don't know for me the In Memory Data Grid I think fits what Ignite is...

Regards

~Adam

Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline Technologies
Office: 603-501-6446 | Mobile: 603-570-8418
www.bottomline.com



On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]> wrote:

    I agree with Stephen about "database" devaluing what Ignite can do (though
    it probably hits the majority of existing use cases). I tend to go with
    "massively distributed storage and compute platform"

    I know, I didn't take sides, I just have both.

    Cheers,
      Glenn

    On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
    [hidden email]> wrote:

    > I think this is a great question. Explaining what Ignite does is always a
    > challenge, so having a useful “tag line” would be very valuable.
    >
    > I’m not sure what the answer is but I think calling it a “database”
    > devalues all the compute facilities. "Computing platform” may be too vague
    > but it at least says that we do more than “just” store data.
    >
    > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
    > [hidden email]> wrote:
    >
    > My vote is for the "distributed memory-first database". It clearly states
    > that Ignite is a database (which is true at this point), while still
    > emphasizing the in-memory computing power endorsed by the platform.
    >
    > The "in-memory computing platform" is an ambiguous term and doesn't really
    > reflect what Ignite is, especially in its current state.
    >
    > -Val
    >
    > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]> wrote:
    >
    >> Igniters,
    >>
    >> Throughout the history of our project, we could see how the addition of
    >> certain features required us to reassess the project's name and category.
    >>
    >> Before Ignite joined the ASF, it supported only compute APIs resembling
    >> the
    >> MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a
    >> distributed in-memory computing engine". Next, at the time of the project
    >> donation, it already included key-value/SQL/transactional APIs, was used
    >> as
    >> a distributed cache, and significantly outgrew the "in-memory computing
    >> engine" use case. That's how the project transitioned to the product
    >> category of in-memory caches and we started to name it as an "in-memory
    >> data grid" or "in-memory computing platform" to differentiate from
    >> classical caching products such as Memcached and Redis.
    >>
    >> Nowadays, the project outgrew its caching use case, and the classification
    >> of Ignite as an "in-memory data grid" or "in-memory computing platform"
    >> doesn't sound accurate. We rebuilt our storage engine by replacing a
    >> typical key-value engine with a B-tree engine that spans across memory and
    >> disk tiers. And it's not surprising to see more deployments of Ignite as a
    >> database on its own. So, it feels like we need to reconsider Ignite
    >> positioning again so that a) application developers can discover it easily
    >> via search engines and b) the project can stand out from in-memory
    >> projects
    >> with intersecting capabilities.
    >>
    >> To the point, I'm suggesting to reposition Ignite in one of the following
    >> ways:
    >>
    >>    1. Ignite is a "distributed X database". We are indeed a distributed
    >>    partitioned database where X can be "multi-tiered" or "memory-first" to
    >>    emphasize that we are more than an in-memory database.
    >>    2. Keep defining Ignite as "an in-memory computing platform" but name
    >>    our storage engine uniquely as "IgniteDB" to highlight that the
    >> platform is
    >>    powered by a "distributed multi-tiered/memory-first database".
    >>
    >> What is your thinking?
    >>
    >>
    >> (Also, regardless of a selected name, Ignite still will be used as a cache
    >> and grid, and we're not going to stop appealing to those use cases. But
    >> those are just use cases while Ignite has to figure out its new identity
    >> ... again).
    >>
    >>
    >> -
    >> Denis
    >>
    >
    >
    >

Nikita Ivanov Nikita Ivanov
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Renaming Ignite's product category

My vote is to just call ignite "IgniteDB". That's it. No other additional explanation is required as no amount of additional verbiage will help. Every DB is different: from MongoDB, to RedisDB, to CockroachDB, to Oracle - they all look & act completely different, and they don't go around trying to explain in one line what they do and how they are different. 

"IgniteDB" is clear, concise and gives us the broadest initial acceptance from the new user perspective. 

Thanks,
--
Nikita Ivanov



On Sat, Sep 19, 2020 at 1:10 PM Saikat Maitra <[hidden email]> wrote:
Hi,

My thoughts are similar to as Denis and Val mentioned like Apache Ignite - "A Memory Centric Database".

It aligns to current features of Apache Ignite as mentioned in the below post.


Regards,
Saikat 

On Fri, Sep 18, 2020 at 9:02 AM Carbone, Adam <[hidden email]> wrote:
So when I came across Ignite It was described as an In Memory Data Grid

So one way to look at this is who do you fashion as Ignite competing against?

Are competing against Redis, Aerospike - In Memory Databases

Or are you more competing with

Gigaspaces - True In memory Compute platform

And then you have like of

Hazelcast that started as a Distributed Hash and have gained some features...

On thing that I think is a differentiator that isn't being highlighted but Is  unique feature to Ignited, and the primary reason we ended up here; The integration with spark and it's distributed/shared Datasets/Dataframes.

I don't know for me the In Memory Data Grid I think fits what Ignite is...

Regards

~Adam

Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline Technologies
Office: 603-501-6446 | Mobile: 603-570-8418
www.bottomline.com



On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]> wrote:

    I agree with Stephen about "database" devaluing what Ignite can do (though
    it probably hits the majority of existing use cases). I tend to go with
    "massively distributed storage and compute platform"

    I know, I didn't take sides, I just have both.

    Cheers,
      Glenn

    On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
    [hidden email]> wrote:

    > I think this is a great question. Explaining what Ignite does is always a
    > challenge, so having a useful “tag line” would be very valuable.
    >
    > I’m not sure what the answer is but I think calling it a “database”
    > devalues all the compute facilities. "Computing platform” may be too vague
    > but it at least says that we do more than “just” store data.
    >
    > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
    > [hidden email]> wrote:
    >
    > My vote is for the "distributed memory-first database". It clearly states
    > that Ignite is a database (which is true at this point), while still
    > emphasizing the in-memory computing power endorsed by the platform.
    >
    > The "in-memory computing platform" is an ambiguous term and doesn't really
    > reflect what Ignite is, especially in its current state.
    >
    > -Val
    >
    > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]> wrote:
    >
    >> Igniters,
    >>
    >> Throughout the history of our project, we could see how the addition of
    >> certain features required us to reassess the project's name and category.
    >>
    >> Before Ignite joined the ASF, it supported only compute APIs resembling
    >> the
    >> MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a
    >> distributed in-memory computing engine". Next, at the time of the project
    >> donation, it already included key-value/SQL/transactional APIs, was used
    >> as
    >> a distributed cache, and significantly outgrew the "in-memory computing
    >> engine" use case. That's how the project transitioned to the product
    >> category of in-memory caches and we started to name it as an "in-memory
    >> data grid" or "in-memory computing platform" to differentiate from
    >> classical caching products such as Memcached and Redis.
    >>
    >> Nowadays, the project outgrew its caching use case, and the classification
    >> of Ignite as an "in-memory data grid" or "in-memory computing platform"
    >> doesn't sound accurate. We rebuilt our storage engine by replacing a
    >> typical key-value engine with a B-tree engine that spans across memory and
    >> disk tiers. And it's not surprising to see more deployments of Ignite as a
    >> database on its own. So, it feels like we need to reconsider Ignite
    >> positioning again so that a) application developers can discover it easily
    >> via search engines and b) the project can stand out from in-memory
    >> projects
    >> with intersecting capabilities.
    >>
    >> To the point, I'm suggesting to reposition Ignite in one of the following
    >> ways:
    >>
    >>    1. Ignite is a "distributed X database". We are indeed a distributed
    >>    partitioned database where X can be "multi-tiered" or "memory-first" to
    >>    emphasize that we are more than an in-memory database.
    >>    2. Keep defining Ignite as "an in-memory computing platform" but name
    >>    our storage engine uniquely as "IgniteDB" to highlight that the
    >> platform is
    >>    powered by a "distributed multi-tiered/memory-first database".
    >>
    >> What is your thinking?
    >>
    >>
    >> (Also, regardless of a selected name, Ignite still will be used as a cache
    >> and grid, and we're not going to stop appealing to those use cases. But
    >> those are just use cases while Ignite has to figure out its new identity
    >> ... again).
    >>
    >>
    >> -
    >> Denis
    >>
    >
    >
    >

dmagda dmagda
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Renaming Ignite's product category

In reply to this post by ggwiebe
Adam,

You defined GigaSpaces as a true in-memory computing platform. What is the true platform for you?


-
Denis


On Fri, Sep 18, 2020 at 7:02 AM Carbone, Adam <[hidden email]> wrote:
So when I came across Ignite It was described as an In Memory Data Grid

So one way to look at this is who do you fashion as Ignite competing against?

Are competing against Redis, Aerospike - In Memory Databases

Or are you more competing with

Gigaspaces - True In memory Compute platform

And then you have like of

Hazelcast that started as a Distributed Hash and have gained some features...

On thing that I think is a differentiator that isn't being highlighted but Is  unique feature to Ignited, and the primary reason we ended up here; The integration with spark and it's distributed/shared Datasets/Dataframes.

I don't know for me the In Memory Data Grid I think fits what Ignite is...

Regards

~Adam

Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline Technologies
Office: 603-501-6446 | Mobile: 603-570-8418
www.bottomline.com



On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]> wrote:

    I agree with Stephen about "database" devaluing what Ignite can do (though
    it probably hits the majority of existing use cases). I tend to go with
    "massively distributed storage and compute platform"

    I know, I didn't take sides, I just have both.

    Cheers,
      Glenn

    On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
    [hidden email]> wrote:

    > I think this is a great question. Explaining what Ignite does is always a
    > challenge, so having a useful “tag line” would be very valuable.
    >
    > I’m not sure what the answer is but I think calling it a “database”
    > devalues all the compute facilities. "Computing platform” may be too vague
    > but it at least says that we do more than “just” store data.
    >
    > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
    > [hidden email]> wrote:
    >
    > My vote is for the "distributed memory-first database". It clearly states
    > that Ignite is a database (which is true at this point), while still
    > emphasizing the in-memory computing power endorsed by the platform.
    >
    > The "in-memory computing platform" is an ambiguous term and doesn't really
    > reflect what Ignite is, especially in its current state.
    >
    > -Val
    >
    > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]> wrote:
    >
    >> Igniters,
    >>
    >> Throughout the history of our project, we could see how the addition of
    >> certain features required us to reassess the project's name and category.
    >>
    >> Before Ignite joined the ASF, it supported only compute APIs resembling
    >> the
    >> MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a
    >> distributed in-memory computing engine". Next, at the time of the project
    >> donation, it already included key-value/SQL/transactional APIs, was used
    >> as
    >> a distributed cache, and significantly outgrew the "in-memory computing
    >> engine" use case. That's how the project transitioned to the product
    >> category of in-memory caches and we started to name it as an "in-memory
    >> data grid" or "in-memory computing platform" to differentiate from
    >> classical caching products such as Memcached and Redis.
    >>
    >> Nowadays, the project outgrew its caching use case, and the classification
    >> of Ignite as an "in-memory data grid" or "in-memory computing platform"
    >> doesn't sound accurate. We rebuilt our storage engine by replacing a
    >> typical key-value engine with a B-tree engine that spans across memory and
    >> disk tiers. And it's not surprising to see more deployments of Ignite as a
    >> database on its own. So, it feels like we need to reconsider Ignite
    >> positioning again so that a) application developers can discover it easily
    >> via search engines and b) the project can stand out from in-memory
    >> projects
    >> with intersecting capabilities.
    >>
    >> To the point, I'm suggesting to reposition Ignite in one of the following
    >> ways:
    >>
    >>    1. Ignite is a "distributed X database". We are indeed a distributed
    >>    partitioned database where X can be "multi-tiered" or "memory-first" to
    >>    emphasize that we are more than an in-memory database.
    >>    2. Keep defining Ignite as "an in-memory computing platform" but name
    >>    our storage engine uniquely as "IgniteDB" to highlight that the
    >> platform is
    >>    powered by a "distributed multi-tiered/memory-first database".
    >>
    >> What is your thinking?
    >>
    >>
    >> (Also, regardless of a selected name, Ignite still will be used as a cache
    >> and grid, and we're not going to stop appealing to those use cases. But
    >> those are just use cases while Ignite has to figure out its new identity
    >> ... again).
    >>
    >>
    >> -
    >> Denis
    >>
    >
    >
    >

dmagda dmagda
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSSION] Renaming Ignite's product category

Adam,

Like your way of thinking. It makes sense to me.

For me, a computing platform comprises two essential components - a storage engine and compute APIs (not only compute grid, but also streaming, SQL, etc.). Under this definition, Ignite fits the "compute platform" category for sure, but the problem (and the reason why I started this discussion thread) is that the "in-memory computing platform" is not a ubiquitous product category. At the same time, we all know that Ignite is used to speed things up by storing and executing in memory. And if you need to make software faster, you usually search for something scalable or in-memory (in-memory caches, in-memory, NoSQL, distributed databases). Basically, most of the folks search for "caches" and "in-memory database" which is related to Ignite and only the tip of the iceberg searches for "in-memory computing platforms" and "data grids".

Btw, how has your story started with Ignite? How did you find out about it?

-
Denis


On Wed, Sep 23, 2020 at 1:24 PM Carbone, Adam <[hidden email]> wrote:

Good Evening Denis,

I’m sure there are more out there as well,  I would consider platforms that the entire applications but that all the execution of code happens exclusively on the platform, and most of the applications are written to run in, not connected to the platform.

Hmmm by this criteria k8s could possible fit the bill…

Spark might even be considered a compute grid as well but it is not a generic compute framework and people don’t usually run there whole applications inside.

What is the vision for the platform? That might help in this discussion, set your category with the direction you are heading, and what you are trying to achieve.

Regards

 

Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline Technologies
Office: 603-501-6446 | Mobile: 603-570-8418
www.bottomline.com

 

 

 

From: Denis Magda <[hidden email]>
Date: Wednesday, September 23, 2020 at 4:14 PM
To: dev <[hidden email]>, "Carbone, Adam" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Subject: Re: [DISCUSSION] Renaming Ignite's product category

 

Adam,

 

You defined GigaSpaces as a true in-memory computing platform. What is the true platform for you?

 


-

Denis

 

 

On Fri, Sep 18, 2020 at 7:02 AM Carbone, Adam <[hidden email]> wrote:

So when I came across Ignite It was described as an In Memory Data Grid

So one way to look at this is who do you fashion as Ignite competing against?

Are competing against Redis, Aerospike - In Memory Databases

Or are you more competing with

Gigaspaces - True In memory Compute platform

And then you have like of

Hazelcast that started as a Distributed Hash and have gained some features...

On thing that I think is a differentiator that isn't being highlighted but Is  unique feature to Ignited, and the primary reason we ended up here; The integration with spark and it's distributed/shared Datasets/Dataframes.

I don't know for me the In Memory Data Grid I think fits what Ignite is...

Regards

~Adam

Adam Carbone | Director of Innovation – Intelligent Platform Team | Bottomline Technologies
Office: 603-501-6446 | Mobile: 603-570-8418
www.bottomline.com



On 9/17/20, 11:45 AM, "Glenn Wiebe" <[hidden email]> wrote:

    I agree with Stephen about "database" devaluing what Ignite can do (though
    it probably hits the majority of existing use cases). I tend to go with
    "massively distributed storage and compute platform"

    I know, I didn't take sides, I just have both.

    Cheers,
      Glenn

    On Thu., Sep. 17, 2020, 7:04 a.m. Stephen Darlington, <
    [hidden email]> wrote:

    > I think this is a great question. Explaining what Ignite does is always a
    > challenge, so having a useful “tag line” would be very valuable.
    >
    > I’m not sure what the answer is but I think calling it a “database”
    > devalues all the compute facilities. "Computing platform” may be too vague
    > but it at least says that we do more than “just” store data.
    >
    > On 17 Sep 2020, at 06:29, Valentin Kulichenko <
    > [hidden email]> wrote:
    >
    > My vote is for the "distributed memory-first database". It clearly states
    > that Ignite is a database (which is true at this point), while still
    > emphasizing the in-memory computing power endorsed by the platform.
    >
    > The "in-memory computing platform" is an ambiguous term and doesn't really
    > reflect what Ignite is, especially in its current state.
    >
    > -Val
    >
    > On Wed, Sep 16, 2020 at 3:53 PM Denis Magda <[hidden email]> wrote:
    >
    >> Igniters,
    >>
    >> Throughout the history of our project, we could see how the addition of
    >> certain features required us to reassess the project's name and category.
    >>
    >> Before Ignite joined the ASF, it supported only compute APIs resembling
    >> the
    >> MapReduce engine of Hadoop. Those days, it was fair to define Ignite as "a
    >> distributed in-memory computing engine". Next, at the time of the project
    >> donation, it already included key-value/SQL/transactional APIs, was used
    >> as
    >> a distributed cache, and significantly outgrew the "in-memory computing
    >> engine" use case. That's how the project transitioned to the product
    >> category of in-memory caches and we started to name it as an "in-memory
    >> data grid" or "in-memory computing platform" to differentiate from
    >> classical caching products such as Memcached and Redis.
    >>
    >> Nowadays, the project outgrew its caching use case, and the classification
    >> of Ignite as an "in-memory data grid" or "in-memory computing platform"
    >> doesn't sound accurate. We rebuilt our storage engine by replacing a
    >> typical key-value engine with a B-tree engine that spans across memory and
    >> disk tiers. And it's not surprising to see more deployments of Ignite as a
    >> database on its own. So, it feels like we need to reconsider Ignite
    >> positioning again so that a) application developers can discover it easily
    >> via search engines and b) the project can stand out from in-memory
    >> projects
    >> with intersecting capabilities.
    >>
    >> To the point, I'm suggesting to reposition Ignite in one of the following
    >> ways:
    >>
    >>    1. Ignite is a "distributed X database". We are indeed a distributed
    >>    partitioned database where X can be "multi-tiered" or "memory-first" to
    >>    emphasize that we are more than an in-memory database.
    >>    2. Keep defining Ignite as "an in-memory computing platform" but name
    >>    our storage engine uniquely as "IgniteDB" to highlight that the
    >> platform is
    >>    powered by a "distributed multi-tiered/memory-first database".
    >>
    >> What is your thinking?
    >>
    >>
    >> (Also, regardless of a selected name, Ignite still will be used as a cache
    >> and grid, and we're not going to stop appealing to those use cases. But
    >> those are just use cases while Ignite has to figure out its new identity
    >> ... again).
    >>
    >>
    >> -
    >> Denis
    >>
    >
    >
    >