<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://barmag.github.io/feed.xml" rel="self" type="application/atom+xml" /><link href="https://barmag.github.io/" rel="alternate" type="text/html" /><updated>2026-04-03T14:01:25+00:00</updated><id>https://barmag.github.io/feed.xml</id><title type="html">barmag</title><subtitle>Engineering leadership, neurodivergence, and technology -- by Yasser Makram</subtitle><entry><title type="html">The Courage to Be Disliked: Adlerian Psychology for Engineering Teams That Burn Bright and Burn Out</title><link href="https://barmag.github.io/leadership/engineering-management/books/2026/03/27/courage-to-be-disliked-engineering-leadership.html" rel="alternate" type="text/html" title="The Courage to Be Disliked: Adlerian Psychology for Engineering Teams That Burn Bright and Burn Out" /><published>2026-03-27T22:00:00+00:00</published><updated>2026-03-27T22:00:00+00:00</updated><id>https://barmag.github.io/leadership/engineering-management/books/2026/03/27/courage-to-be-disliked-engineering-leadership</id><content type="html" xml:base="https://barmag.github.io/leadership/engineering-management/books/2026/03/27/courage-to-be-disliked-engineering-leadership.html"><![CDATA[<p>I picked up <em>The Courage to Be Disliked</em> during a turbulent stretch – agentic AI disrupting the industry, layoffs rolling through, genuine uncertainty about the future of software engineering. I was looking for identity anchoring: something to help me know my strengths and weaknesses when the ground keeps shifting. The kind of existential crisis that makes you read philosophy books instead of just updating your LinkedIn to “open to work” like a normal person.</p>

<p>But the book resonated far beyond that. It validated something I’d been struggling with for years and couldn’t name clearly: the burnout that comes from avoiding confrontation and satisfying a vulnerable ego. Not selflessly putting others first – that’s the noble version. The honest version is that I was protecting myself from the discomfort of being disagreed with, of being seen as difficult, of risking disapproval. And the cost of that protection was burning out.</p>

<p>I was diagnosed autistic and ADHD and that reframing changed how I understood my entire career. Decades of <em>masking</em> – performing neurotypical social behaviour to fit in – combined with an absence of <em>self-advocacy</em>. The result is a kind of exhaustion that doesn’t show up on a performance review. You’re delivering. You’re exceeding expectations. And you’re hollowing out.</p>

<p>Most management books didn’t help with this. Even the best ones – Camille Fournier’s <em>The Manager’s Path</em> is the gold standard – assume a baseline of social intuition. “Read the room.” “Build rapport.” “Give feedback naturally.” These are instructions where the <em>how</em> is supposed to be obvious. For a neurotypical manager, maybe it is. For me, it was like a recipe that says “season to taste” when you can’t taste. I spent ten years reading stack traces; now I’m supposed to read rooms. Rooms don’t have error messages. I needed explicit frameworks – logical structures I could study, internalise, and apply deliberately – because I build social skills through acquisition, not instinct.</p>

<p>Adlerian psychology gave me that. Where <em>The Manager’s Path</em> is the operational manual for tech leadership, Adler is the internal operating system that makes executing it sustainable.</p>

<p><img src="https://barmag.github.io/assets/media/this-is-fine-manager.png" alt="The This is Fine meme adapted for people-pleasing managers" /></p>

<hr />

<h2 id="separation-of-tasks-why-your-engineers-career-crisis-is-not-your-2-am-problem">Separation of Tasks: Why Your Engineer’s Career Crisis Is Not Your 2 AM Problem</h2>

<p>Adler’s most practical concept is the <em>separation of tasks</em>. The test is simple: who ultimately bears the consequences of this choice?</p>

<p>As a manager:</p>
<ul>
  <li><strong>Your task:</strong> Set clear context. Share relevant experience. Create conditions where the team can make decisions and mistakes safely. Bear organisational consequences.</li>
  <li><strong>Their task:</strong> Decide how to approach their work. Learn from their own experience. Own their technical choices. Bear individual consequences.</li>
</ul>

<p>The failure isn’t just micromanagement – stealing their task. It’s also abdication – dumping yours on them. Both are boundary violations.</p>

<p><img src="https://barmag.github.io/assets/media/two-buttons-manager.png" alt="The Two Buttons meme — the manager's dilemma" /></p>

<p>I once managed an engineer who kept missing deadlines. The work they produced was over-engineered, branching into non-core topics, polished far beyond what was needed. They were visibly exhausted. The technical quality was strong – but the goal kept slipping.</p>

<p>A typical management response: “You need to share your work more frequently. Let’s add checkpoint meetings.” That’s a demand disguised as process. It addresses the symptom by adding control.</p>

<p>I recognised the pattern because I’d lived it. The reluctance to share drafts. The over-engineering as a shield. The logic that says: if I make it perfect enough, no one can criticise it. This wasn’t a performance problem. It was imposter anxiety – avoiding the vulnerability of showing imperfect work. Over-engineering is just anxiety with a GitHub history.</p>

<p>Adler distinguishes between <em>etiology</em> (looking backward at causes) and <em>teleology</em> (looking at what present goal the behaviour serves). The standard management question: “Why are you missing deadlines?” The Adlerian question: “What is this behaviour achieving for you right now?” The answer was safety. The over-engineering served the goal of avoiding judgment.</p>

<p>So instead of adding a demand, I shared my own experience. I talked about times I’d done the same thing – buried myself in perfectionism because showing rough work felt dangerous. I reframed check-ins not as surveillance but as collaborative discovery. The shift was from “you need to show me your work” to “I’ve been where you are, and here’s what helped me.”</p>

<p>The engineer’s behaviour changed. Not because I forced it, but because I made it safe to be imperfect.</p>

<hr />

<h2 id="horizontal-relationships-you-have-more-mistakes-not-more-worth">Horizontal Relationships: You Have More Mistakes, Not More Worth</h2>

<p>You have formal authority over the engineers you manage. That’s organisational reality. But formal authority doesn’t require a vertical <em>relationship</em>.</p>

<p>Adler distinguishes between vertical relationships (superior/inferior, built on judgment) and horizontal relationships (equals, built on mutual respect). Most management instinctively defaults to vertical:</p>

<ul>
  <li>“I know better than you” (superiority)</li>
  <li>“You should do it this way” (control)</li>
  <li>“Let me show you the right way” (judgment)</li>
</ul>

<p>The horizontal alternative carries the same experience from a different stance:</p>

<ul>
  <li>“I’ve made this mistake before” (shared humanity)</li>
  <li>“Here’s what I learned when I tried that” (offering, not imposing)</li>
  <li>“You get to decide how to use this” (respecting agency)</li>
</ul>

<p>I think of my experience not as “knowing more” but as <em>wisdom from more mistakes</em>. The content is the same. The relationship is completely different.</p>

<p>The word that captures this is <strong>offering</strong>. When you offer, they can take it or leave it. You’re not diminished if they choose differently. The relationship survives disagreement. Your value isn’t tied to compliance.</p>

<h3 id="why-good-job-turns-engineers-into-golden-retrievers">Why “Good Job” Turns Engineers Into Golden Retrievers</h3>

<p>This plays out most clearly in how you give feedback. Adler argues that praise is a vertical act. When you say “good job,” you’re claiming the authority to judge – positioning yourself above the person you’re evaluating. This creates dependency. Engineers optimise for your approval instead of the work itself. They check in more. They second-guess decisions you haven’t validated. They lose the agency you’re trying to build.</p>

<p>The alternative is <em>encouragement</em> – a horizontal act:</p>

<table>
  <thead>
    <tr>
      <th>Praise (vertical)</th>
      <th>Encouragement (horizontal)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>“Good job on the PR”</td>
      <td>“I see you tried this approach – how did it work out?”</td>
    </tr>
    <tr>
      <td>“That’s the right design”</td>
      <td>“When I faced something similar, here’s what happened…”</td>
    </tr>
    <tr>
      <td>“Well done, I’m proud of you”</td>
      <td>“Thank you for shipping that quickly – it helped the team hit our deadline”</td>
    </tr>
  </tbody>
</table>

<p>If your team’s primary feedback loop is your facial expressions, you’ve built a distributed system with a single point of failure.</p>

<p><img src="https://barmag.github.io/assets/media/vertical-vs-horizontal.png" alt="Vertical vs Horizontal feedback comic" /></p>

<p>The difference between “I evaluate your work” and “I’m curious about your thinking” is where psychological safety actually lives. Not the performative kind where everyone is polite. The kind where engineers feel safe being wrong.</p>

<hr />

<h2 id="the-desire-for-recognition-a-performance-review-of-my-own-ego">The Desire for Recognition: A Performance Review of My Own Ego</h2>

<p>Adler denies the desire for recognition. His argument: if you live seeking others’ approval, you end up living someone else’s life.</p>

<p>This is where the neurodivergent experience and the management problem converge. Before I had Adler’s framework, I didn’t recognise that my conflict avoidance as a manager wasn’t good leadership. It was masking — protecting a vulnerable ego from the discomfort of confrontation and the risk of disapproval.</p>

<p>The research documents this pattern precisely. Raymaker et al. (2020) found that autistic burnout is characterised by chronic exhaustion, loss of skills, and reduced tolerance to stimulus — distinct from occupational burnout, and strongly correlated with masking and unmet support needs. Hull et al. (2017) documented the cost of camouflaging: socially effective but psychologically destructive. Mantzalas et al. (2022) showed how late-diagnosed adults accumulate years of compensatory strategies that eventually collapse. This isn’t abstract to me. This is my career in my twenties and thirties.</p>

<p>In a management context, masking looks like: agreeing with decisions you disagree with, avoiding hard conversations, letting poor dynamics persist because addressing them means risking being seen as difficult. It looks like competence. It feels like drowning.</p>

<p><img src="https://barmag.github.io/assets/media/iceberg-masking.png" alt="The masking iceberg — what they see vs what's actually happening" /></p>

<p>Adler’s separation of tasks broke this cycle for me. Their reaction to my decision is <em>their</em> task. My task is to make the decision with integrity and communicate it clearly. I cannot control how they feel about it – and trying to is both a violation of their autonomy and a path to hollowing out.</p>

<p>This gave me permission to self-advocate. To say no. To have the difficult conversation and let their response be theirs.</p>

<p>But permission to speak isn’t the same as knowing how. Adler tells you <em>that</em> you should have the courage to be disliked – he doesn’t tell you how to deliver the message without being an arsehole. That’s where three other books filled the gap for me:</p>

<ul>
  <li><strong>Radical Candor</strong> (Kim Scott) gave me the framework of caring personally while challenging directly. The courage to be disliked doesn’t mean being indifferent – it means being honest <em>because</em> you care, not despite it.</li>
  <li><strong>Radical Respect</strong> (Kim Scott) added the boundary between candour and harm. Being direct is not the same as being cruel. You can separate tasks without dismissing the person.</li>
  <li><strong>Nonviolent Communication</strong> (Marshall Rosenberg) gave me the actual mechanics: observe without evaluating, name the need, make a request instead of a demand. For someone who builds social skills through deliberate acquisition, NVC was the API documentation I’d been missing.</li>
</ul>

<p>Together, these form a stack: Adler gives you the philosophical permission. Radical Candor gives you the stance. NVC gives you the syntax. Without all three, you either stay silent (burnout) or speak without skill (damage).</p>

<hr />

<h2 id="the-harder-problem-stopping-good-engineers-from-setting-themselves-on-fire">The Harder Problem: Stopping Good Engineers From Setting Themselves on Fire</h2>

<p>The harder problem in managing high-performing engineers isn’t motivation. It’s preventing burnout in people who are passionate, skilled, and willing to destroy themselves shipping great work.</p>

<p>Performance management frameworks are designed to address underperformance. But what do you do with an engineer who’s delivering brilliantly and burning out doing it?</p>

<p>I learned this from my own experience first. I burned out not because I was pushed, but because I didn’t advocate for my own needs. I confused the organisation’s task (maximising output) with mine (sustainable contribution). Adler helped me see the distinction.</p>

<p>As a manager, the same framework applies:</p>

<ul>
  <li><strong>The engineer’s task:</strong> Own their sustainability. Set boundaries. Decide when to push and when to rest.</li>
  <li><strong>The manager’s task:</strong> Create conditions where sustainability is possible. Model it. Make “I’m at capacity” a respected signal, not a weakness.</li>
</ul>

<p>You can take a horse to water, but you can’t make it drink. You can build an environment where rest is valued and pace is designed for endurance. But you cannot force someone to take care of themselves. That’s their task.</p>

<p>What you <em>can</em> do is stop rewarding self-destruction. Stop celebrating the engineer who ships at 2 AM. No one has ever said “I’m so glad I shipped that feature at 2 AM on a Sunday” at their own funeral. Start thanking the one who flags a risk early and asks for help. The incentives you set shape the behaviour the team optimises for.</p>

<hr />

<p><img src="https://barmag.github.io/assets/media/adlerian-framework-infographic.png" alt="The Adlerian Stance for Engineering Leaders — framework summary" /></p>

<h2 id="what-i-took-away">What I Took Away</h2>

<p>Adlerian psychology didn’t give me a management framework. It gave me a different <em>stance</em> from which to apply whatever framework I already use:</p>

<ol>
  <li><strong>Separate tasks.</strong> Know what’s yours and what’s theirs. Don’t steal their agency; don’t abdicate yours.</li>
  <li><strong>Stay horizontal.</strong> You have authority over their role, not their worth. Lead from shared experience, not superiority.</li>
  <li><strong>Encourage, don’t praise.</strong> Be curious about their thinking instead of evaluating their output.</li>
  <li><strong>Let go of the need for approval.</strong> Make the right call. Let their reaction be their task.</li>
  <li><strong>Protect the team from burnout.</strong> The harder problem isn’t pushing people to perform – it’s making it safe to stop.</li>
</ol>

<p>For neurotypical managers, some of this may come naturally. For me – decades of masking behind me, a history of burning out while exceeding expectations – it required deliberate construction. Adler gave me what intuition-based management advice never could: an explicit, logical framework for leading people without losing myself in the process.</p>

<p>The courage to be disliked isn’t about not caring. It’s about caring enough to be honest – with your team, and with yourself – even when the honest thing is unpopular.</p>

<p>For anyone who has spent years performing competence while quietly exhausting themselves: that’s not leadership. That’s survival. And you deserve a better operating system.</p>

<p>And if reading an Adlerian psychology book seems like an unusual path to becoming a better engineering manager – well, so did reading the Kubernetes docs, and we all did that.</p>

<hr />

<p><em>Based on <a href="https://www.amazon.co.uk/Courage-Be-Disliked-yourself-happiness/dp/176063073X">The Courage to Be Disliked</a> by Ichiro Kishimi &amp; Fumitake Koga. Companion reading: <a href="https://www.oreilly.com/library/view/the-managers-path/9781491973882/">The Manager’s Path</a> by Camille Fournier, <a href="https://www.radicalcandor.com/the-book/">Radical Candor</a> by Kim Scott, <a href="https://kimmalonescott.com/radical-respect/">Radical Respect</a> by Kim Scott, and <a href="https://www.nonviolentcommunication.com/product/nvc/">Nonviolent Communication</a> by Marshall Rosenberg.</em></p>

<p><em>Research cited: Raymaker et al. (2020), <a href="https://doi.org/10.1089/aut.2019.0079">“Having All of Your Internal Resources Exhausted Beyond Measure and Being Left with No Clean-Up Crew: Defining Autistic Burnout”</a>. Hull et al. (2017), <a href="https://doi.org/10.1007/s10803-017-3166-5">“Putting on My Best Normal: Social Camouflaging in Adults with Autism Spectrum Conditions”</a>. Mantzalas et al. (2022), <a href="https://doi.org/10.1089/aut.2021.0021">“What Is Autistic Burnout? A Thematic Analysis of Posts on Two Online Platforms”</a>.</em></p>]]></content><author><name></name></author><category term="leadership" /><category term="engineering-management" /><category term="books" /><category term="adlerian-psychology" /><category term="leadership" /><category term="neurodivergent" /><category term="burnout" /><category term="engineering-management" /><summary type="html"><![CDATA[I spent ten years reading stack traces; now I'm supposed to read rooms. Rooms don't have error messages. How Adlerian psychology gave a neurodivergent engineering manager the explicit framework that intuition-based advice never could.]]></summary></entry><entry><title type="html">Lessons from the Trenches: How We Paid Less and Got More from AWS</title><link href="https://barmag.github.io/aws/cloud/2020/07/09/Lessons-from-the-trenches-How-we-paid-less-and-got-more-from-AWS.html" rel="alternate" type="text/html" title="Lessons from the Trenches: How We Paid Less and Got More from AWS" /><published>2020-07-09T12:00:00+00:00</published><updated>2020-07-09T12:00:00+00:00</updated><id>https://barmag.github.io/aws/cloud/2020/07/09/Lessons-from-the-trenches-How-we-paid-less-and-got-more-from-AWS</id><content type="html" xml:base="https://barmag.github.io/aws/cloud/2020/07/09/Lessons-from-the-trenches-How-we-paid-less-and-got-more-from-AWS.html"><![CDATA[<p>I am old enough to have used CORBA, and COM+. Lucky enough to be building distributed loosely coupled systems for 20 years. Now witnessing how easy and accessible distributed technology have become. Many of the principles have not changed, but reflecting on my experience with modern cloud native architecture that building resilient and scalable system with PaaS cloud platforms is much cheaper than both on premises or monolithic IaaS. The on demand, pay for use model costs fractions of provisioned infrastructure, not only money, but also time.</p>

<p>In a previous project I joined the team right after moving the infrastructure to AWS, and the team was using nothing but EC2, and VPCs. The cloud services from AWS enabled us to move incrementally to modernize the system with controlled risk.</p>

<p>CloudFormation was the first service we used from the AWS stack of services. At the beginning we did not have a good idea of what we were doing, but AWS had a selection of useful templates to use and it gave us a taste of what we can accomplish. After a short while we managed to automate and codify our infrastructure creation. With our infrastructure as code we managed to evolve it incrementally for high availability with multi region infrastructure. CloudWatch events was then used to automate the response to failure events. The end result was a self healing environment with no extra cost. The outcome encouraged us to use more services.</p>

<p><strong>Core or Meta</strong></p>

<p>The next decision was whether to continue with meta services i.e. services that help manage and operate our existing code, or use the platform services. The advantages of AWS Lambda was intriguing, so intriguing to the point we were carefully looking for the catch and found none. We used some lambda services to automate some operation tasks, and it cost nothing, easy to manage and deploy so we decided to implement some new requirements using API Gateway, Lambda, RDS, SQS, and Beanstalk.</p>

<p>The legacy component was wrapped into a Beanstalk deployment. Beanstalk enabled us to have a self healing, auto scaled instances without modifying the original code. The legacy code was wrapped with a proxy that listens to an SQS queue. The client communicated via a API gateway endpoints. The gateway handled authentication, throttling, key management, and HTTPS. The API gateway invoked a lambda function that implemented the product new functionality, then put a message in the SQS for the legacy processing. The SQS queue enabled us to control the throughput, tolerate failures, and auto scale the beanstalk environment based on the queue requests. The whole environment was deployed via a CLoudFormation template, and logs were collected via CloudWatch. The following diagram shows the general system architecture. 
<img src="https://barmag.github.io/assets/media/Lambda_andBeanstalk.png" alt="patterns taxonomy" /></p>

<p><strong>More for Less</strong></p>

<p>The success of the project left us hungry for more. After coping with cold start time of lambda, the low cost and auto scaling encouraged us to use it more, and the reliability of SQS enabled resilient architecture at negligible cost.</p>

<p>We added more services to the next project. Combined SNS/SQS to implement a pub/sub architecture. Decomposed more of the legacy logic into lambda functions. Started using DynamoDB for data persistence, and CodeDeploy for continuous delivery.</p>

<p><strong>Goodbye CloudFormation and Welcome CDK</strong></p>

<p>The CloudFormation template grew substantially and it was painful to maintain. We decided to look at AWS Cloud Deployment Kit CDK, and we never looked back.</p>

<p>Out of the box CDK saves a considerable amount of code by following an opinionated CloudFormation code generation that follows AWS best practices. But also it allowed us to build custom constructs, that reflects our architectural patterns, and manipulate the constructs before generation to implement cross cutting concerns like adding monitoring support for our Pub/Sub endpoints.</p>

<p>After implementing two new projects we were happily surprised that the production usage of the Lambda services was still covered by the free tier as well as DynamoDB deployments.</p>

<p>The low cost meant that we can have sandboxed environments for individual developers or specific features. Also performing a production like tests on the staging environment without worrying about the bill. CDK and CodeDeploy allowed us to automate all these operations, and sleep happily at night.</p>]]></content><author><name></name></author><category term="aws" /><category term="cloud" /><summary type="html"><![CDATA[I am old enough to have used CORBA, and COM+. Lucky enough to be building distributed loosely coupled systems for 20 years. Now witnessing how easy and accessible distributed technology have become. Many of the principles have not changed, but reflecting on my experience with modern cloud native architecture that building resilient and scalable system with PaaS cloud platforms is much cheaper than both on premises or monolithic IaaS. The on demand, pay for use model costs fractions of provisioned infrastructure, not only money, but also time.]]></summary></entry><entry><title type="html">Microservices Patterns Chapter 1 Notes</title><link href="https://barmag.github.io/readings/2020/05/17/microservices-patterns.html" rel="alternate" type="text/html" title="Microservices Patterns Chapter 1 Notes" /><published>2020-05-17T10:50:48+00:00</published><updated>2020-05-17T10:50:48+00:00</updated><id>https://barmag.github.io/readings/2020/05/17/microservices-patterns</id><content type="html" xml:base="https://barmag.github.io/readings/2020/05/17/microservices-patterns.html"><![CDATA[<p>Microservices Patterns</p>

<p>Sunday, May 17, 2020</p>

<p>10:24 PM</p>

<p>This is my personal notes for <strong>“Microservices Patterns”</strong> book by Chris Richardson <a href="https://microservices.io/book"><span class="underline">https://microservices.io/book</span></a></p>

<h2 id="chapter-1">Chapter 1</h2>

<p>The first section of this chapter covers the monolithic hell and makes the case of Microservices with a story about a fictitious company and its struggle with maintaining and growing a monolithic app.</p>

<p>I found this section to be verbose with shallow information. I think it is fair to say if you are reading a book about Microservices Patterns chances are you are familiar with the drawbacks of monolithic apps vs. Microservices. It is safe to skip this section in my opinion.</p>

<p>Section 1.2, and 1.3 are about the book and why it is relevant and what it covers. Read it maybe before buying it to decide if it is relevant.</p>

<p>Section 1.4 defines Microservices. I think at the time of writing the book Chris Richardson did not have a concrete definition so instead he presented a verbose description. I find his definition on <a href="https://microservices.io/"><span class="underline">https://microservices.io/</span></a> to be more concrete. What I like about his definition is removing the size of the codebase as a Microservice characteristic and associating the size with team instead. I find this very useful as he drills down to the organizational change needed to decompose the monolith.</p>

<p>Generally, I prefer Sam Newman’s definition of Microservices.</p>

<p><a href="https://www.youtube.com/watch?v=PFQnNFe27kU"><span class="underline">Principles Of Microservices by Sam Newman</span></a></p>

<p>Sam Newman’s definition: Small (independently releasable) <strong>Autonomous services that</strong> work together, modelled around a business domain</p>

<p><a href="https://www.youtube.com/watch?v=CKLIL3Kbf60"><span class="underline">Microservices and Serverless - Sam Newman</span></a></p>

<p><strong>Independently deployable</strong> services that <strong>work together</strong>, modelled around a <strong>business domain</strong></p>

<p>Section 1.6 is the most informative in this chapter, and specifically 1.6.3. It gives an overview of the pattern language used in the book and gives an excellent taxonomy of the patterns.</p>

<p>Chris classifies the patterns into three main layers. Application, Application Infrastructure, and Infrastructure patterns.</p>

<p><img src="https://barmag.github.io/assets/media/image1.png" alt="patterns taxonomy" /></p>

<ul>
  <li><strong>Application Patterns</strong>
    <ul>
      <li>Decomposition</li>
      <li>Database Architecture</li>
      <li>Querying</li>
      <li>Maintaining Data Consistency</li>
      <li>Testing</li>
    </ul>
  </li>
  <li><strong>Application Infrastructure Patterns</strong>
    <ul>
      <li>Cross-cutting Concerns</li>
      <li>Security</li>
      <li>Transactional Messaging</li>
      <li>Communication Style</li>
      <li>Reliability</li>
      <li>Observability</li>
    </ul>
  </li>
  <li><strong>Infrastructure Patterns</strong>
    <ul>
      <li>Deployment</li>
      <li>Discovery</li>
      <li>External API</li>
    </ul>
  </li>
</ul>

<p><strong>Chapter 2</strong> describes decomposition patterns in details. Chris describes it as a set of strategies for decomposing an application into Microservices.</p>

<p><strong>Chapter 3</strong> drills down into communication patterns including communication style, reliability, and transaction messaging while <strong>Chapter 8</strong> covers external API patterns.</p>

<p><strong>Chapter 4, 5, and 6</strong> cover the strategies for data storage in the context of Microservices and the challenges associated with maintaining a database per service. Saga pattern is described in detail as an alternative to 2PC approach for distributed transactions.</p>

<p>Another challenge with database decomposition is querying data scattered around multiple services. <strong>Chapter 7</strong> details a set of different patterns for implementing queries.</p>

<p><strong>Chapter 12</strong> focuses on deployment of Microservices either as VM, container, or serverless. While Chapter 11 details application observability patterns including health check API, log aggregation, distributed tracing, exception tracking, application metrics, and audit logging. <strong>Chapter 11</strong> also describes Microservices Chassis pattern for handling cross-cutting concerns like observability and discovery. <strong>Chapter 11</strong> also discusses security, and access token pattern in detail.</p>

<p><strong>Chapter 9 and 10</strong> focus on patterns for services automated testing with patterns for testing services in isolation with consumer-driven contract test, consumer-side contract test, and service component test.</p>

<p>The final section of this introductory chapter gives a good piece of wisdom about the non-technical aspect of implementing Microservices, and the need of organizational changes and consideration to the human side.</p>

<p>This chapter intrigued my interest in this book and looking forward to reading more.</p>]]></content><author><name></name></author><category term="readings" /><summary type="html"><![CDATA[Microservices Patterns]]></summary></entry></feed>