Understanding Cost Estimate for Google Cloud Platform MicroServices Architecture Design

4
votes

I'm redesigning a monolith application into a MicroServices architecture and am hoping to use Google Cloud Platform (GCP) to host the entire solution. I'm having a very hard time understanding their costing breakdown, and am concerned that my costs will be uncontrollable after I build it. This is for a personal project but I'm hoping will have many users after I launch so I want to get the underlying architecture right and at the same time have reasonable costs initially when I launch.

Here is my architecture:

MicroServices 1 - 4 (Total 4 API Services):

  • Runs on App Engine
  • Exposes a REST API and saves data to DataStore
  • Initially each API should get hit around 200 times a day

MicroService 5 (Events triggered API Service):

  • Runs on App Engine
  • Listens for PubSub events and saves to DataStore (basically I have a sensor that pushes data to this Service for storage)
  • Initially the PubSub should receive events around 200 times a day

MicroService 6-7 (Total 2 UI Services):

  • Runs on App Engine
  • These are UIs so people can login and use the systems. The UIs are lightweight frond end apps that use the REST Services above to populate user data in a nice way.
  • Each UI Service should be used around 3 hours a day

So in Total I have 7 MicroServices with each running as AppEngine "Services" in a single GCP "Project". A DataStore is shared between these APIs within this Project.

As I have 7 App Engine instances running, and they only need to be operational for a short period of time per day, how does the pricing work?

I want to use App Engine because it's completely Managed, which is one of my design requirements. But I'm hoping AppEngine has some kind of Sleep Mode, so that when there is no usage it does not bill?

Any help in understanding what my monthly costs would be would be appreciated.

Thanks very much.

Update 8/2/2017

I've decided to stay out of GCP for now. As I hope to have 7 App Engines Services running in Flex (as they are node.js) I don't seem to get access to a free tier or the ability to scale idle services to 0 instances.

This means I'll be paying full price for these services. (i.e. 7 X Full App Engine VM Cost per Monthly :O )

This is an expense I cant have just for a POC of a proper MicroService design. Instead I'm going to continue with my MicroService design but use a 10$ DigitalOcean box and Dokku to containerise my Services. If this works well and I have a need I will migrate this design to GCP (or AWS)

2
google-app-enginegoogle-cloud-platformgoogle-cloud-datastore
see the appengine docs about this. appengine instances do sleep by default. - Zig Mandel

2 Answers

3
votes

The full outline of App Engine instance handling is available at https://cloud.google.com/appengine/docs/python/how-instances-are-managed . In short, your best bet is to enable automatic scaling and set

max_idle_instances = 0

in your app.yaml.

That means that your app will autoscale to handle traffic as needed and shut down the instances afterwards. Also

When settling back to normal levels after a load spike, the number of idle instances can temporarily exceed your specified maximum. However, you will not be charged for more instances than the maximum number you've specified.

Later - when load time becomes more important you can set min_idle_instances to a more suitable number - this allows for responsive apps.

3
votes

am concerned that my costs will be uncontrollable after I build it

You should be aware that automatically scalable GAE apps always have cost components dependent on the external user request patterns which are not controllable.

For example, in the standard GAE env, the way those 200 requests/day are distributed matters significantly:

  • if they are evenly distributed they will come in less than 15 min apart - the minimum billed time per instance lifetime, so the respective service will be billed for minimum 24 instance hours per day (very close to the daily 28 free instance-hours/day for billed apps, only a single-service app using the smallest instance class can fit in it).
  • if they are all received within a 15 minutes interval the service will be billed for 0.5 instance hours daily (which can easily fit in the free daily quota even with multiple services and/or with more powerfull instance classes).

The actual scalability configuration of each service can matter as well. See, for example,

The only way to keep costs under strict control is via the daily budget configuration (but hitting that limit means your app's functionality will be temporarily crippled).

All other usage-based costs being equal due to the functionality being performed you have some (potentially significant) control over costs via:

  • the GAE environment type selected for each service:

  • the number of services: you could start with fewer services by combining their functionalities (you can still keep them modularized for later split). The expected initial load you describe can easily fit within the free daily budget with just a single standard env service.

Once the app usage picks up and the free daily quotas percentage in the total costs become neglijible you can gradually split the app into multiple services as needed. In general this can be a relatively simple task if the app is properly modularized.