Front end is what customers use although curiously ui code is rarely where anything of business value/differentiation is produced.
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.
Not sure how you run an entire website under a "serverless" architecture having used Azure Functions that sounds awful and not like what it's designed for at all. I still see serverless as mostly useful for cronjobs but that's just my experience with it I suppose. Anyone else care to chime in? The marketing Buzz for serverless died to me with the time limits on Azure Functions. I wanted to process some data off of them but it became too time consuming.
A group of serverless functions are about the same as one Controller. You get more fine grained scalability and on AWS it is somewhat easier to scale Lambda functions than EC2 instances.
Yes someone needs to understand the infrastructure. I got more into AWS infrastructure because I am mostly a back end developer and found myself growing tired of writing Yet Another CRUD API.
I think the future is around knowing infrastructure, devops, and front end and knowing how to tie it together.
I think that’s an interesting thought. My perspective is that many industries will break up into backend/frontend where each part requires a different kind of people and operates on different margins. The backend will be an efficient machine whereas the frontend will be where the cool end customer facing stuff happens. Both will have their value, but operate very differently.
My experience is the opposite to the point where I'd say developers who describe themselves as "front-end" or "back-end" aren't terribly useful to me. What I need is people who can turn their hand to, and learn anything: i.e., full stack developers. These people tend to be able to add more value because they understand the whole system and can work on any part of it. What I definitely don't need is people with a compartmentalised "not my responsibility" view of the world, or our systems.
Because frankly, the serverless/backendless(such as Firebase) movement is just turning Frontend developers into fullstack developers who are completely dependent on vendor lockin.
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.
Developing for serverless is no harder than "traditional" development. The traditional API you have a controller that has methods that are called based on HTTP verbs and routes. The controller methods translate the request to the backend.
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.
API gateway does the same thing as your own custom per request filters and your own routing attributes. The roles for the Lambda you can just give one or more of the built in policies. If you were using EC2 instances, you would still assign roles to the EC2 instance for the same permissions. If you are doing it outside of AWS you would hopefully setup DMZs firewalls, etc.
I'm skeptical of this for larger companies/companies that aspire to get larger - time and time again, the more you outsource, the more you're tethered to those services, especially if you need to scale. This will cost companies lots of money long term if the company grows. I also say this as a developer who works primarily in the UI/frontend web services layer.
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.
This is a joke right? I've read through about 30% of the article and I'm not sure it deserves much more consideration. The author mentions the reason why the serverless approach won't be used by serious companies when they reference Parse. Even if you choose a serverless backend that is being supported by a large company there's no guarantee they won't shut it down leaving you high and dry.
Also, if you want to do anything other than CRUD these types of services won't get you very far.
> Why are you still investing in backend developers when customers don’t care?
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.
Serverless functions that actually do anything still need to be written by someone. Whether they're "backend" engineers or "serverless" engineers, the code still needs to be written and maintained. The question is still: What's the best/most cost effective way to do that?
He is operating in the mindset that the backend is just a dumb persistence layer with auth. If all the problems he is we solving fit into that world view than more power to him.
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.
Have to agree wholeheartedly. He seems to have a problem landscape that involves CRUD on single 'documents/tables' with no business logic involved or required.
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.
Ditto. If your app is CRUD with auth, then, yes, fine (probably).
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.
Here's why you should regard all such advice skeptically: sub-linear scaling.
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.
> I think the question should be: what's the bigger risk? Being "locked into" the vendor with the most useful stuff, or taking months/years longer to build, and needing much more code, and needing more skills on your team?
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.
"When you get to the client interactions, of course, you have amazing heterogeneity."
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.
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.
I listen to at least one podcast they sponsor; they sell training. Obviously if the cloud is a simple abstraction, and your API doesn't change whether cloud or bare metal, there's not much training for "A Cloud Guru" to sell. It apparently isn't enough to optimize the model we already, we need a new paradigm or some such and a vendor to train us on it.
39 comments
[ 3.1 ms ] story [ 78.1 ms ] threadAs 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.
What resources are you comparing it to?
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.
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.
Also, if you want to do anything other than CRUD these types of services won't get you very far.
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.
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.
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.
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.
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.
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.