"Full Stack Serverlesss applications can be shared and deployed as an end to end project without much concern about the developer's local environment because all of the infrastructure is running in the cloud"
So, just like when using a local VM, e.g. a Vagrantbox
"We expect Serverless computing to become simpler to program securely than Serverful computing"
It won't be, because it is just a program running on an OS. It doesn't matter if you put a Dockerfile around it and call it "Serverless". There's still just as much Server there as otherwise. If you're a horribly bad programmer who knows nothing about the most basic security things, Docker won't help you.
"We see no fundamental reason why the cost of Serverless computing should be higher than that of Serverful computing"
Because it is a waste of resources and has a ton of overhead.
"So, just like when using a local VM, e.g. a Vagrantbox"
I don't think this an accurate representation. A VM or a container works with many dependencies that still needs to be maintained by the dev team, e.g., OS of choice, tweaks in ports, custom environments likes timezones etc; A Lambda, per example, you just need to choose a runtime target, a memory size and you are done besides of course the lib dependencies of your code. You even don't need provision the Vagrant config that in the real world in my experience is really messy sometimes with developers getting problems on their own VMs.
"There's still just as much Server there as otherwise. "
For sure. But in this model you don't have the overhead to manage, patch and so on. Serverless naming is somewhat misleading. In reality, as I see, is just an abstraction for the infrastructure. For small teams, per example, is not practical create a CI/CD pipeline. You just don't have time or even someone with all the know how to build, and the most important, maintain. Some of the serverless managed services provided this out of the box. I'm not trying to convince you otherwise of your choices and as Mark Richards and Neal Ford put in "Fundamentals of Software Architecture: An Engineering Approach", "Everything in software architecture is a trade-off", adding that if someone doesn't seem a trade off in a decision is because it just not found it yet. So, for sure there are trade off and some teams and individuals will likely run bare metal and manage all the things, but I wouldn't dismiss so bluntly a very large set of offerings and possibilities developers can leverage with the serverless ecosysteam.
Comment marked as low quality/non-constructive by the community. View Code of Conduct
"You even don't need provision the Vagrant config that in the real world in my experience is really messy sometimes with developers getting problems on their own VMs."
In our company we just use a bogstandard Vagrantbox from app.vagrantup.com (OpenSUSE Leap 15.2 to be exact; we just had to switch unfortunately from FreeBSD because a tool we need doesn't run on it) and use the same Ansible file to provision it as we use for the live servers. This means we get to provision the dev box, the staging server and the live server all with the same config, despite them using different platforms (VirtualBox, Google Compute Engine). (I can even deploy the entire "server landscape" consisting of build1, build2, feature1, feature2, staging, live, plus the postgresql server, with just one Ansible command ;) )
What are potential problems you've run into with that? Genuinely curious, maybe we have something to look out for.
What we do use, though, is a hosted PostgreSQL server, to see how it'll work. So far it's doing fine, the downside being we don't get to decide when e.g. it gets updated.
"But in this model you don't have the overhead to manage, patch and so on."
idk, running sudo zypper up isn't much of an overhead - and in the worst case, you just destroy and redeploy the server :)
Running sudo zypper up is basically the tradeoff to being able to decide what exactly the software stack we want to use looks like. E.g. there's no OpenSUSE Leap 15.2 available on Google Cloud.
"For small teams, per example, is not practical create a CI/CD pipeline. You just don't have time or even someone with all the know how to build, and the most important, maintain."
I know, gatekeeping and all, but... I wouldn't hire a developer who's too incompetent to write a simple CI/CD pipeline for e.g. GitLab CI (after all, a dev should be capable of doing DevOps aka SCCM). It took me all of 30 minutes to write the script that compiles our product, runs the tests, scps it over to the server and restarts the service there using systemctl. And in the end, a Dockerfile is nothing but yet another CI pipeline to maintain.
Who knows, maybe I am totally out of the loop. Or maybe I am oldfashioned for thinking that a good dev should know a bit about the system / platform in use. But that's my view on it all; we are getting way too abstracted, and our projects and tools more and more sit atop a shaky, badly-maintained pile of not always suitable other tools.
"Full Stack Serverlesss applications can be shared and deployed as an end to end project without much concern about the developer's local environment because all of the infrastructure is running in the cloud"
So, just like when using a local VM, e.g. a Vagrantbox
"We expect Serverless computing to become simpler to program securely than Serverful computing"
It won't be, because it is just a program running on an OS. It doesn't matter if you put a Dockerfile around it and call it "Serverless". There's still just as much Server there as otherwise. If you're a horribly bad programmer who knows nothing about the most basic security things, Docker won't help you.
"We see no fundamental reason why the cost of Serverless computing should be higher than that of Serverful computing"
Because it is a waste of resources and has a ton of overhead.
"So, just like when using a local VM, e.g. a Vagrantbox"
I don't think this an accurate representation. A VM or a container works with many dependencies that still needs to be maintained by the dev team, e.g., OS of choice, tweaks in ports, custom environments likes timezones etc; A Lambda, per example, you just need to choose a runtime target, a memory size and you are done besides of course the lib dependencies of your code. You even don't need provision the Vagrant config that in the real world in my experience is really messy sometimes with developers getting problems on their own VMs.
"There's still just as much Server there as otherwise. "
For sure. But in this model you don't have the overhead to manage, patch and so on. Serverless naming is somewhat misleading. In reality, as I see, is just an abstraction for the infrastructure. For small teams, per example, is not practical create a CI/CD pipeline. You just don't have time or even someone with all the know how to build, and the most important, maintain. Some of the serverless managed services provided this out of the box. I'm not trying to convince you otherwise of your choices and as Mark Richards and Neal Ford put in "Fundamentals of Software Architecture: An Engineering Approach", "Everything in software architecture is a trade-off", adding that if someone doesn't seem a trade off in a decision is because it just not found it yet. So, for sure there are trade off and some teams and individuals will likely run bare metal and manage all the things, but I wouldn't dismiss so bluntly a very large set of offerings and possibilities developers can leverage with the serverless ecosysteam.
In our company we just use a bogstandard Vagrantbox from app.vagrantup.com (OpenSUSE Leap 15.2 to be exact; we just had to switch unfortunately from FreeBSD because a tool we need doesn't run on it) and use the same Ansible file to provision it as we use for the live servers. This means we get to provision the dev box, the staging server and the live server all with the same config, despite them using different platforms (VirtualBox, Google Compute Engine). (I can even deploy the entire "server landscape" consisting of build1, build2, feature1, feature2, staging, live, plus the postgresql server, with just one Ansible command ;) )
What are potential problems you've run into with that? Genuinely curious, maybe we have something to look out for.
What we do use, though, is a hosted PostgreSQL server, to see how it'll work. So far it's doing fine, the downside being we don't get to decide when e.g. it gets updated.
idk, running
sudo zypper upisn't much of an overhead - and in the worst case, you just destroy and redeploy the server :)Running
sudo zypper upis basically the tradeoff to being able to decide what exactly the software stack we want to use looks like. E.g. there's no OpenSUSE Leap 15.2 available on Google Cloud.I know, gatekeeping and all, but... I wouldn't hire a developer who's too incompetent to write a simple CI/CD pipeline for e.g. GitLab CI (after all, a dev should be capable of doing DevOps aka SCCM). It took me all of 30 minutes to write the script that compiles our product, runs the tests,
scps it over to the server and restarts the service there usingsystemctl. And in the end, a Dockerfile is nothing but yet another CI pipeline to maintain.Who knows, maybe I am totally out of the loop. Or maybe I am oldfashioned for thinking that a good dev should know a bit about the system / platform in use. But that's my view on it all; we are getting way too abstracted, and our projects and tools more and more sit atop a shaky, badly-maintained pile of not always suitable other tools.
Well thanks for say in a polite way I and my co-workers are incompetent.
I think we have very different visions of is a CI/CD pipeline, and ways to treat people.