Skip to main content
16 Jul 2020

Introducing Infrastructure Autoscaling – Leon Tech Insight

In our effort to bring you some additional insight on the latest tech developments at Leon, here are some of the improvements that have arrived recently.

Infrastructure autoscaling

Infrastructure autoscaling

As many of you are aware, Leon runs on an infrastructure consisting of several servers, for which we can considerately increase or decrease the number of machines. In the last few years though, it has been always done manually, by an actual person. As a result, it wasn’t perfectly efficient due to having the Leon server cluster operating almost constantly at a high capacity, to ensure swift performance of the application. The amount of server resources being increased or decreased happened mostly during the off-season, or during stages that required a lot of computing power.

Unfortunately, this also resulted in having servers operating at less than optimal threshold, generating a slightly less cost-efficient outcome. We knew that in order to optimise the server efficiency, we could shorten the server response time during the working days (when the server load was already quite high) without extending them during night-time or on weekends.

Our next step was implementing the actual automation of the infrastructure scaling (or autoscaling) so that it could occur multiple times during the day, without the human factor being involved. Currently the system automatically increases the number of servers and application containers during peak hours and then reverts the process when the server load decreases. Additionaly, we have introduced another mechanism, addressing spikes in server response times that may happen during the deployment of new releases. In the end, we have managed to optimise the server infrastructure efficiency, while our end users may enjoy Leon running faster and even more reliably.

New API nodes

One of the most common challenges for developers integrating with Leon is synchronising Leon’s schedule with their internal database. In order to simplify this process, we have introduced API nodes, which allow to access a limited range of data, including changes to the schedule or Journey Logs done after a fixed date. Due to this development, API users will be able to retrieve only new data, which translates into a decreased transfer of redundant data, lower server workload and lower risk of data desync.

The GraphQL Subscriptions

Apart from fetching data with Query and modifying it through Mutation, GraphQL API offers also another, less frequently used type of operation called Subscribe. While in case of Query and Mutation it is the client that initiates the communication with the server, GraphQL subscriptions are a method for pushing data from the server to the client. With subscriptions, API user can receive and react in real time to events happening in the application, such as modifications of records in a database. Because of that, it is possible to program a function, in which one user instantly receives an information about changes done by another user.

However, this is not the main reason the Subscribe operation exists, as we already have other technologies allowing that. Due to the declarative character of GraphQL queries, allowing to easily define the extent of data required by interface components, it is also possible to modify the application’s architecture. With lower need for data sync between database and end user, we can put an end to a number of potential errors resulting from the data desync and speed up the development process.

Creating a microservice to handle subscriptions wasn’t the only challenge we have faced, as it was also necessary to set up an infrastructure capable of supporting hundreds, or even thousands of operations simultaneously. We have decided to choose Redis as an event collector, as well as Pub/Sub system and an innovative, async PHP framework Swoole (https://www.swoole.co.uk/). On the client-side we have implemented Apollo GraphQL library.

This solution has yet to be made avaliable to the public, as it is still going through the testing phase in our development enviroment. Ultimately, we plan to provide external API users with an access to this system.

 


Not yet a member of Leon community? Contact our Sales team to find out more or jump straight into the 30-day free trial.

pszmagaj flight operations software

PAWEŁ SZMAGAJ linkedin logo

CTO at Leon Software

 

 

Since 2007 he is supervising the development and introducing new technology standards to help Leon Software maintain its position as a leading scheduling software provider for Business Aviation. 

 

TAGGED WITH

Subscribe and Follow Us

Below to Stay up to Date
flight schedule software