15 ms·

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

danharaj 8y ago
Here's to hoping ignoring serverless will work as well as ignoring NoSQL worked for me.
- Xorlev 8y ago
  But don't you want perfect elastic scalability for your blockchain^W distributed ledger project? /s
  - baxtr 8y ago
    You forgot the AI part...
    - atonse 8y ago
      How about visualizing the realtime graph with VR? There, I tied it all in.
- deleted 8y ago
  [deleted]
- giancarlostoro 8y ago
  Did not Google already make a cloud platform that is cloud agnostic called OpenCloud which is a better name that doesn't target just "Serverless" aka Azure Functions, Amazon Lambdas. The use of "Serverless" is not having to deal with an "IT" guy at all who complains about setting up your app cause you updated the STACK and now it collides with everything else on the same server. Also makes it so you don't necessarily have to use containers.
  - toomuchtodo 8y ago
    I think the problem is all of this tooling (Docker, Serverless, NoSQL) has been created to “support developer velocity”, which really just ends up as technical debt. You can’t magic away the need for experience and domain knowledge. Docker doesn’t replace the need to know how VMs work. Containers don’t magically allow you to scale to infinity (Although k8s shows a lot of potential). And you probably should be using PostgreSQL instead of NoSQL unless you’re absolutely sure you’re smart enough to know why PostgreSQL can’t work for your use case. Serverless is great if you want to replace a cron job, the value of the function firing is substantially higher than the cost to run it (“margins are crazy high, optimize to VMs later and ignore the AWS bill for now”), or you’re executing untrusted code in isolation for customers.
    - sbinthree 8y ago
      I am learning this lesson the hard way with dynamically typed languages on the server. If the documentation and database have to be statically typed, you should really use types in the code. So dynamically typed languages on the server is impossible (?).
      - cphoover 8y ago
        No offense but BS. What you have claimed is totally unsubstantiated, and not aligned with my experience working on highly-trafficked eCommerce applications. If you know what your doing you can write elegant, performance tuned, secure and maintainable code in a dynamic language. I've also seen poorly written code written in statically typed languages. It really comes to who is writing the code, what kind of standards they abide to, and their architectural prowess.
        eropple 8y ago
        > If you know what your doing you can write elegant, performance tuned, secure and maintainable code in a dynamic language. You can! You totally can. But, statistically speaking? You probably won't. Neither will I. And that's why the minimal level of guardrails I'll put up with in 2018 is TypeScript and I'd really rather have better.
- Bahamut 8y ago
  This comment is a little strange - NoSQL is prevalent, especially when dealing with large data sets, or certain problems such as search. That said, I’m not sold on serverless.
- y4mi 8y ago
  Serverless is at its heart - as I understand it - a dockerized microservice, abstracted away to a degree that the developer no longer has to think about anything but his application code. You'll definitely be able to ignore it and it probably won't be used in smallish companies for ages. It's just an easier way to to get your application to scale than homebuild docker images were.
  - chii 8y ago
    > no longer has to think about anything but his application code. i mean, CGI has always existed. This serverless hype is basically rebrand of CGI with some fancy orchestration around autoscaling across boxes (which, tbh, isn't really that much work, and most people don't need the scale required to make this feasible anyway).
    - mmt 8y ago
      > isn't really that much work I suspect that it's this little parenthetical tidbit, and implicit disagreement with it (or differing definitions of "much") that drives the creation of this kind of abstraction. In some situations, I consider the gap to be legitimate, where it may be easy (not that much work) for an expert but difficult for everyone else, and, more importantly, becoming expert is non-trivial, even with training/mentorship from one. In other situations, I consider the gap to be merely one of perception/misestimation, either because it would actually be relatively easy for a non-expert who had actually tried, and/or the needed expertise is shallow enough that it can be quickly taught. I believe autoscaling is (or at least originally was) of the former category and that the availability of tools and abstractions around it has allowed a broad number of non-experts to leverage the wisdom of a much narrower group of expert practitioners. OTOH, I believe running hardware in a datacenter (as opposed to outsourcing it to a VPS or even cloud) is of the latter category. I routinely read comments like "have to hire 5 sysadmins" from non-experts when we experts know that estimate is around 20x too high for a scale of hundreds of servers. Even at higher scale, if hiring is necessary, the hardware-specific skills are easily taught, so junior staff is fine.
  - xchaotic 8y ago
    "a degree that the developer no longer has to think about anything but his application code." a developer still has to understand the implications of resource consumption etc. For performance-critical pieces of code, IMO it's better to have direct access to the hardware - I had a recent first hand experience with this debugging NUMA related performance issue.
- autotune 8y ago
  Serverless has its place, that said I'm not sure how well this company is going to end up doing. Might be a bit biased but the most common serverless applications I've seen are all about integrating cloud services with each other, which is done on their own platform.
- cphoover 8y ago
  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 8y ago
    > 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.
- exabrial 8y ago
  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 point (or why would you keep the data?). Putting that decision into the future just makes it harder on everyone.
  - zaarn 8y ago
    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).
_Marak_ 8y ago
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 8y ago
  > 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.
  - drchickensalad 8y ago
    Not the OP, but they only said it wasn't strong enough, not exclusively engineers. I see plenty of grey area here.
  - spamizbad 8y ago
    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.
paulgb 8y ago
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
- skohan 8y ago
  I just hope the API has stabilized. I worked on a project a couple of years ago using serverless, and we sunk a ton of time into fixing breaking changes after updates.
- rawrmaan 8y ago
  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.
  - wahnfrieden 8y ago
    It’s still the early days so there are pain points, but Amazon already announced a solution to this: Serverless Aurora. It’ll be some time still until it’s public and Lambda-friendly though. And MySQL comes before Postgres.
  - ryanworl 8y ago
    You connect the same way as you do in a regular app. Which is to say, you open the database connection outside of the request handling method (for example, as a global) and then use it from within the request handling method. When your app wakes up again for another request, the database connection is still open and you just use it.
pmlnr 8y ago
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.
- jchw 8y ago
  I disagree. If you build a good enough abstraction, you can give developers a lot for free without needing them to understand. Current serverless platforms are wasteful, but the underlying concept is not inherently wasteful, and I think that cloud providers and serverless software platforms will improve over time.
  - marenkay 8y ago
    The need to understand is a primary skill for a decent engineer. Was in the 1960‘s and still is today. Lack of Knowledge is what makes an engineer a business risk.
    - jchw 8y ago
      I don't need to understand metallurgy thanks to processors. I don't need to understand instruction set architectures or assembly language thanks to programming languages. When abstractions truly separate concerns, they make it very much possible to not understand, much to the benefit of the programmer, who now needs to keep significantly less in their head. Aren't you glad you don't have to be concerned with making sure your stack stays balanced thanks to scoping in C? Well, I'd like to write an API without having to be concerned about job scheduling, dispatching, logging, monitoring, etc. Understanding these things may make you a better programmer (or they may not,) but not having to understand let's you let go of things you don't need to care about and focus on what you're trying to accomplish instead. We as programmers love writing solutions to problems that have been solved hundreds of times. How many node.js http frameworks exist? Or JS frameworks for that matter? But the thing is, for the most part, when it comes to API servers, there's a crazy amount of overlap between what they need to do. They handle HTTP requests and spit out a response. Someone has written this better than you can, so you use an HTTP library. You probably want to serve multiple endpoints on one port, so you route with the URL. What do you do, implement a radix tree, or use a mature, well-tested, high performance library? If you are sane, probably the latter. All serverless is is a realization that most HTTP servers don't need anything special in terms of routing, scheduling, monitoring, etc. By turning an HTTP server inside out, you can allow the developer to focus on exactly one thing and give them a platform that is stable and inherently scalable by virtue of being stateless and making scheduling an implementation detail. If you have a very efficient engine to execute functions, and a very robust and scalable HTTP server, and you can write your app logic to be stateless (locally, anyway,) there's no reason to believe that the serverless approach would be any technically worse than the old school approach. I feel likewise similar about static files. I don't need to write and operate yet another static file server. I can use Amazon S3 + Cloudfront, or Firebase, or GCS, or any other solution. It doesn't mean I don't know how. It's an admission that I have no special requirements, and would like to focus on the things I'm writing that are particular to my app. What's dangerous? Not serverless, for sure. What's dangerous, is programmers implementing everything from scratch because they can, doing their own operations when they don't have the resources to.
neom 8y ago
Hope DigitalOcean works to make this a first-class citizen on their cloud.
- tango12 8y ago
  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
sebringj 8y ago
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.
SSilver2k2 8y ago
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 8y ago
  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 8y ago
    One point: Chalice is non-portable if you outgrow Lambda and want to rehost, whereas Zappa is just Django.
- gsibble 8y ago
  Love Zappa.
jaequery 8y ago
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 8y ago
  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.
i386 8y ago
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.
jaflo 8y ago
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 8y ago
  Wow, this is a really cool application. I needed to cut down a song this week and this is a very cool approach.
  - jaflo 8y ago
    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 8y ago
      Wedding first dance song. Original was 5+ minutes long, we need 2-3.
robertonovelo 8y ago
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!
actionowl 8y ago
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.
nunez 8y ago
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.

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

Xorlev 8y ago
But don't you want perfect elastic scalability for your blockchain^W distributed ledger project? /s
- baxtr 8y ago
  You forgot the AI part...
  - atonse 8y ago
    How about visualizing the realtime graph with VR? There, I tied it all in.
deleted 8y ago
[deleted]
giancarlostoro 8y ago
Did not Google already make a cloud platform that is cloud agnostic called OpenCloud which is a better name that doesn't target just "Serverless" aka Azure Functions, Amazon Lambdas. The use of "Serverless" is not having to deal with an "IT" guy at all who complains about setting up your app cause you updated the STACK and now it collides with everything else on the same server. Also makes it so you don't necessarily have to use containers.
- toomuchtodo 8y ago
  I think the problem is all of this tooling (Docker, Serverless, NoSQL) has been created to “support developer velocity”, which really just ends up as technical debt. You can’t magic away the need for experience and domain knowledge. Docker doesn’t replace the need to know how VMs work. Containers don’t magically allow you to scale to infinity (Although k8s shows a lot of potential). And you probably should be using PostgreSQL instead of NoSQL unless you’re absolutely sure you’re smart enough to know why PostgreSQL can’t work for your use case. Serverless is great if you want to replace a cron job, the value of the function firing is substantially higher than the cost to run it (“margins are crazy high, optimize to VMs later and ignore the AWS bill for now”), or you’re executing untrusted code in isolation for customers.
  - sbinthree 8y ago
    I am learning this lesson the hard way with dynamically typed languages on the server. If the documentation and database have to be statically typed, you should really use types in the code. So dynamically typed languages on the server is impossible (?).
    - cphoover 8y ago
      No offense but BS. What you have claimed is totally unsubstantiated, and not aligned with my experience working on highly-trafficked eCommerce applications. If you know what your doing you can write elegant, performance tuned, secure and maintainable code in a dynamic language. I've also seen poorly written code written in statically typed languages. It really comes to who is writing the code, what kind of standards they abide to, and their architectural prowess.
      - eropple 8y ago
        > If you know what your doing you can write elegant, performance tuned, secure and maintainable code in a dynamic language. You can! You totally can. But, statistically speaking? You probably won't. Neither will I. And that's why the minimal level of guardrails I'll put up with in 2018 is TypeScript and I'd really rather have better.
Bahamut 8y ago
This comment is a little strange - NoSQL is prevalent, especially when dealing with large data sets, or certain problems such as search. That said, I’m not sold on serverless.
y4mi 8y ago
Serverless is at its heart - as I understand it - a dockerized microservice, abstracted away to a degree that the developer no longer has to think about anything but his application code. You'll definitely be able to ignore it and it probably won't be used in smallish companies for ages. It's just an easier way to to get your application to scale than homebuild docker images were.
- chii 8y ago
  > no longer has to think about anything but his application code. i mean, CGI has always existed. This serverless hype is basically rebrand of CGI with some fancy orchestration around autoscaling across boxes (which, tbh, isn't really that much work, and most people don't need the scale required to make this feasible anyway).
  - mmt 8y ago
    > isn't really that much work I suspect that it's this little parenthetical tidbit, and implicit disagreement with it (or differing definitions of "much") that drives the creation of this kind of abstraction. In some situations, I consider the gap to be legitimate, where it may be easy (not that much work) for an expert but difficult for everyone else, and, more importantly, becoming expert is non-trivial, even with training/mentorship from one. In other situations, I consider the gap to be merely one of perception/misestimation, either because it would actually be relatively easy for a non-expert who had actually tried, and/or the needed expertise is shallow enough that it can be quickly taught. I believe autoscaling is (or at least originally was) of the former category and that the availability of tools and abstractions around it has allowed a broad number of non-experts to leverage the wisdom of a much narrower group of expert practitioners. OTOH, I believe running hardware in a datacenter (as opposed to outsourcing it to a VPS or even cloud) is of the latter category. I routinely read comments like "have to hire 5 sysadmins" from non-experts when we experts know that estimate is around 20x too high for a scale of hundreds of servers. Even at higher scale, if hiring is necessary, the hardware-specific skills are easily taught, so junior staff is fine.
- xchaotic 8y ago
  "a degree that the developer no longer has to think about anything but his application code." a developer still has to understand the implications of resource consumption etc. For performance-critical pieces of code, IMO it's better to have direct access to the hardware - I had a recent first hand experience with this debugging NUMA related performance issue.
autotune 8y ago
Serverless has its place, that said I'm not sure how well this company is going to end up doing. Might be a bit biased but the most common serverless applications I've seen are all about integrating cloud services with each other, which is done on their own platform.
cphoover 8y ago
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 8y ago
  > 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.
exabrial 8y ago
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 point (or why would you keep the data?). Putting that decision into the future just makes it harder on everyone.
- zaarn 8y ago
  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).

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 8y ago
> 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.
- drchickensalad 8y ago
  Not the OP, but they only said it wasn't strong enough, not exclusively engineers. I see plenty of grey area here.
- spamizbad 8y ago
  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.

paulgb 8y ago

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

skohan 8y ago
I just hope the API has stabilized. I worked on a project a couple of years ago using serverless, and we sunk a ton of time into fixing breaking changes after updates.
rawrmaan 8y ago
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.
- wahnfrieden 8y ago
  It’s still the early days so there are pain points, but Amazon already announced a solution to this: Serverless Aurora. It’ll be some time still until it’s public and Lambda-friendly though. And MySQL comes before Postgres.
- ryanworl 8y ago
  You connect the same way as you do in a regular app. Which is to say, you open the database connection outside of the request handling method (for example, as a global) and then use it from within the request handling method. When your app wakes up again for another request, the database connection is still open and you just use it.

pmlnr 8y ago

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.

jchw 8y ago
I disagree. If you build a good enough abstraction, you can give developers a lot for free without needing them to understand. Current serverless platforms are wasteful, but the underlying concept is not inherently wasteful, and I think that cloud providers and serverless software platforms will improve over time.
- marenkay 8y ago
  The need to understand is a primary skill for a decent engineer. Was in the 1960‘s and still is today. Lack of Knowledge is what makes an engineer a business risk.
  - jchw 8y ago
    I don't need to understand metallurgy thanks to processors. I don't need to understand instruction set architectures or assembly language thanks to programming languages. When abstractions truly separate concerns, they make it very much possible to not understand, much to the benefit of the programmer, who now needs to keep significantly less in their head. Aren't you glad you don't have to be concerned with making sure your stack stays balanced thanks to scoping in C? Well, I'd like to write an API without having to be concerned about job scheduling, dispatching, logging, monitoring, etc. Understanding these things may make you a better programmer (or they may not,) but not having to understand let's you let go of things you don't need to care about and focus on what you're trying to accomplish instead. We as programmers love writing solutions to problems that have been solved hundreds of times. How many node.js http frameworks exist? Or JS frameworks for that matter? But the thing is, for the most part, when it comes to API servers, there's a crazy amount of overlap between what they need to do. They handle HTTP requests and spit out a response. Someone has written this better than you can, so you use an HTTP library. You probably want to serve multiple endpoints on one port, so you route with the URL. What do you do, implement a radix tree, or use a mature, well-tested, high performance library? If you are sane, probably the latter. All serverless is is a realization that most HTTP servers don't need anything special in terms of routing, scheduling, monitoring, etc. By turning an HTTP server inside out, you can allow the developer to focus on exactly one thing and give them a platform that is stable and inherently scalable by virtue of being stateless and making scheduling an implementation detail. If you have a very efficient engine to execute functions, and a very robust and scalable HTTP server, and you can write your app logic to be stateless (locally, anyway,) there's no reason to believe that the serverless approach would be any technically worse than the old school approach. I feel likewise similar about static files. I don't need to write and operate yet another static file server. I can use Amazon S3 + Cloudfront, or Firebase, or GCS, or any other solution. It doesn't mean I don't know how. It's an admission that I have no special requirements, and would like to focus on the things I'm writing that are particular to my app. What's dangerous? Not serverless, for sure. What's dangerous, is programmers implementing everything from scratch because they can, doing their own operations when they don't have the resources to.

neom 8y ago

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

tango12 8y ago
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

sebringj 8y ago

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.

SSilver2k2 8y ago

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 8y ago
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 8y ago
  One point: Chalice is non-portable if you outgrow Lambda and want to rehost, whereas Zappa is just Django.
gsibble 8y ago
Love Zappa.

jaequery 8y ago

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 8y ago
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.

i386 8y ago

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.

jaflo 8y ago

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 8y ago
Wow, this is a really cool application. I needed to cut down a song this week and this is a very cool approach.
- jaflo 8y ago
  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 8y ago
    Wedding first dance song. Original was 5+ minutes long, we need 2-3.

robertonovelo 8y ago

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!

actionowl 8y ago

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.

nunez 8y ago

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.