Motivation
Ramona is not the only nor the first software that is meant to supervise an application. Before even first thought of Ramona emerged, I was a long-time user of other Open-Source product called supervisord. I used it in multiple commercial projects and I found that there is a strong demand for such a software component. However supervisord`s approach is a very strange (at least to me). There is nothing wrong with an idea or software itself however I found myself several times in a situation when I ran out of supervisord possibilities or I had to finish configuration of my application in very weird way. I was again and again thinking: why it is done this way, it doesn't make a sense.
I also noticed one pattern: once you become familiar with a concept of the application supervisor, you start to use it everywhere. I did the exactly same, every new architecture of mine since that time has been built around this concept; it is great way how you unify 'maintenance user interface' of your application. No more troubles when preparing init.d scripts, no more platform specific scripts, no more questions from application support people how to start/stop/restart particular component. There is just one 'command' and it even has a help. And of course, there is much more.
Since I was not satisfied with supervisord, I've studied source codes of this product only to discover that changes I wanted, are just too large and I don't want to 'hijack' a Open-Source project, I also wasn't able to find any other feasible alternative. Then two things happened: I finished one project, in which we had to implement 'process roaster' component into a web application server and I got a contract to build a brand new product, not web application in this time, but a smart application that will interact with users only via SMSes and emails based on incoming events from an enterprise bus. It quickly became obvious that architecture of this new system will consist of several standalone processes that will cooperate together in order to deliver required functionality. So … wait a minute … I realised that I have an experience from recent project how to (and how to not) approach a task of a processes' supervision, I also have a very good use-case for such a supervisor and I have also some portion of a budget to build it. This was a combination that I couldn't resist.
I started first prototyping work in July 2012 and also it quickly turned out that I will not be the only developer. Jan S. joined quickly and he is actively contributing to Ramona source code till today (thank you :-) ).
Architecture
It quickly become obvious that task of application supervising is just a neat extension of functions provided by operating system. This means that by clever choices in a architecture of such a component, you can archive elegant, simple design. And that is exactly what I had in mind.
So here is a quick list of these architecture decisions:
Client-server architecture
User of Ramona will probably not notice that Ramona uses client-server architecture. But it really does. What you use, is Ramona console - administrator/maintenance user interface on command line or thru your browser - this represents unified point of interaction with Ramona server. Ramona server typically runs in a background (respectively daemonized) and maintains list of programs that run as server subprocesses. So you don't need to take care about daemonization, Ramona will take care about that for you.
Also Ramona console can start or go away and your application is running independently from these actions. If you are familiar with UNIX program 'screen', you can imagine Ramona being a 'screen' integrated into your application. This is one or many way of describing how Ramona operates.
Start/stop scripts (for example init.d ones) just invokes Ramona console commands 'start', 'stop', 'restart' and others.
Built on POSIX but compatible with Windows too
Ramona is meant to support all major platforms that are used today in IT industry. By selecting POSIX as a main OS API, we covered all major UNIX flavours, BSD variations and we are still close enough to support also Windows.
This is excellent match with technologies that we are routinely using in our daily software development and production run of applications we built. Developers tends to use Windows but there is also Linux and Mac OS X around, production software runs mainly on Linux but also Windows are time-to-time selected.
Today Ramona runs on Linux (Red Hat, Ubuntu, etc.), Mac OS X and Windows. I guess it will fluently run on FreeBSD etc. but I hadn't got a chance to test it.
First-class Open-Source
Ramona supervisor is an open-source software from day one. I strongly believe that today you can build software for enterprise segment purely using open-source components and also release it as an open-source. So we started developing it on GitHub, published also on Ohloh and actively promoting it to Open-Source community.
Single-threaded, event-driven
Basically a great way how to construct simple, uncomplicated however powerful applications that are polite to system resources. We selected libev / pyev to be a core of Ramona. Even today I have to say that is has been absolutely correct choice.This choice collapsed whole problem space into finding proper 'events' and writing a code that reacts to them correctly. Internal event loop is provided by libev; Ramona is most of a time sleeping inside
poll() call (or platform-specific alternative) keeping system uninterrupted from its intended primary use.Written in Python but agnostic to an application programming language
We decided to write Ramona in Python (2.7+) because we love this language and it makes us very productive. But it doesn't represent any requirement to supervised application. Even we operates several components controlled by Ramona written in Java, PHP, C and others.First year
Vast majority of a source code base has been written during August and September of 2012. Steady stream of commits flowed into our Git repository every day and functionality started to be available very quickly.
During October 2012, Ramona has been deployed with first project into production life. Since that time, features has been gradually added and 9 beta versions has been released during late 2012 and first half of 2013. Among added features are for example HTTP console, log monitoring and basic email notifications, ability to script custom tools that are integrated into Ramona.
Production use of Ramona has been considered as a success and we quickly observed the second deployment - a customised version of the same system now serving customers in another country. Since that time, every new system produced by our team has been equipped by Ramona. By time of writing, Ramona has been integrated into approximately 10 commercial products.
Thanks to this, we received valuable feedback that allowed us to stabilise this product and properly prioritise new features. Finally - after a year of beta - our first public release has been published in August 2013.
It was quite fun to built Ramona! I've personally learnt a lot and this is actually a first time I published standalone Open-Source product.
Future
In a shorted time period, we want to release a enhanced notification subsystem; a feature that will inform application administrator actively via email about issues of a supervised application and a relevant environment. This is based on log scanning and application status monitoring but it also provides API that can be extended in various ways providing creative space for custom monitoring and notifications. Application should virtually told to administrator that it requires some attention.
Ramona today is processing standard streams from the application therefore scanning of these streams for issues is quite obvious task that Ramona can deliver. By time of writing, this feature is already in alpha stage and first feedback looks quite promising.
As an extension of this concept, various watchdogs can be implemented. These are standalone application or programs that are launched by Ramona in a very same way as HTTP frontend and they implement different checks of the application, the operation system, hardware, network and/or the environment health. When issue is detected, this watchdog program informs Ramona via API and Ramona produces relevant notification (or trigger other action based on configuration).
In a long term, Ramona should become able to supervise an application that operates in a cloud environment. This means multi-node application managed from a single place, allowing smooth addition or removal of nodes, migration of application components across cloud nodes etc. Implicitly this will also enable disaster-recovery scenarios completely managed by Ramona.
Physically this will be done via network of Ramona servers (one on each node), operating autonomously but also maintaining communication with other nodes, discovering newly added nodes and reacting to nodes that disappears from a network. Architecture of this network is inspired by peer-to-peer networks mainly to prevent single point of failure.
Ramona name
People are time to time asking what name 'Ramona' means and why I chose that for this product. I'm a Czech and there used to be one famous passive radar system produced in Czech Republic that has been able to detect even a stealth aircraft like F-117. Although this seems to be as a good way how to choose a product name, I was actually not fully aware of this fact. So this is not a real story behind it.
The real story is that I actually met a girl with this name during early stage of Ramona development, she came and went away - but her name (or maybe just a nickname, this is not a common name here) was so fascinating (so as our few rendezvous have been) that I borrowed her name and use that when I sought one for this product.
She will probably never discover that but anyway … thank you.
Links
Ramona supervisor homepage: http://ateska.github.io/ramona/
No comments:
Post a Comment