Multi-cloud strategy: A tale of two farms

Restaurant and a farm

A highly successful restaurant sources its produce from Farm A. This farm produces a generic variety of fruits and vegetables. However, the restaurant has also built some custom exotic vegetables using Farm A’s infrastructure. Restaurant uses its own seeds but builds using farm processes, hi-tech solutions, rich quality of soil, water, nutrition and sensors created by Farms Research and Development team.

Restaurant has invested heavily in tools and technologies to place orders in advance to the farm. Dedicated custom supply chain integration with the farm is in place, and there are solutions to monitor deliveries and quality of deliverables coming from the farm.

The Beginning

At the onset of its business, the restaurant’s Managing Director asked the CEO “I need a month, so that I can focus and dedicate time on the following concerns before we start our first restaurant.” Questions he raised were:

1) What if Farm A gets flooded and we cannot get the produce for few days

2) What if Farm A increases cost suddenly after we launch our restaurant and cannot walk away from vendor easily

3) We should think of building our own farm and be self-sufficient before we start our restaurant

4) We should link our systems with two farms at the onset, and invest on integrating with at least two farms before we start our restaurants.

The CEO listened patiently to his concerns. He said,

“These look very familiar. You seem to be talking about the problems which the tech world also faces these days. 1) Cloud goes down due to natural calamity or human errors 2) Vendor lock-in and cost risk 3) Self sufficiency by building own data centers 4) Multi-cloud adoption”.

After pondering over for a few minutes, the CEO says “These are valid and pragmatic questions, but do not waste your energy on them at this juncture” and out rightly rejects them. “These are not important issues, when we are just starting our business. There is always a risk in our supplies and integrations with one farm, but let us build our business first, get customers onboarded, generate reasonable revenue and then talk on these risks, when we are on the cusp of growth”

Three years later

Over the years, the restaurant has become quite popular in the town and the owner plans to open four more restaurants in the suburbs.

The Managing Director raises the alarm again and cites the same questions which he brought to the fore at the onset, years ago. The CEO listens to him seriously this time, and goes back to the drawing board.

After careful deliberations with the team, they break the problem into two parts:

1. Generic Produce — Generic variety of produce, which is not dependent on the farm technology, solutions and raw material
2. Exotic Produce — Exotic product which restaurant has custom built using the proprietary soil, technology, water and elements of the farm

The outcome from day long meetings brought out some clear discussion points.

For the first part, they agree that “Generic Produce” can be procured pretty much from any farm, with the same quality and flavor, given the adoption of government recommended standards by all farms. They come up with three strategic options:

1. Onboard Farm B with 10% weightage: We establish relationships with two farms (A & B) instead of one farm, and we use Farm B as standby. We establish basic integration and buy bare minimum produce from Farm B. We will be at good risk though. Time required to switch fully to Farm B will be quite high. Shifting our operations will come at huge cost, delay, additional manpower and skillset, and possibly, business downtime, but are better off than one farm relationship.
2. Onboard Farm B as equal partner: We can have 50% supplies from each farm, and we will bear substantial cost of integrating with their systems and supply chain. There is an overhead of maintaining integration with two farms and building tools and manpower to enable and monitor it. I genuinely wish there was an “intermediary farm vendor” who could be our only point of contact and take care of multi-farm integration and allow us to have a good sleep. After all, multi-farm management is not my core business. CEO: The other day, my director friend from Walmart board mentioned “Why is anyone not building such an intermediary layer for cloud? Although it’s shrouded with complexity and proprietary products, there is a burning need for it. I have heard of Google Anthos and plethora of IAAS and CI/CD tools but that is not enough”
3. Continue with Farm A only: We continue with a single vendor and live with the risk, which has always been there in some form, irrespective of the model we adopt. CEO: I recall — Netflix built their business from single farm produce (aws) with acceptable risk and did pretty well. Their farm (aws) does get flooded once in a while but so does anyone’s farm. Imagine, if they had slowed down at the start, to build their own farm or would have tried to use two farm (cloud) vendors instead of one. I am sure, they would have lost precious time and advantage to build their multi-billion dollar business. I am glad common sense prevailed.

After some more deliberation on Generic produce, conclusions are drawn and agreed upon.

They were:

“We will continue with Option C (single farm), but with changing times and to address some of the concerns raised, let us start implementing Option A partially. We establish relations with Farm B as well, and place bare minimum non-critical orders to them.

So far so good!

Team is elated for drawing conclusions in a single meeting, which usually takes weeks and months. But the elation is short lived. The challenge of making ‘exotic custom produce’ risk free, remains.

CEO: “Our restaurant specific custom built produce which we have invested quite heavily on, is tightly integrated with Farm A’s proprietary material and solutions” What choices do we have?

Once again, team spent hours huddled together and comes up with following points:

Farm-native advantage and decision dilemma

Can we create similar produce from Farm B’s native solutions, just as we do from Farm A?

Maybe Yes, but we have to put in a lot of effort, energy and money to understand the innovations that Farm B has done, and then connect those dots, freshly, to build a product of similar quality which Farm A produced successfully for years. This is complex.

CEO: This makes me feel I should never have used Farm A native solutions. But, wait a moment, why am I thinking of Farm A as a villain? What if I continue with the existing model, although at some risk of floods once a year, and increase in cost at the will of the vendor, if at all. This custom produce has helped us generate millions of revenue at a reasonably fast pace. Let us continue to use Farm A’s native innovative offering”

He then tries to relate this problem with the tech industry — “These are like cloud-native solutions in the cloud world, where each service offers unique value, which cannot be easily replaced or matched by other vendors. Efficiencies (serverless and managed offering) brought in by cloud-native solution, help build products fast, which can be taken to market in less than 10% of the time it used to take earlier, at equal or less cost”

Shifting away from farm-native solutions

Can we use soil, water, solutions available in “open market” and ask Farm A to use those instead of farms proprietary offerings? Yes! That sounds like a fair idea. Although we may not get the exoticness, efficiency, quality and quick delivery we truly desire, this looks to be a reasonable option. Now, we can ask Farm B to use the same open market ingredients, and provide the same output as Farm A, as and when we need them. We can promise them 10–50% of orders. This is the same as “Generic Produce” approach, we discussed earlier.

CEO: “My friend in Walmart calls it multi-cloud strategy, where ‘open market’ means ‘open source’ or ‘non-cloud native products’. You may not get the efficiency of native products but you will be fine, may be a bit slow in your journey. It is workable. You will be able to switch your cloud (farms) since no native services are involved, but it will come at some effort and cost.”

Post these conclusions, the deciding team is given three options to choose from via voting, which will help the company define the right strategy with consensus:

1) Farm-native (cloud-native)

2) Open Market (open source/non-cloud native)

3) Hybrid Approach (both native and open market)

The outcome of voting is:

50% voted for hybrid, 20% for farm-native and 30% chose open market

Although, hybrid is the favored approach, it lacks majority. Team concludes that there is no ‘one size fits all’ solution.

They decide to break down the requirement into multiple segments and then map them to one of these three voted options. A board meeting is called out to take the final decision which should be pragmatic, cost-effective and implementable.

They conclude the following:

1. They will engage with two farm (cloud) vendors with 80–20 share for non farm-native (non cloud-native) requirements
2. They will make use of the evolving space of intermediaries (tools and solutions) which take away some pain of multi-farm (multi-cloud) management and make portability easy.
3. They will continue with single vendor for “cloud-native” solutions which guarantees agility, speed, innovation and low operational overhead .

What next?

Company raises a requisition to hire a seasoned consultant in the space of multi-cloud architecture and strategy :)

One more title addition in our ever- evolving technology space.