Today’s business environment is very competitive. No company, no matter its size, reputation or what industry it is in is safe from disruption. The adoption of agile development is a good practice and certainly helps with fast moving business environments. However, implementing true micro-services best practices allows to further change code quickly, innovate easily, and meet constantly business requirements.
I have some lessons learned from working with the Google App Engine Environment and Web frameworks like Django, Flask and Angular.js which can be time saver and can help make better design decisions during the development process.
Think in terms of micro-services and not monolithic solutions since the beginning.
Micro-services in GAE are small, autonomous server instances that work together which are loosely coupled in a service-oriented architecture with bounded contexts. In GAE, multiple services can be deployed as part of a project. Each service has full isolation of code and the only way to execute the code in these services is via an HTTP invocation ( RESTful API call).
Think of a project as an environment container with multiple small server instances rather than one server or instance providing all services at the same time as a monolithic solution:
For a Web application with backend components, microservices services can be used to host one or more Web servers and multiple lightweight RESTful APIs grouped by feature categories.
In a monolithic application, the code base becomes bloated over time. After a while, it becomes difficult to determine where the code needs to be changed. The example above, in the monolithic application the UI, orders, payments, shipping, etc are part of a single code base. The entirely application needs to be deployed and tested even if a change is made to a small part in the code. This increases productivity cost and functionality risks when making bug fixes and making changes.
Breakdown the app into features and services
In the micro-service design pattern, a service follows the single responsibility principle and has full autonomy from other services. Therefore, changing a service implementation does not have any impact to other services as they communicate based on an agreed RESTFul HTTP interface contract.
When developing a new app from scratch, it is best to break down the application by planned features to be developed. These features can be associated to a module or several modules which can be turned into a microservice or a group of microservices.
If you are porting or migrating a monolithic application into a microservice driven application, it is still best to break down the application by features to determine services or category of services. Then you can extract and refactor the existing code to determine whether the existing code needs to be rewritten or can be refactored into modules.
I find it helpful to work with the multi-module app structure pattern. For small applications with single services, the configuration and source files can be located under the root directory:
GAE apps are hosted using "project ids". A given project ID can have one more more microservicers. But there is always a "default" microservice always active:
For larger applications, typically, you create a directory for each service, which contains the service's YAML files and associated source code for large applications.
A more complex and distributed application employing caching, a message broker, cloud SQL, processing services and backend APIs can look as follows:
Loading of Modules, Allocation of Static Assets & External Libraries
Service instances the Google App Engine standard environment have a hard limit in terms of resources. In standard GAE environment the smaller instance is limited to 128MB in RAM and 600 MHz in CPU. The biggest instance is limited to 1024 MB in RAM with a 4.8 GHz CPU bound limit. Therefore, your code modules need to be lightweight and only use dependencies that are absolutely needed to keep operational costs low.
- External packages or jar files should not be stored in the code repository. Instead, install them using a dependency manager. For a Python application such as Django or Flask, these dependencies can be listed in a manifest text file.
- Centralize static assets such as css files and js files in one central folder located at the root directory called /static and associate it with the corresponding path handler in the YAML file.
- Unused imported modes should not be avoided.
Cost Effective Application Scaling
In the GAE environment there are two options for application scaling: automatic scaling and manual scaling.
| Manual Scaling | Automatic Scaling | |
|---|---|---|
| Request Latency Policy | Requests can last more than 60 seconds | Request must last less than 60 seconds |
| Resident instances | Minimum of one instance at all time | No required instances running at all the time |
| Operational Cost | More expensive for Web apps | Less expensive for Web apps |
| App Features Latency | High latency requests benefit from this mode such processing data in instance ( data transformations, encryption, decryption, etc) | Low latency apps benefit from this mode employing asynchronous requests to other BigQuery resources (BQ Jobs, cloud storage, etc |
| Blocking/Non-blocking Requests | Requests can be synchronous and persistent between browser and backend instance. | All requests should be non persistent and asynchronous. |
| Traffic Spikes | Instance resources are allocated in advanced regardless traffic demand | Instance resources are allocated upon demand based on traffic demand |
In summary, to promote lightweight micro-services to decrease operational cost, the following principles should be followed:
- Aim for using automatic scaling: In this mode, requests must be short lived and data processing in the instance should be minimized. No HTTP request should last more than 55 seconds.
- Use manual scaling only when needed. If a component of the app requires persistence requests, then insolate this component into a microservice and configure it as manual scaling. The rest of the services should continue to use automatic scaling.
- Decouple the app by categorizing features which can be grouped and hosted in different microservices. Trying to centralize the API component, Web server, HTTP routing and any other module features in one service only leads to monolithic architectures which in turn would require more instance resources which is costly and do not scale well.
- Avoid slow-loading apps. Unused third-party libraries should be avoided at all times. Only libraries and modules to be used should be loaded. This decreases the number of service instance needed and decreases operational costs.
- All backend operations and interactions with front end should be performed asynchronous. Avoid persistent HTTP requests.
- Event driven processing should be used when possible. For instance, if the app processes data uploaded by the user, you can use a Google Cloud Storage bucket to store the data blobs and use Google Cloud Functions that are triggered when the data blob is uploaded for further processing.
- Design each application microservice so that it focuses on compute tasks only. This approach enables you to use a worker pattern, to add or remove additional instances of the component for scalability.
- Use pub/sub for messaging queueing to enforce loose coupling between processes that are running in different microservices. The message broker can be used to perform asynchronous processing, and buffer request in case of spikes in traffic rather than scaling up the service tear.
- Decrease the number of previous versions deployed in the project container. By default, GAE keeps running previous versions in the project container so you can switch between releases easily. However, this increases billing exponentially.
For automatic scaling: Make sure your deployment pipeline calls the gcloud command line with the --stop-previous-version flag:
gcloud app deploy --quiet --stop-previous-version
In automatic scaling, at least the last release version is kept running by default. This is something you can not change.
For manual scaling: The gcloud command line with the --stop-previous-version will stop all previous releases.