|
Reasonably new to cloud native design stuff - wondering about a proposed setup. We have a tool that's going to be used sporadically (during certain types of events only) - we wanted to design it as a webapp as a reasonably straightforward DDB backend, with the frontend basically delivered as a static file that calls to various lambdas for dynamic content, using Flask on Lambda to handle calls to the DDB backend for reads/writes/etc. Is this setup going to be able to deliver anything near acceptable performance, or is the startup/ephemeral nature of lambdas going to be a problem? My fallback plan is going to Fargate or something for a container, or otherwise just setting up some sort of containerized server. Falcon2001 fucked around with this message at 19:17 on Jun 22, 2022 |
#
¿
Jun 22, 2022 18:27
|
|
|
|
| # ¿ May 22, 2024 09:16 |
|
|
Agrikk posted:Sometimes the obvious solution can also be the cheapest in the right circumstances. If you have times when the tool is active and times when it isn’t used at all, you can save a lot of money and complexity by building a container or even an EC2 instance that points to your back end. In this case, the problem would be that it's a service that needs to work very quickly when we need it to - basically for realtime response stuff, otherwise I'd agree that's a pretty good approach. For the others, it sounds like the idea is at least sane enough to get up to the 'testing' phase. 'Acceptable performance' mostly meant 'Is the latency going to be high enough that a user would find the delay irritating' and it doesn't sound like there's a significant problem here.
|
|
#
¿
Jun 22, 2022 23:34
|
|
|
MightyBigMinus posted:its not engineering if you're not using numbers This is totally fair, but I'm also describing things that I don't have clear measurements on. This is a tool used during response to certain types of incidents; based on past experience I expect to use it 6-12 times a year for a few days at a time, but you can't predict incidents, so I'm trying to make sure it's at least somewhat scalable. By 'acceptable', I'm trying to ask 'is this going to deliver a level of responsiveness that humans won't find to be weirdly slow or stilted'; I don't have a lot of frontend experience so web user experience stuff is something I don't have a ton of experience on yet, so I'm not sure what the right term would be. CarForumPoster's response covers it though; basically I just wanted to check if my entire design was fundamentally flawed from the get-go, and it doesn't really sound like it.
|
|
#
¿
Jun 23, 2022 04:27
|
|
|
Docjowles posted:For my money it’s some very basic info on how networking and/or dns work. I’ve had some absolutely I've worked at huge tech companies and I can confirm that the number of senior devs who believe that network is basically magic is concerningly high. "I think we need networking." "Alright, what's the issue you're seeing?" "Uh...I'm getting errors." "What kind of errors?" "HTTP 500 errors." "I don't think you need networking."
|
|
#
¿
Jul 12, 2022 02:46
|
|
conversations with senior devs where you suddenly realize that what they’re trying to explain only makes sense if their world view about how two computers communicate is totally and fundamentally broken.
|
Docjowles posted:Yeah this is the level of detail I am talking about. I am not asking devs to pass the CCNA. I would be elated if they understood the significance of an IP address that starts with 10.x and one that doesn't. What a private vs public subnet means in AWS. And, yes, the significance of a DNS lookup failure. Not even how to troubleshoot it, just that it's a distinct failure mode. I don't feel like this is "embarrassingly condescending and patronizing" at all, devs I've worked with across several companies struggle with this. *Yup*. Like the amount of networking knowledge needed to run a service is not that much. But it is greater than most devs know about as far as I can tell.
|
|
#
¿
Jul 12, 2022 05:31
|
|
|
Docjowles posted:Tbh this is every business. Everyone thinks they are a snowflake. Never worked in law but I’ve dealt with plenty of cases of “well I know there is a free open source solution that does 98% of what we need. But it lacks this one specific feature so gently caress it we’re building our own from scratch!!!” And you get the one feature but it’s significantly worse in every other way. Plus now you’re stuck maintaining some bespoke piece of poo poo forever that you can’t just Google answers for when the guy who wrote it leaves. On the other hand, is there anything worse than 'The solution that we picked without consulting you doesn't do $VeryImportantThing, so your new process is going to be 50% manual and 50% in this new system"
|
|
#
¿
Jul 14, 2022 20:23
|
|
|
I think it's probably more important to make sure you hit the parts of STAR instead of forcing yourself into a routine/form letter style thing. Just make sure you don't rat-hole too hard on any one thing and you get all the bits in there and you should be fine. Like, just make it clear what the task was, you don't have to say 'my situation was THIS, my task was THIS' - just make sure you don't skip over any of the things while telling your awesome story about the time you did a thing. FWIW - Nthing the LPs stuff. It's pretty interesting coming from another big tech company how important the leadership principles are at AWS, and how...internalized they are? It actually gives me some minor hope that AWS might fix some of the weird rear end Bezos stuff once they start internalizing the newer LPs around not being terrible. But I do work around outages, so the adherence to customer obsession/etc lets my team get poo poo done that's important, because the main part of our work is all around having less, better run outages. At other companies it's been much harder to get them to give a poo poo about outages and proper operational excellence stuff, and I'm really impressed by AWS at least.
|
|
#
¿
Jul 30, 2022 22:52
|
|
|
i am a moron posted:I looked at Levels and Glassdoor and it didn’t seem like it paid that much tbh. But I might not be looking at the right stuff. The recruiter sent me a news story about AWS doubling salary limits. So basically Amazon used to have a salary cap of $160k for literally everyone. Everyone who made more than that made it in stock, which is pretty similar to a lot of tech companies (MSFT had a similar system but no set cap that I was aware of). Obviously stock keeps you invested because you're leaving cash on the table if you leave the company. But on the other hand, it's just delayed pay(handwaving stock volatility/etc), and a starting bonus can make up significantly for the delay. But definitely make sure you're looking at total comp instead of just base salary, because a lot of folks at tech companies make way more than their base salary in stock awards.
|
|
#
¿
Aug 12, 2022 22:35
|
|
|
Just did a little over a year at AWS and am leaving my current team for Amazon retail, because my org had some serious problems that were pretty anti-Amazon stuff (took forever to decide stuff, no clear goals, etc). But I didn't dislike AWS as a whole, for what it's worth. I worked a lot with high availability stuff, and working in an org where nobody argues about why uptime/availability is important was pretty great. OTOH: I'm starting to get a little tired of working at job after job where there's always like 200% workload and you're constantly dealing with manual toil bullshit you don't get time to automate away. I know that's not unique to big tech, but it feels like it might be endemic there. Blurb3947 posted:How'd you guys get your start at AWS? I'm almost a year at my current org doing some light cloud and software support, but want to do more AWS. Have the Cloud Practitioner and want to get the SAA ones and probably SysOps. I'm one of the lucky stories about self-taught devs. I work in a niche field, and at Amazon they want people with that discipline who are also developers, so I was able to argue my way in the door pretty easily because most of our candidates either had that niche experience OR were devs, but very few who could argue both. Harriet Carker posted:A year and a half at AWS now, mostly really happy. Yeah, my RSU value has gone in the tank but the first two years cash bonus is high enough that I barely care. After the two year mark I'll have to reevaluate. But overall the work/life balance is great (YMMV) One really nice thing about AWS for me was that a lot of teams had a follow the sun setup, so you mostly aren't having to get sleep interruption. That's a huge quality of life thing for folks that haven't worked 24x7 oncall at a big company with a large oncall burden before. For me it was the first time in over a decade I wasn't working graves or oncall. Still had some weekends, but that's an easy trade compared to overnight work for me at least. I pretty consistently worked 40 hour weeks outside of a few weird events, and I had TOIL days (time off in lieu) for working weekend shifts/etc, so I'd get a weekday off. The workload was way too high, but at least I wasn't being pressured to work 60+ hour weeks to deal with bad management decisions.
|
|
#
¿
Nov 4, 2022 19:01
|
|
|
jaegerx posted:Aws has a hiring freeze as I understand it. From what I've read publicly, I don't believe the hiring freeze is a full one - backfills I think are still open for now.
|
|
#
¿
Nov 5, 2022 02:39
|
|
|
Agrikk posted:I showed up with literally zero cloud experience of any kind. But I did have a fifteen year history of building virtual patterns in data centers so I was able to parley my architecture knowledge into AWS services during the interviews. Yeah, our interview methodology doesn't say you have to be familiar with AWS services necessarily, more that you need to be able to think at the scale AWS operates at. It doesn't matter so much if you're using the buzzwords.
|
|
#
¿
Nov 6, 2022 07:57
|
|
|
Thanks Ants posted:Can AWS employees still use Slack or is everybody being forced to use "Wickr" now? Still Slack unless that changed in the last week or so. You can't shift an org the size of AWS over to new tooling for stuff like collaboration quickly.
|
|
#
¿
Dec 3, 2022 22:14
|
|
|
Yeah it's still a bit of a pain in the rear end (Does this channel exist and private, or does it not exist at all? WHO KNOWS) but I think I'm not much of a Slack poweruser. I'm sure the team running it is overloaded though. Still way better than Teams.
|
|
#
¿
Dec 17, 2022 21:50
|
|
|
necrobobsledder posted:loling that people are on a big company-run Slack and complaining that they can't create actually private channels. My company essentially says Keybase should be used for private comms as a best practice rather than to use Slack if it's that important. We're open by default but also expect people to be sensible and not shitpost hard on the drat company Slack. Company lets people link to outside Discords and Slacks that are even ex-employee run and let people be idiots there if anything. Not saying we're some benchmark standard to go with but this doesn't seem like rocket science to me. Yeah to be clear my complaint isn;'t 'oh no my slack channel isn't actually private' more like 'people create private slack channels and then expect people to be able to find them', because Private breaks both discoverability and access, and in my experience most people actually care about the access restriction and don't really give a poo poo / actively dislike the behavior of the discoverability changes.
|
|
#
¿
Dec 19, 2022 04:12
|
|
|
Blinkz0rz posted:The intent is kind of in the name, isn't it? Sounds a lot like PEBCAK imo. Sure, if there was a separate thing you could do that was just access, then yeah, but there isn't. That's more of a Slack problem than an implementation one, fwiw.
|
|
#
¿
Dec 19, 2022 17:00
|
|
|
duck monster posted:Our new baby project manager just tried to submit to the boss an architecture plan based almost entirely on ARM vms. Thankfully I intercepted and explained to the kid we are NOT going to move our infrastructure from a kubernetes cluster to a bunch of virtualboxes running on raspberry PIs (or however the gently caress those amazon arm ec2s work), and to seriously rethink the plan before the boss does a boss and fires him. EKS is good. EKS is nice. EKS works, lets not fix what isn't broken, and most importantly lets not abandon the grand plan of "all VMs must die", if it aint in a lamba, docker/k8 container, or in strict "we just wanna test it on a temporary vm" , it stays off my loving cluster. Can't you run EKS on ARM instances? If he's got such a boner for 'em figure that'd be an easy place to start and might offer some savings, depending on what that looks like.
|
|
#
¿
Dec 21, 2022 06:36
|
|
|
Docjowles posted:I've only used QuickSight to deploy the CUDOS cost dashboards but it sucks enough to make me wonder why it exists. Are there real people who evaluate it next to any other BI product and go "gently caress yeah we gotta have this"? It's fairly cheap I guess if you have minimal requirements. I think this is a thing that people going through simple tutorials go 'why is this here it's just some weird added extra layer between my app and the data, like the American health insurance industry! I'll just skip it!' because in a simple tutorial your frontend is just like straight up passing stuff to the DB and isn't doing much.
|
|
#
¿
Jan 12, 2023 18:37
|
|
|
Docjowles posted:Yeah we actually do all of this stuff too. https://pre-commit.com makes sure various linters run before poo poo even gets committed, let alone to the code review stage. Pedantic assholes arguing about the number of spaces or whatever is such an obnoxious waste of time, just make a tool enforce it. Nthing this; pick a linter and force compliance in CI for basically any language; if folks want to argue about the right formats to use, agree as a team and setup your CI to use it (like PEP8 for Python says 80 char lines, but line lengths of 120 is perfectly reasonable. The rest of it should really be consistent with a given style guide used by whatever linter you're using)
|
|
#
¿
Jan 29, 2023 05:54
|
|
|
Pile Of Garbage posted:Have to admit I just did that recently for a new cloud-native environment. Put everything in Azure except for the public DNS zones which I put in AWS R53 because it was just easier. I love poo poo like this because I know this is keeping some PM up at night going 'our data shows someone is using all Azure *except for DNS*' and he can't figure out why.
|
|
#
¿
Apr 27, 2023 04:24
|
|
|
I think it's hilarious how it's like 'hey I want to send an email from server x to email address y in the same domain' 'Oh that's pretty easy, just boop beep telnet and you're good!' 'Oh great! I want to send that email to a hundred people on gmail now'. 'You'll need a multinational corporation and two ritualistic sacrifices'
|
|
#
¿
May 21, 2023 18:38
|
|
|
mondomole posted:AWS is exceptionally good about backward compatibility so this may not be a good stick. Yeah, for the most part your EC2 instance getting ransomware'd isn't Amazon's problem, that's your problem. But uh...it is a problem. Go find some particularly juicy ransomware stories and start trotting it out every time someone balks at migration plans.
|
|
#
¿
Jun 17, 2023 08:08
|
|
|
mondomole posted:I found a better stick. Here's an article by a law firm claiming that running EOL Windows may violate article 32 of General Data Protection Regulation (GDPR). Ransomware is probably too theoretical / low probability that C suite may end up ignoring it, but GDPR violations have heavy fines and they are enforced relatively quickly. Plus, once you've mentioned GDPR compliance in writing, they probably don't want to be dismissing that in writing either...That said, the argument that EOL Windows should violate GDPR feels a bit weak to me, but I'm also not a lawyer. Hell yeah, get 'em. Lord knows we need more good reasons for businesses to actually keep up with poo poo.
|
|
#
¿
Jun 17, 2023 23:43
|
|
|
Docjowles posted:I am in no way advocating this but a lot of companies just give the bare minimum lip service to security and privacy. Because the cost of actually doing it right is less than just paying a fine and eating some bad PR if/when a major breach occurs. I mean it’s not like Equifax or Target went down when they had massive incidents a while back. Not to get off topic too hard, but the part about this that irritates me the most is how much this fucks with the ability for teams to plan, because ignoring stuff like this just turns into a crisis later on that suddenly comes into your office, sweeps everything off your desk onto the floor, and takes a poo poo on your desk.
|
|
#
¿
Jun 18, 2023 19:37
|
|
|
Honestly best way might just be deploy it and see what happens.
|
|
#
¿
Jun 28, 2023 07:58
|
|
|
|
| # ¿ May 22, 2024 09:16 |
|
|
necrobobsledder posted:Am in security and am a Cloud Guy and this is part of the pentest suites for discovery out there, so yes being predictable is probably a Bad Idea. Also yes, consider "prod" to be similar to using "password" in your passwords - they are directly being used in word lists as top priority right next to dev and stage. Nah, this forum's significantly older than Markdown's rise to prominence, you're not missing anything.
|
|
#
¿
Aug 5, 2023 21:41
|
|