In follow-up to my post earlier this week on problems with Database-as-a-Service platforms, an email from
I was just reflecting on some of our technology-stack choices, and I had an interesting thought that may be relevant to you.
We’ve recently tried out (DaaS service for App Developers). Our experience was interesting. At first, it was great to dive into product development with higher velocity (abstracting the backend saved us some time to get to a very basic prototype.)
However, we found that were constrained within a couple weeks, and that it we wouldn’t be able to expand our feature set without ‘rigging our own backend for the stuff the service couldn’t do.’ The problem with that, of course, is that it’s way more complicated to work with and keep two backends synchronized. As a result, we had to write-out the service, and use our own backend for everything .
As I think about the future of DaaS / PaaS, that’s probably the biggest challenge for the space as a whole. Engineers and technical decision makers as a segment hate to be constrained. And there are very real challenges with abstracting-and-super-simplifying parts of the stack that will almost certainly create limitations in app functionality. Once people have to circumvent the DAAS, they’ll likely just stop using it.
I guess what I’m saying is: the tech landscape is growing too fast to try to abstract away the backend pieces wholesale. You’ll only be able to nail part of it effectively. You’d need a LARGE army of engineers to make your service robust enough to handle all the crazy things people want to do. But if you don’t handle everything, people will have to workaround you once they scale. And once they do that, it’s hard to stay relevant.
In short: I’m bearish.