13 ms·
Introducing S2
- tdba 2y agoIs it possible to bring my own cloud account to provide the underlying S3 storage?
- shikhar 2y ago(Founder) Not currently! We want to explore this.
- ms7892 2y agoCan someone tell me what does this do? And why its better.
- moralestapia 2y agoIt's a message queue on the cloud. https://chatgpt.com/c/676703d4-7bc8-8003-9e5d-d6a402050439 https://chatgpt.com/c/676703d4-7bc8-8003-9e5d-d6a402050439 Edit: Keep downvoting, only 5.6k to go!
- ms7892 2y agoThank you
- alanfranz 2y agoSort of serverless Kafka, which natively uses object storage and promises better latencies than things like warpstream.
- ivankelly 2y agoA interesting difference is the ability to have exclusive access to writes on the log (the fencing token). This allows you to use the logs as write ahead logs.
- shikhar 2y ago(Founder) There is a table on the landing page https://s2.dev/ https://s2.dev/ which hopefully gives a nice overview :) It's like S3, but for streams. Cheap appends, and instead of dealing with blocks of data and byte ranges, you work with records. S2 takes care of ordering records, and letting you read from anywhere in the stream. This is an alternative to systems like Kafka which don't do great at giving a serverless experience.
- stogot 2y agoCould you clarify the Kafka difference further? Or more generally, when is it better to choose S2 vs services like SQS or Kinesis? S2 sounds like an ordered queue to me, but those exist?
- shikhar 2y ago(Founder here) Managed cloud offerings for streaming limit ordered throughput pretty low, e.g. Kinesis at 1 MiBps, Redpanda serverless at 1 MiBps, Confluent's even higher-end clusters at 10-20 MiBps IIRC. If you really need ordering, this can indeed be a limit. S2 lets you push 125 MiBps currently, and we may grow that. Another factor is how many ordered streams you can have. Typically a few thousand at most with those systems. We take the serverless spirit of S3 here, when did you have to worry about the number of objects in a bucket? We are also able to offer latency comparable to disk-based streaming like Confluent's Kora and Kinesis, with our Express storage class (under 50 milliseconds end-to-end latency for client in the same cloud region) - while being backed by S3 with regional durability! Not a disk in the system. We want people to be able to build safe distributed data systems on top of S2, so we also allow concurrency control mechanisms on the stream like fencing. Kafka or Kinesis won't let you do that. This is the approach AWS takes internally (https://brooker.co.za/blog/2024/04/25/memorydb.html https://brooker.co.za/blog/2024/04/25/memorydb.html), but they don't have that as a service. We want to democratize the pattern. ED: on throughtputs, to clarify, I am talking about ordered throughput, i.e. per Kafka partition or Kinesis shard. WarpStream also does well here because of their architectural approach to separate ordering, but at a latency cost.
- 2y ago
- deleted 2y ago[deleted]
- jcmfernandes 2y agoIn the long-term, how different do you want to be from Apache Pulsar? At the moment, many differences are obvious, e.g., Pulsar offers transactions, queues and durable timers.
- shikhar 2y ago(Founder) We want S2 to be focussed on the stream primitive (log if you prefer). There is a lot that can be built on top, which we mostly want to do as open source layers. For example, Kafka compatibility, or queue semantics.
- durkie 2y ago[flagged]
- shikhar 2y agoIndeed... we sure wish we could have nabbed that crate name, but it was not to be. Our Rust SDK is here https://lib.rs/crates/streamstore https://lib.rs/crates/streamstore
- ISV_Damocles 2y agoReplying to this one since you apparently can't reply to a comment that has been flagged. Why was the grandparent flagged? Google's S2 library has been around for more than a decade and is the first thing I think of when I see "S2" in a tech stack. And the flippant response from the parent here that they don't really care that they're muddying the waters and just want the crate name is irksome.
- deleted 2y ago[deleted]
- iambateman 2y agoThese folks knowingly chose to spend the rest of their careers explaining that they are not, in fact, S3.
- shikhar 2y ago(Founder) well 50% of our name is different
- ozim 2y agoI would look much more into Levenshtein Distance ;) if I would like to be smart ass funny.
- do_not_redeem 2y agoYou should have gone with S4 tbh. The suits love bigger numbers. Super Simple Stream Store.
- shikhar 2y ago(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.
- solatic 2y agoHelp me understand - you build on top of AWS, which charges $0.09/GB for egress to the Internet, yet you're charging $0.05/GB for egress to the Internet? Sounds like you're subsidizing egress from AWS? Or do you have access to non-public egress pricing?
- nfm 2y agoList pricing is $0.05 per GB after 150TB and at high volume it’s cheaper than that
- shikhar 2y ago(Founder) We are not charging in preview. At the scale where it matters, we will work it out. Definitely some assumptions in here.
- 8n4vidtmkvmk 2y agoJust FYI, that doesn't give me confidence in the longevity of your service.
- shikhar 2y ago(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.
- everfrustrated 2y agoDiscounts require multi year commitment for minimum (and increasing) spend. Generally you need to be either profitable or a well funded startup to demonstrate why a vendor would trust your ability to pay (it's literally a debt on your books). How do they know you're good for it? Plus multi cloud means less scale and less marketing incentive (can't talk about you as a x cloud customer). I wish you the best, but would encourage you to not set your prices below your costs.
- bushido 2y agoI 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 for a business or product team. I consider myself fairly technical and familiar with many of the underlying concepts, but I still couldn’t work out the practical utility without significant effort. It’s worth noting that much of technology adoption is driven by technical product managers and similar stakeholders. However, I feel this critical audience is often overlooked in the messaging and positioning of developer tools like this.
- shikhar 2y ago(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.
- deleted 2y ago[deleted]
- jcrites 2y agoI 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.
- revskill 2y agoServerless pricing to me is exactly like the ETH gas pricing !
- behnamoh 2y agoso the naming convention for 2024-25 products seems to be <letter><number>. o1, o3, s2, M4, r2, ...
- masterj 2y agoSo is this basically WarpStream except providing a lower-level API instead of jumping straight to Kafka compatibility? An S3-level primitive API for streaming seems really valuable in the long-term if adopted
- shikhar 2y ago(Founder) That somewhat summarizes yes :) We take a different approach than WarpStream architecturally too, which allows us to offer much lower latencies. No disks in our system, either.
- adverbly 2y agoSeems really good for IoT no? Been a while since I worked in that space, but having something like this would have been nice at the time.
- shikhar 2y ago(Founder) so many possibilities! That's what I love about building building blocks. I think we will create an open source layer for an IoT protocol over time (unless community gets to it first), e.g. MQTT. I have to admit I don't know too much about the space.
- BaculumMeumEst 2y agoS2 is, in my opinion, the sweet spot of PRS's lineup.
- veqq 2y agoRelated to an old comment of yours: > I also kind of strongly dislike HtDP. I'm researching programming pedagogy and I'm curious about your thoughts on this.
- h05sz487b 2y agoJust you wait, I am launching S1 next year!
- graypegg 2y agoOk good, my startup S½ (also known as Ç) is still unique, phew
- andrethegiant 2y agoDibs on S0
- why-el 2y agoyour incident lingo will be fun.
- johnrob 2y agoThis is a very interesting abstraction (and service). I can’t help but feature creep and ask for something like Athena, which runs PrestoDB (map reduce) over S3 files. It could be superior in theory because anyone using that pattern must shoehorn their data stream (almost everything is really a stream) into an S3 file system. Fragmentation and file packing become requirements that degrade transactional qualities.
- shikhar 2y ago(Founder) There are definitely some interesting possibilities. Pretty hyped about S3 Table (Iceberg) buckets. S2 stream to buffer small writes so you can flush decent size Parquet into the table, and avoid compaction costs.
- Scaevolus 2y agoThis 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 compatible services (RDS -> Aurora), and I could see them doing the same with a Kafka reimplementation.
- sensodine 2y ago(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.
- philjohn 2y agoWait, data from multiple tenants is stored in the same place. Do you have per-tenant encryption key, or how else are you ensuring no bugs allow tenants to read others data?
- shikhar 2y ago(Founder) We will be using authenticated encryption with per-basin (our term for bucket) or per-stream keys, but we don't have this yet. This is noted on https://s2.dev/docs/security#encryption https://s2.dev/docs/security#encryption
- kdazzle 2y agoWould this be like an alternative to Delta? Am I thinking about that right?
- ComputerGuru 2y agoSo is this a "serverless" named-pipe-as-a-service cloud offering? Or am I misreading?
- pram 2y agoIt 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.
- infiniteregrets 2y ago(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 https://s2.dev/docs/quickstart) . Rust felt as a good starting point for us as our core service is also written in it.
- mdaniel 2y agoMerely as a "for your consideration," writing an SDK in a very, very different language can surface "rust-isms" in the way your API works that might not be obvious when using a homogeneous tech stack I think of that as the "Chinese wall" of shipping SDKs: can someone not familiar with your product use it effectively from a language you don't know
- _1tem 2y agoThis is a really good idea, beautiful API, and something that I would like to use for my projects. However I have zero confidence that this startup would last very long in its current form. If it's successful, AWS will build a better and cheaper in-house version. It's just as likely to fail to get traction. If this had been released instead as a Papertrail-like end-user product with dashboards, etc. instead of a "cloud primitive" API so closely tied to AWS, it would make a lot more sense. Add the ability to bring my own S3-Compatible backend (such as Digital Ocean Spaces), and boom, you have a fantastic, durable, cloud-agnostic product.
- shikhar 2y ago(Founder) we do intend to be multi-cloud, we are just starting with AWS. Our internal architecture is not tied to AWS, it's interfaces that we can implement for other cloud systems.
- qudat 2y agoPeople keep making the same argument against Aptible (https://aptible.com https://aptible.com) and it is still a very successful PaaS over a decade later.
- joshstrange 2y agoI had never heard of this company so I took a look and the main pitch was compelling and then I went to the pricing page and saw the pricing goes from $0 to $500 a month once you want to go to “production”. i’m clearly not the target market, which makes sense why I’ve never heard it.
- paulddraper 2y agoIt’s popular for security sensitive (e.g. healthcare) stuff
- throwaway519 2y agoAmazon don't compete for price sensitive product offerings. If anything, they normlise an expectation with a budget aware base.
- bdcravens 2y agoMy first thought: "introducing? The S2 has been out for a while!" https://www.sunlu.com/products/new-version-sunlu-filadryer-s2 https://www.sunlu.com/products/new-version-sunlu-filadryer-s...
- 01HNNWZ0MV43FF 2y agoGoogle had it years ago! http://s2geometry.io/devguide/s2cell_hierarchy http://s2geometry.io/devguide/s2cell_hierarchy
- karmakaze 2y agoI do like this. The next part I'd like someone to build on top of this is applying the stream 'events' into a point-in-time queryable representation. Basically the other part to make it a Datatomic. Probably better if it's a pattern or framework for making specific in-memory queryable data rather than a particular database. There's lots of ways this could work, like applying to a local Sqlite, or basing on a MySQL binlog that can be applied to a local query instance and rewindable to specific points, or more application-specific apply/undo events to a local state.
- bawolff 2y agoIn terms of a pitch, i'm not sure i understand how this differs from existing solutions. Is the core value proposition a simpler api?
- shikhar 2y ago(Founder) Besides simple API, - Unlimited streams. Current cloud systems limit to a few thousand. With dedicated clusters, few hundred K? If you want a stream per user, you are now dealing with multiple clusters. - Elastic throughput per stream (i.e. a partition in Kafka) to 125 MiBps append / 500 MiBps realtime read / unlimited in aggregate for catching up. Current systems will have you at tens. And we may grow that limit yet. We are able to live migrate streams in milliseconds while keeping pipelined writes flowing, which gives us a lot of flexibility. - Concurrency control mechanisms (https://s2.dev/docs/stream#concurrency-control https://s2.dev/docs/stream#concurrency-control)
- shikhar 2y agoForgot to mention storage classes to tune your latency vs cost tradeoff. That you can even reconfigure - soon we will make that a live migration.
- siliconc0w 2y agoDefinitely a useful API but not super compelling until I could store the data in my own bucket
- unsnap_biceps 2y agoI really liked the landing page and the service, but it took me a while to realize it wasn't a AWS service with a snazzy landing page.
- aorloff 2y agoKafka as a service ?
- shikhar 2y ago(Founder) Nope! We have a FAQ for this ;)
- evantbyrne 2y agoSeems like really cool tech. Such a bummer that the it is not source available. I might be a minority in this opinion, but I would absolutely consider commercial services where the core tech is all released under something like a FSL with fully supported self-hosting. Otherwise, the lock-in vs something like kafka is hard to justify.
- shikhar 2y ago(Founder) We are happy for S2 API to have alternate implementations, we are considering an in-memory emulator to open source ourselves. It is not a very complicated API. If you would prefer to stick with the Kafka API but benefit from features like S2's storage classes or having a very large number of topics/partitions or high throughput per partition, we are planning an open source Kafka compatibility layer that can be self-hosted, with features like client-side encryption so you can have even more peace of mind.
- evantbyrne 2y agoFirst-class kafka compatibility could go a long way to making it a justifiable tech choice. When orgs go heavy on event streaming, that code gets _everywhere_, so a vendor off-ramp is needed.
- shikhar 2y ago(Founder) That makes sense. We would eventually host the Kafka layer too - and will be able to avoid a hop by inlining our edge service logic in there.
- rswail 2y agoHaving a kafka compatible API and S3 storage would be something I would jump to, the savings over MSK would be huge. If you had a (paid for) API that sat on top of an S3 API for on-prem, that would be fantastic as well. Kafka is great, but the whole Java ecosystem and the lack of control of what is in the topics and the stuff about co-ordinating the cluster in zookeeper is a management PITA.
- ThinkBeat 2y agoThis would sell much better is was S5 or S6 next level thing. Wow man are you stil stuck on S3?
- nextworddev 2y agoThis is cool but I think it overlaps too much with something like Kinesis Data Streams from AWS which has been around for a long time. It’s good that AWS has some competition though
- shikhar 2y ago(Founder) We plan to be multi-cloud over time. Kinesis has pretty low ordered throughput limit (i.e. at the level of a stream shard) of 1 MBps, if you need higher. S2 will be cheaper and faster than Kinesis with the Express storage class. S2 is also a more serverless pricing model - closer to S3 - than paying for stream shard hours.
- nextworddev 2y agoThanks. You are right about those points. One thing to probably consider is whether serverless provides enough cost savings for most streaming ingest use cases which need static provisioning since ingest volumes are unpredictable. A better messaging would be that your serverless model can handle bursts well. (for context: used to sell KDA and KDS at AWS as part of AI solutions)
- animex 2y agoIANAL,but naming your product S2 and mentioning in the intro that AWS S3 is the tech you are enhancing is probably looking for a branding/copyright claim from Amazon. Same vertical & definitely will cause consumer confusion. I'm sure you've done the research about whether a trademark has been registered. https://tsdr.uspto.gov/#caseNumber=98324800&caseSearchType=US_APPLICATION&caseType=DEFAULT&searchType=statusSearch https://tsdr.uspto.gov/#caseNumber=98324800&caseSearchType=U...
- volemo 2y agoTBF, building something with the goal of enhancing S3 I would call it S4.
- jffry 2y agoToo late, name's taken for something else: https://incubator.apache.org/projects/s4.html https://incubator.apache.org/projects/s4.html
- CobrastanJorji 2y agoAnd don't forget the other S4: http://www.supersimplestorageservice.com/ http://www.supersimplestorageservice.com/ It's like S3, except better because, by focusing on being a write-only data store, they can manage much more throughput and efficiency, plus your data is far more secure at rest than it is in S3.
- locusofself 2y ago"Making the world a better place through streamable, appendable object streams"
- somerando7 2y agoScribe aaS? ;)
- nyclounge 2y agoHow is this compare to https://github.com/deuxfleurs-org/garage https://github.com/deuxfleurs-org/garage ? Seems like there are a lot of more lite weight self-hosted s3 around now days. Why even use S3?
- zffr 2y agoHow does this compare to Kafka? Is the primary difference that this is a hosted solution?
- rswail 2y agoReally interesting service and bookmarked. I'd really love this extending more into the event sourcing space not just the log/event streaming space. Dealing with problems like replay and log compaction etc. Plus things like dealing with old events. Under GDPR, removing personal information/isolating it from the data/events themselves in an event sourced system are a PITA.
- shikhar 2y ago(Founder) An S2 stream is a durable log and can be replayed! We do want to add compaction support. Event sourcing is a great use case for S2.
- cultofmetatron 2y agoI had an idea like this a few years ago. basicly emitting a stream interface to a cloud based fs to enable random access seeking on bystreams. I envisioned it to be useful for things like loading large files. would be amazing for enabling things like cloud gaming, images processing and CAD kudos for sitting down and makin it happen!
- throwawayian 2y agoI look at the egress costs to internet and it doesn’t check out. It’s a premium product dependent on DX, marketed to funded startups. But if I care about ingress and egress costs, which many stream heavy infrastructure providers do.. This doesn’t add up. I wish them luck, but I feel they would have had a much better chance from the start by getting some funding and having a loss leader start, then organising and passing on wholesale rates from cloud providers once they’d reached critical mass. Instead they’re going in at retail which is very spicy. I feel like someone will clone the tech and let you self host, before big players copy it natively. It’s a commodity space and they’re starting with a moat of a very busy 2 weeks from some Staff engineers at AWS.
- shikhar 2y ago(Founder) Thanks for sharing your thoughts. We are early and figuring things out. I agree egress cost is going to be a big concern. We want to do the best we can for users as we unlock some scale. During preview, we are focused on getting feedback so the service is free (we will need to talk if the usage is significant though).
- deleted 2y ago[deleted]
- Lucasoato 2y agoWow, imagine Debezium offering native compatibility with this, capturing the changes from a Postgres database, saving them as delta or iceberg in a pure serverless way!
- CodesInChaos 2y ago1. Do you support compression for data stored in segments? 2. Does the choice of storage class only affect chunks or also segments? To me the best solution seem like combining storing writes on EBS (or even NVMe) initially to minimize the time until writes can be acknowledged, and creating a chunk on S3 standard every second or so. But I assume that would require significant engineering effort for applications that require data to be replicated to several AZs before acknowledging them. Though some applications might be willing to sacrifice 1s of writes on node failure, in exchange for cheap and fast writes. 3. You could be clearer about what "latency" means. I see at least three different latencies that could be important to different applications: a) time until a write is durably stored and acknowledged b) time until a tailing reader sees a write c) time to first byte after a read request for old data 4. How do you handle streams which are rarely written to? Will newly appended records to those streams remain in chunks indefinitely? Or do you create tiny segments? Or replace and existing segment with the concatenated data?
- jgraettinger1 2y ago> To me the best solution seem like combining storing writes on EBS (or even NVMe) initially to minimize the time until writes can be acknowledged, and creating a chunk on S3 standard every second or so. Yep, this is approximately Gazette's architecture (https://github.com/gazette/core https://github.com/gazette/core). It buys the latency profile of flash storage, with the unbounded storage and durability of S3. An addendum is there's no need to flush to S3 quite that frequently, if readers instead tail ACK'd content from local disk. Another neat thing you can do is hand bulk historical readers pre-signed URLs to files in cloud storage, so those bytes don't need to proxy through brokers.
- shikhar 2y ago(Founder) Thanks for the deep questions! 1) Storage is priced on uncompressed data. We don't currently compress segments. 2) It only affects chunk storage. We do have a 'Native' chunk store in mind, the sketch involves introducing NVMe disks (as a separate service the core depends on) - so we can offer under 5 millisecond end-to-end tail latencies. 3) The append ack latency and end-to-end latency with a tailing reader is largely equivalent for us since latest writes are in memory for a brief period after acknowledgment. If you try the CLI ping command (see GIF on landing page) from the same cloud region as us (AWS us-east-1 only currently), you'll see end-to-end and append ack latency as basically the same. TTFB for older data is ~ TTFB to get a segment data range from object storage, so it can be a few hundred milliseconds. 4) We have a deadline to free chunks, so we we PUT a tiny segment if we have to.
- dragonwriter 2y agoApparently this is “S2, a new S3 competitor” not “S2, the spatial index system based on heirarchical qaudrilaterals”.
- jgraettinger1 2y agoRoughly ten years ago, I started Gazette [0]. Gazette is in an architectural middle-ground between Kafka and WarpStream (and S2). It offers unbounded byte-oriented log streams which are backed by S3, but brokers use local scratch disks for initial replication / durability guarantees and to lower latency for appends and reads (p99 <5ms as opposed to >500ms), while guaranteeing all files make it to S3 with niceties like configurable target sizes / compression / latency bounds. Clients doing historical reads pull content directly from S3, and then switch to live tailing of very recent appends. Gazette started as an internal tool in my previous startup (AdTech related). When forming our current business, we very briefly considered offering it as a raw service [1] before moving on to a holistic data movement platform that uses Gazette as an internal detail [2]. My feedback is: the market positioning for a service like this is extremely narrow. You basically have to make it API compatible with a thing that your target customer is already using so that trying it is zero friction (WarpStream nailed this), or you have to move further up to the application stack and more-directly address the problems your target customers are trying to solve (as we have). Good luck! [0]: https://gazette.readthedocs.io/en/latest/ https://gazette.readthedocs.io/en/latest/ [1]: https://news.ycombinator.com/item?id=21464300 https://news.ycombinator.com/item?id=21464300 [2]: https://estuary.dev https://estuary.dev
- shikhar 2y ago(S2 Founder) Congrats on the success with Estuary! You are not the first person to tell me there is no/tiny market for this. Clearly _you_ thought there was something to it, when you looked to HN for validation. We may do a lot more on top of S2, like offering Kafka compatibility, but the core primitive matters. I have wanted it. It gets reinvented in all kinds of contexts and reused sub-optimally in the form of systems that have lost their soul, and that was enough for me to have this conviction and become a founder. ED: I appreciate where you are coming from, and understand the challenges ahead. Thank you for the advice.
- jgraettinger1 2y agoThe market is gobsmackingly huge, it's just the go-to-market entry points which are narrow. In my opinion, the key is to find a value prop and positioning which lets prospects try your service while spending a minimum of their own risk capital / reputation points within their own org. That makes it hard to go after core storage, because it's such a widely used, fundamental, and reliable part of most every company's infrastructure. You and I may agree that conventions of incremental files in S3 are a less-than-ideal primitive for representing streams, but plenty of companies are doing it this way just fine and don't feel that it's broken. WarpStream, on the other hand, leaned in to the perceived complexity of running Kafka and the share of users who wanted a Kafka solution with the operational profile of using S3. Internal champions can sell trying their service because the prospect's existing thing is already understood to be a pain in the butt. For what it's worth, if I were entering the space anew today I'd be thinking carefully about the Iceberg standard and what I might be able to do with it.
- nikolay 2y agoPretty bad branding! It should have at least been S4!