Welcome to the Open Source Way. This is our podcast series, SAP's podcast series about the difference that open source can be. And in each episode, we'll talk with experts about the Open Source Way and why they do it the Open Source Way. I'm your host, Karsten Hohage, and in this episode, I will talk to Satyajit Krishnan and Pavan Nayak about CAP Operator. Hi Satya and hi Pavan. Great to have you both here. Now let's look at who these guys are.
Satya is an architect in the Cloud Europe area and he has been working at SAP for 16 years. His time at SAP has been split between product development and executing customer-specific development projects. So I assume that's custom development, but we can clarify that later. Pavan is an architect in the cloud ERP area with 17 years of experience, also across different projects at SAP.
As we're talking about the open source today, Pavan was also part of UI5, parts of which, as we've talked about in this podcast series, are open sourced within SAP, that is. And he also has an interest in several open source projects outside SAP. Most prominently, the custom ROM scene with AOSP, as if that would mean anything to me. Pavan, let's start with you. Custom ROM, does that have anything to do with the shiny disks that carried music before it went online?
Unfortunately, no. It doesn't have anything to do with that. So custom ROM and AOSP refers to the Android operating system, the OS that runs on your mobile phones or other Android devices. So those are basically any customized versions of Android, which is open source, is referred to as custom ROMs and in that part of the world where you talk about this thing. So yeah, that's what it refers to here, Augustin.
Okay, but ROM still stands for read-only memory also in that case?
Absolutely, absolutely.
Okay. Yeah, at least that has in common. Absolutely. Okay. By the way, you're both located in Waldorf, is that correct?
Correct, yes.
Okay, so you also have about 36 degrees right now, right?
Yeah, that's why I'm here in the basement.
Yeah, great thing to wear headphones on a day like that, right? Right. Satya, when I just assumed customer-specific development projects, was that in the custom development organization or something different?
Yeah, you are exactly right, Karsten. So I was working also as part of the SAP custom development for some projects related to cloud for sales, as it was called some time back. So this is on the CRM side of things. And there I was working for certain customers here in Europe.
Any open sources employed in these projects?
Oh, no, that would be a very difficult thing, I'm afraid, because I know that in some BTP-related projects, they are using open source libraries, especially for security and so on and so forth, which are available. But most of the projects I was working on was mostly proprietary code, which was, yeah, unfortunately.
Okay, then let's turn away from that. And let's turn to our actual open source topic of the day, which generally has to do with, let's say, operating CAP applications in the Kubernetes environment, as far as I understood it. So that's pretty deep down. Would you say there are prerequisites to benefit from this episode?
Out? Maybe I take that one. So the prerequisites that I see would be containerizing applications. You would know how to do that. Then as we are operating mainly on Kubernetes, so knowledge about Kubernetes, what Kubernetes operators are, what are Kubernetes controllers, and as it's the CAP operator, so knowledge about CAP and using CAP with PTP services. So basically anyone that wants to operate a CAP application is welcome to look at the CAP operator. I would say that's a big positive.
Okay, good thing that I'm a total expert on all of this. But anyway, Satya, before we go into Cap Operator, it deals with Kubernetes controllers, right? What are they usually used for?
Yeah, that is right, Karsten. So in Kubernetes, one of the most important concepts is that of a control loop. So basically, you would be defining what would be the specified state or the desired state of the system as these YAML files. And there are certain components in the background which are then trying to bring the system to this desired state from the current or actual state.
So the easiest way to think about this is to think about a thermostat which is usually in your rooms so you change the dial on the thermostat to specify what the temperature of the room should be and then based on that in the background there is equipment working to either turn it on or off to keep the temperature at that level so if it just becomes colder it heats up the room and then vice versa so that's one thing to keep in mind
and when i say when we talk about controllers Controllers are exactly this component, which is running this control loop and always checking for all the specifications in this Kubernetes system. What is the desired state to go to and then continuously working to achieve that state. So those are controllers, let's say.
Okay, so as you use an analogy, and I like to check analogies, that means the environment does need, absolutely need the controllers to run, only to put it in the desired state, just like with the heating. The heating runs anyway, and the thermostat then says how much it should run or how it should distribute, right?
Yes, exactly. So what we do with these controllers is it runs in the background to kind of make sure that the actual state and the desired state are always the same. So it's always running.
It is a continuously running loop. and what is important also maybe just to mention here is that kubernetes is extendable so what it provides us the capability to do is in addition to all the standard controllers which are there as part of kubernetes we can build also our own controllers and that is an example which we are going to talk about now okay
So now we're taking it over to cap operator if i get it correctly.
Exactly.
Pavan, can you, as a first step, very briefly explain what exactly that is and.
Absolutely. So to add to what Satya said, you know, Kubernetes is extendable. And what we have done with the Kappa operator is we have created our own custom resources that manage the lifecycle of Kappa applications. With that, what I mean by lifecycle is you can now like deploy application onto Kubernetes cluster using these custom resources and our controller will reconcile them. It can help manage different application versions.
It can help you to, you know, when you, as you talk about multi-tenant CAP applications, that's the target audience for our operator. This basically means that we can onboard and off-board tenants. And, you know, we also have like a possibility to have custom operations for tenants, et cetera. So it basically makes use of what just, what I said here, our operator will basically provide these custom resources, which you can now create.
And when you deploy it on the Kubernetes cluster, our controller from the CAP operator will We'll reconcile all of these and do these things that I mentioned just now in brief.
Okay. By the way, I originally had thought the name was CAP Operators in plural, but it really only is Cap Operator Singular, right?
Yes.
Okay. Because it's basically, I don't know, it points to this is the software that replaces the person who does all this.
Yeah.
Okay. Okay. So do we need more detail on that one, how CAP Operator does all that, Satya, or was Pavan's explanation already covering it?
So Pavan gave you a really good explanation of what it is doing or what is the purpose of having this operator. So maybe I can add a little bit about what are the different components of the operator and how we handle these things. So like you just mentioned, Karsten, the Kubernetes operator or the CAP operator is trying to capture the key goal of a human operator or a DevOps person in the end. So how it does it is it has three different components, more or less, I would say, inside.
So one of the heart of it is the controller, as we just talked about, which is looking at two different resources. So CAP operator defines two different YAML schemas. One is called the CAP application and one is called the CAP application version. And looking at this, it reconciles and creates all the different workloads which are required. So when I say workloads, these are probably CAP application servers or you can also say maybe microservices which are running within the Kubernetes cluster.
Other things like networking on top and everything is also taken care of the second component which is of interest is called a subscription server this basically integrates with btp's task provisioning service so whenever tenants are onboarded onto your cap application so this comes from this central service and the cap operator is able to receive these calls and then take care of tenant operations like provisioning and all to create these new tenants yeah
so just to put it very simply while creating a new tenant you might need to create the new database schemas which are isolated for this new customer create networking on top and allow requests from the outside to reach this particular Tenant-based service so that's basically what it does i hope that gives a little bit more light on this
It leads me to a totally different question, or actually not totally different, but it leads me to the question that assume that BTP or Gardner or whatever would deliver some of what you described out of the box. So how did the need for cap operator arise? Or do I have this totally wrong from my mapping?
Maybe I try to answer that for you, Karsten. And so what we did is when we all started off, we also hoped that some of these parts would already be present, like you thought, on BTP and Gardner. And some of this, like the networking aspects, do exist on Gardner. But we manually have to then somehow create all these things on our own. And we didn't find anywhere something that was provided yet that was automating this whole thing as such.
So what we did is when we started off in the mid-market organizations, we both are formerly part of this mid-market team. And there we already built, we saw this need that we, here we had to do a lot of applications quickly and built, like purpose built for different market segments and so on. And there we then had to build a lot of applications that we had to deliver. And for operating all of these, we saw this missing automation. And that's why we built this initially for our own purpose.
And then as we saw, this probably solved the bigger goal. We then made it inner source within SAP. So other teams across SAP could also then try to use it and benefit from what we are doing. And finally, actually, since about a year ago, I think in last year, we made this whole open source because we see that the overall goal of running CAP application is not just limited to something within SAP. Even if customers want to use CAP, which is also available externally, right?
So they could also, and if they have a Kubernetes cluster that they are running already, they could make use of the CAP operator and they could then do the same on their own. So basically, to answer your question, this need became also from us that we also hope that there was something available. And when we didn't see this, we try to fulfill that on our own. So that helps answer.
Okay. Let me try an analogy then. Is that kind of cap operator is just simply a bit ahead of say BTP and Gardener with certain possibilities of managing your Kubernetes environment i don't know analogy they used to be for those who remember the so-called Windows power tools who would deliver things some user gimmicks but also some administrative stuff sometimes that was not released within windows before the next version
often or they figured okay this is not what we needed and take it back out again. Is that an analogy or does that not work at all?
Yeah, so let me answer that, Karsten. So I think that is a good analogy. So in the past at SAP, we have also had different types of platforms as changes in technology have happened. So we had Neo, then we had Cloud Foundry. Now we are using Kubernetes. So the platform themselves, they are completely coming from outside. So it provides a lot of flexibility. But at SAP, we have our own processes on top, which need to be also tied in.
So as these platforms grow, you would see that Cloud Foundry is quite mature. Kubernetes is being adopted. And we also need to build in more tooling around it to make it more mature and easy to consume for building SAP specific applications or applications which follow the B2B multi-tenancy paradigm. So your analogy is right. So we also hope that the CAP operator, we made it open source. We can also get contributions from other experienced application developers.
And hopefully in the future, a version of this would also be part of B2B platform coming out of the box.
Okay, at least it sounds like a great idea to do this open source. And Pavan, correct me if I'm wrong, this is now all available under Apache license, right?
Yes, absolutely, you're right. It's under Apache license, yeah.
Okay, and how's the community going? Are you getting feedback or contributions even, or is it more like spectators?
We have a bit of a long answer for that. We are still building up, so we don't have any active contributions with respect to code as of now, but we do have a lot of feedback, and mainly the feedback has been with respect to feature requests that have been asked by the teams who are currently using it or some feedback with documentation and so on that we have to incorporate and also to add in about overall community, what you mentioned over here, right?
So to give you some background, you know, we, from SAP, we have a small team working on this, just the three of us, the three people working on this topic. But what we are also having from a community point of view is as it is a CAP operator, we are also closely working with the CAP colleagues. And now we also have a plugin that we have released as part of the CAPJS organization, which is also open source.
And there I think we are getting feedback from CAP colleagues and other consumers who have been using the CAP operator. And the aim of this plugin is basically to make it easy for any consumers who are already on CAP to create the resources that we talked about earlier, this custom resources, this YAML files, to make it easier to get onboarded onto Kubernetes. it is.
So these plugins will hopefully then help and there we, with feedback from the community, we also will hope to get, you know, further into this topic and build more features in there.
Yeah, well, I mean, feature requests is always a good start in ways of people collaborating, right? I mean, you do have to know what's needed out there, right?
Yes, absolutely. But like Satya also mentioned, if there's someone who sees the need for this and sees other things that can help other people out of it, they are free to also actively contribute. You're also welcome to that.
Yep, yep, yep. Yep. And we talked about Apache license, but I do assume correctly, this is an open source project, but it's SAP-governed, I guess, right?
Absolutely. It's governed by SAP. It's open source, so you're free to consume it.
Okay. Anything else? What's the plan for the future, for example?
Couple? With respect to the CAP operator, one thing you can assume based on your previous question as well is we are working to get the CAP operator delivered out of the box, maybe into the Kyma platform of SAP. They have this concept of modules and maybe soon we may have something which comes out of the box. Currently it is possible to directly install it into any Kyma cluster and use it, but we want to make the experience even more convenient.
Other things which we are targeting, let's say, are with respect to the extensibility concept of the CAP application programming model. So we want to also invest a little bit into managing the lifecycle of those extensions, which might be built on top of the application with CAP. We will also look into, let's say, capabilities where the application can expose certain metrics and we will integrate some monitoring capabilities also for the application out of the box.
So these are maybe some of the things which we are currently looking at and which we hope to have going forward.
And as you mentioned monitoring, that would be monitoring for that stuff which is also being managed by controllers that again are being controlled by the CAP operator, right? Or is it general monitoring you're talking about?
You are right. So there are two types. you can divide into broadly. So there are things which are managed from a resource point of view. Let's say a workload is consuming so much CPU or memory and so on, and you would like to monitor this. So Kubernetes already provides certain things to see this and have dashboards built on it and so on, right? But the other aspect, which is also is maybe the application is handling things in a certain way.
So this would be more like how many login sessions are currently active. So how many database connections are currently active on the application? So these are metrics which are still very important, but they are maybe more individual to the type of application which is being built. So such things also we would like to see whether we can generically cover specific to CAP applications.
Okay, okay. I just asked that return question because in ways of monitoring, we have sometimes more the issue of partially redundant tools, right? And then the question is, what do you monitor where? But I guess you will be paying attention to that. Who am I to ask? Anyway, information about all of this, is it just GitHub repo or anywhere else you want to send people?
We have a GitHub repo. We also have a page, a GitHub page, where you can link to support, also link to the GitHub repo. So this is where you find the most prominent information about repository documentation. We have pretty good documentation also in the GitHub page. And we also have a plugin, and all of this will link with the podcast today.
Yep, absolutely.
Maybe, Satya, there's something else to add that I missed.
If there is anything else to add to the links, you can always let us know. We always have a list of links under the podcast. Sacha, did you want to add anything?
Yeah, I just wanted to mention that we are also working on some samples on the SAP samples open source repository. So there are certain applications like a CAP multi-tenant sample. So we are contributing right now to provide Helm charts and so on, which kind of show how you can use the CAP operator also with those applications. So this would also be good.
That would be sample content, right? For the CAP operator. Okay.
Sample content, exactly.
Okay. Exactly. Good, good. In the history of things, that was always what made things successful way back in the days. But, I mean, you're 16, 17 years here. The BW, the business warehouse, was at first, I think, only a platform. And when they started to deliver analytics content, it became successful.
Successful so content is always king i guess absolutely now yeah we have come to actually i didn't announce the before last question that was the uh the where do you go to find info now we are directly headed to the last question which is always if you want people to remember two three things some people call it the key takeaways from this podcast episode what would they be maybe Maybe, Pavan, you want to start and take turns? Yeah, absolutely.
So I'll start off with this. So I would say the first key takeaway would be if you're looking to operate, you know, a multi-tenant CAP application on Kubernetes, then the CAP operator provides you sort of a paved road, which will help you get up and running quickly with minimal efforts with respect to setup, configuration, etc. So that would be, I would say, the first key takeaway from my perspective.
Okay, Satya, then your turn.
Yeah, so I would like to add that even if you are completely new to Kubernetes, but want to understand this multi-tenancy concept around SAP-based applications, it is a good place to start. So you can start with a very minimal configuration, then understand how the multi-tenancy is tackled with the different ideas in the operator, and then gradually you do more advanced things with Kubernetes, like, for example, spreading out workloads across different regions and so on.
Okay, one last one.
Yeah, so as we are talking to the open source world community over here, I would say that we are really open to support anyone of you who is going on a journey to run, operate, automate multi-tenant CAP applications on Kubernetes. And if you see something missing, and more importantly, if you have a scenario that you see that could really help others benefit from that, so we would welcome any such contributions, feedback, or anything along those lines into our repository.
And even if you would like to add some samples and references of how you use the CAP operator, please, you're welcome to do that and that would be really great for us. That would be all that I have to add.
Alright. Okay, great. As this is the open source way, that was of course the, best final key takeaway we can have, the call for collaboration. With that, I I believe we are through for today. Thank you, Satya and Pavan, for doing some heavy duty explaining to the moderator today.
It was a pleasure to be here. Thanks for having us, Karsten.
Yeah, thank you. Thank you very much for having us.
You are more than welcome. And all of you out there, thank you for listening to The Open Source Way. If you enjoyed this episode, please share it.
Don't miss the next one. we used to publish every last Wednesday of the month this has gotten a bit off but of course you're totally subscribed to us so you will find out when the next episode comes out you'll find us on all the regular mainstream Apple, Spotify and so on podcasts at SAP Podcasts but you can of course also use open source podcast clients, to listen to this podcast thanks again thanks again Satya and Pavan and bye bye for now.