The Production-First Mindset

Vonage's Amitha Pulijala - Anticipating The Unanticipated

February 06, 2022 Liran Haimovitch Episode 28
The Production-First Mindset
Vonage's Amitha Pulijala - Anticipating The Unanticipated
Show Notes Transcript

Rookout CTO Liran Haimovitch sits down with Amitha Pulijala, Vice President of Product at Vonage.  They discuss how APIs are the fuel of customer experiences, what it’s like running a business with developers as their core users, video services and the pandemic, and what differences they’re trying to encourage to promote innovation.

Painless Cloud-Native Debugging
Rookout is a disruptive developer solution for Cloud-Native debugging and live data collection.

SPEAKERS
Amitha Pulijala, Liran Haimovitch

Liran Haimovitch  00:02
Welcome to The Production-First Mindset. A podcast where we discuss the world of building code from the lab all the way to production. We explore the tactics, methodologies, and metrics used to drive real customer value by the engineering leaders actually doing it. I'm your host, Liran Haimovitch, CTO and co-founder of Rookout. Today's episode is about APIs and how they're fueling new customer experiences. With us is Amitha Pulijala, VP of Product for video, AI, and platform services at Vonage. She enjoys working with dynamic teams to create large-scale products and loves exploring new technologies. Thank you for joining us and welcome to the show.

Amitha Pulijala  00:50
Happy to be here. Thanks for inviting me.

Liran Haimovitch  00:53
Of course, it's our pleasure. Can you tell us a little bit about yourself?

Amitha Pulijala  00:56
Sure. I'm an entrepreneur at heart and an engineer by training, that combination has served me very well. Because I'm very passionate about ideas that can make life simpler. And at the same time, I think, a logical strategy to execute those ideas. During my career in the software industry, I worked for startups, mid-size companies, and very large organizations. I had a very interesting but very different learning experience at each, I should say. I currently lead Video API, AI, and Platform products at Vonage. Prior to Vonage, I had a long tenure at Oracle, where among other things, I was responsible for Oracle's digital customer experience solutions, and it has been a great journey for me so far.

Liran Haimovitch  01:45
Great stuff. Now, you're today with Vonage. I know you guys are happily building APIs. And a recent guest of the podcast, Tyler Jewell, told me that API as a service is today one of the biggest, fastest-growing market segments in IT. In general, what's your take on that?

Amitha Pulijala  02:03
I absolutely agree. In the past, if you can recall, there were applications which were largely monolithic. Think about ERP systems, or financial systems, which means businesses largely operated in silos, adding any new features to the systems would take months to execute, especially if the systems are complex. And if they don't have developer skills to do everything, that would not work in the digital-first connected world that we are living in today. Today, most of these traditional large applications are broken down and offered as services that are exposed through APIs. And APIs are like these Lego pieces. Companies can use one or more of these Lego pieces to build their services. They can use internal APIs across many services, or they can use a combination of internal and third party API's to extend their functionality and create something new. In fact, I was reading this…data survey that says around 90% of developers, and they estimate this as around 19 million developers. They use APIs, and why shouldn't they? Right? Many APIs lower the barriers of entry for developers to use complex technologies. At Vonage, we provide communications API, if you get a message on a phone that your food order is ready, there's an API behind it. If you're making a doctor's appointment through an automated voice bot, there's an API behind it. And if you are talking to a doctor over a video call, there is an API behind it. So APIs are fueling all kinds of customer experiences and API businesses is one of the fastest-growing businesses at Vonage as well.

Liran Haimovitch  03:53
Now, Vonage didn't start in the API business. Did it?

Amitha Pulijala  03:56
No, you're right. Vonage started out as a residential, telephony, Voice over IP provider about 20 years ago. It pioneered this idea of communications without boundaries. Over the past decade, Vonage entered into the business communication space. By acquiring assets in unified communications, and call center software. Vonage also made heavy investments in API, acquiring companies like Next… over AI. In order to engage customers effectively, you have to reach them where they are, right? Using multiple motor indications to connect with them. At Vonage, we enable those connected customer journeys to our communications APIs.

Liran Haimovitch  04:42
Makes perfect sense. I'm kind of wondering, this must be a big shift from you know, being a service provider to being an API provider. And what's it like running a business with developers as your core users?

Amitha Pulijala  04:55
That's a very interesting journey for us for sure. And as you know, they have been major shifts and disruptions in software for decades, right? Like shift from general software development to a client server technology, or more recent move to cloud, to give some examples. API economy is one such major shift, in my opinion. We are talking about a fundamentally different business model here, there are some points that I want to highlight here. So one is providing value with your API, your developers are always looking for cool tools. And developers are counting on us to bring cool services that they don't have. So we have to provide them value with our APIs. It's a bi-directional relationship. If you provide value with APIs, developers will surprise you with all the things that they can build. We see this day in and day out with our customers, they build very innovative applications and services with our APIs. I'll give you an example here. As you know, bandwidth plays a big role in video experience. And if you have low bandwidth, video quality is not good. During early pandemic days, video moved from one to one communications, to large groups, students moved into classrooms online, there were online meetings, there were online gatherings. And every vendor in the video space was trying to optimize on video quality for these large groups. And there was this customer of ours in India, who used our video APIs to build a virtual classroom during early pandemic days. The classroom had large number of students, and they were joining the classroom through their mobile devices. So the bandwidth was not great. So this vendor came up with a very cool idea of not showing all the videos, but spotlighting just five students at a time. So they'll rotate five students at a time, and they were ensuring low usage bandwidth. But at the same time, they were making sure students were paying attention, because they don't know when their video would be spotlighted. This was pretty cool. They hit two birds at a time, right? They use low bandwidth at the same time, made sure students paid attention. So, these are kind of the cool innovations that we see. The partnership with our customers, and the ecosystem of our developers is very, very important for us. I will also say-- The second point I would say, working with customers across the globe, and developers across the globe is to anticipate the unanticipated, you know, when we provide APIs at such a scale, there will be some bad actors, right?. So controlling the fraud, providing proper security capabilities is very important. So we ensure proper scalability, governance, compliance, and security when we provide our enterprise-grade APIs. And third one I would say is, it takes a lot of effort to build a developer community, customers and developers don't come to us when we just build the APIs, right? So we have to build the ecosystem, we have to run user communities, we have to run hackathons, we have to provide clear documentation. And we have to provide example code and proper developer tools. So evangelism is very critical to our success. And finally, I would say think big. So when we are providing APIs to our customers across the world, we are not just catering to single use case or a persona, we are essentially unlocking the potential for our customers to innovate and open up new business opportunities. So customers are not really buying functionality with APIs, they are buying experiences that they can unlock for their own customers, which they can really cycle back into their own design of products and services that foster innovation. So it's very important for an API provider to think big and think about all the possibilities for innovation.

Liran Haimovitch
  08:58
Your experiences, and for you specifically, those experiences are all about video. And so, as you mentioned, in the pandemic two years ago, video experience was the one everybody was aiming for, because face-to-face was decreasing very quickly. Now, unlike some of your customers that could choose to limit some of that video, using a platform as an API provider doesn't have that luxury. When anybody asks for an API for video, you have to provide it. And I'm guessing usage went through the roof at a time, and I have to wonder how did that make you feel?

Amitha Pulijala  09:32
It was definitely an experience. At Vonage we provide different APIs and video being one of them. But as pandemic rapidly turned the world into a physically and socially distant one, people began using our video services more. And during early pandemic days we saw traffic go up like, 10x 15x during some weeks and months, right? So this really made us anxious, right? We Know that we should scale up. But we didn't know how much we should scale up, and how long would this growth last. Right? So we had to make some tough decisions and we had to stick with it.

Liran Haimovitch  10:13
So what kind of decisions did you end up making and why?

Amitha Pulijala  10:17
So the first important thing for us was to make sure we had the business continuity, it was not just our customers shifting to remote, our own employees were working from home, there was no playbook. And we had to adjust to the style of working and collaborating even more working remotely. And the second one is really-- the biggest worry for us was ensuring that our service stays up and running for our customers. So really, how did we manage this? So we had to really make decisions around what are the things that are really, really important to us, and focus on that. And one of the things I said is to make sure we are serving our customers, and there's no interruption on service. And also making sure we had right incident management procedures in place, considering our remote work situations. This was I think, kind of tough, as I said, because there was no playbook that defined what to do in such situations. Typically, most commonly we relied on historical trends to establish how much more capacity that we would need, in terms of scale. But that was no longer relevant, right, because this case, there was no extrapolation of historic data. So we had to make-- we had to rely more on our intuition, we had to do some predictive analysis. And we had to be more open and agile. So that's what served us well. And I'm glad to say we didn't have major incidents during these peak months. And overall, our customers were happy.

Liran Haimovitch  11:56
So can you share a bit more about how did that look like? I mean, how did you scale those applications, that infrastructure to run 10x or 20x the workloads, and did anything else fail along the way?

Amitha Pulijala  12:09
So firstly, we had to make a decision on how much we would scale. We had an infrastructure that was capable of scaling vertically and horizontally. So our SRE engineers did a good job of estimating the capacity and scaling the capacity to the needs of our customers. And in addition to scaling capacity, we also worked on identifying and removing inefficiencies in our infrastructure, which served us well in the coming weeks and months. In addition to that, we had good monitoring tools that always monitored the applications and our capacity, and gave us alerts ahead of time if something was not going normally. So with all these different tools in place, we were able to keep our uptime and make sure our service was up and running for our customers.

Liran Haimovitch  13:06
Now speaking of that infrastructure, you have over 500 engineers at Vonage working to build and operate all of those APIs. I have to wonder what kind of architecture are you using to make all of that work together? What kind of infrastructure Do you have shared between those engineers?

Amitha Pulijala  13:25
So the core of what Vonage is built on, is the Vonage communications platform. It is a core platform for all our services. So Vonage communication platform is built on microservices architecture at almost every layer of its platform. So this gives us the ability to react to the changes in market much easier than our competitors. And as more and more channels that we add, for example, we have video, we have messaging, we have voice. But if we have to add more and more channels like WhatsApp, and Instagram, we diverge from the logic path only when needed to add that functionality. But the core services that are used across all these different channels is the same. This means that we can still leverage all the upstream systems and features while we are catering to the needs of that new channel. And that's the kind of the architecture, different layers in the architecture are basically the infrastructure layer. And we have different services layer where we provide services like off identity services around security, that could be used by the API's and any kind of applications that are built using these API's. So we have a good reuse of all the API's in all the downstream services that we provide across all the applications that we build.

Liran Haimovitch  14:53
You've mentioned earlier that all of those API products, even though they're built on the same platform, they came from different acquisitions along the years. And I have to wonder what differences exist between those groups within those products? And even more interesting, what kind of differences do you care for? What kind of differences are you trying to encourage, to bring on innovation or for other purposes?

Amitha Pulijala  15:18
As you rightly said, when we acquire companies, each company would build on different infrastructure. They have different tools that they would use. They have different monitoring tools and different ways in which they extend their services, and so on. So over the time, right? So, we adopted the API first approach, right? So we took some of the commonalities that we saw across all the products that came from different acquisitions. For example, every product that came through different acquisition needed authentication API, right? So it was very easy for us to take it and make it as a common shared service. And many examples like this, some of the tools, monitoring tools. It's easy for us to make those tools as a shared service. And then as I said, we took the API first approach, so that most of these services could be reused across different products that we are releasing, and those are the things that we ensured are common. And the things that we want to keep, really are the optimizations that you would have on a specific service that you're delivering to the customers, even though you use most of the services that are common. There are certain optimizations that are required for specific products to ensure you're catering the needs of that channel, that service, or that product you're delivering to the customers. So those are basically a value add, or what the commonalities and we want to ensure we keep those for the products that come from different APIs and so on.

Liran Haimovitch  16:59
That's very interesting. Now you've mentioned a couple of times, the concept of being API first. I'm wondering what kind of culture does that promote? Being and trying to build everything in an API first Manner?

Amitha Pulijala  17:12
That's a good question. So as a company, we definitely develop robust products for enterprises. But we always have developer first mindset. I'll give you an example. During the pandemic, we had a customer called Story cops. And this is an organization, a nonprofit organization in the United States that talks about heroes and their stories in the community, common people can be heroes in the community. And that's what they do, right? They talk about these stories. And usually they go interview people in person and take their stories, and they publish the audio, video recordings of their stories. But the pandemic was very different. And if this was 10 years ago, an organization like this, wouldn't have been able to build an application where you would interview people over a video, right? Because that means they would need skilled developers, they need a big developer team, and so on. But within a few weeks, this company has taken our API's, they've built an application to remotely interview people, and they were able to accomplish great stories about the communities. So looking at the services that our customers build, gives us this higher sense of purpose to what we do everyday. So I think that is the kind of culture that we have, and we promote in the company.

Liran Haimovitch  18:42
Amitha, thank you very much for being here. It's been a pleasure hosting you. Do you have any final words you want to say to our audience?

Amitha Pulijala  18:49
So at Vonage, our mission is to accelerate the world's ability to connect. We are building cool products to enhance customer engagements. And we are hiring. So if you're interested in building awesome customer experiences, please reach out to us.

Liran Haimovitch  19:05
If you're interested, check out Vonage. Thank you very much again, Amitha, for being here.

Amitha Pulijala  19:10
Thank you so much.

Liran Haimovitch  19:16
So that's a wrap on another episode of The Production-First Mindset. Please remember to like, subscribe, and share this podcast. Let us know what you think of the show. And reach out to me on LinkedIn or Twitter at @productionfirst. Thanks again for joining us.