The Last9 Ṛta
Ṛta (/ɹ̩ta/; Sanskrit ऋत ṛta "order, rule; truth")
The principle of the natural order regulates and coordinates the universe’s operation and everything within it. In the Vedas, Ṛta is described as ultimately responsible for the proper functioning of the natural, moral and sacrificial orders.
Last9’s Ṛta is the ethos and reasons behind our products. Whether it’s engineers who build or customers who use our products, we want people to consistently experience our intentions and aspirations behind how we think of products.
9 and never a perfect 10
The most efficient system is the stalest system. If it’s stale, your systems are not improving. In fact, a perfect system is only a subset of an imperfect world. Thus, all aspirations for the perfection of a 10 are futile.
Failures are inevitable. In software engineering, failures are the norm. All our energies are being directed toward reducing these failures. Embracing 9s means resigning to accepting a simple ethos — nothing can be 100%. The space we operate in is chaotic, and unpredictable, and requires us to take large amounts of ambiguity and deliver clarity.
All our products and engineering aspire to help our customers realize the economics of this fight for 9s faster. Hence, Last9. 😊
Simple things fit in a box
Every system has a unique logic. This logic should behave the same when run locally, on staging, or in production. The only difference between the three stages should be the scale, not the design or its dependencies. Products designed this way are quick-to-adopt and easy to scale.
We design our products with these constraints in mind. We often gravitate towards being lockless, stateless, and idempotent. And if there’s a need for a state, offload it to another component.
Pluggable Products
Simple designs cannot be articulated, they can only be experienced. The hallmark of well-designed products is to seamlessly disappear in existing workflows and toolchains. Some of the Unix Philosophy of building tools heavily inspires us:
- Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.
- Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter the output with extraneous information.
We strive to create simple products that plug into, and leverage existing toolchains of developers.
Decisions-as-Code
Systems behave like humans in production. How humans need a declaration of independence, constitution, rights, and duties; so do systems.
Systems that operate under the declarations of duties and disciplines behave predictably. Because systems understand only code, we need Decisions-as-Code.
Infrastructure-as-Code is a testament to this need. All our products strive to provide a way to declare guardrails, policies, and decisions to manage systems predictably.
Observability
Speed is the only currency startups have. And speed comes from confidence. The constant fear of failure leaves you with a pedestrian pace. The only way to beat this fear is to be confident of failure notifications. Most developers know their code and can fix things fast. The biggest challenge is to let them know something needs fixing.
The onus to detect failures lies outside of the system being observed. This love for Outside-In Observability inspires our engineering and products.
Love solutions, not code
Focus on the problem you’re solving and buy or build technology around it. If the solution drives the situation’s outcome, the code is irrelevant. If you can use an excel sheet to solve the problem, do that, and proudly so.
Because problems last a lifetime, tools don’t.