I'd wager that probably covers only ~30% of the world population, and considering that people who speak Mandarin for example use other apps, it probably covers an even larger slice of the Whatsapp userbase.
We use BQ quite extensively there are a number of billing tuning options which are not that well documented.
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.
Completely unrelated but as HN works as an unofficial support channel.
This page https://www.cloudflare.com/ips/ seems to be missing a range of IPs which are in the 172.66.x.x range, our site appears under it but can't see it on the page
I think it won't give you much in Dev but can give your more in production. We have the following work flow
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/
We have been using calico Cni with kubernetes with quite some success.
It's a solution that assigns ips and then sets up bgp routing between your docker/kubernetes nodes. It makes it very easy to trace what's happening. Not as easy as a flat lan but still pretty easy.
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
Calico looks good. As far as we understand calico works the same way as flannel/host-gw does, i.e. creates a route for all subnets in the cluster. Of course, calico is more advanced technology than flannel/host-gw, but the reason why we haven't tested it is following: they're different in control path but the same in data path. Our original intention was to test underlying linux-kernel mechanisms and understood how much we lose in terms of latency and throughput.
For small configurations flannel/host-gw is OK, I guess, but if one have several kubernetes clusters, flannel/host-gw becomes harder to maintain. That's a place where calico should be useful.
Actually my understanding is a bit different.
Flannel uses VxLan and acts as a overlay network (packet inside of packet) while Calico is a pure Layer 3 routing solution.
This means some performance gains but less protocol support vs VxLan. I think it would be quite interesting to test
My experience in Singapore is that Google Maps trumps Apple Maps on finding points of interest. However with driving directions Apple is a lot easier to follow. Apple tends to alert at better points before turn and also give more precise information about the turn. Example would be the number of the exit from the express way.
So I've resorted to finding the address in Google and then using Apple for the directions.
I would agree with all those points, except that Apple Maps regularly gives straight up wrong directions in terms of the infrastructure. I know of one interchange near Chicago where it consistently presents as "you need to veer right to proceed on this highway" where it's actually the left lanes you need and they spur right afterward. I've never had a similar error out of another navigation app or service.
