On a normal day, we ingest a lot of data into our ELK clusters (~6TB across all of our data centers). This is mostly operational data (logs) from different components in our infrastructure. This data ranges from purely technical info (logs from our services) to data about which pages our users are loading (intersection between business and technical data). At trivago,we use Kafka as a central hub for moving data between our systems (including logs).
Throughout my career, I’ve had times where I worked 100% remotely. Overall working remotely can have benefits and even make you more productive as an engineer. I would like to share 5 tips that have worked very well for me. TLDR: Communicate more than you would normally do. 1. Leverage working asynchronously This might seem as a disadvantage initially, but leverage that you are not communicating synchronously with each other.
“The Cloud Native Computing Foundation (CNCF) hosts critical components of the global technology infrastructure. CNCF brings together the world’s top developers, end users, and vendors and runs the largest open source developer conferences. CNCF is part of the nonprofit Linux Foundation.” - CNCF Last year, when visiting CloudNativeCon/KubeCon Europe in Barcelona (one of the biggest cloud-focused conferences in Europe), I noticed that there were some companies present in the exhibition space whose primary focus wasn’t software development.
Imagine you go to your hotel for check-in and they say that your dog is not allowed even though the website clearly states that it is! trivago gets information about millions of accommodations from hundreds of partners and they keep on updating. There are many differences not just in the data format, but also in the data itself. There can be many discrepancies in the information and consolidating them can be a very complex process.
We recently hosted a Q&A on our trivago tech Twitter and Life at trivago Instagram page, where we gave our followers the opportunity to ask our developers anything. Even though we tried to answer all of them on the day, we decided to compile some of the most recurring questions and their answers for you below! Getting a tech job at trivago Do you offer any opportunities for React developers?
trivago open sourced a Prettier plugin for the Twig template language. It is available under the Apache 2.0 license, and you can access it on trivago’s Github space. The trivago core product runs on our own frontend framework Melody. Melody uses a Twig-inspired template language because when it was introduced, it had to be interoperable with our existing codebase, which was based on the Symfony PHP framework with Twig as the default template language.
To the outside, trivago appears to be one single software product providing our popular hotel meta search. Behind the scenes, however, it is home to dozens of projects and tools to support it. Teams are encouraged to choose the programming languages and frameworks that will get the job done best. Only few restrictions are placed on the teams in these decisions, primarily long-term maintainability. As a result, trivago has a largely polyglot code base that fosters creativity and diverse thinking.
Tackling hard problems is like going on an adventure. Solving a technical challenge feels like finding a hidden treasure. Want to go treasure hunting with us?
View all current job openings
A quick recap At the end of last year, to celebrate our continued sponsorship of the Open Source community, we hosted a small conference with special guests at our Düsseldorf campus. We initially hoped to welcome Tobias Koppers and Sean Larkin from Webpack, plus some internal speakers. What we didn’t expect was the huge amount of fantastic speakers who wanted to present their projects to the community. In the end, Sean unfortunately couldn’t make it but we did have a chance to welcome Marvin Hagemeister, Juan Picado, Norbert de Langen and Pia Mancini as speakers, plus our own amazing talents.
At trivago, we generate a huge amount of logs and we have our own custom setup for shipping logs using mostly Protocol Buffers. Eventually we end up with some fields in Elasticsearch (ES) that contain partial (or full) URLs. For instance, in our specific case we store the query component of the URL in a field called query and the path component in a field named url_path. Sample values for these fields could be: