Add links to Spring Boot for Apache Geode to the reference documentation

[philwebb]

This section of the docs has a link to GemFire and Geode but we don't have an actual dedicated section describing it like we do with the others. Since it's a Spring project, we should add a paragraph with a description and link to the relevant project docs.

[jxblum]

Hi @philwebb and Spring Boot team-

Thank you for creating this ticket to clarify Spring Boot's position on GemFire/Geode.

To start with, and to make this even easier, we don't need to mention ("VMware Tanzu"; previously "Pivotal") GemFire any longer. In short, dedicated Spring bits are exclusively based on and focused towards OSS, Apache Geode now.

Reasons for this include, but are not limited to:

1. GemFire diverged from Apache Geode - There are no standalone GemFire releases matching the latest Apache Geode releases currently, e.g. Apache Geode 1.13.7 and 1.14.3. GemFire 9.10.x (latest) was last based on Apache Geode 1.12. I used this event as an opportunity for a clean break and separation.

2. GemFire does not have a compatible license - GemFire is commercially licensed by VMware while Apache Geode uses the Apache 2 License the same as the corresponding Spring bits.

3. GemFire is not available in Maven Central; Apache Geode is (here).

While #1 might be surprising,#2 and #3 are not, as we have discussed in the past.

The main problem I have is, users, customers, and even internal VMW field engineers alike, all have trouble knowing where to start and finding relevant information on Spring Boot's support for Apache Geode.

I have made strides in this area over the years, but I find myself having to repeat myself, a lot.

While Google searches (for example) reveal some artifacts of Spring Boot for Apache Geode (SBDG), search terms have to be deliberate and precise (arguably an SEO problem).

Unfortunately, SBDG does not have a dedicated project page on spring.io/projects, or specifically, here, despite being a proper Spring project.

However, I have tried to mirror my SBDG GitHub project page (README) as closely as possible to project pages on spring.io. This includes things like an opening description, Features, Learn, Getting Started, Getting Started with Spring Initializer even, to including an example starter app and references back to Spring Boot's project site along with a Wiki page discussing version compatibility across the Spring projects on which SBDG is based (see here, specifically).

Most users and customers I talk to all start at spring.io and Spring Boot's documentation, and specifically, here, to try and find relevant information.

I always communicate to users and customers alike that Spring Boot documentation is deliberately vague, but precise, encouraging users to "drill down" into the relevant documentation for the projects that "owns the code" as @wilkinsona has stated, and I whole heartedly agree.

For Spring developers using Apache Geode, like much of the Spring portfolio of projects, I want users to start with Spring Boot. I don't want them specifically looking at Spring Data for Apache Geode (SDG) unless they absolutely need to. This has been a point of confusion. "Do I start with SDG and use explicit, declarative Annotation/Java based configuration or do I use Spring Boot?" - said nearly every single user I have encountered, and my answer is always, "Spring Boot, of course!".

By way of example, if users are only using Apache Geode as a caching provider in the core Spring Framework's Cache Abstraction, then Spring Data (access) is irrelevant. If users are using Apache Geode for event/streaming or distributed compute use cases, then Spring Data is mostly irrelevant. SBDG has first-class, built-in auto-configuration support for most of Apache Geode's features, including data access with Spring Data [for Apache Geode]. All of this can be seen in the various "chapters" from SBDG's documentation. In all cases, start with Spring Boot [for Apache Geode].

While I am very depth-oriented (I like to know how the engine runs), most users, for the sake of time, are very breadth-oriented and want to cover a lot of ground, quickly.

SBDG is a culmination of Spring Data for Apache Geode (SDG; and foundation), Spring Session for Apache Geode (SSDG) and Spring Test for Apache Geode (STDG), pulling all the bits together into a cohesive whole, helping users use the project successfully, either individually or together.

SBDG should not be confused with Spring Data as SBDG and SDG's concerns are very different, i.e. convention over configuration using auto-configuration vs. data access concerns.

SBDG's documentation will then be responsible for "drilling down" in to the relevant docs from SDG, SSDG and STDG including Spring Boot docs, and Spring Data Commons docs, and Spring Session core docs, and Spring Framework docs, as appropriate, even Apache Geode docs. I can even cover (and do) explain the difference from Apache Geode to VMware Tanzu GemFire, so Spring Boot itself does not need to.

I hope all of this makes sense, and specifically my reasons for linking Spring Boot to SBDG. I want to make things easier to find, ultimately, and help uses help themselves.

Happy to discuss more as needed.

Regards,
@jxblum

[jxblum]

To be fully transparent, VMware is planning to release standalone versions of VMware Tanzu GemFire again, as of 9.15, which will be based on Apache Geode 1.15.

The Spring team has no intention of owning the Spring bits based on and dedicated to GemFire for the reasons cited above (1-3). Like other commercial and/or community driven projects (e.g. Hazelcast), the VMware engineering org will "own" Spring Data for VMware Tanzu GemFire.

From a Spring perspective, we will view and treat this effort (Spring Data for VMware TanzuGemFire) as a community, or rather commercially led project, releasing independently from the rest of Spring Data since another reason includes, GemFire has very different support lifecycles (driven by contracts) from the rest of Spring.

In addition to above, this is also why OSS Spring bits for Apache Geode will be exclusively tied to OSS Apache Geode.

Regards,
@jxblum