[D&M] Add nuance to current comparison points between deployment types

[florent-leborgne]

• This is not a great page ATM and my changes don't make it good either, they just fix a few things
• Table is ugly right now but it does make serverless sound less limited.
• A couple of things were outdated or not exactly true
• Despite the branch name, I actually replaced the "Yes"iz and left Some "No"z because in some cases the difference is rather "you can do it, but it's manual" vs. "it's available but you need to enable it" vs. "it's automatic or we're doing it for you trustme"

I think some capabilities/aspects are missing even though this does a good job of showing that each option is mostly different in the degree of customization/control the user has over what's under the hood

I'm ok with leaving this PR open until we figure out more things or how we actually want to properly showcase these differences.

[leemthompo]

I shouldn't have merged that table 🙈

[florent-leborgne]

There was a page we designed to go in the product at some point and it may have actually become a marketing website page, maybe that would be enough to cover the main differences and orientate users (if i can find it)

[leemthompo]

Already much more useful (I was considering removing the table in meantime)

Feel free to merge or continue iterating 👍

[florent-leborgne]

Found it https://www.elastic.co/cloud/serverless
Maybe we don't need many more comparison points than what's there (we can still add a row for monitoring and another for data management), and might just make slight adjustments to fit the self-managed column in. WDYT @shainaraskas & @leemthompo ?

[leemthompo]

@florent-leborgne I think less is more indeed. The goal is to help readers make a relatively high-level decision about which deployment type might best fit their needs, and for them to investigate first, not an exhaustive cross-comparison.

[shainaraskas]

Found it elastic.co/cloud/serverless
Maybe we don't need many more comparison points than what's there (we can still add a row for monitoring and another for data management), and might just make slight adjustments to fit the self-managed column in. WDYT @shainaraskas & @leemthompo ?

:2c: that marketing page and these docs serve a different audience. In this case, I think granularity is a huge benefit to help orient users and give them clarity on what works in what context.

Sounds like we could pull some more info from that comparison table, but if you were considering cutting down to match this table I screenshotted, I think we'd be making it harder on our readers.

Edit: thought about this more and am disagreeing with myself a little. especially because they have this nice serverless roadmap now

[shainaraskas]

I'm cool with merging and iterating (don't reco leaving it open - just send it into the world)

added some comments re: things I think might be slightly incorrect or that we could zsuzh with links to make serverless support even clearer

[florent-leborgne]

Edit: thought about this more and am disagreeing with myself a little.

😂 yeah I think I went through the same steps. With this kind of docs, we must either be kind of exhaustive (which is far from being the case here + remember to maintain it weekly), or summarize just the key differences so that users have a good understanding of which one can best serve their needs. (degree of control over hosting and perf+cost related elements, security, maintenance effort needed, ability to customize, pricing model, and of course feature scope). I believe something closer to the latter might be a clearer start. I'll merge as is and think about it more.

[leemthompo]

Thanks for jumping on this @florent-leborgne