Microservices blogpost

apps/website/src/content/posts/callbacks-exercises.md

@@ -7,7 +7,7 @@ authors: ["david"]
 category: "Learn Javascript"
 editors: ["velimir"]
 abstract: "It's really hard to test your programming knowledge after you have completed a tutorial or a lecture. We have prepared some exercises to help out beginner devs to solidify their understanding of callbacks. Every exercise has a brief description of the problem, starting code, links to relevant MDN docs, and expected results. Try to solve the problems without taking a peek at the solution."
-image: "/images/callback-hell.jpg"
+image: "/images/callback-hell.png"
 draft: false
 ---
 

apps/website/src/content/posts/create-react-app-is-dead-what-are-the-alternatives.md

@@ -7,7 +7,7 @@ authors: ["david"]
 category: "Learn Javascript"
 editors: ["velimir"]
 abstract: "Create React App seems abandoned and dead. I want to show you some great alternatives that we personally use at CroCoder. T3 Stack is a web development stack created by Theo that focuses on simplicity, modularity, and full-stack type safety. Its core pieces are Next.js, TypeScript, and Tailwind CSS. T3 Stack is a great alternative to Create React App (CRA) because it offers superior performance, faster development time, and is actively maintained. Vite + React is a great alternative to Create React App (CRA) because it offers superior performance and faster development time. Additionally, Next.js is a frontend framework that is built on top of React and is designed to improve the performance, user experience, and SEO of web applications. It provides an out-of-the-box solution for server-side rendering (SSR) of React components, which allows for simple indexable HTML to be sent to the user, making it easier for web crawlers to read the text content of the application, thereby improving its visibility in search engines."
-image: "/images/create-react-app-is-dead-what-are-the-alternatives.jpg"
+image: "/images/create-react-app-is-dead-what-are-the-alternatives.png"
 draft: false
 ---
 

apps/website/src/content/posts/crowdstrike-microsoft-incident-breakdown.md

@@ -7,10 +7,11 @@ authors: ["david"]
 category: "AWS"
 editors: ["velimir"]
 draft: false
-abstract: "On July 19, 2024, CrowdStrike's Falcon Sensor update caused widespread disruptions on millions of Windows systems, leading to \"blue screens of death\" and boot loops. The issue, an error in the C++ code of a system driver, impacted aviation, media, banking, and healthcare sectors, grounding flights and disrupting emergency services. This incident highlights a failure in CrowdStrike's development and deployment processes, as such errors should be caught by automated code sanitization tools. It underscores the importance of rigorous testing, CI/CD practices, and phased rollouts to prevent widespread disruptions in critical systems. Robust testing and deployment strategies are essential, even with memory-safe programming languages."
-image: "/images/crowdstrike-microsoft-incident-breakdown.jpg"
+abstract: "On July 19, 2024, CrowdStrike's Falcon Sensor update caused widespread disruptions on millions of Windows systems, leading to \"blue screens of death\" and boot loops. The issue, an erorr in the C++ code of a system driver, impacted aviation, media, banking, and healthcare sectors, grounding flights and disrupting emergency services. This incident highlights a failure in CrowdStrike's development and deployment processes, as such errors should be caught by automated code sanitization tools. It underscores the importance of rigorous testing, CI/CD practices, and phased rollouts to prevent widespread disruptions in critical systems. Robust testing and deployment strategies are essential, even with memory-safe programming languages."
+image: "/images/crowdstrike-microsoft-incident-breakdown.png"
 ---
 
+
 On July 19th, 2024, CrowdStrike released a critical update for their Falcon Sensor vulnerability scanner, which led to widespread disruptions across millions of Microsoft Windows systems.
 
 This update caused numerous Windows machines to experience "blue screens of death" and enter a boot loop. The incident affected almost every sector, including aviation, media, banking, and healthcare, grounding commercial flights, and disrupting emergency services.

apps/website/src/content/posts/microservices-are-a-way-to-organize-your-company.md

@@ -0,0 +1,55 @@
+---
+title: "Microservices Are a Way to Organize Your Company"
+description: "Are microservices practical or just fashionable? Discover when they're the right choice and how they impact team autonomy and complexity."
+createdAt: 1740307629165
+updatedAt: 1740307629165
+authors: ["david"]
+category: "DEVELOPER EXPERIENCE"
+editors: ["velimir"]
+draft: false
+abstract: "Microservices are often praised for boosting team autonomy and enabling rapid development—but are they always the right architectural choice? This article explores the real implications of adopting microservices beyond just technology. It emphasizes that successful microservices architectures align closely with organizational structures, empowering small, autonomous teams to own and deploy services independently. However, without clear boundaries and proper organizational readiness, microservices can quickly turn into fragmented monoliths, introducing unnecessary complexity and operational overhead. Ultimately, choosing microservices involves balancing technical solutions with organizational needs, understanding trade-offs, and critically examining whether you're solving genuine problems or simply following architectural trends."
+image: "/images/microservices-are-a-way-to-organize-your-company.png"
+---
+
+Microservices remind me a bit of Crocs; you either find them practical and comfortable or see them as a questionable fashion choice that somehow became acceptable. 
+
+Both perspectives have merit, honestly. 
+
+But here's the thing: microservices aren't only about code. They're about how you structure your teams and organize your whole company.
+
+We know that software teams work best when they’re small and autonomous. Microservices are an attempt to bake this principle into the very structure of a system.
+
+The idea is that small, autonomous teams should be able to develop, deploy, and own their services independently. Teams can move fast, own their domains, and minimize cross-team dependencies. If your teams aren’t structured to take advantage of microservices, you’re just adding complexity for no real benefit.
+
+## Managing complexity
+
+Software complexity is inevitable. The real question is how you manage it. Microservices approach complexity by breaking the system into small, independently deployable parts. This means you should be able to make changes to one service without affecting the others.
+
+The defining feature of microservices isn’t Kubernetes or sending JSON from a service to a service. It’s autonomy. If your microservices aren’t giving your teams real autonomy, they’re not microservices. 
+
+**They’re just fragmented pieces of a system with extra network latency on top.**
+
+If your services aren’t truly independent, if they have to be deployed together, tested together, or change in lockstep, you don’t have microservices.
+
+## So... It depends
+
+So should you use microservices? It depends. 
+
+Like any architectural choice, microservices come with trade-offs.
+
+**Well-defined boundaries are hard to get right.** If your services are too tightly coupled, you end up with a distributed monolith. If they’re too loosely coupled, each team duplicates the logic and reinvents the wheel.
+
+**Communication between services adds friction.** In a monolith, a function call is just that, a function call. In a microservices system, that same call might involve network hops, retries, timeouts, and debugging distributed failures.
+
+**Operational overhead increases.** More services mean more deployments, more monitoring, and more infrastructure complexity.
+
+In short, microservices aren’t inherently good or bad, they’re just a tool. Like any tool, they make sense in some contexts but are overkill in others. The main reason you'd want to use them is when your company has multiple teams that own different parts of the system, and there's an obvious benefit to those teams operating with fewer dependencies on each other.  If your team boundaries clearly match up with different business features or services, then microservices can be a really practical solution. Otherwise, they introduce complexity you don't actually need.
+
+
+## Conclusion
+
+Microservices are great, but they are not for everyone. And that's perfectly okay. 
+
+Done well, they make teams ship independently, scale easier, break complex systems into more manageable domains. But if your team structure isn't ready for microservices, you will introduce complexity instead of reducing it.
+
+The one question I want you to think about before jumping into migrating the entire system to a new architecture is: am I solving a technical problem or an organizational one?