
Serverless, Inc. lands $10M Series A to build serverless dev platform - TheMissingPiece
https://techcrunch.com/2018/07/30/serverless-inc-lands-10-m-series-a-to-build-serverless-developers-platform/
======
paulgb
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 power cycled.

So congrats on the funding, I hope you can convert some haters :)

[1] obligatory plug: [https://notify.run](https://notify.run)

~~~
rawrmaan
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.

~~~
yoran
I think the example you give is more because there's a mismatch between
technologies, rather than the "fault" of serverless. In serverless, your
endpoints become infinitely scalable. This doesn't go well when they're backed
by technologies where there is a hard limit on the number of connections, for
instance SQL servers or a Redis server. I think therefore that SQL database
technologies have to adapt to the serverless paradigm rather than dismissing
serverless "because it brings so many other issues". I think AWS has already
started that with Amazon Aurora.

That aside, I agree that there are a lot of secondary concerns that are
important when running things in production but that aren't available out-of-
the-box when you run something on AWS Lambda. I'm thinking about error
monitoring, performance monitoring, logging,... All those things need to be
set up and that's quite time-consuming.

However, I think that's more due to serverless being relatively new and not as
mature as the traditional way of doing. I don't think it will take long before
we'll have the equivalent for serverless of adding `gem 'newrelic_rpm'` to
your Gemfile and magically having performance and error monitoring across your
app.

~~~
rantanplan
> I think therefore that SQL database technologies have to adapt to the
> serverless paradigm rather than dismissing serverless

Empty statement that means nothing. SQL/RDBMS is backed by computer science
and robust engineering examples that make the world spin. Alternatives are
usually full of fanfare and false promises.

> I think AWS has already started that with Amazon Aurora.

Just in time when we were talking about fanfare. Spend 10-20 minutes searching
on the Internets to see what actual experiences people have with it.

Its 3X write increase? Bollocks. Usually the performance is worse than when
you administer your own DB(Postgresql/MySQL). You might(or not) see some read-
performance increase, which... well everyone can scale on reads so I don't see
the point.

I suspect it has other goodies pertaining to administration/provisioning, but
performance/scaling is not one of them.

~~~
athenot
>> I think therefore that SQL database technologies have to adapt to the
serverless paradigm rather than dismissing serverless

> Empty statement that means nothing. SQL/RDBMS is backed by computer science
> and robust engineering examples that make the world spin. Alternatives are
> usually full of fanfare and false promises.

Traditional relational databaases have indeed solved many issues that some
newer datastores struggle with. But the flip side is that it is non-trivial to
design traditional databases that are not Single Points Of Failure.

Storing data is surprizingly hard in a cloud environment, and involves trade-
offs. Reaching a comprehensive solution (fast, HA, consistent, easily
recoverable, scalable volum, evolvable schemas...) is hard no matter what
technology you pick.

------
sebringj
I ended up using lamda for several things ad hoc and I have to say the
experience is great to quickly add functionality to specific niche things you
don't necessarily want to run on your API servers because of weight or simply
that having a trigger built in makes the whole flow simpler. However, the
downside is if you do something stupid like create an infinite trigger
accidentally your bill will exponentially increase. Always remember that part.
On a $5 digital ocean instance, they will never charge you $3000 a month for
accidentally doing something stupid but AWS will forgive you one time at least
and I have my one time now. The most hilarious part of this whole thing...and
this is really one of the main points, the $5 digital ocean kuejs (nodel.js)
server instance that my AWS lamda was smashing the shit out of with millions
of requests did not go down the entire time although had some intermittent
slow downs of course. $5 goes a long way apparently.

------
_Marak_
Congratulations to Austen and Serverless Inc. for raising an additional 10m
dollars. From what I've seen they are all very nice people over at Serverless.

I've been running a small service similar to their new "Serverless Platform"
for some time and was approached by them in 2014 to see about joining their
team.

Ultimately I ended up deciding not to join because I wasn't convinced there
was a strong enough engineering presence in their leadership to make a good
product. The next couple of years should be interesting to watch if they can
actually build a profitable product.

~~~
nodesocket
> I wasn't convinced there was a strong enough engineering presence in theit
> leadership to make a good product

That seems like a strange requirement. Ultimately for a business to be
successful there has to be people that know business, marketing, and slaes. If
the leadership team is all hard-core tech engineers, there will be a lack of
all of the other social and fundamental business skills needed.

~~~
spamizbad
I think it’s perfectly reasonable given their domain. If you’re in a
technology-frontiering business, of which serverless most certainly qualifies
for, you need management that’s going to support engineering through the
litany of challenges they will face. I’ve seen founders get cold feet and cut
corners or pivot away from things when the engineering side seems daunting.

The other side here is your customers are likely engineers themselves. You
need to build products that connect with them and genuinely make their lives
easier... if your leadership is too far removed from that you’ll end up with a
product platform shapes via a game telephone...

With that said, some strong hires early on can make a real difference here.

------
pmlnr
The coming age of people with no understanding of what running code actually
means, no idea how hardware/close to hardware systems behave deep down, is
going to be fabulous, and full of wasted computing.

~~~
dragonwriter
> The coming age of people with no understanding of what running code actually
> means, no idea how hardware/close to hardware systems behave deep down, is
> going to be fabulous, and full of wasted computing.

Just like _now_ is to people who were programming in the 1990s, or the 1990s
to people who were programming in the 1970s.

~~~
pmlnr
Partially agreed; on the other hand, Arduinos & PIC helped a lot to get, say,
hardware IRQs, something that is quite heavily abstracted away in general
computing.

------
jaflo
Wooo! I'm happy for them! I am using their stuff right now for a project I'm
working on (plug: [https://kurz.app/](https://kurz.app/)) and I really
appreciate the ecosystem serverless is cultivating. Simple stuff like bundling
up pip requirements or syncing a local folder with a S3 bucket could be done
using a script I write, but through serverless I can just install a package
and have it hook in as part of each deploy.

~~~
brettlangdon
Wow, this is a really cool application. I needed to cut down a song this week
and this is a very cool approach.

~~~
jaflo
Thank you! I really appreciate it. Can I ask what you cut the song down for? I
think I'll make a ShowHN post soon and am still trying to figure out my market
outside of video editors.

~~~
brettlangdon
Wedding first dance song. Original was 5+ minutes long, we need 2-3.

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

~~~
cphoover
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 more
features). Graph databases can be used for data with complex relationships
that are not easily modeled. They are also good for seeking strong
correlations between related items. (think person A. called person B. called
person C. (palantir type searches).). Searches can be done way more
effectively in a specialized index, like an inverted index used by
lucene/elasticsearch, which also supports things like stemming, synonyms, and
numerous other features. These are all "NoSQL" NoSQL is not just mongodb
(which isn't nearly as bad as people make it out to be btw).

Even traditional RDBMS are seeing an influx of NOSQLesque features. Like JSON
types and operations in postgres.

The reason "NoSQL" dbs got popular are because in my experience monolithic
large relational databases are hard to scale, and manage once they become too
complex. When you have one large database with tons of interdependencies, it
makes migrating data, and making schema changes much harder. This in my
opinion is the biggest issue (moreso than performance problems associated with
doing joins to the n-th degree., which is also an issue.)

It also makes separating concerns of the application more difficult when one
SQL connection can query/join all entities. In theory better application
design would have separate upstream data services fetch the resources they are
responsible for. That data can be stored in a RDBMS or NOSQL, but NOSQL forces
your hand in that direction.

As it goes for serverless, this just seems like a natural progression from
containerization, I'm interested to see where the space goes.

Personally I think it's foolish to put your head in the sand when the industry
is changing, or learning new concepts.

~~~
danharaj
> 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
write schemas. That's what it's for, for the majority of users.

If I need a key value store, I use a key value store. There's no flashy
paradigm there. If I need to put a container up on the interwebs, I do it.
What's serverless? Nosql is an "idea", "paradigm", "revolution", or at least
the branding of one. Just the same, serverless.

I will continue to ignore nosql and serverless.

The industry sure does change, but do you know how much of that is moving in a
real direction and how much is a merry-go-round? Let's brand it "Carousel" and
raise 10 million. And in 20 years we can talk about serverless being the new
hotness, again.

~~~
cphoover
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 consuming services and applications you don't even
know about are opening up all sorts of transactions. Even just splitting the
DB into schemas for each resource domain and limiting access per service can
help to avoid this.

Also performance is relative, I've worked on highly trafficked applications
that had to support high throughput. I have also worked on applications backed
by relational storage where data size and complexity has impacted performance.

~~~
the_af
> "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.

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

------
actionowl
We've been using serverless with AWS lambdas for a few months.

Testing is hard, the more AWS shit you tie yourself to the harder local
testing and development becomes. I picked up a lambda project another
developer started and asked them how they were testing and developing locally.
Answer: They deployed a new update for every change (!?)

Debugging: Look at log files...

Also, at some point serverless added some autocomplete crap to my .bashrc file
without asking which I will never forgive them for.

------
SSilver2k2
Serverless is great, but I am really loving Zappa for Python Flask and Django
development with Lambda and API Gateway.

Deployed our first production tool with it and it's been working great.

~~~
inspector14
do you have any strong opinions re: differences between chalice / zappa?

I was looking at these two recently and ended up going with chalice as the
docs seemed a bit simpler and more readily accessible.

~~~
wahnfrieden
One point: Chalice is non-portable if you outgrow Lambda and want to rehost,
whereas Zappa is just Django.

------
i386
This looks interesting and I wish them good luck. The problem with any
developer tools startup is that no matter how great the product is, the
willingness to pay is very low (developers think they can replace you with a
small script) and extremaly likely that your market gets slowly eaten from the
bottom by open source and/or MS/Google/Amazon fold in your service into their
cloud platform.

------
robertonovelo
I usually do TDD serverless apps by debugging unit tests with jest. Is it a
bad practice? Anyone can easily mock events this way, It does not matter
whether its a SNS event or an HTTP event. Overall, I have had a great
experience with serverless!

------
nunez
Super happy for them. It's clear that lots of companies and people are
interested in serverless, as the benefits are clear. this could be how the
"microservice" actually manifests itself in a few years.

------
neom
Hope DigitalOcean works to make this a first-class citizen on their cloud.

~~~
tango12
I think they are. I do see a lot of twitter posts by them talking about the
rise of serverless.

[https://twitter.com/digitalocean/status/1017529341742403586](https://twitter.com/digitalocean/status/1017529341742403586)

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

~~~
zaarn
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.

