Extreme A
@extremea.bsky.social
Insights into building and supporting software systems: DevOps, Automation Tooling, Software Delivery, Team Structures, Strategy and more.
Subscribe: https://insights.extremeautomation.io/
Subscribe: https://insights.extremeautomation.io/
The conference is running June 23–27 with a great mix of virtual sessions, workshops, and live events.
platformcon.com/sessions/str...
June 24, 2025 at 5:59 AM
The conference is running June 23–27 with a great mix of virtual sessions, workshops, and live events.
platformcon.com/sessions/str...
It should offer powerful capabilities behind clean, intuitive interfaces. It should reduce friction, not increase it.
Easier said than done.
Easier said than done.
June 11, 2025 at 6:07 AM
It should offer powerful capabilities behind clean, intuitive interfaces. It should reduce friction, not increase it.
Easier said than done.
Easier said than done.
This is where Gregor Hohpe’s insight is so important: build abstractions, not illusions. The value of a platform lies in its ability to abstract away the messy, intricate details of infrastructure and tooling, so teams can focus on delivering business value.
June 11, 2025 at 6:07 AM
This is where Gregor Hohpe’s insight is so important: build abstractions, not illusions. The value of a platform lies in its ability to abstract away the messy, intricate details of infrastructure and tooling, so teams can focus on delivering business value.
Not because they want to rebel, but because the official platform no longer meets their needs. It has become an obstacle, not a support structure.
June 11, 2025 at 6:07 AM
Not because they want to rebel, but because the official platform no longer meets their needs. It has become an obstacle, not a support structure.
And then comes the inevitable workaround what I call the "shadow platform" movement. Talented engineers, trying to get things done, start building their own tools and workflows on the side, often out of sight from the official platform team.
June 11, 2025 at 6:07 AM
And then comes the inevitable workaround what I call the "shadow platform" movement. Talented engineers, trying to get things done, start building their own tools and workflows on the side, often out of sight from the official platform team.
The result? Teams lose motivation. Innovation slows. Engineers spend more time negotiating exceptions than building value.
June 11, 2025 at 6:07 AM
The result? Teams lose motivation. Innovation slows. Engineers spend more time negotiating exceptions than building value.
The rules, meant to ensure consistency and security, often go too far, dictating not just what should be done, but how it must be done, down to the smallest details.
June 11, 2025 at 6:07 AM
The rules, meant to ensure consistency and security, often go too far, dictating not just what should be done, but how it must be done, down to the smallest details.
I’ve seen many internal platform initiatives start with ambition and good intentions, only to fall under the weight of rigid processes and overly strict governance. These platforms, instead of becoming enablers, turn into bottlenecks.
June 11, 2025 at 6:07 AM
I’ve seen many internal platform initiatives start with ambition and good intentions, only to fall under the weight of rigid processes and overly strict governance. These platforms, instead of becoming enablers, turn into bottlenecks.
It should empower teams to move faster, with confidence, while still aligning with security, compliance, and operational excellence. In short, your platform should feel like a power-up, not a penalty.
June 11, 2025 at 6:07 AM
It should empower teams to move faster, with confidence, while still aligning with security, compliance, and operational excellence. In short, your platform should feel like a power-up, not a penalty.
It should give an ability to deliver bigger value with less friction, not introduce more bureaucracy. A good platform removes cognitive load from developers, abstracts away infrastructure complexities, and provides clear, reusable paths to production.
June 11, 2025 at 6:07 AM
It should give an ability to deliver bigger value with less friction, not introduce more bureaucracy. A good platform removes cognitive load from developers, abstracts away infrastructure complexities, and provides clear, reusable paths to production.
I find Martin Fowler's Technical Debt Quadrant especially useful. It categorizes debt based on whether it's intentional or unintentional, and whether it’s taken thoughtfully or carelessly.
What’s your relationship with technical debt?
May 26, 2025 at 4:48 AM
I find Martin Fowler's Technical Debt Quadrant especially useful. It categorizes debt based on whether it's intentional or unintentional, and whether it’s taken thoughtfully or carelessly.
What’s your relationship with technical debt?
Many teams fail to recognize just how many impediments they’ve created for themselves by ignoring technical debt.
Like financial debt, technical debt can be a reasonable trade-off when taken deliberately to support growth or seize opportunities.
May 26, 2025 at 4:48 AM
Many teams fail to recognize just how many impediments they’ve created for themselves by ignoring technical debt.
Like financial debt, technical debt can be a reasonable trade-off when taken deliberately to support growth or seize opportunities.
Notice I haven’t used the word “microservice.” You can start with small services from day one, but that assumes you already have a mature deployment platform and a deep understanding of your domain structure. Often, that’s not the case early on.
May 21, 2025 at 5:18 AM
Notice I haven’t used the word “microservice.” You can start with small services from day one, but that assumes you already have a mature deployment platform and a deep understanding of your domain structure. Often, that’s not the case early on.
Option B offers simplicity in debugging and reasoning. But to scale effectively, it still demands strong subdomain boundaries and ongoing investment in intelligent build and deployment systems to maintain team velocity.
May 21, 2025 at 5:18 AM
Option B offers simplicity in debugging and reasoning. But to scale effectively, it still demands strong subdomain boundaries and ongoing investment in intelligent build and deployment systems to maintain team velocity.
Option A gives you a strategic advantage: you can continue splitting services as needed. With good domain boundaries and a mature deployment/monitoring platform, these transitions are straightforward.
May 21, 2025 at 5:18 AM
Option A gives you a strategic advantage: you can continue splitting services as needed. With good domain boundaries and a mature deployment/monitoring platform, these transitions are straightforward.
When done well, it allows a growing team to operate autonomously within their respective subdomains.
May 21, 2025 at 5:18 AM
When done well, it allows a growing team to operate autonomously within their respective subdomains.
Option B: Keep the monolith, but invest in smarter tooling - incremental builds, partial regression testing, etc. This path still requires enforcing strong domain boundaries to enable distributed ownership across the team.
May 21, 2025 at 5:18 AM
Option B: Keep the monolith, but invest in smarter tooling - incremental builds, partial regression testing, etc. This path still requires enforcing strong domain boundaries to enable distributed ownership across the team.
However, you’ll still need to invest in the deployment platform to ensure the new application is delivered as seamlessly as the original monolith. The benefit is that teams can now work more independently on separate services.
May 21, 2025 at 5:18 AM
However, you’ll still need to invest in the deployment platform to ensure the new application is delivered as seamlessly as the original monolith. The benefit is that teams can now work more independently on separate services.