austinshea

just explain your pattern.

what you are saying means you have a leaky chain of custody and are fine with that,

but you can show why i'm wrong.

This is so nice, and very generous.

I would like to be able to self host this, and, while this is absolutely not the best way for you to monetize this thing, if you put it up for some sub 100 dollar price, and I felt like I was getting a lifetime pass... I would do it.

It isn’t, but it’s not possible to get paid like that if your work isn’t a necessary component in the work that earns the company a lucrative payday.

A lot of people, who are on their way to doing truly professional work, have this epiphany.

The place you need to get to is understanding that you are being asked to ensure a problem is solved.

You’re only causing a larger problem by “solving” issues without both becoming an SME and ensuring that knowledge can be held by the organization, at all levels that the problem affects (onboarding, staff, project management, security, finance, auditors, c-suite.)

I agree with everything you're saying, and I think other archaeologists feel the same.

My opinionated take is: I wouldn't want to use this space for the information that this tool could provide, and rather leave it as the truth.

The truth is that it was committed without a meaningful message, and now I might recognize a chain of message-less commits, representing a moment in time where the authors were trying to figure out where they wanted to end up.

If the tool is producing this info simply by reading the diffs in the code, why not just use it when you need it, to help explain what you're digging through, instead of changing the commit history?

Either way, the critical detail is: People should get that detail out before the rice has been cooked, and that's what I do for myself, in my own private repos, and when others do that for future archaeologists, we all benefit.

I love it. A bit guided of assistance can really make all the difference.

It's not absurd, and it's also not gatekeeping.

Why do you want a summary of the changes? The bulk of the information in a commit is the diff itself.

The information that is not contained in the diff is the author's intent, and that's what the space is meant to contain.

I'm not convinced you actually believe that a summary is valuable because this whole comment is coming from a very defensive place.

The value of the space is the ability to glean the commit author's thoughts, at the time they committed it.

This is extremely dissimilar to the thoughts of the author.

The value of what this emits is already handled by evaluating the diffs in the per-file history.

It's not good to throw this sort of thing over the fence, and justifying it by considering it to be wasteful of your precious time doesn't change that.

It's better to leave it blank, but a tool like this looks perfect to help someone avoid scrutiny, while simultaneously avoiding providing a tiny depiction of what they were thinking when they committed the change, at the expense of injecting vast amounts of noise.

Some stuff is going to be provider-specific.

Let me explain why we’re not talking about an 80/20 split.

There’s no reason to treat something like a route53 record, or security group rule, in the same way that you treat the creation of IAM Policies/Roles and their associated attachments.

If you create a common interface for your engineers/auditors, using real primitives like the idea of a firewall rule, you’ve made it easy for everyone to avoid learning the idiosyncrasies of each deployment target, and feel empowered to write their own merge requests, or review the intended state of a given deployment target.

If you need to do something provider-specific, make a provider-specific module.

Most work isn’t greenfield.

AWS can be used in a different, cost effective, way.

It can be used as a middle-ground capable of serving the existing business, while building towards a cloud agnostic future.

The good AWS services (s3, ec2, acm, ssm, r53, RDS, metadata, IAM, and E/A/NLBs) are actually good, even if they are a concern in terms of tracking their billing changes.

If you architect with these primitives, you are not beholden to any cloud provider, and can cut over traffic to a non AWS provider as soon as you’re done with your work.

Talk to support: https://support.aws.amazon.com/#/contacts/one-support?formId...

Yes, they do.

https://support.aws.amazon.com/#/contacts/one-support?formId...

Thanks for this article. It feels like a huge problem to discuss the nuance described here.

There will be people who will carelessly create unmaintainable software, and they might do it to bamboozle someone who is paying for the work that experienced people can deliver.

Others might fire the sorts of people who would do that sort of work, and try to survive without paying the going rate.

These things are objectively bad.

It is not bad to use these tools, or any others, to do the best work you can provide.

This is entirely predicated on the issues this person experienced. Irrespective of whether or not devops teams end up with solutions that look like this, none of them are meant to.

My first experiences had to do with the ability to add new services, monolith or not, and have their infrastructure be created/modified/removed in a environment/region in-specific way, and to be able to safely allow developers to self-service deploy as often as they want, with the expectation that there would be metrics available to observe the roll-out, and safely revert without manual intervention.

If you can't do this stuff, then you can't have a serious posture on financial cost, while also providing redundancy, security, or operating independently of one cloud provider, or one specific region/datacenter. Not without a lot of old school, manual, systems administrator work. DevOps hasn't gone away, it has become the standard.

A bunch of pet servers is not going to pass the appropriate audits.

There were more peripherals to worry about, and fewer generic drivers.

It's not like people are trying to individually purchase PCI sound/ethernet/modem/graphics; they just get these components from the south bridge and they don't think about it at all. This makes things much easier, and gives a clear target for community notes/contributions.

I suspect that the reason he is describing this systems admin work as exhausting is because we've moved on. Personally, I only care about the thing I'm doing with the computer I happen to be sitting at, as opposed to computer itself.

Separately, power management is not a new detail: https://www.lpthe.jussieu.fr/~talon/pentiumII.pdf The Pentium II processor supplies a STPCLK# pin to enable the processor to enter a low power state. When STPCLK# is asserted, the processor puts itself into the Stop-Grant state. The processor continues to snoop bus transactions while in Stop-Grant state. When STPCLK# is deasserted, the processor restarts its internal clock to all units and resumes execution. The assertion of STPCLK# has no effect on the bus clock.

This is fantastic! Thank you for writing this and sharing it.

Okay, I hope so too. The article reads: Rodriguez said: “Facebook knows very well that they have no obligations under the act right now.”

Your original post is full of your ideas, that do not relate to this article.

I can agree that there's more to a job than the salary, and it's totally cool to negotiate.

When you make the salary ambiguous in order to make your sales pitch, you are being unreasonable.

Cyberax,

I missed my opportunity to reply to your comment, but I really appreciate it, and I wanted to find a way to get this back to you. The comment in question:

"Well, I was one of the engineers that made the change :) I'm not sure how much I can tell, but the public reason was: "to make pricing more predictable". Basically, one of the problems was customers who just set the spot price to 10x of the nominal price and leave the bids unattended. This was usually fine, when the price was 0.2x of the nominal price. But sometimes EC2 instance capacity crunches happened, and these high bids actually started competing with each other. As a result, customers could easily get 100 _times_ higher bill than they expected."

There was more to it than that, but I figure that's a good enough reference point.

Thank you for these improvements. It doesn't change anything, in terms of how much savings I can get by following the latest generations and exotic instance-types, but it does help with the reliability of my workloads.

It's been a huge benefit to me, personally, that I can provide some code that enables the potentiality of servers dying, with the benefit of 80% cost savings without using RIs.

This seems to ignore the fact that the prices are consistently low if you are tracking the lesser used instance types/regions, even when talking explicitly within AWS.

Why would that change?

Why do you think this?

“The whining is often just a (I don't want to say pathetic but, not socially adaptive) form of attempting social-belonging/bragging ("The movie sucked the book was better" hipsters == Look at me I read books, I don't own a TV, etc)“

It’s not incorrect like the rest of us. It’s incorrect in a very different way.

Providing detailed information on the usage of a service that has never existed is a brand new kind of incorrect that is carelessly causing the rest of us grief.

very well said

sounds uninformed. i'm sure this opinion will change with experience.

I really appreciate the passion of this person.

I truly hope they can feel proud, without any guilt.

“A move away from monolithic statically compiled binaries to constellations of microservices (usually bloated docker containers) is a significant part of the problem.”

Untrue, in every way.

Why did you say this?

Always nice to have new players in the space, but that gap isn’t even addressed here.

Same old problems with configs/secrets, integration with internal/external services, and the details required by your cloud provider.

This is the sort of solution I have regularly been hired to untangle, after a company entrenches itself.

I agree with you, but I wanted to add this stupid detail into the conversation:

USB-C doesn’t ensure that you have any of these features. It’s just the style of connector.

You can have best-of-breed USB with any connector type you want, but obviously the most current hardware is using usb-c.

Not really relevant, but I know, now, to not have any expectations based on the fact that I’m using usb-c.

I would be focused on trying to simply run your workloads on your own.

It can be with EC2 or on your own physical/virtual Linux machine, but it should involve the required databases, the various components (e.g. your front & backends,) and some way of providing access (it could just be the option address and a port at the start.)

Lastly, figure out what it looks like to update code safely.

Afterwards, you should have a pretty good idea of how you can leverage cloud services to enhance or replace aspects of this, but will be dependent on none of them.

I can’t imagine that you’ll get this valuable perspective from any available course.

It was popular, but it has always been someone’s choice to start from someone else’s flat base.