It has been a while since I posted anything referring to Data Gravity. While Data Gravity is interesting and can explain many motivations of Cloud Companies and their Data Services, there are other influential forces at work.
Service Energy
What am I referring to as a Service in this case? Any code or logic that has been deployed by a provider to expose a resource.
Examples include:
- APIs
- Message Queues and Buses
- Automation, Scripting, and Provisioning Interfaces
- Web Services
- Many more…
When resources are externalized, this is what enhances the value of Data and helps increase Data Mass and Data Gravity. As a Service is used more frequently, the amount of energy it is emitting increases in our analogy. The emitted energy has effects just as it would in Physics. Service Energy has the ability to assist in Escape Velocity as well as increase Data Gravity, all depending on what the Service Energy is doing.
Service Energy shows motivations in Clouds for specific behaviors such as:
Why Salesforce acquired Heroku – (Heroku is indeed a Ruby PaaS, but it was beginning to bring in SERVICES from outside which increased its Service Energy) Salesforce needs this in the Ecosystem, just like it needed to create Database.com to help increase it’s Data Mass and therefore it’s Data Gravity.
Why Amazon created SQS and SES (These are services that encourage additional consumption of Compute but more so amplifies the amount of data (Data Mass)
It should be noted in the picture above that the Data is made accessible through a service which is why it has Service Energy around it, which should be distinguished from Data Gravity. Remember, Service Energy does NOT attract, but can amplify.
Service Energy also can be used for Escape Velocity. By properly architecting applications and even Service Oriented Platforms, the Data Mass can be spread across many providers (and even sources inside of those providers). This provides looser coupling between the App and a specific Cloud, which gives more flexibility. The trade-off is that this design is more prone to service interruptions, latency, and bandwidth constraints.
There is much more to be said about Service Energy in the future including exploring other effects it has with more IaaS centric solutions.