Amon 3.0 released, The past and future of Amon

By Martin Rusev read

The story of Amon

This part is a quite long and follows the story of Amon and some of my personal story and experiences in the last 4 years. If you are not interested, you can jump directly to the announcement

Why Amon exists?

Amon started as a toy project in early 2011. At that time I was a Python web developer. If you don't know this about Python and web - it is one of those languages that forces you to understand Linux, servers and devops in general. Compared to PHP for example where you upload a site with an FTP client and right click, in Python you can't get far without advanced Linux knowledge.

In addition to my dev skills, I've always been an optimizer, sometimes to the extreme - if I believe that some critical piece of code could be written in 2 clean lines, I will spent days optimizing. If an SQL query on the front page takes 400ms and I believe it could be faste - again - tremendous amount of time will be spent. At the time I came with something I call Benchmark Driven Development. BDD is like TDD, but instead of just writing tests, you add iterations. That way you can see slow pieces of code way before your users. BDD looks something like this:

post('create_user', values)
assert user_created

# BDD - Benchmark Driven Development
for i in range(0, 1000):
  post('create_user', values)
  assert user_created

Needless to say when you want to optimize your apps to be as fast as humanly possible, you need all the data you can get when they are deployed in production. Your servers are the foundation, so you have see performance issues as fast as possible, so you can move up the chain - to slow queries in the database, slow I/O operations when uploading files, etc.

All that lead me on my quest to find a monitoring tool which is as simple as possible from a developer perspective. My goal was to find something that:

I started with the elephant in the room - Nagios, which is the standard bearer in the monitoring world. From the 4 requirements I had, Nagios fails at 3 of them. It has a solid foundation, there is no doubt about that. The people who already pushed through the pain, can't live without it. The thing is - it is just not developer friendly.

After Nagios - there was Cacti. With Cacti - I was not really OK with something installing Apache and PHP on my fragile 256MB VPS. There was also Munin, Zabbix and a dozen of others. I have tried Scout, New Relic and Server Density. Server Density, at least for me was the most promising. The problem I had with SaaS apps is that they get more expensive over time and you don't have control over your own data.

All this just made me more frustrated. I was a developer and I wanted to spent more time making apps and less time dealing with servers, devops and figuring out ways of extracting the metrics I needed.

That is why, I decided to create a small monitoring tool which didn't require a complex installation, could be installed with 1 line and doesn't need a lot of system resources.

Amon 0.X (2011)

The first version of Amon was born, it was a small python CherryPy app with Redis as a datastore. Redis was starting to get popular back then and to this day there is probably no other tool that satisfies my "Elegant, simple and useful" desire better than Redis. I really wanted to stick with Redis, but soon realized - it is not suited for massive amounts of data, because it keeps everything in RAM. The next contender was MongoDB, which defaults to scale - meaning taking a lot of space and RAM. The good thing about Mongo is that if you have the time to dig a little bit deeper in its configuration, you can have a NoSQL database with a very small footprint.

After a couple of months Amon was stable enough and I decided to release it as a self-hosted, open source tool. As it turned out a lot of developers had similar problems and it got popular really quickly. I got a lot of enthusiastic emails and job offers. I even ended up working for a Silicon Valley company and getting an offer from Google for a Reliability engineer position.

I spent a lot of time back then thinking of ways to grow Amon and capitalize on that success. In the beginning Amon was a single server tool - paste a line, install it and have something up and running in less than a minute. The initial version was taking somewhere between 15-20MB RAM which was something reasonable even on a small 256MB VPS.

Amon Plus (2011-2013)

This let me Amon Plus, which was a little bit more sophisticated version with a web app running on 1 servers and agents on all the other. Right from the start my goal with Amon Plus was to provide a pleasant, affordable monitoring tool for small companies, sole developers and startups. This is my world, these are the people I believe I understand best. What really happened in the real world though, was that Amon Plus really got popular among hosting, media and internet of things companies. The problem at least for me was that I didn't know the real needs of these types of companies and personally felt that I failed to realize my initial goal - provide a simple monitoring tool for startups. In a typical startup fashion I decided to pivot and change course.

A word of advise - if you are startup founder and you have a working product and you want to pivot, because you believe that there are greener pastures out there - don't kill your already working product, create a new one. A pivoted product always appeals to a different audience and a very small percentage of the people using your current product will be interested anyway.

Amon SaaS (2013-2014)

This is how Amon was reborn as Software as Service. There were several basic business rules that I didn't know and I broke at the time. The most important of them: If you want to succeed you need to have a unique product. There are several books, that you should check out if you are interested in this topic. My favorites are Becoming a Category of One, by Joe Calloway and Zero to one by Peter Thiel.

I went from a unique product to a product competing in an already saturated market. When you arrive in a situation like this and I have seen it countless times in startups around me you try to "Level the battlefield before inovating" That means instead of focusing on customers and their needs, you try to have all the features the most successful product in your niche already have and when this is done - add your own ground breaking features. Usually in the process, the product loses its own identity.

I spent almost a year doing just that - trying to copy what Datadog, Server Density, Scoutapp and New Relic already have and mix the best in one new awesome package. Along the way I lost sight of my original vision. The other problem when you compete head to head with established players is that - it is always a race to the bottom kind of a deal. You try to compete mostly on price and optimize your product to be cheap on your side, instead of innovating.

At some point in the beggining of 2015, I got tired of trying to code my way to relevance. I took a look at the monitoring/metrics SaaS landscape and though about where Amon could fit. It turns out - my original vision from 2011 still stands - if you are looking for an elegant, easy to install and support self-hosted monitoring tool - there are none. Zero.

On the self-hosted side of the spectrum we have Nagios, Cacti, Zabbix, Icinga which still are very painful to install, configure and support. In the middle we have Monit, which is great in its own merit, but kind of expensive for what it does. And we have the hosted tools - like Datadog, New Relic, Server Density, which get really expensive over time.

That is why I decided to pivot Amon one more time and bring it back as what made it popular in the first place - self-hosted monitoring tool that does not accumulate technical debt over time with upgrades, support, etc.

Amon 3.0

Amon 3.0 is the biggest release to date. It is the result of over 4 years of hard work and iterations. It marks the beggining of a new era for Amon - after 2 years of struggle and playing it safe in the SaaS world, it goes back to being a self-hosted monitoring tool and doing things differently.

If you are long time Amon user you probably already know what Amon is all about. You can take a look at the feature page for more details about this release. I have already compiled a list of ideas for the next releases, please let me know at martin@amon.cxwhat you think and what features you want to see in Amon.

If this is the first time you hear about Amon and you made it this far - I am really impressed by your attention span :) I want to invite you to take a look at the feature page to learn more about what Amon can do for you and I really hope you will like what you see.

Thank you for reading and I really hope you enjoy the new Amon!
Martin Rusev