November 7, 2018

Google Cloud AppEngine or AWS Elastic Beanstalk?

For Indiehacker projects without any clear revenue, which one would you use? So far I've used EC2 instances bascially as VPSes, but I'd like to move to a more managed solution (mostly for learning purposes).

It seems like Google Cloud AppEngine would end up being a lot cheaper for the first project than AWS Elastic Beanstalk (which would require a load balancer for 220 dollars per year).

Any experiences?

Note; I'm partially doing this for the learning experiences. I figure it's knowledge I can take with me to my future projects.


  1. 4

    App Engine is the pioneer in this space. Super easy to use and scale. I've used it for almost all of my apps (from prototype to production), including a venture-backed company that we scaled to millions of users and eventually acquired.

  2. 3

    I'm using AppEngine for my sideproject (https://devsnap.io) and I must say I love it. Currently it's not even costing me money, since I use the Standard environment.

    Try to use that environment too, since the flexible environment always needs 1 instance, which costs a lot more.

    What surprised me the most was how fast AppEngine activates 1 instance in the Standard Environment if you have currently running 0. It takes not more than 100-200 ms.

    Other than that it has already intergrated logging, load balancing, it creates your SSL certificat for your custom domain and other things...

    1. 2

      What are your Cloud SQL costs like? And what are you using for CDN, Cloudflare? Also, I need to play around with Go + GraphQL. Currently just do Node.js + GraphQL. :)

      1. 2

        I'm using the smallest possible instance of Cloud SQL (postgres) and it costs me ~9$ a month. I was honestly surprised just how much I can already do with the smallest instance. I have currently > 100k rows in that table and the cpu utilization is still only between 3-7% at all times, even with searching over several columns and all that stuff. It's crazy.

      2. 1

        As for the CDN, I also use Google Cloud. The company images are hosted in a Google Cloud Bucket and before that is the CDN. The static files for the website itself are only hosted on AppEngine, since AppEngine already is crazy fast in case of static assets (close to a CDN), so I don't really need to do anything there yet.

      3. 1

        And I'm actually using Go+GraphQL for the backend and Nodejs for the frontend as well.

        I really fucking love Go + GraphQL, it's so nice.

        1. 1

          Do you use a GraphQL framework for Go? I've been hesitating cause I rely heavily on Apollo GraphQL server and that's only for Node.js, haha. I'll get started this weekend though!

          1. 1

            I only started with GraphQL for that project as well. I knew Go already before that tho. I only use https://github.com/graphql-go/graphql and resolve everyting myself.

            In my opinion that is the way you should use GraphQL. It's just a way to speak with your API, not some framework that magically creates your entire backend. I think you lose too much flexibility if you use something like that.

            1. 2

              I'm going to slightly disagree with you here because I felt like Apollo GraphQL really helped move the space forward and I just really love the developer experience. I've been in love since day 1.

              Of course, with Go I won't even have a choice, so raw it is, and I can still use Apollo GraphQL on the client of course, which is probably where it's most useful anyway. And it's so great to hear you love the language, as I'm sure people like Ryan Dahl and TJ Holowaychuk moved from Node.js to Go for good reason. At my day job I also do a lot of work in blockchain, so it's about time I pick up Go for chaincode as well.

              Gonna be following you so we can be Go + GraphQL + Google Cloud buddies!

              1. 1

                Yeah you're right about Apollo. Actually I was using Apollo on the client side as well.

                I was talking about server side frameworks like https://github.com/graphile/postgraphile that magically create your entire backend for you.

                And yeah, let's be Go + GraphQL + Google Cloud buddies! :-)

    2. 2

      Nice, thanks for the feedback! Sounds like I should try it for my next project. Although I heard the opposite from some people, that it can take 3-4 seconds from cold to warm on App Engine.

      And cool site! Are you scraping other sites for the data, or how does that work?

      1. 1

        And thanks for the positiv feedback to my sideproject. :-)

        Yeah, I scrape the data of other sites.

      2. 1

        It seems to strongly depend on the programming language you use. I did notice that my nodejs frontend takes longer than my go backend. The go backend is like instantly there, node takes the aforementioned time.

        I don't know about Java or Python. That could take longer indeed.

  3. 2

    App Engine (and GCP in general) is quite powerful and tend to be far simpler than AWS products. I use App Engine + Firebase products for CommentBox.io and I couldn't be happier.

    1. 2

      Product is really smooth. Nice job Shaun!

      1. 1

        Agreed, good job Shaun!

      2. 1

        Thanks!

  4. 1

    I have no experience with AWS Elastic Beanstalk, but I've been using Google App Engine standard for many years with Java and Google datastore.

    My product https://documentnode.io (pre-launch phase) is running on AppEngine as well.

    But just be careful with some limitations, I saw some complaints about issues they encountered with Google App Engine, like billing jumped high suddenly.

  5. 1

    Let me share my own experience.

    I started from GAE impressed with their conditions and features. Almost everything worked well until several days ago when I updated my CLI (they required) and my deployment broke. I wasted 2 days and decided to move to AWS because of their poor support (I created a bug - they refused it saying it's "by design" and they also said I don't have a support at all because it's a free tier (what is actually not, they already charged me for a dollar :).

  6. 1

    I like them both, but considering I like Firebase too much for my mobile apps, I just stick to Google Cloud, so I have all of my costs on one dashboard. Currently using App Engine, Cloud SQL, Firebase/Cloud Storage, Cloud Vision, Firebase/Cloud Functions, Firebase Auth, Firebase Cloud Messaging, Firebase Analytics, and very happy with the experience. I'm pretty strong at devops, but managing a deployment is the last thing I want to worry about when trying to start a business, and this setup works great.

  7. 1

    Take a look at Kubernetes. Since it’s a sort of platform agnostic solution, you can find the cheaper one.

    The downside is that you’ll need to manage a lot of stuff manually 🤷‍♂️

  8. 1

    So IMHO it doesn't really matter. Unless there is some very particular feature then they will all probably do whatever you need.

    They will both advance and also leapfrog each other in particular areas. Google seems to be going the 'cheaper' route but once they make significant inroads maybe they change that

    They both have free plans, so as long as they work for you then pick one and go for it!

    Again this is predicated there is nothing special you are looking for. e.g.if you tell me you want to get certified to advance your career, then AWS looks better given their bigger footprint.

    I wouldn't spend too much time thinking this one through. take 10 hours and try one. If you don't like it, you'eve only spent 10 hours...

    Just my 2 cents

    Simon

  9. 1

    Consider Heroku as well.

    What are you trying to learn? If you're wanting to be an indie developer and make money, go with whatever simplifies server admin for you. I find Heroku really helps here.

  10. 1

    EBS

    1. 1
  11. 1

    I'd steer away from any Google cloud platform products. While they were the first with Google App Engine, there are so many corner cases and google-oddities you don't see with AWS or Azure.

    Getting to the cloud is hard enough w/o googles idiosyncrasies adding delays.

    1. 3

      Could you add some more detail/exemplify please?

      1. 1

        Not an exhaustive list, the node sdk for google cloud storage didn't work, we had to create a bug ticket for it.

        There are a lot of idiosyncrasies you don't get with aws or azure, around boot drives, renaming instances.

        One particular fun case was the gui for the GCP load balancer no longer showing a "backend service" so we have to remove the backend and recreate it for it to show again, which then removed the cloud armor rules and caused a bit of a problem.

        There are a lot of pieces that are just broken compared to AWS,Azure, and we just work around because "google".

        They have multiple versions of documentation that is factually wrong or missing large chunks of "how it really works".

        Our first time using google so it's a big learning experience but I certainly would not use again, if it was my choice.