Change is coming, and FairCom is leading the way

By Shane Johnson, FairCom’s head of marketing

I couldn’t be more excited to join FairCom as the head of marketing. I turned to the dark side 10 years ago, and started using terms like positioning and messaging (and, even leads), but I will always be a developer and architect at heart. I still write code for fun, I enjoy reading research papers on distributed transactions, and I’m the most animated when discussing architectural challenges and solutions. Thus, I’m rather discerning when it comes to marketing databases. In order for me to champion one, I need to be excited about it.

And that … is precisely what drew me to FairCom.

I look at databases through the lens of a developer/architect and the applications they’re building, and when I do, I see a tremendous opportunity. The truth is applications have evolved much faster than databases. The way applications are built, deployed and used has changed so much over the past several years… the way applications use databases, not so much.

Yes, there was NoSQL. JSON became the de facto standard for sending and receiving data, so it only made sense for databases to support it (and really, they all do). However, JSON is but one change – and to be honest, it’s just a format. I think there are three areas where databases can evolve to improve applications and application development: deployment architecture, data access APIs and client protocols.

I’m particularly interested in how databases can evolve to better meet the needs of microservices and connected devices.

It’s not uncommon for desktop applications and enterprise software to use embedded databases, whereas web and mobile applications use remote databases. But, what about microservices? What if microservices were built and deployed with an embedded database that replicated to a remote database? What if, together, they were a single deployable unit – and if you needed high availability or scalability, you simply deployed more units? The remote database can still serve as a central repository of data (for all microservices), or the embedded database could replicate directly to a data lake or data warehouse.

We can take this even further. What if the microservice stored and accessed binary objects with MessagePack, Avro or FlatBuffers for maximum performance, while its data was replicated to a remote database where it was stored as rows in tables for maximum compatibility? What if the embedded database could execute arbitrary microservice code via callbacks instead of putting code in the database? What if the microservice could use a data access API optimized for how its users interact with it instead of traditional batch APIs (e.g., SQL)? You can see I mean it when I say this stuff gets me animated.

Beyond web and mobile applications, there is the Internet of Things and edge computing. Like microservices, connected devices can benefit from using an embedded database that replicates to a remote database. Alternatively, homes, factories and gyms become the edge where things like TVs, robots and treadmills replicate to an on-prem database, which then replicates to a cloud database.

This is where protocols such as MQTT and OPC UA come into play. Why integrate an MQTT broker and database when we can simply extend the database to support MQTT? Why not extend the database to pull data directly from industrial equipment and machines, or enable them to push data directly to the database?

FairCom is rethinking what a database can do in the 21st century. It doesn’t have to be confined to a client/server architecture. It doesn’t have to be confined to SQL. It doesn’t even have to be confined to JSON.

We’re limited only by our imagination, and that’s exciting!