Live data from Hacker News

Serverless, Inc. lands $10M Series A to build serverless dev platform

techcrunch.com

111–120 of 204 posts

Re: Serverless, Inc. lands $10M Series A to build serverless dev platform

#111

Earlier quoted context omitted.

> The reason "NoSQL" dbs got popular are because in my experience Monolithic large relational databases are hard to scale. I've met a lot of people whomst thought they had to scale that big. Very few handled anything that couldn't run off a beefy postgres installation. The purpose of a system is what it does. People don't use nosql to scale because they don't need to scale, so what does it do? People use nosql to not…

Scale is not just user load, but also scale of application complexity. In my experience when one db connection has access to every resource, in a complex application, this can lead to some really convoluted queries and make schema changes very difficult because of cross cutting dependencies built into these queries, triggers, procedures... etc. This is forgetting about the issues of deadlocks when you have 80 consumi…

> when one db connection has access to every resource

So why not use db users to restrict each part to only be able to access the parts it should?

Re: Serverless, Inc. lands $10M Series A to build serverless dev platform

#112
post #16

I don't understand the knee-jerk opposition people have to serverless architectures. I recently developed a service[1] with the serverless framework and it was the first time I enjoyed developing server-side code since the era of PHP on shared hosts, where you could just upload code and refresh the page. There's something freeing about never having to think about the server process or what happens if the server is po…

Serverless in this context is Server-aaS. It's doublespeak. That's why I "knee-jerk".

Instead of a couple of servers you have thousands of small virtual servers running on real server and call that serverless. It's comical.

I wonder what hell this approach will be for legacy serverless systems where there is stuff running everywhere and no one got a clue where to pull the plug or patch stuff.

Re: Serverless, Inc. lands $10M Series A to build serverless dev platform

#113
post #16

I don't understand the knee-jerk opposition people have to serverless architectures. I recently developed a service[1] with the serverless framework and it was the first time I enjoyed developing server-side code since the era of PHP on shared hosts, where you could just upload code and refresh the page. There's something freeing about never having to think about the server process or what happens if the server is po…

I don't understand the knee-jerk opposition people have to serverless architectures

It’s the name. It infuriates people because obviously there still really are servers. But I think of it like WiFi - there still are wires, you just don’t see them.

Re: Serverless, Inc. lands $10M Series A to build serverless dev platform

#114
post #16

I don't understand the knee-jerk opposition people have to serverless architectures. I recently developed a service[1] with the serverless framework and it was the first time I enjoyed developing server-side code since the era of PHP on shared hosts, where you could just upload code and refresh the page. There's something freeing about never having to think about the server process or what happens if the server is po…

It feels like a giant step backward from a development standpoint. It's as bad or worse than the days when I had to make a change, save it, FTP that file to the server, refresh, lather-rinse-repeat. Want a debugger? Nope. Want log files? Gotta get them from a different service that frequently has a lag of 30 seconds or more[1]. Don't get me started on the massive vendor lock-in inherent with a Serverless Architecture…

I don't disagree with you that serverless is a step backwards if you want control about your running platform but your debugger example can be argued away by the fact that you shouldn't really be debugging a live platform. If your code is portable enough to run "serverless" then you should be able to spin up a docker container or whatever and run the same tests in there.

I think the issue is some people see "serverless" as an all or nothing scenario which it really isn't. Some problems are solved well with serverless and some are not. It's like the container vs virtual machine argument. One isn't designed to replace another - they're just different tools for solving different problems; each have their own strengths and weaknesses.

Re: Serverless, Inc. lands $10M Series A to build serverless dev platform

#115
post #69

Earlier quoted context omitted.

Scale is not just user load, but also scale of application complexity. In my experience when one db connection has access to every resource, in a complex application, this can lead to some really convoluted queries and make schema changes very difficult because of cross cutting dependencies built into these queries, triggers, procedures... etc. This is forgetting about the issues of deadlocks when you have 80 consumi…

> "Scale is not just user load, but also scale of application complexity" In my experience, when people use NoSQL because "the application is too complex for relational DBs" they tend to make a mess of it, NoSQL included. They usually end up reinventing the wheel and re-writing buggy versions of features a RDBMS would have given them natively.

Been there, done that, migrated everything back to Postgres and saw huge gains.

Re: Serverless, Inc. lands $10M Series A to build serverless dev platform

#116
post #16

I don't understand the knee-jerk opposition people have to serverless architectures. I recently developed a service[1] with the serverless framework and it was the first time I enjoyed developing server-side code since the era of PHP on shared hosts, where you could just upload code and refresh the page. There's something freeing about never having to think about the server process or what happens if the server is po…

It feels like a giant step backward from a development standpoint. It's as bad or worse than the days when I had to make a change, save it, FTP that file to the server, refresh, lather-rinse-repeat. Want a debugger? Nope. Want log files? Gotta get them from a different service that frequently has a lag of 30 seconds or more[1]. Don't get me started on the massive vendor lock-in inherent with a Serverless Architecture…

Want a debugger? Nope.

https://www.markheath.net/post/remote-debugging-azure-functi...

Re: Serverless, Inc. lands $10M Series A to build serverless dev platform

#117

Earlier quoted context omitted.

It feels like a giant step backward from a development standpoint. It's as bad or worse than the days when I had to make a change, save it, FTP that file to the server, refresh, lather-rinse-repeat. Want a debugger? Nope. Want log files? Gotta get them from a different service that frequently has a lag of 30 seconds or more[1]. Don't get me started on the massive vendor lock-in inherent with a Serverless Architecture…

I don't disagree with you that serverless is a step backwards if you want control about your running platform but your debugger example can be argued away by the fact that you shouldn't really be debugging a live platform. If your code is portable enough to run "serverless" then you should be able to spin up a docker container or whatever and run the same tests in there. I think the issue is some people see "serverle…

How do I debug locally/on Docker with services like SNS and ElasticTranscoder? I know there are emulators but those have gaps in services that providers like AWS offer. Not to mention, I'm debugging with an emulator and not the real thing.

Re: Serverless, Inc. lands $10M Series A to build serverless dev platform

#118
post #113
post #16

I don't understand the knee-jerk opposition people have to serverless architectures. I recently developed a service[1] with the serverless framework and it was the first time I enjoyed developing server-side code since the era of PHP on shared hosts, where you could just upload code and refresh the page. There's something freeing about never having to think about the server process or what happens if the server is po…

I don't understand the knee-jerk opposition people have to serverless architectures It’s the name. It infuriates people because obviously there still really are servers. But I think of it like WiFi - there still are wires, you just don’t see them.

Except there literally isn't any wires in WiFi. Unless you're talking about power cables on access points or other unrelated tech used on devices that have ethernet / whatever AS WELL AS WiFi?

Re: Serverless, Inc. lands $10M Series A to build serverless dev platform

#119

Earlier quoted context omitted.

It feels like a giant step backward from a development standpoint. It's as bad or worse than the days when I had to make a change, save it, FTP that file to the server, refresh, lather-rinse-repeat. Want a debugger? Nope. Want log files? Gotta get them from a different service that frequently has a lag of 30 seconds or more[1]. Don't get me started on the massive vendor lock-in inherent with a Serverless Architecture…

Want a debugger? Nope. https://www.markheath.net/post/remote-debugging-azure-functi...

That's great. I'm sure Amazon and Google will follow suit. But they're not there yet and Amazon is the big guy that most people are on.

As I've said before; these are all problems that all of the cloud providers will solve eventually. But until they do I'm not sold on building a production application on a Serverless Architecture.

Re: Serverless, Inc. lands $10M Series A to build serverless dev platform

#120

Earlier quoted context omitted.

I don't see how. Your points of failure were always there, but at most they're more explicit since "service failure" conflates with "network failure" - something I think is beneficial, since you always had to handle "service failures" but they were implicit. That is - a piece of code in a monolith may fail, and a piece of code in a microservice may fail, but I've already written the code to handle network errors for…

That assumes that a local function call has the same failure rate as a remote function call to a microservice, which in my experience is very much not true. If I have a local function in the same language I can pretty much assume that a call to that function will actually call that function. With a remote call over HTTP or whatever I can't, so that is an additional failure I need to handle.

I'm not sure I understand. Why would an RPC call a different function than what you expect?

I'll grant you that there is more complexity in this approach, but I believe that fault tolerance is something you improve with microservices, not something you regress on.

Post reply on HN