Eyal Solomon:
Both transparency and understanding that the product will evolve as people will use it and share their policies on top of it is something that led to us to the decision that this project has to be open source.

Eric Anderson:
This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson.
I'm excited to have Eyal Solomon on the show today. Eyal is a co-founder of the Lunar company and specifically Lunar the project, which we'll be talking about today. Welcome, Eyal.

Eyal Solomon:
Hi. Thanks for having me, Eric. Happy to be here.

Eric Anderson:
So you had some big news at the end of '23, announced a seed round and you open-sourced Lunar. Maybe tell us what Lunar is.

Eyal Solomon:
Sure. So Lunar is a project that actually been baked in the mind of me and my co-founder, Roy, for quite some time. It's a platform for engineering teams to monitor, manage, and optimize third-party API consumption. Basically what the system does is giving you that full view and visibility into all of the APIs you're consuming, those external APIs that you're using, then giving you the understanding of the bottlenecks that are associated with that consumption, problems that are associated, and then actually help you in real-time remediate those problems like implementing the mechanisms and the policies that help you actually enforce policies and optimize that consumption to lower down costs, to improve resilience, to improve security. This is the project. We've been working on it for quite some time and decided to release it, as you said, at the end of the year and announced our seed round. And it's been a crazy ride since.

Eric Anderson:
You mentioned this is something that's been in your head for a long time. Have you had problems with this pain in the past?

Eyal Solomon:
Yeah. So we did have problems with it in the past. I think that it's something that at one point of time every developer encounters when integrating with an API. I mean, it's easy as it gets to integrate with an API, but then at one point of time things begin to change, to break. You're being reliant on an external resource and then you're trying to manipulate with that resource. So you're thinking about maybe caching some of those API calls, having a retry mechanism in place, having throttling from your side to make sure that the requests are being sent by the order and magnitude that you wish.
So everyone encounters something that has to do with the maintenance of APIs, but then I'll give you an example. Roy, my co-founder and CTO, did the caching mechanisms for one of the APIs that used to be used by his previous company back at Check Point. And then as we talked with companies about that pain that associated with API integrations, we actually understood that there's an underline to it, that maybe everyone thinks that they got a unique type of problem because they have their own type of business logic to consume that API. So everyone think it's a distributed problem that has to do with their personal preparations and the way that they're using that API.
But we understood along a lot of conversations that basically it all boils down to the same type of implementations. So it wasn't like an iterative process. As I said, over a course of a few months of talking with many cool developers, architects, people from engineering, understanding that the way that we've encountered the problem is the same way that other companies encounter the same problems and then trying to understand what will be the most generic type of solution that actually fits every tech stack out there and can give you instant and real time type of remediations without changing your existing infrastructure and your existing code.

Eric Anderson:
I'm curious, now that you're measuring the performance of these third-party APIs, are there some bad actors out there? I mean, are there APIs that are really awesome and others that continually pose problems for people?

Eyal Solomon:
You're putting me in a tough spot.

Eric Anderson:
I know, I know.

Eyal Solomon:
I won't bash anyone, but I'll say that there's a reason that, I mean, some companies are called API-first companies. Those are companies that their core product is their API. They're keeping a lot of focus when it comes to documentation and announcing of breaking changes and keeping it available and steady and whatnot. But the API economy is bigger than that.
So we can talk about as assertoric APIs, maybe APIs that have a specific purpose or maybe not that being well maintained and still those APIs are being used heavily and being reliant heavily in some companies. Think about companies that, I'll give an example, from the freight industry. They're consuming tons of shipping APIs. Not all of them are API-first companies. So those APIs tends to break and change a lot and have a lot of problems associated with them, especially when you go in scale. And we've seen companies telling us, "Listen, we've thinking about implementing our own type of mechanisms. Maybe we've tried to implement and maybe we actually implemented our own type of mechanisms for those APIs, but it keeps on breaking."
So I'll say that the non-API-first companies are problematic APIs that are associated mostly with a high error rate, breaking changes, being unannounced, undocumented. But also some of the API-first companies, there's problems that are associated with cost. So it can be fine state-of-the-art type of API, but if it's too expensive for you to consume, you will still need to think about a logic that will make you consume better and in a more optimized manner.
So all across the board, I won't mention a specific API out there, but just to give you the clearance, I mean there's the API-first companies and there's the long tail of so many other APIs. And we've seen it on a daily basis, APIs that cause a lot of headache and maintenance for the developers that are actually implementing those APIs.

Eric Anderson:
And what's the typical alternative? I imagine you tried to solve this before building a product and maybe you find your prospects are doing things in order to ease the pain. Is there anything you can do outside of Lunar, or how do people try and approach this before you meet them?

Eyal Solomon:
So there are some alternatives mainly around type of libraries, language specific that has to do with resilience. There's one library called Polly that it's been used quite some time, but it's for a specific language. It's not generic type of thing. It's not in the architecture of your backend that solved that problem.
What we mostly seen is that companies actually has somewhat of an evolution when it comes to building their own type of solution. At the beginning, it's level number one. This is the application developers, they're developing the application, they're integrating with API. Everything that breaks and associated with that problematic API, that will solve ad hoc on the spot. So at that point in time, we're seeing companies actually implemented. I mean, the developers themselves implementing just like the basic type of monitoring and traffic handling when it comes to try and catch within the code, stuff like that.
As companies mature, we've seen that there actually begins to form a new type of layer, what we call the stateless middleware. Those are companies, we've seen a lot of them, that actually dedicating integration teams telling them, "Listen, integration team, you're in charge of all of our external integrations." Now we've seen more sophistication around the API's that you're consuming. Now we're seeing that some of those companies can actually have the ability to edit API requests and responses, add headers to those APIs. They can tag API calls, they can have collection of metrics and traces. So this is layer number two. A lot of companies are staying there or maybe at that level.
But I think that the most savvy companies that we're seeing are somewhat building their own type of, or trying to build their own type of Lunars, which means that they're building a dedicated type of management service. They're building a dedicated egress service to manage all of your egress traffic, your outgoing traffic to those third-party APIs. At the pinnacle of that evolution, those are sometimes the platform team or the infantry that actually build internal types of tooling, in some ways type of Lunar, to manage their external integrations for the whole company as a whole.
So to wrap things up, I'll say that there's minor type of approaches to solving these problems, some open source projects around libraries and resilience, but the majority of the use cases, we've seen companies building it on their own all the way to actually forming teams of R&D to solve that ever-growing problem.

Eric Anderson:
The AI revolution I feel like kind of plays in your favor a bit. So folks are now making API calls to services that represent the bulk of their computing costs. If you're a heavy OpenAI user, OpenAI may cost more than the rest of your infrastructure combined and you rely on this API. Is there a tailwind there? Do you see people using Lunar for generative AI calls a lot and is there value there?

Eyal Solomon:
So definitely. It's booming with the gen AI revolution. I mean, let's think about it as follows and real-life examples. You got ChatGPT that you want to use. You're integrating with that API. Does it make sense... I mean, I'm telling you real use cases and real-life examples. Does it make sense to make API calls to ChatGPT for the most expensive one or maybe some API calls needs to be degraded because you're not serving with the same type of quality service to all of your customers, maybe just the VIPs? So that internal logic of deciding how to route the API call to a specific gen AI API, this is a logic that we've seen companies needing to implement. That might be based on cost or on accuracy of the model they're going to use. Sometimes it has to do with availability. This is one aspect of internal routing or decision-making to which API is to use. This is a big thing that we've seen across the gen AI evolution.
But still, or maybe on top of it, we've seen also companies that are actually being bounded or strictly bounded by the rate limits they're being provided by OpenAI. I mean, everyone wants to use OpenAI. OpenAI has a lot of customers to serve, and they're bounding them. So now we're seeing lot companies trying to orchestrate between different API accounts to consume much more and increase their quota. And all of those playmaking and middleware, it's the same type of pattern that we've seen companies approaching us with these problems. Either they want to choose the right provider at the right time or they want to optimize and increase their volume of consumption based on their internal logic. And I'll say maybe the third thing, which I said at the beginning, is prioritize of API calls based on tenant, based on service.
So those are things that we've seen in the past few months taking place a lot when it comes to using gen AI APIs. And everyone talking about gen AI, but once you're going to run into production, it's like a different ballgame and we're just seeing the tip of the iceberg when it comes to problems associated with consumption of those APIs. So definitely that's one of the main focuses of our company in the past few months.

Eric Anderson:
Great. Speaking of change in the last few months, I want to go back to this decision to open source. I think some of the listeners on this show are interested in the kind of dynamics of operating an open source business. Was that always the plan to open source? What kind of led to the decision-making around the timing and how you go about an open source launch?

Eyal Solomon:
Yeah. So I think that the decision of going open source wasn't like that maybe natural go-to as you would imagine with a company that has an open source offering to it, but it's something that grew within us along the way. I mean, obviously I can talk about us as developers wanting to give something back and also make the world a better place. We can talk about all of that. But at the core essence of understanding how we are solving the problem with Lunar, we understood that this is a distributed problem, and I'll put an emphasis. It means that the way that you will optimize your APIs might be different than the other type of company optimizing on the same API, let's say on Amadeus for traveling or for Twilio for messaging. But it all goes down to the same type of configuration. So understood that problem of really managing your consumption and optimizing it needs to be something that is a common knowledge being shared by other developers.
So Lunar had to be open source in some manner. It had to be that place where people can build logic on top of the platform and it will be shareable. So if I'm a developer that is building a caching mechanism for one API provider, it might make sense for the other type of company consuming that same API to build that same caching logic or retry logic or build the same type of, we call them flows, share the same type of flows. So that shared knowledge that being formed within Lunar is something that drove us to understand that it's open source. This is one. And second of all because Lunar is inline and we sit within your traffic intercepting the traffic and then wiring via the Lunar proxy, we had to show that we're fully visible, I mean fully transparent. So that's part of building transparency with the community and our type of persona that we're aiming for.
So both transparency and understanding that the product will evolve as people will use it and share their policies on top of it is something that led to us to the decision that this project has to be open source. We're not an open source company. We are a company with an open source offering. That may be something worth mentioning. But we believe that in order to solve your problems, you need to start, it should be out there for free. And then as you scale, you work your way out of there. But this is one of the reasons they made us go about releasing it as an open source type of project.

Eric Anderson:
And when you say we're not an open source company, we're a company with an open source offering. I guess that just speaks to the centrality of the open source offering in your case.

Eyal Solomon:
Yeah, I will say I haven't put a lot of emphasis to that statement, but yeah, it basically says that, I mean, as a company, obviously they want to show traction and show momentum. It's not all about GitHub stars and the way they're interacting with the open source. It's about how they're contributing to the open source when it comes to the policies and offering. So it means that Lunar has layers to it. There's also managed layers. But the core essence, the core value of Lunar will be open source. Take it, tinker with the system, build on top of it. Everyone needs to use the type of product so you can do it. This is why we want to give it out into community. It serves us in the same time of actually understanding what people want us to do and how they want us to solve their problems and building the right type of plugins so they can change them and solve complex problems.
So maybe that's the angle that I'm saying about. It's not just about the metrics of an open source company. It's a company that has an open source offering to it that grows on top of it. It's like open core type of thing.

Eric Anderson:
The purpose of your open source isn't strictly community development, but also peace of mind to your customers. And so having things in open source independent of the amount of traction they get in open source is a value to your customers, the transparency aspect you mentioned earlier.

Eyal Solomon:
Exactly. Yeah.

Eric Anderson:
Eyal, maybe you could talk a little bit about what the future holds for Lunar. I mean, it feels like there's a lot happening. You have your commercial launch. You're still in early access. The open source is fairly new. Where do you see this going long term and any exciting milestones that you can speak to?

Eyal Solomon:
Yeah, so we got a lot on our plate, a lot that we're planning. I'll say that it's like building in layers or maybe in stages. So stage one was saying, "Okay, this is the product, it's open source, play with, contribute to it." But as we're learning about how people actually building what we called, as I said, using plugins and building flows on top of it, then the system actually becomes more savvy and smart. So as we'll collect enough data and give enough suggestions in the next step of how to optimize on specific APIs, we'll have enough data to learn from and then build the next level of offering, which is an autonomous type of optimization. It means that all you have to do is just install that proxy, that Docker installation or via Kubernetes and you're good to go. It will understand the problem and the type of plugin that dynamically will change according to your problem. So I think that this is the natural progression that we're seeing within the product.
What we're trying to do in steps and what we're trying to do during 2024 is saying, "Okay, at the beginning there's those plugins or processors and we can use the same name, but then at the next level there's pre-built chains or pre-built flows that we've built, complex type of scenarios." Think about throttling together with caching and alerting. Think about retries with an account orchestration between a few accounts that you need to orchestrate as a round-robin type of thing. So there's a lot of complexities that you can build and those will be pre-made flows. But in the next version of the product, it will be out there as type of a tool that you can actually drag and drop your own type of things and build your own type of flows. So now we're giving back to the community the ability to actually build rather easily those type of flows themselves.
So as I said in the next phase, and this is part of the holy grail, is saying that this should be autonomous. I mean, if someone wants the autonomous version of it, so you just can install a proxy and everything will be done automatically for you. So this is the progress of the product. We're going to be releasing in actually pretty fast as we go along. We just released recently our control playing UI. So you can do everything from a UI, not just a backend type of a solution, which is kind of cool. We're seeing a lot of good traction and feedback from that.
And basically this is what we're planning on during 2024, use the system, build flows on top of it. We'll see suggestions taking place. You can do everything from a UI type of manner. And a lot of cool flows coming along. We're building them. We're hearing the community telling us which type of APIs they want us to help with, and then we're providing those flows, sharing thoughts. So that's the main play of the next few months I'll say. Besides that, building a community, forming it, getting love, giving love back to the community, this is another big thing that we're focusing on.

Eric Anderson:
Super. As those early community developments start, keeping in mind that this podcast will probably, by the time the listeners hear this, it will have been recorded a couple of months ago, where can people who are excited about Lunar come hang out or learn about the project?

Eyal Solomon:
So Discord, obviously. We have a Discord channel. Show us some love, join the community. We'll be happy to review both your feedback, thoughts, problems that you run into with type of problems. We also got the open source on GitHub, so you can also approach us there.

Eric Anderson:
Okay. I want to tackle one more topic before we wrap up here, Eyal. Most of our listeners, according to my stats, are in the United States. We have a number of security and developer tool companies out of Israel. And I think we're all amazed at the kind of rate of innovation that comes out of Israel. Maybe you could say a few words about how that works. How do you and your co-founders, how did you meet and how do you see these companies forming? And you already spoke a little bit about the inspiration behind the idea, but is that typical for other folks that you talk to?

Eyal Solomon:
Okay, so I won't pretend that I'll know the way that the Israeli tech community is being formed. I will say our personal... Maybe there's derivatives to it, but the personal link of me and my co-founder Roy is that, first of all, I know this guy from the first grade. So me and Roy go way back. We sat at the same table in first grade, so we know each other for 30 years. There's a lot of trust between me and this guy. All of the curse words we've already used on each other. So there's nothing that can surprise me about Roy.
And then we spent some times in the, as you mentioned, the cybersecurity landscape getting some tools and skills. And the ideation for Lunar is something that we actually literally sat in the basement of his mother's house, talk with so many companies, prototyping with code. So it's something I will say it's not glamorous, it was painstaking, but it's think about how we can synthesize between, I don't know, cybersecurity knowledge and type of things, things that we've seen. I think maybe the main thing is talking with many companies, many people out there hearing their thoughts and trying to wrap things up and see how you can prototype on top of it. So I think that this process is not has to do necessarily with Israelis, but any entrepreneur out there. This is the way that it worked for us.

Eric Anderson:
Eyal, how do you get those first conversations with lots of companies that seem so important? I have aspiring entrepreneurs every day that come to me with an idea and they want to bounce the idea off of me. And I often tell them, "Well, have you talked to any prospects about this? Any potential customers?" And they often haven't. I think some might find that a barrier, how do I meet these people? How do you go about talking to lots of companies about an idea like this?

Eyal Solomon:
Basically everywhere that I can get a phone call or an intro or someone respond to my LinkedIn message, I will be there. So it was kind of like an operation of legend to the right type of personas they want to speak with. And then approaching them on a daily basis on LinkedIn and using every connection that I have.
VCs are really helpful at that point in time. There's really cool VCs that help you with that ideation, validation, experimentation with customers, and making those hooks. In intros, one of the things that someone gave me is a tip, and I will definitely share that tip later on. Finish having conversation with, "Cool. Do you have anyone else that I can speak with and consult with it on that matter?" And sometimes it works, sometimes it doesn't. But it actually means that every contact might be a door to additional contacts.
So it's a long process, but we just never put a stop to it until today. I'm taking every intro that I can get, talking with people. You're recording, of course, with their consensus those calls on Gong. And then you're reviewing those calls, understanding what the pattern that you've seen, you're trying to build a framework of how you can actually summarize those calls.
So maybe my tip will be get the calls wherever you can get them, whatever, from whomever, friends, VCs, LinkedIn, forums. We've been on Reddit, we've been in all of the forums lurking people and telling them, "Listen, I've seen that you've talked about this problem. Do you mind sharing your thoughts with me?" You will be surprised how many people are actually kind and want to share their thoughts and knowledge and the way that they're seeing the problem space. So I think that this is what help us actually progress with product and the ideation and the prototyping in the first phases.

Eric Anderson:
Awesome. That's actually really insightful. What you described I think is typical for any, I guess kind of B2B company, really any company. As you go open source now, does that motion change? Do you find the way you engage with people, seek for feedback is that different in open source land versus commercial?

Eyal Solomon:
I don't think so actually. I mean, same type of move. You're finding those people that I want to talk with. And yeah, it doesn't matter whether it's open source or not. I mean, if you've got an interesting problem and you're approaching people in a kind manner and you want to actually hear their thoughts, it doesn't matter whether it's open source or not. So hope that answered your question, but I haven't seen a big difference.

Eric Anderson:
Okay. Final question that I can come up with. What's the kind of ideal user of Lunar look like? I can imagine some folks, increasingly indie hackers build all application. The whole application is based on APIs. They're dependent on their infrastructure via API. They're dependent on we talked about gen AI already and lots of third-party dependencies as it increases efficiency. On the other hand, maybe larger applications might have a little more in-house. A big company like Uber or Lyft might choose a lot to do internally. What does the ideal user of Lunar look like? Is that spectrum a helpful one?

Eyal Solomon:
So I will say it's a spectrum because if we'll talk about API gateways, there's a lot of known data out there. It's been around for a lot of years. But if it comes to orchestrating and managing the consumption of external APIs, this is something rather new in a way, or maybe it's being distributed by different personas. We're focusing on the developers, the application developers themselves, backup developers. And as we said, in some cases that might be also integration engineers and also platform engineers, depends if they're building their own type of thing.
I will say that within the process, we're also really interested in what the architect has to say because the architect is the one that sometimes seem like the problems as a whole and try to think about the right architecture type of component that will solve a lot of those needs, which is basically Lunar, that centralized component that will help you manage and optimize your egress traffic.
So those are the type of personas that we're focusing and can actually onboard the system and use it. And actually this is the persona, but it also interests the data that comes with Lunar and actually the value proposition. The results of it is also interesting to executives. Think about the VP R&D that is interested that bird-eye view and the cost that associated with API consumption or the security posture of it. So there's additional roles within the company, but we're focusing on the people that actually witnessing the pain, feeling it firsthand, trying to solve it on their own, and now we're bringing a cool and very innovative solution to the landscape.
Yeah, in terms of the type of companies, you said it, it's cross-vertical. I mean, every company from every vertical has their own type of APIs. It's not something that we might be focusing in terms of marketing or in terms of validation of a specific problem, but we're out there. The platform is generic. It can be used on any API that you're consuming. So there's a lot of interest that we're seeing at the moment from the advertising tech industry, the freighting tech, travel tech industry. E-commerce is also a big thing, a lot of problems has to do there. We've talked about implementing [inaudible 00:26:40]. It's also a big thing. Company at the growth stage also.

Eric Anderson:
Eyal, anything we didn't cover you wanted to cover?

Eyal Solomon:
No, I think we got it all covered, Eric. I really enjoyed the conversation. It was a pleasure. And thank you so much for the opportunity.

Eric Anderson:
You can subscribe to the podcast and check out our community Slack and newsletter at contributor.fyi. If you like the show, please leave a rating and review on Apple Podcasts, Spotify, or wherever you get your podcasts. Until next time, I'm Eric Anderson and this has been Contributor.