Live data from Hacker News

Serverless Architectures

martinfowler.com

191–200 of 215 posts

Re: Serverless Architectures

#191
post #171

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/

check https://hyper.sh container-based cloud

Re: Serverless Architectures

#192
Would have liked to see some real cost analysis, other than it should save you money, because that is only true if scale is small to medium.

That'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

#193
post #152

Earlier 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.

I created Lite Engine[1] specifically as an alternative for this. Being able to POST and execute queries saved on the backend enables A LOT of functionality. Sqlite because it's simple to manage and allows massive multi tenancy for very low cost. And performs acceptably well for small/medium size work loads.

[1] https://www.lite-engine.com

Re: Serverless Architectures

#195

Earlier 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.

So my job is:

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

#196
It's sometimes okay to use inexact or uninformative terminology, but it becomes a problem when words are used to mean their exact opposite. So if you are going to talk about serverful programs - those which depend on servers and can't operate without them – that's fine, but please use some term other than 'serverless'.

Re: Serverless Architectures

#197

I 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…

I am reading about this trying to think what it could be useful for. (I am sure there are some, I don't see any use for it with my work).

"Serverless" seems to be the pricing model. It still runs on a server.

Re: Serverless Architectures

#198

Earlier 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.

Hosted services doesn't really differentiate what they are. DynamoDB is a hosted service. So is EC2 and ECS.

Re: Serverless Architectures

#199
post #50

So 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.

I think it does matter in a lot of circumstances.

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

#200

Earlier 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.

Then call it function hosting or business-logic hosting. "Serverless" means "there is no server" which is demonstrably false. Or should I assume that words don't mean things?
Post reply on HN