Microservices Architecture on Google App Engine
Microservices refers to an architectural style fordeveloping applications. Microservices allow a large application to bedecomposed into independent constituent parts, with each part having its ownrealm of responsibility. To serve a single user or API request,a microservices-based application can call many internal microservicesto compose its response.
A properly implemented microservices-based application can achieve thefollowing goals:
- Define strong contracts between the various microservices.
- Allow for independent deployment cycles, including rollback.
- Facilitate concurrent, A/B release testing on subsystems.
- Minimize test automation and quality-assurance overhead.
- Improve clarity of logging and monitoring.
- Provide fine-grained cost accounting.
- Increase overall application scalability and reliability.
Google App Engine has a number of features that are well-suited for amicroservices-based application. This page outlines best practices to usewhen deploying your application as a microservices-based application on GoogleApp Engine.
App Engine Services as microservices
In an App Engine project, you can deploy multiple microservices as separateservices, previously known asmodules in App Engine. These services have full isolation of code; the onlyway to execute code in these services is through an HTTP invocation, such as auser request or a RESTful API call. Code in one service can't directly call codein another service. Code can be deployed to services independently, anddifferent services can be written in different languages, such as Python, Java,Go, and PHP. Autoscaling, load balancing, and machine instance types are allmanaged independently for services.
Versions within services
Furthermore, each service can have multipleversions deployed simultaneously.For each service, one of these versions is the default serving version, thoughit is possible to directly access any deployed version of a service as eachversion of each service has its own address. This structure opens up myriadpossibilities, including smoke testing a new version, A/B testing betweendifferent versions, and simplified roll-forward and rollback operations. The AppEngine framework provides mechanisms to assist with most of these items. We'llcover these mechanisms in more detail in upcoming sections.
Service isolation
Though mostly isolated, services share some App Engine resources. For example,Cloud Datastore, Memcache, and Task Queues are all shared resources between servicesin an App Engine project. While this sharing has some advantages,it's important for a microservices-based application to maintain code- anddata-isolation between microservices. There are architecture patterns that helpmitigate unwanted sharing. We'll describe these patterns later in this article.
Project isolation
If you don't want to rely on these patterns to achieve isolation and you want amore formal enforcement of separation, you can use multiple App Engine projects.There are pros and cons to using projects instead of services, and you mustbalance the tradeoffs depending on your situation. Unless you have a specificneed for one of the advantages offered by using multiple projects, it's best tostart with using multiple services within a single project because performancewill be better and the administrative overhead will be minimized. Of course, youcan also choose some hybrid of the two approaches.
Comparison of service isolation and project isolation
The following table provides a comparison between using multiple services andmultiple projects in a microservices architecture:
| Multiple services | Multiple projects | |
|---|---|---|
| Code isolation | Deployed code is completely independent between services and versions. | Deployed code is completely independent between projects, and between services and versions of each project. |
| Data isolation | Cloud Datastore and Memcache are shared between services and versions, howevernamespaces can be used as a developer pattern to isolate the data. For Task Queue isolation, a developer convention of queue names can be employed, such asuser-service-queue-1. | Cloud Datastore, Memcache, and Task Queues are completely independent between projects. |
| Log isolation | Each service (and version) has independent logs, though they can be viewed together. | Each project (and service and version of each project) has independent logs, though all the logs for a given project can be viewed together. Logs across multiple projects cannot be viewed together. |
| Performance overhead | Services of the same project are deployed in the same datacenter, so the latency in calling one service from another by using HTTP is very low. | Projects might be deployed in different datacenters, so HTTP latencies could be higher, though still quite low because Google's network is world-class. |
| Cost accounting | Costs for instance-hours (the CPU and memory for running your code) are not separated for services; all the instance-hours for an entire project are lumped together. | Costs for different projects are split, making it very easy to see the cost of different microservices. |
| Operator permissions | An operator has the ability to deploy code, roll forward and roll back versions, and view the logs for all services of a project. There is no way to limit access to specific services. | Operator access can be controlled separately on separate projects. |
| Request tracing | UsingGoogle Cloud Trace, you can view a request and the resulting microservice requests for services in the same project as a single composed trace. This feature can help make performance tuning easier. | Cloud Trace calls can be visualized across GCP projects if they are within the same Organization. |
What's next
- Understand how tocreate and name dev, test, qa, staging, and production environments with microservices in App Engine.
- Learn thebest practices for designing APIs to communicate between microservices.
- Learn thebest practices for microservice performance.
- Learn how toMigrate an existing monolithic application to one with microservices.
- Understand if microservices are ideal for your situation. On his personal blog, Google Solution Architect Preston Holmes haspublished a post about some of the drawbacks he sees in microservices.
Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-12-15 UTC.