CDK outputs CloudFormation templates that you can pass to any other tool if you wish. CDK is technically just a glorified shim over CFN (although 1000x better but you do get caught in the awkwardness that is CFN many times).
It does, but very indirectly which defeats the point of "just emit YAML". I regret phrasing it that way as it seems to have caused a lot of confusion. See my responses to sibling comments for more information.
If anyone notices a problem you'll likely need to write a COE, there's no way to get around that. Not updating the status page absolutely doesn't get you out of that task.
COE also doesn't lead to negative marks on anyone at AWS that I know of. It's a learning experience to know why it happened and action items so it doesn't happen again.
Companies usually like to downgrade when hiring. Amazon does it a lot. So even if you qualified as an L7 they may hire you as an L6 (sometimes with L7 pay) and you need to go through a promotion cycle to get back to L7.
This just isn't possible. No company in their right mind would take their monolith and rewrite a bunch of stuff just to please a couple randoms on the internet.
I think you're drastically underestimating the amount of code Github is powered by and how freaking long any type of refactor/rewrite would take. We're talking about years.
Oh, was Github monolith? I did not read any articles about their architecture so I assumed that Github could be composed by micro services, and in that case, splitting could go easier. I edited to "If Github was made with micro services architecture,..."
Does anyone have link to any interview or article talking about granularity of their architecture?
Reading Github Engineering blog posts related to their architecture. https://goo.gl/amkJfV As far as I read so far, Github looks like composed of micro services, or at least split into many distributed services.
Github has been a well known Rails monolith. Absolutely they have services that power all sorts of stuff (they have a few blog posts on it) but it's just impractical to even start a discussion on splitting it up for the reasons you initially argued for.
I've been through a number of large rewrites/reworks that took monoliths much like Github (with many many many services behind it) and split them up into modular pieces and it's an insane amount of work that can take years. You simply need very good reasons (including business reasons) to do that.
Moreover, companies at these sizes just have a LOT of code all over the place. Tooling, infra, supporting services, etc... Not to mention it's just not useful to have external contributors for a business product like Github. Doing code reviews, addressing bugs that were introduced, spending time discussing things with contributors takes an incredible amount of time.
Basically if the reason you want Github open sourced (and reworked into some weird architecture you described) is so that people can contribute to fix things and add features....Github could/will just hire more devs to work on that.
Thinking about the fact that Github have Github.com (production service) and Github Enterprise (self hosted), could it be like this?
Github.com = Github Core + Production Services and Infra
Github Enterprise = Github Core + Services need for Self Hosting
Maybe it's not worthy to proceed based on assumption but if there is something like "Github Core" which is shared codebase between prod and self-hosted, open sourcing the core can be an option?
Thanks TheHydroImpulse for the insights. So Github IS monolith. It really makes sense that splitting is too much work for just open sourcing and I do not see business gain to invest money and people into it.
Then possible path might be isolating least coupled (and small) components of client side code and open source?
when you have to manage a large number of services with a bunch of different devs touching things, Docker is almost required to get a consistent development state.
There's literally nothing wrong with reaching for Docker right away. It allows you to have the same, repeatable development environment. Maybe you deploy to production without Docker, but any project I start I'll reach for Docker right away.
As someone without a degree, getting an interview at the Big 5 was quite easy. Passing those interviews is another thing entirely but having the right experiences in your resume has been more important in my case.
That's the thing, right now, I don't really have the "right experiences" that's why startups do seem appealing.
I have the skills people are looking for but not the resume validation with internships, the right degree, or school. I got an internship at the start of my intensive where I got to work on some fun problems and used my marketing skills too.
I think the only other track would be through open source contributions. If we circled back in December or January, I wouldn't be surprised if I ended up at a non-tech SMB, small consultancy, or startup because of my prior experiences in marketing paired with my new SWE skills.
Something I was wondering, in your experience or anyone reading, do I have to always focus all the technology stacks for each role and project or can I focus more on the problem I solved?
For example, in my internship, for one problem that made a big difference was setting up all their email automation and tieing it into their website. That project wasn't a ton of programming but my work; but by the end got them about $150k in revenue with my other work on their Black Friday sale, as an intern. Most of the SWE projects I got started but wasn't able to finish in the 3 months (priorities kept changing) like a tool that converted audio from videos into searchable indexes for their youtube videos (granular text searchable video basically). I'm hoping to redo that project on my own. I did get their website to speed up though (an older WordPress website).
Absolutely focus on the problems you've solved, and also the problems you failed to solve after getting deeply involved in them.
They know that you'll have to learn their proprietary technology stacks, which are always both ahead and behind the public stacks they inspired. At some companies they won't ask anything about your resume keywords after the phone screens.
Most Big 5 companies use what's called "Behavioral Interviewing" or "S.T.A.R." to formally assess how you get stuff done, and the technical questions can be answered in almost any language you like. Hell I've given successful answers to Big 5 "tell me about a time when you had to…" questions based on experiences in bicycle manufacturing and nonprofit administration, but it really has to involve ownership if you're straying from the norms.
I'm good at "S.T.A.R.", most of my effort in the past is using CAR and PAR but it's not a hard shift. I'm glad to hear they don't limit it to just technology problems.
>"the problems you failed to solve after getting deeply involved in them".
I have done it before in interviews when asked about weaknesses or failures; I've never done it on a resume though. How would you go about representing that on a resume?
I think this might be true if your lucky I was up for a FANG position in London but I have an atypical education I I suspect my lack of a degree counted against me.
With the best will in the world some low level recruiter working out of Spain is not going to be able to read between the lines and work out that actually working for a world leading RnD org on campus at one of the elite UK universities might actually mean I was a good candidate.
I'm like you, I've got some really niche experiences. I went to a #1 program at an arguably #1 school for undergrad for the industry I was planning on going into. I also have a unique personal background (extensive life-long travel) which has been helpful in more than one way but it's hard to see that on my resume.
L3 at other companies is an L4 at Amazon (I believe only contractors or part-time employees can be < 4). L5 also has a much wider surface area and the gap from L5 to L6 is quite big.
NSQ has been (IMO) far far easier to operate than Kafka has been. With Kafka you need a Zookeeper cluster in addition to your Kafka brokers. Not to mention developing against NSQ is pretty simple whereas Kafka you need to think about partitions and offsets.
If you're worried about data loss, Kakfa can be what you're looking for (but takes a lot to learn how to operate it correctly).