Is this supposed to be comedic? It seemed comedic to me in several places. Is that the joke?
Guide to Serverless Architecture
61–70 of 105 posts
Re: Guide to Serverless Architecture
#62Earlier quoted context omitted.
You can play it at https://tombs.io/ It's pretty much a collaborative and social experiment where I wanted to explore the concept of using in-browser cryptocurrency mining as a monetization and bot fighting method (something I had a problem with in the original Ludum Dare entry it's based on). That's a different discussion though. (You need to manually start the mining and you can explore the map without doing it. It…
I get this from your site: Security risk detected: Trojan.Gen.NPE
Thanks! I presume it's the Coinhive script that triggers it. What antivirus software do you use?
Re: Guide to Serverless Architecture
#63For me the BIGGEST gain of using serverless architecture is security. For example, this year I started two ecommerce platforms. One's a digital delivery e-shop - selling ebooks, training and stuff and the other is a physical delivery e-shop. Normally, I'd write my own Phoenix/Rails app, but this time, I decided to go serverless for my furniture shop and wrote it all in Jekyll. Yes, the static site builder. I use netlify to manage the production aspect of it (which IS pretty AWESOME) and simple excel sheets to track inventory (which is what my vendor provides me, anyway). For payment, I simply use the checkout/cart functionality provided by Paypal and all this just works! The site is designed in such a way that you can't even tell anyway what's being used for the backend. No one can tell it's just a bunch of static HTML pages on display.
Whereas, for my digital delivery store, I regularly need to check my logs to see if anyone's doing anything suspecious. For example, a lot of IPs randomly try to visit wp-login.php or /phpmyadmin. Maintaining a production web application is a full time job by itself, if you don't have a team.
Having said that, many people would immediately assume static page builders are generally dumb. That isn't exactly true - You can automate a lot of stuff. For example, my local machine has a custom Jekyll plugin for my store that resizes and optimizes product images before pushing to prod to keep the page load time small. IF I had chosen the Rails/Phoneix route, I'd need to worry about hosting imagemagick or the like somewhere. Or maybe write some code to communicate with an third party API and usually, it's not free.
End of the day, I make sales and that's all that matters. That's when it hit me hard that my customers needn't care nor know what's behind their favorite site.
Re: Guide to Serverless Architecture
#64> Drawback of Serverless: Vendor lock-in, statelessness, local testing, cold/warm start perf, security, deployment, execution, monitoring, remote testing, debugging. Excuse me? Let's use lambda for what it was meant to do, not replace your entire stack.
But 'serverless' has a much nicer ring to it than 'serverfewer'...
"Serverfewer" sounds like the title of the next Neal Stephenson book :-)
Re: Guide to Serverless Architecture
#65For me the BIGGEST gain of using serverless architecture is security. For example, this year I started two ecommerce platforms. One's a digital delivery e-shop - selling ebooks, training and stuff and the other is a physical delivery e-shop. Normally, I'd write my own Phoenix/Rails app, but this time, I decided to go serverless for my furniture shop and wrote it all in Jekyll. Yes, the static site builder. I use netl…
If static sites are now also Serverless, the word has lost all meaning.
IF I had chosen the Rails/Phoneix route, I'd need to worry about hosting imagemagick or the like somewhere.
Static sites have no option but to run that stuff ahead of time, but that doesn't mean that dynamic sites can't do the same. Asset Pipelines with precompilation are pretty common - both Rails and Phoenix have one.
Re: Guide to Serverless Architecture
#66One thing I would like to see in articles like this are more concrete use cases for using serverless. The article begins talking about the concept as though you should write your entire app in serverless, and then in their case study, use serverless as a background process to convert image types. The other use case I always come across is image scaling. I'd be interested if anyone would like to share their use cases…
Well, I'll add my own use of serverless.
We use Lambda + API GW to manage the glue between our different data/service providers. So for instance we expose a "services" API (API GW) that takes a request, does some business logic (lambda code), calls the relevant provider(s) and returns the aggregate response. That principle can (and probably will) be extended to hosting our own back-end / business logic.
We're trying to get to the point where a dev only needs to write a Swagger file, the lambda code and a bit of configuration, and the rest is taken care of by AWS and our CI framework.
Re: Guide to Serverless Architecture
#67Re: Guide to Serverless Architecture
#68Earlier quoted context omitted.
The other key component of serverless is the pricing scheme: pay for what you use; don’t pay for provisioned capacity. This has a huge impact on how you design systems as you no longer have to consider throughput (besides account limitations that you can raise without cost), only latency. You can even treat lambda like an async queue which will never accumulate a backlog. Interestingly lambda seems to make async IO t…
> The other key component of serverless is the pricing scheme: pay for what you use; don’t pay for provisioned capacity. There is another way of looking at it: Pay for a percentage of the traffic, irrespective of how fast your application runs or what your budget is. If you reach your monthly budget because of one hacker news trending article, yeah, then no more traffic for you. It can be insane. If I have autoscalin…
I don't know if platforms already support it, but there's no reason why you can't have a throttle (calls/minute).
Re: Guide to Serverless Architecture
#69One thing I would like to see in articles like this are more concrete use cases for using serverless. The article begins talking about the concept as though you should write your entire app in serverless, and then in their case study, use serverless as a background process to convert image types. The other use case I always come across is image scaling. I'd be interested if anyone would like to share their use cases…
Well, I'll add my own use of serverless. We use Lambda + API GW to manage the glue between our different data/service providers. So for instance we expose a "services" API (API GW) that takes a request, does some business logic (lambda code), calls the relevant provider(s) and returns the aggregate response. That principle can (and probably will) be extended to hosting our own back-end / business logic. We're trying…
Very cool, thanks for sharing. The last part about just writing Swagger, Lambda, and a little config is very interesting.
Do you worry about vendor lock in, which is coming up a lot on this comment section?
Re: Guide to Serverless Architecture
#70Earlier quoted context omitted.
Well, I'll add my own use of serverless. We use Lambda + API GW to manage the glue between our different data/service providers. So for instance we expose a "services" API (API GW) that takes a request, does some business logic (lambda code), calls the relevant provider(s) and returns the aggregate response. That principle can (and probably will) be extended to hosting our own back-end / business logic. We're trying…
Very cool, thanks for sharing. The last part about just writing Swagger, Lambda, and a little config is very interesting. Do you worry about vendor lock in, which is coming up a lot on this comment section?
we're a small start-up, so I worry about shipping as fluidly as possible, and being confident that my infra just runs (security, patch management, scalability, uptime, etc.) All of which serverless gives me much more easily, and at a lower cost (for now) than running my own EC2 instances.
I'll worry about vendor lock-in (or dumping serverless for that matter) once I start to get ridiculous bills from AWS, or hit performance issues, or whatnot. But I try to mitigate by relying on standard formats (Swagger) and keeping my code as close to the business logic as possible - which is fairly easy with Lambda. The only thing that is really tied to AWS is the framework we use to build and deploy the architecture: a large Cloudformation file basically. We explored Serverless (the app) to manage this, but it didn't fit our need (in particular, Serverless has apparently never heard about Swagger, so that sucks).