In this third post, we look at the migration efforts, the mistakes we made and where we are now heading.

In the second of three posts, we look at the the actual physical and virtual infrastructure, their setup and the number of changes made to bring the platform up to date in 2019.

This is the first in a small series of posts about the work behind the scenes to move the entirety of Realtime Trains infrastructure. This post concentrates on choosing the new datacentres and the initial work to get everything moving. Realtime Trains is almost entirely hosted on equipment (servers, firewalls, routers, switches, etc) and this is in space rented within datacentres, commonly known as co-location. We do this predominantly as it is, and remains, the most cost-effective way we have found of operating with a fairly constant base load.

In early 2017, we spoke about the future of Realtime Trains. We have, in the background, been continuing to work towards releasing the next system. We are working on a new area of interest for us, and as part of that we need assistance. A lot of the work behind the scenes performed by a small team involves maintaining data relating to train positioning and comparing this with the signalling system outputs we use.

It’s been a while since our last proper update. Since the last update, I hired a new systems engineer (Chris), have done substantial charity work in Africa, RailMiles was finally relaunched and over the last six months we have been continuing to develop Realtime Preserved Trains into a proper product. We’re also working on updates to Realtime Trains itself, as we have been since the last major update in August 2013.