Bob Glithero contributed to this blog post.
This post is the first in a series and will dive into service-gateway on VMware Tanzu RabbitMQ for VMs. In future posts, we will cover service-gateway access for VMware Tanzu GemFire and VMware Tanzu SQL (MySQL).
A key part of the Tanzu Application Service (TAS) value proposition is the self-service provisioning, scaling, and automation of data and other services commonly used in cloud native settings with a few simple commands. These properties of TAS promote release velocity, which means that many of our customers are able to deploy code many times a day, to fleets of tens of thousands of virtual machines. Data services available for TAS include a relational database (MySQL for VMware Tanzu), a cache (VMware Tanzu GemFire), and a messaging queue (Tanzu RabbitMQ).
All these services work well within a single foundation—a logical construct that houses individual instances of control components, such as the Ops Manager and the BOSH director. But what do you do when you need to work with applications or databases running in other TAS foundations to enable uses like high availability or disaster recovery?
In those cases, you’d like to be able to connect to those external data stores or applications in a way that’s secure and performant. You’d also like to insulate developers from the lower-level implementation details as much as possible, so that they can get on with building and shipping great software. That’s why we created multi-foundation connectivity in TAS via service-gateway access, which allows you to search, view, and manage orgs, spaces, apps, and service instances across multiple foundations from a single interface. Let’s take a closer look at how this works.
Implementing multi-foundation connectivity
Until now, customers have implemented multi-foundation connectivity in a couple of ways:
-
Creating manual networking configurations and opening up firewall ports: The idea here is that services from two different foundations can reach out to each other. Several approaches can work, including DNS resolution or IP address resolution, and most of them involve changing networking rules to allow specific traffic to and from specific IPs within a network. For example, in case of IP address resolution, you may create a link (route) between two networks or deploy two foundations in the same network (see documentation to illustrate this idea).
-
Using BOSH virtual IPs (VIP): This involves opening up externally-accessible IPs; a list of reserved IP addresses is called out in BOSH's cloud config. While this approach does allow for IPs to be visible outside of a foundation, it does not work for ports, mainly due to firewall policies. Since the method requires reserving a block of IP addresses, it is not ideal for on-demand data services, where users can require service instances to be spun up or down as a function of demand.
These solutions work for specific customers in very specific contexts. But while they do meet the goal of providing multi-foundation visibility, they are hard to scale. For example, custom network rules that provide off-platform visibility must be rewritten every time a node on the network is reconfigured. When key people who understand these changes eventually move on, training new people to maintain custom configuration can be challenging. Then there are concerns with traceability and the audit trail of actions.
Service-gateway access simplifies multi-foundation connectivity
To solve multi-foundation service visibility in a manner that worked for enterprises, we came up with service-gateway access. For Tanzu RabbitMQ, this feature leverages TCP routing and enables on-demand service instances to connect to external components that are not on the same foundation as the service instance. These components could live on another TAS foundation, or they could be hosted outside of the foundation entirely.
Service-gateway offers a number of benefits for both application developers and platform operators.
Off-platform visibility
-
Better apps: Customers have been able to create visibility and access to off-platform apps. As an example, developers can use Tanzu RabbitMQ on TAS, and let off-platform systems (such as mainframes—connected to the Gateway via ESBs, or IoT systems) talk to Tanzu RabbitMQ instances, enabling them to write apps that offer broader functionality.
-
Developer productivity: Developers connect to service instances from their local workstations, which are often on a completely different network than the service instances. Service Gateway allows them to connect easily and securely from outside the TAS network.
Off-platform visibility in practice: A banking customer uses Tanzu RabbitMQ with service-gateway access to enable applications running on TAS to consume events produced by external clients. They use Tanzu RabbitMQ’s flexible routing capabilities to deliver events to consuming applications, scaling out apps as necessary, and seamlessly dealing with any downtime and changes—all without any modifications on the producer side. The producer has no knowledge of the consumer, so each can operate independently of the other, leading to more resilient, secure architectures.
Multi-foundation connectivity
-
Application instances that reside in two different TAS foundations (separated for logical or geographical reasons) can be connected to the same data service instance residing on one of those foundations.
-
Simpler configuration: Developers can provide their applications a single DNS endpoint to talk to, instead of a list of all the nodes in case of Tanzu RabbitMQ.
-
Streamlined ops: Platform operators only have to configure the service-gateway for their developers to start reaping benefits, instead of manual workarounds with their networks.
Multi-foundation connectivity in practice: An insurance customer runs two data centers for resiliency and business continuity in an active/passive model. In the event of a failure at the primary data center, the apps in the secondary site start up. In the primary site, they utilize an on-demand Tanzu RabbitMQ with service-gateway to federate messages over to the secondary site. When the secondary site starts, the messages the apps require are waiting in Tanzu RabbitMQ.
A TAS foundation with a service-gateway that connects on-platform service instances with off-platform apps and data
How can you use service-gateway access for Tanzu RabbitMQ?
-
To access Tanzu RabbitMQ from apps deployed to VMware Tanzu Application Service for VMs (TAS for VMs) on a separate foundation
-
Replicating messages between Tanzu RabbitMQ clusters in different foundations, for example, to set up federation for disaster recovery
-
Enabling apps running outside the foundation to communicate, through Tanzu RabbitMQ, with apps deployed via TAS for VMs
-
Make Tanzu RabbitMQ for VMs available to apps that are deployed off the Tanzu platform, e.g., on-premises or in public clouds
How does an operator enable service-gateway access?
Enabling service-gateway access is designed to be as simple as possible for operators and developers alike (see the documentation). These are the steps for operators:
-
Enable TCP routing using the TAS for VMs tile
-
Configure the firewall to allow incoming traffic to the TCP router
-
Configure the load balancer in the IaaS to redirect traffic to the TCP router
-
Create a DNS record that maps to the load balancer
-
Configure a service-gateway enabled plan
For developers, the steps are even simpler:
-
Create a service instance with the service-gateway plan by running:
|
|
-
Obtain credentials by creating a service key:
|
|
Reference architecture illustrating how components such as service-gateway, TCP router, TAS, load balancers, and the application connect together
Creating specialist foundations using service-gateway access
One of the implications of a service-gateway connecting foundations is the notion that developers can create purpose-specific specialist foundations, such as a data services-only foundation. As the name suggests, this is a TAS foundation that hosts only data service instances and does not house any applications. In a traditional TAS implementation—where apps and data both live—we recognize that administrators worry about both platform and service administration. These tasks have a large knowledge surface area, as admins must build up expertise on platform and service concerns. By segregating services on a single foundation, we enable specialist service administration teams to manage those foundations. This allows operators at the platform and service level to focus on their areas of expertise.
Here’s what the implementation would look like:
Two TAS foundations, one containing only services and the other with apps and services. Service-gateway access enables app/data visibility across foundations. The services-only foundation is managed by service operators.
Although service-gateway access is necessary for this implementation, it’s not sufficient on its own to execute a data services-only foundation. For example, we would need credentials management between foundations (so credentials are not shared) and a services control plane that deals with the details of creating and binding services across foundations. We would also need a robust authentication and authorization framework (for example OAuth implementation across the foundations).
Teams that want to implement a services-only foundation may look at the user-provided services route to simplify credential sharing between foundations. At the moment, there is no automated method to get credentials from the services foundation into the app foundation. In order to bind to a service in the services foundation, app developers will need to create a service key on the services foundation, and put credentials from the service key into an instance of the user-provided service running on the app foundation. The last step will be to bind the user-provided service instance to the app. (This process could be automated to reduce operational pain, since it would need a lot of effort to scale.)
Alternatively, a future version of Tanzu RabbitMQ for VMs can support OAuth for authentication. Once configured, credentials can be stored securely in your federated identity and access management system (i.e. UAA, Active Directory, LDAP), and apps can use these credentials to connect to Tanzu RabbitMQ.
Service-gateway access for flexibility in your platform experience
We’re very excited about service-gateway access for Tanzu RabbitMQ. This feature enhances the platform operator experience by enabling teams to pave the way for foundations that host only specialist services. It enhances the application developer experience by broadening the boundary of developer access to apps and data.
If you’re ready to take the next step, consult our product documentation, or contact us to discuss your specific use cases today!
