Imagine this: you have time travelled to the late 1980s. You’ve met someone on the street and want to tell them about your job and the software you use. Now, think of how you’d explain using “the cloud” for applications as opposed to the desktop software the person is using. What exactly is cloud software? – the explanation may be cloudy indeed.
Today, explaining what the “cloud” is may sound simple enough: maybe the person is using gmail, or CRM, or some other Software-as-a-Service cloud-based application. Yet, in the transportation world, cloud needs some explaining. Most (or all, with the exception of Optibus) software for scheduling is either desktop-based or client-server based. This aged approach results in some of the problems plaguing public transportation scheduling- slow optimization runs that hurt business agility (actually, quick optimizations are the result of advanced algorithms more than being cloud-based). Yet is it enough for these older systems to somehow add cloud computing resources, and then announce that they are cloud based? The answer is no. Not all “cloud based” systems are made equal and the difference between them is actually huge.
To explain this, let’s first explain the difference between “cloud-native” and “cloud-hosted”.
Cloud-native applications were designed from scratch for cloud deployment. They are hosted on on-demand cloud computing platforms, which can scale computing resources out or in, as needed. The result delivers all the benefits inherent in software-as-a-service systems:
Cloud native assembles cloud-based elements in a way that is optimized for the cloud. Being cloud-native is actually crucial for applications and optimization in the transportation industry, because the nature of these problems requires a lot of computing horsepower. That’s why a cloud-native architecture is crucial – since it harnesses and parallelizes cloud computing resources in a smart way that will distribute the problem across many computing resources, delivering quicker and better results than traditional desktop-based or client-server software. For instance, using a Function-as-a-Service architecture.
A cloud-hosted application takes on-premise software and moves it from an on-premise server (or desktop) to a dedicated server on the cloud. This server is managed by the software vendor. Some application functionality may remain on the client side. In short, it is an on-premise application that is accessible remotely. While this may sound as good as “cloud native”, it isn’t:
To sum it up it isn’t enough to deliver databases, storage and infrastructure through the web, or to pay per consumption of computing resources, because these cloud hosted deployments do not exhibit the advantages of cloud-native offerings. At most, this may reduce some of the IT costs associated with managing on-premise servers.
As traditional transportation software providers try to modernize their software systems, which are client-server based and even desktop based, and as cloud-native applications are disrupting the same market with a better user interface and speeds that completely eclipse those of older systems (resulting from advanced algorithms and not just being cloud-based), many claim to have “cloud-based” systems.
Yet, as we’ve shown here, “cloud-based” means different things to different people. True cloud-native software as a service systems give transportation operators and agencies the power to run their business without worrying about software or hardware. Systems that are “cloud-based” are the same old system, only that part of it was deployed on the cloud.