Network management software

Member of the IT-CS group (Communication Systems) which is in charge of telephony (GSM, VOIP, analog), networks (from top-down: structured cabling, selection of switches/routers, installation, network engineering, network support, Wi-Fi) and central network services (DNS, DHCP, Radius, NTP, …).

In this group, my section, IT-CS-CT (Communication Tools) is a small team (around 7 people) of young and multicultural developers and is in charge of building software to support and manage the network, telephony, and group services.

The database controlled by our section (LANDB), is the core of the network activities at CERN, and we model all needed networking and telephony concepts that will be either consumed by high-level applications that we build or by other low-level applications in other sections of the group.

CSDB

Administrators application, it is used by members of the group, security team and other power users to configure the network.

This application has been developped since many years, thus there were many architectures (JSP code, J2EE beans, master singleton with all the code, …). I proposed to introduce a new layered service-oriented architecture based on Spring (MVC, Data, …). This ended up with the standard three layers: controllers, services, repositories.

By using this architecture we were able to share code (through maven artifacts) among all the application that we develop.

LANDB Portal

User-facing application, it is used by all the users and visitors at CERN who requires network connectivity.

The old application WebReq was in Perl and written more than 20 years ago, it has been migrated to Grails.

• Grails

  The application backend is written using Grails framework. The service layer is shared between CSDB and LANDB Portal as a Maven artifact.

• AngularJS

  The application frontend is using AngularJS.

• Micro-services

  After evaluating different options, I proposed to replace some parts of the legacy application using Spring Boot powered micro-services.
  I chose Spring Boot as we were already heavily using Spring framework and it was at that time the more mature framework. It allowed us to migrate very quickly and easily legacy features to our new architecture.

LANDB Database

LANDB is the core network database which stored all the network configuration: topology, devices, users, connections, firewall, fibers, telephony, …
This database is the core of all the application developped in the section and is heavily used by other people around CERN using SOAP and REST API.

Since the database was the common layer of the legacy applications, all the logic has been developped in PL/SQL over many years. In order to greatly simplify the maintenance and the evolution of the codebase, I proposed to migrate this legacy code to a service oriented architecture. The two main application now use the same service layer and a REST interface will be setup based on the same layer.

Devops

I was in charge of administering all the applications used by the developers, inside the section but also used by other people in the group.

• SVN repositories

  I was responsible of the SVN repositories used by the whole group. The creation of the repositories and the access management was automated using the access roles provided by CSDB application.
  In order to provide high quality source code, commit hooks were setup running Checkstyle static analysis prior to any commit. This enforced the same source code format and really reduced the different development styles of each developer.

• Atlassian Bamboo

  To build our applications we are using Atlassian Bamboo.
  Very similar to Jenkins, I was maintaining and updating the build plans depending on the environment change: migration to Java 8, development of new applications based on different frameworks (Grails, Spring Boot, Android, ANT, Maven), retirement of old applications.

• Atlassian Fisheye

  As part of our software development life cycle, prior to deploy any changes to the codebase, peer reviews were mandatory. Using Atlassian Fisheye at least two other developers had to review the code. This not only greatly improved the code quality, but also allowed the simplify knowledge transfer among all the developers.

• Selenium Grid

  I was managing the entire Selenium grid, from its setup to its maintenance using OpenStack to manage the nodes of the cluster.
  I decided to develop a simple framework that allows to drastically simplify the development of integration tests, by creating a layer between Selenium API and our own applications.

• Migration to GitLab

  The IT department at CERN is mostly using Git as VCS. In order to profit of all central services provided by IT, I took care of the migration of our standalone SVN server to GitLab.

  This included to migrate all SVN repositories to Git keeping the history. As well to migrate our build system (based on Atlassian Bamboo) to GitLab CI (using Docker containers).

Development of Neoload software

As member of a small development team (around 10 people), I was developing on NeoLoad software.

NeoLoad is a load testing solution designed for web and mobile applications to realistically simulate user activity and monitor infrastructure behavior. Developed in Java, Neoload is a heavy client using Swing for UI. To generate heavy load on tested servers it generates virtual users that replay a recorded scenario.

Development Process

Based on Agile methodologies

SVN as version control system

Bugzilla as backlog

Jenkins as build system

JUnit for unit testing and QFTest for Swing UI testing

Simulation (record and replay)

Theses modules are used to record the protocol traffic and display it in a user-friendly way. This allows the user to easily understand the purpose of each request but also to modify them according to their testing scenario.

Also used to execute the requests during a load test, these modules required strict memory management and code synchronization as they are used by more than 1500 threads simultaneously.

• Adobe RTMP (Real Time Messaging Protocol)

  Protocol developped by Adobe to communicate between a media server and a client (mostly Flash player). Detect and record RTMP traffic at TCP level (using tcpdump/jNetPcap). This required not only to reverse-engineer the protocol but also to adapt the module to work with a variety of media server (using their own retro-engineered protocol).

• Google Web Toolkit RPC

  Protocol developped by Google to ease communication between a GWT client and the server. Text based protocol, it is used to serialize Java objects between client and server. This required to understand the protocol by understanding GWT source code and be able to simulate it.

Monitoring

Modules used to analyze the behavior of the environment when performing an application load test. Each of them required to analyze how the monitored element provides statistics, retrieve them and provide usefull information to the tester.

• Hypervisor

  VMWare ESx
  Connection to hypervisor Web service and collection of provided statistics.

• Applications servers

  Oracle Application Server, JOnAS, GlassFish
  JMX connections to retrieve populated MBeans, statistics are different for all servers.

• Databases

  DB2, PostgreSQL
  JDBC connection established with the database and statistics are retrieved using engine specific SQL queries.