1

I'm looking at moving my application to google cloud and I'm having a hard time understanding how best to organize my project. It seems like you can only have one App Engine application per project with services available to support a microservices architecture and instances representing the App Engine instances created via auto scaling.

What is the correct way to build an App Engine for my API server and an App Engine for my Web Server? Do I need to have a project for each? I'm essentially trying to accomplish the following:

enter image description here

Runicode
  • 291
  • 2
  • 3
  • 19

2 Answers2

0

Best Practices:

Your Dev and Prod should be in separate projects for both security and billing purposes.

App Engine:

You can only have one App Engine per project. This will create a problem for you to use App Engine for both API Server and Web Server. In this case, I would not use App Engine at all and instead look at Containers on Compute Engine or go for Kubernetes.

Even a single node Kubernetes Cluster will shock you with its flexibility and power. Containers on Compute Engine still have a lot flexibility and power too. If you like the concepts of App Engine Flexible, then you might really like containers. The exception here is that App Engine makes some concepts brain dead simple where you have more work in configuration for Containers or Kubernetes.

John Hanley
  • 74,467
  • 6
  • 95
  • 159
0

It is straightforward to have a single GAE project implement both your website and an API. You can even do this within a single service. You could put each in a separate service, and the advantage of that is that you can update one without updating the other. For small projects, a disadvantage is that two services are more expensive than one (though GAE is quite inexpensive overall).

For prod vs dev, you'll need to explain your requirements a little more, but here are some thoughts.

Each GAE service has multiple versions. You can deploy your production version to www.mycompany.com and deploy a dev version to dev-dot-myapp.appspot.com (that's the way GAE does URLs for versions of your app). Both of these versions will access the same datastore so you need to be careful with the dev version so that it doesn't mess up your prod implementation.

If you have a dev situation that is bleeding edge and shouldn't be able to access the datastore of your production app, then you would create a different GAE project for that.

Here is a way to visualize it:

  • Google Cloud Project A
    • GAE Project A
      • production www service
      • production API service (this could be combined with production www service)
      • dev www service
      • dev API service
  • Google Cloud Project B
    • GAE Project B
      • bleeding edge www service
      • bleeding edge API service
new name
  • 15,861
  • 19
  • 68
  • 114
  • I'm going to try your suggestion on having a www service and an api service and see how it feels. I think the terminology just feels weird to me knowing that it's geared toward micro services. But I can see how this approach is manageable. In the future the api will be broken into microservices so app engine seems to be a fit at least for the api. For the dev vs prod, I think John Hanley has it right to split them into projects, but I'll flag this as the answer. – Runicode Jan 02 '19 at 00:31