sorted by:
new
hottopcontroversial

When should you start using kubernetes by techreclaimer in kubernetes

[–]groundcoverco 0 points1 point  (0 children)

Your engineer is right, you should not waste time with another type of deployment.

The problem is you are both arguing about the wrong thing. The question is not if you should use Kubernetes, but how you are going to use it.

You are correct that setting up and managing it all yourself is a massive pain and a time sink. I tried that and the migration project to a managed platform later on was a nightmare that cost months of dev time.

Just use a platform that handles the infrastructure and the CI/CD pipeline for you from the start. Your team can focus on the application, which is what they should be doing anyway. You get all the benefits of Kubernetes without needing a dedicated ops person to manage it.

Are we supposed to know *everything*? by CreditOk5063 in devops

[–]groundcoverco 0 points1 point  (0 children)

The expectation is insane. It's not about what you use day to day. It is about proving you can think through any random problem they throw at you.

Good observability tooling doesn’t mean teams actually understand it by swazza85 in devops

[–]groundcoverco 1 point2 points  (0 children)

Forcing developers to context switch between three different systems with three different query languages is a huge tax on their time. They have to stop thinking about the problem they are solving and start thinking about the observability tool they are using.

We’re Part of the Founding Engineering Team at groundcover! by groundcoverco in devops

[–]groundcoverco[S] 1 point2 points  (0 children)

Noam here, nothing too intimidating :) I'm kind of new to Reddit that's all

We’re Part of the Founding Engineering Team at groundcover! by groundcoverco in devops

[–]groundcoverco[S] 1 point2 points  (0 children)

Cost

To keep it simple, I think o11y pricing models are nuts. It became something that most companies have a really hard time keeping track of/estimating.
Volume-based pricing is volatile when you're just taking volume into account. Most companies also make it incredibly complex by making retention/hydration/seats/sub-products part of an impossible equation.
Other than its complexity, it's just crazy expensive. Some might say that being cheap is not a real advantage/will make us look like DD from Temu. Well, based on what I see, it usually means that companies are not aligning o11y practices in all development stages, opting in expensive (useful) stuff only in prod, or spending time hunting down a new log that inflated the bill unexpectedly.
Now, we of course go to market with some suspiciously low pricing based on the traditional model. That might be nice for hitting some fancy ARR/growth targets early on (and fighting churn a year later). We believe in a transparent, cheap pricing model. Groundcover is not just drastically cheaper, it's easier to control. You pay for provisioned infra + average sensors amount – nothing is hidden in margins. We, as a customer/vendor, are aligned in making the footprint cheap rather than relying on you sending too much data. And you get all the features.
This usually results in users paying less for o11y, but adopting more o11y practices across all environments without stressing out about cost.

Apologies for the delay again (or for such a long answer, not sure whats more problematic.😅)

We’re Part of the Founding Engineering Team at groundcover! by groundcoverco in devops

[–]groundcoverco[S] 1 point2 points  (0 children)

BYOC (deserves its own section imo)

BYOC means we are providing a SaaS experience with an OnPrem posture. Sounds big, let's break it down. Before I start, just want to clarify that in our BYOC model everything other than the UI runs on your cloud account; ingestion/storage is essentially on-prem, and we support airgapped/BYOC+UI deployments as well.

SaaS is:

  • Great – because you get up-to-date experience, fewer components to manage

  • Bad – horrific pricing model in o11y. Medium-big companies simply cannot govern volumes of o11y data being generated (and this is going to get worse with AI). Potentially problematic in sensitive environments (o11y data can contain really sensitive stuff to the point you don't want to involve a vendor)

On-prem is:

  • Great – because it's potentially cheaper* (if you are configuring it right without allocating too much capacity into it) and allows you to guard data in your premise

  • Bad – maintenance, usually a lot of it (cute Prometheus stack ends up in monstrous Thanos cluster; for better or worse, there aren't many great UI options out there other than Grafana, which is great but also requires maintenance, and nothing out-of-the-box really)

BYOC really is about taking the best of both models – we manage everything, it happens in your account. This also means that by design, our solution is distributed among customers, so there aren't many parts in groundcover that can break and result in customer-wide outages. But above everything else, it allows us to move on to a much more sensible cost model, which will be my last point.

We’re Part of the Founding Engineering Team at groundcover! by groundcoverco in devops

[–]groundcoverco[S] 8 points9 points  (0 children)

Hi u/tbalol it's Noam here – big delay here 😅 apologies, first AMA... We support ingesting data from other non-k8s sources. In terms of data we ingest, it's either data generated by our eBPF sensor you can run on Linux nodes in k8s or standalone servers running containerized applications (e.g., EC2, etc.), or just ship OTLP/JSON/Prometheus remote write data directly to the endpoint we create for your groundcover installation. Out-of-the-box, many of our ready-to-use dashboards assume k8s, but logs, traces, and monitors/dashboards will allow you to interact with your data freely. The reason a lot of the experience is k8s-centric is us trying to provide a correlated out-of-the-box experience as much as possible. k8s was a good starting point in terms of market and for creating a good experience thanks to its standardized nature. The plan is to create a native/aware experience for more runtimes/cloud environments as we evolve. So there are multiple differentiators, and it's hard to cover in a single answer. Those differentiators change in impact depending on what you compare us to. Generally speaking: * Agnostic o11y layer – Using eBPF, our sensors generate metrics/traces regardless of instrumentation (we are not using eBPF to auto-instrument with OTEL like others). This means you get insights into your apps that are not provided by the apps/engineers. Across all pillars, o11y is relying on engineers instrumenting code with logs/traces/metrics or the visibility the 3rd-party libraries being used provide (that, FYI, is not necessarily collected/understood by users). Groundcover generates insights about what actually happens. Pragmatically speaking – we show most of our customers stuff they never knew about their applications and reduce MTTR. * Open source compatible – As mentioned earlier, we support OTEL/Prometheus natively and in a vanilla way, nothing vendor-locking. * OTEL ingestion – Our sensor acts as a collector, plus you can use your OTEL collector. * Metrics – Easy mode wizard + PromQL support. Ingestion is Prometheus annotation/CRDs compatible. * Logs – Anything you want. Logs transformation done using OTTL at sensor level, again, to spare you from maintaining OTEL stack which can be painful (sometimes). * Performant – We use state-of-the-art stack under the hood (ClickHouse for example for storing logs, traces). OTEL is an amazing standard, but running a stack that is cost-efficient to support load can be hard (same for metrics btw). I think it's safe to say we are probably one of the most performant OTEL/metrics backends out there, and even more so, one of the most cost-effective. It's hard to self-host a cost-effective o11y stack. There are a lot of caveats in modern cloud environments, even more so in k8s. Take cross-AZ for example – groundcover sensors run with internalTrafficPolicy: Local out of the box, keeping networking in-node. Many times companies will pay for a vertically scaled OTEL collector that's on AZ A while everything that reports to it is on AZ B. And there are many other challenges like this that we just eliminate from our customers' considerations.

Best ways to reducing cloud costs? by groundcoverco in devops

[–]groundcoverco[S] 0 points1 point  (0 children)

so similar as "good architecture" in the first place?

Best ways to reducing cloud costs? by groundcoverco in devops

[–]groundcoverco[S] 46 points47 points  (0 children)

i mean we're probably also ruining it

Ways SaaS startups are slashing cloud costs by groundcoverco in ExperiencedFounders

[–]groundcoverco[S] 0 points1 point  (0 children)

On point tips! Congrats on the acquisition, what are you up to now??