Weekly curated: 2021#33

This week, I’d like to share a news article about a npm package-name takeover. It opens quite a perspective about the security of npms (and others) package repositorities. Then, I’d like to share a podcast about choosing the right tech stack for a greenfield project. Even though you might not start a new greenfield project soon, the podcast consists of an interesting discussion and evaluation of various tech stacks, while not being biased against any tech. Then, a decent article about the difference of DevOps, Site Reliability Engineer and Platform engineering by Ivan Velichko. Also, an article by Corey Quinn about why Lyft is smart to Pay AWS $300M for 3 years of service.

GitHub’s npm gave away a package name while it was in use

It’s certainly not news that unpublishing packages or malware is found in npm packages. And it certainly is not unique to the JavaScript ecosystem. But this incident is a bit different and quite interesting as GitHub’s npm team gave away a name for a package that was – seemingly – dead because the registry had a wrong e-mail address for the owner of the package and therefore could not contact the owner. On top of that, the policy basically was to just give the name to another person if the currently owning person is not able to respond within a few weeks. The DotNet Foundation has a similar proposal currenly open.

I think such issues open a view on a broad set of questions like how uniqueness of a package name is defined – is it unique for now or unique forever? When should a project be considered dead – like moment.js which had its last release back in October 2020 but is still widely in use. And as todays code more and more consists of transitive dependencies, such issues might have even broader impact than visible at first.

You can read the full story at The Register.

Podcast: Choosing the right tech stack for a greenfield project

A question that I was required to answer several times in the past few months: What tech stack to take for a greenfield project? This podcast from Software Engineering Radio talks with Jason Meller about modern tech stacks accross a variety of programming languages and when and why to consider (or to not consider) them for a greenfield project.

I personally like how Jason answers the question of „Why this language?“ with the reasonable answer „it depends“, and then continues to go on to explain what „depends“ actually means and what to consider when choosing a tech stack for a new project. Additionaly, he tells a lot of details about various companies that succeeded with a seemingly „wrong“ tech stack and reasons about what actually matters when choosing a tech stack.

You’ll find the podcast on the website of SRE, or on various platforms like Apple Podcasts or Spotify.


DevOps, SRE and Platform Engineering

Ivan Velichko wrote a blog post about DevOps, SRE and PE and his personal experiences about those three jobs and their differences. I, sometimes, find the differences and similarities of those jobs consuting and he does a good job explaining it in the way he experienced it. He concludes that in his experience those three jobs become more and more distinc with the size of the company and if one works in a smaller shop, he (probably) will do more than one of these three roles.

You can find the whole blog post on Ivan Velichkos blog.

4 reasons why Lyft is smart to pay AWS $300M

Yes, 300 Million USD is a lot and that’s what Lyft commited to pay AWS between 2019 and 2021. That’s roughly 8 Million USD each month. Corey Quinn, the go-to guy for stuff related to your AWS bill, gives quite an insight in his blog post about why it is reasonable for Lyft to pay this amount and gives four reasons skeptics might bring up.

Breaking down the four reasons: (1) It’s smart to pay someone to maintain a datacenter instead of doing it itself – there’s more time for the core of the business (which is not replacing failing disks in servers). (2) It is not that much money compared to other spendings of a company – sure IT costs have increased over decades but it also brought a lot of value to everyone involved in the value stream. (3) Nobody could save a larger part of this money by changing anything. And besides that, for a company that is not even profitable and solely focused on growth, saving money is not the primary concern. (4) There’s no way nobody at a company valued 26 billion USD did never think of checking whether this amount is reasonable.

You may read the full blog post at Coreys Last week in AWS blog.

Leave a Reply

Your email address will not be published. Required fields are marked *