This year summer has extremely nice weather. While Western Europe beats the temperature records oftentimes exceeding the mark of +40C, Belarus enjoys the comfortable +22-26C — the best weather for productive labor. Such perfect weather forced us to maintain perfect quality of the product and its infrastructure. In the world where everybody has to burst with new features or become uncompetitive, where smartphones leak your information on a regular basis, and cars are replaced with new ones every three years, where freshly built Boeing’s 737 MAX planes crash due to bugs in outsourced software by $9-an-hour engineers from India — in this (our!) world we try to preserve an island of quality, stability, and performance by providing a specialized product with focused functionality and the best support done by engineers knowing everything under the hood and thus being able to provide efficient assistance in the real-time chat.
- Lyrics aside, we finished June with 100% uptime for the fourth time since we started calculating uptime automatically using bots from multiple locations performing more than ten different tests each minute. But this month is special — due to a published critical security vulnerability in Linux called CVE-2019-11477 we upgraded all our servers with fresh kernel and this is the first time we did this with zero downtime. The very first time we performed similar server maintenance in September 2017 we ended up with a lot of experience and a few hours of downtime. Now, this is an almost fully automated process and we even decided to perform it on schedule every two months to maintain gathered competence. Since the architecture of the platform is absolutely durable, we can easily rotate servers in and out of production services with almost zero impact on the users.
- If you periodically check our platform status page with live counters, you may notice the growth we had in the last few months. This is the migration of one of the largest GPS tracking systems with 150K trackers connected to the flespi. From a technical perspective there are no questions, but what is interesting is the commercial part of such project. How flespi business model where users pay for the actual usage of the platform behaves on large volumes? It has always been theoretically calculated and now we have some facts. This project relies on flespi analytics for implementation of real-time reports and notifications system and uses HASD for various data storage and its retrieval directly into web/mobile applications. The average cost in such a scenario makes up $0.03-$0.10/device. This price level for such consumption level was our initial plan and I’m glad that it worked out.
- In June we completed all the initially planned features of the flespi analytics system and published three blog articles covering its practical usage — stops detection, geofence ins/outs control, and results aggregation based on time slots. We did a lot of changes from the moment we first presented it to the community and are now waiting for the feedback from our users, consulting them on how to use analytics to the fullest, and tuning its internal components based on the growing load. Although analytics is primarily intended for developers to build solutions on top of it, we are still trying to deliver a mouse-click ready-to-use interface for visualizing various aspects of fleet operations in dashboard-like interfaces like MQTTTiles.
- We decided to introduce some REST API changes to the gateway system. We released the new API methods for operating streams and marked subscriptions management methods as deprecated. We will also move ident/phone device attributes into a special configuration object together with other configuration fields like device password. All these fields will be defined by a protocol-dependant JSON scheme making it easier for users to enter the IMEI, custom serial number or whatever may be needed to identify the device. Our users can even use special embeddable tools (like formbox) in their applications to show these commands/configuration utilities to their users.
- In June we didn’t add new protocols to the telematics hub but added plenty of new devices and various new settings for them to the already-integrated manufacturers — like this nice e-scooter from Concox.
- For those who are using flespi MQTT Broker, we have added the possibility to define a conversion scheme for channels working over MQTT protocol to map incoming message parameters to custom flespi message parameters. Also, we decided to enhance MQTT protocol with own features and introduced topic selectors for fast and easy enumeration of multiple topics in one subscription. We need this as a part of HASD — for fast access to multiple objects in one call (subscription).
- We already installed fresh rack with 12 servers in Russia and will use it now for extensive testing of the platform behavior under extreme load. Also in the next few months, we will concentrate on an extremely difficult task — we want to install in Russia a part of the current flespi cloud that provides the same geo-distributed services as our installation in the Netherlands. But at the same time, it should be fully autonomous and capable of operating even if isolated from other data centers. Our goal is to make it seamless — no matter where you connect to the flespi broker or REST API gateway, you should be able to receive all the data from multiple locations. That is non-trivial, especially because the bandwidth between Russia and the Netherlands is quite limited, but we will do our best to implement it correctly.