One of the bigger problems with serverless architecture (beyond catastrophic lack of good debugging and development tools) is the idea of managing multiple users, working on multiple code branches, and all needing environments that somewhat closely mirror production. This leaves servless as a decent way to hook an event callback to some AWS event (new file uploaded to S3, etc) but IMHO not anything that approximates…
Second that. There's ELB + EC2 which can give you auto-scale but data persistence needs to be handled separately. There's AWS ECS which is/was quite unwieldy but I am hopeful for GAE's Flexible Environments (beta) built on Docker containers, putting it midway between Docker and Lambda with some interesting features https://cloud.google.com/appengine/docs/flexible/
Serverless Architectures
191–200 of 215 posts
Re: Serverless Architectures
#192That's the thing, I guess the demographic that lambada is going for it will save money, but along with the mentioned vendor lock in, when you really need to have something on and processing requests non stop the costs savings really evaporate.
It's weird to me that the serverless thing catches on when it seems to be best suited for projects in their infancy without need for 24/7 request processing , or things out of the critical path like image resizing or things of this nature. But entire apps? Feels very much like going back in time to shared hosting.
I could see it saving money until about 1m requests a day and then a sharp drop off where you are hemorrhaging cash after that...
With modern auto scaling systems that aws and gce provide I bet most shops don't stand to save any more money than with a normal modern day refactor.
At the end of the day this leaves you more rope to hang yourself with. It makes it easier to run slow or poorly thought out code. 1000 processes might be cool but is never as cheap as 2 working correctly that accomplish the same thing, as an extreme but actual example of a situation I helped unwind with GAE, which was serverless before the buzzword.
Re: Serverless Architectures
#193Earlier quoted context omitted.
First we need a common standard for the serverless pieces of code to talk to the app server and gateway... maybe we could call it a common gateway interface. Then maybe someone will write an apache module for it.
I laughed at the CGI reference, but TBH pub/sub + microservices feels really awesome and clean so far. Combined with DB as a service it's even better IMO.
Re: Serverless Architectures
#194Re: Serverless Architectures
#195Earlier quoted context omitted.
I would call that a deployment strategy, not an application architecture.
No! That's EXACTLY the point - this is EXACTLY what it isn't - a deployment strategy. Docker vs Ansible is a deployment strategy. Relying on others to make your code run on a server is VERY different than doing it yourself. It's practically the difference between a company with a DevOps team and one without it.
Write server-side code as part of my application, targetting some platform API. Once finished, invoke some deployment routine.
The service provider's job is:
Receive a request from me to deploy my server-side code and keep it running on some server cluster.
That's not a serverless applications architecture because the application contains server-side code.
If you don't want to call it a deployment strategy, fine, I won't insist on that name, even though in my view using a service provider for deployment deserves to be called a deployment strategy.
More generally, it's an approach to make my server-side code run once I'm finished writing it. Call it what you will.
Re: Serverless Architectures
#196Re: Serverless Architectures
#197I truly hope that people stop misleading the mass with buzz words. We already have too many of them being used for clickbait. I don't get why a simple client-server architecture would not suffice the "serverless". Software engineering and architecture design used to be cool in the past with useful design patterns. Now it's full of tricks/buzz words that promise the users of silver bullets that help them to manage cod…
"Serverless" seems to be the pricing model. It still runs on a server.
Re: Serverless Architectures
#198Earlier quoted context omitted.
Does it matter whether something is new or not? The fact is there are services such as AWS lambda that people are using and talking about, so we need terminology for that.
Not really, as long as it's useful. But call it what it is -- hosted services. Don't make up a new, nonsensical name.
Re: Serverless Architectures
#199So apparently "serverless" means you don't have to requisition a cloud instance to run the service. I remember this movie the first time around, when it was called "virtual hosting". What a revolution -- transitioning from needing a Unix box running Apache to run your PHP e-commerce site to having your host take care of that for you -- and everybody else. Just because you're doing something old "in the cloud" now doe…
Does it matter whether something is new or not? The fact is there are services such as AWS lambda that people are using and talking about, so we need terminology for that.
Take NoSQL which was hyped as something new 5 or 6 years back. Because of that everyone under a certain age decided that they had to use it.
The older more cynical of us realized that this was how people has been writing software before SQL came along, and realized we were throwing out a whole host of features and benefits because this was the "new" way of doing things.
Re: Serverless Architectures
#200Earlier quoted context omitted.
Not really, as long as it's useful. But call it what it is -- hosted services. Don't make up a new, nonsensical name.
Hosted services doesn't really differentiate what they are. DynamoDB is a hosted service. So is EC2 and ECS.