Face the inevitable: Local persistent data at the Edge will happen
It’s indisputable that Edge Intelligence will grow, whether that’s mobile applications running on Smartphones, IoT applications running in Smart Cars (or the underlying sensors), in the entertainment center, navigation systems, etc. There will be countless mobile and IoT – taken as a whole, Edge scenarios – where a native application will be a better approach than a web-based application, or where it would be inefficient/potentially less secure to send raw data back from IoT collection points – rather than process the data and locally store or erase the input data.
Complexity of process and workflow at the Edge, ability to run analytics at the point of action, and working in disconnected modes or with spotty connections are all examples of why you will need local data storage and therefore a local database. It’s a foregone conclusion that data associated with these applications will mushroom.
Unfortunately, what’s equally unavoidable is that security vulnerabilities and opportunistic attacks that target these weaknesses will increase for the foreseeable future. There have been several studies and surveys undertaken over the last few years that clearly show a far larger number of security vulnerabilities in IoT and Mobile device-based software than on more mature desktop or laptop platforms, let alone software running on servers in the data center. Let’s not forget that 10 years ago, each security breach in the Cloud generated a sense of panic and perhaps slowed adoption of Cloud services. This could very well be where we are now with localized and embedded data management for Edge devices.
Case in point, over the weekend a very serious security vulnerability was discovered in SQLite and the Web bundled version of SQLite in Chromium (the Open Source roots for Google Chrome). While this is not the first or the largest potential breach point found in Open Source data management – after all, the Heartbleed virus in 2014 that took advantage of OpenSSL probably holds both of these records – because this vulnerability is associated with SQLite, a database that is near ubiquitous in mobile native and web-based apps, and its APIs, we should brace for the knee-jerk reaction: perhaps data shouldn’t be stored locally on Edge devices and everything should be done in the Cloud, where it’s assumed to be more secure (my, how times have changed).
Retrenchment would be an overreaction. First off, SQLite is a far better than a combination of temporary memory allocation and flat file systems, an approach I’d never recommend to anyone I call a friend. Why? Unlike memory allocation and use of flat files, which provide little standardization, built-in indexing or other real data manipulation, SQLite provides baseline database support for Edge Intelligence.
SQLite is able to run on a device to support fully optimized use of local compute resources, providing an application with the ability to handle local data management – yet offering the same set of APIs calls for a web-based version of that same app, or even work on both the native and web components of a more complex app. It handles most SQL API calls, so it’s also standard.
Settling would be an equally poor choice. However, SQLite has many drawbacks compared to a commercial, enterprise-grade embedded database. Most notably, it doesn’t have built-in encryption for data at rest or in transit, let alone at 128-bit or above. It also can only embed in a single application and single instance, therefore can’t be scaled up to support multiple users that need to send or receive data from that SQLite image.
For example, if you were to put SQLite on a Gateway and then have multiple downstream IoT devices attempt to write data to that SQLite instance, there is no way to manage more than one client (downstream IoT device) writing to the SQLite database at a time – a requirement in an IoT environment often with tens, hundreds, or even thousands of devices downstream. However, Client-Server databases are capable of handling hundreds or thousands of active downstream clients; therefore, flat file and SQLite users must always pair their applications that send or receive data with MS SQL, mySQL, Oracle, or some other Client-Server database. This pairing guarantees that data reformatting or ETL (Extract, Transform, Load) is a necessary evil.
There are three major drawbacks of ETL that we find most data architects and developers struggle with: integration cost, performance and data security. I’ll save the cost and performance penalties for another blog, but data security is worth discussing here. In the absence of a single architecture across client and server database management, even if you had built-in encryption, you would have no choice but to decrypt and re-encrypt so that you could perform ETL functions – even if you had no other data manipulation to perform. The requirement to decrypt means your data payloads are – even if temporarily – exposed to hackers.
A superior way to securely manage data at the Edge. The Actian Zen database family is based on a single, scalable secure architecture that allows Zen to run on VMs in the Cloud, virtually any operating environment, from Windows, Linux, and Mac OS as a full-fledged Client-Server database to Windows IoT Core, Raspbian Linux distributions, Android, and iOS as a pared down 2MB client-only Edge data management platform. Since Actian Zen runs on virtually anything with completely transferrable APIs (you can use SQL directly or NoSQL/SQL APIs programmatically from most popular programming languages), engine, and underlying file storage, it requires Zero-ETL. It also has 192-bit encryption at rest and in transit thereby removing both integration cost, data security vulnerabilities, and boost performance.
Summary. When it comes to SQLite and the recent security vulnerabilities uncovered, the response must be to plug the security vulnerabilities and reduce the risk by fixing SQLite or going to a superior enterprise class solution like Actian Zen. The answer is not to avoid or severely constrain placement of data on local devices. These constraints will throttle innovation and improved outcomes that will undoubtedly come from intelligence embedded at the point of action. Cloud security has seen marked improvements because vendors, industry customers and standards bodies, as well as government (NIST specifications, FEDRamp, etc.) have taken on the challenge, not run back to legacy environments. There is always going to be risk, but the point is to manage that risk by moving from static, reactionary and periodic checks on security to a risk-based, continuous diagnostics and monitoring approach. Expect nothing less over time for Mobile and IoT data security as vendors – like Actian – work together to help customers stay calm and keep their data at the Edge secure.