[ixpmanager] IXP Manager - Planning for v4

[Barry O'Donovan]

Hi,

A lot has changed in the 3 to 5 years that the decision was made to use 
certain libraries / technologies / methods on IXP Manager.

In previous major version changes we made some serious architecture 
changes in one sweep. For example v2 -> v3 saw the complete migration 
from Doctrine ORM v1 to v2 (which was a change from the Active Record 
pattern to the Data Mapper pattern).

Today, IXP Manager is a very large project and to do such a sweeping 
migration in one go would stifle development, break something that isn't 
actually broken and take a lot of time.

But, sticking with older technologies and libraries has negative effects 
also. It creates developer apathy (for which I can personally vouch 
for). It also provides a major stumbling block for bringing on new 
developers and contributors (who wants to learn Zend Framework 1 now 
which has been EOL'd for sometime?).

So, our plan for v4 is to bring in new technologies without throwing 
away everything we have.

IXP Manager is a MVC application that currently uses Doctrine2 as the 
Model, Smarty as the View and ZF1 as the Controller. Doctrine2 is still 
current and won't be changing.


Smarty will remain as the view engine for current / unmigrated 
functionality. But Smarty is... oh my God... soooooo bad. v4 will 
default to Twig [1] which is more modern and far better structured from 
a programming point of view. Coupled with the new framework, it will 
also allow for a nicer means of skinning. For the interested, Twig has 
some very nice features including layouts, macros and also some nice 
security features.


ZF1 has served us well but it's been EOL'd and is now quite outdated. 
The new 'hotness' in PHP is Laravel [2], which I've been using to great 
effect for a while now. Laravel show cases some of the new and best 
functionality of PHP and using very modern techniques (such as IoC [7]).

But more importantly, Laravel will let us do things in a much different 
and much more flexible manner for the IXPs using IXP Manager. Some of 
these include:

  - Job queues: built-in and simple (to use) support for job queues via 
Beanstalkd and others. Queuing jobs will provide functionality that we 
at INEX have been looking for (and it's also an FAQ from other IXPs) -> 
reconfiguring services on demand (or, at least quicker than a twice 
daily cronjob).

Put this together with:

  - Events: Laravel allows us to trigger events and subscribe to them.

A key example of queue and event functionality would be that a change to 
a VLAN interface (such as checking the RS client box) would trigger a 
'vlan interface changed' event. One subscriber to this event would be 
the route server configuration manager. Based on the VLAN change, this 
event handler can then queue events. The route servers themselves would 
monitor these queues and rebuild / reconfigure the route servers 
appropriately 'on demand'.

Similar handlers for route collectors, DNS ARPA changes, etc. can offer 
much more 'real time' control of all the services at an IXP.

IoC decouples logic from the controller. What this means is that IXPs 
who want to do things differently than INEX (let's say use Cacti instead 
of MRTG as an example), can swap out MRTG with Cacti with one line of 
code (that's assuming we write contracts - interfaces - for such 
handlers and a Cacti version is coded of course!). But that's the kind 
of power and flexibility we're looking to bring in.

Other features Laravel provides includes:

  - much much improved unit testing on controller actions. Right now, we 
spin up Apache and MySQL to test controller actions. This is no longer 
required with Laravel making tests easier to write, more robust and more 
focused.

  - a much nicer and more structured way of creating command line 
interfaces rather than the quite clunky way we have of doing it currently.

  - a much more natural way to develop REST API endpoints with json:api 
compatible responses.


And that leads us to the front end. Right now, the front end and the 
back end are tightly coupled. During the development lifetime of v4, we 
want to move more towards an 'API is Everything' back end with a 
decoupled front end.

This separation will again aid unit testing providing a more reliable 
and robust IXP Manager. It will allow other IXPs to create their own 
front end on member facing portals or, even, move to IXP Manager as 
their back end system but retaining investment of current member portals 
by adding new features from IXP Manager through API endpoints. It will 
also allow existing systems in IXPs to integrate with IXP Manager to 
provision services and ports for example.

One of the bigger tests of this plan will be the (long awaited and badly 
needed) revamp of the member facing area. We're currently planning the 
UI / UX of this to deliver key information to members in the best way 
possible. This will include Bootstrap v3 which is 'fluid' from the 
ground up so mobile browsers to wide screen browsers should be supported 
naturally.

During the early stages of v4, we'll create the API endpoints necessary 
to support the member portal functions and then create a front end on 
that using Ember.js [3].

Other changes in v4 will include:

  - a switch from package management via Git sub-modules to composer [4] 
and Packagist [5] as is current standard practice;

  - introduction of Bower [5] for front end asset management;

  - and we'll need a task runner for pulling everything together - for 
that we'll use Grunt [6] (although that'll mostly be a development / 
release prep tool rather than an end user requirement.


So, that's what we're looking at! It won't happen overnight but we'll 
continue our policy of release early, release often and we'll update the 
documentation and provide complete upgrade instructions at the 
appropriate times. Some of the above is also subject to change depending 
on practical experience / issues as we move towards it.

Comments, ideas, etc. are all welcome.

  - Barry


[1] http://twig.sensiolabs.org/
[2] http://laravel.com/
[3] http://emberjs.com/
[4] https://getcomposer.org/
[5] http://bower.io/
[6] http://gruntjs.com/
[7] http://laravel.com/docs/ioc


-- 

Kind regards,
Barry O'Donovan
INEX Operations