TRACKGPS Cloud: The Future of
Vehicle Fleet Tracking

By | February 12, 2014

These days the Cloud is on everybody’s lips and rarely in regards with the weather. The multitude of advantages it offers has made Cloud Computing an important technological choice over the last years. While we use this term in its general sense (the name was inspired from the flowcharts and diagrams used in the past to represent the Internet with a “cloud” symbol), Cloud Computing can have different meanings. It refers either to providing infrastructure for storing personal data and files so that they can be accessed from everywhere by the end user or to offering software products that interact with the user through a front-end portal. The latter is known as the Software-as-a-Service Cloud Model (SaaS) and in the last years has enjoyed a large increase in popularity, with ever more companies adopting it.

The obvious question for any prospective user of SaaS is “Why should one use this model?”. What advantages does it offer? Well, I guess it’s all about cost and convenience. Why have some hardware to control and administer when you can easily access the Cloud and get all the necessary resources from there?

Although this sounds very good and promising, there are still people who like to manage their hardware requirements themselves or are too reluctant to accept changes in the way their businesses operate. We, on the other hand, think that the Cloud is the way forward and, for our project, aim at changing first the mindsets regarding the Cloud and then gradually updating the infrastructure for the adoption of the SaaS model.

TrackGPS is a web solution that offers GPS-GPRS technology for tracking vehicle fleets. First implemented only a few years ago, the system grew in popularity rapidly, being used at the time to monitor about 25000 vehicles. This spectacular growth brought with it the need to implement new models of architectures that would allow us to scale components and add/multiply components/services/servers easily. We learned that the world changes very quickly and we need to move with it. In our case, we had peak demand during certain days/hours, when we needed to increase the computing power. By creating and managing the software wisely, we easily added machines when they were needed and removed them later on, during slower times.

Listed next are some of the changes we had to make to the existing software and hardware architecture to adopt the SaaS model:

Database:
We began the project with one stand-alone database for all the clients. As the number of clients increased, the volume of data also grew at a fast pace and we had to think of a new design that would allow us to add new clients and have a good performance for the queries. Along this line we have implemented a method for extending our database horizontally, solution that allowed us to add new resources into the cluster. We have also created a Master database that holds information about all the existing clients and routes the database requests to individual Client databases. The Client database holds TrackGPS client data and may serve one or more TrackGPS clients (depending on the projections about the size of data that the client will produce). All client database are hosted over several server machines and are backed up daily. Adding a new database to the cluster only takes several minutes, while removing one from the cluster is even quicker. This innovative design greatly improved the performance of our application and also allowed us to adjust to the increasing number of clients.

Services:
The TrackGPS platform includes a multitude of services that help us implement all the tasks required to meet the business requirements. With the database model changed as explained above, we also needed to refactor all the services to adhere to this model. All the services have been designed with the master/slave architecture in mind. For each service we can have one or more instances deployed on one or multiple application servers, approach that allows us to quickly deploy the required instances when a new Client database is spawned.

Web Applications:
Our main target of the whole architecture is the web portal. Using the web portal, clients can view their data and take certain actions according to their needs. To help our clients, we constantly monitor the performance counters of the web application and we take actions when things start worsening. The web application uses load balancing servers for balancing requests between web servers. This offers a good response time to the clients. Our architecture offers the possibility to quickly add a new web server to the cluster and to the load balancing scheme. Likewise, if a server is not needed anymore, we will take it out from the balancing scheme, but keeping it “on hold” for when it might be needed again.

Although there is still a lot of development to be done towards offering our software as a service in the cloud, we have made significant progress in the changes we have implemented so far to adopt this model and we continually build new automation models, hoping to provide the software to the client at “a click of the mouse” in the near future.

Leave a Reply