Behind the scenes
How we develop our software
by Oliver Herren
Team Darwin: the futurists among our software engineers
6.2.2018
Translation: Eva Francis
Pictures: Thomas Kunz
Research, refining, implementing, investigating – team Darwin shapes the future of our online shop. Let’s take a look behind the scenes of our engineering department.
«I've only been away for two weeks,» digitec engineer Michal Nebes states, «and now I hardly recognise my own job.»
His team members laugh and explain that the previous sprint, the one Michael missed, was a prototype sprint – after this sprint, nothing was as before.
Team Darwin is one of the youngest engineering teams of Digitec Galaxus AG. Their task is to build the online shop of the future.
«We’re not yet entirely sure how we’re going to do this», Daniel Zürrer, Junior Engineer, explains.
Team Darwin is responsible for figuring out the technological aspects of how digitec and Galaxus will work in the future. For this reason, their planning looks more like taking notes. The team discusses methods and potential solutions and weighs them up against each other. They reject some and accept others.
Intelligence in the cloud
Team Darwin was set up six months ago. This team is different to the other engineering teams: While all others have names from James Bond movies (Skyfall, Octopussy, Spectre, Goldeneye, Goldfinger and Thunderball), they are named team Darwin, they live in the future and always try to be at least one step ahead of everyone else.
They work in two-week sprints and are always under time pressure. The five backend engineers, the two user experience designers, the front-end engineer, the product owner and the user experience researcher – that’s the entire team – get together and discuss the last sprint. What worked well? What didn’t? Which adjustments need to be made?
«Our work involves dealing with unknown variables and unresearched subject areas,» Daniel Zürrer explains.
That’s why Agile Development works so well for team Darwin.
Agility is an incremental and iterative approach in which a project is developed in small steps. The status quo is checked after every step and, if necessary, adjustments are made. By doing so, team Darwin remains flexible enough to adapt to current developments, trends, best practices and security standards.
Team Darwin was founded in August 2017 with an ambitious aim in mind: Galaxus and digitec shall only show you things that you’re interested in. And, as we’re all interested in other topics, different content is displayed to every user. A lot of data analysis and abstract thinking is required to make this work.
Before Darwin started working on the online shop, they implemented a recommender in the cloud. This was proof of concept (PoC).
This is how the team described their plans on the development site: We want to push View Events into Google PubSub, process them with Cloud Dataflow and store them in BigQuery. A Cloud Dataproc job runs every night, which reads the data from BigQuery, carries out Collaborative Filtering and saves the results for every customer in Cloud Datastore. To read out the calculated data, we intend to have an AppEngine instance that runs via a cloud endpoint and reads the results from Datastore. Everything is logged centrally in Stackdriver.
Shortly afterwards, they wrote: The current version in January 2018 looks a little different. Cloud Dataflow turned out to be an overkill, which is why we now have a lightweight .net core application that runs in a Docker container, processes PubSub messages and stores them in BigQuery. We have named this component Hephaestus, after the Greek god of metalworking, as this component also works PubSub news into new formats. The calculations still run as it was intended in Dataproc, but we also work with a .net core Docker image, which sets up the environment for Dataproc, initiates the job and finally removes the environment.
They continue to write: As planned, we use a cloud endpoint to read results. This simplifies logging and security processes. However, after several iterations of Appengine, we replaced the backend with am ASP.net core application running on Cubernetes.
Team Darwin doesn’t just implement technology to solve problems. Their aim is to find the most efficient, lean and performant solution. The leaner a solution, the fewer resources are needed, the better the shop performs and the fewer failures are expected.
This brings up the core area of their work: the cloud. Decentralised data storage and distribution across multiple redundant systems. More stability, more uptime, no problems. Really?
The problem with the cloud
Migrating the online shop is tricky. The document that team Darwin has drafted and is now working on describes the lean approach the team are aiming at as well as other challenges they faces.
One of their main discussion points is Pythia. They write: Pythia is best seen in the context of agile development. Pythia – named after the oracle of Delphi – handles the recommender and is an adapter for a Datastore.
The concept of Pythia started off simple: Team Darwin planned to use the serverless Node.js applications based on Google's newly introduced cloud functions. These functions looked perfect for their purposes.
But this plan was ruined. It turned out the cloud functions can currently only be hosted in the US. This means, to operate Pythia with cloud functions, critical business data from the Swiss legal area would have to be transferred across borders to the US. And that's not all:
- Research revealed that the functions aren’t compatible with the cloud endpoints.
- The latency is too high if you’re located in Europe.
- Digitec Galaxus would have to implement the authentication and logging processes themselves.
Conclusion: Google’s cloud functions are a no go.
The mission isn’t over; a new solution needs to be found. For now, the solution is called AppEngine. AppEngine provides a simple environment for hosting software projects in languages ranging from Python to Go, Java and C#. This engine is something between a minimal cloud function and an entire virtual machine in the cloud.
Team Darwin takes up work with AppEngine in the standard version with Python 2.7, because version 3 is not supported, when their work is brought to an abrupt halt: The Google Python libraries for cloud endpoints don’t work with the Datastore. You’d assume that Google libraries are compatible with each other, but this is not always the case.
But that's not all: On top of this incompatibility, there’s also no alternative to the Cloud Endpoint Framework, which requires definitions to be created from the Swagger API code. This creation was programmed (by Google) in Python and is terribly unstable.
After deployment is before deployment
Despite all these obstacles, «no problem» is the prevailing opinion in Darwin team. The solution:
- Python 3
- AppEngine Flex
This set-up allows the engineers to define the endpoint in JSON. Next, they want a Python backend. But Python is said to be too expensive. «As expensive as Docker,» the engineers admit. They’re currently working with C# and Docker.
For now.
They’ve already taken up discussions on further developments. This time, they’re discussing – not technologies. They talk about the future of the online shop, potential new features and how to implement these in a lean, fast and reliable way. The team finds it difficult not to get bogged down in details in these kinds of discussions.
After deployment is before deployment; team Darwin keeps on researching. The engineers are aware of their task: They are the ones who shape the future of the online shop.
By the way: Team Darwin wants you to know that our engineering team is recruiting. If you’d like to join the team, take a look at the following vacancies:
There are more job vacancies from our engineering department here.
Want to know how our software development is developing? Check out this article.
Journalist. Author. Hacker. A storyteller searching for boundaries, secrets and taboos – putting the world to paper. Not because I can but because I can’t not.
4 comments
later