Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serverless Architectures

martinfowler.com

Post reply on HN
Print view View original

181–190 of 215 posts

Re: Serverless Architectures

#181

Post by sp527 »

rapind wrote: post #152
wcummings wrote: post #147

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 was thinking DBaaS as well, which is the part that's usually under-emphasized. NoSQL for specific tasks and (sharded if needed) relational with stored procedures for anything complex. When you think of Postgres as its own (heavily optimized) server, it changes the game. For most apps, at that point you just need a passthrough layer exposing endpoints, which is usually a dead simple nodejs app behind a balancer. The rest of the heavy logic is then offloaded to the client. This is why full-stack makes sense now more than ever. It's getting so easy there's almost no excuse anymore.

Re: Serverless Architectures

#182

Post by tcarey83 »

themihai wrote: post #2

The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.

Well for AWS Lambda, they offer three languages: Java, Javascript, and Python. Even then, its really just running in a container and you have access to anything in their standard Linux AMI and whatever else you include with your code, so you could really use almost any language you want. I'm using wkhtml2pdf with my Python code which is a c++ executable. Also, although the Python is 2.7, you can easily use the existing Python 3 environment or include your own.

As far as lock in, it is trivial to utilize the same code on your own servers. I do that for my Python code for development using a simple Cherrypy setup in less than 100 lines of code.

Re: Serverless Architectures

#183

Post by wpietri »

robotresearcher wrote: post #167
wpietri wrote: post #163

Earlier quoted context omitted.

You use "server" to mean "a vast array of servers"? I don't think I've heard that before.

I'd say that http://amazon.com is the address of Amazon's web server, yes. Does that sound wrong?

I don't think I have ever heard anybody use "server" to mean "lots of servers". Perhaps "web site" or "service" or "cluster" or even "load balancers" depending on whether they want to talk about what they provide or what does the providing.

Re: Serverless Architectures

#184

Post by tcarey83 »

scrollaway wrote: post #22
themihai wrote: post #2

The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.

I like to think that vendor lockin is something I care greatly about, for the correct reasons. In the case of AWS Lambda however, it doesn't apply. Serverless architecture isn't a "lockin" problem. You don't develop your app with serverless in mind, thinking that you might some day go back to serverful. Serverless is a core design of (some parts of) your app. When I hear people say they're trying to "be generic", "ab…

You can run all the Python 3 code you want. Just execute it from the Python 2.7 environment. The AWS Lambda environment does support it as the AWS environment is just the basic Linux AMI, and then you can include anything you want into your Lambda code zip file. You can exactly replicate the Linux image they use for Lambda and create your own custom environment that will run your code. What more could you ask for?

Re: Serverless Architectures

#185

Post by EGreg »

jwatte wrote: post #178
EGreg wrote: post #145

Why is it called serverless if it uses Amazon Lambda instances?

Because you, the developer, do not buy or pay for "servers," only ephemeral "code invocations."

Sweet! So by that logic, all static sites are serverless because I pay for "file hosting" right?

Re: Serverless Architectures

#186

Post by ronreiter »

fauigerzigerk wrote: post #94
adamt wrote: post #85

Earlier quoted context omitted.

The phrase that Amazon used when launching lambda was 'deploy code not servers'. To me this sums up what 'serverless' means. It means the developer doesn't have to worry about servers in any way. With AWS Lambda/API Gateway (and arguably with Google App Engine before it) you take away the toil of having to: * Manage/deploy servers * Monitor/maintain/upgrade servers * Figuring out tools to deploy your app to your serv…

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.

Re: Serverless Architectures

#187

Post by tomc1985 »

smt88 wrote: post #158
tomc1985 wrote: post #155

We used to have serverless architecture... it was called standalone desktop apps! No servers, no backend, no nothing, just you and the code. It was great!

It wasn't great. Updating apps was a huge pain, which meant that bugfixes were fewer and farther between. You couldn't sync preferences/settings between computers. Remember getting a new computer or wiping one? You knew you had hours of work ahead of you, just reconfiguring it. Did you write a shell script to do that for you? Too bad, it did something weird along the way, and now you have to spend hours figuring out…

It honestly wasn't so much of a bother. Updates were really the only pain point but then programs received updates periodically at best. (Talking dial-up era here) The cost of distribution motivated developers to release much higher-quality code, relatively-speaking, as not doing so cost you more (in terms of disks+shipping, additional bandwidth, etc) and well as earned a much greater amount of ire from your users.

If you were smart you had a system for dealing with migrating between computers. Maybe it was a script, maybe you knew which folders to copy, maybe you were extra careful with where you saved everything. Maybe you didn't care.

Some of the modern shit is nice (I fondly remember setting up a personal Active Directory+Exchange server to get a private LDAP sync, compared to Google now) but as a whole the current model encourages carelessness and mindless profiteering. There's too much of the equation nowadays in control of people who want to charge you for it, whereas before the user was had control. I miss the days when it was considered rude to require a network connection unnecessarily.

Plus, nowadays a product you love can turn to mush and there's nothing you can do about it save stop paying for it (and lose its services in the process), which will never amount to anything unless people do it en mass. Features regularly disappear because some bullshit business reason or another, or some user metric said only 2% of people used it. Well, fuck those 2% guys right?!? Before, if I didn't like your patch I could just revert to the old install discs. Nowadays I have to pray you don't alter your deal further.

edit: and don't get me wrong, as a developer the evergreen model is great. But as a power user, I hate it.

edit2: not to say older software didn't have its crap. Lots of fussy stuff to deal with. But compare the initial release of Windows 3.1 to Windows 10...

Re: Serverless Architectures

#188

Post by scrollaway »

tcarey83 wrote: post #184
scrollaway wrote: post #22

Earlier quoted context omitted.

I like to think that vendor lockin is something I care greatly about, for the correct reasons. In the case of AWS Lambda however, it doesn't apply. Serverless architecture isn't a "lockin" problem. You don't develop your app with serverless in mind, thinking that you might some day go back to serverful. Serverless is a core design of (some parts of) your app. When I hear people say they're trying to "be generic", "ab…

You can run all the Python 3 code you want. Just execute it from the Python 2.7 environment. The AWS Lambda environment does support it as the AWS environment is just the basic Linux AMI, and then you can include anything you want into your Lambda code zip file. You can exactly replicate the Linux image they use for Lambda and create your own custom environment that will run your code. What more could you ask for?

I know, and this is far slower as it involves a serialization/deserialization pass on the data as well as a subprocess.

> What more could you ask for?

Native support. Was that not obvious?

Re: Serverless Architectures

#190

Post by hackdroid »

There is google's appscript(based on javascript), which could also be termed as serverless. So ingenious for individual purposes, I have used it as a database(with google spreadsheet), scraping and saving 1000's of html/xml, deploying and demoing bootstrap websites. It also has a time limit of 5mins 30 seconds which could be overcome by controlling triggers or by using patt0's CBL http://patt0.blogspot.in/2014/08/continuous-batch-library-up....
Post reply on HN