Matthias Hellmund
Head of Customer Insights, ShareTheMeal
DESCRIPTION
Instead of providing a really long list of backend technologies which I have been working with during my professional career, I’d like to outline some learnings from the past years.
There is no one-fits-all
Picking a good choice for building your backend hugely depends on the three factors: team, expectations and product. While Erlang is a good choice for building high-available services, it’s a tough choice for finding suitable engineering talent. While I’m not a fan of building wobbly quick hacks, picking a limited backend-as-a-service can be a great choice for rapidly launching an MVP. There are more and more service building blocks available to use, which also means not to reinvent the backend wheels.
Costs
What a backend costs hugely depends on the scalability strategy and the connected services. Especially tech startups tend to favor complex combinations of *-as-a-service offerings. While this can cause additional client SDK dependencies on the app/frontend side, some pricing models scale much more in favor of the platform provider. Key is to be smart about picking the right scalable model for your service and fixing this at least for the medium term in SLAs with the platform providers..
Dependencies
I have seen many setups connecting to a multitude of platform-specific services while some other projects might include some deprecated proprietary modules for no obvious reason (besides not having done research). Although it might be attractive for developers to use the latest beta features, running a solid business should be your top priority. My general recommendation is, depending on the team experience and availability of alternatives, to prefer battle-proven and portable services where possible to avoid vendor lock-ins. Portability of backend platform services is becoming the new default.