• 0 Posts
  • 59 Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle
  • I manage a stack like this, we have dedicated hardware running a steady state of backend processing, but scale into AWS if there’s a surge in realtime processing needed and we don’t have the hardware. We also had an outage in our on prem datacenter once which was expensive for us (I assume an insurance claim was made), but scaling to AWS was almost automatic, and the impact was minimal for a full datacenter outage.

    If we wanted to optimize even more, I’m sure we could scale into Azure depending on server costs when spot pricing is higher in AWS. The moral of the story is to not get too locked into any one provider and utilize some of the abstraction layers so that AWS, Azure, etc are just targets that you can shop around for by default, without having to scramble.








  • If your services are not stateless, work to make them such so you can learn about scaling in the cloud, which can even be done w/ VM-based services. how much more agility using cloud vs a DC gives you

    This can’t be understated. Embracing elastic idology to remove single points of failure and decoupling stateful aspects of applications has been the biggest takeaway of being part of several migrations of services to AWS. Implementing these into your practices as you grow is a huge benefit that may is worth the cost.

    Over time, if the scale you’re operating at grows, using experience/knowledge from AWS and applying it to running services in a datacenter could be beneficial. In my experience, if you have a large, consistent, asynchronous workload which you’ve maxed out on reserved instances or savings plans, it is likely cheaper to operate on your own hardware than in the cloud (or get credits from GCP or Azure to migrate services to reduce costs). This is where avoiding vendor lock-in is key.

    have y’all factored in all the time/money spent on maintaining the server hardware, power, DC cooling, etc. too?

    For sure, this isn’t 2007 where you need to purchase servers and network equipment to start a website. For most startups and small businesses, operating in the cloud will be less expensive upfront and likely over the first 3 years. This isn’t a one size fits all approach though, and it’d be prudent to evaluate the cloud spend periodically and compare with what’d it’d cost to manage it entirely. Obviously you’d need a team competent enough to manage this, without it going to shit.





  • In my experience, I prefer to review or contribute commits which are logical changes that are compartmentalized enough that if needed, they could be reverted without impacting something completely differently. This doesn’t mean 1 commit is always the right number of commits in a PR.

    For example, if you have a feature addition which requires you to update the version of a dependency in the project, and this dependency update breaks existing code, I would have two commits, being:

    • Update dependency and fix issues because of the upgrade
    • Add new feature using new dependency

    When stepping through the commits in the PR or looking at a git blame, it’s clear which changes were needed because of the new dependency, and which were feature additions.

    Obviously this isn’t a one size fits all, but if someone submitted a PR with 12 commits of trial and error, and the overall changes are like +2 lines -3 lines, I’d ask them to clean that up before it gets merged.









  • Also not a lawyer, but right to be forgotten applies to search engines to remove articles from the search index. Originally applied to news articles some guy in Spain didn’t want showing up when you google’d his name. The law doesn’t require the publisher to remove the content from their website, but instead requires search engines to remove the links in results.

    So if someone’s comment was mirrored to Lemmy AND that comment was indexed by a search engine linking back to a Lemmy instance, then you still have the right to request Google or Bing or whatever to remove those links from search results via the same process.