Lessons from a multi-year transformation across governance, networking, developer experience, and platform operations
In 2023, I began helping a large regulated utility in the United States move from a legacy API gateway toward an enterprise API management platform. The technical direction was important, but the harder part was driving change across security, infrastructure, architecture, application teams, and governance bodies.
Publication note: The client name, region identifiers, internal system names, and selected implementation details are intentionally generalized. Platform metrics are rounded and reflect my implementation experience
The context: APIs behind a mission-critical utility
A utility does much more than transmit and distribute energy. Its software landscape supports customer billing and service, outage management, field operations, wildfire-mitigation programs, clean-energy initiatives, regulatory reporting, and communication with external partners. Many of these capabilities depend on APIs, even when the end user never sees them.
In our environment, more than 4,000 interfaces connected custom applications, SaaS platforms, operational systems, and vendor solutions. Many were mission-critical. The existing on-premises gateway had served the organization for years, but it required significant infrastructure support and did not provide the scalability, developer experience, or automation we wanted for the next phase of growth.
The goal was not simply to replace one gateway with another. The goal was to establish Google Apigee as an enterprise API platform: a common control point for security, traffic management, analytics, product governance, and developer onboarding.
The architecture was not the longest part of the journey. Reaching agreement on ownership, network boundaries, risk controls, funding, and the operating model took more time than building the first API proxy.
Start small and make the value visible
We began with a focused proof of concept on Apigee Edge. The POC connected a cloud-hosted API and an SAP OData service. We applied OAuth 2.0 and mutual TLS, published the API through the developer portal, and demonstrated analytics and trace capabilities for troubleshooting.
This small scope was deliberate. An enterprise review board does not need a hundred-slide vision before it can assess a platform. It needs evidence that the platform can secure a real service, expose it through a governed interface, provide operational visibility, and fit within enterprise standards.
The POC gave the review board something tangible to evaluate. After approval, we started onboarding cloud APIs to Apigee Edge. Over the following two years, the production footprint grew from zero to more than 300 API proxies and handled millions of successful calls.
Those numbers mattered, but the more important outcome was organizational confidence. Application teams could see a repeatable path to publish an API, security teams could see consistent policy enforcement, and support teams could use analytics and tracing instead of relying only on backend logs.
Treat each API proxy as a software product
As adoption increased, manual deployment was no longer sustainable. We created a CI/CD model in which each API proxy was maintained as its own source-controlled project. This made ownership, version history, rollback, and release auditing much clearer.
The pipeline supported two build paths. Existing Maven-based proxy projects were validated and packaged directly. For specification-first APIs, a custom generator used the OpenAPI definition to create a standard proxy structure with shared logging and policy components. Environment-specific values were injected during the build rather than hard-coded in the proxy bundle.
Figure 1. The proxy pipeline supports source validation, Maven- or OpenAPI-based builds, controlled promotion across environments, and a gated production release.
The design principles behind the pipeline were straightforward:
- Keep proxy source, tests, and deployment configuration in version control.
- Use templates and shared flows for common security, logging, error handling, and correlation patterns.
- Separate environment configuration from deployable proxy logic.
- Promote the same build artifact across environments whenever possible.
- Require an explicit approval gate for production.
- Capture the proxy revision, commit, approver, and deployment result for auditability.
A representative security policy
A reusable control attached early in the request flow. The exact policy and identity-provider model varied by API, but token verification always happened before business processing:
<OAuthV2 name="OAuthV2-Verify-Access-Token">
<Operation>VerifyAccessToken</Operation>
</OAuthV2>
For backend services that required mutual TLS, the target connection referenced managed keystores and truststores rather than embedding certificate details in proxy code:
<HTTPTargetConnection>
<URL>https://internal-api.example.com</URL>
<SSLInfo>
<Enabled>true</Enabled>
<Enforce>true</Enforce>
<ClientAuthEnabled>true</ClientAuthEnabled>
<KeyStore>ref://target-keystore-ref</KeyStore>
<KeyAlias>target-client-key</KeyAlias>
<TrustStore>ref://target-truststore-ref</TrustStore>
<IgnoreValidationErrors>false</IgnoreValidationErrors>
</SSLInfo>
</HTTPTargetConnection>
These examples are intentionally minimal. In the actual platform, authentication, traffic protection, message validation, logging, and fault handling were assembled through shared standards so that every application team did not have to solve the same problem independently.
Self-service does not mean uncontrolled access
Our developer-experience requirement created an interesting governance challenge. We wanted API products to remain discoverable across the enterprise, but discovery should not automatically grant permission to invoke them.
Apigee supports manual approval for API-product credentials. However, our enterprise process required more than a pending status. We needed product-owner routing, scheduled detection of requests, notifications containing application and requester details, an auditable approval interface, and the ability to revoke access through the same governed path.
We therefore extended the standard portal flow with a custom approval service. A scheduled job checked for pending requests through Apigee management APIs, identified the responsible product owner, and sent a notification. Authorized approvers could approve or revoke the product assignment through a controlled portal.
Figure 2. API products remain discoverable while access is controlled through a product-owner approval workflow.
We also introduced a ServiceNow-based onboarding request. Application teams used the form to request a repository and provide their OpenAPI specification. Automation bootstrapped the repository with the expected directory structure, policy templates, pipeline configuration, and documentation placeholders. Teams still owned their APIs, but they started from a compliant baseline instead of an empty repository.
A useful self-service platform removes repetitive work. It should not remove accountability. Product ownership, consumer identity, approval history, and revocation must remain visible.
The network boundary became the turning point
The initial Edge implementation worked well for cloud-reachable backends. As adoption expanded, a larger question emerged: how would the platform reach private services that were accessible only inside the enterprise network?
This was not simply a proxy configuration issue. A cloud API gateway cannot reach a private target unless the enterprise provides an approved network path, routing model, DNS resolution, firewall rules, and certificate trust. The target location like on-premises, Google Cloud, AWS, Azure, or a SaaS provider changes the connectivity pattern.
At that stage, the network architecture became as important as the API policies. We needed to decide where the runtime should operate, who would own it, and how internal and external traffic would remain isolated.
What we learned from the Apigee Hybrid evaluation
We evaluated Apigee Hybrid and deployed a runtime plane on an enterprise-managed Kubernetes environment in AWS. The POC proved that APIs running in the hybrid runtime could connect to internal target endpoints through the organization’s established network.
Technically, the model worked. It also made the operational responsibilities clear. With Apigee Hybrid, Google hosts the management plane, while the organization installs and operates the runtime plane on a supported Kubernetes platform. That means the enterprise remains responsible for cluster lifecycle, capacity planning, platform upgrades, observability, backup and recovery procedures, and coordination across the Kubernetes and Apigee support boundaries.
For organizations that require API runtime traffic and data to remain within infrastructure they directly control, that trade-off can be appropriate. For our operating model, however, the additional infrastructure and operations burden was difficult to justify.
The Hybrid POC was not a failed direction. It gave us the evidence needed to compare two valid operating models: customer-managed runtime control versus a Google-managed Apigee runtime.
Why we selected Apigee X
The organization ultimately selected Apigee X. The primary reasons were operational simplicity, network architecture, and the ability to create a scalable regional design without operating the underlying runtime platform ourselves.
- Google manages the Apigee runtime infrastructure, platform maintenance, and core service lifecycle.
- Our platform team can focus on API design, governance, security policies, onboarding, and reliability rather than Kubernetes operations.
- The architecture supports distinct ingress patterns for internal and external consumers.
- Separate non-production and production landing zones can provide stronger isolation of runtime, traffic, administrative access, and change control.
- Multiple regions can serve the same environment to improve availability, capacity, and latency.
- Private Service Connect and enterprise network connectivity can provide controlled paths to private targets.
AI readiness was another strategic benefit, but it was not the original reason to modernize the gateway. Apigee has since added AI-gateway capabilities such as LLM token policies, semantic caching, Model Armor integration, and support for governing APIs and tools used by agentic applications. These features strengthened the long-term platform fit because the same governance layer can be applied to traditional APIs and AI traffic.
That distinction is important. A platform should not be selected only because an AI feature is new. It should be selected because its operating model, security model, and network design fit the enterprise. AI capabilities then become an extension of a sound platform decision.
The Apigee X target architecture
The current design uses Apigee instances in two U.S. regions in an active-active pattern. Both regions can serve the same API environment, while load-balancing and health checks route traffic to healthy regional capacity. Non-production and production use separate infrastructure boundaries to reduce blast radius and support independent change control.
The connectivity model separates traffic by direction and destination:
| Traffic path | Primary pattern | Purpose |
|---|---|---|
| External consumers to Apigee | External load balancing and controlled public ingress | Expose approved APIs while applying enterprise edge and API security controls. |
| Internal consumers to Apigee | Private DNS and private northbound connectivity, including PSC where selected | Keep internal API traffic on approved private paths and isolate it from public ingress. |
| Apigee to services in other VPCs | Southbound PSC endpoint attachments to producer service attachments | Reach privately published services across project or VPC boundaries. |
| Apigee to on-premises services | Enterprise VPC routing through Dedicated or Partner Cloud Interconnect | Extend private reachability to internal data-center workloads. |
| Apigee to AWS or Azure services | Cross-Cloud Interconnect or another approved private transit pattern | Provide private, governed multicloud connectivity without treating the public internet as the default route. |
Private Service Connect is useful, but it is not a universal replacement for routing. It connects Apigee to services that are deliberately exposed through supported service attachments. On-premises connectivity still depends on the enterprise network, Cloud Router/BGP design, DNS, firewall policy, and the route path established through Cloud Interconnect or an equivalent private connection.
The same discipline applies northbound. Internal and external consumers may use different hostnames, load balancers, certificates, and security controls even when they eventually reach the same API proxy. Designing those paths early prevents a late-stage debate about whether an API is “internal” simply because its backend is internal.
Migration is a factory, not a single release
We are now in the middle of migrating legacy and Edge-hosted APIs to Apigee X. A large estate cannot move through one cutover window. The practical approach is to build a migration factory with repeatable assessment, remediation, testing, deployment, and operational handoff steps.
For each API, we examine more than the proxy code:
- Consumer applications, authentication method, credentials, certificates, quotas, and traffic profile.
- Backend location, private connectivity, DNS dependencies, timeout behavior, and firewall requirements.
- Shared-flow dependencies, key-value maps, target servers, environment variables, and custom policies.
- Logging, analytics, correlation IDs, alerting thresholds, and support ownership.
- Cutover strategy, rollback path, credential transition, and the period of coexistence with the legacy gateway.
The objective is platform consolidation, but consolidation should not be interpreted as an immediate shutdown of every legacy path. During migration, coexistence is expected. The legacy gateway is retired only after consumers move, traffic is stable, operational support is ready, and rollback risk is acceptable.
Lessons learned
1. Prove the operating model, not just the API proxy.
A successful POC should demonstrate security, deployment, monitoring, troubleshooting, ownership, and support. A working endpoint is important, but it does not prove that the platform is ready for enterprise adoption.
2. Start the network design early.
Private connectivity, DNS, ingress, egress, routing, and firewall ownership can influence the platform decision more than the API design itself. These discussions should begin before application teams start building proxies.
3. Use the migration as an opportunity to improve the APIs.
Moving an existing interface to a new gateway does not automatically modernize it. Where practical, the migration should also improve API contracts, security policies, observability, documentation, and ownership.
4. Make governance easy to follow.
Every API product needs a clear owner, access policy, support group, and lifecycle plan. Repository templates, reusable policies, automated checks, and approval workflows help teams move faster without bypassing governance.
5. Choose the platform based on the operating model and plan for a gradual transition.
Apigee Hybrid provides more control over the runtime, while Apigee X reduces the infrastructure and operational burden. The right choice depends on regulatory requirements, skills, cost, and accountability. In either case, a multi-year migration needs a clear coexistence strategy, meaningful success measures, and a strong governance foundation before newer capabilities such as AI gateways can deliver real value.
Conclusion
This transformation is still in progress. That is part of the story. In a regulated utility, enterprise modernization rarely moves in a straight line. The platform must satisfy technical requirements, but it must also earn the confidence of security, infrastructure, operations, architecture, application owners, and leadership.
The most important lesson from this journey is that API management is not only a gateway implementation. It is an organizational capability. The gateway provides enforcement and visibility, but the transformation succeeds only when teams agree on ownership, standards, automation, network boundaries, and the day-to-day operating model.
Starting with Apigee Edge allowed us to prove the value quickly and build adoption. Evaluating Apigee Hybrid clarified the operational trade-offs. Moving to Apigee X gave us a managed, multi-region foundation for the next phase. The journey has been long, but it has also created a more consistent and governable path for how APIs are designed, published, secured, and operated across the enterprise.
Technical references
The product statements in this draft were validated against Google Cloud documentation available in August 2026.
· What is Apigee?
· What is Apigee Hybrid?
Note:I documented all the technical reference links, but since the tool only supports two links per post, I had to remove them.