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
2016 has been a very busy year at Trainline as we have been growing at a rapid pace. This means our tech team has had to work hard to scale effectively and cope with the sheer demand.
New product teams have been springing up all through the year, while older teams have grown and been split into sub-teams to maintain the essential agility of small teams. With such growth, we have needed to ensure our processes were in good shape to manage the increased complexity that this brings.
Here are a few fascinating stats which tell a short story of the year at Trainline … Continue reading
STEP 1: A HACK TO SOLVE OVERCROWDING
When I participated in Hack Train a few months back, the big hackathon for the rail industry, the challenge was to improve customer comfort within 2 days (while travelling on a train without a proper internet connection!).
Just over a year ago we were set the challenge of ‘spotting problems and fixing them before our customers notice’. To spot the problems we knew we had to change our behavior from only opening our logs when an issue was suspected, to making them available at the touch of a button to our engineers so it was easy for them to monitor their applications and spot problems and fix them.
Ash Powell’s blog explains how we did this, ‘What the ELK!? – Log Aggregation,‘ and here’s a short film we’ve just completed with Elastic to explain our business and how ELK’s role:
Keeping trainline on track
You are sitting at your screen reading a blog about the death of monolithic databases:
“Monolithic databases are so 80s, inflexible, they are an obstacle to change. Referential integrity stops us implementing service orientated architecture, and they cannot be harmonised with continuous delivery”.
And you agree.
Well, you may be right, sometimes, but I assume you don’t agree with the following two statements: Continue reading
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