Although it always seems that many questions need to be asked before starting a project, in reality, they all boil down to one very simple Yes/No question…

Should we do it?

This blog outlines the way cloud is revolutionizing the answer to that question, by raising many projects that would have otherwise fallen into the lowly “No” bucket, up to a “Yes”, in the cloud.

Surprisingly, the reason for this isn’t directly related to in-cloud computing costs versus on-premises computing costs. In fact, in some cases, costs might even have been lower on-premises and still, economically, the project would have been a “No” on premises, but a “Yes” in the cloud. Indeed, it is another aspect of cloud that enables it to save projects from the realms of oblivion. That being, the financial impact of its practically endless elasticity.

We will prove all of this shortly and I will not forget to return to the question posed in the blog title. However, as has been my custom in the previous blogs in this series, I will start with a classical pre-cloud example to illustrate the principle, and then turn to the impact of cloud.

To keep the subject relevant, our example will remain in the realm of infrastructure.

**How to Evaluate a Project – The Tel Aviv Subway Example**

Mr. Jones runs an infrastructure company. He is given the opportunity to run a lucrative project, building the first subway line of a metropolitan city, in our example, Tel Aviv. The terms of the deal are simple: build the subway line and you get the revenue from passenger tickets for 10 years after the line opens.

Should he do it?

Mr. Jones does not run a non-profit organization, so there is really one factor affecting his decision. Will taking the project create value for his company? Value for him is measured in dollars, so he asks his finance team to estimate the cost and revenue from the project. After some work, the team comes back with the following forecast. The main expenditure in the project is boring the tunnel for the subway. He will need to get a boring machine from China to Tel Aviv, and this involves a fixed setup cost of $150K. The team estimates that it will take the machine 10 years of work to complete the project with each year adding another $150K of operating costs. All in all, estimated costs would be $150K+10*$150K for a total of $1.65M. But then the fun begins. The team estimates that given that this is the first and only metro line in Tel Aviv, ticket sales would amount to $400K each year. So, starting in year 11 (just after the boring machine finishes the line) and for the ten years up to year 20, Mr. Jones’s company would be making $400K a year, for a total of $4M.

This seems a no brainer. You invest $1.65M and gain $4M. Surely value is created?

Well, no. As Mr. Jones financial advisors are quick to point out, there is a catch. All the investment money is going out in years 1-10, while all the income of the project is received in years 11-20. And a dollar promised to be delivered 20 years from now, is certainly *not* worth the same as a dollar one gives up today.

Luckily, financial wizards have devised a way to evaluate projects when expenditures and revenues are spread over time. The method is called net present value (https://en.wikipedia.org/wiki/Net_present_value). While a full review of this method is beyond the scope of this blog, the basic idea is that future promised sums should be discounted when evaluated today.

The net present value takes into account the expenditures and incomes ** after considering this discounting over the years due to the time value of money**. Selecting a discount rate of 10% per year, I will let those of you who want to do the math, follow the calculation here. For the others, I’ll just give the result: Unfortunately, the math turns out on the down side. The income is just too far out into the future. The future risky gain is outweighed by the present certain expenditures. As indicated in the table below, the net present value

**One Machine Project**

Setup Cost |
Expenditure/year, years 1-10 |
Income/year, years 11-20 |
Net Present Value at discount rate of 10% |

-$150K | -$150K | $400K | -$121K |

A sad result for Mr. Jones, and for the people of Tel Aviv. This blog would have ended on a negative note, but for a strange twist of events. Mr. Jones decides to take the weekend off and visit Jerusalem.

**King Hezkia to the Rescue**

While visiting Jerusalem, Mr. Jones stumbles upon the King Hezkia tunnel (https://en.wikipedia.org/wiki/Siloam_tunnel). Upon learning that this ancient tunnel was dug by two teams working from both sides to meet at the middle, he has an epiphany! Why don’t I order a second boring machine! With two machines working one towards the other, the project will finish in half the time and the revenue stream will start earlier. He runs back to the drawing board and redoes the math. The cash stream now looks different. Sure, he needs to increase the setup costs to S300K to bring two machines, and maintenance is twice as much for 5 years, but the revenue starts pouring in much earlier, with the initial income appearing in year 6.

**Two Machine Project**

Setup Cost |
Expenditure/year, years 1-5 |
Income/year, years 6-15 |
Net Present Value at discount rate of 10% |

-$300K | -$300K | $400K | +$127K |

Eureka! With revenues streaming in much earlier, their present value becomes higher and the project net present value turns positive. Let’s start digging.

But wait, he thinks, can I do more? He comes up with what seems a brilliant idea. The subway track has stations dug up along the route. What if I bring over 10 boring machines, put each machine at one of the stations and let the ten dig at the same time, each towards the next station? This way the project completes in just one year. He takes another stab at the net present value calculation.

**Ten Machine Project**

Setup Cost |
Expenditure, year 1 |
Income/year, years 2-11 |
Net Present Value at discount rate of 10% |

-$1,500K | -$1,500K | $400K | -$542K |

To his horror he discovers that the net present value flipped back to the negative. What just happened? We are seeing the combined effect of two opposing forces. One the one hand, more machines means bringing the revenue in sooner and hence increases the project value. But on the other hand, bring in too many machines and you start to suffer from the wasted setup cost of each machine.

As Mr. Jones discovers, ** when there is a setup cost attached to each machine you use**, the net present value of a typical project can be graphed as below.

Use too few machines and you will reach the market too late, negating the value of your project. Use too many machines, and your setup costs become prohibitively expensive. In between, you may (or may not) find a quantity of machines that makes the project worthwhile.

**Why the Cloud Changes Everything**

A machine is a machine, and infrastructure is infrastructure. And while the silicon-based servers in data centers bore through data rather than dirt, they serve the same purpose as their larger metal-based brethren. Namely, getting the project to value creation as quickly as possible.

“So what did the cloud change?”, you may ask. What is the critical difference between classical on-premises infrastructure and the Infrastructure-as-a-Service of cloud?

What is it in the words “as a Service” that transforms the economic equation? To answer this question, let’s look at the project net present value in a world in which setup costs are practically zero.

In the cloud, Infrastructure is payed for on a consumption basis…i.e. there are no setup costs associated with starting up a machine, you just pay for the time you use. This means that paying for 1 machine running for a year, or 365 machines running for a day costs exactly the same. ** As long as your workload is divisible among multiple workers**, there is no “tax” for setting up more hardware to complete your project earlier.

Before cloud, you had to perform a delicate balancing act when selecting your project resources. If you selected too few resources, you deliver late and lose value. If you selected too many resources, your setup costs might bury any future profit. **In the cloud this no longer holds.** Selecting too few resources will still produce a negative net present value because results will come in late. However, in the new realm of cloud, there is no reason not to use **as many workers as you can divide our workload between**. Yes, you heard me correctly, use the largest number of servers possible to finish the job as early as possible. Your finance guy with thank you for it! Remember, the minute your servers finish boring just shut them down. There is no penalty.

You are going to pay the same if you use 10 servers or 1,000 servers to process the same data. But 1,000 servers will do the job a lot quicker, and the sooner you get to market, the higher your impact and the larger the value created.

This is especially visible in machine learning workflows. Before a project makes worthwhile inferences, a model must be trained. Training involves an immense amount of data ingestion and processing. In many cases finding the best model also involves changing hyperparameters to train multiple models and find the best one. All of this takes time…and time decreases value. Slow your processing and you go to market too late or come out with a sub-optimal model. Accelerate your processing and increase your power and you get to market sooner and with a better product.

Which brings us back to the opening question. Can 9 AI’s make a baby in 1 month? Probably not. **But they sure can produce a lot of net present value.**

And one more thing. If you want to spin up an elastic file system to efficiently serve data to as many AI nodes as possible, you’re in luck. Elastifile just announced the availability of our file system on Google Cloud Launcher. Check it out **HERE**.