One of the most rewarding things about starting a technology company is seeing how software developers think. I often play an “imagine if” game with friends over a cold beverage: what if clothing could reshape itself, what if you could transport yourself a few feet, and so on. Unlike me, when developers play the “imagine if” game they tend toward incremental, technology change, often coming up with ideas that could be created without a lot of effort.
Some of these ideas blow my mind and I while I have no idea if there is demand for them or what the specific use cases are, they sure get the juices flowing. A few of those “imagine if” sessions generated some ideas around the FatFractal platform: are they brilliant or crazy, prognostication or pointless?
- Portable Device as Part of the Fabric: Because FatFractal is engine-based and because that self-configuring engine can be quite small (could be well under a megabyte), imagine an engine on a mobile phone, for example. That is, the phone becomes part of the FatFractal Fabric. You could deploy to it and it could be managed as a resource to the platform. These engines could be specialized (i.e. configured as “FatFractal Local Mobile Engines”) but the question is, what would you do with them?
- Cross-module Backends: Backends tend to incorporate a single “business logic” language as part of the stack. If you are developing in Python or Ruby you stick to it. But with the FatFractal architecture, there’s no reason you couldn’t have multiple modules (e.g. NoServer, Ruby, Python, etc) as required by an app sharing the FatFractal API and a common data store. These various “language modules” would be configured dynamically. If you already built that perfect Ruby Gem but want to use it alongside your JS Serverside code? No problem.
- Cross IaaSs, Hybrid, Orchestrated Backends: Because FatFractal is an engine-based PaaS abstracted from underlying infrastructure, we can already deploy across multiple IaaS’s. Since the platform can be deployed pretty much anywhere, including private networks (and even, as above, devices like phones), one “imagine if” scenario is that the platform’s orchestration engine dynamically shifts the backend infrastructure service(s) based on availability, spot cost, geography or any other criteria you can think of.
Every day I look at a development schedule full of useful, important features that customers require for real use cases. That is pretty exciting on its own. And as a science fiction geek, I’ve always enjoyed far-out thinking and wild-eyed imagination. The “imagine ifs” from the minds of developers, though, are the best because they could actually be implemented in the short term.
Got any “imagine ifs” of your own? Any use cases you have to implement in the near future? We’re all ears.