Just as we were iterating to reduce risk and gain experience. We were also increasing the scope of our work as the iterations went.

We didn’t expect to have to handle the hardware. Yet we learned how to choose it. How many servers we wanted per rack and why. Measuring the actual power load at full usage. With the help of the network team, choosing the right routers and cabling and finally doing the bill of quantities (BoQ). All that while learning to speak to the vendors. And at last submitting the orders.

Then it was overtaking the authentication components. The Identity and Access Management (IAM) & Billing team was too busy to deliver what we required, so we built our own authentication service and database change. We connected to their database and added the required token.

Then we had difficulties deploying our supporting services. We needed a dozen virtual machines but there was no platform team yet. So… We built our own infrastructure, provisioning the required hardware.

There was a push to have a single application programming interface (API) entry point. We couldn’t get guarantees for bandwidth and request per second capacity. We also used a different transport protocol. So we incorporated our own load balancer. Both choosing the hardware, doing the network design and assembling the right software together.

Historically, the first version of S3 had used the Scaleway domain as top level. A bucket being `bucket.s3.scaleway.com` or something similar. We were against using that domain for two reasons. The first one being reputation scores on the domain. A bucket could be used to host customer data. We did not control what they put in it. It could be illegal content that could have a negative impact on the domain scoring. The second one being, AWS used a different domain, why should we think we were smarter than them?

So, after a few back and forth, we choose one. Théo then purchased it for the company. It was the scw.cloud domain. We promptly hooked it up and used it for object storage. Every other team started using it subsequently after.

It’s not that we wanted to do everything ourselves. It’s that we assessed each component. Was there a clear team that was responsible for this? If not, we would do it ourselves. If yes, did the team have something that matched our requirement? Requirement could be the API availability or simply being able to take the required throughput. If not, we did it ourselves.

My general idea at the time was that everyone was building. We could take shortcuts and maintain them until we could handover the components back to the right team.

It was a balancing act. It was required because of Scaleway’s context. As time flowed, the context changed. A few years later it would require different methods.

Why was it so important to take temporary ownership? Because of latency.

(1) Photo by Loic: https://www.linkedin.com/in/loic-carr/​

(2) Photo by Loic

(3) Photo by Quentin : https://www.linkedin.com/in/quentinselle/; Nicolas : https://www.linkedin.com/in/nsampre/​

If you have missed it, you can read the previous episode here​

To pair with :

• Crescendo - The underachievers
• Ripe: A Cook in the Orchard by Nigel Slater