Death by a Thousand Microservices  ## Metadata - Author: [[The Changelog: Software Development, Open Source]] - Full Title: Death by a Thousand Microservices - Category: #podcasts - URL: https://share.snipd.com/episode/d2a021ea-1702-4060-9b83-af7203517fd8 ## Document Notes ## Highlights - **Complexity Kills** - The software industry is rediscovering that complexity kills productivity. - Microservices, driven by VC funding and a need for rapid growth, often exacerbate this complexity. Transcript: Jerod Santo Okay, let's get into the news, shall we? Andrei Terenchenko says the software industry is learning once again that complexity kills. And he wonders, how did we get here? How did our aim become not addressing the task at hand? Instead, setting a pile of cash on fire by solving problems we don't have. He's talking about microservices, of course. And in an attempt to answer this question, Andrei takes aim at JavaScript and Node.js, which I tend to disagree with and may trigger you if you're of that ilk. But what he's really saying is this, quote, my point really was more about the dangers of hermetically sealed software ecosystems that seem hellbent on relearning the lessons that We had just finished learning. We ran into the complexity wall before and reset. Otherwise, we'd still be using core button soap. These airtight developer bubbles are a wrecking ball on the entire industry and it takes about a full decade to swing, end quote. He then turns his attention to the VC funded tech startup boom that only recently busted, saying, investors needed to see explosive growth, but not in profitability, no. They just needed to see how quickly the company could hire ultra expensive software engineers to do something. And now that you have these developers, what do you do with them? Well, they could build a simpler system that is easier to grow and maintain, or they could contra up a monstrous constellation of microservices that no one really understands. ([Time 0:00:40](https://share.snipd.com/snip/65a7f808-0537-49d9-b3e1-2eb3482f637e)) - **Unity's Pricing Change** - Unity's retroactive pricing change, from per-seat to per-install, shocked developers. - This change prompted discussions about alternatives like Unreal, Godot, and Defold. Transcript: Jerod Santo End quote. This post is salty for sure, but there's also a lot of level-headed reasoning that's worth your consideration. K.C. Muratore wasn't too surprised last week when Unity announced a retroactive change to his pricing model from charging per seat to charging per install. Quote, I do follow game business trends to a certain extent, and for well over a year now I've been warning that Unity's relationship with game developers would inexorably change for The worse. This was not based on any insight knowledge. It was based solely on the financials they report and the kinds of statements they make to investors in their earnings calls. The move by Unity sent shockwaves through the developer community, so much so that they have since announced they will soon be making changes to the new ([Time 0:02:16](https://share.snipd.com/snip/6cf5f47d-f92e-4522-9c96-190e1d00f4ce)) - **Homebrew CPU** - 19-year-old Filip Szkandera built Pineapple One, a functioning 32-bit RISC-V macro processor. - Built with discrete components, it demonstrates that building a modern CPU is achievable. Transcript: Jerod Santo Once again, that's this coming Wednesday, September 20th. Sign up now to get your questions answered. Thanks again to Sentry for sponsoring this episode of Change Dog News. Pineapple 1 is a functioning 32-bit, risk-5 macroprocessor built by a 19-year-old Philip Skandera over the course of two years. Quote, we chose to build a CPU only out of discrete, off-the-shelf components. You heard it right, there is no FPGA nor any microcontroller. There are just logic gates and memories. Our goal is to prove that designing a modern CPU isn't that hard, so we have released our schematics and made it open source. End quote. Philip calls this groundbreaking for homebrew CPUs and put together a great video demonstrating the hardware. Speaker 2 My CPU is fully compatible with the RV30s by standard, which means that it can use off-the-shelf compilers. So, anybody can make a program for this CPU very easily. This is groundbreaking for homebrew CPUs, because almost every one of what I saw used a custom compiler or just an assembler. With risk-5, we can achieve much more with much less components. And this is what I have demonstrated here. My CPU is built only out of discrete logic components and memories, so you won't find any FPGAs nor any microcontrollers on board. I managed to fit all that into this tower, which I don't think would be possible with any other popular architecture. At this point, it runs at... Jerod Santo Matt Bosta ([Time 0:04:15](https://share.snipd.com/snip/d2da759b-16fe-4e1e-a5aa-497abd0872d3)) - **Ephemeral Software** - Matt Basta built a web-based Excel clone at Uber, only to have the division sold a week later. - He shared the code and reflected on the ephemeral nature of software. Transcript: Jerod Santo Tells a fascinating tale of the time he single-handedly built a web-based Excel clone for the data scientists inside Uber, only to have the entire division sold to another company A week later. He learned a lot about how Excel works and shares some of the interesting bits, and he also has a super-healthy outlook on what happened to all his hard work. Quote, my first reaction was to publish the code on GitHub, which he did. My second reaction was to move on. There was maybe a part of me, my younger self, that was disappointed that this major piece of code that I labored over had been so gently used before being retired. I wasn't recognized for it in any material way. My manager didn't even know what I'd built. On the other hand, we as engineers need to be real with ourselves. Every piece of code you write as an engineer is legacy code. Maybe not right now, but it will be. Someone will take joy in ripping it out someday. Every masterpiece will be gleefully replaced. It's just a matter of time. ([Time 0:05:52](https://share.snipd.com/snip/d8ca4ddd-49ed-424a-85f3-cbc3eb75d66f)) - **Static Search Alternative** - Consider PageFind, a static search library, as an alternative to services like Algolia. - It efficiently searches large sites with minimal bandwidth usage. Transcript: Jerod Santo So why get precious about how long that period of time is? Page Find looks pretty cool. It's a fully static search library that aims to perform well on large sites while using as little of your users bandwidth as possible and without hosting any infrastructure. It runs after your static site generator, like Hugo, 11D Astro, etc., and generates a static search bundle to add to your build files. It then exposes a JavaScript search API that can be used anywhere on your site. Quote, the goal of Page Find is that websites with tens of thousands of pages should be searchable by someone in their browser while consuming as little bandwidth as possible. Page Find's search index is split in the chunks so that searching in the browser only ever needs to load a small subset of the search index. Page Find can run a full-text search on a 10,000-page site with a total network payload under 300 KB, including the Page Find library itself. For most sites, this will be closer to 100 KB. End quote. I'd love to see a comparison. Link me up if you know of one. But my guess is that this could easily replace Algolia on lots of open-source docs and websites. Unless service depends on why not, ([Time 0:06:55](https://share.snipd.com/snip/7feb648b-b94d-443e-9bd0-38dfb1062052))