At Google, they found that engineers L5 and above got more work done with RTO, and engineers at L4 and below got significantly less work done. WFH is great but it doesn't work for fresh engineers (who are often the most gung-ho about it as well).
We use Python to generate these configs at my work. Ends up working out pretty well. I previously worked on the biggest deployment of gcl (the inspiration for KCL, Jsonnet) at Google and it was a giant nightmare and the cause of many outages.
Agreed. I used json-e back in the day, and have been using pulumi more recently, though my pulumi configs are simpler and I'm not sure how well it scales to really complex workloads/job graphs.
More likely they mean "readiness check" - this is the one that removes you from the Kubernetes load balancer service. Liveness check failing does indeed cause the container to restart.
Yes sorry for not qualifying - that’s right. IMO the liveness check is only rarely useful - but I've not really run any bleeding edge services on kube. I assume it’s more useful if you actually working on dangerous code - locking, threading, etc. I’ve mostly only run web apps.
> When using Cloudflare Workers as an API server, I have experienced requests that would “fail silently” and leave a “hanging connection”, with no error thrown, no log emitted, and a frontend that is just loading. Honestly, no idea what’s up with this.
Yikes, these sorts of errors are so hard to debug. Especially if you don't have a real server to log into to get pcaps.
Cloudflare workers are not amazing in terms of communicating problems. The errors you get can also be out of sync with the docs and the support doesn't have access to poke at your issues directly. Together with the custom runtime and outdated TS types... it can be a very frustrating DX.
I've done it, but: enterprise support helps a lot, multiple extremely annoying tickets were required, I did find multiple issues - some fixed, some worked around. And overall, the fewer people use CF (or another provider of their size) the better.
> And overall, the fewer people use CF (or another provider of their size) the better.
I understand your sentiment, but I vehemently disagree.
The cloud provider space has rapidly become an oligopoly and CloudFlare is one of the few new entrants that (1) has sufficient scale to compete with the incumbents; (2) has new ideas that the incumbents cannot easily match (region earth, durable objects etc.).
For most production workloads, I would not even consider the newer cloud providers, but I sincerely meant it when I said I hope Cloudflare will succeed. They've also been very responsive to the feedback raised in the blogpost when I DM-ed them.
(On a side note re: difficulty for newcomers in this market, I used to be part of a team that would run e.g. staging and testing environments on a new serverless db provider, but would run prod on AWS Aurora. In retrospect, this did not make much sense either as you want your environments to be as similar as possible, which means new cloud providers have an even tougher time getting started.)
I'm curious why people pick Azure, if anyone here has direct experience with making the decision.
I work at a startup that runs on Azure, and we're only here because of Microsoft's monopolistic behavior. We switched because Microsoft gives Office 365 discounts to our customers as long as all the the SaaS services they use are hosted on Azure, and so our customers demanded we use Azure. Part of the monopoly playbook: "using a monopoly in one area to create a monopoly in another".
I used to work at GCP, and I thought it was almost shameful that we were in 3rd place behind Azure. Now it just makes me mad (especially since I had to migrate our startup from GCP to Azure).
Pretty similar reason, customers use Azure so the incentives are in place to run more things on Azure.
Case in point at work: we need to set up Azure infrastructure per-customer. Hitting the Azure RM endpoint from outside the Azure network is not reliable; the API endpoint's DNS record points to one of two IP addresses in westus, and when the DNS record flips (presumably for blue/green deployments) the no-longer-referenced IP address immediately aborts the connection. The official Azure Terraform provider throws an error when this happens and it usually results in Terraform state losing track of something that it already created. Azure support just says "well all we see is 200 OK from our side".
The "solution" is to run the Terraform workload from within Azure. The SLA is only really guaranteed if you're connecting to the Azure RM API from within Azure. Cue the insanity.
In my case, the company I work for isn’t a software company. The bean counters / IT group would rather just have something tacked onto their existing Microsoft subscription vs. something entirely different.
Also, I suspect part of the reason people are hesitant to use GCP because Google is perceived as a company that will gladly kill products off on a whim. Not great for something mission-critical.
From what I've seen, when people pick Azure, it's always about money.
Whereas with other providers, it can also be about money (because they offer a big discount or because the migrating partner is cheaper), but it can also be about wanting one service/feature that only X is providing; and once you're in, people tend to prefer to put everything there, instead of doing poly-cloud.
In my region, Azure salesmen are very active, providing huge discounts, so Azure is the most popular amongst big companies.
Meanwhile smaller ones will go on AWS because its easier to find information and (actual) knowledgeable people.
I used to work in a company using AWS : everything was managed through Terraform and we were as cloud agnostic as possible (mostly containers).
Then we were acquired by a bigger company with a Azure deal, so they told us to migrate from AWS to Azure.
They provided us with their own experts to help us, but six months in, we were still unable to have anything remotely viable for UAT.
The experts were starting to acknowledge that even with they years of experience, they still weren't convinced with this whole Azure stuff so they actually relied heavily on a legacy on-prem DC.
That's when I left.
Last time I heard about old coworkers, the product was still running perfectly fine on AWS, while there was still a team working on the migration.
It's been more than two years now.
And I had other bad experiences with Azure.
I know that cloud providers are not fun if you don't start with two weeks of training, so I try to stay open-minded, but no matter how many Azure experts I talked to, I never found one who was actually confident in using it.
How does this work? Do they demand you to use Azure for your servers so they get a discount? Or do you have to create instances of your product in e.g. VMs that are put in their Azure account? Did you have to completeley leave every last bit of gcp behind? How is this checked by MS?
- we use mainly GCP
- we do not want to use AWS because of random political issue (absurd, in my opinion but whatever)
- we are raped by GCP and would like an alternative to help keeping the price "acceptable"
What you call “monopolistic behavior” a senior/lead engineer with a brain will see as ecosystem compatibility. If you are working within an org that already uses Microsoft for everything, why the hell would you bother introducing a new stack everyone else will have to learn rather than use the Microsoft offering if it’s competent enough? On top of that, the Microsoft product will most likely work nicer with other MS products. Same reason people buy iPhones and Macs and stay in the apple ecosystem. Yeah it’s not as hip and exciting but enterprise development is rarely hip or exciting. At a startup not already using MS products, yeah no shit you can use whatever you want with little to no considerations for compatibility within the stack, especially when your main goal is cost savings.
Yup, the hardest part about migrating to Azure was jumping between all the managed services that work everywhere else but are insanely buggy on Azure. We ended up with the most basic architecture you can imagine (other than AKS, which works great as long as you don't use any plugins) and we're still running into issues.
We have a very long list of Azure features and services that we've banned people from using.
Just got off a call with someone at Azure today who told us to setup our own NAT gateway instead of using Azure's because of an outage where we made too many requests and then got our NAT Gateway quota taken away for the next 2 hours.
> Yup, the hardest part about migrating to Azure was jumping between all the managed services that work everywhere else but are insanely buggy on Azure.
Care to point out a concrete example? I've worked with Azure a few years ago and I wouldn't describe it as buggy. At most, I accuse them of not "getting" cloud as well as AWS. For example, the whole concept of a function app is ass-backwards, vs just deploying a Lambda with a specific capacity. That is mainly a reflection of having more years working with AWS, though.
