Is Google App Engine flexible enough? – Agile Cloud Environment

Recently we discussed some basic features of App Engine, one of the Google Cloud’s environments (see Your application in Cloud – Google App Engine). Although it gives you some idea on what the platform is and how it’s different from other solutions, to be honest, we barely touched the tip of the iceberg.

When it comes to choosing the right architecture, a typical mistake some of us make is relying on first impressions, rather than analyzing deeply what is hidden behind all those awesome features. Most likely, you will find yourself on the dark side sooner or later. It might be a matter of pricing, tools or just quality – but you would have to be a real optimist to expect to find a solution that is perfect on every level and from every possible angle.

App Engine’s limitations

Not everything can be changed

The most common argument against the Google Cloud Platform – GCP – is that you cannot change anything in the environment itself in terms of what’s included in the runtime.

It may be a serious drawback if you think about the evolution of your system. While it may fit well in the platform at the moment, it’s typical that the requirements change during the project and it doesn’t really matter if the source of these changes lies in someone’s vision, the users’ needs or in the improvements of the analysis process. The important fact is that it’s always a living organism and it’s risky to assume that you will never need anything beyond the tools you already have.

Difficulties of file storage

Another issue you can face in this solution is a banned usage of disk space. Although some of such restrictions may just cause some minor difficulties or will make you solve the problem differently than you are accustomed to, this time it’s a no-go for libraries that need to write a file on a hard drive. As this platform comes as a solution so easily maintained on the scalability level, the environment is a closed sandbox and you cannot expect to do low-level operations here.

The above limitations, however, are not that big a deal anymore since the launch of the Flexible environment, which is an answer to most of the issues of the Google Cloud Platform App Engine.

Standard vs Flexible

Currently, the first decision you need to make when starting with the App Engine project is the choice between the two environment types it comes with. App Engine Standard environment, historically the first, is in many cases still the best choice, yet it is the one that all the limitations in terms of tools and runtime apply to.

Flexible Environment – Solution for runtime problems

The Google App Engine Flexible environment solves all the runtime problems you may face in your project. While it’s maintained almost the same as in the Standard application, it allows you to deploy a custom Docker Image that you can complement with any binary tool or language version you need.

Greater flexibility costs

Another thing that’s changed is the pricing. Google App Engine Standard environment is a model wherein the early days of your system when the traffic is low you either pay nothing or just small amounts for the resources that are used. Flexible Engine App, on the other hand, requires that at least one instance of the application is always available. It means that it’s impossible to stay within the free quotas.

Switch freely between environments

What’s important is that you don’t have to make this decision only once. You can switch between the flexible and standard environment or even use both at the same time to solve different problems.

Know your limits

Summing up: know your limits. It’s crucial to analyze the requirements and available tools deeply in order to be comfortable with the decision about the infrastructure underlying your system. You may also be interested in What you can’t do in Google Cloud NoSQL – Limitations of Google Cloud Datastore.

Every solution (Google App Engine Environment being no exception) may have its weak points and it’s necessary to identify them in advance so that it’s possible to evaluate what the possible workarounds are or if this specific tool is a good choice for the project that you will be working on. The alternative for a good analysis may fac the mentioned iceberg, but this time from a perspective much worse for you and anyone else involved in the project.