I am a fan of using “boring” (or as I put it – mature) technology for customer work. I like using familiar, well-documented tools to solve customer problems. For me the job is all about implementing the customers’ business solutions.
So when we started to use Google Cloud Platform I had assumed I would just continue to run my code in Linux virtual machines and that all this would mean is that the VMs would be in a different location – and apparently more easily backed up, more secure and maybe with a better SLA. I had previously experimented with containerization using Docker Swarm and then Kubernetes (despite my preference for using mature technology in production we keep up with the new technology – after all, some of today’s cutting edge is tomorrow’s “boring”.) However, I had come to the conclusion that containerization solutions were still a time sink with way more friction than reward.
Then as The Cloud People ramped up as a GCP partner and I started taking certifications I had plenty of chance to study and play with the different GCP options for running containerized applications. There are several different options which will work well for different usage requirements. For example: we are using Kubernetes to run some applications and the experience has been great. However, the option that jumped out at me was App Engine Standard environment. This promised a true No-Ops experience and seamless scaling. … then I noticed the run time requirements. Specific versions of specific languages with limited libraries… This looked limiting. I shook my head and went back to my Linux VMs. But then some new run times came out. The new PHP run time supports installing arbitrary libraries via composer! This looked like something to try! We jumped in with several new services.
What have we been doing and what has the experience been like?
- Personally I would prefer to use Python whilst some of my colleagues would like to use Go but since several of us have deep PHP knowledge (and the language has been steadily improving for the last decade) we decided to stay with PHP.
- We decided early on to support local development using docker/docker-compose. This decision has been great because it means we are not locked into App Engine. We know that our code runs in a non-GCP environment.
- Deploying directly to test instances in GCP is almost too easy! For production we have started to lock down the deployment process.
- The read only file system has been a slight limitation, but it has encouraged best practices around build artifacts and media files.
- We are using a full-fat-framework that we are very familiar with. Most features of the framework work perfectly. A few features are limited by the read-only file system. We will one day need to solve some problems around this but have not had anything impacting us so far.
- The build service for App Engine does not support post-install scripts for composer. This has been the biggest limitation we have encountered so far.
- Integration with other GCP services has been excellent.
- In these projects we are already making extensive use of Pub/Sub, postgres hosted in Google Cloud SQL and Google Cloud Storage. In the future some workloads which are appropriate for Cloud Functions will be refactored into Cloud Functions.
- So far the costs (reasonable), auto-scaling (seamless) etc have been exactly as expected.
- We are now planning to migrate some legacy products into App Engine Standard environment.
If you have any questions feel free to get in touch with us at info@thecloudpeople.com.