VidulividuliBeta

Breaking the Silence: A Platform Update

We haven't blogged in a couple of months, but we've been hard at work to bring Viduli to tip-top shape for broader adoption.

By Avin Kavish
Founder InsightsUpdates
Background
Breaking the Silence: A Platform Update

It's been a while since I posted in the blog - about 2 months. It is tough to be writing and developing the platform simultaneously; it's a balancing act. I also felt like there was no point in posting updates if the underlying platform wasn't ready for adoption. So, I made a judgment call to buckle down and focus entirely on development until I could get the platform ready for scale.

Building a new product, company, or startup - whatever you want to call it - is tough. There are so many judgment calls involved that it's impossible to validate every decision ahead of time. The results of some things are only known after the choices are made. I made a choice, and I hope it was the right one. Anyway, let's jump right in and see what we've been building.

Project Tiers

We added project tiers. Not all projects are created equal. Some are hobby projects, some are tests, some serve a few thousand users, and others have 10 million active users. Each project tier is made to fulfill a specific purpose.

  • Free - The Free tier is meant for trying out the platform or validating your build risk-free.
  • Basic – Basic tier projects are ideal for low traffic applications.
  • Premium - Meant for medium to high traffic
  • Premium HA - Meant for very high traffic with maximum availability

Basically, these tiers should be enough to get you from zero to about a hundred thousand RPS. With autoscaling, the projects will have no limit; the tiers simply define the base costs. In the future, we'll be introducing autoscaling so project gateways can handle any amount of traffic, up to one million requests per second and beyond.

Build System Overhaul

We made large sweeping improvements to our build system for all supported frameworks. Some of the improvements are,

  • Pinned base image versions to prevent regressions
  • Added a standard toolkit to each container to help with debugging
  • Support more versions via .xxxx-version file

We'll be following up with a detailed blog post about the build system soon.

Platform Upgrades

Although not directly visible in the UI, we've made several upgrade to our underlying core architecture to improve resilience, robustness and visibility. These upgrades will also serve as the foundation for future scale out of the platform.

Auto-provisioning Kubernetes Clusters

We switched to Karpenter-based node auto-provisioning for our clusters. Karpenter provisions exactly the compute resources needed to run user workloads, so there are no excess idle resources. We reduced our burn rate by about 30% through this switch. Karpenter-based scaling also has no upper limits. It'll provision as many nodes as necessary to run the requested workloads.

Prometheus-powered Metrics

Previously, we had a simple metrics monitoring system that used kube metrics server. Now, we've switched to prometheus for metrics collection. Going from just CPU and memory metrics to much more detailed metrics, it feels like sanity has been brought to the system.

We are also scraping application-specific metrics, like active connections and TPS in Postgres, and commands per second in Redis.

Note: Although, we are collecting these metrics, they are not yet exposed in the web console.

Loki for Log Storage

It uses Loki for log storage and querying, and Alloy for collecting logs from the nodes and pushing them to Loki.

Note: Although, we are collecting these logs, they are not yet exposed in the web console.

Application Fixes & Improvements

We also made dozens of UI/UX improvements to our web console, some of which are highlighted in the changelog post. Overall, users should have a much smoother experience with fewer bugs and faster navigation across the console.

Test Coverage

Nothing flashy here, nothing that users can see, but we are gradually increasing test coverage of the Viduli system. It's helping us ship faster and more confidently, also helping to reduce regressions and prevent introducing bugs. For us, it's a critical step in graduating from a beta to a generally available, trusted and tested cloud platform that software teams can rely on.

Conclusion

All in all, I think the two-month grind was a great success. It feels like the platform has gone from "something to try" to experience the concept to "something to use" get things done. That's not all - we have been working on Kafka support too, and it's nearly ready. I will reveal more details as I talk about each of the above topics in great detail in upcoming weeks.

About Viduli

In case you wondering what I am talking about, Viduli is a next-gen cloud. It's the new stack to replace your old stack. With Viduli you can skip the headaches induced by tool sprawl. What used to take three dozen tools to set up in traditional cloud now only takes one tool, one platform - Viduli.

Kubernetes, Grafana, Prometheus, Loki, Alloy, KEDA, Nginx, Envoy, etc, etc.

Nope? Just use Viduli.

Give it a go and let me know what you think.

Cheers!

- Avin, Founder

P.S. Subscribe below for more updates.

Join our newsletter

Get the latest updates and insights delivered to your inbox.