I have a new car and I love it. To achieve better fuel efficiency, it tells me when to shift. Now I like to get to know my car, so I keep a close eye on how much fuel I use. The display can show me this in real-time. While driving home yesterday I noticed something odd.
When I drove 130 km/h, the car used the same amount of fuel when driving 100 km/h in the same gear (as suggested by the car). My assumption was that 100 km/h was too slow for that particular gear. I tested this assumption by shifting back a gear on the next 100 km/h stretch. Even though my car was telling me to shift to 6th gear, I found that in 5th gear the car used 0.3 l/100km less fuel. This morning I tried again, and found no difference between 5th and 6th gear. Apparently there are environmental factors (e.g wind, incline, engine temperature etc.) that influence which gear is most efficient. The algorithm in my car doesn’t take this into account. It just looks at speed and acceleration to determine the right gear.
We could try to make the algorithm smarter, but that is a flawed approach. The premise that we can create an algorithm upfront that makes the best calculation is fundamentally wrong. This is a perfect case for Microsoft Azure Machine Learning. Through learning it can figure out when to use which gear based on telemetry data. And not just for my car, but all the cars of the same model. There are approximately 1 billion cars in the world. Assuming these drive an average of 10,000 km a year, saving just 0.1 l/100km would save 1 trillion liters of fuel per year.
In software development the platform you build on has always been a key piece of how you build applications. For a long time the platform was the system you were developing for, like a PDP-11 or Commodore 64. You were stuck with the processor, memory, and I/O capabilities of the platform. If your application didn’t run well, you had to change your application. Beefing up the hardware was virtually impossible.
Developers have become lazy
Although it is still true we develop on platforms today, these platforms are virtual. Java, .NET, Node.js, and most relational databases are all independent of the hardware they run on. The common practice is therefore to develop an application, and then figure out which hardware to run it on. Memory and CPU capacity are available in abundance, so scaling your application is easy. Well… it was anyway.
Cloud redefines the platform
When developing for Platform-as-a-Service (PaaS), the possible variance of the hardware platform is again limited. You have to deal with the platform as a whole. Aspects such as CPU, memory, network & disk latency, and failure rate, all have to be taken into account when building applications. Most Infrastructure-as-a-Service (IaaS) platforms have similar limitations. IaaS is not just a data center in the cloud which you can shape to fit your needs.
The platform is expanding, rapidly
Cloud vendors such as Amazon, Google, and Microsoft are all adding services we can use in our applications. Data(base) Services, Identity & Access, Mobile Notification, Big Data, Integration, are just a few areas where developers can now use high available and reliable services, instead of hosting their own services on some infrastructure. The Cloud has become the platform, and we need to use the services it offers as-is.
For years we’ve built applications that assume the system is only used from a single location. As a result most applications work with local time, with the local time set to the time zone the application lives in. So an application of one of our Dutch customers would run in UTC/GMT +1, whereas the reservation site of a Las Vegas hotel would run in Pacific Standard Time (UTC/GMT-8) or Pacific Daylight Time (UTC/GMT-7) depending on the time of the season. You could think that there is no problem, after all the systems work as they are supposed to. There are however at least two problems.
Applications are interconnected
Suppose the application of our Dutch customer would interact with the reservation system of the Las Vegas system, for instance to get information about the latest time a reservation can be cancelled. The systems would need to agree which time to use, and make a conversion when necessary. That is possible but cumbersome, for instance because Daylight Saving Time starts and end on different days.
Time zone is not the same on every machine
If we move an application to another machine, we have to be sure the time zone is the same on the new machine, otherwise the chance is pretty good the application runs into problems. Any operation comparing stored time data against local time would yield different results.
Cloud Platform Time
In Cloud platforms such as Microsoft Azure, all machines use the same time: UTC. And when using their PaaS instances, Microsoft recommends not changing that (see bit.ly/azuretimezone). The best solution is to use UTC anywhere where date/time stored, queried, or manipulated. Only format date/time as local time for input or output. UTC is the universal time zone: Cloud Standard Time (CST).