Cloud Foundry deployed applications can easily connect to Cloud Foundry services like HANA or PostgreSQL or Redis but what about other currently non supported situations?
What if we needed to have our application access a MySQL server which runs on TCP port 3306?
It turns out that outbound TCP connections are allowed from CF applications but this may not always be possible or desirable.
If the firewall protecting the server blocks port 3306 but allows other well known ports then a TCP over HTTP tunnel can be used to reroute connections to the server.
This solution is illustrated with an example MTA project found here along with linked docker projects and AWS example image.
mta_docker_nodejs
If the server is on an internal NAT protected sub-network then the CF app can act as the tunnel server and create a connection with an outbound HTTP request. Here we are effectively swapping the role of the tunnel client and tunnel server. Once this pathway is open, then requests from the Node client on port 3306 are passed through as though the MySQL server were local.
All of the components can be hosted within SAP Cloud Platform, Cloud Foundry (yellow dashed box) but the connectivity is still required to pass through the primary platform HTTP router since deployed containers don't have TCP visibility between each other even when deployed into the same space. So from an architecture point of view this is similar to the second case illustrated above.
Keep in mind that in all the prior cases, I assumed the MySQL server would be deployed in an AWS EC2 instance that would have it's lifespan managed by dev-ops and would be run in an environment where a block-store device (the file system) would be suitable for such a server.
The next configuration while attractive from an "all in SAP CPCF" point of view suffers from an inherent down-side that if the container for some reason gets restaged or restarted, that the container filesystem will be reloaded from the blob-store and thus be reset to it's state when initially deployed. This is the inherent behavior of a micro-service execution environment and may be suitable when the server service is more ephemeral in nature (maybe a custom message broker). But will likely be untenable for a server with large data storage requirements. Such a setup would likely need to persist it's state to an object store service and reload it's state as well should restaging occur.
When you use SAP provided DB services like HANA or PostgreSQL or Redis, the environment in which the core service runs is tuned to the needs of that service by SAP dev-ops and the service level agreement includes things like backup/restore as well. You don't need to worry about these operational concerns.
Cloud Foundry as defined by the Cloud Foundry Foundation, does support TCP routing which would make all of this discussion mute, but SAP has not currently implemented it as of the date of this post.
More details on this feature can be found here.
https://www.cloudfoundry.org/blog/tcp-routing-comes-to-cloud-foundry/
This may at some future time be implemented in SAP's Cloud Platform and I encourage those interested in such functionality to keep an eye on the official roadmap documents.
There is one notable exception and that is of HANA As A Service(HaaS) instances running on Cloud Foundry. In the case of these instances but not of earlier provisioned HANA instances, A unique hostname/port is generated and made available such that direct TCP connectivity for JDBC connections is allowed. Also the needed TCP routing for this situation is established such that external client applications can make direct JDBC connections. This alone is a great reason for considering HANA in your micro-services architecture.
The goal of this post is illustrate possible scenarios that get around some of the perceived limitations when considering SAP Cloud Platform Cloud Foundry. Everything described here is possible because HTTP websocket style connections are an inherently supported feature of Cloud Platform and can be leveraged in innovative ways. The chisel tunnel software used in this illustration is written in the GO programming language, is open source and should be treated as inherently insecure until you prove to yourself that it meets your needs. I make no warranty that anything discussed in this post will work, work correctly, work securely, or in a performant way for your situation. It is up to you the system architect to prove this for yourself in your situation.
What if we needed to have our application access a MySQL server which runs on TCP port 3306?
It turns out that outbound TCP connections are allowed from CF applications but this may not always be possible or desirable.
- Server has a public name/ip
- Firewall allows inbound connections from CF app on 3306
If the firewall protecting the server blocks port 3306 but allows other well known ports then a TCP over HTTP tunnel can be used to reroute connections to the server.
- Server has a public name/ip
- Firewall allows inbound connections from CF app on 8080(or 80 or 443) but not 3306
This solution is illustrated with an example MTA project found here along with linked docker projects and AWS example image.
mta_docker_nodejs
If the server is on an internal NAT protected sub-network then the CF app can act as the tunnel server and create a connection with an outbound HTTP request. Here we are effectively swapping the role of the tunnel client and tunnel server. Once this pathway is open, then requests from the Node client on port 3306 are passed through as though the MySQL server were local.
- Server does not have a public name/ip (behind a firewall?)
- Docker provided container in CF has a public route for HTTPS(WebSocket)
All of the components can be hosted within SAP Cloud Platform, Cloud Foundry (yellow dashed box) but the connectivity is still required to pass through the primary platform HTTP router since deployed containers don't have TCP visibility between each other even when deployed into the same space. So from an architecture point of view this is similar to the second case illustrated above.
Keep in mind that in all the prior cases, I assumed the MySQL server would be deployed in an AWS EC2 instance that would have it's lifespan managed by dev-ops and would be run in an environment where a block-store device (the file system) would be suitable for such a server.
The next configuration while attractive from an "all in SAP CPCF" point of view suffers from an inherent down-side that if the container for some reason gets restaged or restarted, that the container filesystem will be reloaded from the blob-store and thus be reset to it's state when initially deployed. This is the inherent behavior of a micro-service execution environment and may be suitable when the server service is more ephemeral in nature (maybe a custom message broker). But will likely be untenable for a server with large data storage requirements. Such a setup would likely need to persist it's state to an object store service and reload it's state as well should restaging occur.
When you use SAP provided DB services like HANA or PostgreSQL or Redis, the environment in which the core service runs is tuned to the needs of that service by SAP dev-ops and the service level agreement includes things like backup/restore as well. You don't need to worry about these operational concerns.
- Docker provided server container in CF has a public route
- Client app assumes localhost:3306 is a local server
- Danger in that if MySQL container gets restaged, all DB changes are lost
Cloud Foundry as defined by the Cloud Foundry Foundation, does support TCP routing which would make all of this discussion mute, but SAP has not currently implemented it as of the date of this post.
More details on this feature can be found here.
https://www.cloudfoundry.org/blog/tcp-routing-comes-to-cloud-foundry/
This may at some future time be implemented in SAP's Cloud Platform and I encourage those interested in such functionality to keep an eye on the official roadmap documents.
There is one notable exception and that is of HANA As A Service(HaaS) instances running on Cloud Foundry. In the case of these instances but not of earlier provisioned HANA instances, A unique hostname/port is generated and made available such that direct TCP connectivity for JDBC connections is allowed. Also the needed TCP routing for this situation is established such that external client applications can make direct JDBC connections. This alone is a great reason for considering HANA in your micro-services architecture.
The goal of this post is illustrate possible scenarios that get around some of the perceived limitations when considering SAP Cloud Platform Cloud Foundry. Everything described here is possible because HTTP websocket style connections are an inherently supported feature of Cloud Platform and can be leveraged in innovative ways. The chisel tunnel software used in this illustration is written in the GO programming language, is open source and should be treated as inherently insecure until you prove to yourself that it meets your needs. I make no warranty that anything discussed in this post will work, work correctly, work securely, or in a performant way for your situation. It is up to you the system architect to prove this for yourself in your situation.
- SAP Managed Tags:
