[HN Gopher] General guidance when working as a cloud engineer
___________________________________________________________________
General guidance when working as a cloud engineer
Author : lockedinspace
Score : 39 points
Date : 2022-12-25 21:13 UTC (1 hours ago)
(HTM) web link (www.lockedinspace.com)
(TXT) w3m dump (www.lockedinspace.com)
| mustafabisic1 wrote:
| Some solid career advice in there as well.
|
| I feel like this could used as one of those "How to 10x career"
| articles - and be better than all of them.
| elric wrote:
| > Certify yourself with official courses.
|
| Can anyone recommend some certifications that are worthwhile? I
| realize that this is a very broad ask, but the advise is also
| rather broad.
| WolfOliver wrote:
| "Microservices should only perform a single task." -> I guess
| this advice is the reason there are so widely misunderstood, see:
| https://linkedrecords.com/challenging-the-single-responsibil...
| adamisom wrote:
| Wow and I thought _functions_ should only perform a single
| task. I need to keep up with the times! Apparently you need an
| entire deployable app and API to do anything these days. I
| guess it makes sense. How else could we justify so many
| software engineers!?
| elric wrote:
| So many? Last I checked there was a huge shortage, and with
| the exception of a couple of notable bloatware companies,
| most seem to be understaffed?
| lockedinspace wrote:
| A helpful list of things to have in mind when working with
| anything tech related.
| martynvandijke wrote:
| Nice guide, just curious are there more of these guides ?
| myfirstproject wrote:
| > Git should be your only source of truth. Discard any local
| files or changes, what's not pushed into the repository, does not
| exist.
|
| Completely agree with that.
| nijave wrote:
| >Before jumping straight into a new technology, read and
| understand their docs
|
| The number of issues I've seen that turn out to be documented
| features... (or, more accurately, things just being configured
| incorrectly)
| pondidum wrote:
| > Do not make production changes on Fridays
|
| I ~hate~ dislike this advice. If you can't deploy on a Friday,
| you need to fix your deployment strategy. By removing Friday from
| when you can deploy, you're wasting 1/5 of your available days.
|
| Note: deploy != Release[1]. Use flags, canaries etc.
|
| [1]: https://andydote.co.uk/2022/11/02/deploy-doesnt-mean-
| release...
|
| Edit: hate is far too stronger word for this
| dopylitty wrote:
| This one made me laugh. I've been places that only allow
| deployments on Fridays because it gives the whole weekend to
| fix things if they break.
|
| It's a good interview question as a candidate. If you ask the
| interviewer when they deploy and they say only Friday (or worse
| only once a month) then perhaps look elsewhere for your own
| sanity because it's a sign of serious malfunction either
| organizationally, technically, or both.
| fragmede wrote:
| * * *
| kevan wrote:
| I'm a huge advocate for CI/CD pipelines and my team owns a lot
| of them. We're confident enough to deploy anytime but we choose
| to limit deploys to our team's business hours and not on
| Fridays. Why? Because we think the return going from deploying
| 4 days/week to 5 days/week is outweighed by the stress and
| morale hit of ruined weekend plans if something weird happens.
| There's probably situations where that extra speed makes a
| difference but for us deploying to all regions safely can take
| a full day anyways so it's pretty normal to have multiple
| changes flowing at the same time.
| elric wrote:
| Hating it seems a little strong. I'm sure that any team far
| along enough on the quality spectrum can just read this and say
| "we've moved beyond this worry". The post is titled "general
| guidance", not "absolute truths". Adjust expectations
| accordingly.
| pondidum wrote:
| You're right, hate is far too stronger term for this, I've
| updated the wording. Thanks.
| Sevii wrote:
| The point of not deploying on friday is to reduce the risk of
| getting paged over the weekend. It's a quality of life move for
| the oncall team. No deployment strategy will change the fact
| that deployments are the leading cause of outages.
|
| If you can't afford to give up 1/5 of your available deployment
| days you have a problem somewhere in your CI/CD system.
| nijave wrote:
| Sure but ideally you have high enough confidence in your
| software that those types of issues are highly unlikely.
| lopatin wrote:
| Interestingly my company _only_ deploys on Friday because it
| has to wait for (most) markets to close for the weekend.
| kator wrote:
| Don't forget "pets vs cattle", thinking of servers as ephemeral
| and working towards quickly being able to scale up/down based on
| demand. So often I see people "lift and shift" from a dedicated
| server model into the cloud and never convert their pets into
| cattle. This reduces flexibility later, not to mention makes it
| harder to respond to patching needs, scaling, and moving to
| optimize latency or costs.
___________________________________________________________________
(page generated 2022-12-25 23:00 UTC)