41–50 of 126 posts
I think python would've been in more trouble if it never made the transition to version 3. You probably shouldn't be building massive apps in Python in the first place.
Earlier quoted context omitted.
Okay — and? How is any of that relevant to what I said? You’re ignoring that maintaining your code without modifying your data access (changing only the wrapper) significantly simplifies virtually everything you listed - with the exception of network topology changes.
Because in the grand scheme of things “your code” and even changing your code is just a minuscule part of what it takes if a migration did ever happen. So the question remains, have you ever been a part of a large scale migration? Have you ever been in the room when the planning was happening?
Just a rant about having to react to things that the author didn't want to react to. But these are facts of life. I find GCP policies pretty reasonable. I was never caught off guard by them.
When everything takes 20% longer to ship than you planned because every other week some random team(s) is forced to do unplanned, immediate rewrites by a vendor, that vendor starts to look like a dick and also a huge liability to your business.
Also Google's own documentation is full of grenades. Just yesterday I found in their GKE docs something they tell you is the default and you must use it...except it doesn't apply to clusters created a few versions ago, even if they're updated, because they didn't roll their change out to existing clusters -- just new ones created after their change.
Also google's docs reflect their deprecation policy -- there is no document versioning. You can always and only see latest.
I think python would've been in more trouble if it never made the transition to version 3. You probably shouldn't be building massive apps in Python in the first place.
A major critique of the python transition is that they forced you to port your code instead of supporting python 2 code alongside python 3.
This story resonates with me so much. An avid cloud platforms user in the past, now I just use Dockerfile + fly.io combo. Dockerfile gives you a total freedom without vendor lock-ins and forceful deprecations. I have never been calmer and happier before that switch. Now, only I decide when to upgrade - and usually it is as easy as editing a text file pointing to a new package version. IMHO, the only thing cloud provi…
One of our engineering teams wanted to use fly.io instead of kubernetes that I was running in AWS for the company. They really liked its ease of use and they really wanted to use it. Unfortunately fly.io only allowed 5,000 concurrent TCP connections, and there's was a chat app that needed to maintain many more web sockets than that for each instance that was running (More like 50,000). So they ended up switching to k…
Google engineers just don’t seem to value back compat in their bones. I’ve read they have tools and processes internally that let them make breaking changes and globally find / fix callers. That’s cool, but the rest of don’t have that. No one likes getting an email that says “we’ve changed the way X works, you have until Y to change your code or it will break.” Not even if Y is a year from now. A rule that says no br…
Fundamentally it comes from the fact that they don't have to do any of it anyway.
Anyone using AdWords knows that it's a money-printing machine. Google is thousands of fresh CS graduates who want to do "cool green-field stuff" but not really the day-to-day grind we are all part of and what we call "software engineering".
========
Hello,
This is a reminder to update your policies to avoid changes to your access to AWS Billing, Cost Management and Account consoles. Our records indicate that you are still using retired actions to access these consoles.
If your policies are not updated with new actions by December 11, 2023, your users’ access to the AWS billing, Cost Management, and Account consoles will be affected.
The policies that need to be updated to include the new fine-grained actions are listed in the “Affected Resources” tab of the AWS Health Dashboard in the “Policy | Policy Name | Policy ARN | Type” format.
To help you with the migration, we have published a mapping between old and new actions in our user guide [1]. If you need to update policies across multiple member accounts in your organization, we have built bulk policy migration scripts to help you update all policies quickly and securely from your management account. See the bulk policy migration scripts user guide [2] for more information. You can find a detailed guide on how and which policies you need to update on our blog [3] and definitions of new IAM actions in Cost Management [4] and Billing [5] user guides.
AWS will not be able to grant further exceptions after December 11, 2023, so we strongly recommend that you act promptly to migrate your policies to new actions.
If you have more questions or need help make updates to your policies, please contact AWS Support [6].
Sincerely, Amazon Web Services
========
Not only did they send me this email, they sent me 10 copies - one for each account we have. Pages and pages of documentation, steps to follow, Cloud Formation stacks to create, Python scripts to run, etc. I'm still not completely sure what the problem was or what is supposedly improved, or if I would've actually lost access to anything, but hopefully the emails stop now.
Google engineers just don’t seem to value back compat in their bones. I’ve read they have tools and processes internally that let them make breaking changes and globally find / fix callers. That’s cool, but the rest of don’t have that. No one likes getting an email that says “we’ve changed the way X works, you have until Y to change your code or it will break.” Not even if Y is a year from now. A rule that says no br…
Note: Post is from 2020