Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
I'm curious what other peoples realworld workflows are like.

For instance, do you work from a text editor editing cloudformation templates and then run an aws cli command on your laptop? Do you have an ssh bounce host? Do you use the web interface on a day to day basis? How do you really deeply browse/survey/crawl an account to make sure you haven't accidentally left some rds instances running in brazil for a month?

Adbot
ADBOT LOVES YOU

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
thank you. I guess I don't even mean as much from a cost perspective as a "sprawling long tail mess" perspective.

every AWS account I've inherited or jumped into has been riddled with things like s3 buckets nobody knows if they're still in use, iam roles likewise, lambda functions with similar names from when they were trying to get it working, etc etc.

how do you ride herd on this stuff programatically? like I've been trying to clean out my account and start from scratch (its just for labs anyway) and a week later i'm still stumbling on little things in random corners from years ago (ssh keys you've long lost), and I was never even a really active user.

is there like an "aws dump all" or an "aws reset account to scratch --dry-run" type way of auditing all the things? (not in like a logs/security audit but in like a dead-code-path audit sense).

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
if you were launching a node app today: ec2 instances, elastic beanstalk, or ecs?

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
welcome to devops, the next step is to pick your self medicating poison of choice

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS

Volguus posted:

I totally will hire a devops whose job will be solely to deal with this poo poo.
god dammit

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS

Volguus posted:

What did I do? Or say? Or ... how wrong was that sentence?
developers making messes they can't maintain and throwing the problem over the wall to the systems/ops people was the exact problem "devops" was invented to counter.

saying "i'll just dump this mess on a devops janitor" is the perfectly distilled essence of not getting it and using a buzzphrase exactly 180 degrees backwards

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS

Volguus posted:

me, the developer, architect, tester, build and release manager
...
I would be very happy to not have to touch AWS
yea man we all want to be the ideas guy and not have to do the work

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
speaking of eks... is it ever going to happen? did something go horribly wrong in the beta?

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS

Startyde posted:

Devops is just sysadmins that got tricked into release engineering but accidentally the whole infrastructure. It’s burn out zone staff reduction.
to me the fascinating thing is that this looks like an early example of a broader pattern. I think the sysadmin+rel-eng+qa -> devops role-compression is a symptom of "automation". the pattern goes like this: the more powerful the tooling becomes, the more complex it becomes to operate. that causes a filtering affect on peoples technical-aptitude/complexity-tolerance that bifurcates labor into ~20% that adopt a new "paradigm" (devops) wherein they do 2 - 10x more "work" by leveraging automation, and the bottom 80% (sysadmins/etc) that are lucky to see a cost-of-living raise for the rest of their careers, if not outright laid off.

I think we will see the sysadmin->devops pattern play out through the not-tech economy over the next decade or two as "automation" crosses over into the physical world. Its not going to take peoples jobs, its going to squeeze the ever living gently caress out of them for a decade first.

https://www.youtube.com/watch?v=ym64NFCWORY

quote:

The coming bubble pop and rush back to the warm bosom of CapEx and colos is going to be thunderous.
this seems beyond wishful thinking

StabbinHobo fucked around with this message at 03:44 on May 2, 2018

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
start here: https://acloud.guru/learn/aws-certified-cloud-practitioner

after that they should still probably do one of the 'associate' level courses that come next, but for $100 everyone can just start with 'practitioner' and try to plow through it before the end of the quarter.

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS

Blinkz0rz posted:

I've never had a problem with the remote state loving itself
lol

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
the halfassed way is you take the acloudguru video courses and you just don't go back through them a second/third time when you score lovely on the mock tests, and then you don't take the real test. its the same videos/labs either way.

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
move your postgres db to an rds instance with 2x the power of your home machine
then put your python code on an ec2 instance with 2x the power of your home machine

run it as-is, see how you like it. did it get 4x faster? probably not, but at least now you can look at some graphs and see which side was bottlenecking.

there's a hojillion things you can do from there but anything beyond the above is getting ahead of yourself

oh and make sure to turn the instances off when you're done.

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
this is out of my rear end but i base it on the 80/20 rule, aka 4:1

your hire your first four devs and then one person who's a 'backend type' thats also handling the infra poo poo

then you hire your next four devs and your first "devops" person

then you hire your next 8 devs and a pair of SREs

then your next 16 devs and an architect, a security person, a manager, and jr sre/devops type.

after that... well gently caress if I know, usually you just dive straight into fulltime middle managmeent meeting fest stalemates by then.

StabbinHobo fucked around with this message at 06:11 on Dec 11, 2018

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
keep in mind that only works if the dev side are the first tier for the oncall rotation and they're reasonably self disciplined about "don't add a new loving toy for every project" engineering.

edit: vv 100% agree, aggregate saas and paas solutions as much as possible before you touch iaas

StabbinHobo fucked around with this message at 21:45 on Dec 11, 2018

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
you were clear rats, agrikk just misfired his hot take pistol

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS

Cancelbot posted:

Architectural one - We had an argument today of whether or not we should have environment based transit. For context: the developers have to provision a "mainline", "staging" and "live" environment by having a VPC for each per region they want to be in (so more often than not teams end up with 6 VPCs for 2 region redundancy) this adds headaches as theoretically it also means a pair of VPN tunnels per VPC-Region if they want to hit our on-premise infrastructure and a hell of a lot of NAT gateways.

We're partway to a solution by having Transit VPCs span everywhere so everyone can share the NAT, Internet, and VPN tunnels through one account, but would you go a step further and split the transit into a "mainline", "staging", "live" set of transit gateways? In the end it's all the same address space and due to how hosed our on-premise network already is QA is already visible to Live and vice versa, save for security groups locking this down; plus there's the risk of someone just smashing the transits all together in their account and giving a giant middle finger to routing.

However it could mean we get a bit closer to some network sanity by actually segregating poo poo and allowing for the networking team to try things out which doesn't bring every conceivable environment down. One argument against this was our switching & routing on premises isn't segregated physically so why would we do it in AWS?

if you do this please tag the vpc "area: 0"

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
if you're ever bored, this talk about how aws vpc networking works is really good:
https://www.youtube.com/watch?v=Zd5hsL-JNY4

its mad old now, but like its basically the step by step story of "why we had to do this and how we did it"

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
if you're starting greenfield on a single-aws-account setup whats the right ci/cd pipeline setup for IaC/cloudformation work?

i'm amazed at how many half baked blog posts from 2017 there are and then... nothing.

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
the only useful info in those answers was "hasn’t changed for like 3 years" (and therefore I should probably just follow the old blog posts).

Adbot
ADBOT LOVES YOU

StabbinHobo
Oct 18, 2002

by Jeffrey of YOSPOS
goddamn yall love to post a lot of words without reading

i did pick a tool. i named it in my very short and specific question.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply