One of the common inquiries from our users is the possibility to install flespi on premise. Usually for such projects we are talking about volumes of 50K to 5M devices. Most of the time these are either projects subject to a specific country’s governmental regulations or large Telematics Service Providers looking to embed flespi into their infrastructure to increase service quality and minimize development costs. In the past we also received similar requests from a car manufacturer that was connecting its cars to the cloud.
We have always answered that flespi is a cloud service provider and on-premise installation is not available. Now I want to explicitly clarify why we are going cloud-only.
Requirements to the gateway
First, let’s analyze what we need for a telematics gateway service to run smoothly:
good connectivity to your infrastructure together with maximum link uptime;
servers, switches, racks hardware fault tolerance;
software fault tolerance, bug fixes as quick as practically possible;
enough computing power available to double or triple the consumption in a moment;
constant product updates and new features availability;
live service monitoring, immediate reporting about any incident that may occur;
support with competent engineers that have access to all the tools in house;
fair pricing.
Financial analysis
All of the points from the list above are possible to deliver even in an on-premise installation. But the cost for this will be incredibly high compared to the cloud-based alternative. I know that most of the time it is not about money but about data security and ownership. But let’s count the money first.
Here I estimate the infrastructure suitable to handle data processing for 1M devices. My calculations show me that in order to receive comparable quality of service you have with flespi in the cloud mode the initial investment in the hardware part is about 50,000-100,000 EUR, which may be doubled if we include human labor involved for the initial setup. So the initial investment of 100,000-200,000 EUR into hardware and software installation plus additional 20,000-40,000 EUR per month for the infrastructure operations, maintenance, and support.
Let’s assume that we have a five-year depreciation cycle for the whole system. In that case the investment will be: 200,000 EUR (initial) + 40,000*12*5 (recurring) = 2,400,000 EUR. This will result in 2,4 EUR per device on a 5-year horizon or 0,04 EUR/month/device. The final price should also include the flespi licensing fee, which currently does not exist, but even if we take a medium market price for such volumes (0,15 EUR/month) we will end up with a total cost of 0,20 EUR/month/device for 1M devices in own infrastructure that covers most of the initial/recurrent costs for hardware/software/labor.
Looks not that bad. Device costs of 0,20 EUR/month allow you to deliver a final solution that is quite competitive nowadays. But remember — in order to minimize the costs you have to connect 1,000,000 of devices. If you connect 100,000 devices, your infrastructure costs will be more or less similar but the device cost for the project will rise up to 2 EUR/month. And if you connect 10,000 devices, the cost will rise up to 20 EUR/month per each device that will make your solution non-competitive.
In order to better understand the existing flespi pricing in our cloud please take a look at this comprehensive article by Sergei Leuchanka.
Technical analysis
Now let’s look at the technical side of the on-premise installation. You have two options for the infrastructure — either you will build your own racks or you host it as a service.
If you plan to host your on-premise flespi infrastructure with AWS, Google Cloud, Azure or any other infrastructure provider, you will be affected by a lot of troubles with the lack of choices, limitations on static IPv4 addresses, and uncontrolled connectivity. Basically in such mode all your investments into own infrastructure will be useless as the level of risks for your operations will be the same as with the cloud-based flespi but with higher price for the resources. Thus in such mode when part of your infrastructure is already in the cloud, it makes more sense to simply use flespi in cloud mode.
But if you are a company that hosts everything in-house, let’s look at what it takes to host flespi locally. Before you start I recommend you check this 5-year-old article describing flespi architecture. For the hardware part it is still relevant.
First you need reliable infrastructure with racks filled with servers and routers. All servers should be maintained by an engineer who will install OS updates on time and regularly perform various negative tests like power cuts for this or that server ensuring that everything is still running smoothly and all backup systems are operating correctly.
Then you will need a range of static IPv4 addresses and a connectivity provider that will arrange routing services for you. With DDoS protection, uninterruptible maintenance, and good support. But if you consider having flespi on-premise, you might already have such provider in your datacenter with whom you have close and trusted relationships.
Ensuring high availability
Now the most important part. Every software is buggy. The more features you release, the more opportunities for new bugs you create. Flespi is not an exception here. The difference is that in the cloud mode we fix bugs as quickly as possible. It usually takes no more than a few hours for minor issues and up to several days for the trickiest situations.
With the on-premise installation there will be no way for the flespi developers to get in and perform fixing asap. It means that the bug fixing process slows down incredibly — from information flow with sometimes gigabytes of logs for analysis to the software upgrade with the actual bugfix.
The same is true for the new features. In the cloud mode we operate in continuous integration mode. It means that we are installing new features as quickly as possible once they have been tested. Here is a good article about this process, five year old, but still actual.
Each important upgrade is carefully delivered by our engineers that monitor all possible impacts to the system in real time. Sometimes we upgrade only a part of services and compare old and new ones between each other. Or even worse — data format upgrade of our database system sometimes requires full resynchronization of the data on the mirror. In normal mode we operate three mirrors with the same set of data but during such updates we manually create a fourth mirror with the data in a new format, then move all read operations there and wait a couple of hours or even days to make sure nothing wrong happens. For the engineer everything is automated but it is hard to imagine how we can correctly script the data upgrade process for the on-premise installation.
And finally our NOC that performs automated monitoring of services availability and immediately reports any incident that may happen. We use our own set of tools and it is possible to deliver these tools for on-premise installation, locating them somewhere outside of it. But this system should be monitored in real time 24/7 and you should have a backup team of engineers capable of resolving any incident at any time of the day — from connectivity to software and hardware failures.
***
So, fairly speaking, there is not big deal to provide a flespi on-premise installation. We have such an installation on each developer’s laptop. But will it be better protected, maintained, quicker and cheaper on large volumes than our cloud version? I have doubts about this.