Get Appointment

contact@wellinor.com
+(123)-456-7890

Blog & Insights

Keyva is pleased to announce the certification of the Keyva Service Integration Hub for Red Hat Ansible Automation Platform for the new ServiceNow Zurich release. Clients can now seamlessly upgrade their ServiceNow App from previous ServiceNow releases (Yokohama, Xanadu) to the Zurich release.

The ServiceNow Zurich release delivers enhanced AI-driven workflows, improved user experiences, and expanded automation capabilities to increase productivity, resilience, and service efficiency across the enterprise.

Keyva's Service Integration Hub for Red Hat Ansible Automation Platform allows users to initiate and manage Ansible automation tasks directly from ServiceNow Catalog Requests, Change Requests, and more. Users have the flexibility to configure custom triggers and define specific conditions for launch, ensuring that any approvals established within ServiceNow are completed before the corresponding Ansible job is initiated. This integration allows organizations to fulfill IT automation requests through Ansible Automation Platform from a centralized ServiceNow service catalog, without requiring additional ServiceNow licensing such as Orchestrator or Integration Hub.

Learn more about the Keyva Service Integration Hub for Red Hat Ansible Automation Platform and view all the ServiceNow releases for which Keyva has been certified at the ServiceNow Store: store.servicenow.com.

Keyva is pleased to announce the certification of the Keyva Service Integration Hub for Red Hat OpenShift for the new ServiceNow Zurich release. Clients can now seamlessly upgrade their ServiceNow App from previous ServiceNow releases (Yokohama, Xanadu) to the Zurich release.

Keyva's Service Integration Hub for Red Hat OpenShift allows users to trigger Red Hat OpenShift build jobs directly from ServiceNow Catalog Requests, Change Requests, Incident Requests, and more. Users have the flexibility to configure custom triggers and define specific conditions for launch, ensuring that any approvals established within ServiceNow are completed before the corresponding OpenShift deployment job is initiated. This integration allows organizations to fulfill IT automation requests through OpenShift from a centralized ServiceNow service catalog, without requiring additional ServiceNow licensing.

Learn more about the Keyva Service Integration Hub for Red Hat OpenShift and view all the ServiceNow releases for which Keyva has been certified at the ServiceNow Store: store.servicenow.com.

[post_title] => Keyva Service Integration Hub for Red Hat OpenShift Certified for Zurich Release [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => keyva-service-integration-hub-for-red-hat-openshift-certified-for-zurich-release [to_ping] => [pinged] => [post_modified] => 2026-05-26 12:48:53 [post_modified_gmt] => 2026-05-26 12:48:53 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5238 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 5233 [post_author] => 15 [post_date] => 2026-05-19 12:43:11 [post_date_gmt] => 2026-05-19 12:43:11 [post_content] => For a long time, "just run it on VMware" was the lowest-risk answer in the room. Most teams treated it as infrastructure they didn't need to think too hard about. It was stable, operationally familiar, and usually predictable from both a support and budgeting standpoint. That calculus changed fast. After Broadcom's acquisition closed, the licensing model shifted dramatically. Customers who had been paying predictable per-socket costs woke up to per-core bundles that in some cases tripled their annual spend overnight. And for organizations also running Tanzu for Kubernetes, the hit was compounded. We started getting calls in early 2024 from infrastructure leads who weren't just unhappy, they were in genuine budget crisis and being asked to justify costs they'd never planned for. The honest answer we give clients is this: the technology alternatives are real and mature. The challenge usually isn't finding alternatives anymore. It's figuring out whether those alternatives will behave properly once your real workloads, operational processes, and failure scenarios are sitting on top of them. Why Most Platform Evaluations Miss the Real Risks Most infrastructure teams do evaluate alternatives. They read vendor documentation, sit through demos, maybe spin up a test cluster. What they almost never do is run their actual workloads - the ones that matter - against the candidate platform under realistic conditions. We worked with a financial services client a few months back that had already gone through a traditional RFP process and selected a replacement platform. By the time they brought us in, they were three months into implementation and starting to discover that their PostgreSQL clusters, which handle transaction processing, behaved very differently under their access patterns than the vendor benchmarks had suggested. Latency was inconsistent in ways that didn't show up during the proof of concept because the PoC used synthetic data and none of the actual query patterns that the application generates under load. They weren't in crisis yet. But they would have been if they'd migrated production. That scenario is more common than people admit. The gap between a vendor's reference architecture and what your environment actually does is where migrations fail.

What a Structured Framework Actually Changes

When we run a Virtualization Migration Assessment, the thing that changes isn't the depth of documentation - it's that we test your workloads, not representative ones. That means standing up PostgreSQL with your schema and your query load. That means running Kubernetes with your application manifests and your resource profiles. That means subjecting the candidate platform to the failure conditions you actually worry about at 2 am. For a healthcare organization we worked with earlier this year, the Kafka throughput numbers were the deciding factor. They were considering two platforms that scored nearly identically across most capability domains. On paper, both were viable. Under load with their actual event volumes and partition configurations, one of them degraded in ways that would have caused real problems for their patient data pipeline. The other didn't. That's not a result you get from reading whitepapers. The framework evaluates platforms across more than 15 domains, including - networking, storage, Day-2 operations, migration tooling, licensing model, observability, and more. But the workload validation is what makes the rest of it trustworthy. Scores without evidence are just opinions.

Making the Decision Stick

The other thing we've learned is that these decisions have to survive a room full of skeptics - the application team that's worried about their deployment pipeline, the security team that has questions about network segmentation, the CFO who wants to understand the TCO comparison. Our deliverable is built for that room: scored comparisons, performance benchmarking results, and a migration roadmap that has actual phases with actual sequencing. By the time an organization starts moving production workloads, there should already be confidence in how the platform behaves under real operational conditions. That's ultimately what the assessment is trying to establish before the migration becomes expensive to reverse. That's what a framework is for. Keyva's Virtualization Migration Framework is available as a Lite, Core, or Premium engagement. Reach out at info@keyvatech.com to discuss your environment. [table id=3 /] [post_title] => When VMware Stopped Being the Safe Choice [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => when-vmware-stopped-being-the-safe-choice [to_ping] => [pinged] => [post_modified] => 2026-05-19 12:43:11 [post_modified_gmt] => 2026-05-19 12:43:11 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5233 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [3] => WP_Post Object ( [ID] => 5230 [post_author] => 7 [post_date] => 2026-05-18 14:57:56 [post_date_gmt] => 2026-05-18 14:57:56 [post_content] => Keyva applies a structured, workload validated approach to virtualization platform replacement that helps organizations make informed, high confidence decisions.

Who This Is For

This post is for infrastructure architects, platform engineers, and IT leaders evaluating a virtualization platform migration -- whether you're moving off VMware following licensing changes, reassessing your hypervisor strategy, or trying to build a defensible business case for a platform decision that carries serious financial and operational risk.

Replacing your virtualization platform is not a routine infrastructure project.

It's a decision that touches every workload in your environment. It affects performance, operations, licensing cost, and your team's ability to manage things on an ongoing basis. Done poorly, it creates years of technical debt. Done without sufficient data, it creates organizational risk that's hard to walk back.

Most organizations know this going in. What they often underestimate is how difficult it is to make the decision well.

The Problem With How Most Virtualization Assessments Get Done

The typical approach goes something like this: evaluate a few platforms, collect some vendor documentation, run a proof of concept on a non-critical workload, and use the results to make a call.

The problem is that vendor-provided comparisons are built to favor the vendor. Theoretical architecture reviews don't account for how your specific workloads actually behave under load. A proof of concept on a low-stakes workload doesn't tell you much about how a stateful database or a high-throughput streaming platform will perform after migration.

The result is a decision that looks defensible on paper but is built on a shaky evidentiary foundation. And when something goes wrong post-migration -- performance degradation, operational complexity that wasn't anticipated, licensing costs that didn't show up in the original model -- there's no data trail to understand why or how to fix it.

That's the gap Keyva's Virtualization Migration Framework is designed to close.

What a Workload-Validated Migration Assessment Actually Looks Like

The framework evaluates candidate platforms across more than 15 capability domains using a weighted scoring model with defined threshold criteria -- not a subjective review. Every platform gets measured against the same standard.

Scope of Evaluation

The assessment covers the full operational picture, not just raw performance:

Virtual machine and container platform capabilities
Networking, storage, and security
Operational maturity and Day-2 readiness
Migration feasibility and tooling
Performance, scalability, and resilience
Observability and automation
Licensing model and total cost of ownership

Workload-Based Validation

The most important differentiator in the framework is real workload testing. Candidate platforms are validated against representative, production-like workloads -- not synthetic benchmarks. This includes:

Stateful database workloads (PostgreSQL) -- evaluated for performance under load, storage behavior, and failure recovery
Containerized application workloads (Kubernetes) -- evaluated for scaling behavior, elasticity, and Day-2 operational complexity
High-throughput streaming workloads (Kafka) -- evaluated for throughput stability, network characteristics, and resilience

Each workload is tested across performance and stability under load, scaling and elasticity, failure recovery, storage and network characteristics, and operational complexity. Results are benchmarked like-for-like against your current virtualization environment so comparisons are grounded in your actual baseline -- not a vendor reference architecture.

What the Assessment Delivers

The framework produces structured deliverables built for both technical and executive audiences:

Standardized evaluation framework and scoring model
Detailed workload validation and proof of concept test plan
Comparative vendor scorecards
Performance benchmarking results
Cost and licensing analysis including total cost of ownership
Migration strategy and phased roadmap
Executive-level decision recommendation

The goal is to give infrastructure, platform, and application teams shared visibility into the tradeoffs -- and give leadership a recommendation they can act on with confidence.

Frequently Asked Questions About Virtualization Platform Migration

How do I know which virtualization platform is the right replacement for VMware?

There's no universal answer -- it depends on your workload mix, operational model, team capabilities, and cost constraints. The right approach is to evaluate candidates against your specific requirements using real workload data, not vendor positioning. Platforms that perform well on generic benchmarks don't always perform well on stateful databases or high-throughput streaming workloads. A structured, workload-validated assessment gives you the data to make that call for your environment.

What should a virtualization migration assessment include?

At minimum: a standardized evaluation framework applied consistently across all candidate platforms, real workload testing against production-representative systems, a financial model that includes licensing, infrastructure, migration effort, and ongoing operational cost, and a like-for-like performance comparison against your current environment. Assessments that rely primarily on vendor documentation or theoretical architecture reviews tend to produce decisions that don't hold up once migration begins.

How long does a virtualization migration assessment take?

It varies based on the number of platforms being evaluated and the complexity of the workload testing, but a structured framework-based assessment typically runs several weeks from scoping through deliverables. Workload validation and benchmarking are the most time-intensive components -- they're also where the most useful data comes from.

What are the biggest risks in a virtualization platform migration?

The most common sources of migration risk are: underestimating the operational complexity of Day-2 management on a new platform, workloads that perform differently than expected after migration (particularly stateful databases and high-throughput systems), licensing cost models that look favorable upfront but scale poorly, and misalignment between infrastructure teams and application owners on migration sequencing and risk tolerance. A validated assessment surfaces most of these before you commit.

How is Keyva's approach different from a vendor-led assessment?

Vendor-led assessments are optimized to support the vendor's platform. Keyva's framework is vendor-neutral -- the same evaluation criteria and scoring model apply to every candidate platform. Workload testing is done in your environment or a representative equivalent, and results are benchmarked against your current baseline. The output is a recommendation built on measured data, not positioning.

What does virtualization migration cost, and how do you evaluate total cost of ownership?

Total cost of ownership for a virtualization platform migration includes platform licensing (often the most visible cost), infrastructure changes required to support the new platform, migration tooling and labor, retraining and operational ramp-up for the team managing the new environment, and any application-layer changes required by the migration. Licensing models vary significantly across platforms -- some that appear cost-effective at initial licensing scale in ways that create surprises at renewal or at growth. A thorough TCO analysis models cost across a multi-year horizon, not just year one.

When is the right time to start a virtualization migration assessment?

Earlier than most organizations start. By the time a contract renewal forces the decision, timelines are compressed and leverage is limited. Organizations that assess their options 12-18 months before a licensing event have room to run a thorough evaluation, complete workload validation, and plan a phased migration without operational risk. If you're already inside that window, a faster-paced assessment focused on the highest-priority workloads is still more defensible than a decision made without data.

The Decision You Make Here Has a Long Tail

Virtualization platform decisions don't resolve quickly. The platform you choose will shape how your infrastructure team operates for years. Migration complexity, Day-2 tooling, licensing model changes at renewal, performance headroom for future workloads -- all of it flows from the decision you make now.

The organizations that get this right tend to share one thing: they invested in getting real data before committing. Not vendor claims. Not theoretical comparisons. Actual workload performance in an environment that resembles their own.

That's what a structured migration assessment is for.

[post_title] => Virtualization Migration Framework: How to Choose a Platform With Confidence [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => virtualization-migration-framework-how-to-choose-a-platform-with-confidence [to_ping] => [pinged] => [post_modified] => 2026-05-18 14:57:56 [post_modified_gmt] => 2026-05-18 14:57:56 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5230 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [4] => WP_Post Object ( [ID] => 5227 [post_author] => 7 [post_date] => 2026-05-18 14:50:12 [post_date_gmt] => 2026-05-18 14:50:12 [post_content] =>

The Keyva AI Enablement Workshop bridges this gap through a structured, hands on engagement. Rather than focusing on theoretical training, this workshop works directly with your teams, tools, and operational data to design and validate practical AI driven use cases that can be immediately applied and scaled.

Who This Is For

This post is for infrastructure engineers, operations leaders, and platform teams who are under pressure to do more with AI but haven't found a path from experimentation to something that actually runs in production. If your team manages observability pipelines, incident response, or ITSM workflows -- and you're tired of AI training that doesn't connect to your real environment -- keep reading.

Most infrastructure and operations teams are already feeling the pressure.

Improve reliability. Cut incident resolution times. Scale operations without growing headcount. And somewhere in that list: do something with AI.

The challenge isn't usually awareness. Most teams know AI can help with alert summarization, runbook retrieval, ticket triage -- the high-friction, repetitive work that consumes hours every week. The challenge is getting from "we should probably explore this" to something that actually works in your environment, with your data, connected to your actual tools.

Generic AI training doesn't close that gap. Vendor demos don't either.

Why Most AI Initiatives Stall Before They Scale

The pattern we see most often: a team runs a proof of concept, gets promising results in isolation, and then the initiative sits. Production deployment raises questions nobody scoped for -- data handling boundaries, integration with ServiceNow or Jira, human-in-the-loop controls, auditability requirements. The gap between "prototype" and "production-ready" turns out to be wider than expected.

The other common version: the organization invests in an enterprise AI platform -- Microsoft Copilot, Azure OpenAI, Claude -- and then spends months figuring out how to actually operationalize it for infrastructure use cases. The capability is there. The practical application isn't.

That's the gap the Keyva AI Enablement Workshop is built to close.

What a 3-Day AI Enablement Workshop Actually Covers

The engagement is structured across three phases, designed to move from alignment to working prototypes to an executable roadmap -- all within the workshop itself.

Phase 1: Context Alignment and Discovery

Before any development starts, the workshop establishes shared context across platform engineering, operations, and security stakeholders. This phase covers:

Identification of key operational pain points: incident response, alert fatigue, ticket quality
Review of existing tools and workflows across observability, ITSM, and CI/CD
Evaluation of available data sources -- logs, alerts, tickets, runbooks -- and their readiness for AI application

Deliverable: Data readiness validation and workshop alignment summary.

Phase 2: Hands-On AI Use Case Development

This is where the workshop does the actual work -- live, collaborative development using your real tools and data. Two to three AI-powered operational use cases are designed and prototyped during this phase. Common examples include:

Incident Copilot -- automated summarization and analysis of alerts and logs to reduce triage time
Runbook Assistant -- natural language retrieval from internal documentation so engineers can find answers faster
Ticket Enrichment Engine -- automated classification and enhancement of incoming tickets to reduce manual handling

The workshop is platform-agnostic. Implementation uses whichever enterprise AI platform fits your environment -- Microsoft Copilot via Azure OpenAI, Claude, or both. Prompt engineering, response tuning, and comparative model analysis are included.

Deliverable: Working prototypes, reusable codebase, and a prompt library.

Phase 3: Optimization and Roadmap

Prototypes that can't reach production aren't useful. This phase focuses on architecture design for real-world deployment and covers:

Azure-native or hybrid deployment models
Integration patterns for ITSM platforms (ServiceNow, Jira), collaboration tools (Teams, Slack), and observability pipelines
Security and governance requirements: data handling boundaries, human-in-the-loop controls, auditability and compliance
Prioritization of use cases by effort and business impact
A 30/60/90-day implementation roadmap
Executive readout and strategic recommendations

Deliverable: Architecture blueprint, implementation roadmap, and executive readout.

What Teams Walk Away With

By the end of the three-day engagement, infrastructure and operations teams have:

Working prototypes built on their own tools and data -- not generic demos
A reusable prompt library tuned for operational accuracy
A clear architecture blueprint for production deployment
An implementation roadmap with prioritized next steps and realistic timelines
Reduced ambiguity around governance, security, and integration requirements

The practical outcome is faster incident triage, less time spent on manual ticket handling and runbook navigation, and a structured path to scale AI across infrastructure and operations -- rather than another stalled pilot.

Frequently Asked Questions About AI Enablement for Infrastructure Teams

What kinds of AI use cases are most valuable for infrastructure and operations teams?

The highest-impact starting points are typically incident triage and alert summarization (reducing the time it takes to understand what's happening during an incident), runbook and knowledge retrieval (giving engineers natural language access to internal documentation), and ticket enrichment (automated classification and context-gathering for incoming service tickets). These use cases address high-volume, repetitive work with measurable time savings.

How is this different from AI training or a vendor demo?

Training and demos work from generic scenarios. This workshop works from your actual operational environment -- your logs, your runbooks, your ticketing workflows, your observability stack. Prototypes are built against real data, and the architecture is designed for your production constraints, not a reference environment.

Which AI platforms does the workshop support?

The workshop is platform-agnostic. It is designed to work with Microsoft Copilot via Azure OpenAI, Claude (Anthropic), or a combination of both. Comparative model analysis is part of the hands-on development phase.

How do you handle security and governance concerns?

Security and governance are addressed explicitly in Phase 3. This includes data handling boundaries, human-in-the-loop controls, and auditability and compliance requirements. These aren't afterthoughts -- they're built into the architecture design before any production deployment recommendation is made.

What does a team need to have in place before the workshop?

The discovery phase at the start of the engagement assesses data readiness and tool availability. Teams don't need to have everything perfectly in place -- part of Phase 1 is identifying what's available and what gaps exist. Having access to representative operational data (logs, alerts, tickets, runbooks) and relevant stakeholders from platform engineering, operations, and security helps the workshop move faster.

How long does it take to go from workshop to production?

That depends on the complexity of the use cases and the organization's deployment environment. The workshop delivers a 30/60/90-day roadmap that prioritizes use cases by effort and impact. Simpler automation use cases can often reach production within 30 days. More complex integrations with ITSM platforms or observability pipelines typically take longer.

What if our team has already started an AI initiative that hasn't gained traction?

That's actually a common starting point. The workshop's discovery phase is designed to assess where existing efforts stand, identify what's blocking progress, and build from what's already in place rather than starting over. If you have prototypes or partially implemented use cases, those can be incorporated into the engagement.

The Difference Between Experimenting with AI and Operationalizing It

There's a real gap between running a successful proof of concept and having something that runs reliably in production, integrates with your existing tools, meets your governance requirements, and actually gets used by the team.

Most organizations that are struggling to scale AI aren't struggling because the technology doesn't work. They're struggling because the path from experimentation to operationalization is more complex than a demo suggests -- and they haven't had a structured way to work through it.

That's what the Keyva AI Enablement Workshop is designed to address.

[post_title] => AI Enablement Workshop for Infrastructure and Operations Teams [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => ai-enablement-workshop-for-infrastructure-and-operations-teams [to_ping] => [pinged] => [post_modified] => 2026-05-18 14:50:58 [post_modified_gmt] => 2026-05-18 14:50:58 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5227 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [5] => WP_Post Object ( [ID] => 5224 [post_author] => 7 [post_date] => 2026-05-15 15:33:37 [post_date_gmt] => 2026-05-15 15:33:37 [post_content] => Most engineering leaders I talk to can tell you roughly what their cloud bill looks like. “Somewhere around $150K a month.” “Azure went up again this quarter.” “AWS feels higher than it should.” But if you ask where the spend is actually coming from, things get fuzzy pretty quickly. Which teams are driving the increase? How much of the spend is production versus lower environments? How many resources are sitting mostly idle? How much storage has been accumulating for years because nobody wants to risk deleting it? Those answers are usually harder to get than people anticipate. And honestly, that’s understandable. Cloud environments evolve fast. New subscriptions get added. Teams spin up workloads to solve immediate problems. Projects end, but the infrastructure behind them doesn’t always disappear with them. Over time, the cloud bill becomes something organizations react to instead of something they actively manage. We see it constantly. Development environments running full weekends because nobody ever implemented shutdown automation. Large database tiers sized for peak usage that only happens a few days a month. Old snapshots, unattached disks, forgotten load balancers, reserved instance opportunities nobody had time to evaluate. None of it looks catastrophic on its own. Together, it becomes real money. That’s why we stopped approaching cloud cost optimization as a “recommendation exercise.” Most teams already know they probably have waste. Usually, the problem is not that teams are ignoring cloud costs. It’s that the cleanup work never becomes urgent enough to pull people away from delivery deadlines, production support, or platform work already in flight. Most environments already have savings opportunities sitting there - somebody just needs the time to trace through the billing data, validate what is actually being used, and make the changes carefully enough that nothing critical gets disrupted. That was really the reason we turned this into a structured sprint instead of just another assessment. The engagement starts with discovery and billing analysis across the environment. We look at tagging quality, utilization trends, resource inventory, and how costs break down across teams, applications, and environments. The goal is to get past generalized assumptions and identify where spend is actually occurring. From there, we move into analysis and prioritization. Compute right-sizing, storage cleanup opportunities, licensing optimization, lifecycle automation gaps, and unused resources all get reviewed with projected savings attached to each item. But the important part is implementation. We apply the quick wins during the engagement itself. Budget alerts. Automated shutdown schedules for dev and test workloads. Tagging enforcement. Infrastructure-as-code updates for repeatable governance patterns. By the end of the sprint, organizations are usually already seeing measurable reductions in spend. One recent engagement involved an organization operating across eight Azure subscriptions with monthly cloud costs around $180,000. In that environment, lower-tier workloads were basically running all the time whether anybody was using them or not. Tagging standards had drifted differently across teams over the years, and several systems had simply been sized larger and larger without anyone revisiting whether the capacity was still necessary. About six weeks later, monthly spend was down by close to $20,000. There was no major migration project behind it and no application redesign effort. Most of the improvement came from cleaning up the environment, tightening governance a bit, and fixing the kind of operational drift that slowly builds up in long-running cloud environments. Nobody wants an open-ended consulting engagement just to figure out why their cloud bill increased. In most cases, the savings offset the engagement cost fairly quickly. The long-term value is usually bigger than the initial savings anyway. Once teams finally have visibility into where costs are coming from, and with some basic guardrails in place, the environment tends to stay much healthier over time instead of gradually drifting back into the same patterns. At a certain point, most organizations can tell when the cloud bill has turned into something they simply accept every month instead of something they actively manage. That’s usually the point where it makes sense to step back and take a closer look at it. Download our Cloud Cost Optimization sprint overview [table id=3 /] [post_title] => Your Cloud Bill Is an Unmonitored Process. Here's How to Trace It. [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => why-your-cloud-bill-keeps-growing-and-how-to-fix-it [to_ping] => [pinged] => [post_modified] => 2026-05-15 15:33:37 [post_modified_gmt] => 2026-05-15 15:33:37 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5224 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [6] => WP_Post Object ( [ID] => 5218 [post_author] => 7 [post_date] => 2026-05-12 19:00:44 [post_date_gmt] => 2026-05-12 19:00:44 [post_content] => I've had some version of the same conversation with engineering leaders more times than I can count: "Our pipelines aren't great… but we know what's wrong. We just need time to fix it." A couple years ago, I would've nodded and moved on. Now I push back. Not because they're wrong, but because they're usually only seeing part of it. In almost every environment we've assessed, teams can point to a handful of real problems. Slow builds. Flaky deployments. Maybe some test instability that everyone has quietly agreed to tolerate. Those things are real, and they matter. But they're rarely what keeps me up at night. What we keep finding are the things that stopped feeling like problems years ago. Long-lived credentials that were supposed to be temporary. Branch protections that exist in the settings but get bypassed under deadline pressure. Pipeline logic that was copy-pasted between repositories and has since drifted in six different directions. No one made a bad decision, things just accumulated. Individually, none of it feels urgent. But when you look at the whole picture, the exposure adds up fast. The engagement that really changed how we work was with a large clothing retailer. Experienced platform team. Mature Terraform usage. Years of GitHub CI/CD in production. On paper, they were further along than most. When we got into the details, the story got more complicated. Four different branching conventions had developed across teams over five years. SonarQube was configured, but enforcement was inconsistent depending on who had merged last. There was no documented recovery process if something went seriously wrong with the pipeline or the repository state. None of it was catastrophic in isolation, but none of it was actually under control either. Rather than handing them a list of things to fix, we ran a structured assessment. Direct repository and pipeline analysis. Stakeholder interviews. A look across version control hygiene, CI/CD design, security posture, testing strategy, GitOps alignment — the full system, not just the symptoms the team had already named. The output wasn't a slide deck. It was a prioritized roadmap with effort and impact scores - something the team could actually sequence and execute, not file away. That difference matters more than it sounds. Most pipeline advice ends up in a document somewhere. What teams actually need is someone telling them: this is what to fix first, this is what can wait, and here's why. It's why we changed how we structure this work. Short, focused engagements. Direct technical analysis, not just interviews. Something concrete at the end - not just a framework, not just a set of principles, but a sequenced implementation plan. If your pipelines have been running for a few years without that kind of outside look, there's a reasonable chance you're carrying more risk than the team realizes. That's not a knock on anyone, it's just how systems evolve when people are heads-down shipping. The question worth sitting with is whether you want to find out on your own terms, or wait until an audit, an incident, or a frustrated engineering leader forces the conversation. Get more information on our pipeline assessment and optimization. [table id=3 /] [post_title] => Why We Stopped Giving Pipeline Advice and Started Doing the Work [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => why-we-stopped-giving-pipeline-advice-and-started-doing-the-work [to_ping] => [pinged] => [post_modified] => 2026-05-12 19:00:44 [post_modified_gmt] => 2026-05-12 19:00:44 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5218 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [7] => WP_Post Object ( [ID] => 5209 [post_author] => 7 [post_date] => 2026-04-28 18:42:03 [post_date_gmt] => 2026-04-28 18:42:03 [post_content] => A few months ago, I was on a call with a mid‑sized financial services firm. They had a solid security team and capable engineers. Nothing about the organization suggested risk or immaturity. During the conversation, I asked a simple question: how many TLS certificates are you managing? The answer was roughly 180. Then I asked how renewals were tracked. The response: spreadsheets, a shared drive, and calendar reminders. It was concerning, but not surprising. Just six months earlier, I had the exact same conversation with a healthcare organization managing more than 300 certificates the same way. Despite the risk, this approach is far more common than most teams are comfortable admitting. What’s changing now is scale. The CA/Browser Forum has approved a progressive reduction in maximum TLS certificate lifetimes, culminating in a 47‑day limit by 2029, with significant reductions beginning as early as 2026. For teams that renew certificates annually today, this represents an eightfold increase in renewal activity per domain. For that financial services client, 180 certificates quickly translate into more than 1,400 renewal events per year. With their existing process, this was not an operational problem waiting to happen. It was a structural failure already underway. As we worked through the implications together, the initial instinct was predictable: add more process. Better spreadsheets. Tighter ownership. Escalation procedures. We challenged that assumption early. Process does not scale at this magnitude. No amount of procedural rigor can compensate for an eightfold increase in repetitive, time‑sensitive work. Automation is not an optimization here. It is the only viable answer. What we ultimately built, and have since deployed for several organizations facing the same challenge, is an Ansible‑based automation pipeline that manages the full certificate lifecycle end to end. Certificate signing request generation. Submission to the certificate authority. Deployment across a wide range of endpoints, including web servers, load balancers, and Kubernetes clusters. Post‑deployment validation to ensure certificates are live and correctly installed. Event‑Driven Ansible plays a critical role. Instead of relying on humans to track expiration dates, the system continuously monitors live endpoints, local certificate stores, and Kubernetes secrets. When a certificate approaches its renewal threshold, the pipeline is triggered automatically. No manual checks. No calendar reminders. No late‑night surprises. Equally important were the less visible pieces. Integration with secrets management so private keys never leave their source systems. A complete audit trail suitable for compliance and security reviews. And a local test harness that allowed engineers to run the full lifecycle safely in their own environment before anything touched production. That last element matters more than most teams realize. Trust in automation comes from watching it work, repeatedly, in a controlled setting. Three months after go‑live, something interesting happened. On‑call pages for expired certificates stopped entirely. The system did its job quietly in the background, which is exactly how critical infrastructure should behave. The security team gained auditable evidence they could provide to regulators without manual effort. The platform team reclaimed hours previously lost to renewal toil. And when we compared the avoided manual effort against the cost of implementation, the payback period was under eight months, even before factoring in the cost of downtime or customer impact from an outage. The broader takeaway is simple. Organizations should assess their certificate exposure now, before the 2026 reductions take effect. The solution itself is not complex, but implementing it properly takes time. Six to eight weeks is typical, and that timeline compresses dramatically once a mandate is already in force. Teams that act early will barely notice the transition. Teams that wait until 47 days becomes the standard will find themselves scrambling to automate eight renewals per year per domain while still delivering on every other commitment on their roadmap. The spreadsheet era of certificate management is ending. That outcome is already written into policy. The only remaining question is whether your organization gets ahead of it or reacts when the pressure arrives. Learn more about CertOps Automation. [table id=3 /] [post_title] => The 47 Day Certificate Problem No One Is Talking About (Yet) [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => the-47-day-certificate-problem-no-one-is-talking-about-yet [to_ping] => [pinged] => [post_modified] => 2026-05-15 18:52:02 [post_modified_gmt] => 2026-05-15 18:52:02 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5209 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) ) [post_count] => 8 [current_post] => -1 [before_loop] => 1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 5240 [post_author] => 7 [post_date] => 2026-05-26 12:53:43 [post_date_gmt] => 2026-05-26 12:53:43 [post_content] =>

[post_title] => Keyva Service Integration Hub for Red Hat Ansible Automation Platform Certified for Zurich Release [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => keyva-service-integration-hub-for-red-hat-ansible-automation-platform-certified-for-zurich-release [to_ping] => [pinged] => [post_modified] => 2026-05-26 12:53:43 [post_modified_gmt] => 2026-05-26 12:53:43 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5240 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [comment_count] => 0 [current_comment] => -1 [found_posts] => 153 [max_num_pages] => 20 [max_num_comment_pages] => 0 [is_single] => [is_preview] => [is_page] => [is_archive] => [is_date] => [is_year] => [is_month] => [is_day] => [is_time] => [is_author] => [is_category] => [is_tag] => [is_tax] => [is_search] => [is_feed] => [is_comment_feed] => [is_trackback] => [is_home] => 1 [is_privacy_policy] => [is_404] => [is_embed] => [is_paged] => [is_admin] => [is_attachment] => [is_singular] => [is_robots] => [is_favicon] => [is_posts_page] => [is_post_type_archive] => [query_vars_hash:WP_Query:private] => 95de42762d32886c3a67e68b6c7dee87 [query_vars_changed:WP_Query:private] => [thumbnails_cached] => [allow_query_attachment_by_filename:protected] => [stopwords:WP_Query:private] => [compat_fields:WP_Query:private] => Array ( [0] => query_vars_hash [1] => query_vars_changed ) [compat_methods:WP_Query:private] => Array ( [0] => init_query_flags [1] => parse_tax_query ) [query_cache_key:WP_Query:private] => wp_query:6a971c9360222b08a49992f8d4c48b7c [tribe_is_event] => [tribe_is_multi_posttype] => [tribe_is_event_category] => [tribe_is_event_venue] => [tribe_is_event_organizer] => [tribe_is_event_query] => [tribe_is_past] => )