Kadira

» see kadira.io as it lived, on the wayback machine

~ the eulogy ~

Meteor was never my stack. In 2014 it was the framework I kept skipping past, because what it solved was not a problem I had: real-time web apps that pushed data to the browser without you writing any of the plumbing. It had a short, bright window of popularity, and inside that window one developer in Colombo built the tool that told Meteor developers why their apps were slow.

Arunoda Susiripala announced Kadira on Hacker News on 2 June 2014. It was performance monitoring in the way that was becoming standard by then: you added a package to your app, and the dashboard showed you which methods were slow and where the database was hurting you. The difference was that nothing else did this for Meteor. New Relic and its competitors were built around request-and-response web servers, and Meteor's whole premise was a persistent connection pushing updates, which the standard tooling could not see into.

The whole company was him: one developer in Sri Lanka with a paid product and no investors behind it, and by Kadira's own marketing the service ended up trusted by over five thousand organizations and developers. I build things from Ankara, which is also a long way from the places that get written about, and what stays with me here is a single person in the wrong time zone quietly becoming load-bearing infrastructure for a few thousand strangers.

~ the dossier ~

~ one developer, five thousand apps ~

Kadira shipped a lot for its size. There was Kadira Debug, which let you step through a running Meteor app's performance rather than reading it after the fact, and later a product called Genie. The company name on the earliest work was Meteorhacks, which was also the name of the blog where Susiripala published the Meteor internals writing that got him an audience in the first place.

The economics of this are the interesting part and they are not complicated. A monitoring service has to stay up, because a monitoring service that goes down while your app is on fire is worse than nothing. Staying up is a staffing problem before it is a technical one, and the staff here was one man who also wanted to write code. That worked for three years.

~ the december letter ~

On 30 December 2016 he posted that Kadira was shutting down. The original deadline was 28 February 2017, and it moved twice, because people had production systems wired into the thing and needed longer than two months to get out. Meteor Development Group announced on 24 March 2017 that it was taking the assets, and the source code went public on 7 April.

The service itself stopped on 15 May 2017. Meteor folded its own application monitoring into Galaxy, its hosting product, and a community fork called Monti APM appeared the following year under a different maintainer with no connection to the original team. The code survived and the company did not, which is the usual arrangement when a single-maintainer business closes.

~ what outlived it ~

In March 2016, while Kadira was still a going concern, Susiripala's team released something called React Storybook. It was a side tool for developing UI components in isolation, the kind of thing you build because your own work annoys you. It was handed to the community in April 2017, the same month Kadira's code went open, and it is now simply Storybook, used by an enormous number of front-end teams who have never heard of the Meteor monitoring company that paid for its first year. Kadira is the rarer kind of failure: the business died and its accidental byproduct became the thing everyone uses.

@}-->--

              )
             (_)
            .-'-.
            |   |
            |   |
            |   |
            |   |
          __|   |__   .-.
       .-'  |   |  `-:   :
      :     `---'     :-'
       `-._       _.-'
           '""""""

« previous  ·  random  ·  next »