API Evangelist Conversation with Subramanian Krishnan, Architect and API Integration at Cloud Software Group within Citrix

Hi, Ken. Uh, good to see you. And hi everyone. This is bu uh, I’m a software architect. I work as the architect for Citrix Enterprise Browser in Citrix now called Cloud Software Group. And I’m very happy to be here on this podcast with Kim. As always,

Sure, Ken. Uh, and I mean, to keep it short, I’ll not go too far in the past. So maybe I’ll talk about the last, most recent, uh, two, three years. And, uh, you’re right, Ken. I mean, there’s a lot of change, a lot of dynamic changes happening in the industry as we speak. And that’s been true for the last few years. And, and I see that happening in my role as well. So, uh, since we spoke last, like I moved on to the Citrix analytics service for security and Uh, the focus there was to see how we can cut down the cloud costs. So normally, typically as architects and engineers, we focus a lot on new feature development, but here was this change in the role where we were focusing on seeing how to deliver value to the customers, but at an optimal cost. And the way to that was to, you know, uh, looking at all our cloud infrastructure and downsizing, right sizing things. And cutting down what’s not needed so that we are, we stay within the limits for as far as the cost is concerned, because at the end of the day, uh, technology is great, but then the business also has to make sense, right? So that was this role and it was a very good learning and a very different perspective for me as compared to what I’ve done in the past. Moving on from there, the other theme I see very prominently emerging in the last few months and years is a lot of focus on existing customers, not trying to go and make new customers, but trying to keep the ones that you have happy. And what that means is if your existing customers are on premise, they are not on cloud, they don’t want to be on cloud. You honor that you respect that you don’t try to push them to the cloud if they don’t want to be there. And again, what this meant for us is trying to look at existing customer issues, the existing stacks for the legacy products, and then improving it, bringing in enhancements, fixing the issues that customers are reporting and not delivering value, which matters to them. And that might not always mean the coolest and the greatest of the technology, but. It always brings a lot of satisfaction because whatever you build is something to their needs, which means it’s immediately adopted. You hear good feedback and it leaves both the parties happy because business is good. You are solving real customer problems, delivering value and getting back appreciation and even good business from them. So that’s the other trend which I’m seeing happen a lot. And I think it’s so good. Uh, the third thing I would, uh, you know, uh, say is, uh, given all the different changes happening in the industry, it’s very important to stay flexible, stay adaptable and not be rigid. Because even in my own career, I’m seeing that every six months to one year, I find myself at the crossroads of something totally new, something I’ve not done before. And the classic example is enterprise browser. So I have never not worked much on the client side. I have mostly been an API guy or the backend service guy. Okay. And here for a change, I am an architect for the enterprise browser. And that was initially different and new, but then I played along and there was very good learning that was happening for me there. And as I said before, we were working very closely with our customers and trying to build things which really matters to them. So, uh, good learning at the same time, good value, which is coming out of the, all the efforts and good feedback and just from customers. So in a nutshell, like that’s what has been happening again for the last few years and sensory support. And I’ll be happy, happy to answer any specific questions or anybody.

it’s absolutely bigger. So the only thing I feel that is Citrix is slightly ahead of the way, or I can, I give the credit to the leadership, new leadership we have, which is able to sense these trends. a little bit ahead of time and positioning us well for, you know, handling what’s coming our way. But in all honesty, I don’t think it’s restricted to Citrix, like be, uh, meeting the customers where they are being very, very cloud conscious, very, very cost conscious and doing the right thing for the customers and not having opinionated one sided view on how something should evolve or what, how technology should look like. I don’t think that’s Citrix. That’s, that’s, that’s true for the industry. And I don’t, I think, uh, even if there are exceptions, there’ll be far and few, but for the most, I think all these teams are very, very prevalent and relevant to the most of the industry.

Uh, sure. And then let me answer that because that’s a very fair and good question, Ken. So again, not to say that my love for API has reduced or diminished or disappeared. Not at all the case. In fact, everything I said applies to API. Then I can give you good examples for that as well. Uh. So cost cutting, again, we have worked a lot and it might not be me directly, but parts of my other teams that focus on that area have been working on how to reduce API infrastructure costs. So, and again, for every API call we are getting, there is some cost we are incurring, right? So how do you make sure that that’s optimal and you reduce unwanted pieces from the puzzle and only keep it to lean and mean? still effective at solving the problem. So definitely what I said has been done for the API infrastructure as well. API platform as well. That’s absolutely relevant there. And from the standpoint of what customer needs again, instead of just, and we have talked about it in the past as well. So the mindset wherein you just keep building APIs and hope and wait for one customer or some customers to show up Sunday and start using the APIs. Instead of that approach, taking the outside in approach and you start looking at what’s the pain point, what’s the problem we are solving and which is the API, how do you design an API and what kind of an API is going to solve the problem and build only those APIs and either deprecate or not invest more on APIs which are going to solve the problem. very much. You are just building it for the joy of it or the fun of it, but you’re not necessarily meeting any customer needs. So meet customer where they are completely and absolutely applies to a P as well. And last, but not the least, even in terms of which type of APIs you are building. And again, we have spoken about this briefly, Ken. So in terms of cool technology, there’s no end to it. Like you have all kinds of APIs that GraphQL and, and whatnot. But do you really need it? Again, I’m not being against any technology per se here, but simple point I’m trying to make here is that the actual customer need, if it can be solved using a simple HTTP REST API, that’s about it. I mean, there is no need to add complexity to it. There’s no need to add cost to it by building something more than what’s needed. Trust me when I say this, customers are happy when you solve their problem. They are not necessarily happy when you use the coolest of the technology. In most cases, they don’t know. In most cases, they don’t care what you are doing, but if you solve their problem, you are good in their eyes and you could have used whichever technology you feel like doing for that. But if you don’t solve that problem and throw all jargons and keywords at them and technologies at them, they still complain. I mean, I’m talking purely based on my experience. So actually everything I said applies equally to APIs as well.

You should definitely, I mean, that is not going anywhere, Kim. That’s going to stay there forever. And I can, I recently read this code that, you know, SQL has been there for all this while, and it’s going to be there for long after we are gone. I think APIs and backends now fall into that same category. That’s not going anywhere, but one word of caution, or instead of saying caution, I think the better thing to say is one word of advice I would have is. Be very conscious of what you are doing. And as I said, try to align it with real needs. So instead of jumping onto the quick technical solution, okay, how do I build this? Like, should I use Node. js or Flask? I mean, of course do all of that, but always ask this question, why are we doing this? Like, what problems are we planning to solve? Because it might appear to you that somebody has done that thinking, but take it from me that in more, most cases, people have not done the groundwork. The first thing they hear from customer, they’ll come and tell you, and you’ll build the whole thing only to realize that that’s not what the customer needed. And again, you’re back into that loop. So one way you can, you know, become more valuable and more efficient at what you do is. It’s always question like why we are doing this, what’s the outcome we are trying to achieve and keep that as your north star. So anytime you are building as much as you pay attention to the design, to the API design, to the code, to the implementation, testing, documentation, all that is great. But Equally, you should have it clear in your head, what is the kind of problem this API is gonna solve? What is it that it’s gonna enable an end user to do? What value it’ll deliver? So keep the value always at the back of your head, and I’m telling you, you’ll not go wrong. Or at least most of the time, you’ll not go wrong. And again, I’m purely talking based on experience and all the mistakes are. Most of the times I have regretted is when I didn’t pay attention to the value question. I jumped into the technology and focused only on that, only to build perfectly the thing which is not needed actually. So that would be my, you know, a few cents of advice in that.

Sure. Again, again, a great question. And let me try to capture as much, you know, uh, inputs I can capture on that. You, you talked about AI can, so again, my view on that is again, it’s cool. It’s great, but it’s also overhyped and there’s a lot of narratives being built around it, which may or may not be true. But at the same time, it’s not prudent to totally ignore it. So the way I look at it is that I look at it like a great slave, but a poor master. So if you want to give it to a position or a place where it’s going to dictate everything to you, then you are relegating yourself to something which is insignificant. And I don’t think we should do that. We should use it more like a slave, use it more like something which is to assist and I use it quite a lot for doing quick POCs on areas which have no experience in. So it’s a very good way for quick learning and turning out prototypes, but I wouldn’t just take that code and put it in production any day. I would still use manual effort to validate and test and, you know, do all that I normally do as an engineer. So, uh, but at the same time, I’m not ignored because it does give you speed. It gives you quick opportunities to learn things and quickly turn things around in terms of working prototypes. So that’s one area. And likewise, learning anything new, I always start with asking AI, but then after that I do my own reading. I go back to my traditional ways of learning. So one advice that is that use it as, as a good assistant. Make use of it. And, but at the same time, compliment it with all your traditional skills and traditional strengths you bring to the table. So that I think makes a powerful combination rather than choosing this way or that way, which I think loses out on something or the other. So that’s, as far as AI is concerned in terms of adaptability and flexibility, what I would say is it’s more of a mindset game in more than anything else. So instead of, you know, being stuck and rigid about anything, be it technology, be it, you know, uh, product feature or. roadmap, strategy, whatever, for sure, have your opinions for sure have point of views, but be willing to change it, be willing to question it and adapt it as you know, your environment changes, because what’s happening today is that things are changing too fast around us. And if we don’t pay attention to those signals, if we don’t align to that, and if you keep sticking to what we are doing, it’ll go back to what I was telling before that we’ll end up making or building something. which is actually irrelevant. It’s not solving real customer problems, or it’s not adding real value to real people. And then again, you will feel demotivated. You will feel that, you know, why did I put so much effort on something which didn’t land anywhere? Right? So when I say adaptable and flexible, it’s like being open and aware of what’s going on around you and being willing to make changes in your thought process, in your strategy, even in your skill set and approach. Uh, to play along with what’s happening and then when you do it that way, I feel that yes, it’s, it’s a bit difficult, but it’s also equally interesting and you know, it gives a good learning experience, uh, other than, you know, just doing monotonous, same kind of things all the time because you These days, you never know what will work. So always good to be ready to experiment, change, and adapt.