10 ms·

My one-man-SaaS setup: - Static frontend hosted on Netlify (free unlimited scale) - Backend server on Google App Engine (connecting to Gcloud storage and mana

• mark_l_watson 6y ago
  Interesting, thanks. I used to use Google AppEngine a lot and very much liked it, but haven’t touched it for years. Now, I like the idea of using Heroku better, and just pay a little more.
  • devoutsalsa 6y ago
    Heroku my feels cheaper when you think about how long you can punt on having ops proper person(s) & how much time you save rolling your own everything.
  • nocommandline 6y ago
    If you don't mind my asking, can you say why you moved from GAE to Heroku and/or why you prefer Heroku over GAE?
    • mark_l_watson 6y ago
      I used them both in the same time period. I liked GAE because it was basically free to use for low use web apps, but has scalability built in. I liked Heroku because it was just so easy to develop and deploy with.
  • toomanybeersies 6y ago
    My experience of Heroku has mostly been the pain of migrating to a different platform once you grow to the point that their pricing (and abstraction) starts to act against your growth. Heroku is great for general applications, but if you're trying to do something that isn't a standard CRUD app, it can really start to bite you in the arse. Their DB pricing in particular is incredibly inflexible compared to AWS RDS. Among other issues we had with Heroku at my old job, was having a DB that was hitting its storage limits, but was miles away from hitting its memory or connection limits. There was no option but to upgrade to the next tier, with additional memory etc., even though all we needed was additional disk. That's not to say that Heroku is bad, but like any tool, you need to be aware of the long term costs that are often associated with term convenience.
• I_am_tiberius 6y ago
  I wouldn't say Netlify has free unlimited scale. There are some limitations, especially the data transfer limit of 100GB.
  • rory 6y ago
    That's right, I'm exaggerating. At current rates I'll hit that limit at 7.5MM pageviews/month. I've also paid for extra builds once or twice in the past (automatically charges a few dollars when you cross the build time limit), and I pay them $9/mo for analytics.
    • modeless 6y ago
      Free unlimited scale does exist though. Cloudflare has no bandwidth limit for free plans, and it pairs well with App Engine.
    • remram 6y ago
      How much is 1MM? I'm unfamiliar with that suffix.
      • jeffreyrogers 6y ago
        1 million
      • zests 6y ago
        M == thousand
        • lupire 6y ago
          This is a false-cognate in MM. MM means millions, plural of M which means million.
          • antonvs 6y ago
            Source? Every source I've seen says that MM is derived from the Roman numeral M, meaning thousand.
• amzans 6y ago
  I agree with you in terms of using what you already know best. > If you're not already familiar with these tools consider using a managed platform first, for example Render or DigitalOcean's App Platform (not affiliated, just heard great things about both). They will help you focus on your product, and still gain many of the benefits I talk about here. And: > I use Kubernetes on AWS, but don’t fall into the trap of thinking you need this. I learned these tools over several years mentored by a very patient team. I'm productive because this is what I know best, and I can focus on shipping stuff instead. Your mileage may vary. I actually spend very little time on infrastructure after the initial setup (a week of part time work, since then a couple of hours per month tops). For comparison, this post describing what I did took nearly a month of on-and-off work. But I might just be slow at writing :)
  • rory 6y ago
    Makes sense, didn't mean my comment as a criticism of your setup Anthony. The product and infra look very cool! Just highlighting that things can be a lot simpler for those of us with more mundane requirements.
    • amzans 6y ago
      Hey no worries :) I think my reply came off differently than I meant it. I just wanted to complement your sentiment.
• fnord77 6y ago
  cloud vendor lock-in fears are overblown. pricing and features will always be competitive between the big vendors. I suspect people waste a lot of time/money trying to be cloud agnostic. Real vendor lock-in is when you have decades of code written against an Oracle DB and you're getting charged outrageous Oracle rates and it would also cost a fortune migrate.
  • skynet-9000 6y ago
    ... a decade later: Real cloud vendor lock-in is when you have decades of code written against a [cloud vendor] and you're getting charged outrageous [cloud] rates and it would also cost a fortune migrate.[sic]
    • undreren 6y ago
      If anything, vendor lock-in is consistently underblown.
      • arminiusreturns 6y ago
        The thing Ive learned is that a lot of people have both a vested interest and a sort of stockholm syndrome with vendors (cloud or otherwise). If you spent tons of time learning AWSs special tooling, you are going to see everything as a nail if you catch my drift. Ive seen a few particular users here spend many threads defending their choices despite the often very logical criticisms levied against the "cloud everything" approach. One thing I like to talk about to Cs is their strategy on capex vs opex, because honestly that determines quite a lot, but is often something engineers dont think about.
        • undreren 6y ago
          > The thing Ive learned is that a lot of people have both a vested interest and a sort of stockholm syndrome with vendors. Not to mention “resume driven development”. Recruiters love cloud experience.
        • 6y ago
• 8458e112e7b2 6y ago
  Another way to do something similar would be to use Cloud Run https://cloud.google.com/run https://cloud.google.com/run and that way you can avoid vendor lockin since you can move your manifests to another knative hosting provider or spin up your own K8s cluster and deploy knative
• iamgopal 6y ago
  People here underestimate google app engine a lot. But I doubt if there is better one person Saas service out there.
  • stanmancan 6y ago
    Digital Ocean is fantastic.
    • crazy1van 6y ago
      Would you mind being more specific? Is it the price / functionality balance that makes DO fantastic?
      • stanmancan 6y ago
        Price and functionality. It’s incredibly easy to use, unlike AWS and Google Cloud. The downfall is that you have a bit less control, but that’s never been an issue for me. Their servers have been incredibly reliable, they offer managed databases now, load balancer, S3 compatible Spaces. Everything I’ve needed so far, predictable and affordable pricing, and none of the complexity.
    • rory 6y ago
      Agreed, would have gone with their managed app platform if I was using one of the supported techs. For search I use a $5/mo meilisearch DO droplet that took almost no time to set up and I never have to pay attention to.
      • WrtCdEvrydy 6y ago
        I'd actually use Caprover then manage my services using that... it's as close to a self-managed platform as you can get for one-click deploys.
    • devops000 6y ago
      Digital Ocean + Cloud66
• waylandsmithers 6y ago
  I'm curious, as someone knows probably only enough about this stuff to get myself into trouble, what am I missing out on by just pushing to heroku?
  • sammorrowdrums 6y ago
    Netlify free tier is pretty great, giving custom DNS and support for NextJS build was so simple. Heroku is similar, but Netlify is at least equally simple I found. Maybe someone else can shed more light on differences.
    • selcuka 6y ago
      Aren't they different products though? Netlify is front end only while Heroku is full stack.
      • sammorrowdrums 6y ago
        Well if you're deploying a static site they are the same, but that's still not the whole picture. They have support for lambda style "serverless" functions and Fauna DB[1], and can bundle functions with apps automatically for some tools like Next.js to do server side rendering for dynamic routes[2]. So while they don't support quite the same level of custom stacks, backends and DBs, they do provide tools that enable full stack applications. [1] https://www.netlify.com/tags/database/ https://www.netlify.com/tags/database/ [2] https://www.npmjs.com/package/@netlify/plugin-nextjs https://www.npmjs.com/package/@netlify/plugin-nextjs
  • rory 6y ago
    First of all nothing important, mostly stuff that's a distraction unless it becomes a need. That said, using a static frontend cached on a CDN in general improves initial pageload and cuts down on traffic to your server by a lot. Netlify makes this easy if you want to use React on the client (with NextJS). With AppEngine you get direct access in one console to all the bells and whistles of Google Cloud, basically the same as the other infra giants. AWS has even more bells and whistles but I find its console more annoying.
• mtlynch 6y ago
  In my experience, the issue isn't that Google will jack up the costs but that they'll deprecate their infrastructure and push the migration work onto you, often forcing you to reimplement major features.[0] One notable example is how their NDB client library used to automatically handle memcache for you, but they got rid of that with Cloud NDB Library and forced clients to implement their own caching. The sequence of datastore APIs I've seen during my experience with AppEngine is: * Python DB Client Library for Datastore[1], deprecated in favor of... * Python NDB Client Library[2], deprecated in favor of... * Cloud NDB Library[3], still supported, but they ominously warn new apps to use... * Datastore mode client library[4] [0] https://steve-yegge.medium.com/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc https://steve-yegge.medium.com/dear-google-cloud-your-deprec... [1] https://cloud.google.com/appengine/docs/standard/python/datastore/api-overview https://cloud.google.com/appengine/docs/standard/python/data... [2] https://cloud.google.com/appengine/docs/standard/python/ndb https://cloud.google.com/appengine/docs/standard/python/ndb [3] https://cloud.google.com/appengine/docs/standard/python/migrate-to-python3/migrate-to-cloud-ndb https://cloud.google.com/appengine/docs/standard/python/migr... [4] https://cloud.google.com/datastore/docs/reference/libraries https://cloud.google.com/datastore/docs/reference/libraries
  • ijamj 6y ago
    Are you still with them? If yes, would love to hear why. Otherwise, what made you jump?
    • mtlynch 6y ago
      I still use GCP, but I avoid locking myself into their proprietary infrastructure when I'm writing new stuff. I feel like Google is far too cavalier about deprecating services and forcing their customers to do migration work. It is hard to replace GCP's managed datastores because I really don't want to maintain my own database server (even if it's a managed service that someone else upgrades for me). So I've stuck to Google Cloud Datastore / Firestore, but I've been experimenting a lot with Litestream[0], and I think that might be my go-to choice in the future instead of proprietary managed datastores. Litestream continuously streams data from a SQLite database to an S3 backend. It means that you can design your app to use SQLite and then sync the database to any S3 provider. I designed a simple pastebin clone on top of Litestream, and I use it in production for my open source KVM over IP. It's worked great so far, though I'm admittedly putting a pretty gentle workload on it (a handful of requests per day). [0] https://litestream.io/ https://litestream.io/ [1] https://github.com/mtlynch/logpaste https://github.com/mtlynch/logpaste
• uh_uh 6y ago
  If your frontend is on CDN, how are you handling auth? Do you use Firebase for that?
  • rory 6y ago
    I oversimplified a bit. I have a low-traffic "admin" interface that's rendered server-side. The people using that are my direct customers and are the only authenticated users (they auth in a traditional in-app way). I also have a high(er)-traffic frontend on a CDN which is used by their customers. User writes there are purchases/payments handled by third(fourth?)-party SaaS.
    • hinkley 6y ago
      Many sites have low write:read ratios and don’t leverage that fact in their architectural choices. Availability for maintainers is often less critical than for consumers, and your life is better if you build that in. My current employers still haven’t learned this lesson and think caching fixes everything.
      • pdimitar 6y ago
        Not sure I am following you: why shouldn't we use cache?
        • hinkley 6y ago
          Tons of reasons, but the main one is that cache is shared mutable state, pretending not to be. It has all of the ugly attributes of global variables, especially where knowledge transfer and reliability are concerned. In a read-mostly environment you can often more easily afford to update the state all at once. It’s clear what the effects are because they happen sequentially. The cost of an update isn’t fanned out and obscured across the codebase, where or your team can delude yourself of the true system cost of a suspect feature.
          • pdimitar 6y ago
• ashconnor 6y ago
  >managed DB via magic What product is this?
  • rory 6y ago
    Google Cloud SQL. I say magic because locally I need a service key to connect to the proxy, but the production app doesn't seem to need anything but the internal google address.
    • ZeroCool2u 6y ago
      The service credentials are supplied via an env variable that points to their location. Locally, you can provide the location directly or set the env variable yourself. When deployed, most GCP service environments just have that variable setup already and you don't have to think about it, so it feels a bit like magic. Same thing underneath the good though.
      • rory 6y ago
        Oh cool, that makes perfect sense, thanks for the explanation!
  • mmerlin 6y ago
    Sufficiently Advanced Technology https://lab.cccb.org/en/arthur-c-clarke-any-sufficiently-advanced-technology-is-indistinguishable-from-magic/ https://lab.cccb.org/en/arthur-c-clarke-any-sufficiently-adv...
• gsvclass 6y ago
  I love this post. I'm a big believer that one and two man startups will continue to build more and more impressive products. My one man startup 42papers.com (A community for top trending papers in CS/DL/ML) has the following stack. 1. Firebase Hosting for the React frontend 2. GraphJin (Automatic GraphQL to SQL Engine) on App Engine for the backend 3. Cloud SQL Postgres for DB https://github.com/dosco/graphjin https://github.com/dosco/graphjin
• spondyl 6y ago
  Some would argue that identity management is the real lock in anyway and while a business may mostly be abstracted from their cloud via Kubes, any Internal IT systems may be such a kludge that moving away is a nightmare hell
• kaydub 6y ago
  I work at a unicorn. We're all in on AWS and don't care about lock-in. The vendor lock-in argument isn't worth considering for most businesses.
  • toomanybeersies 6y ago
    I'm almost inclined to believe that the relationship is inverted from what many assume. Amazon will bend over backwards to accomodate a company spending $500 mil a year on hosting (apparently what Snap spends). Sure it's only a fraction of its revenue ($386 bill for AWS), but half a billion is half a billion.