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

#201

Post by cphoover » Wed, Aug 01, 2018, 1:25 PM UTC

jacques_chester wrote: post #160

cphoover wrote: post #18

Earlier quoted context omitted.

NoSQL has been and continues to be hugely influential. All major cloud players provide document/object based storage, as well as other NoSQL Solutions. The term "NoSQL" was dumb and overhyped... But I think it's really about using the correct storage solution for the job. Non relational data should be stored in a non rdbms. Key-Value stores like Redis are immensely useful as caching layers (but they offer so many mor…

> monolithic large relational databases are hard to scale DB2 on z/OS was able handle billions of queries per day. In 1999. Some greybeards took great delight in telling me this sometime around 2010 when I was visiting a development lab. > When you have one large database with tons of interdependencies, it makes migrating data, and making schema changes much harder. Another way to say this is that when you have a too…

Not everything requires pessimistic transactional guarantees or atomicity. The problem domain you are solving for will influence the importance of those guarantees. If I'm solving for something where data consistency is not an utmost priority (tons of applications meet this criteria, including the one you are using now HN.) I don't have to worry about this.

But when you have transactional guarantees you also lose partition/failure tolerance. So it ends up being a choice of consistency over availability.

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

#202

Post by jacques_chester » Thu, Aug 02, 2018, 12:43 AM UTC

cphoover wrote: post #201

jacques_chester wrote: post #160

Earlier quoted context omitted.

> monolithic large relational databases are hard to scale DB2 on z/OS was able handle billions of queries per day. In 1999. Some greybeards took great delight in telling me this sometime around 2010 when I was visiting a development lab. > When you have one large database with tons of interdependencies, it makes migrating data, and making schema changes much harder. Another way to say this is that when you have a too…

Not everything requires pessimistic transactional guarantees or atomicity. The problem domain you are solving for will influence the importance of those guarantees. If I'm solving for something where data consistency is not an utmost priority (tons of applications meet this criteria, including the one you are using now HN.) I don't have to worry about this. But when you have transactional guarantees you also lose par…

> Not everything requires pessimistic transactional guarantees or atomicity.

They are easier to give up after the fact than to try to regain after the fact.

> If I'm solving for something where data consistency is not an utmost priority (tons of applications meet this criteria, including the one you are using now HN.) I don't have to worry about this.

Sure. But wait for the pain. Prove the business need to relax the guarantees and the business acceptance of the risks.

> So it ends up being a choice of consistency over availability.

Total partitions are relatively rare and so disruptive that even if the magical datastore keeps chugging, everything else is mostly boned, so it doesn't matter. Meanwhile people tend to discover that actually, consistency mattered all along, but it's impossible to fix in retrospect.

Then there's the whole thing of bold claims being made in theory and not delivered in reality. RDBMSes, with the exception of MySQL which is close to being singlehandedly responsible for the emergence of NoSQL in the first place, tend to actually deliver on what they promise. The record for the alternatives is mixed, the fine print varies wildly and tends to leave out important details like "etcd split brains if you sneeze too loudly" or "mongodb is super fast, unless you want your data back".

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

#203

Post by scarface74 » Thu, Aug 02, 2018, 2:34 AM UTC

paulddraper wrote: post #199

nrb wrote: post #178

Earlier quoted context omitted.

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.

Without a VPC, how do you not expose your Aurora cluster to the world?

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Auror...

Aurora DB clusters must be created in an Amazon Virtual Private Cloud (VPC). To control which devices and Amazon EC2 instances can open connections to the endpoint and port of the DB instance for Aurora DB clusters in a VPC, you use a VPC security group. These endpoint and port connections can be made using Secure Sockets Layer (SSL). In addition, firewall rules at your company can control whether devices running at your company can open connections to a DB instance. For more information on VPCs, see Amazon Virtual Private Cloud (VPCs) and Amazon RDS.

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

#204

Post by jjeaff » Thu, Aug 02, 2018, 5:56 PM UTC

eyjafjallajokul wrote: post #106

jjeaff wrote: post #102

Earlier quoted context omitted.

Localhost first is ideal. But not always possible.

Can you explain why?

Proprietary software or hidden configurations. I have my site on localhost docker container. But I can't spin up an Aurora instance. So I use a similar mysql container. But it's not exactly the same.

And sometimes the data is too large to have fully on localhost. You can work with a subset, but if you have a 2tb database, it's not feasible to have the whole thing local for testing.