The Service Business
PaaS, BaaS, IaaS have been a growing, and, I dare say, welcome, industry over the past 5 years. There is a lot of *aaS options out there with specific offerings.
While there are many varying opinions as to when to choose one or many or none of these types of services, this article is an overview of the latest comer to the service space, and in this humble developers opinion, the best out there: FatFractal
First let’s define what each of the different types of services is:
Platform as a Service
PaaS provides all the infrastructure needed to run applications over the Internet. It is delivered in the same way as a utility like electricity or water. Users simply “tap in” and take what they need without worrying about the complexity behind the scenes. And like a utility, PaaS is based on a metering or subscription model so users only pay for what they use.
With PaaS, ISVs and corporate IT departments can focus on innovation instead of complex infrastructure. By leveraging the PaaS, organizations can redirect a significant portion of their budgets from “keeping the lights on” to creating applications that provide real business value.
This model is driving a new era of mass innovation. For the first time, developers around the world can access unlimited computing power. Now, anyone with an Internet connection can build powerful applications and easily deploy them to users wherever they’re located.
Source: SalesForce
Infrastructure as a Service
Infrastructure as a service (IaaS) means delivering a virtual server, desktop computer or remote storage from the cloud. In other words, a hosting provider such as Dell gives you a remote data center — where it manages the infrastructure, servers and virtualization — and you access your virtual computers and storage from the internet through a secure virtual private network (VPN) connection.
An IaaS approach to infrastructure can offer:
- Faster responses to changing business conditions or internal customer needs, enabled by rapid system provisioning and rapid scalability, both up and down, without the long-term lock-in of hardware purchases
- Productivity increases resulting from access to your applications and data from anywhere and the reliability that comes from a distributed computing model.
- Reduced capital outlay for hardware acquisition, maintenance, data center real estate, and power and cooling, when using a pay-for-use (public cloud) model
Source: Dell
Backend as a Service
BaaS, as we shall call it for the sake of brevity, has carved its own little niche nestled neatly between Platform as a Service (PaaS) and Software as a Service (SaaS). Unsurprisingly, it does exactly what it says on the tin – that is – it provides a near complete server side stack including persistence, user management, data retrieval and querying, file storage and a few other things at the flick of a switch.
Source: Cloudspring
Who Is Out There
I’m sure I am not covering them all, but these are the platforms and back ends that I have used myself.
They all offer varying takes on the following list of features:
- PUSH notifications
- iOS, JS, Android SDKs
- REST Service
- Twitter, Facebook integration
- Server Extension (Stackmob and Kinvey only)
- Location Services
- File storage
- Payments (In-app Purchasing)
From Code to Cloud
When I was first invited to FatFractal’s private beta I was expecting more of the same. That isn’t to imply that the above services are bad, just more of the same with their own flavor. You know that expression, “You don’t know what you’ve got until it is gone.”. With FatFractal I never knew what I didn’t have until I experienced it.
As I stated above all of these services offer the same features in some shape form or fashion, however they fail to implement the basic of features in the correct manner.
What developers want and need is a platform that has the benefits of Google App Engine in regard to scalability, language support, and schedule tasks, but an abstracted data store (BaaS) that gives developers complete control over their models. Enter FatFractal. A true, abstracted data store and an engine that is language agnostic. You have all the features I described above but without endless endpoint creation and spaghetti client code. Plus, you get a new and refreshing approach to data-modeling.
The four main areas where FatFractal excels above all the others are:
- local development
- modeling
- object graphs
- server-side functionality
Local Development
Since the genesis of BaaS there has been an assumption that developers want to manage the life cycle of their app data in the cloud. Incorrect. We want to be able to have a light-weight local environment that is an exact replica of what we deploy into the cloud. The only current option is GAE, but the trade-off is that you lose the benefits of what BaaS providers offer out of the box. Not with FatFractal.
The FatFractal platform was built on an engine model. We believe that during application development it is imperative to have the local runtime environment be a carbon copy of what’s up on the cloud. When you set up for local development, you install a fully-featured FatFractal Engine on your desktop. This is not a crippleware version, not a simulation.
Source: Lovin’ Localhost
Deploying is literally one line (local): ffef deploylocal (cloud) ffef deployFFFabric
Modeling
I like to create models as subclasses of NSObject. `` I know it seems like a far out idea, but it is a far to common practice to force developers to interact with models that are only hashmaps or dictionaries or having to create a map between my objects and backend. The specifics of how models are defined and created go beyond just defining properties. It could involve conforming to a protocol like NSCoding or using KVO. The reverse is also true. There are many use cases when I just want clean objects. I don’t want extra overhead that is unknown to me.
Functionality like this should not have to be written.
Data Graph
Six degrees of separation refers to the idea that everyone is on average approximately six steps away, by way of introduction, from any other person on Earth, so that a chain of “a friend of a friend” statements can be made, on average, to connect any two people in six steps or fewer. When we talk about object relationships we are usually discussing these relationships based some sort of defined structure, whether that is a join table, circle references or foreign keys. The truth is, relationships aren’t always explicitly defined. Most BaaS’s will provide a standard, one-to-many or many-to-many option, but you still run into the “noSQL join” obstacle. Data relationships are like human relationships. What makes objects/data useful are these relationships but where is the flexibility to define these complex relationships in a simple and meaningful way? John Doe and Jane Smith are friends but their friendship graph is:
John’s mother' second cousin’s nephew’s best friend’s ex-wife’s bridesmaid is also Jane. With FatFractal’s grabbag datatype and back references this kind of complex relationship is trivial to define and return through a query.
Most models start clean but the moment you start defining relationships other PaaS/BaaS services start to fall down:
- Pivot tables
- guids
- duplicate data
When defining a grabbag as part of an object definition the values aren’t loaded by default with the instance. The grabbage is kept as datastore reference and populated via API. Long story short it doesn’t pollute the object graph with each instance request.
Essentially FatFractal has solved the NoSQL join problem.
Creating and managing relationships, no matter how complex, are finally straight forward without compromising data integrity or performance. One-to-many, many-to-many, many-to-infinity…it doesn’t matter to FatFractal, but it is a big problem for FatFractal’s competitors.
Server-side Functionality
A major, deciding factor when choosing any sort of “automated” service to replace something that you could hand-roll yourself is how easy or difficult it is to extend functionality. This mentality is always at the forefront of a developers mind. It is our nature. Why?…Because it is the very being of object-oriented programming. You extend classes, and inherit parent functionality. You implement interfaces to enforce signature. The same functionality should exist with BaaS providers. Stackmob does provide extension capability, but you are restricted to Java and there isn’t a way to ensure that your local development will run the same when you deploy into your dev or production API (see local dev enviornment above). FatFractal is language agnostic. You want to write your extension in Python, no problem, JS, go for it…hey I’m one of those cool ruby kids what about me?…they have you covered too.
In addition to extending the server you can also code up event handlers.
Event handlers execute when an event occurs on your app’s backend and are one of the most powerful and unique aspects of the FatFractal Platform. Every CRUD action automatically generates an event, with no coding required by your application, that may trigger an event handler.
In the examples I’ve reviewed from other services I see way too much server-side code being performed on the client, whether it’s list filtering, validation or post processing…the reason being, the ability to perform most of these server tasks, on the server-side, doesn’t exist. It does with FatFractal.
For example, if I have an app that “checks-in” a user I would probably also want to update a user property “myEvents” (list of all events I have attended) and “currentEvent” (instance of Event) and add myself to the events group of attendees which will provide me certain resource permissions. Having to do this on the client-sizde of a mobile app is horrible design. The mobile app should post to a “checkin" resource, essentially validating an access code or something and then continue on. The server-side should have an event handler which takes a successful checkin and updates the object instance and any other related objects. Aside from StackMob, where you would have to roll and trap your own events in Java, it isn’t possible to do this on any other service.
Using It
Over the past 9 months I have used all of the aforementioned BaaS services with production apps where I hand-rolled my own webservices using RDBMS, as well as NoSQL…not just ‘hello world’ tutorials. Each one has its niche in the market; but when making the decision of which service I would use for developing WhoNote (still in development), and any future applications, FatFractal is the clear choice. I am able to keep clean, native objects easily, define a complex object-graph, implement proper server-client design with extensions, event handlers, scheduled tasks and last, but not least, have configurable implicit and explicit permissions while developing in an exact duplicate, local, development environment that I then push to the cloud.
Summary
FatFractal is the next evolution of app development platforms.
*Note: I am not employed by FatFractal and was not paid, bribed or coerced into writing this article. I wrote it because their approach to PaaS/BaaS provides the level of out of the box features and customization that I have seen in parts and pieces all over the interwebs, but hadn’t yet found in one solution.