My first thought: "introducing? The S2 has been out for a while!" https://www.sunlu.com/products/new-version-sunlu-filadryer-s...
Google had it years ago!
http://s2geometry.io/devguide/s2cell_hierarchy
Introducing S2
61–70 of 206 posts
Re: Introducing S2
#62Earlier quoted context omitted.
(Founder) well 50% of our name is different
You should have gone with S4 tbh. The suits love bigger numbers. Super Simple Stream Store.
http://www.supersimplestorageservice.com/ exists and calls itself S4. It's a decent gag and the immediately came to mind when I heard S2 vs S3.
Re: Introducing S2
#63Earlier quoted context omitted.
You should have gone with S4 tbh. The suits love bigger numbers. Super Simple Stream Store.
(Founder) I have definitely received that advice before :) - to not seem like a regression from S3. But as an abbreviation for Stream Store, it made sense.
Why not just use SS? There can’t possibly be any negative connotations there.
Re: Introducing S2
#64These folks knowingly chose to spend the rest of their careers explaining that they are not, in fact, S3.
(Founder) well 50% of our name is different
I like it. I see it as ostensibly a product for engineers and so when I see a name like S2 it's immediately clear that it's a product led and conceived by engineers.
I also see that on your pricing page -
"We are building the S3 experience for streaming data, and that includes pricing transparency"
Love the simple and earnest copy. One can imagine what an LLM would cook up instead, I find the brevity way preferable.
Re: Introducing S2
#65It looks neat but, no Java SDK? Every company I've personally worked at is deeply reliant on Spring or the vanilla clients to produce/consume to Kafka 90% of the time. This kind of precludes even a casual PoC.
(S2 Team member) As we move forward, a Java/Kotlin and a Python SDK are on our list. There is a Rust sdk and a CLI available (https://s2.dev/docs/quickstart) . Rust felt as a good starting point for us as our core service is also written in it.
Re: Introducing S2
#66This is a very useful service model, but I'm confused about the value proposition given how every write is persisted to S3 before being acknowledged. I suppose the writers could batch a group of records before writing them out as a larger blob, with background processes performing compaction, but it's still an object-backed streaming service, right? AWS has shown their willingness to implement mostly-protocol compati…
(S2 team member here)
> I suppose the writers could batch a group of records before writing them out as a larger blob, with background processes performing compaction, but it's still an object-backed streaming service, right?
This is how it works essentially, yes. Architecting the system so that chunks that are written to object storage (before we acknowledge a write) are multi-tenant, and contain records from different streams, lets us write frequently while still targeting ideal (w/r/t price and performance) blob sizes for S3 standard and express puts respectively.
Re: Introducing S2
#67Earlier quoted context omitted.
(Founder) I have definitely received that advice before :) - to not seem like a regression from S3. But as an abbreviation for Stream Store, it made sense.
Why not just use SS? There can’t possibly be any negative connotations there.
Reserved by GM for the Super Sport
Re: Introducing S2
#68Earlier quoted context omitted.
(Founder) I have definitely received that advice before :) - to not seem like a regression from S3. But as an abbreviation for Stream Store, it made sense.
Why not just use SS? There can’t possibly be any negative connotations there.
You could even make the s look kind of like a lightning bolt to emphasize how fast it is
Re: Introducing S2
#69Earlier quoted context omitted.
(Founder) We are not charging in preview. At the scale where it matters, we will work it out. Definitely some assumptions in here.
Just FYI, that doesn't give me confidence in the longevity of your service.
(Founder) I understand the concern. However, cloud discounts at scale can be very large, and we are going to share as much of it as we reasonably can.
Re: Introducing S2
#70I wish more dev-tools startups would focus on clearly explaining the business use cases, targeting a slightly broader audience beyond highly technical users. I visited several pages on the site before eventually giving up. I can sort of grasp what the S2 team is aiming to achieve, but it feels like I’m forced to perform unnecessary mental gymnastics to connect their platform with the specific problems it can solve fo…
(Founder) Appreciate the feedback. We will try to do a better job on the messaging. It is geared at being a building block for data systems. The landing page has a section talking about some of the patterns it enables (Decouple / Buffer / Journal) in a serverless manner, with example use cases. It just may not be something that resonates with you though! We are interested in adoption by developers for now.
I think they're saying that you should provide some example use-cases for how someone would use your service. High-level use-cases that involve solving problems for a business.
For what it's worth, I am already familiar with this design space well enough that I don't need this kind of example in order to understand it. I've worked with Kinesis and other streaming systems before. But for people who haven't, an example might help.
What kind of business problem would someone have that causes them to turn to your service? What are the alternative solutions they might consider and how do those compare to yours? That's the kind of info they're asking for. You might benefit from pitching this such that people will understand it who have never considered streaming solutions before and don't understand the benefits. Pitch it to people who don't even realize they need this.