Category: © EmberLabs (BY)

Posted on by

When Microservices Go Rogue

Thoughts of the Fractional Chief

How “Nanoservices” Created 500+ Repos
… and why to small will cost you… 
TL;DR

Microservices can help teams move faster—until they explode into nanoservices: tiny, single-endpoint codebases scattered across hundreds of repositories with no boundaries, no cohesion, and no architectural sense. One service per path or method is not microservice architecture. It’s fragmentation.
The escape hatch is not returning to a monolith, nor is it doubling down on microservices. The answer is miniservices: A meaningful middle-path, based on domain-sized, cohesive components that are small enough to understand but large enough to contain meaningful behavior, and which can be split in a reasonable way, should there be a need. “Miniservices” restore control, reduce cognitive load, and prevent microservice spraw. 

1. The Accident Nobody Planned: Microservices Turning Into Nanoservices

This problem always begins with good intentions.

A team wants:

  • Autonomy
  • Scalability
  • Isolation
  • Independent deployment
  • Faster iteration

So they break the system into microservices.

But without boundaries, ownership, or domain thinking, teams quickly slide into:

“One endpoint = one service.”

Before long, the architecture contains:

  • 500+ Git repositories
  • Services with 50 lines of code
  • Duplicated logic (Copy – paste, no shared libraries)
  • Inconsistent conventions
  • Circular dependencies via HTTP
  • Non-stop CI/CD pipelines
  • No unified view of the system
  • No stable contracts
  • Dozens of small deployment failures per week
  • Extreme costs of Lambda functions or operation via containers, when taken to the extreme.

This is not distributed architecture – this is distributed confusion.

2. Why Nanoservices Form: The Root Causes

1. No shared definition of “microservice”

One team treats a microservice as a meaningful domain boundary.

Another treats it as “a new repo for every small piece of logic.”

2. Over-focus on independence

Teams think independence means “split everything” instead of “separate things that change for different reasons.”

3. Fear of merge conflicts or shared ownership

Avoiding coordination by dividing code endlessly is attractive—until everything depends on everything else.

4. CI/CD enthusiasm without restraint

“If it can be deployed separately, it should be deployed separately” leads to chaos.

5. No domain model

Without a clear domain understanding, boundaries follow endpoints—never business logic.

The result:

a fractal explosion of tiny services that nobody understands or controls.

This is just uncontrolled, unimpeded software design without architecture, which leads to a truly unmaintainable mess, that will not just cost you down the line, it will also cost a lot to run it, as it will need one lambda or container per function, and this leads to a massive overhead in the infrastructure, that will cost you as well, as you will have to oversize the infrastructure to cater for the additional overhead. 

3. The Cost: When Services Become Too Small to Be Useful

Nanoservices introduce friction and costs everywhere:

1. Cognitive overload

Developers must understand dozens of repos to make one change.

2. Slow delivery

Every feature requires touching N services, coordinating deployments, and updating contracts.

3. Performance issues

Network latency and cross-service chatter balloon.

4. Operational drag

Monitoring, alerting, dashboards, pipelines—multiplied by hundreds.

5. Versioning hell

Breaking changes ripple through the system like dominoes.

6. Hard-to-find bugs

Failures disappear into the cracks between services.

7. Ownership confusion

Who owns what? Nobody knows.
Or everybody does – which is worse.

8. Maintenance overhead

Since there is often a lot of copy-paste code in such constructs, especially if combined with a specific lack of shared libraries, you will have to fix bugs and security issues, repeatedly.

In short: The “architecture” stops being distributed logic and becomes a massive distributed pain.

4. The False Choice: Monolith or Microservices

When nanoservice chaos becomes obvious, teams usually debate two extremes:

“Should we return to a monolith?”

Pros: simpler, cohesive, easier to understand.

Cons: hard to scale organizationally, risky to evolve if already unstable.

“Should we try to fix the microservices?”

Pros: autonomy, scalability, clear boundaries (in theory).

Cons: the current boundaries are wrong and require a rewrite anyway.

Both extremes are reactionary.

There is a middle ground..
Let’s fix this, calmly and sensibly. 

5. The Better Path: Miniservices

A miniservice is:

  • Organized around a real functional and primarily self-contained domain (think “service”, like “users”, “payment”, “cart”, …).
  • Large enough to contain meaningful logic
  • Small enough to understand
  • Owned by a team
  • Independently deployable
  • Internally cohesive
  • Externally simple 
  • … and, if there are performance or scaling issues, it can relatively easily be split or rewritten, compared to a monolith. 

Think of them as:

“Microservices that actually make sense.”

Not one service per endpoint.

Not one giant ball of everything.

Instead:

  • One domain = one cohesive service (user, wallet, cart, ..)
  • A handful of boundaries instead of hundreds
  • Shared common code and functions  that makes sense. 
  • Stable, well-defined contracts
  • Clear ownership
  • Fewer repos
  • Fewer deployments
  • Fewer failures
  • Easier onboarding
  • Easier refactoring

Miniservices operate as building blocks—not confetti.

6. What Miniservices Look Like in Practice

Each miniservice contains:

  • Its domain logic
  • Its data store (optional but common)
  • Internal modules, not external services
  • Coherent APIs
  • Shared patterns within the domain
  • Consistent error handling
  • Meaningful boundaries

Examples:

Instead of nanoservices like:

user-auth-post/
user-auth-get/
user-session-put/
user-session-delete/


in a microservicce, you typically have:

auth-service/
session-service/

 

and in a broader miniservice:

Instead of 50 small repos for billing, you have:

billing-service/

That includes:

  • invoicing
  • tax rules
  • charge retries
  • refunds
  • billing events

Not because it’s “big”—but because these things belong together, and that it makes perfect sense to group these together in terms of business logic. 

7. The Benefits of Miniservices Over Nanoservices

1. Drastically reduced operational overhead

Monitoring 20 services is hard.

Monitoring 200 is impossible.
Monitoring 500+ – forget it. 

2. Fewer deployments, fewer failures

Bigger services = fewer moving parts = fewer incidents.
When you build a mini service, the moving parts has been integrated tighter directly in the code and not as an external service which means that development  and testing of the integrations and function works in a wholly different way, and you do not run the same risk of introducing bugs by external changes in a foreign api endpoint. 

3. Clearer domain ownership

Teams know exactly what they own and why, and what is in the module/service, and the function of it. 

4. Easier onboarding

New developers learn domains, not random endpoints.

5. More stable contracts

Domains change less frequently than paths and endpoints.

6. Faster delivery

Fewer cross-service dependencies mean less coordination.

7. Real autonomy

Teams can make changes within their domain without touching external services every time.

Miniservices preserve the benefits of microservices without the pathological fragmentation, all while making the domain and function clearer and it’s use more intuitive.

8. A Warning: “Miniservice” Doesn’t Mean “Mini Monolith”

Miniservices are not monoliths in disguise.

They still follow good distributed design:

  • Independent deployability (you redeploy the “user” service etc)
  • Clear domain boundaries (you don’t mix the user and payment services)
  • No shared mutable state
  • Well-defined and documented APIs – use formats like OpenAPI and tools like Swagger/ApiDog to design, generate and test. 
  • Decoupled schemas
  • Versioned contracts
  • No hidden cross-service calls. 

The difference is size and cohesion—not looseness.

9. How to Transition From Nanoservices to Miniservices

1. Identify domains, not endpoints

Look for natural groupings:

  • Billing
  • Authentication
  • Search
  • Cart
  • Profile
  • Notifications
  • Inventory
  • Recommendations

2. Collapse nanoservices into cohesive units

Merge them based on logic, not repo history.

3. Introduce clear domain ownership

One team per domain. No exceptions (well, maybe in small teams – there’s always an exception to the rule).

4. Reduce inter-service chatter

Replace many small calls with internal modules.

5. Establish API contracts that reflect domain responsibilities

Stop mapping endpoints one-to-one.

6. Adopt internal libraries instead of isolated repos

Shared logic doesn’t require a new service.
You could use a shared repo that defines commonly used things such as the database connectivity functions, reading of config files, logging, and other things commonly re-used but rarely changed. 

7. Avoid premature splitting in the future

Split only when two domains evolve independently – be clear about why the split is needed and why you do it.

10. Closing: The Problem Wasn’t Microservices — It Was the Lack of Domain Thinking

Microservices didn’t fail.

The team never defined what a service was, and went to town with the notion that everything is a service, even when it is not.

Nanoservices are what happens when:

  • Endpoints become architectural boundaries
  • Repos become the default unit of structure
  • Autonomy is mistaken for fragmentation
  • Teams split before they understand the domain

The solution is not to swing back to monoliths.

The solution is to adopt sensible, stable, cohesive miniservices.

Miniservices give teams:

  • Autonomy without chaos
  • Flexibility without fragmentation
  • Scalability without sprawl
  • Clarity without over-simplifying
  • Boundaries without bottlenecks
  • Funtional definition and confinement

The solution is not to swing back to monoliths.
The solution is to adopt sensible, stable, cohesive miniservices.

So how do we define a “miniservice”? 

The “miniservice” is a sensible and practical middle-ground approach between the often-unscalable monolith and the pathological microservice hell (nanoservices). It is not a hard definition of size, but a set of logical and practical principles:

  • Logical Cohesion:
    It is a logical and practical grouping of components that belong together, based on a cohesive functional domain (e.g., Billing, Cart).
  • Understandable Scope:
    It isolates business logic into a size that can be easily understood, maintained, and worked on by a single small team.
  • Architectural Flexibility:
    It maintains the ability to be independently deployed and can be split reasonably if independent evolution is genuinely required later.
  • Optimized for Cost and Performance:
    It reduces the massive operational overhead and cross-service communication costs associated with nanoservices while retaining the ability to scale horizontally or vertically more easily than a monolith.

The architecture becomes something everyone can understand—and something the company can grow on, with less costs. 

 (C) (BY) EmberLabs® / Chris Sprucefield

 

Posted on by

Infosec – Time for a New Class of “DevSec”?

Thoughts of the Fractional Chief
TL;DR
Most companies leave a gap between development and security. Developers move fast, and infosec steps in too late, when issues are already hard and expensive to fix.
A new role—DevSec—fills that middle space. DevSec catches insecure patterns early, filters noisy alerts, guides developers with simple and practical advice, and prevents small mistakes from becoming real vulnerabilities. It’s not a replacement for dev or infosec, but a missing function that keeps products safer, reduces rework, and helps teams move faster with fewer surprises.

2025-12 – By Chris Sprucefield.

Most companies still separate development and security into two distant groups. Developers build features, ship code, and keep things going. Infosec teams respond to alerts, run scans and write long lists of issues that often arrive too late in the development cycle to fix without disruption.

This split leaves a gap in the middle.

In the meanwhile, nobody is watching the small decisions and habits that create security risks long before anyone notices them. By the time a formal security review happens, the code has settled and dependencies have grown. The system has become harder to change, and at that point, problems are expensive, frustrating, and often pushed aside because deadlines are tight.

We need a role that fills this gap.

For now, I’ll call it DevSec—not an existing title, but a new class of function designed to sit between development and traditional infosec, focused on preventing problems before they turn into incidents or audits.

What DevSec Is (and Isn’t)

  • DevSec is not a developer who happens to care about security.
  • DevSec is not an infosec analyst who steps in after the fact.
  • DevSec is not a pipeline engineer building scanners or automations.

Instead, DevSec is a practical, hands-on generalist who understands enough about code and coding in general, and enough about security to evaluate risks as they appear and is reported by supporting tools or reviews, not months later. They don’t need deep, specialized expertise in every system, but they need the ability to look at a piece of code or an alert and decide:

  • Is this threat real, or is it noise?
  • Could this pattern cause trouble later if not fixed?
  • Does this issue affect our actual product or environment?
  • What is the simplest fix?
  • … and how do we prevent it from recurring?

The point is not to replace security teams or developers. The point is to augment and support devs at an early stage, prevent avoidable work and avoidable failures by catching issues early – when they are still easy to fix.

Why This Role Matters

1. Developers aren’t meant to be full-time security analysts

Most development teams already deal with tight timelines. Handing them a long list of scanner warnings only slows them down. They need someone who filters out the noise and highlights the few things that truly require attention.

2. Traditional security looks at problems too late

Security teams often depend on completed features, logs, or external scans. They step in only after code is written, patterns are set, and risky habits have already spread through the codebase. Furthermore, traditional infosec teams does often does not have the budget for this, and are they are typically ill-equipped to review code or being very hands-on, as their primary focus is typically on process, procedure and higher level systematic security. 

3. The space in between is where most vulnerabilities are born

Unsafe defaults, repeated shortcuts, overly permissive functions, straight AI copy and paste issues, SQL injections and many other common bad or lazy practices, and forgotten test logic – these are the seeds of future incidents, and they form quietly in day-to-day development, especially when the pressure to deliver is high, or perhaps, the development team is young. 

A DevSec function sees these before they harden into real vulnerabilities.

What DevSec Actually Does

Here’s what this role focuses on:

  • Reviewing code for insecure patterns without requiring full developer depth.
  • Triaging alerts from automated tools to identify what matters and what doesn’t.
  • Spotting bad practices early and nudging the teams to correct them.
  • Explaining risks in simple, practical and actionable terms.
  • Offering targeted suggestions for fixing problems now and avoiding them later.
  • Keeping the security posture aligned with how the product actually works.

This is early-stage, practical prevention—not bureaucracy, not policy writing, and not firefighting.

The Benefit to the Whole Team

With DevSec in place:

  • Developers get fewer false alarms and clearer guidance.
  • Security teams receive fewer late-stage surprises.
  • Risk is primarily handled at the point of creation instead of after release.
  • Bad habits are corrected early, reducing long-term maintenance pain.
  • The product becomes naturally more secure without slowing down delivery.
  • When there are external threats, Developers will get help to determine the focus for fixes.

This helps companies avoid the familiar cycle of security issues suddenly piling up right before an audit, or surfacing only after customers report something unexpected.

A nice side-effect is that it is highly likely to save money for the company by less late-stage costly fixes and revisits (time that can be spent on developing products), all while delivering a safer product, which in turn will improve the goodwill and market reputation among it’s customers.

Why DevSec Is Needed Now

Many companies are now building faster, integrating third-party tools constantly, and relying heavily on automated systems. The pace of change means small missteps compound quickly. Traditional security functions can’t keep up with that pace if they’re only brought in late. Developers can’t shoulder responsibility for everything either—they’re not equipped, and it’s not realistic.

Classic Infosec teams primary focus is on the bigger picture, processes and procedures, and while very good at what they do, they are typically not very hands-on. 

The midpoint has been empty for too long.

A dedicated DevSec role fills that gap and brings steady, ongoing security awareness into the daily rhythm of development, without overwhelming anyone.

This isn’t about introducing another layer of process. It’s about putting someone in the spot where issues actually appear—right where code is written, habits form, and risks begin.

DevSec is the missing piece that makes that possible.

 

(C) (BY) EmberLabs® & Chris Sprucefield

Posted on by

1PassMapper – updated.

Not too long ago, we published this article about the 1PassMapper.
( article: http://emberlabs.tech/2025/09/18/1passmapper )

Guess what?
It just got updated with a couple of new items to make it even more powerful!

We just added the flags -prefix <path> and -token <filename> .

The -prefix allows you to have the same build script prepend the source paths in the template, using a single template for all your environments, instead of multiple files, moving the prefix of the path into an argument.

In the template, you would use something like [[some.path.to.cred]],  and with the -prefix dev , the real path would be: [[dev.some.path.to.cred]].

Replace the `-prefix dev` with -prefix prod, and now, you would use the “prod” source path in your credentials file.

The -token <filename>` ?  – this is how you can easily switch from using the default 1Password token file to some other token file allowing you the use of multiple 1Password accounts for different needs.

Get your team onboard with keeping the creds out of the GIT!

Get your copy today – It’s free!
https://github.com/emberlabstech/1PassMapper

Njoy!!

 

Posted on by

Handling gaps in Your CV as a contractor or self-employed professional

TL;DR:
Register a trading name (and TM), use it as your employer on your CV, describe your roles, and treat clients as projects, not jobs.
This provides a seamless, professional timeline—no gaps, and full legitimacy.

The longer reasoned version…
If you are looking for a new position, gaps in your CV can raise questions, especially if you work as a contractor or are self-employed.
Here’s a practical approach, that can solve these issues, and provide a solid timeline.

  1. Register a Trading Name:
    Even as a sole trader, register a trading name for your business. In most countries, this is inexpensive and can also be registered as a trademark (™), giving your business added credibility. Just choose the trading name you want to work with, and typically, within EU, a national registration is ~100 euro.
    This also gives you a VERY strong legal protection for your trading name, and you can prevent others from using it in your class.
    It is even stronger protection than registering a busines name with the companies house…
    Also, register this as a “wordmark” for maximum protection, as this enables you to incorporate the name in any graphical setting, as otherwise, a trademark would be linked and limited to the specific graphical representation that has been registered, as a wordmark allows you to use it in ANY graphical, logo or font setting, as it is the “word” itself that is protected, not how it is represented.

  2. Trade Under Your Registered Name:
    Conduct all your business activity using your trading name.
    Use this name consistently on all invoices, contracts, and professional correspondence.

  3. Present Your Trading Name as Your Employer:
    On your CV, list your trading name (and TM, if registered) as your employer.
    Your self-employment under your own company or trading name is a perfectly valid and legal form of employment, and way of representing yourself on the market.

  4. List Roles, Not Clients:
    Instead of listing each client as a separate employer, describe your roles and responsibilities under your trading name, and optionally mention key clients or projects as examples.
    This creates a single, continuous timeline of employment and avoids unexplained gaps.

Example:

Period Employer Role Details
2015–Present ACME Consulting™ Owner/Consultant Provided IT consulting to various clients…
[list of clients, and summary types of work / roles for the clients]

The benefits?

  • Ensures a consistent work history with no unexplained gaps.

  • Enhances professional image with a registered TM.

  • Allows you to maintain confidentiality about clients if needed.

  • Factually correct: Self-employment under a trading name is a legal form of employment.

  • Common practice: Many experienced contractors use this method to avoid the appearance of gaps.

  • Protects client confidentiality and avoids cluttering the CV with short stints.

  • Removes bias – Employers often hesitate if they see gaps or too many short contracts; this format presents stable, ongoing work.

Possible caveats?

  • Some HR may request clarification about what you did for that period—be ready with a project/client list if asked.
    Any non-client periods, can be explained as self-investment in training, working on internal products and otherwise.

  • In some industries (e.g., government, finance), disclosure of clients may still be required at later stages.
    This is technically not a problem, and you would have the invoicing and other items to show, as well as self-investment as cover for gaps.

Good luck!

Posted on by

Contractor vs Employee?

Consultants/Contractors vs Employee – A side by side comparison

Which one? Or both?
A seemingly never-ending and long-standing dilemma for many decision-makers and businesses is whether to use employees or consultants/contractors (hereafter, contractors).

When choosing between contractors and employees, it’s a common perception that contractors are for short-term and employees are for long-term commitments, and contractors are very expensive, but this does not generally hold true as of today.

In either case, one needs to consider real factors like flexibility, cost-effectiveness, and specialized expertise. Contractors offer targeted skills ideal for equally short-term specific projects without long-term commitments, or general long-term commitments and continuity, if properly managed by the provider, while employees has the ability to bring continuity and deeper integration into your organization’s culture. It is all down to what your priorities and goals are.

Shifting preferences. 
Also, in today’s world, the sentiment of many highly skilled and professional workers have shifted a lot as of recent years, with them becoming contractors rather than employeers, and being a contractor have become a new common form of employment, offering a greater flexibility as seen to the business side of things, and one that can equally come to become a longer term part of the business with an equal level of commitment, if done right.

The longevity of commitment claim is especially at stake here, as it is today common for employees to change jobs in the range of every two to four years, sometimes more often, negating the long-term engagement claim, and price-wise, there is not much of a realistic difference between the two anymore. 

The net result of this, speaks in favor of the contractor, not just purely from the business perspective.

Side by side:
Take a look at these two quick summaries, side-by-side examples on comparable levels: 

Contractor/Consultant
Contractor: 550/day over 44 weeks.

No additional costs of:

  • Paid holidays
  • Sick leave
  • Employer NI
  • Pension match
  • Bonuses
  • Training

Benefits (their selling points)

  • Flexibility
  • Preserved continuity by well-managed service provision
  • Pre-defined documented skills and knowledge
  • Little to no onboarding costs/time.
  • Only paid for days working
  • Break clauses based on work
    or project requirements.
 Employee
Permanent employee: 75K salary over 44 weeks.

Additional costs to consider:

  • Employers NI  ~10%-15% (7,500 – 11,250)
  • Pension match  ~5% (750)
  • Bonus ~10% on average (7,500)
  • Recruitment fee ~15-20% (11,250 – 15,000)
  • Statutory 20 days PTO (or more)
  • Statutory sickness leave (up to ~15 days)

Other types of common costs (benefits) include (estimates per year):

  • Private Medical/Dental Insurance,
    €500 – €3,000
  • Voucher Schemes, €500-€2,500
  • Employee Wellbeing Programs,
    €100 – €1,000+.
  • Away Days, Parties, and Events,
    €50 – €500+ per-event. (3/y)
  • Equipment and Tech Costs, €500 – €2,000

Office space average cost across EU p/a and employee: €7500 (range: 3.9-15k/y)
This includes rent, maintenance, supplies. 
Total: 550/day for 44 weeks – €121K  Total Year 1: €121 – €148K (€134.5k)
Total Year 2+: €108 – €135k (€121.5k)

Today, and so far in this comparison, it is pretty much like-for-like, cost-wise, but with added benefits for both parties, but it does not stop there. 

The contractor, in greater self-governance, albeit at somewhat greater risks and contractual committments, and for the business, it’s a more well-defined commitment with a known entity and lesser set of risks in cases of non-performance and similar issues. 

The hidden costs:
Additionally, there are likely considerable company overheads in HR, Legal, and compliance due to the costs required to maintain employee records, manage disputes management, conduct reviews, provide training, and many other functions. These are commonly not required for contractors, due to their contractual self-governance.

It doesn’t stop there,  as for the staff, the business usually has other overheads not covered in the above, such as parking, office space, heating, energy, office supplies and additional factors that needs to be added to the costs of the employee, which for the contractor is mainly or wholly covered by themselves at their own expense. The cost of this has been summarized above as a range, and is based on 15sqm/employee and year, as an average across EU, for both cowork and outright rented spaces. 

As for the longevity and company culture, the relatively small cost of including contractors to company events, parties, etc, will be greatly outweighed by the benefits, and still be a tax-deductible, as it is  now supplier entertainment. One just needs to be careful about the anti-bribery regulations. 

As you can see, after the first year, contractors and employees are on par or cheaper, without the loss of productivity or protection for your business, and in the end, with all things considered, it is a win-win situation for both parties, business and contractor, offering the greater flexibility.

Summary: 
If you take all of the hidden business overheads as listed above into account, you will likely soon see that the contractor is actually the cheaper option overall, with the same or greater business benefits.
The primary question now comes down to:

  • Are you willing to have consultants and allow them to work remotely? 
  • Are you willing to trust the people you hired to work for you, to do their job? 

If the answer is yes, then, you have just widened your recruitment basis and access to qualified staff.