Hybrid Cloud Connectivity Deep Dive
Key Points
- Savannah, an IBM developer advocate, opens the hybrid‑cloud architecture series by emphasizing that establishing solid connectivity between private and public clouds is the foundational step for any hybrid‑cloud strategy.
- The video outlines three key connectivity topics: (1) basic methods for linking private and public cloud environments, (2) using a service mesh to unify communication among microservices, and (3) leveraging integration tools to simplify connections to internal and third‑party services.
- A “stock trader” sample app is used to illustrate the architecture: a consumer (mobile/web) contacts a private‑cloud endpoint, which routes traffic into a Kubernetes cluster hosting the Trader service that creates portfolios.
- The Portfolio service calls out to public‑cloud APIs (via a “get” service) to fetch real‑time stock prices and uses an egress setup for external API access, while an MQ service in the same cluster communicates with the public cloud to manage loyalty‑level data for users.
- By walking through this end‑to‑end flow, the presentation sets the stage for deeper discussions on service mesh capabilities and integration solutions in subsequent parts of the series.
Full Transcript
# Hybrid Cloud Connectivity Deep Dive **Source:** [https://www.youtube.com/watch?v=Fp2In_la9DE](https://www.youtube.com/watch?v=Fp2In_la9DE) **Duration:** 00:13:20 ## Summary - Savannah, an IBM developer advocate, opens the hybrid‑cloud architecture series by emphasizing that establishing solid connectivity between private and public clouds is the foundational step for any hybrid‑cloud strategy. - The video outlines three key connectivity topics: (1) basic methods for linking private and public cloud environments, (2) using a service mesh to unify communication among microservices, and (3) leveraging integration tools to simplify connections to internal and third‑party services. - A “stock trader” sample app is used to illustrate the architecture: a consumer (mobile/web) contacts a private‑cloud endpoint, which routes traffic into a Kubernetes cluster hosting the Trader service that creates portfolios. - The Portfolio service calls out to public‑cloud APIs (via a “get” service) to fetch real‑time stock prices and uses an egress setup for external API access, while an MQ service in the same cluster communicates with the public cloud to manage loyalty‑level data for users. - By walking through this end‑to‑end flow, the presentation sets the stage for deeper discussions on service mesh capabilities and integration solutions in subsequent parts of the series. ## Sections - [00:00:00](https://www.youtube.com/watch?v=Fp2In_la9DE&t=0s) **Hybrid Cloud Connectivity Deep Dive** - Savannah introduces the first part of IBM’s hybrid cloud series, covering how to connect private and public clouds, service mesh basics, and integration tools using a stock‑trader sample app. ## Full Transcript
hi everyone my name is Savannah and I'm
a developer advocate with IBM today
I want to start with the first part of
the hybrid cloud architecture series
with a deep dive into connectivity
connectivity is an important concern
when you're starting with your hybrid
cloud strategy and that's why I want to
start with it first by establishing
connectivity we can then start thinking
about other requirements and then move
on to the other parts of the series
there's three major parts about
connectivity that won't that I want to
hit with this video starting with very
simply how do you actually connect
private and public cloud environments
next I'll be moving on to the service
mesh essentially enabling your
applications and micro services to work
with one another as one singular mesh
and then we'll close it off by talking
about some integration tools that we
have available to make it easier to
connect up your services and third-party
services and that kind of thing to
better explain and set the set the stage
for the rest of the topics I want to
introduce a stock trader sample
application that will be kind of
revisiting with this architecture so
let's get started over here we have a
consumer application whether it's a
mobile app a web browser whatever it
might be
and whenever user accesses the stock
trader application they'll be hitting
the private cloud endpoint at this point
they'll be fed into the kubernetes
cluster that we have here and within
this kubernetes cluster we have a number
of services the first service that
they're going to hit is the the trader
so this will be the end of the
application so there'll be kind of an
exposure from the trader to the outside
of that cluster the trader in turn goes
in creates portfolios so this
essentially is the the reason why people
use stock trader is to create these
portfolios to manage their investments
and their and their trades and that kind
of thing this portfolios app then in
turn has a couple of services that it
takes advantage of which it actually
pulls from the public cloud one it
actually needs to get the
price of a stock and to do that we have
a service in the public cloud which
we'll call get which actually goes off
to the investors exchange API to access
the the current stock price so it'll
take advantage of that and then to kind
of feed that data back we have a egress
setup so external API request that
allows the portfolio app to work
directly with the service that we have
in the public cloud another service that
we have that backs is a stock trader
application is the mq service which is
essentially a message queuing capability
and we're going to be using that to keep
track of the loyalty levels that a user
has when working with their portfolios
so various Commission's would be changed
based on how long that they've kept a
particular stock within their portfolio
and the same thing here so in addition
to portfolios working with the public
cloud the mq service is also going to be
accessing the public cloud however the
mq service isn't concerned with getting
stock prices instead it wants to notify
users whenever there's a change in their
loyalty or in their in their portfolio
and to do that we're actually going to
take advantage of several as
capabilities using cloud functions which
in turn will go and send a message to
the user using a slack integration so
this kind of sets the stage for the
various parts that we have within the
stock trader application and actually
before I forget there's one more piece
to actually persist the data for the
portfolio's we have a dedicated database
service that's hosted in the private
cloud outside of the cluster that the
portfolio's application will be using to
persist the data this kind of sets the
stage for us to jump into the very first
piece that I want to talk about which is
connect so although we've laid out the
architecture here we haven't really
talked about how these applications are
able to work with the public cloud
services although you know generally a
private cloud is going to be behind a
firewall
it's going to be in a restricted network
there's one very easy way to expose
services from private cloud to a public
cloud and that is by taking advantage of
a VPN tunnel and that's one of the
easiest ways to get started an IPSec VPN
tunnel essentially exposes a subnet of
IPs
that can be exposed from the private
cloud and public cloud enabling those
connections to happen so we'll create
that VPN tunnel between the two
environments and one key thing to note
here is that this is all happening over
public internet so this has some caveats
although it was very easy to setup the
problem is that when you're working over
the public Internet you're kind of you
can be kind of affected by variability
in the amount of time a request takes to
travel between the private and public
cloud
in addition VPN you know you're not
gonna get the best bandwidth
capabilities out there because you're
going over the public Internet flows so
there's an alternative to VPNs and
that's taken advantage of direct link
capabilities to create entirely private
connections between your private and
public cloud this is made possible by
taking advantage of apop which is a
point of presence generally provided by
a public cloud and enables completely
private connections to that private
cloud and this kind of always exists to
enable your existing architecture to fit
into this you will need to work with
your network service provider and create
a direct connection for all connections
coming out of your private cloud maybe
you have a whene wide area network to
make sure that all of these connections
flow privately in this way you never
actually actually take advantage of
you're never actually using the internet
for this connection it's all private and
in addition the big advantage of that is
you get much higher bandwidth
capabilities there is one thing though I
want to mention once you have a direct
link like this setup it's also possible
to have a failover which in case that
this doesn't work it'll
kind of fall back and use the VPN over
Internet and by using those two in
conjunction I'd say that's probably the
best way to connect up your networks
from a private and public cloud
environment next I want to talk about
the service mesh there's a great project
out there that you might be familiar
with it's completely open-source it's
called Sto it was created by a number of
industry leaders like Google IBM lifts
and a number of other leaders out there
and you know when we've noticed here we
had taken advantage of kubernetes on our
on our private cloud and let's say that
we're also using kubernetes on the
public cloud although we only have one
service in there so far we'll get around
to creating some additional ones later
on so what we have is two different
clusters in different environments we
want to make sure that they get managed
in an easy way so that your operations
teams don't have to concern themselves
with working with multiple environments
multiple clusters which can lead to you
know an increased kind of load and and
it can be quite difficult to manage so a
service mesh essentially in generally in
the context of is do you manage the
services within a single cluster but
there's been new developments in STL
that allow you to connect up multiple
clusters together and have the services
behave as one singular cluster one mesh
across multiple environments to better
kind of explain this let's let's say
that stock trader wants to create a new
version of trader
so we've got v1 here and we want to make
v2 and this time we want to host it on
the public cloud let's say because we
want to have the front end of the
application geographically closer to
wherever most of our customers are so
we'll create another trader application
and this one is going to be v2 let's say
that you know all this traffic coming
right now so a hundred percent of
traffic flowing into the application is
flowing in here with Sto what we're
going to essentially set up is a gateway
right here and this gateway has a number
of policies that
are kind of enabled and set up by a
control plane so we got here
make a misty Oh control plane so we've
got sto here and that's essentially
enabling us to create policies for this
ingress gateway so essentially all
requests that are flowing in and now
let's say that we want 50% of traffic to
flow through to v1 and then we want 50%
of traffic to flow to v2 very simply
once we have the service mesh set up all
we have to do is create a policy in sto
that tells the Gateway to route the
other traffic and that will actually go
ahead and take advantage of the VPN or
the direct link connection we have to
move 50% of all traffic to this version
of the trader application so you know
very simply taken advantage of sto our
existing connection policies as well as
a control plane we're able to create a
policy that allows us to route a certain
percentage traffic to the new version of
the application this is very useful when
you start thinking about creating new
versions of your app and rolling them
out to your users the last thing I want
to mention along with a steal you also
get a number of awesome analytics and
metrics tracing management capabilities
so all of those health management
capabilities that sto offers they're not
limited to the cluster itself they will
actually manage requests that flow
between all of your services that your
STL mesh is connected to essentially
this gives your operations point
operations team a single point of
management for all of your services
across your environments and the last
thing I want to touch on is integration
so there's a lot of things out there
that are repeated quite often that means
customers are kind of constantly doing
these things so iBM has created a suite
of tools to make integration with those
services easier for example let's
imagine that you have a set of user data
that's stored in Salesforce and you've
already taken advantage of this data
this account data and your on-prem
private cloud applique
but you want to start reusing those
capabilities in the public cloud so in
the public cloud maybe there's certain
network or network challenges that that
change how its implemented you can take
advantage of these integration tools to
very quickly move that data between
Salesforce and your public cloud micro
service applications take an advantage
of some of these tools this is made
possible through connectors that you
know not only connect up Salesforce but
a lot of other services out there things
that we notice that our customers are
doing quite often another integration
tool I want to talk about is an API
gateway and we're noticing more and more
that this is something that really is
something that's really important to the
overall hybrid cloud architecture
especially when you're working with
third-party services so here we actually
have a number of them with Salesforce
slack and the investors exchange let's
say that one of our engineers has a bug
that accidentally hits the investors
exchange way too many times and they're
throttling us which ends up bogging down
the whole system to prevent that from
happening or just to be more secure
about how we're accessing third-party
services what we can do is create a
gateway that essentially sits in between
the public cloud and those third-party
services and allows you to do things
like manage rate limits create
authentication since like oh ah there
maybe even basic keys to really restrict
how your public cloud services as well
as users are accessing those third-party
services so we've noticed that API
gateways in addition to those suite of
tools that I mentioned are a core part
of connecting up your your cloud
services to third-party services and as
well as kind of some of the things that
you have going in your private cloud I'd
say that these three topics are the main
things you want to think about when
figuring out connectivity with your
hybrid cloud architecture as always
we're checking comments for feedback or
ideas for new videos so feel free to
drop a comment below and definitely
subscribe because the next part of this
series would be talking about strategies
to modernize legacy applications thank
you