So why are we still fighting so hard to maintain the local environment
Because not everyone had fiber internet direct to their house. You know how every call there's at least one person "dealing with connection issues all morning"? That's in VoIP traffic prioritized by ISPs. It's bad enough having people not be able to sync up as needed, let's not make it so that you can't do work when latency spikes after 4pm.
No local development would lock out a decent chunk of remote workers even within the US.
But why else? Because debugging is still an incredibly important process and remote debugging still takes heroics to set up for many environments.
And because setting up IAM and network/vm configuration properly to support junior developers cranking out a cloud-first prototype requires expertise that far from every team lead has. (Localstack works great for this)
And because exploring an idea in an unfamiliar codebase/framework shouldn't have you praying you throttled billing well enough to not accidentally end up homeless
There's more but let's stop there. I don't want every single day to day thing I do in development to be coupled to concerns over billing.
Because not everyone had fiber internet direct to their house
Testing in the cloud can be done on dial up. A full deployment of an entire service is usually only a few MB's. Using tools (such as the serverless deploy function) command to push ONLY code changes to test is usually less than kb's and only text. This is not equivalent to VoIP which is streaming and far larger in volume so to compare the two is false analogy.
Because debugging is still an incredibly important process and remote debugging still takes heroics to set up for many environments.
sls deploy function -f functionName and after 3 secomnds or less the code is in AWS. Then sls logs -t functionName and you have a tail of remote logs to view on your terminal. Use sls invoke -f functionName to execute it and get feedback on the logs you are currently tailing. This is FAR easier than pretty much ANY local development environment that I have had the pleasure of using in the past.
And because exploring an idea in an unfamiliar codebase/framework shouldn't have you going you throttled billing well enough to not accidentally end up with a mega bill.
I understand this fear but in practicality it is over blown and just not true. I have had "accidental" mega bills myself twice in the past and both times AWS had 0 issue reversing the charges. If developers want security, the org they work for can provide them an AWS account to play in instead.
And because setting up IAM and network/vm configuration properly to support junior developers cranking out a cloud-first prototype requires expertise that far from every team lead has.
The framework can do a lot of that heavy lifting for you and can be configured as a part of the deployment process so that it doesn't need to be manually configured by "someone in the know" each time. And traditionally we see more and more Serverless applications not using VPC and complex network architectures.
The entire point of the post is to point out that because serverless allows us to deploy easily, quickly and with 100% accuracy in multiple environments we can leverage off of that to finally be working in an environment that doesn't result in "it worked on my machine" when stuff inevitably breaks in production because of some nuance of the production environment no one expected or experienced.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Because not everyone had fiber internet direct to their house. You know how every call there's at least one person "dealing with connection issues all morning"? That's in VoIP traffic prioritized by ISPs. It's bad enough having people not be able to sync up as needed, let's not make it so that you can't do work when latency spikes after 4pm.
No local development would lock out a decent chunk of remote workers even within the US.
But why else? Because debugging is still an incredibly important process and remote debugging still takes heroics to set up for many environments.
And because setting up IAM and network/vm configuration properly to support junior developers cranking out a cloud-first prototype requires expertise that far from every team lead has. (Localstack works great for this)
And because exploring an idea in an unfamiliar codebase/framework shouldn't have you praying you throttled billing well enough to not accidentally end up homeless
There's more but let's stop there. I don't want every single day to day thing I do in development to be coupled to concerns over billing.
Testing in the cloud can be done on dial up. A full deployment of an entire service is usually only a few MB's. Using tools (such as the
serverless deploy function) command to push ONLY code changes to test is usually less than kb's and only text. This is not equivalent to VoIP which is streaming and far larger in volume so to compare the two is false analogy.sls deploy function -f functionNameand after 3 secomnds or less the code is in AWS. Thensls logs -t functionNameand you have a tail of remote logs to view on your terminal. Usesls invoke -f functionNameto execute it and get feedback on the logs you are currently tailing. This is FAR easier than pretty much ANY local development environment that I have had the pleasure of using in the past.I understand this fear but in practicality it is over blown and just not true. I have had "accidental" mega bills myself twice in the past and both times AWS had 0 issue reversing the charges. If developers want security, the org they work for can provide them an AWS account to play in instead.
The framework can do a lot of that heavy lifting for you and can be configured as a part of the deployment process so that it doesn't need to be manually configured by "someone in the know" each time. And traditionally we see more and more Serverless applications not using VPC and complex network architectures.
The entire point of the post is to point out that because serverless allows us to deploy easily, quickly and with 100% accuracy in multiple environments we can leverage off of that to finally be working in an environment that doesn't result in "it worked on my machine" when stuff inevitably breaks in production because of some nuance of the production environment no one expected or experienced.