cloud native news pivotal products spring cloud

Spring Cloud Gateway for VMware Tanzu, the cloud-native API gateway developers love, is now GA

Pivotal Spring Cloud Gateway is a developer-friendly way to route API requests (internal or external) to your services. This commercially supported product, based on the open-source Spring Cloud Gateway project, provides a simple, yet effective way to route API traffic.  Pivotal Spring Cloud Gateway makes life simpler for API consumers and producers while delivering centralized enterprise control, security and resilience.

Pivotal Spring Cloud Gateway is now GA and is available for download.

Instantly change API routing rules with code (and say goodbye to ticket-based change requests)

Through our Beta program, we’re already seeing how Pivotal Spring Cloud Gateway customers are solving some big problems:

Simplify the API provider experience

Services are only accessible via the gateway and so can evolve their deployment topology over time to meet the needs of their consumers, without requiring changes to the consumer. This decoupling also means that cross-cutting concerns, such as Single Sign-On (SSO),  can be off-loaded onto the gateway, simplifying the developer experience and ensuring a common, compliant, centrally managed approach to areas such security. The gateway also hides implementation details such as language, enabling developers to use the most appropriate programming language and frameworks to deliver the service, without concern for the consumer’s technology signature. 

Improve the API consumer experience

Pivotal Spring Cloud Gateway provides a single, abstracted consumer entry point to access every API-fronted application service. This decouples consumers from the specifics of differing service implementations creating a consistent experience across APIs.

Intra-organization API access

Many organizations have multiple teams or business units that provide their own APIs for consumption by other teams and business units. This can result in large-scale service discovery and custom enterprise client library curation approaches with high maintenance overheads. Enter the Pivotal Spring Cloud Gateway, which provides a strong Bounded Context within organizations, using Pivotal Platform. Now, each team or business unit can deploy its own gateway service, including SSO and route configurations, and then offer services to other teams in their organization. This approach mitigates the centralization effect, offering a more consistent API consumption approach across the organization.

Monolith “strangling”

Breaking down a monolithic application into microservices can derive more business value by attracting more consumers to the newly isolated services, increase velocity of feature delivery and reduce the cost of maintenance. Using the “Strangler Pattern”, Pivotal Spring Cloud Gateway can break down monolithic applications, piecemeal. First, a gateway is configured with the existing routes, in front of the monolith application and all traffic is routed through the gateway. Refactoring and redesign of the application breaks out smaller services that then have new routes added to the gateway to keep the application running. Over time, more and more application services are separated out of the monolithic application, freeing these services to be leveraged in new ways, in their own independent life cycle.

Any service, any language, anywhere

Pivotal Spring Cloud Gateway can route API requests to any HTTP-enabled service, regardless of language or infrastructure. API services made available through the gateway can be running on the Pivotal Platform, Kubernetes or any other platform.

Not your average API gateway

The API gateway has become a common pattern in many organizations, and many have already bought or built the capability. So what’s so special about Pivotal Spring Cloud Gateway?

Pivotal Spring Cloud Gateway on Pivotal Platform utilizing additional Spring Cloud services

We’ve spent years helping organizations and developers adopt cloud-native patterns and learned a lot about the developer experience along the way. We channeled these insights into Pivotal Spring Cloud Gateway to deliver these exclusive features:

Low-friction API publishing

Developer self-service is a key cloud-native capability, so why is ticket-based, centralized API configuration management still a thing? In many organizations, there is a need to create a ticket to update the centrally managed API gateway configuration, causing a delay in the delivery of new API updates. Services in the Pivotal Spring Cloud Gateway provide their route configuration to the gateway using Pivotal Platform’s bind configuration capability. This means that developers and continuous delivery pipelines can deploy new API routes automatically, without delay caused by manual configuration.

Simplified Single Sign-On integration

Most organizations already have an enterprise-wide Single-Sign-On (SSO) solution implemented. Configuring SSO to work with an API gateway is really hard, so why doesn’t it work out of the box? We don’t know either, so we built it directly into our gateway. 

Dynamic route control

In Pivotal Spring Cloud Gateway, route configurations for an application service can be provided dynamically via a bind request with a JSON configuration file. 

The following example bind request will create a new set of routes that the Pivotal Spring Cloud Gateway service will handle:

$ cf bind-service myserviceapp mygateway -c myroutes.json

And the contents of myroutes.json:

{"routes": [
    {
      "method": "GET",
      "path": "/myapp/**"
    },
    {
      "method": "POST",
      "path": "/myapp/**",
      "sso-enabled": true,
      "roles": [
        "app.admin"
      ]}]}

With this simple configuration file, we can tell the `mygateway` service instance to route HTTP GET requests to `/myapp/**` to `myserviceapp`. In addition, if a HTTP POST request is made to `/myapp/**` then ensure that the requestor has authenticated successfully via SSO and has the authorized role of `app.write` before allowing the request to be routed to `myserviceapp`. We are able to do this by integrating with Pivotal Single Sign-On.

Because Pivotal Spring Cloud Gateway leverages Pivotal Platform capabilities, such as internally mapped routes, container networking and service discovery, we are able to route appropriate requests to `myserviceapp` without providing URL or other network configuration information.

And the best part about being able to provide a JSON file for dynamic route configuration on a Pivotal Spring Cloud Gateway service instance is that the JSON file can be source controlled with the application service’s code. No need to keep centralized configuration files that can become out of alignment or difficult to update as the application service evolves.

Where to find out more

Related Articles