tobad357
Joined 11 years ago
Joined 11 years ago
1. for some it will make sense to move to pricing based on CPU time per query vs billing on scanned TB of data. This can be done through the commits in UI.
2. there is option to have storage billed on logical or physical bytes. If you have data with a lot of duplication (enums, customer ids etc) then physical billing can be a lot better option. Last I looked this was only available through CLI setting in dataset and you may need to ask Google to include you in their beta. We lowered our billing with 30% for storage.
I try to keep an eye on GCP release notes to find things like the physical vs logical billing.
1. Use Docker images for our applications where we can run them locally by mounting in a config file pointing to local db or dev cluster db etc
2. We then use CI to build new docker images and push them to our registry
3. Using Kubernetes deployment yaml files we then deploy the new versions to the cluster with rolling upgrades. This can be combined with auto scaling For config we have a Kubernetes ConfigMap in the cluster which then gets mounted into the docker containers when they start.
My suggestions would be for you to check out Googles Hosted Kubernetes which removes a lot of the headache of getting up and running. https://cloud.google.com/container-engine/
Netstat -rn and you can see where the traffic is going or coming from. The added benefit is you can then bgp peer with other clusters and get routing across them
I implemented reflection for the dBase language and was also part of trying to convert it to Visual C++ instead of using the Borland compiler. I was very green back then but it was interesting, my only time dealing with interpreters / compilers