10 ms·

I hear a lot of evangelism but no success stories aside from one-off use cases that almost seem designed to benefit from the autoscaling. To me, this is market

I hear a lot of evangelism but no success stories aside from one-off use cases that almost seem designed to benefit from the autoscaling. To me, this is marketing and second-tier marketing by consultants hoping to sell you their services. Serverless makes it harder to test locally, harder to move between hosts, often times much slower (cold starts), and forces going to the network to do things like persist to disk, run queues, etc. Of course, all these services are provided by the megacorp in charge of your servers so the lock-in goes deeper. The only ones that should be considering serverless are companies that need to scale up and down operations at a moment's notice. That is if you're huge or doing a lot of short-burt big data processing. Otherwise, it's all koolaid. Enjoy the open standards we have. Let's work on improving and evangelizing those instead of megacorp lock-ins.

emforce 9y ago
If we look at the likes of Unity3D, nothing was perfect straight off the bat, and I feel like the same can be said of Serverless architectures. The people offering serverless are no doubt aware of the difficulties and I wouldn't be surprised if they said they were developing something that would make this easier. Cold starts are a valid issue though and I feel that the effects of this can be minimized with the use of fast compiled languages such as Go. Lock-in is also a worry for most, as we progress we need to ensure that we are able to write serverless code in such a manner that they can easily be transported across to other serverless providers.
- jacques_chester 9y ago
  > Cold starts are a valid issue though and I feel that the effects of this can be minimized with the use of fast compiled languages such as Go. Warmed-up code will always have an edge. Even if Go code can launch very fast, the same binary retained in main memory and heavily represented in L2 and L3 caches is going to absolutely stomp the same bits being loaded from disk over and over. > Lock-in is also a worry for most, as we progress we need to ensure that we are able to write serverless code in such a manner that they can easily be transported across to other serverless providers. This will come down to folks building such platforms. I am working for Pivotal on Project Riff. Oracle released Fn, IBM and others are supporting OpenWhisk. There are really a lot of people working on it.
illumin8 9y ago
How about this: https://read.acloud.guru/serverless-superheroes-eric-hammond-aws-lambda-and-the-power-of-code-31f847a2150f https://read.acloud.guru/serverless-superheroes-eric-hammond... From the article: > The most surprising thing I learned from building TimerCheck.io was: If designed well, it is possible for some products built with services like AWS Lambda, API Gateway, and DynamoDB (often categorized as “serverless”) to require zero technical maintenance! The public, free TimerCheck.io microservice API was released in July 2015 and I have never had to do anything to keep it working or to scale it, with one notable and unexpected exception. > The only time I had to do work on TimerCheck.io was when Amazon declared that AWS Lambda support for Node 0.10 was being phased out. If my code base had been larger, it probably would have been easier to simply upgrade to Node 6.10, but I decided instead to rewrite the function in Python 3.6. It has continued operating smoothly since. > As part of the rewrite, I also took advantage of one of several good AWS Lambda deployment tools that have arisen to fill what was an important gap when Lambda was launched. I chose Amazon’s open source chalice tool for this project, and was thrilled with how it eliminated all the work of setting up an API Gateway, a formerly daunting task. > The TimerCheck.io service has had a few short outages over the years, but they were always due to region-wide problems that AWS experienced, and AWS resolved the issue without me having to lift a finger. Even with a lot of work and expense, I could not reproduce that uptime. Letting Amazon operate my service infrastructure more reliably is well worth the cheaper price. > Speaking of expenses, I’ve been pleasantly surprised by the cost-effectiveness of the AWS services used by TimerCheck.io. I wrote an article that broke down the operating charges for December, 2016 which came out to $11 for 2.1 million API hits. I just checked, and in August 2017 it had grown to 4.8 million API hits for about $20 (“blended price” makes it difficult to calculate exactly).
RhodesianHunter 9y ago
My team (~20 people within a Fortune 50) could be considered a success story. We use Lambda for ETL type work, Healthchecks, Web Scraping, and infrastructure automation. > Serverless makes it harder to test locally, harder to move between hosts Most of our code is written in Java. We have a main method, which calls a static method. The only difference between running locally and running in Lambda is that the Lambda calls the static method while we call the Main method locally. This also pretty much eliminates lock-in since all of the code behind the static method could without much trouble be moved behind an API endpoint running in a more traditional environment. > The only ones that should be considering serverless are companies that need to scale up and down operations at a moment's notice. That is if you're huge or doing a lot of short-burt big data processing. Otherwise, it's all koolaid. Respectfully disagree, as first hand experience has taught me otherwise. Just like any tool, Lambda is extremely effective when used for the things it excels at.
- xstartup 9y ago
  Assuming most companies start their ETL job at midnight in UTC. Isn't serverless more expensive when everyone needs it at the same time?
  - RhodesianHunter 9y ago
    You're charged by memory utilization and compute time. The number of others using it at the same time has no bearing on price.
- jacques_chester 9y ago
  I'd be interested in talking to you when I get back to work (2 weeks from now). My email is in my profile.
  - RhodesianHunter 9y ago
    As long as you don't try to sell me anything I'm always happy to chat.
- 9y ago

emforce 9y ago

If we look at the likes of Unity3D, nothing was perfect straight off the bat, and I feel like the same can be said of Serverless architectures. The people offering serverless are no doubt aware of the difficulties and I wouldn't be surprised if they said they were developing something that would make this easier. Cold starts are a valid issue though and I feel that the effects of this can be minimized with the use of fast compiled languages such as Go. Lock-in is also a worry for most, as we progress we need to ensure that we are able to write serverless code in such a manner that they can easily be transported across to other serverless providers.

jacques_chester 9y ago
> Cold starts are a valid issue though and I feel that the effects of this can be minimized with the use of fast compiled languages such as Go. Warmed-up code will always have an edge. Even if Go code can launch very fast, the same binary retained in main memory and heavily represented in L2 and L3 caches is going to absolutely stomp the same bits being loaded from disk over and over. > Lock-in is also a worry for most, as we progress we need to ensure that we are able to write serverless code in such a manner that they can easily be transported across to other serverless providers. This will come down to folks building such platforms. I am working for Pivotal on Project Riff. Oracle released Fn, IBM and others are supporting OpenWhisk. There are really a lot of people working on it.

illumin8 9y ago

How about this: https://read.acloud.guru/serverless-superheroes-eric-hammond-aws-lambda-and-the-power-of-code-31f847a2150f https://read.acloud.guru/serverless-superheroes-eric-hammond... From the article: > The most surprising thing I learned from building TimerCheck.io was: If designed well, it is possible for some products built with services like AWS Lambda, API Gateway, and DynamoDB (often categorized as “serverless”) to require zero technical maintenance! The public, free TimerCheck.io microservice API was released in July 2015 and I have never had to do anything to keep it working or to scale it, with one notable and unexpected exception. > The only time I had to do work on TimerCheck.io was when Amazon declared that AWS Lambda support for Node 0.10 was being phased out. If my code base had been larger, it probably would have been easier to simply upgrade to Node 6.10, but I decided instead to rewrite the function in Python 3.6. It has continued operating smoothly since. > As part of the rewrite, I also took advantage of one of several good AWS Lambda deployment tools that have arisen to fill what was an important gap when Lambda was launched. I chose Amazon’s open source chalice tool for this project, and was thrilled with how it eliminated all the work of setting up an API Gateway, a formerly daunting task. > The TimerCheck.io service has had a few short outages over the years, but they were always due to region-wide problems that AWS experienced, and AWS resolved the issue without me having to lift a finger. Even with a lot of work and expense, I could not reproduce that uptime. Letting Amazon operate my service infrastructure more reliably is well worth the cheaper price. > Speaking of expenses, I’ve been pleasantly surprised by the cost-effectiveness of the AWS services used by TimerCheck.io. I wrote an article that broke down the operating charges for December, 2016 which came out to $11 for 2.1 million API hits. I just checked, and in August 2017 it had grown to 4.8 million API hits for about $20 (“blended price” makes it difficult to calculate exactly).

RhodesianHunter 9y ago

My team (~20 people within a Fortune 50) could be considered a success story. We use Lambda for ETL type work, Healthchecks, Web Scraping, and infrastructure automation. > Serverless makes it harder to test locally, harder to move between hosts Most of our code is written in Java. We have a main method, which calls a static method. The only difference between running locally and running in Lambda is that the Lambda calls the static method while we call the Main method locally. This also pretty much eliminates lock-in since all of the code behind the static method could without much trouble be moved behind an API endpoint running in a more traditional environment. > The only ones that should be considering serverless are companies that need to scale up and down operations at a moment's notice. That is if you're huge or doing a lot of short-burt big data processing. Otherwise, it's all koolaid. Respectfully disagree, as first hand experience has taught me otherwise. Just like any tool, Lambda is extremely effective when used for the things it excels at.

xstartup 9y ago
Assuming most companies start their ETL job at midnight in UTC. Isn't serverless more expensive when everyone needs it at the same time?
- RhodesianHunter 9y ago
  You're charged by memory utilization and compute time. The number of others using it at the same time has no bearing on price.
jacques_chester 9y ago
I'd be interested in talking to you when I get back to work (2 weeks from now). My email is in my profile.
- RhodesianHunter 9y ago
  As long as you don't try to sell me anything I'm always happy to chat.
9y ago