Kevin Montalbo

Welcome to episode 65 of the Coding Over Cocktails podcast. I'm your host, Kevin Montalbo. Our guest for today is an entrepreneur, author and investor in software and the API industry. He founded the popular APIDays conferences in 2012, the main series of conferences on APIs and data portability. He is now the co-founder of ALIAS, a Data Protection API engine and was the co-founder of the API Identity portability platform OAuth.io, acquired in 2017.

He also has several books and reports under his name, which include Continuous API Management, The state of the API Industry Landscape 2022 report, and “Regulating Big tech: empowering the many by regulating the few”.

Joining us for a round of cocktails is Mehdi Medjaoui. Hi Mehdi, welcome to Coding Over Cocktails!

Mehdi Medjaoui

Hi, Kevin! I'm really glad to be here and thank you very much for having me.

Kevin Montalbo

All right, we're glad that you're with us! So, let's dive into the questions. You're one of the co-founders of the APIDays conferences. Can you tell us a bit about your role as chairman and more curiously, how you came to find or found this conference?

Mehdi Medjaoui

So, we were in 2012. Let's say the new protocols enabling to have APIs that were to be really, really easily implementable compared to previous protocols were coming up, like REST, JSON, especially. So we wanted to evangelise larger companies about this new digital transformation that was completely API-led or API-enabled. And when we tried to pitch, “Do you know about APIs? With recent technology, there are new ways to interface software with each other and to connect, to become marketplaces, platforms,” wow. Nobody understood anything. They were relying on old protocols that were not really able to be opened, like the SOA (software oriented architecture) service architecture. But that was not really made to be open, but we've seen some companies like Twitter, Flickr, Google, Facebook, having open APIs and being really successful. 

So, we said, “Okay, we need a conference. We need a conference to attract developers, architects, business managers, to understand what we call the API mindset.” So, we started in 2012 and we made our first conference. It was just, let's say, one Google Group. Do you remember Google Groups?

Kevin Montalbo

Yeah. Google Groups. Yeah.

Mehdi Medjaoui

Yeah, we had at the time. And it was funny, it was trendy. And so it was mostly the API Craft Google Group. I just posted something and said, “Look, let's meet in Paris for Christmas. Let's meet all together. We’ve never met each other, so let's meet together.” And we started mostly as an international meetup and after the conference, I said, “Okay, do you want to organise your own in your own country? I will help. And I will be highly involved.” And Spain said yes, San Francisco said yes, Berlin, Melbourne… 

And so finally, we now have 10 conferences a year in 10 different countries. And so far, we have attracted like 300,000 people online or in person at APIDays conferences, pushing the API mindset for all on the technical side, but also on the business side, because we need business people who have the budget to fund, let's say, the IT side of APIs.

Kevin Montalbo

Right. And that was interesting, what you said there that you started out as an international community already. And I would imagine that the pandemic really affected how you ran these APIDays conferences. So did you continue to run the conferences during the pandemic? Were you able to, you know, continue them on an online, remote basis?

Mehdi Medjaoui

So you know, we have Twitter, we have email, we have YouTube. So, before the pandemic, the goal was, as we said — and I start every APIDays conferences like that — the goal is to connect the humans behind APIs, the humans behind interfaces. So we wanted to have it in person. We didn't want to stream. We didn't want to be virtual all our life. We wanted people to be there, but with the pandemic, we had the question, “Do we stop? Or do we go at a higher level and we continue to fulfill our mission, which is to connect humans behind APIs?” The only way was to do it virtually. And so yes, we said, “Okay, we follow our mission and DNA.” And finally, we went online for two years. The community followed. 

It was great because now we could have speakers we couldn't have before because of travel, because of busy timing. Attendees from worldwide. The event could be free because online costs less. So, we can completely make it free to make it more accessible for under served people worldwide. And now we are back in person, plus virtual. It’s like hybrid this year. But yeah, I think all conferences will need to be virtual at some point or hybrid. The full in-person only will be difficult to support, I think, for events. And we've already seen conferences stopped. We've seen so many conferences that just stopped. We are glad to survive. We're glad that because the community's there and the sponsors are there and yes, we really want to thank all the community for having been supportive during these two years.

Kevin Montalbo

Yeah. And I bet they missed, you know, all that traveling. You know, that airport food and the hotel food. 

Mehdi Medjaoui

Yeah.

Kevin Montalbo

Right, so in 2019, you also co-founded ALIAS, which aims to help companies ensure that they are GDPR compliant. Now I know most of our listeners would already be familiar with GDPR, but for the uninitiated, can you start with a brief refresher or explanation of what GDPR is and how it affects companies collecting data on individuals?

Mehdi Medjaoui

Yeah. Let's say GDPR, it’s a law. It's a regulation applying to every person, every company who interacts with European cities and data or people who are on the territory of Europe. So, it can be an American, but based in Europe. Right? If I try to make it simple, it obliges you to know at any time, what is the data you collect? How do you collect it? Is it compliant? Like, does it follow a specific legal base? And where is the data, how it will be processed by which company, which sub processors, as they call it. And so you have a really, really good view about what you do with the data. Just imagine like the ingredient lists when you buy, for example, cornflakes, or when you buy a specific ice cream or whatever, you can go back and look at what's inside.

So the goal is the same with GDPR, but with personal data. So every company needs to be compliant if they want to interact with European cities and data. But the thing is, the US now has many laws which are following GDPR. China has a law following GDPR. Singapore, India, Australia, and 60 countries have GDPR-like regulations. So, it's not only Europe, it's worldwide. And by the end of the year, two-thirds of the world’s population will be under GDPR regulation. So, almost any business who wants to interact with personal data will have to follow these regulations and what we do is try to make it really simple. We are a data protection engine. Just imagine it's like an AI lawyer that tells you what to do. And when to do it, we just put sensors. You put sensors in your code, databases, apps, SA, whatever, and you send it to our engine.

You send the events. What's happening? A user clicked here, a user of a newsletter, a user bought the product, the engine just analyses it. “Oh, you just bought a product. Now you can keep the data.” According to the law, you have to keep the data for at least five years, not three years anymore. Or so we give you these insights, but what you have to do according to the 60 regulations. So, our baseline is like, interact with the ALIAS engine and continue to not worry about GDPR anymore. So that's what we do.

Kevin Montalbo

And I took a glance at your website. And in order to help companies become GDPR-compliant, you've done a couple of APIs on your side, which are first, the PII Storage Duration API. Please, correct me if I'm wrong. And the ALIAS GDPR Events API. Can you run us through what these APIs do for companies?

Mehdi Medjaoui

So, you know, it's like food. When you are at a restaurant and you have food, you have a specific date. You can't continue to sell it over a specific date. After it comes, it becomes improper for consumption, right? The regulation puts the same for personal data. So, you can't keep personal data forever. You have to declare how long you keep it, or by regulation, you have to keep it for a certain time and not any longer. 

And so, we help you. We help you to know what type of data, where it starts and how you collect it. So a lot of value, but we help you say, “Oh, this data in this context is two years. But in this other country, the same context is five years. And this country in the same context is three years.” So, we give you like the whole jurisprudence, all the legal cases to tell you, without knowing the law, what you have to do with the data. So that's the Storage Duration API, the PII Storage Duration API. 

And the Events API, it's an API that enables you to listen to the events that happen in your system, right? And it enables you to maximise the use of data according to the law. So, we look at all those available in the country, and we tell you when the user, for example, becomes a customer. From prospect to customer, you have the right to keep the data for longer, but you also have the obligation to keep some data for five years or 10 years. 

Just an example, invoice in France. You have to keep the invoice for 10 years and everybody forgets that. So yeah, we give you these insights in a readable way, and we tell you, “Yeah, the user data, you have the right to keep it for three years for marketing purposes. But the invoice data is 10 years for legal reasons.” And so we give you all these insights as a lawyer would do, but the lawyers are like $400 per hour, just to give you one insight. And we give you millions of insights for millions of users alike for the same price of a lawyer.

Kevin Montalbo

Yeah. So do you have individual lawyers working for you who are, you know, looking at all these international laws and all these regulations? I'm pretty sure they're different for each country, right?

Mehdi Medjaoui

Yeah. They're different for each country. Even in Europe, where it's the same regulation, it's not the same for all the types of data in Poland, in France, in Germany, in the UK and whatever, it's different. So, yeah. We have a team of PhDs in law and lawyers who do the job all day analysing all of this. Of course, there are some legal databases that we can look at. There are laws. So, we do the work for all. We do the work once for all, and we deliver it by an API instead of having incomplete infos in many, many lawyer firms where you pay for their training. You say, “Okay, look for this.” And you pay for their time of learning. No, no, don't. You don't have to pay for learning. You pay for the advice. And this is why we think an engine giving you advice in real time on the fly with accumulated knowledge is the solution to really lower the barrier of being compliant and lower the barrier of knowing the law at scale.

Kevin Montalbo

Yeah. And the work doesn't stop there because on your website, it says that the data processor API is coming soon. Can you give us a sneak peek of what this data processor API will do in the future?

Mehdi Medjaoui

Yeah. Actually, when you collect data, you can process it yourself. So, you trick it yourself. You do a specific AI algorithm, you start it in your own CRM, but if you use a third party CRM like Salesforce or HubSpot, or another one, it's called subprocessors. So you have to be sure these subprocessors respect and are also compliant. Right? So, for example, some countries do not allow their data to go out of the country. You know, they don't allow, for example, children's data to go out of the country. If you put this data in a SaaS platform or in an IaaS or PaaS platform, you are not actually compliant because some of these SaaS platforms replicate data outside the country. So, this data processor API helps you to know if you put data there like, what does that imply? Does the data go out of the country or not? And so, are you compliant if you use that service or not?

Kevin Montalbo

Oh, okay. So, I'm just curious on whether actual SaaS companies and iPaaS, or what have you, these “as-a-service” companies, do they approach you as well? Or is it more of a business-to-company or business-to-client engagement? Like, are you more engaged with customers or businesses themselves, or do you have clients from the “as-a-service” side of the equation?

Mehdi Medjaou

Yeah. Most of the companies now are “as-a-service.” At some point, they all were software-as-a-service websites or applications or whatever, but yeah, no, our, our goal how we operate, we give APIs for developers because internally developers have to do the compliance. So that type protection officers tell what to do, but developers do it, you know, that's, that's that their job, but sometime they're lost. So they find our APIs and they say, okay, they talk to, with their data pro protection officer and say, look, it seems these guys have done APIs that does the job. Right. So let's let's, let's work together and, and let's and let's implement a APIs inside our it system. So we have sensors and we can really handle this in real time. So that's, that's mostly high work it's we are a B2 D I business to developers. Right. But after the developers are onboarded, they tell their managers about like, yeah, this is their way to do. Right. You know, so that's how it works.

Kevin Montalbo

Right. Anyway, you've co-authored the book, “Continuous API Management” with Eric Wilde, Ronnie Mitra and Mike Amundsen, the latter two have been guests of the show actually, friends of the show. And I assume that this book and your experience with the APIs has fueled the growth of your company ALIAS. But before we dive into the specific topics of said book, can you tell us some of the key updates that you've made from the first edition that compelled you to come out with this brand new second edition?

Mehdi Medjaoui

Yeah, sometimes you have two versions of APIs when something new is out. So, why not versioning books and APIs, right? So, that's the joke we had internally with the team, but yeah. In this new version, we keep the same core principle of the first version, of course, but the second version was really about listening to feedback from readers of the first edition. It adds more “how to,” and more “how to apply” and really concrete methodologies or more practical cases, more practical stuff. So, that's the first part. 

There's also a second part, another new chapter, which is on API styles. A lot of people were telling us, “Yeah, but you didn't help us decide between REST or GraphQL or hypermedia APIs, or event-driven architecture,” or stuff like that. So, we added a new chapter dedicated to that for people to understand that continuously managing APIs is the same methodology and philosophy, whatever the protocol, the format, the vocabularies you use and everything, or the API standards. But it helps to remind some specifications about managing GraphQL APIs versus managing REST APIs or whatever. So, yeah, mostly more practical stuff, more updated numbers or updated principles, more methodology and practices, but also more a new chapter on API styles.

Kevin Montalbo

Right. You talked about API styles. I'm going to go back and circle back to that question later on, because I'm interested about this third chapter which delves into why we consider APIs as a product. So, we've been talking, we've been hearing about API-as-a-product a lot, not only in the show, but a lot in blogs on LinkedIn and in other podcasts as well. So, why do you think it's important for companies and its teams to realise that this perspective of having an API-as-a-product perspective within their organisation would be essential to create or form an API strategy?

Mehdi Medjaoui

The real API as a product shift came really when we stopped thinking about APIs for integration, but APIs for consumption. You consume your product, but you integrate a technology or service or whatever. And so integration is just about making things work, technically product and consumption mean that I consume because it brings me enough value, right? So this is what I love. I think it's Amancio Bouza who said APIs as VPIs, like value proposition interfaces. Even if it's internal APIs or external APIs, the API product mindset is to say, “Look, I wrote a piece of software, but I designed it in a way that when someone will see it, it'll bring him or bring her more value than the software he could have built himself. So it's not about integration to just make things work and we don't care about what's behind the scenes. No, no, no. It's about how I'm sure that something I've been produced with gives me more value than if I did it myself. 

And this is why we've seen the success of companies like Stripe and Twilio, who all thought APIs as a product to be consumed by others in let's say, a digital supply chain, right? And the API product mindset changed a lot of things in inside in the business teams because the business teams said, “Look, actually we can be a marketplace. We can be a platform. We can have outstanding programmable business models to make business by opening software to others.” And mostly the API economy is an as-a-service economy, right? Consume what others are doing to focus on what you do the best, but you will open what you do the best as APIs to be consumed by others so they can focus on their own core businesses.

And that took many years to happen in the classic industry, you know? The brick and mortar industry with a supply chain. It took us two decades to do it in the software industry. And now we see so many APIs as product companies and they're outstanding and they're achieving a lot of value at scale because of the capability to be self-service, to be easily consumed, to be developer-friendly. And so people come to discover the documentation, discover the value, integrate if it's well documented, they don't even talk to a human about support. And it goes like that. You become a platform because people consume and come and consume in self-service. And so I guess you accumulate value at scale.

Kevin Montalbo

Right. And shout out to Amancio Bouza, who's been in the show twice already! And now, I want to circle back to what you said earlier about the API style section, because this is something that is a favourite topic amongst our readers on the Toro Cloud Blog and on our knowledge base, and actually we're going to have a JMS versus Kafka smack down soon. So, not a different technology. But we're going to cover these in the future. But anyway, you have an API style section, which is a new addition and you explored the five most common API styles you've observed from companies all over the world. So, can you give us a quick rundown of what these are and why you think they've emerged as the most popular API styles?

Mehdi Medjaoui

Yeah, it’s a chapter written by Eric Wilde. So, you can definitely go deeper on that one, but the thing is, let's say you have really different styles. You have the one with the hypermedia APIs that a lot of people had a lot of hope for in the early 2010s because it was pushed by Roy Fielding’s philosophy and REST philosophy and architectural style. It’s the fact that you can interact with other APIs by referring them to every resource with links. And we kind of have a web of APIs, so it works well internally. But let's say, it has been hard to implement. But this is a style that really is beautiful. 

Then you have the CRUD style, one of the styles people use the most. You know, GET, POST, PUT, DELETE and respecting some of REST verbs, but mostly interacting in a CRUD style. You have the query style, like GraphQL mostly, SOAP at the time. GraphQL really enables interaction with different systems with the query language that enables them to interact faster. This style is great when you control the backend and the frontend. So when you control the backend and the frontend, it's kind of a highway. You know what you’re doing. You know it will not be open to everyone. It's a really controlled environment. And so, you don't have to anticipate future use-cases. Mostly, it's really for some use-case that you understand better. 

There is also the event-driven architecture aspect, you know, the streaming kind of APIs that are there. And now that's great, because with more and more services interacting with each other, if you have to pull every API all the time, “Hey, did you have something new for me?” “No.” “Okay. Did you have something new from me?” It consumes a lot of resources and makes the network quite busy. So now, you can subscribe to some APIs and say, “Look, when something is new, just send me a notification,” like streaming, broadcasting news. And so if you are signed up for the news, you receive it. And so you can manage it economically. And we see a lot of traction in these event-driven APIs, like some people in the software industry will say, “Yeah, we've done that 30 years ago,” but it was with different styles, different technologies that were not enabling it to really do it at scale. So yeah, really different styles. 

Then, you have the RPC style, which is really about calling a remote function and having the ability to request a specific function of an API and get the answer. But again, with this RPC style, the thing is you can have some issues about naming if you don't respect some conventions. And everybody calls the function, the method the way they want, and if you don't respect conventions like some REST conventions, it can be difficult. But for example, Slack has a great RPC-style API, right? It's mostly meant for bots. It's really about interactions, specific functionalities over the network. And it's not about resources. It's about bots who do a specific task, and RPC was really successful for them. But I really invite you to go more under the chapter and dive into the styles a little more.

Kevin Montalbo

All right! So fantastic thoughts there, and we appreciate the energy and passion that you put through for the growth of APIs and the industry in general. Before we end the episode, can you tell us how listeners can reach out to you, follow you, learn more about what you do, and of course, read the book “Continuous API Management?”

Mehdi Medjaoui

So, you can reach me on LinkedIn with my first name and last name. You will find me on Twitter, I'm “M-E-D-J-A-W-I-I,” so that's my handle on Twitter. You can sign up for the APIDays Conferences on the APIDays.global website. And you will be able to register for free for online events or hybrid events, or if it's in your region, go in person. And we can meet. And we try to have book signings on our in-person events. So, if you also want a book, if you want to buy it online,of course you can if you are in a hurry. But if you want to meet me, Mike, Eric, and Ronnie for a book signing, you can come to APIDays’ in-person events, and we would love to to sign a book and offer you a complimentary version.

So yeah, and the last thing I wanted to say is the 10 Years of APIDays Conferences. So this year, it's quite special. And at the end of the year, we will try to gather all the top API influencers, most of your past podcast speakers in an event in Paris. We expect like 4,000 people in person. We’ve booked the City of Science and Industry in France. It's like a huge thing, like a museum of science to really talk about the next 10 years of software. The past 10 years was the rise of APIs, but what will be in the next 10 years? So ,we will talk about that for the 10 Years of APIDays.

Kevin Montalbo

Looking forward to that and hoping to see you soon in person as well! Mehdi, thank you very much for joining the podcast.

Mehdi Medjaoui

Thank you for having me!