21–30 of 236 posts
Shout out to the RCE I found in the zeit.now deploy button: https://github.com/zpnk/deploy.now/issues/27 Hopefully someone from Zeit reading this can get my fix merged, it seems to be quite a popular service
Looks great for basic websites but it's missing the biggest and most difficult piece of cloud infrastructure. The DATABASE! Today you'd have to open up your cloud DB provider to the world since Zeit can't provide a list of IPs to whitelist. This is a showstopper for me unfortunately.
Shout out to the RCE I found in the zeit.now deploy button: https://github.com/zpnk/deploy.now/issues/27 Hopefully someone from Zeit reading this can get my fix merged, it seems to be quite a popular service
This is not supported nor maintained by us. Thanks a lot for bringing it to our attention. We will do our best to reach out!
> Serverless means never having to "try turning it off and back on again"
> Serverless models completely remove this category of issues, ensuring that no request goes unserviced during the recycling, upgrading or scaling of an application, even when it encounters runtime errors.
> How Does Now Ensure This?
> Your deployment instances are constantly recycling and rotating. Because of the request-driven nature of scheduling execution, combined with limits such as maximum execution length, you avoid many common operational errors completely.
Somehow this sounds very expensive to me (like restarting Windows 2000 every hour just to avoid a BSoD, except that here it’s not that time consuming a process) and seems to leave aside caching, state management and other related requirements on the wayside for someone else to handle or recover from.
Or it’s likely that I’ve understood this wrong and that this can actually scale well for large, distributed apps of any kind. Sounds like magic if it’s that way.
My biggest problem with serverless functions is development and testing. Can I run these locally? even better offline?
Yep. Pretty soon. You write code. You create a docker file. You find a place to run the docker file with your code [cheapest!]. Run it through your tests. Monitor it. The end. No vpcs,salts, puppets, sshs,chefs, horses,anisbles, cats,ec2s,devops,noops, sysadmins, kubernetes or chaos monkeys required.
this wont be popular but I always felt like docker was a step backwards in order to regroup and take a giant leap forward. I went from right clicking and deploying from visual studio to SSH and configuring dockerfiles, docker compose, even nginx.conf to loadbalance. You do get more bang for the buck with such setup but its too much work on infrastructure and less time for development. edit: add kubernetes to it, alth…
Being a FaaS proponent, I still think this could be a good idea, because of the kinda standardized workings of Docker. I mean, AWS also uses Docker for local testing.
> “A very common category of failure of software applications is associated with failures that occur after programs get into states that the developers didn't anticipate, usually arising after many cycles. In other words, programs can fail unexpectedly from accumulating state over a long lifespan of operation. Perhaps the most common example of this is a memory leak: the unanticipated growth of irreclaimable memory t…
> I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.
> “A very common category of failure of software applications is associated with failures that occur after programs get into states that the developers didn't anticipate, usually arising after many cycles. In other words, programs can fail unexpectedly from accumulating state over a long lifespan of operation. Perhaps the most common example of this is a memory leak: the unanticipated growth of irreclaimable memory t…
The crucial difference is that the activation cost of booting up a full OS (like Windows 2000) is massive (typically involving a chain-reaction of CPU and IO-intensive init services), whereas that is not the case for our serverless infrastructure.
What you do point out is one of the most important engineering challenges we had to solve (and continue to be focused on).
Looking at Now, it looks like you are billed by the 'plan' that you choose, and that decides how many deployment instances you are limited to. What does a deployment instance mean for something that is 'serverless'?
EDIT: Whoops, I see that there are 'on demand' prices for deployment instances too--now I just need to figure out how deployment instances map to serverless.
Looks great for basic websites but it's missing the biggest and most difficult piece of cloud infrastructure. The DATABASE! Today you'd have to open up your cloud DB provider to the world since Zeit can't provide a list of IPs to whitelist. This is a showstopper for me unfortunately.
If you connect to your database over TLS (maybe with an extra client certificate or something), I don't see much of a problem.
The problem is that it's possible, and very likely, there are exploits in the wild for your database server -- that are known but you failed to update for a day, or are 0 day exploits -- which are exploitable without having an authenticated account. Those issues can't be exploited if you firewall your database server to known IPs, but once you make it world accessible, all bets are off.