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 :)
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[2].
Don't get me wrong; from a resources management and scaling perspective it's great. But that doesn't outweigh the massive pain during development that it creates.
We're in the process of rebuilding a project to move everything out of a Serverless Architecture. After six months of building it on serverless we finally all agreed it was a big mistake.
[1] That's our experience with AWS. May be different with other providers.
[2] I recognize that Serverless Framework helps mitigate this but that's just yet another abstraction on top of abstractions in my opinion.
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.
Because it should really just be called Functions-as-a-service, and they are great for single-focus reactive/connective processing and 1-off tasks but are not a replacement for everything as people try to use it for.
I can't say much about its technical merits but I find it misleading that an application be described as "serverless" when in actuality it very much uses servers. The "serverless" moniker comes from the Serverless Framework, produced by Serverless, Inc. "Serverless" is the name of a product and should be capitalized accordingly.
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.
I help run a Node server, and we have some jobs that aren't run through CRON, but instead are set up using in-memory intervals. So I'm considering using a serverless setup to offload the work.
In your opinion, it easy to differentiate between dev/prod environments for development? How about logging?
> I don't understand the knee-jerk opposition people have to serverless architectures
because it's purely a marketing concern, it means nothing from an architectural standpoint, it"s a buzzword, like 'cloud', 'nosql', 'web 2.0' or 'the blockchain'.
I don't think it compares to the move to the cloud. The cloud was a lot easier to setup than dedicated and the end result was basically the same...you got a server. Serverless is quite a different paradigm and the benefits are less obvious.
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.
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.
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.
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.
> 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.
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.
> 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.
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.
The people programming in the 1970s feel the same way about today, when you use such high level abstractions like C. That's why programs today require so much RAM and CPU.
But that is the price of agility. Serverless is just another abstraction on top that increases agility at the price of increased compute.
The coming age? I do software development coaching and most every developer I'm contracted to teach doesn't understand what running code actually means (to use your phrase).
To take it another step, pretty much none of them understand how the JVM or V8 run their code.
I think this has been the case for the case for the past 20 years, probably longer, though I'm optimistic that improvement is possible. E.g., perhaps serverless computing is inefficient today but it could help improve hardware utilization.
Wooo! I'm happy for them! I am using their stuff right now for a project I'm working on (plug: 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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
[+] [-] paulgb|7 years ago|reply
So congrats on the funding, I hope you can convert some haters :)
[1] obligatory plug: https://notify.run
[+] [-] Zelphyr|7 years ago|reply
Don't get me wrong; from a resources management and scaling perspective it's great. But that doesn't outweigh the massive pain during development that it creates.
We're in the process of rebuilding a project to move everything out of a Serverless Architecture. After six months of building it on serverless we finally all agreed it was a big mistake.
[1] That's our experience with AWS. May be different with other providers.
[2] I recognize that Serverless Framework helps mitigate this but that's just yet another abstraction on top of abstractions in my opinion.
[+] [-] rawrmaan|7 years ago|reply
No-worries devops experiences are nothing new. See Heroku.
[+] [-] chx|7 years ago|reply
[+] [-] manigandham|7 years ago|reply
[+] [-] Yver|7 years ago|reply
[+] [-] everdev|7 years ago|reply
[+] [-] skohan|7 years ago|reply
[+] [-] tenaciousDaniel|7 years ago|reply
In your opinion, it easy to differentiate between dev/prod environments for development? How about logging?
[+] [-] nostalgeek|7 years ago|reply
because it's purely a marketing concern, it means nothing from an architectural standpoint, it"s a buzzword, like 'cloud', 'nosql', 'web 2.0' or 'the blockchain'.
[+] [-] na85|7 years ago|reply
Every technical person understands there's still a server there. So it seems like a marketing tactic intent on misleading clueless CEOs.
[+] [-] pbreit|7 years ago|reply
[+] [-] matte_black|7 years ago|reply
[+] [-] rightbyte|7 years ago|reply
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.
[+] [-] gaius|7 years ago|reply
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.
[+] [-] sebringj|7 years ago|reply
[+] [-] _Marak_|7 years ago|reply
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|7 years ago|reply
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.
[+] [-] pmlnr|7 years ago|reply
[+] [-] dragonwriter|7 years ago|reply
Just like now is to people who were programming in the 1990s, or the 1990s to people who were programming in the 1970s.
[+] [-] jchw|7 years ago|reply
[+] [-] jedberg|7 years ago|reply
But that is the price of agility. Serverless is just another abstraction on top that increases agility at the price of increased compute.
[+] [-] ryanmarsh|7 years ago|reply
To take it another step, pretty much none of them understand how the JVM or V8 run their code.
[+] [-] jssmith|7 years ago|reply
[+] [-] neom|7 years ago|reply
[+] [-] bradhe|7 years ago|reply
The amount of waste already present would boggle your damn mind.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] mrlala|7 years ago|reply
[deleted]
[+] [-] jaflo|7 years ago|reply
[+] [-] brettlangdon|7 years ago|reply
[+] [-] danharaj|7 years ago|reply
[+] [-] cphoover|7 years ago|reply
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.
[+] [-] exabrial|7 years ago|reply
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.
[+] [-] y4mi|7 years ago|reply
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.
[+] [-] autotune|7 years ago|reply
[+] [-] giancarlostoro|7 years ago|reply
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.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] Xorlev|7 years ago|reply
[+] [-] Bahamut|7 years ago|reply
That said, I’m not sold on serverless.
[+] [-] actionowl|7 years ago|reply
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|7 years ago|reply
Deployed our first production tool with it and it's been working great.
[+] [-] inspector14|7 years ago|reply
I was looking at these two recently and ended up going with chalice as the docs seemed a bit simpler and more readily accessible.
[+] [-] gsibble|7 years ago|reply
[+] [-] i386|7 years ago|reply
[+] [-] robertonovelo|7 years ago|reply
[+] [-] nunez|7 years ago|reply
[+] [-] neom|7 years ago|reply
[+] [-] tango12|7 years ago|reply
https://twitter.com/digitalocean/status/1017529341742403586
[+] [-] jaequery|7 years ago|reply
[+] [-] zaarn|7 years ago|reply