Why our heads are in the cloud - 1/3

While our feet are on-premises

François Bouteruche
My Local Farmer Engineering
6 min readJun 17, 2021


In today’s episode

This is the first article of a series explaining why I Love My Local Farmer has decided to embrace the cloud. Below, Inès Abderrahmane, CTO of I Love My Local Farmer, describes their on-premise footprint and why the engineering team decided to open a second data centre in 2017. To conclude, she shares her thoughts and learning as of now. In the next post, she will highlight the benefits that I Love My Local Farmer was expecting from the cloud. Finally, in the third article, she will disclose how the engineering team handled the discussion with the CFO.

I Love My Local Farmer is a fictional company inspired by customer interactions with AWS Solutions Architects. Any stories told in this blog are not related to a specific customer. Similarities with any real companies, people, or situations are purely coincidental. Stories in this blog represent the views of the authors and are not endorsed by AWS.

Our feet are on-premise

In our first post about Working From Home, my engineering team already disclosed parts of our on-premise infrastructure. I would like here to expand a little bit on it and how we manage it. If you read our launch announcement post, you may know that we started the I Love My Local Farmer platform back in 2010 in France. We were leasing some space in a data centre based in Paris. We bought, installed and operated our hardware. Progressively, the few heroic people who were operating our infrastructure became THE Infrastructure team as our platform and its traffic grew. One of the main critical tasks that they were handling was capacity planning. They were accommodating for the current hardware requirements of our engineering projects, as well as planning ahead for eventual growth in consumption, and hence load, when planning the budget for hardware investments.

Of course, not all projects had the same priority. We always prioritized hardware investments that would be dedicated to our production e-commerce platform. Our development and test environments, our internal productivity system, and the network file storage for our employees were lower priority. The reasons for this are straightforward. First, it’s easy to justify investment in the system that puts money in the bank. Secondly, if we overspent on our capacity planning budget, we could always postpone the non-critical IT investments and go ahead with the production system upgrades. Handling unsatisfied employees because of lagging internal IT system isn’t something pleasant but, always better than handling business stakeholder dissatisfaction because of poor performance of the end product.

We operated this way until 2016. In early 2016, our Paris data centre encountered a major outage that impacted our e-commerce platform for a couple of days. The only way to address this outage would have been to have a secondary data centre in another region. Through the years we had already encountered some small outages, but never such a large-scale outage as this. Indeed, when we opened the platform in 2010, the company was small and operated only in France. Five years later, we were operating in four countries: France, Spain, Italy and Germany. This turned into a loss of several hundreds of thousands of euros in sales alone. It also spoiled the trust of the customers and farmers in our platform, which impacted our growth for several months. Back in 2010, investing in a Disaster Recovery data centre would have been a financial nonsense, but in 2016 it was a worthwhile investment. As a result we began a Disaster Recovery project to lower the impact of such an event in the future.

When we launched, the idea of having a Disaster Recovery system in the Public Cloud was already a topic, and so we did our due diligence by researching the possibility of a Cloud migration. Our preliminary analysis revealed similar value propositions between each of the major cloud providers: to pay only for the resources that you use, and to offload heavy lifting tasks onto managed cloud services. The main differences reside in the breadth and depth of services available, the reliability of the provider, their global footprint, and the number of people trained in their usage.

The analysis showed that setting up a Disaster Recovery plan is a well-addressed topic. Cloud providers like AWS in its whitepaper offer several options from a simple backup and restore strategy to a multi-site active/active strategy. It all depends on your business requirements.

However, the analysis also highlighted a change in the expenditure model when you move to the cloud. While on premises, your IT Budget is based on a capital expenditure (CAPEX) model, in the cloud, it’s based on an operational expenditure (OPEX) model. We had a discussion with Sebastian Feldmann, our Chief Financial Officer, and agreed that we wouldn’t jump into a cloud adventure without further discussions and analyses on the impact on our IT budget. In fact, the main concern about moving to the cloud was the probability to impact our IT budgeting. Monthly spend variations could impact our margins, moving from a predictable budget to variable expenses wasn’t something he was open to, without knowing how we could control the spend.

The analysis pointed out that securing customer data on the cloud is a sensitive topic too. While Cloud providers seemed to offer security services and security features to handle this topic, Qiao Lǐ, our Chief Information Security Officer, needed more time to investigate and to figure out how we could follow regulatory requirements like the upcoming GDPR and the PCI-DSS.

Finally, despite the appealing options offered to set up a Disaster Recovery plan, we decided we weren’t mature enough to migrate workloads to the cloud, and that more investigation and training were required. Hence, we decided to rely on what we knew and opted for opening a Disaster Recovery data centre in Berlin. We knew we had a mature infrastructure team that would be able to deal with this. In 2016, we took our decision based on the information available to us and we are proud of it! In 2017, our Disaster Recovery data centre was up.

Final thoughts

Now, we are in 2021. I would like to share my conclusions and learning with you as the CTO of I Love My Local Farmer. Here are my thoughts.

Twice we have faced an unexpected situation that we were not prepared for. In 2016, a major outage in our data centre, and in 2020, a worldwide pandemic breaking our procurement lines.

As CTO, part of my job is to put our company in a position where we have the right data to make quick decisions. This is so that we can adapt, continue and improve our business. We should be prepared for the unexpected. We must embrace change. Presence of change is the only constant thing in IT, and even the rate of change changes.

A lot of success stories demonstrate that it would be against current trends to not leverage at least one cloud provider. During the pandemic, Cloud Service Providers have demonstrated that they were the only option to continue providing infrastructure resources at the needed pace. Our procurement tried to convince us to involve as many cloud providers as possible so that we could get the best set of prices. I know that having one provider could be risky, and part of my role is to mitigate risks. On the other hand, if you want to learn a new language, you do not want to start by learning three different languages at once; before you even start, you know that you will not be as efficient as if you only learnt one at a time.

Because of the pandemic, our needs changed literally over night and we were forced to experiment. Without the pandemic, it is possible that we would have stayed in our technological comfort zone longer. We weren’t scared, we were just unsure. Our approach worked for the last 11 years, it would definitely have worked some time longer. This unexpected situation pushed us to act. We made a bold decision to give the cloud a try. We started by moving our Working From Home infrastructure to AWS, and then we implemented our Serverless Java Solutions for Deliveries on AWS. We were positively surprised with the outcome. We wanted more!

We have decided to take the next step and write down our cloud strategy, which we will share with you in the following posts in the series.

Useful Links