DEV Community: knowis AG

Service Granularity: When Is a Microservice Really “Micro”?

Valentino Giorgio Pino — Wed, 03 Dec 2025 15:05:18 +0000

In the early days of microservices, “small and independent” sounded simple enough. Teams broke apart their monoliths, spun up a dozen new services, and declared victory.

Then came the reality: too many services, endless integration pain, duplicated logic, and distributed complexity that nobody asked for.

Somewhere along the way, the word “micro” became misunderstood. It was never about size - it was about boundaries.

So, what does “micro” really mean?
And how small is too small?

The Size Myth

Let’s start with a misconception: microservices are not defined by lines of code.

A microservice with 500 lines can still be too big - if it mixes domains.
And a microservice with 50,000 lines can still be fine - if it’s cohesive and autonomous.

The essence of a microservice lies in independence:

It can be developed and deployed independently
It owns its data
It exposes clear contracts
It doesn’t need other services to perform its core function

It’s not about how much code it has, but how much context it owns.

A microservice should be as small as possible, but no smaller than your domain allows.

The Domain Lens: Finding Natural Boundaries

Good service granularity starts with the domain, not the code.

Domain-Driven Design (DDD) teaches us to identify bounded contexts - parts of the business that have their own language, models, and rules. These often map naturally to microservices.

For example, in an e-banking system:

The Accounts context manages balances and account types
The Payments context handles transactions and transfers
The Notifications context deals with messages and alerts

These are clear boundaries. But if you split Payments into Payment Initiation, Payment Validation, Payment Execution, and Payment Logging - you’ve likely gone too far.
You’re no longer modeling the domain. You’re modeling your workflow.

That’s a sign your services are too fine-grained.

The Cost of Small

Granularity comes with a price. Each service adds:

A new deployment pipeline
Network overhead and latency
API versioning and compatibility concerns
More operational and monitoring complexity

Multiply that by 50 or 100, and “micro” becomes “micromanagement.”

If you find yourself building tools just to manage your services, you may have split too eagerly. The goal of microservices was to enable independence, not to require orchestration frameworks just to keep them talking.

If your architecture diagram looks like a subway map, your services probably aren’t micro - they’re fragmented.

The Signs of Healthy Granularity

So how do you know when you’ve got it right?

A well-sized microservice usually:

Owns a clear part of the domain (bounded context)
Has a single, clear reason to change (cohesion)
Can be deployed independently without coordination
Contains all the logic it needs to deliver its function
Has stable external contracts and internal freedom

The Organizational Mirror

Here’s where architecture meets reality:
*The “right” granularity depends on your team structure. *

Conway’s Law tells us that systems mirror the communication structures of their organizations.
If your teams are small, autonomous, and domain-aligned, you can afford more fine-grained services.
If your teams are large, cross-functional, and share ownership, coarser-grained services might work better.

In other words:

The perfect service size is the one your organization can actually operate.

Granularity is not a design decision in isolation - it’s a socio-technical trade-off between independence and coordination.

Evolving Granularity Over Time

Service boundaries aren’t permanent. They evolve as your understanding grows.

Early on, it’s often better to start coarser:

Combine related functionality into one service
Avoid over-segmentation until domain boundaries are clear

As your product matures, split where it makes sense:

When teams struggle to coordinate deployments
When a service’s model becomes inconsistent
When scaling or performance needs diverge

This evolutionary approach keeps your architecture aligned with your reality, not with theoretical purity.

Microservices are not designed - they’re discovered, iteratively.

Conclusion - “Micro” Is About Autonomy, Not Size

The word microservice has always been a bit misleading.
The goal was never to make services small - it was to make systems independent.

The right granularity is achieved when:

Your teams can move fast without tripping over each other
Your services are cohesive, stable, and aligned with real domains
Your system’s complexity grows linearly, not exponentially

When you get that balance right, your services stop being “micro” and start being meaningful.

In the end, a microservice isn’t micro because it’s small - it’s micro because it’s focused.

From Monolith to Microservices: Why It’s Never Just a Technical Decision

Valentino Giorgio Pino — Wed, 12 Nov 2025 15:58:10 +0000

For years, “We’re moving from a monolith to microservices” has been a familiar battle cry in software engineering. It’s usually framed as a technical evolution - a natural response to scalability challenges, complex deployments, or growing codebases.

But anyone who has actually lived through that transition knows the truth: it’s never just a technical decision.

Moving from a monolith to microservices doesn’t just reshape your software. It reshapes your organization, your communication patterns, your governance, and your culture. What starts as an architectural redesign quickly becomes a transformation of how people think and work together.

The Technical Promise

Let’s start with the surface-level motivations - the reasons most teams give when they plan a migration to microservices:

Independent deployability
Horizontal scalability
Fault isolation
Domain-driven boundaries
Technology freedom

These are valid technical aspirations. But they only describe what you hope to achieve, not what it takes to get there. The challenge begins when the elegant diagrams meet the messy reality of human collaboration and organizational inertia.

The Human and Organizational Layer

When you decompose a system, you don’t just break down code - you break down responsibility. And responsibility lives with people.

Team Autonomy vs. Coordination

Microservices are built on the idea of autonomous teams. But autonomy isn’t free.
Every decision that was once implicit in a shared monolith - logging, error handling, data consistency - becomes an explicit cross-team contract. Suddenly, coordination replaces centralization.

Without clear boundaries and communication practices, the dream of autonomy turns into integration fatigue.

Ownership and Accountability

In a monolith, ownership is fuzzy. When something breaks, everyone owns it - and no one owns it.
Microservices make ownership explicit. Each team becomes responsible for their service’s quality, stability, and API integrity. That sounds empowering - until you realize it also means you can’t hide behind “the backend team” anymore.

This clarity is powerful, but it demands a cultural maturity many organizations underestimate.

Cognitive Load

The cognitive shift is also profound. Developers who once worked in a single, familiar codebase now navigate a distributed ecosystem of APIs, contracts, and deployment pipelines. Complexity doesn’t disappear - it just moves.
Instead of fighting monolithic coupling in code, teams now fight distributed coupling across services.

Conway’s Law in Action

“Organizations design systems that mirror their own communication structure.” - Melvin Conway, 1968

Every organization is a mirror - and your architecture reflects it.
If your company’s structure is centralized, with siloed decision-making, your “microservices” will likely reproduce that pattern. You’ll end up with a distributed monolith - decentralized code but centralized control.

To truly embrace microservices, you must align organizational boundaries with domain boundaries.
That means rethinking team topologies, decision-making processes, and the flow of information. You can’t modularize software without modularizing communication.

Decision-Making and Governance

Microservices shift decisions downward - from architects to autonomous teams. But autonomy without alignment quickly becomes chaos.

Teams need clarity on:

How to model their domain
Which technologies are flexible vs. standardized
How to document and share architectural decisions
How to maintain coherence across dozens of independently evolving systems

The most successful organizations find a lightweight governance model - one that empowers teams while ensuring transparency and consistency.
Architecture decision records (ADRs), collaborative modeling, and clear communication channels often matter more than any framework or tool.

Start with People, Not Code

The transition from monolith to microservices is not primarily about decomposing software - it’s about evolving your system of work.
It requires new skills, new boundaries, and new forms of trust.

So before you start drawing new service diagrams, ask:

Are your teams ready for ownership?
Do you have shared understanding of your domains?
Can your organization tolerate decentralized decision-making?

If the answer is no, microservices won’t save you.
They’ll only expose what was already broken.

The real success comes when architecture and organization evolve together - when your system’s structure and your team’s structure are in harmony.

Microservices don’t solve your problems. They just make them visible.

They also don’t create good architecture; they reveal the quality of your organizational structure and culture.

Will Software Architects Be Replaced by Technology?

Valentino Giorgio Pino — Thu, 30 Oct 2025 15:47:34 +0000

Despite the rapid rise of AI and modern automation tools, the role of the software architect will not vanish - quite the opposite. In business-critical systems, architectural work will remain essential and even gain importance as technology stacks, design patterns, and best practices grow ever more complex.
What must change, however, is the path from idea to implementation. Today, too many iterations and costly reworks slow down delivery. The next evolution is not replacing architects but empowering them: moving away from fragmented toolchains toward integrated environments that connect brainstorming, modeling, and decision documentation in one place. With intelligent AI systems assisting at every step, architects and development teams can finally focus on what matters most - building the right solutions faster and with greater confidence.

From Sticky Notes to Model Elements

Architecture always starts with ideas - sketches, notes, and rough concepts. In our environment, these early thoughts don’t get lost on a whiteboard or sticky wall. The generic diagram allows architects to capture ideas as digital sticky notes for planning, collaboration, or quick annotations.
But the real power lies in the transition: every sticky note can evolve into a model element. This seamless flow turns unstructured brainstorming into structured architecture, right within the same workspace. Architects can design freely and later formalize concepts into system components without switching tools or losing context - turning creativity directly into actionable design.

Real-Time C4 Modeling

System design is rarely a solo activity. Our platform enables teams to create System Architecture Design projects based on the C4 model, bringing real-time collaboration to architectural modeling.
Multiple stakeholders, architects, developers, and product owners, can contribute simultaneously, visualizing system contexts, containers, and components as they evolve. Changes appear instantly for everyone, keeping the architecture consistent and shared. Real-time C4 modeling transforms diagrams from static documentation into a living, collaborative representation of the system’s structure.

AI-Supported Architecture Decisions

Architecture Decision Records (ADRs) are vital for transparency and long-term maintainability. However, documenting and reasoning about decisions can be time-consuming. That’s where AI assistance steps in.
Within our environment, architects can create ADRs with integrated AI support that helps to formulate, evaluate, and refine decisions. The system can suggest templates, propose arguments, or even analyze consistency with existing design choices. The result: faster, clearer, and better-documented decisions, all without sacrificing human judgment.

The Future: Human Insight, Machine Support

Software architecture will always be a human discipline - anchored in experience, creativity, and strategic thinking. Yet, the tools surrounding architects are changing rapidly.
By combining visual collaboration, real-time modeling, and intelligent assistance, we can bridge the gap between ideation and implementation. Technology will not replace software architects - it will amplify their capabilities and help them deliver better architectures, faster.

Cursor AI meets design-aware context

Valentino Giorgio Pino — Wed, 22 Oct 2025 15:08:37 +0000

We gave an AI Coding Assistant a design file.

Here is what happened.

AI is changing everything - including how we build software. Coding assistants are everywhere, and the hype is real. But so are the concerns:

Will it scale?
Can I trust the output?
What happens when things go wrong?

We get it. We are a software company ourselves and like everyone else: we are under pressure to deliver more, faster and smarter.

So we asked us a simple question: what if we could make AI coding assistants "safe by design"?

knowis workbench meets coding assistant

In our product, architecture and design are not an afterthoughts. They are executable assets packaged as living design files that define: what gets built, how it works and why it matters.
From ideation to architecture to design specs, we align early and keep everything versioned and in sync with Git repo, pipelines and stacks.

So we took a coding assistant - in this case, the choice fell on Cursor - to run a hackathon. We didn’t write user stories. We didn’t hand over vague requirements. Instead, we fed the coding assistant the structured design artifacts generated from the knowis Workbench. Simple.

The Result? It worked well:

Code generation was fast, focused, and aligned with our intent.
Architecture guardrails stayed intact, even with rapid iterations.
Review and testing? Easier than ever.

"Shift left" matters

Shifting the (investment) focus to the "left" of the software development process doesn’t just mean testing earlier. It means thinking, designing earlier. Better. Because AI accelerates code but architecture and design defines what gets built.

Conclusion and Recommendation

In a few words: you don’t need to fear coding assistants. You need to feed them better inputs. Learn more about knowis Cloud Solution Workbench and our vision of software development acceleration.