The problem is a growing business won't initially understand where the real technical requirements are.
At first, Parse seems like a strategic investment because you don't need IT maintenance on the server, application deployment could be as simple as FTPing static files to a shared host, and all technical aspects of maintaining a database, backups, restores, reboots, DNS and maintenance is attractive to the weekend hacker - or a small scrappy start-up.
The problem is as traction sets in, feature usage and load comes as a total surprise. This is why iteration is fundamental to design.
Overnight a Parse user will need to run backend jobs on the data. Then what? Because the application execution exists within the context of the browser, separate tooling would be necessary. Or what if we needed to access this data from backend infrastructure in real-time?
My point is business demands are demands because the situation calls for it - not because it is planned.
While for most client-centric CRUD type management apps this works great. Its Paas-Rails for scrappy users coming from PHP.
Most web applications worth the web-space they are printed on does something special, or does something simple at great scale.
Access to the data, an IT-based SLA or other guarantees only further positions the business as an IT service provider. My impression of the product was it was targeted for developers and small shops as an application platform with crazy-easy deployment and management. Ultimately the aim is cost reduction in infrastructure IT. I get it.
But any long-lasting business with the momentum built into the plays of most internet companies will outgrow the current version of Parse faster than I believe the growth could be practically followed. That said - proving me wrong would be worth a lot of money.
Anyway - that was the thought process behind that comment. I wasn't trying to be harsh, but if you ask me this oversight is too fatal to ignore.
At first, Parse seems like a strategic investment because you don't need IT maintenance on the server, application deployment could be as simple as FTPing static files to a shared host, and all technical aspects of maintaining a database, backups, restores, reboots, DNS and maintenance is attractive to the weekend hacker - or a small scrappy start-up.
The problem is as traction sets in, feature usage and load comes as a total surprise. This is why iteration is fundamental to design.
Overnight a Parse user will need to run backend jobs on the data. Then what? Because the application execution exists within the context of the browser, separate tooling would be necessary. Or what if we needed to access this data from backend infrastructure in real-time?
My point is business demands are demands because the situation calls for it - not because it is planned.
While for most client-centric CRUD type management apps this works great. Its Paas-Rails for scrappy users coming from PHP.
Most web applications worth the web-space they are printed on does something special, or does something simple at great scale.
Access to the data, an IT-based SLA or other guarantees only further positions the business as an IT service provider. My impression of the product was it was targeted for developers and small shops as an application platform with crazy-easy deployment and management. Ultimately the aim is cost reduction in infrastructure IT. I get it.
But any long-lasting business with the momentum built into the plays of most internet companies will outgrow the current version of Parse faster than I believe the growth could be practically followed. That said - proving me wrong would be worth a lot of money.
Anyway - that was the thought process behind that comment. I wasn't trying to be harsh, but if you ask me this oversight is too fatal to ignore.