Ryan Niksch (00:00):
Greetings. My name is Ryan Niksch. I am a Principal Solutions Architect with Amazon Web Services. Joining me here today is Charlotte from Red Hat. Charlotte, say hi.

Charlotte Fung (00:09):
Hi, everybody. My name is Charlotte Fung and I manage OpenShift Black Belt at Red Hat. Thank you for having me here, Ryan.

Ryan Niksch (00:18):
Always a pleasure. Charlotte, I've been working with OpenShift customers, more notably the Red Hat OpenShift Service on AWS, or the managed version of OpenShift. And a common question I get from my customers is: "Yes, it's a managed service, what does that actually mean? What do I, as a customer, focus on? What does Red Hat do for me? What are the things that infrastructure teams, administrators, operators, not have to worry about?" And secondly, when they need to reach out to support, what is the simplest path for that? Who does a customer reach out to from a support perspective? And I think you've been working with a lot of customers and you've sort of unpacked this quite nicely.

Charlotte Fung (01:03):
Yeah. Thank you so much, Ryan, for that question, which is really an important one because going from like a serve managed, because that's what usually happens, customers, they go from a serve managed to a managed service, and it causes that confusion, and they're not sure. What am I supposed to do now? What is my responsibility or what is Red Hat's and AWS's responsibility? So on this spot here, I have my two blocks of responsibility separated out. Everything to my left is what the customer should worry about.

Customer responsibilities 

Ryan Niksch (01:38):
Okay, so this is really a customer over here?

Charlotte Fung (01:41):
Yes.

Ryan Niksch (01:46):
And I'm assuming then this side of the fence is what is being provided by the managed service by most likely Red Hat SREs. Is that correct?

Charlotte Fung (01:57):
That's correct.

Ryan Niksch (01:58):
Let's spend some time and talk about the customer side of things here. I noticed that you've specified the application life cycle. So that's the customer's applications, the development of those applications, maintenance of those applications. Do the management teams on the Red Hat side, so the SREs, have access to customers' applications, access to customers' data?

Charlotte Fung (02:22):
No, we have no access to customers' applications, because the customer completely owns that. So SREs have no access to the customer managed projects and applications running in those projects.

Ryan Niksch (02:33):
So very clear separation from an OpenShift project's name spaces perspective, everything that is the customer’s is ring-fenced from the actual cluster. I suppose to some degree, what Red Hat is doing in managing Red Hat's mandate or interest isn't around the applications. It's really to make sure that OpenShift as a platform is always there and working as expected. That way Red Hat focuses on this, the customer can focus on what's important to them and their business, which is their application workloads. You noted user management at the top. What do you mean by that?

Charlotte Fung (03:10):
So for user management, what we do at the platform itself, it comes with an OAuth server, like an authentication operator, and then it downloads the server. And what the customer's responsible for is making sure they grant access to their users, to your projects. Like all of that is the customer's responsibility and you can use the role-based access control that OpenShift comes with.

Ryan Niksch (03:42):
Now there's two parts to that. When I deploy an OpenShift cluster, one of the things I commonly do is I go and configure an identity provider. Whether that's Microsoft Active Directory or whether that's an OIDC type solution. I, as the customer, then have to add users to there and define what those users have access to. So again, everything within the customer's side in terms of who has access to what element of my business is up to me, the customer, not up to Red Hat. If the wheels fall off and I create a starting admin account and something happens to that admin account–doesn't work–I can reach out to Red Hat to assist with that initial account. But that's just there to get the process started. That's not every single user in the directory services.

Charlotte Fung (04:33):
That's absolutely correct. So you have the initial admin account and then after that we recommend that you give somebody dedicated admin privileges or a group of people depending on your business needs, and then you can go from there.

Red Hat responsibilities 

Ryan Niksch (04:53):
Right. Let's shift across to what am I, as a customer, getting from Red Hat in terms of management? What are... I'm assuming these are SREs that are doing most of this?

Charlotte Fung (05:05):
Yes.

Ryan Niksch (05:05):
So over here we have the Red Hat SRE team. What do you mean by each of these? How deep does this go?

Charlotte Fung (05:19):
All right. So the SRE team is actually the team behind the managed service. They're the group that makes this a truly managed service because they take all the heavy lifting. They do all the heavy lifting for you in the background so you don't have to worry about your platform availability and all of that. And so for cluster creation, what we do is we give you a self-service automation for you to just like...

Ryan Niksch (05:48):
I was going to say, you don't create the cluster, I do. I'm the one that types on my keyboard ‘ROSA cluster create.’

Charlotte Fung (05:48):
Exactly.

Ryan Niksch (05:53):
Now what you mean is there's a very, very simple intuitive step for the customer to create the cluster.

Charlotte Fung (05:53):
Exactly.

Ryan Niksch (05:59):
The automation, a lot of the stuff that is prescriptive, it's a much simpler journey to what it was in, say, OpenShift 3.

Charlotte Fung (05:59):
Exactly.

Ryan Niksch (06:08):
And the success or failure of that cluster creation really is within Red Hat. I define which AWS region I'm deploying into, whether it's a Multi-AZ cluster, what OpenShift version. I think there's probably about nine or 10 parameters that I, as a customer, decide. And then the rest is real automation in the background. And the SRE team is monitoring that in the back end...

Charlotte Fung (06:34):
Exactly.

Ryan Niksch (06:35):
...To make sure that that goes ahead. Cluster management, there is a bit of an overlap here because there are things that the customer can do on the cluster, but I think for the most part what we're talking about here is the health of the cluster.

Charlotte Fung (06:50):
Yeah, we're talking about the health of the cluster. We're talking about cluster upgrades, we're talking about changes to the cluster. For example, for cluster upgrades, we do the upgrade for you, but we give you that self-service option where you can program when you want your upgrades to happen, and then it can be automatic or it can be single upgrades depending on what works best for your company. And then we do it at the background and for like... What else was I going to talk about? For change management, capacity management, sorry, we do all the control plane and the in frontal capacity management for you.

Updates perspective

Ryan Niksch (07:35):
So there's two very interesting things there. The first is from an updates perspective, I can choose whether it's automatic or not. And if it's automatic, I define a schedule that works for my business.

Charlotte Fung (07:47):
That's right.

Ryan Niksch (07:47):
If it's not automatic, it's a bit more of a manual request process. I want to update now and I send a request in, and then the SRE teams do the update.

Charlotte Fung (07:56):
That's correct.

Ryan Niksch (07:57):
And that update takes place without impacting my applications. The OpenShift environment is resilient in its design. So I can update one node while the other two nodes are still servicing my applications and will cycle through them. From a break/fix perspective and from a scaling perspective, you've got monitoring that the SREs are doing. So they don't monitor the applications themselves. They're monitoring the cluster and they're looking at what is the consumption on the work nodes, the consumption on the control plane. And if an action is needed, they will either scale those. From a control plane perspective, what I typically see is they will scale the EC two instance types of AWS. So they'll scale vertically, not horizontally.

Charlotte Fung (08:46):
Yeah.

Ryan Niksch (08:47):
How is that communicated to a customer? Is that to reach out to a customer and tell you there's a need for scaling, can we scale or do they just scale it and then notify you that that action is taken?

Charlotte Fung (08:58):
Are you asking about the control plane scale?

Ryan Niksch (09:00):
Let's talk about control plane scaling for example.

Charlotte Fung (09:02):
Okay. So as you said, they're proactively monitoring and they're looking at capacity and seeing if you are continuously going above capacity. And what they do is, as you said, they'll scale that for you and there'll be a notification just to let you know there was some changing capacity that needed to be done because you're needing more, like your workloads are needing more, like they are becoming bigger for our control planes to manage. And then from the customer's perspective, let's say if your workloads are getting bigger and you are using, like, CPU and memory and your workload needs to be scaled and you haven’t enabled autoscaling, you also get a notification from our SRE team.

Ryan Niksch (09:57):
That's a bit of a recommendation process as well. Because I would typically add in a machine autoscaler and define a minimum and a maximum. And that's really the machine autoscaler scaling the infrastructure and then the Kubernetes layer of OpenShift, managing the workloads across that. There's monitoring and logging that's important to customers. There's also monitoring and logging of the cluster itself, and that's telemetry to Red Hat. And network configuration is a bit of an interesting one because, as a customer, when I deploy OpenShift, I am going to define the AWS VPC that it deploys into. I'm going to get options such as the machine side and things.

Charlotte Fung (10:44):
That's right.

Ryan Niksch (10:44):
And what is the network configuration that Red Hat is managing?

Network configuration

Charlotte Fung (10:49):
So the network configuration that we manage, we manage like the default load balancers that come with your cluster. We also manage, if you go with the installer provision, like if you go with our default installation, I should say that, we will provide the VPC for you. We'll provide the sub-netting. We'll also make sure we provide the service networking, the router there that takes care of all the routing inside-

Ryan Niksch (11:19):
So, you're talking a bit about the provisioning process here. When I provision a ROSA cluster, I don't have to build out the entire network environment. I can take advantage of the installer to create that for me.

Charlotte Fung (11:30):
That's right.

Ryan Niksch (11:30):
But I do still have the choice to deploy it into an existing VPC. Likewise, the route layer I think is super important. Because you've got those ingress controllers inside OpenShift that facilitate communication inside OpenShift, SDN to AWS, and the customer doesn't really need to worry about that. And you can now add custom domain names...

Charlotte Fung (11:51):
You can, yeah.

Ryan Niksch (11:52):
...Which extend that automatically. I think we did touch on the software and the security updates. Talk to me about support. So is support and management the same thing? Is there a separation? Are there considerations that customers need to take into account here?

Charlotte Fung (12:10):
Thank you for that. So for management, the SRE team will take care of all of that. When it comes to support, customers have the option because this is jointly supported by Red Hat and by AWS. So it doesn't matter who you contact when you have an issue with your cluster or the infrastructure in which your cluster is running. You can either contact AWS support or you can contact Red Hat support. And whatever issue you're having with the platform will be kind of...

Ryan Niksch (12:43):
So this is a real customer choice. If I have a good working relationship with say AWS, absolutely I can open up a support case with AWS, so they'll provide tier one support. I'm assuming if need be, they can escalate to Red Hat for something that is really OpenShift-specific, and the inverse is also true.

Charlotte Fung (13:02):
That's true. So it doesn't matter where you put the support in, they'll bounce it off each other, different support teams. If it's something that's related to the platform itself, it'll be sent to Red Hat support. If it's related to the infrastructure, like the cloud infrastructure, it will be sent to AWS. Like AWS support will handle that for you, whichever team is best fit in to help with the problem will handle it. And you won't notice any delay because we all do that in the background for you.

Ryan Niksch (13:33):
But this is no longer a case of I, as a customer, don't need to open up a support case with AWS and a separate one to Red Hat and play the middleman. Red Hat and AWS are doing that for me. I choose where I reach out to and they will interact with each other.

Charlotte Fung (13:49):
Absolutely correct.

Ryan Niksch (13:50):
I think there are situations when it becomes very OpenShift specific. So if a customer has questions around how do I do something in OpenShift itself, such as take advantage of an abstraction provided by OpenShift, something that's not related to AWS in any way. To me, it does make sense to open that support case directly to Red Hat.

Charlotte Fung (14:14):
You're right. So yeah.

Ryan Niksch (14:17):
With the SRE team being on the Red Hat side, if I know that there's something where I want the SRE team to potentially make a change, so like a deliberate scaling action, I'm assuming it makes a little bit more sense to, again, open up a support case with the Red Hat side to get to the SRE team quicker.

Charlotte Fung (14:36):
That's right.

Ryan Niksch (14:38):
Is there anything that is super important that we haven't discussed so far?

Charlotte Fung (14:44):
I think we've touched on everything. And what I just want our customers to take home, if there's anything that you should take home from all of this, is everything that pertains to your application, to your users, you'll be like, a hundred percent responsible for them. And everything that pertains to the platform and support, AWS and Red Hat will provide that.

Ryan Niksch (15:06):
I think there's one final thing that we need to do before closing. And that is the management of OpenShift has no impact, no change to the developer. My application owners, they're still doing exactly what they were. They're still getting all of the benefits from OpenShift. This change over here really impacts infrastructure teams, operators, administrators, the developers will see no difference. Same interfaces, same CLI tooling, same pipeline process, same benefits. Life carries on. This is really a business streamlining and agility for the Day-2 operational aspects. So you're really getting the benefit of both things here. Charlotte, as always, fantastic having you here. Thank you for joining me.

Charlotte Fung (16:01):
Thank you so much Ryan.

Ryan Niksch (16:02):
And thank you.

Charlotte Fung (16:04):
Bye everybody.

For more information, learn how Brightly has innovated with ROSA.