Aren't you getting killed on inter-AZ bandwidth costs with streaming replication?
This was our experience when we tried it.
108 karma · joined March 18, 2018
`paul.s (at) objectdisoriented (dot) com` if you need to reach out.
This was our experience when we tried it.
We manage a rather large cluster using it and for the most part, it works.
Getting functional PITR that you can restore rapidly is honestly our biggest gripe with PG. WAL-G/Barman certainly do work, but when your DB is measured in terabytes, even bootstrapping a replica is very slow.
Good housing will cost you.
Networking in the early years as a young founder paid off big time.
More than likely will get their ESP's attention.
They email me once a year that stuff is about to expire, I renew it.
I've never had to interact with them otherwise about anything, which in this case means they're clearly doing something right.
So yes, really. Nothing on your list is unattainable at much, much lower cost if you're willing to put in the work at maintaining it yourself (no cloudformation at most traditional providers of this stuff, and while you can somewhat roll your own with k8s for /some/ stuff, the offering traditionally is nowhere near as cohesive.)
The non-open source but complementary services (think Dynamo/EventBridge etc) are imo AWS' real strength. If you need to be able to just throw cash at the problem and never worry about capacity management yourself, AWS (and GCP, and Azure, and <insert PaaS provider here>) is usually an excellent fit.
Our fault, I suppose -- but multi-az is prohibitively expensive if you need to run anything data heavy distributed.
WebStorm seems to understand Microsoft's TS better than the VS Code Plugin. Complex refactors actually work.
Ultimately, regardless of how the high school education level might be, these countries win out.
That's not really saying much.
Sure, `http.createServer` is a few more lines of code compared to the equivalent PHP `hello world` but I don't see it as an insurmountable hurdle.
Socializing in your formative years is MASSIVE.
If there's someone with a proven track record of making sound decisions at the required level, often the team benefits from just following their lead.
Obviously, this can't be another case of the 4x engineer making everyone else 0.4x engineers. Fairly situational indeed.
Let's not forget that you'd also have to pay at least 3 (8 hours per shift, not accounting for weekends) people to ensure 24/7 service availability through those 15 Hetzner nodes.
AWS/GCP/Azure et al make it so you generally don't need to worry about the infrastructure part of the problem. Everything else still applies though.
I said that at the risk of being accused of having internalized racism as an Asian person, but the situation on the ground really does resemble what he said.
I wish they went with Intel chips too :(
User privacy is a great thing, and most of us smaller developers have nothing against it. However, it needs to be done in a way that doesn't threaten our business continuity.
I'll even go one step further and say that I personally don't think Apple will do it unless under extreme circumstances.
The thing is though, business continuity assessment still points to adopting Apple login to be a bad idea. You never really know when you'll find yourself in hot water with one of your vendors, especially a vendor who's a LOT more powerful than you.
I agree with the group that's (rightfully, imo) concerned about handing over this amount of power over their business to any 3rd party. There's a real potential for abuse.
If Apple tells you to take a hike, and then subsequently disables the email redirect -- you're completely SOL. You'd have no way to reach out to the user anymore, unless you took other identifying bits of info. And if you did that anyway, that defeats the purpose of AppleID to begin with.
Most users will probably not even be tracking what autogenerated email they're using, hence you no longer have a way to reliably reconcile what user had which account.
Regarding the GMail specific case though, I fully agree. Being banned by GMail is a company ending thing.
Where's this confidence coming from? If Apple sees it fit to prevent you (the developer) from accessing your Apple specific userbase for any reason / violation, other people seem correct in their theorization that there's nothing you can really do as the developer.
Not implementing this new "Sign in with Apple" will also probably be interpreted as not being privacy friendly by the users, a developer can't really have that either.
Pretty much the definition of being stuck between a rock and a hard place.
From a network administrator's point of view, they're an absolute joy to work with too.
If you're share any IXes with them at all, they'll peer with you. Private / appliance based peering has additional requirements, but that's par for course.
Most of the pushback is on the ISP end.
This prevents people from pointing the finger at them for not providing SLA credits.
Twilio/Google Voice (more generally, VOIP numbers) are explicitly being blocked (because it's possible to find out what type of number it is) at a number of services, likely to combat fraud.
I've found MSFT (Azure) and AWS to be recent examples of such services. Google itself does the same.
Having the Americanized name instantly lowers the difficulty though. Anecdotal, but I've seen this myself as well.
Ah, brings tears to my eyes :)
It's amazing how true this is (applies to most minority groups). With my native name, a lot of companies don't even seem interested in sparing a second look.
With the Americanized version, I've had no problems at all landing interviews (and getting hired!).