I'm a backend team lead for a travel company. To render that list of flights and hotels to the Android app it's not a database lookup. It's hundreds of soap and rest calls stitching together airline and hotel data from multiple platforms. This isn't something I can do on the front end. And even if I could I wouldn't want to replicate this logic between iOS, Android, web and our internal support portals.
I suppose it is fine to have business logic in a client, but replicating that for every platform seems silly and a simple way to acquire huge amounts of technical debt and complex role out strategies. He says about being the only backend guy to ensure not much code gets written there. I feel like this is not a person I want to work for. Not even seeing the problem before telling me the solution.
This article could have been much better framed if it discussed using his suggested tooling to solve simple CRUD applications in a bootstrap scenario perhaps. But it has been my experience that long term, complex business systems that are created in Javascript are black holes of lost time trying to maintain and extend. Especially ones written to 'configure' the backend based on client defined configuration which he also suggests is a good thing.
In our case we're running calculations across a large dataset on the back-end and serving up the results to the client. Due to the number of ways the data can be cut, pre-calculating everything anybody could possibly isn't cost-effectively feasible, so if we were going to stick all the business value in the client we'd have to load a bunch of the raw data into the client and then do the calculations there (in JavaScript!!).
Funnily enough that actually was the original approach, and it worked "OK" up to a point, except in Internet Explorer 11, which couldn't handle the memory consumption, and honestly it was dog slow everywhere else: both loading the data and doing the calculation. And of course this approach is a disaster on mobile.
Even if we could get calculation performance on the client that is better than the sum of time spent on the server plus latency, and maybe we could with WebAssembly or WebGL hacks, except that we'd probably have at least some incompatibilities to deal with (hey, starter for 10, IE11 again - who knew?), there's still raw data transfer to consider.
So now most of the smarts are in the back-end, and they'll stay there for the foreseeable future.
It's simple really. Because they're more profitable than your hurdle rate. Serverless isn't the elimination of backend, it's just reallocating backend engineers to AWS, which is widely regarded as absurdly profitable for Amazon. Optimizing your AWS spend essentially becomes the new ops.
If you want to keep your team small, that's fine, but don't delude yourself into thinking this is constrained by anything other than the size of the opportunity you're pursuing.
Also, if you want to do anything other than CRUD these types of services won't get you very far.
To directly address the author's question: My customers aren't speaking HTTP with me. Surprise! There are other protocols out there too. I don't have what you'd call 'frontend' development. No JS, only small amounts of HTML for informational pages, and most effort goes into keeping big backends alive.
"Serverless solves all problems" yeah, right.
I believe, wholly, in frontend-first design and thinking. Talk to customers, understand their problems, build toward that and have the code adapt to their wants and needs.
But with vendor lockin, sometimes you have problems that they genuinely can't let you solve, or you can't solve in a performent way.
---
Also, it strikes me that in reality, a serverless architecture is just functional programming without the ability to share code nearly as easily. If you're worrying your head off about how you're having to pay for servers that are always up- you're absolutely solving the wrong problem. Even the cheapest junior developer's time costs a fraction as much as what you'll waste in time developing for serverless instead of a traditional solution- and it's not because serverless technology isn't there, it's because even in the ideal, serverless will always be a harder solve. It's inherent to the problem itself.
With Lambda it's the same thing. You have a Lambda function mapped to an HTTP verb and route and you get s message and context. The handler acts just like your controller method. Converting from Lambda to a traditional MVC is not that hard.
Lambda is simple. However, to do what you're describing requires a lot more: API Gateway, IAM roles, etc.
If you can avoid hiring a backend team early, there will be a cost advantage. However this advantage will evaporate once you start to scale up. At some point it will work against you until you burn all of your cash.
Serverless products price support and infrastructure maintenance on a linear basis, but these items are very responsive to economy of scale. One person can maintain a few, a few hundred, or a few thousand servers with the appropriate tooling.
So go ahead and start serverless. Remember that this is a decision that needs review as your business scales.
The more reasonable view is analyze your problems, see what your near & long term business goals/possibilities are, and the risk/benefits you get from each technical approach to meet them. Whether that be serverless, or more traditional backends & data management, it doesn't really matter. Puff pieces like this making some incendiary assertion and chock full of assumptions don't do businesses any favors. There's no good shortcuts to running a good business than good decision making & a little luck.
What resources are you comparing it to?
The heterogeneity of client apps is very superfical. One layer underneath the fancy design and arguably unnecessary custom imteractions, everything start looking very much the same as the article argues is the case for backend.
Funny enough, not too long ago people said you don't need frontend devs, because of tools like gwt. And long before Firebase people were already claiming you don't need to write backend code because of uml.
If you take enough steps back everything will start looking the same and generic. But dependant on the problem your are solving, you should take a closer look at certain aspects, instead of blindly following "best practices" of the current week, month or year.
I get that this is PR, but the bigger risk is still being locked into the vendor. And the assumption that it takes longer and requires more skills than the "useful stuff" from a vendor is simply incorrect. It's not magic. You can benefit from this stuff of course, but only in specific cases, not in general. You'll know when and why.
As to second part - serverless - well, as a developer, I don’t really care how you call servers where code runs from - as long as it can run it and I can still access my databases/search engines (and not key value stores). And also not lock me to being an AWS slave for life.
I think the future is around knowing infrastructure, devops, and front end and knowing how to tie it together.