Serverless, Inc. lands $10M Series A to build serverless dev platform • Hacker News Board

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

#191

Post by zaarn » Tue, Jul 31, 2018, 1:49 PM UTC

cphoover wrote: post #34

danharaj wrote: post #23

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…

I don't think I've seen a deadlock in a long long time on most major DB platforms.

PG also lets you get very vague about it being an relational DB if you want.

And tbh, if the size of your table impacts performance, you either don't have a very good DBA or your DBA doesn't know what partitioning is, both good reasons to replace them.

Most modern DBs don't have any of these issues, PG can cleanly handle live schema changes since it packs those in transactions. Old transactions simply use the previous schema. MariaDB requires a bit more fiddling but Github figured it out.

And from experience, you're likely not going to hit the scale where you need multiple DB nodes for performance. In 10 out of 10 cases, a simple failover is what you need (but didn't invest in because MongoDB is cooler).

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

#192

Post by zaarn » Tue, Jul 31, 2018, 1:58 PM UTC

jaequery wrote: post #131

i think more than half the websites on the internet can run on serverless platform and that makes the web more secure and faster.

I think more than half the websites on the internet can run on a shared hoster for less than 3$ a month and that makes the web more secure and faster.

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

#193

Post by zaarn » Tue, Jul 31, 2018, 2:01 PM UTC

exabrial wrote: post #63

danharaj wrote: post #2

Here's to hoping ignoring serverless will work as well as ignoring NoSQL worked for me.

This is anecdotal, and I've read cases of the opposite, so I know there are downvotes incoming. I've yet to work on a system where NoSQL was I was like "thank goodness we didn't use a structured database!". Instead, every time it's been the HIPPO trying to defend the decision while everyone else just deals with it. NoSQL seems to be taking a giant loan... You're going to need to organize and parse your data at some p…

Schemaless definitely has a few applications, usually systems related to tagging. Luckily you can easily integrate schemaless into your Postgres database with no performance downside all thanks to the magic of JSONB or FDW, depending on which way you swing.

The very few pure schemaless databases that continue to exist and where I'm convinced they will continue to exist for a long while are those that specialize a lot (ie, Redis, Elasticsearch, a lot of the Timeseries databases).

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

#194

Post by cphoover » Tue, Jul 31, 2018, 2:34 PM UTC

SahAssar wrote: post #111

cphoover wrote: post #34

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…

> 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?

Sure that works... I think encapsulation through separate db schemas is generally sufficient. Most people don't start or end up here however. I'm not saying that RDBMS used correctly is a bad thing. I prefer multiple small postgres schemas per "data service" (what I'm calling a service that deals only with data persistence, and updating consumers about changes to data), each schema can correlate to a single resource, or smallest possible domain of the application. These services can publish notifications about updates that can be consumed by consuming downstream services.

It's my opinion micro-services, should do one thing and do them well, and the data storage that backs these services should only be concerned with the domain of that single-purpose service. It should be isolated from all other concerns.

Having a separate schema for "users" than for "messages" for example.

Where to draw those dividing lines is not always easy.

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

#195

Post by staticassertion » Tue, Jul 31, 2018, 4:14 PM UTC

fauigerzigerk wrote: post #187

staticassertion wrote: post #148

Earlier quoted context omitted.

This is what I was saying though. Yes, you have to handle the failure case of "network call". Microservices add this failure case. But you already had to handle the case of "code blew up because of a bug". By forcing you to handle comm errors like network failure, you also force people, implicitly, to handle "code blew up because of a bug" errors. Even though it adds a second error case, you pretty much handle them t…

>But you already had to handle the case of "code blew up because of a bug". I'm handling bugs very differently than network failures though, because network failures are usually temporary while bugs are usually (or even by definition) permanent. Dealing with temporary outages in lots of places is extremely difficult. You may need retry logic. You may need temporary storage or queuing. You may need compensating transa…

> I'm handling bugs very differently than network failures though, because network failures are usually temporary while bugs are usually (or even by definition) permanent.

Depends on the bug - there are transient bugs that are not networking related.

But let's assume it's a "hard error" ie: a consistently failing bug. I would say where that bug is makes a huge difference.

If it's a critical feature, that bug should probably get propagated. If it's a non-critical feature, maybe you can recover.

By isolating your state across a network boundary, recovery failure is made much simpler (because you do not need to unwind to a 'safe point' - the safe point is your network boundary).

But it often depends how you do it. I personally prefer to write microservices that use queues for the vast majority of interactions. This makes fault isolation particularly trivial (as you move retry logic to the queue) and it scales very well.

If you build lots of microservices with synchronous communications I think you'll run into a lot more complexity.

Still, I maintain that faults were already something to be handled, and that a network bound encourages better fault handling by effectively forcing it upon you.

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

#196

Post by staticassertion » Tue, Jul 31, 2018, 4:15 PM UTC

manigandham wrote: post #175

staticassertion wrote: post #156

Earlier quoted context omitted.

> No server to manage is the least important part of it all. OK, well it's the most important part for me. I don't want to manage patching a box.

Sure, but there have always been options for that, regardless of abstraction level.

I don't know of an abstraction that provides FaaS + Managed System other than serverless - what are you referring to?

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

#197

Post by mmt » Tue, Jul 31, 2018, 9:29 PM UTC

laumars wrote: post #185

Zelphyr wrote: post #110

Earlier quoted context omitted.

We found that the further we got into using different services the more difficult local development became. I just assumed that, as in the old days of web development, we would be forced into not being able to do local development at all. So then we'd have to have duplication of services. One for development and one for production. Or multiples for development so that each developer didn't step on the toes of the oth…

It's good practice to have separation of dev and prod service anyway. I don't see that as duplication, I see that as different operating environments. Even back in the days of self hosting, I've lost track of the number of times a Dev script has gone wild and caused excessive load on the RDBMS or tried to spam the SMTP relay. On a Dev environment you can catch that without affecting live services. As for the other is…

> There have always been appliances in IT.

Indeed, and, as a general rule, they were astonishingly expensive, especially in up-front purchase cost.

> The only difference with public cloud solutions

I posit that another difference is that the up-front cost is approximately zero. That makes the adoption decision much easier (even possible in the first place) for much smaller companies, especially startups.

That also means what would otherwise have been an up-front cost is hidden in the pay-as-you-go cost.

That cost-hiding does create a new problem, albeit a sublte on. A startup faced with having to buy a $300k appliance might think nothing of it if there were a smaller/dev version available for $30k for that environment. However, if that appliance actually needed to be duplicated in the full $300k form [1] in both (or maybe more, if they have stage/qa/integration, research, and/or multiple dev envs), that startup would take a serious look at alternatives. Those relative costs aren't as stark with the cloud version of applicances, until well after the choice has been made.

[1] Or, worse, an even more expensive version, if dev, testing and/or research use of the appliance is heavier than production. I expect that's a rare, outside of storage.

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

#198

Post by com2kid » Tue, Jul 31, 2018, 11:11 PM UTC

joecot wrote: post #36

brylie wrote: post #32

Earlier quoted context omitted.

I may misunderstand your comment. That said, where I work (MaaS Global) we have a production PostgreSQL database hosted on AWS Relational Database Service (RDS): https://aws.amazon.com/rds/postgresql/ We connect to the AWS RDS instance in our lambda functions using an ES library called knex.js and some environment variables to store the DB credentials: https://knexjs.org/

How do you deal with the 10+ second cold start times for Lambda when using it in a VPC? Are you pre-warming your lambda functions? Did you open up your RDS instance to the world so you could connect to it from a public lambda network? I know you had to pull some magic, because I've been down that road. It's been a problem for years and there's been no sign of a solution. Example article from last month: https://mediu…

> How do you deal with the 10+ second cold start times for Lambda when using it in a VPC?

And I was complaining about 500ms cold start times on Firebase Functions.

I think I'll stop complaining now.

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

#199

Post by paulddraper » Wed, Aug 01, 2018, 2:08 AM UTC

nrb wrote: post #178

scarface74 wrote: post #171

Earlier quoted context omitted.

How is that a “hack”? You create your DB and you get a connection string to a publicly accessible database or you create it inside a VPC and you configure your lambda to run inside a subnet within your VPC and you configure your security group. This can all be configured within the console.

The main issue with this approach is that running your lambda in a VPC results in painfully slow cold starts, on AWS at least.

IDK why the parent mentioned VPC. It's not necessary.

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

#200

Post by bmilleare » Wed, Aug 01, 2018, 9:11 AM UTC

rawrmaan wrote: post #20

paulgb wrote: 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 think a lot of people have tried “serverless” and found it to present more challenges than it solves. How, for example, do you connect to a Postgres database from Lambda/Cloud Functions? As far as I can tell, the answer is: You don’t, you use a different database. No-worries devops experiences are nothing new. See Heroku.

As others have pointed out, connecting to RDS from Lambda is actually pretty trivial by having them run in the same VPC. We actually came up against an issue where our Lambda function needed access to RDS but also to the outside World which meant some extra hurdles to jump [1] but overall our experience with Lambda has been a positive one.

I don't think we'll be considering a fully serverless architecture anytime soon due to cold-start times, but it's awesome for anything outside of the user request/response loop or internal microservices where response time is perhaps not such of a problem.

[1] https://aws.amazon.com/premiumsupport/knowledge-center/inter...