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

Hello, Kin Lane, API Evangelist here for another one of my API Evangelist conversations, where I sit down with folks who are doing interesting things with APIs and around APIs. So let’s not waste any time, let’s bring on my guest and find out who they are. Hello, who are you?

Hi Kin, good to see you, and hi everyone. This is Subu. I am a software architect, I work as an architect at Citrix Enterprise, Citrix now called Cloud Software Group. I’m very happy to be here on this podcast.

I appreciate you joining me. We’ve known each other for a number of years, followed your career for a while, as you joined me on Breaking Changes. Big fan, but I love the trajectory your career is taking, because I think it reflects where I’m going as far as just the realities of the world we operate in. So can you give us a little overview of your role and what you do, and what changes have you seen in the last couple of years?

To keep it short, I’ll talk about the last, most recent, two, three years. And you’re right Kin, 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 I see that happening in my role as well. So since we spoke last, I moved on to the Citrix Analytics Service for Security, and the focus there was to see how we can cut down the cloud cost. 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 do that was through looking at all our cloud infrastructure and downsizing, right-sizing things, and cutting down what’s not needed, so that we stay within the limits as far as that cost is concerned. Because at the end of the day, 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 delivering value which matters to them. And that might not always be the coolest and the greatest of 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 then it leaves both the parties happy, because business is good, you are solving real customers’ problems, delivering value, and getting back appreciation and even goodwill. So that’s another trend which I’m seeing happen a lot, and I think it’s for good.

The third thing I would say is, even with 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 worked much on the client side, I have mostly been an API guy or the backend service guy, 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 matter to them. So good learning at the same time, good value which is coming out of all the experts, and good feedback, just from customers. So in a nutshell, that’s what has been happening for the last few years and months, and I’ll be happy to answer any specific questions or if anybody wants.

Well, you’re active on LinkedIn and social media, you tune in to the outside world, that’s one of the reasons we know each other. So is this just a Citrix kind of trend, or is this something you think is bigger?

It’s absolutely bigger. So the only thing I feel is that Citrix is likely ahead of the way, or I give the credit to the new leadership we have, which is able to sense these trends a little bit ahead of time and positioning us well for handling what’s coming. But in all honesty, I don’t think it’s restricted to Citrix. 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 an opinionated, one-sided view on how something should evolve, or how technology should look like, I don’t think that’s Citrix, that’s true for the industry. And I don’t think, even if there are exceptions there will be a few, but for the most part I think all these trends are very, very prevalent and relevant to most of the industry.

So APIs, I think what I’m learning after almost 15 years of doing this, I feel like APIs are important but they’re kind of fading into the background, like the web and just how we use technology and web-based internet technology. And I feel like everything I just heard you say, what you talked about in the last two bits, you talked about everything we’ve been kind of pedaling and selling with APIs, and APIs as products and life cycle and consumers and all this, but you didn’t mention APIs at all in there. You just talked about saving money, doing more with less, hitting on what customers want. I mean, so do you think this is going to continue as far as your career is concerned?

Well, sure, and let me also address that, because that’s a very fair and good question Kin. Again, not to say that my love for APIs has reduced or diminished or disappeared, not at all, Kin. But everything I said applies to APIs, and I can give you good examples for that as well. 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 cost. So 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 lean and mean and still effective and solving the problem? So definitely what I said has been done for the API infrastructure as well, the API platform has done that, 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, the mindset wherein you just keep building APIs and hope and wait for one customer or some customers to show up someday 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 you 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. Then either deprecate or not invest more, or, you’re just building it for the joy of it or the fun of it, but you’re not necessarily meeting any customer needs. So meeting the customer where they are completely and absolutely applies to APIs 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, in terms of technology there’s no end to it, you have all kinds of APIs, REST, GraphQL, and whatnot, but do you really need it? Again, I’m not being against any technology per se here, but the simple point I’m trying to make 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 wiring something more than what’s needed. And trust me when I say this, customers are happy when you solve their problem, they are not necessarily happy when you use the bullet train, that, in most cases they don’t know, in most cases they don’t care what you are doing. But if you solve that problem, you’re 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 jargon and keywords at them and technologies at them, we still, I mean, I’m talking from all my experience, so actually everything I said applies to APIs as well.

Amen. So well said, it so reflects what this is all about, it’s a very, very people thing. Now, from a career perspective, you said you’re mostly a backend API person. What do you recommend for other backend engineers who may not be as good at speaking as you are, as good at talking to customers, as good at dealing with front-end applications? Do you recommend more backend developers do it, you did, or is it just something that you personally did?

You should definitely, I mean, that is not going anywhere Kin, that’s going to stay there forever. And again, I recently read this quote that 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 fall into that same category, that’s not going anywhere. But one word of caution, I would, 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 that quick technical solution, okay, how do I build this, 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, what problems are we planning to solve? Because it might appear to you that somebody has done that thinking, but take it from me, in most cases people have not done the groundwork. The first thing they hear from the customer they come and tell you, and you’ll build the whole thing only to realize that that’s not what the customer needed, and again go back into that loop. So one way you can become more valuable and more efficient at what you do is always question, like, why are we doing this, what’s the outcome we are trying to achieve, and keep that as your north star. So any time you’re 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 is going to solve, what is it that it’s going to enable an end user to do, what value it will deliver. So keep the value always at the back of your head, and I’m telling you, you will not go wrong, or most of the time you will not go wrong. And I’m purely talking based on experience, and all the mistakes, 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 a thing which is not needed actually. So that would be my few cents of advice on that.

So you mentioned adaptability, flexibility, learning, all these things. How do you know what to pay attention to or prioritize in this world of technology? I mean, there’s so many things to learn, and now we’re in with AI and all these new ways of doing things. So how do you recommend someone deal with it from a career perspective, how do you stay adaptable, flexible, and know what to prioritize?

Sure, again, a great question, and let me try to capture as much inputs as I can on that. You talk about AI, Kin, again, my view on that is, 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 not be true. But at the same time, it’s not true that you should totally ignore it. So the way I look at it is, I look at it like a great slave but a poor master. So if you want to give it a position or a place where it’s going to dictate everything to you, then you are relegating yourself to something which is insignificant, I don’t think we should do that. We should use it more like a slave, use it more like something which is there to assist. And I use it quite a lot for doing quick POCs on areas which I have no experience in, so it’s a very good way for quick learning and turning out a prototype, 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 do all that that I normally do as an engineer. But at the same time, I would not ignore it, 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 like with 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 there is, use it as a good assistant, make use of it, but at the same time complement 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 more than anything else. So instead of being stuck and rigid about anything, be it technology, be it a product feature, or roadmap strategy, whatever, for sure have your opinions, for sure have a point of view, but be willing to change it, be willing to question it and adapt it as 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 we keep sticking to what we are doing, it’ll go back to what I was telling before, that we’ll end up building something which is actually irrelevant, it’s not solving real customer problems, or it’s not adding real value to the people, and then again you will feel demotivated, you will feel that, why did I put so much effort on something which didn’t land. 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, to play along with what’s happening. And then when you do it that way, I feel that, yes, it’s a bit philosophical but it’s also equally interesting, and a good learning experience, other than just doing monotonous kinds of things all the time, because these days you never know what will work, so always good to be ready to experiment, change, and adapt.

Love it. Always love hearing from you, you’re very practical, pragmatic, and just more human than the technology, is what I love about your approach. I appreciate you coming by and having a conversation with me today, Subu.

Absolutely, thank you so much for the opportunity, Kin. It’s always lovely to connect with you, and as I said, I enjoy both the technical, business, as well as the human aspect that you bring to that, so it’s a pleasure to know you and talk to you, and I’ll see you.

Same here, my friend, thank you so much.

All right, awesome. I always love talking with him, because just that pragmatic, last time check out the Breaking Changes podcast where we talked about governance, definitely one of the reasons why I went to Bloomberg and went out into the field to try to understand governance, is some of the people aspects that he had shared with me. So, great, another great conversation. What’s cool about this format is I can have him back, we can dive into cost management, we can dive into talking to customers, and so you’ll be seeing more. Well, thank you everyone, I appreciate it, have a good day.