Multicloud Communication for Kubernetes – But with Applications in Charge

We almost reached the end of another calendar year and the wonderful tradition of the Java Advent Calendar continues into another year. I’ve had the pleasure of either opening or at least contributing to the 24 yearly surprise articles for a few years now and it always lets me be thankful again to celebrate the creativity, knowledge, and the power to share of the amazing Java community. With that in mind, I wish you and your loved ones an amazing time running up to the end of year and hope you get to recharge your batteries and enjoy a daily learning experience with the amazing authors presenting a new topic for the coming 23 days.

Java for sure isn’t an afterthought. Won’t be for a while longer and has shown to adopt seamlessly even to ever changing, modern, cloud-native architectures and requirements. One reason for this for sure is the endless innovation being driven by the language and the platforms but also more and more projects continue to push the boundaries of what’s possible by creating better open source frameworks to solve challenges. One of those challenges is connecting applications. And I am deliberately not talking about services here but I am also not excluding them. With more organizations paying close attention to what workloads are running on which infrastructure the true multi cloud landscapes silently became a reality. And the reasons for this are plenty. Governance, (data-)sovereignty, cost management, privacy and others. And applications need to make sure to either wait for infrastructure to provide the necessary integrations or implement them themselves. The last point is particularly challenging when applications need to cross network boundaries or various cloud implementations. A brilliant way to address this presents Skupper: A powerful open-source project that emerged as a solution to streamline multi cloud communication for developers.

What is Skupper and why should developers consider using it!

Skupper is a cloud-native communication platform designed to facilitate secure and seamless communication across multiple Kubernetes clusters, Virtual Machines or Bare-Metal Servers or a combination of all of these – regardless of whether they are on-premises, in the cloud, or spanning various cloud providers.

It delivers a layer 7 service connection with no need for VPNs or special firewall rules. Using a simple command line interface, interconnections are created in a matter of minutes, avoiding extensive networking planning, and overhead. All interconnections between environments use mutual TLS(mTLS).
This approach puts applications in charge of the connections between services, abstracting away the intricacies of dealing with different networking configurations across clusters. It also provides service discovery features that make it easy for applications to find and communicate with services in other clusters.

If your application is truly distributed, it shouldn’t be limited by network topology. On the other hand, we are talking about a specific application, with specific communication requirements – so we don’t want to punch a gaping hole into firewalls, allowing all applications on a cluster (or even network segment) to freely communicate with all others. This is an application-scoped, secure VAN (Virtual Application Network).
Read: “With Skupper, your application can span multiple cloud providers, data centers, and regions.” (Source: https://skupper.io/ )

What sounds complicated is in fact comparably easy. You don’t even need to change your existing application or have any administrator privileges. The communication transparently covers HTTP/1.1, HTTP/2, gRPC, and TCP.

What’s in it for a Java guy?

Think modernization. Many legacy infrastructures tend to have central components that you may even need to connect to via EJBs or other legacy connections. This could be workflow instances or specific messaging infrastructures. If you configure your remote EJB endpoints to point to a skupper router (or use the gateway paradigm from above) then you could move your application to the cloud (as a VM or deployment to Kubernetes) without being tied down by the central infrastructure that most likely cannot be moved. Using this approach you gain a lot more flexibility during your modernization initiatives because you can start working across physical boundaries without significant network security hurdles.

Steps to get Skupper up and running!

Skupper needs to be installed on the Kubernetes clusters or machines that host applications or services that need to be connected. After installation it needs a brief configuration with trusted connections followed by the allowed service communications.

Try it out yourself!

Well, if it sounds super straightforward and easy it should be a breeze to test out directly. And you can: There is a full guide with a portal web application deployed to the free OpenShift Sandbox that securely connects and accesses a PostgreSQL database on your local laptop without exposing any ports of your local database publicly.