Since my talk at AWS re:Invent in December, we’ve had a lot of questions about how we tackled our Oracle Exadata migration to AWS.
This post goes through our Oracle migration journey in more detail and also includes some general tips for moving large databases to the Cloud. Continue reading
Whenever I reach a milestone or finish something, I pause and reflect on the journey and what I have learnt. I’m going to talk about our journey of migrating one of our systems from MSMQ to SQS.
When we started, we had a system that looked like this:
(click here for the English version)
En janvier, nous avons appris que la SNCF souhaitait mettre à jour son système tarifaire, c’est-à-dire l’ensemble des règles qui déterminent le prix d’un billet. Elle laissait tomber les prix des périodes d’affluence des TGV, elle diminuait les changements de prix brusques, elle offrait tant de cadeaux aux porteurs de cartes de réduction que ça sentait bon Noël.
Mais ces nobles objectifs s’accompagnent de grands défis. Tout comme une princesse doit combattre un dragon pour délivrer son prince charmant, la SNCF devrait combattre son système tarifaire actuel pour en extraire une perle de ses cendres. Le sang de ce combat ne pouvait éviter de couler sur leurs partenaires : les guichetiers, les agences de voyage, les GDS, et nous.
Les systèmes tarifaires n’ont qu’à bien se tenir !
(cliquez ici pour la version française)
Back in January, here at Trainline Europe, we learnt that SNCF, the main French railway company, wanted to update their fare system — that is, the set of rules which determine their ticket prices. The plan was to scrap congestion pricing on TGVs (France’s high-speed trains), reduce sudden price increases, introduce so many offers to discount card owners that it would feel like Christmas!
However, those goals were not without challenges. Just as a princess must defeat a dragon to free her Prince Charming, SNCF had to fight the complexity of its current fare system to extract a pearl from its ashes. The blood from this fight had to drip onto their partners: counter agents, travel agencies, GDSes … and yours truly.
Fighting fare systems requires extensive equipment.
You’re probably a medium-to-large-sized company, you run a medium-to-large application. You apply all the industry best practices, using micro-/plain-old-service architecture, compartmentalise your system into nice tidy chunks. As they usually do, your DB admin doesn’t like to maintain multiple databases and so you’ve been restricted to run everything under one fairly large database.
One fine day, you decided your data is important, it needs integrity. You decided the best thing to do is to introduce foreign keys.
You may have just made a big architectural mistake
When building a software system the biggest problem we face is change. Requirements change, technologies change, traffic on our web application changes, everything changes and our software that was perfect just a moment ago, now is broken and no longer suitable for our purpose. Continue reading
This post is part 3 in a series. Read part 1 and part 2.
Part 2 finished detailing our relatively recent move to Product teams, a change that has had a big impact on our delivery process.
While this is definitely an exciting change, with product teams having a lot more responsibility from development to live, it highlights the fact that Development and Test environments have some needs that are similar to the Live environment, but also differences that must be clearly understood and supported, potentially in a different way to the Live environment:
This post is part 2 in a series. Read part 1.
thetrainline’s Journey in Improving Throughput
From a very early point in thetrainline’s journey it was clear that the web site was only the tip of the iceberg and that there would need to be a continued programme of development to: improve customer experience; adapt as web technology evolved; and as more automation was implemented in back office processing from initially fulfilment to most recently refunds. In the past 14 years rail travel has doubled in size and the customer’s expectations have also risen. Although journey planning and advanced purchase ticketing are well planned and carried out in advance the immediate future will see more innovation in ticketing from smart cards supporting multiple train operators to NFC payment and potentially ticketing. In order to be able to provide the required levels of service at the relevant price for the product and across all channels and devices thetrainline will need to continue to improve the throughput of ideas through to production implementation.
DevOps is a part of the natural evolution of Agile Development and Continuous Delivery. Where quick feedback from the use of a system by its users in the production environment helps to drive the next phase of the product; maintain or improve the rate of change and the total cost of ownership. But the fundamental principles of DevOps are not new. Developers have been seeking an understanding of how their code behaves from the first line of code written. This post summarises the DevOps journey at thetrainline.com and how Operations have embraced the principles of DevOps with the goal of achieving Continuous Delivery. DevOps is a key part of the answer to improving product throughput BUT it is a small part. This post details my 12 year journey with thetrainline.com but, more importantly, the wider need for Developers to learn from others involved in a product’s life-cycle, both from a historical view point as well as the capabilities available today. For the continued growth of a business the tools and processes required to reduce the time taken for feedback from live use of a product are essential to both a start-up and an enterprise. Continue reading
At thetrainline.com we are currently working hard at re-engineering our e-commerce retailing platform to streamline the development of new features. This will allow better product offerings, innovation in ticket delivery methods, enhanced payment options and, above all, a cutting edge mobile experience. While our current platform is serving us well, as with all technological platforms, it is slowly becoming outdated and increased coupling is creeping in. As a result, our ability to change has been slowing down and this is not something we are ready to accept.
As part of the re-engineering work, we have been ramping up our use of RabbitMQ as a messaging infrastructure to build components for our new platform. While most of us are already familiar with building event-driven applications using NServiceBus/MSMQ, designing applications to communicate over RabbitMQ has its own unique challenges.
Here is a presentation from one of our weekly brown-bag tech talk sessions about some of the key considerations when developing new components leveraging RabbitMQ.