cbushko

15 ms·

91.
by cbushko 6y ago
Interestingly, we don't have any of these problems with MySQL. We have several read-replicas on our DBs and things have been stable. I will guess that you are much higher scale than us.
92.
by cbushko 6y ago
We are using PHP and thus no connection pools at all. This definitely doesn't help us with speed. With public IP there was some mystery point that just slowed everything to a crawl. MySQL for our DB.
93.
by cbushko 6y ago
I created all of the IAM roles that our 100+ person company uses. It was and is important from a security standpoint that we do not just blindly give too many permissions to employees. I had to do some research to understand what the bare
94.
by cbushko 6y ago
I honestly don't know what the difference is but the number of hops is probably a contributing factor to the decrease in speed. There could be some translation layer happening when going from the CloudSQL instances private IP to public
95.
by cbushko 6y ago
There are several reasons: - Google has a lot of experience running containerized services because of Borg. Google Research says that they have been running these workloads since 2005. - The above gives them insight into how to do thi
96.
by cbushko 6y ago
Definitely. I have nothing against Digital Ocean or their offering. It was only an example of a different mindset.
97.
by cbushko 6y ago
Ours cloudsql-proxies were on running on GKE so they were not "that bad". Switching to private ip definitely had the largest impact by far on performance.
98.
by cbushko 6y ago
I went through this during last summer. The nice thing is that you can switch to private ip and cloudsql-proxy will still work. At least you can isolate your changes.
99.
by cbushko 6y ago
I spent over a year doing a full migration from AWS EC2 + ECS instances to GCP + docker + kubernetes. It was a huge task that has paid off very well. 1) Costs per customer are lower because you can fit more containers per VM due to kube
100.
by cbushko 6y ago
Not the original poster but we migrated to GCP because: 1) AWS was extremely expensive 2) Our GCP bill is about 1/3 of what AWS was 3) The Kubernetes offering is top notch 4) Google giving us credits and offering us co
101.
by cbushko 6y ago
CloudSQL was slow for us until we do the following: 1) Increase the disk size to 100GB as this increases the IOPs 2) Switch to using private IP addresses. Huge speed increase 3) get rid of cloudsql-proxy. Another huge speed increase
102.
by cbushko 6y ago
It was 100% toxic environment and a broken culture. My coworkers were fantastic but upper management was horrible. It was almost like highschool drama. I learned so much, 70 hour weeks will do that, but I also learned about balance and what
103.
by cbushko 6y ago
Ooof. I think people are picking and choosing too many points to make it seem like this guy is an asshole and a toxic manager. I read that he wants people to: - Do their work - Provide value for their users - Get stuff done. vs - Work on fl
104.
by cbushko 6y ago
Or you can pay the price for it and use GKE. Of course, not for a home lab :)
105.
by cbushko 6y ago
We do use some helm charts for the bigger things, gitlab runners, istio, thanos, prometheus, argo, etc. Some of those are run as directly from helm but many are being converted to use the terraform helm provider. Our initial rollout on kube
106.
by cbushko 6y ago
I too prefer HCL to YAML and especially to helm templating. Loops and conditionals in HCL could still use some real work though. They are still clunky to work with.
107.
by cbushko 6y ago
> (Not joking) You are tired of running Helm charts or writing large YAML manifests. The config syntax for Nomad jobs is human friendly and easy to grasp. I write all of my kubernetes resources in terraform because I don't want to f
108.
by cbushko 6y ago
The things you are writing now are fantastic so keep that up. Anything deep into kubernetes, go, GKE, monitoring, security, etc are all good things to read about. I found your writings based on your helm article. I am not a fan of helm as i
109.
by cbushko 6y ago
I tried a couple weeks ago and it wasn't working. It must have been a medium thing but it's working now! Thanks!
110.
by cbushko 6y ago
Nice insights and I will definitely take a deep look at ko. Slightly off topic but since you linked to his Twitter account, everyone should check out Dan Lorencs articles. There is some interesting articles about Golang, kubernetes and othe
111.
by cbushko 6y ago
We are using it for code tracing, hostname ingress routing to the correct namespace, and egress blocking. This year we should also be using it for canary deployments also.
112.
by cbushko 6y ago
Exactly. Kubernetes has established patterns. Once you understand them then everything gets EASY. How toñset everything up, how to deploy, networking, service communication, secrets, etc I've had teams create brand new services in hour
113.
by cbushko 6y ago
We go through several stages before it hits prod. Our test environment -> the dev environment -> staging -> prod and still we are bitten by istio. A lot of the problems we have seen do not manifest themselves until you get signific
114.
by cbushko 6y ago
The Istio one hits home. It is the single scariest thing to work with in our kubernetes clusters. We've caused several outages by changing the smallest things.
115.
by cbushko 6y ago
Doing it now will save time in the future, similar to how writing tests now will save you in the future. If you are using terraform to deploy to the cloud, there are a lot of standard modules out there that you can leverage that will save y
116.
by cbushko 6y ago
Not exactly. You have to watch your libraries for vulnerabilities no matter what language you use. Link or apt-getting the library will pull in a vulnerability I am more concerned about pulling in Linux binaries that are full of vulnerabili
117.
by cbushko 6y ago
I have not studied this area of science but the article reminded me of the fictional book series The Three-Body Problem by Liu Cixin. I really don't want to say anything to spoil the books but the series were so good that I devoured th
118.
by cbushko 6y ago
I agree with you. I've worked at several startups and they start with 'productive' languages like python, ruby, and PHP. These are great for getting something up and running easily. Everything looks great at the beginning. Th
119.
by cbushko 6y ago
Yes, you can patch them but with a compiled binary like go, you don't have to. You don't have to watch security lists for vulnerabilities. You don't have to scan your docker containers because the dockerfile is 4 lines long.
120.
by cbushko 6y ago
That is a double edged sword. Sure, that dynamically typed language of python or ruby might be quick to develop on but they often contain a lot of surprising bugs. Compilers catch a lot of bugs before your software is in production.

More ›