We had something similar happen with lifecycle rules, moving an entire bucket to glacier: end result was > $200k and AWS weren’t especially helpful on our attempts to refund us.
We were unaware that changes via a rule still count as an api hit per object, despite all happening in the backend. I’m sure we can’t be the only people hit by this.
The reality is that Amazon makes big bucks off the complete opacity of their costs. If you offer a UI where a click costs money, you should also display price.
But that's just my opinion. Maybe others like buying things from a menu without prices.
DigitalOcean emailed me once when I left my single $5/month instance open by mistake. AWS would never do that even for thousands.
I almost did that. Someone double checking the plans raised that as an issue and instead we went with a lifecycle at some specific age rule which didn't try moving everything at once.
And yes, it's both fairly well documented and something that can catch you by surprise at the same time.
You know, I feel like the perfect person to answer this. I used to be a sysadmin, then a devops engineer, then a "VP of Infrastructure", and I'm currently doing some hands on work again as a "lead devops engineer".
Like you, I used to be frustrated at my inability to program, and I felt like I could never make sense of any of it. I spent years in my earlier career sticking to "sysadmin things" because of that limitation.
Eventually, as automation hit the industry, I started writing more and more ruby code (we were Puppet users) and eventually I took a full time job for a year writing ruby code.
It was never an inability, it was always a confidence thing. I was scared to try and fail. By taking a full time position as a developer I -had- to succeed, and I like to think I did. I found it's not nearly as hard as I imagined, and the fact I did not have sysadmin duties competing made a HUGE difference. I was able to dedicate all day to what I was doing, not fit it into the corners of my life.
From what you wrote above, it's pretty clear that your personality woes (anxiety probably is the big one here) is convincing you that you can't do this.
I wasted years convinced that it was "too hard", but in reality I just didn't have the motivation to push through my discomfort. I don't actually write a lot of code these days, but I'm no longer afraid to pick up some code and modify it if I need to because I know it's just a matter of being patient and figuring things out as I go.
I'm not surprised it failed, with such drastic changes. Why couldn't they add a constraint of no more than 15 minutes change and reapply every year for 5-10 years until they reach a point they are happy with?
Because done that way (in addition to what sibling comments suggest), halfway through, there'll be a point when everyone has to get to school at the same time and the bus fleet will have to triple, at huge cost. Or you just end up doing a large disruptive jump anyway to avoid that timing issue.
Of course they could, but as the article mentioned toward the end, the school district no longer has the political capital to pursue rearranging school schedules. The superintendent lost his job over this. I imagine votes were angry with the school board.
Repeated change has its own substantial costs for a system as large as a school district - even without the outrage over the drastic change, reworking schedules every year would be enormously unpopular.
(Think of everything from changing heating and AC schedules to reworking start times for bus drivers to telling parents they need to drop their kids off at a different time each year. There's a reason most school administrators I know get an absolutely hunted look when you mention changing anything.)
My biggest issue with SICP was the lack of available unit tests for the exercises. I'd often "get it wrong" and have no recourse but to read a solution to see that I'd failed to account for some aspect of the problem.
Without an easily verifiable way to test your solutions as you go I think these kinds of books really do themselves a disservice as you lose the ability to struggle and think hard about the problem if you can't immediately solve it.
I ran into something very similar with a cluster almost identical to you. Turns out the default disk size for kops is 25G and when your masters run out of space things start to die with almost no way of telling why.
I rerolled with 100G and I've seen zero problems since.
The one thing I really wish I had was a comprehensive test suite for all the exercises. They are (obviously) hard to solve and there's no other way to see if you were right but to check the solution. It's a huge flaw in most CS books, feedback without hand feeding you the answers.
I disagree with this pretty strongly, actually. The best skill you can get from SICP-level exercises is looking at the code and being completely confident that you understand it and that it is correct. The best way to use them is to write the code without running it, and once you are sure, review it with someone else to find out if you were right.
This breaks down a bit around chapters four and five where you are plugging in parts of a larger code base, and the accidental complexity starts to dominate.
Self-study students can find someone online to study together.
I like the amount of projects SICP inspires. That's one of the best things about it. I wouldn't want to discourage writing a test suite, but I wouldn't suggest studying it by using one.
SICP questions are designed to have elegant solutions, which may be missed, this is one reason why a study group is better than a test suite.
How do you judge those qualities? I too interview for a similar set of skills (intelligence, curiosity, a desire to constantly improve things, someone who's just willing to put in the hard slog as well as work on the fun projects) but it's incredibly hard!
I've definitely had people that interviewed well that just wanted JIRA tickets fed to them immediately upon starting. It's very hard to figure out if someone will seek out and make improvements consistently from the basis of conversations.
(I'm in ops so there's rarely a body of code available they can share for how they work, either.)
take it with a pinch of salt... people that excel in all 4 criteria are at most 1% of workforce, and you need to bring some serious money and interesting challenges to attract them over from other seriously paying places with great challenges and atmosphere and whatnot.
I mean, what ambitious person would like to worse in less that best job available on the market, for best possible money?
Maxwell Health | Infrastructure Engineer | Boston, MA | REMOTE | www.maxwellhealth.com
Maxwell is a health and wellness technology company in downtown Boston. We’re on a mission to transform healthcare in America by creating an awesome consumer experience for enrolling in, managing, and using benefits.
We're looking to transform our style of operating services at Maxwell and we're hiring Infrastructure Engineers to help us build out the technology and platform our engineers use to build, test, and run their services in production.
We're currently using terraform, docker, and ansible, (and jenkins) in AWS to deliver our SaaS platform. Any prior experience with these would definitely be appreciated by us!
If you're interested in helping us implement containers in Kubernetes, in transforming our approach to monitoring and metrics, or just in working closely with engineers to really build something you're proud of, come talk to me at ashley.penney@maxwellhealth.com.
Maxwell Health. | www.maxwellhealth.com | Devops/Infra Engineers | Full time in Boston, MA.
Maxwell is a HR and benefits technology platform that combines management and enrollment in benefits into one experience, aimed at small businesses.
(I just used it as an employee as I just joined Maxwell and it was pretty slick compared to my previous onboarding experiences!)
We're looking to hire an "Infrastructure Engineer" to help us improve our
automation and operational practices. We're in the middle of transitioning from a traditional "devs build, ops run" environment to a microservice driven "devs build and run their own services" world. We're looking for experienced engineers who have either been through or worked on the other side of this transition to help us build, improve, and deliver building blocks to the developers.
We're especially interested in anyone with real world docker experience (I'd be double thrilled if you've played with Kubernetes) who has seen beyond the shiny marketing and experienced the world of pain that Docker can bring.
We're hiring locally in Boston at this time. If you're the kind of person that loves to pair up with engineers to help share your expertise throughout the team and really values a true collaborative environment then please come talk to me at ashley.penney@maxwellhealth.com. (or ashp on Freenode)
Am I doing something exceptionally wrong? I click Restore from file in scoped rules, and then decode recipe. That gets me more json on the left (in a red box, so I assume parsing failed). I then try "Import Rules" and nothing seems to happen. The commit button at the top never allows me to click, and nothing changes.
This is using the abp setup (and a few of the others in stuff/), none of which worked.
We were unaware that changes via a rule still count as an api hit per object, despite all happening in the backend. I’m sure we can’t be the only people hit by this.