4 ms·

What this seems to be saying is that serverless is great if you are doing javascript-heavy SPA's, otherwise not so much. Serverless is good if you don't actuall

What this seems to be saying is that serverless is great if you are doing javascript-heavy SPA's, otherwise not so much. Serverless is good if you don't actually need to talk to the server.

leesalminen 9y ago
Totally agree. I used Google Cloud Functions + Google Cloud Storage to deploy a single function “app”. We replaced a SaaS that was a UI for recurring plan signups over Stripe. It started costing us $500/Mo. I replaced it with 16 hours dev+testing. It turned out really well and am very happy with it thus far. I expect maintenance to be minimal thanks to serverless. Though I don’t think it’d work as well for an app with 100+ database tables. Definitely a middle ground in there.
- tehsauce 9y ago
  Just curious, what kinds of apps use 100+ database tables? I don't know too much about this stuff.
  - leesalminen 9y ago
    We offer a SaaS product that helps manage pet services businesses. Think CRM+POS+ERP all mashed together, targeted at a niche. Our app is highly configurable by each business. It turns out these businesses are pretty complex :). We’re at 152 production tables today.
    - dodders 9y ago
      Our core banking app has 1000+ tables.
      - evrydayhustling 9y ago
        This sub-thread is fascinating. On the pet service business, it sounds like there might be more tables due to some kind of object polymorphism on a per customer basis? Are there any other "per-whatever" expansion factors that are multiplying your table count?
        icebraining 9y ago
        A CRM+POS+ERP is pretty complex by itself, and being more configurable means more stuff is in the database vs the code. I work with a platform that also does CRM/POS/ERP (plus a bunch more), and the products alone have over 10 tables for describing them: the base products, their variants, a list of generic variant attributes, a table detailing which variants have which attributes, a table for specifying the values that those variants have of those attributes, the product categories, two tables for configuring the taxes applied to each product (on purchases and sales), the product images, the list of suppliers. We're already on 10 and we haven't even used those products for anything (stocking, selling, invoicing, purchasing, etc, etc).
cle 9y ago
I didn't get that from this article at all. It didn't really seem to say anything about backend stuff. I build huge serverless backend applications, and IMO it's been fantastic. There is a learning curve, because your application's execution environment is pretty different from traditional applications, but it's allowed us to build a remarkably complex and scalable application, very quickly. And it's been pretty maintainable too.
- wojcikstefan 9y ago
  Can you elaborate on what your application does, what’s a basic flow of a request, and finally, what are the high-level steps you take to ship a new feature or API endpoint?
  - cle 9y ago
    I can't elaborate on what the application does, but I can talk about high-level architecture and development. Basically we have an API that performs asynchronous data analysis and processing. Our fronting service receives a request, writes some metadata, and places the request in a "queue", which is picked up by a backend poller that starts a workflow execution, which orchestrates the fulfillment of the request. This is all serverless (AWS tech...API Gateway, Lambda, Step Functions, S3, DynamoDB, CloudFormation, CloudWatch, etc.). Serverless makes deployments much easier, since we can version our Lambdas and State Machines using CloudFormation, and have many different versions running at the same time (not fun if you're managing your own hardware!). We have a CD pipeline that builds code changes, deploys them to a test account, and runs integration tests. We use CloudWatch Alarms to monitor production and alert us of any issues. We have some development scripts for pushing code changes with CloudFormation for testing during development. We use that to develop, then once we check the code in, it works its way through our pipeline and into production.

What this seems to be saying is that serverless is great if you are doing javascript-heavy SPA's, otherwise not so much. Serverless is good if you don't actually need to talk to the server.

leesalminen 9y ago

Totally agree. I used Google Cloud Functions + Google Cloud Storage to deploy a single function “app”. We replaced a SaaS that was a UI for recurring plan signups over Stripe. It started costing us $500/Mo. I replaced it with 16 hours dev+testing. It turned out really well and am very happy with it thus far. I expect maintenance to be minimal thanks to serverless. Though I don’t think it’d work as well for an app with 100+ database tables. Definitely a middle ground in there.

tehsauce 9y ago
Just curious, what kinds of apps use 100+ database tables? I don't know too much about this stuff.
- leesalminen 9y ago
  We offer a SaaS product that helps manage pet services businesses. Think CRM+POS+ERP all mashed together, targeted at a niche. Our app is highly configurable by each business. It turns out these businesses are pretty complex :). We’re at 152 production tables today.
  - dodders 9y ago
    Our core banking app has 1000+ tables.
    - evrydayhustling 9y ago
      This sub-thread is fascinating. On the pet service business, it sounds like there might be more tables due to some kind of object polymorphism on a per customer basis? Are there any other "per-whatever" expansion factors that are multiplying your table count?
      - icebraining 9y ago
        A CRM+POS+ERP is pretty complex by itself, and being more configurable means more stuff is in the database vs the code. I work with a platform that also does CRM/POS/ERP (plus a bunch more), and the products alone have over 10 tables for describing them: the base products, their variants, a list of generic variant attributes, a table detailing which variants have which attributes, a table for specifying the values that those variants have of those attributes, the product categories, two tables for configuring the taxes applied to each product (on purchases and sales), the product images, the list of suppliers. We're already on 10 and we haven't even used those products for anything (stocking, selling, invoicing, purchasing, etc, etc).

cle 9y ago

I didn't get that from this article at all. It didn't really seem to say anything about backend stuff. I build huge serverless backend applications, and IMO it's been fantastic. There is a learning curve, because your application's execution environment is pretty different from traditional applications, but it's allowed us to build a remarkably complex and scalable application, very quickly. And it's been pretty maintainable too.

wojcikstefan 9y ago
Can you elaborate on what your application does, what’s a basic flow of a request, and finally, what are the high-level steps you take to ship a new feature or API endpoint?
- cle 9y ago
  I can't elaborate on what the application does, but I can talk about high-level architecture and development. Basically we have an API that performs asynchronous data analysis and processing. Our fronting service receives a request, writes some metadata, and places the request in a "queue", which is picked up by a backend poller that starts a workflow execution, which orchestrates the fulfillment of the request. This is all serverless (AWS tech...API Gateway, Lambda, Step Functions, S3, DynamoDB, CloudFormation, CloudWatch, etc.). Serverless makes deployments much easier, since we can version our Lambdas and State Machines using CloudFormation, and have many different versions running at the same time (not fun if you're managing your own hardware!). We have a CD pipeline that builds code changes, deploys them to a test account, and runs integration tests. We use CloudWatch Alarms to monitor production and alert us of any issues. We have some development scripts for pushing code changes with CloudFormation for testing during development. We use that to develop, then once we check the code in, it works its way through our pipeline and into production.