FAQ

• What does “Infrastructure as Microservices” actually mean?

  It means your infrastructure-as-code is built from a library of small, self-contained, independently versioned modules. Each module handles one thing well: networking, compute, storage, a database, monitoring, a security baseline. You compose those tested building blocks into full environments instead of writing infrastructure code from scratch for every project.

   

• Why not just build our own module library?

  You can, and many teams do. But it takes months or years of development, testing, and iteration before the first project ever deploys from it. Yahara has already done that work. Our library is built, documented, and validated through automated and manual testing. The infrastructure is integrated into your environment within a few weeks. 

• We already have infrastructure-as-code in place. Does this replace it?

  It replaces the ad-hoc, drifted, project-by-project code that has become hard to maintain. If your teams have accumulated different implementations of the same patterns that can no longer be updated in bulk, the versioned modules become the single source those patterns come from. Existing workloads are migrated progressively, with validation at each step and rollback capability maintained throughout. 

• How long until we are deploying from the library?

  The full delivery timeline from scoping through deployment (Phase 0 to Phase 2) runs 4 to 8 weeks, depending on the complexity of your environment and the scope of migration. A team that builds a library from scratch typically invests months or years before the first project deploys. 

• Do we keep the modules if we don’t continue with Yahara?

  Yes. The module library and all configuration artifacts are yours at the conclusion of Phase 2, regardless of whether you continue with Yahara for ongoing support. Phase 3 — ongoing module updates, new template development, and access to the registry as it evolves — is optional. 

• How does this reduce our maintenance burden over time?

  Because projects run off of shared, versioned modules rather than owning their own copies of the code. Security fixes, performance improvements, and compliance updates made to a module will automatically propagate to every project during a software update. As your infrastructure portfolio grows, the cost of maintaining it remains the same.

• What infrastructure does the module library cover?

  The library covers the components most organizations deploy repeatedly: networking, compute, storage, databases, load balancing, monitoring, and security baselines. Modules follow a consistent interface design, are independently versioned, thoroughly documented, and validated through automated and manual testing.