Nofar Asselman is the Head of Business Development at Epsagon, where she initiated Epsagon’s partnership with Amazon Web Services (AWS) and developed growth opportunities for the company. Nofar leads Epsagon’s business development department strategy, through revenue-generating channels and creating new alliances.

Nofar is a key figure at the AWS Partner Community and founded the first-ever AWS Partners Meetup Group. The group is focused on sharing joint AWS go-to-market strategies that successfully affect AWS Partners’ ecosystem and growth.

Nofar is passionate about her work with AWS cloud communities, organizes meetups regularly, and participates in conferences, events, and user groups. Nofar is a Founding Member of the Multi-Cloud Leadership Alliance (MCLA) and she loves sharing insights and best practices about her AWS experiences in blog posts on Medium.

Watch this episode on YouTube: https://youtu.be/FL9XLtW57Ms

This week's episode is sponsored by Off-by-none, the weekly newsletter that focuses on the technical details of building modern applications in the cloud, driven by the serverless community. Visit us to subscribe, provide feedback, submit your articles, and nominate people who are contributing to the serverless community to become a Serverless Star.


Transcript

Jeremy: Hi everyone. I'm Jeremy Daly and this is Serverless Chats. Today, I'm speaking with Nofar Asselman. Hey, Nofar, thanks for joining me.

Nofar: Hi, Jeremy. Thanks for having me.

Jeremy: So you are the VP of Business Development at Epsagon, so I'd love it if you could tell the listeners a little bit about your background, what you do at Epsagon, and what Epsagon is all about?

Nofar: Yeah, absolutely. So actually I started in my past life, I was an attorney. I work in a big law firm, and this is where I understood that it's fun to work with startups from the legal side, but I wanted to move to the business side. And this is where I start my startup journey and today I work at Epsagon, where we help microservices customers to adopt microservices in confidence while providing them really seamless experience in monitoring their microservices architectures.

Jeremy: Awesome. All right. So one thing that's really interesting about what Epsagon does is Epsagon has built a business around sort of the serverless ecosystem providing a solution for people who use serverless or are trying to build things with serverless. And I think that's really fascinating because serverless has become obviously quite a buzzword over the last few years. And a lot of people will stick the word "serverless" in their product title or in their description somehow. But what I would love to talk to you about is this idea of actually building a business sort of for serverless, right? So building something for the serverless ecosystem, whether that's a tool, whether that's some sort of a thing that makes it easier for you to monitor or build new things or whatever it is. But something that is for the serverless ecosystem. And so you have a ton of experience in this, so I'd love to get your perspective, but maybe we could start just sort of like what is the current state of the serverless market from a business perspective?

Nofar: Yeah, so I think that serverless is definitely growing. I'd say that it's not growing as fast as we thought it would grow, but I think we see more and more companies are leveraging serverless technologies to really achieve business agility and go to market faster. But I think if 2020 was a year where we did see an uptick in customers that are leveraging serverless, in 2021, we'll see that in a higher scale, just because I think that last year there were still some challenges around tooling and expertise that was still missing from lots of organizations. And there are so many great tools out there now that helping these customers to leverage their technology using serverless and really meeting market demands and meeting their customer's needs smoothly with serverless. So I think this year will be significant in terms of serverless growth.

Jeremy: Right. Yeah. And I think that is something that we've seen a lot of is there's been a lot of complaints that serverless is not easy to adopt as sort of a change in the mindset in terms of how you, again, maybe need new tooling, maybe we need new monitoring tools, maybe we need other solutions that help us do serverless. Certainly need education and training. So do you think, though, that with the growth of the serverless market that there are opportunities for tools and solutions and things like that?

Nofar: Yeah, absolutely. Absolutely. I do think that building solutions around serverless is super important and if we're looking long-term, that's definitely the technology that will be the ground of many companies that will use serverless architectures. But I think today ... And that's what we did in Epsagon, so I'm not very objective, you can see what we've done in Epsagon, where we started to build the serverless solution, serverless monitoring solution and then we expanded the product to also include containers and microservices. Because in the end of the day, when customers are moving to microservices and to more modern applications they would most likely to use serverless, but I wouldn't count on that they're going to use 100% serverless. So you do want to provide them with seamless experience and solution that they can use as a one-stop-shop to their distributed applications.

Jeremy: Right. Yeah. No, and I think that that's a really good point because you haven't seen many shops that are like 100% serverless, right? There's a lot of this hybrid stuff that's going on. I mean, I've talked to several of them, whether it's Liberty Mutual, that's trying to go 100% serverless or LEGO who I think is 100% serverless at this point. And so if you're building tools to support the 100% serverless companies then are you sort of limiting your opportunities there? I mean, like you said with Epsagon shifting over to Kubernetes or expanding I should say to support that. There's been a few monitoring companies that have expanded in that direction as well, went from serverless as a start then they went into the broader container market. But then there are other services and solutions and tools that have stayed just focused on serverless. And then you've had a bunch of other monitoring solutions and other tools that were not serverless that have worked their way back to serverless. So I guess, is the market big enough for serverless-specific tools or do you really think you have to take that approach where you broaden and look at that hybrid market?

Nofar: Yeah, I think it's a great question because at the end of the day, if you're only doing serverless you're probably going to do it better than others. But if you're expanding so the market is larger than it used to be. So I do think that if you're expanding your offering you definitely going to increase the markets that you can approach. But if you are keeping or want to focus on serverless, I think you would need to pay attention also to product integrations and finding partners that can complement your solution. In order again, to provide the customer with a better experience of using one tool or one interface instead of multiple platform if it's monitoring or security or deployment. So I think that's super important because in the end of the day when customers wants to leverage serverless and they want to benefit from business agility and so on, you don't want them to spend so much time on tooling and all of those things. You want to help them to bring value faster.

Jeremy: Right. No, no, no, no, no, I totally agree with that. And I think that's one of those things where some of the companies that are coming top-down for this, they are sort of adding ... It's an add-on, right? And so again, there's a lot of this traditional mindset where it's like, well, here's how you do traditional development. Here's how you do monitoring and deployments. And here's how some of these other things work. Whereas when you take it from the other side of the equation, when you look at it from just the serverless specific. There are things that are done in serverless that are so different than the way that we do them with our traditional application that I do agree. I think that focusing on serverless could give you sort of a leg up, but, you do need to identify the right customer because they need to be someone that's sort of willing to experiment with new tooling.

Nofar: Right, right. Definitely.

Jeremy: All right. Awesome. So what I want to do is I want to use your expertise here and pick your brain a little bit because the point of, I think, this episode is there are a lot of people who are building products with serverless, but they're just building them with serverless. So again, I want to focus on this idea of building products for serverless like things that layer on top of it, things that other solutions, other services that might aid you in your development of serverless or your ability to maintain and manage serverless, or even to educate people on serverless. So, let's start with maybe this idea of how do you find the right contact person in a company you're trying to sell to? Now, I'm not a sales person. I don't think you're a salesperson either. But, I hate selling things. I'm not a huge person trying to sell things. So, this is an awkward conversation for me.

But I do find that if you can find the right person in the company and maybe that's not the right specific person, but just the right level of person. And you can strike up an authentic dialogue with that person then selling becomes less about selling and more about helping, that may be a little altruistic from the sales side of things. Anyway, so if you trying to get into a company that was building with serverless, so who would you start with? Would you try to target developers? Would you try to target senior leadership like the CIO, CTO level? Would you try to go like maybe VP of engineering like mid-level? Who's the right person to target for a serverless solution?

Nofar: Yeah, I think it really depends on the customer serverless journey or where the customer is in which stage of adoption the customer is. Because it's really, you know, early stages, let's say if we look on AWS serverless where customers using are Lambda, but not more than let's say $1,000 per month. So there you would see that most of the customers or most of the users would be developers. This is going to be the main point of contact for you. The motivation there is more of tooling and really improve the developer's experience. But then if you're looking at the company that is a bit further in that journey and looking from $1,000 and let's say up to $5,000 or more or less. This is where the company is starting to scale on serverless and then the needs are different. Then the needs are more to reduce total cost of ownership in the short term, dev ops needs and so on. And there is the main point of contact that I would approach would be mid-level, director of engineering, people in or cloud architect leads, this kind of personas. And then if you were going up then more than $5,000 per month, I'd say this is where the CTO is getting involved. This is where the total cost of ownership in the longterm is more the main motivation for this adoption.

Jeremy: Right. I love that level breakdown. That's actually kind of helpful. So, you mentioned though like where customers are in their journey. So, I think that's another question sort of like I've been involved in a lot of startups. I've unfortunately had to be involved in some of the sales processes for startups, because as a technical person I would come in and sort of do evaluations and things like that. And I know for one, trying to sell into an enterprise can be very, very long and lengthy process. Whereas sometimes startups are a little bit faster to adopt a technology and try something new. Mid-market or midsize companies there's always a sort of a crapshoot there in terms of how quickly they will move and how many layers of red tape that they have. But I'm curious like what would be the size company that you would think would be best to target? Like should you, if you're building a new product for serverless should I start with the startups and try to target those companies? Or should I shoot for the moon and go right for the enterprise customer?

Nofar: Yeah, definitely. I would say that it really depends again on the consumption of serverless on the customers, but where we see most or when we see the need of monitoring for serverless, we obviously see it's among startups, right? They are cloud native, born in the cloud usually they use serverless from day one, and this is really our bread and butter. So definitely start-ups is the main audience for the cloud native in the cloud native space. But then you also see enterprise customers that are starting to leverage serverless technologies, really again, to improve agility and to reduce costs and to reduce overhead from their teams. And you see that they're starting to have more and more projects of where they use serverless and also containers, but serverless in particular.

And once they see success there, this is where you see more projects that are involving serverless as well. I can give you an example that we had a win with one of our customers with one team in an enterprise company. And then within three months, we already had two upsells, two different teams that just saw the success and replicated that. So that's exactly how enterprise ... They are moving slow, but when they are moving it's at scale. So this is why I love also working with enterprises because when they see the value and you have one success with one team it's so much easier to work with other teams in the company as well.

Jeremy: Yeah, no, I think that makes a ton of sense. And that's the other thing with enterprises too, is that now with all these different business models or organizational models that are used, you have these little project teams that are a little bit independent, they're like startups within a larger enterprise. And if those can start adopting a specific tool or some other solution that getting the rest of the company to pile on or to adopt that is a good possibility. So that's always a good tactic, but again, it's about identifying companies and figuring out which companies are doing which. But that actually brings me to another question I think is kind of interesting when it comes to this, not a ton of people or I shouldn't say this ... A lot of people are using serverless, but a lot of people are sort of dabbling in serverless. They're not full on serverless, using it every single day or whatever.

And I guess my question is if you're building a new serverless company and you're trying to target people with this, do you want to try to sell something to someone that isn't using serverless? Or do you want to try to sell something to someone that is using serverless? Like if you're already using serverless, it seems like it's an easier sale to sell them a serverless solution as opposed to trying to sort of create a market.

Nofar: Yeah. I think creating a market is super important, but if you are building a company around serverless and you do want to make profit out of it, I would say that waiting for customers to adopt serverless and sort of educating them and convincing them to move and adopt serverless that would take you a lot of time to see any value out of it. I do think that education is super important, but I think that targeting customers that even if they've just started, but they're already sold on the serverless idea and they already see the value. I think this is where, in my opinion, to keep most of your focus on to educate them how they can take these just initial adoption and scale that. So I would focus on these kinds of customers.

Jeremy: Right. Yeah. I totally agree. I see a lot of blog posts of people who are starting to use serverless, and it's amazing that they're either trying to do things themselves and they're not aware of the larger ecosystem. And again, there's so much content out there about how to use serverless, how to build, how to monitor, how to do distributed tracing, how to do canary deployments, all those kinds of things. And I see a lot of people reinventing the wheel. And I think a big part of that, like you said, is sort of this lack of education, which I mean that's another thing where if you're a startup and you're in the serverless sphere here.

And again, I think this goes for any company that's in any new emerging technology market or something like that, participating in the community, being someone who's out there whether you're just doing webinars or you're posting videos, or you're writing blog posts, or you're going to conferences or contributing to open source, things like that. I think that's really important. I'm just curious your perspective from I guess a business development standpoint, how important is that that as a new company in some ecosystem that you get involved in the community and that you contribute to the community and try to help educate?

Nofar: I think it's super important. I'm a huge believer in communities. I run a community of AWS partners. I write blog posts about things that I'm doing when it comes to cloud alliances and how you can grow your business with cloud alliances. So I think that in the serverless space, there are so many ... You know the community in serverless spaces is just amazing. You are playing a huge part of it and Farrah Campbell as well, doing such a great job in really educating the market and showing that you don't need to be an expert in order to leverage serverless and that's awesome. And I think that going to conferences as a customer that wants to leverage serverless or is a company that builds a solution around serverless. Going to these conferences like ServerlessDays, in the past life before COVID, but ServerlessDays, AWS re:Invent and all these old ... any summit that is really technical-oriented where there is a huge focus on serverless that's definitely where I would go. And also this is a great platform for you to meet potential customers, to learn about challenges that they experience and how you can actually be more helpful to these kinds of companies.

Jeremy: Yeah, no, I totally agree. And I can't stress that enough. One of the things that's been great about Epsagon and a lot of the other companies in this space is they've helped create the community. They've built, they've run the conferences, they've done the webinars, they've flooded things with blog posts. And the other thing I love is, I think AWS, Microsoft, even Google, they do a great job of writing articles and creating content around their particular products and services. But I know for a fact that any article that comes out of one of those places goes through multiple layers of review and everything has to be just right, and you don't get the criticism. I don't think you get the breath of fresh air where someone says like, "Oh, well, this is great. But..." And you don't always get that when you don't have sort of independent voices.

And even if an independent voice is selling their own product, even if you're selling your own monitoring service or your own deployment pipeline or whatever it is, your own CI/CD service. Regardless of whether you're doing that or not, at least when it comes to the technology itself, the overall technology being serverless, I think you've got more honesty there. Which to me is super important because again, I love serverless, I build as much as I possibly can with it, but it's not a silver bullet.

Nofar: Yeah, absolutely. Absolutely. Something will go wrong, but you do need to have the right tools in order to overcome them. Absolutely. Yeah.

Jeremy: Absolutely. Right. Totally agree.

Nofar: And I think what's great about Epsagon as well, is that we are talking in every single conference that we can and our CTO, Ran, is an AWS Serverless Hero. And when he talks about observability within serverless applications, he will talk about Epsagon but in the end he will first educate you about the challenges, how to solve them with open source tools. So, I think that market education is very, very important for every company that is building product in this space.

Jeremy: Yeah, Ran and Nitzan do a great job and your team does an excellent job for the community. So that is definitely much appreciated. All right. So we talked about education as being one of the challenges, and this is just sort of a larger problem I think with just people understanding serverless or what they may need for serverless and things like that. But there's also education in terms of educating people on your own products. So, like you said, with Epsagon you'll educate on the problem itself and then educate on how your solution helps that. So that can be done through blog posts and those sorts of things as well. But what about things like brand recognition? Like how big of a challenge is that for a new startup in this space?

Nofar: It is a huge challenge because when you just starting your business specifically, especially like two years ago nobody really knew what serverless is and then you're coming with a product that is helping to monitor a serverless applications. So that's definitely challenging. You want to gain brand recognition to get credibility so this is where we also use the community and we open our product for a free trial. So companies and customers will be able to see the value for themselves. But I would say that the number one strategy that we had in order to improve our brand recognition would be, of course, doing marketing events, but also working with strategic partners like AWS. And one of the examples that I always give is that about few months after we went GA with the serverless solution.

So we just started the AWS partnership and we were launch partners of Lambda Layers that was announced in 2018, I think. And then all of a sudden in re:Invent we see Epsagon's logo in Mark Vogel's keynote. One out of nine names out there. So all of a sudden from a small company that nobody knows we are on the main keynotes at re:Invent and that just changes everything. So I think partnerships plays a huge role when it comes to brand recognition. And, of course, AWS wouldn't just do that without validating our solution and vouching for us. So that's definitely a great way to improve the brand awareness and recognition.

Jeremy: Right. Yeah. And I guess this probably ties in, because I think definitely the route that you went with being an Amazon partner or part of the Amazon partner network or APN that was a very, very wise strategic move. Because the other thing, I mean, this is just other challenges I think about. Like if I'm starting a technical company, one of the things that you probably need to do if you're dealing with the cloud and you're dealing with serverless, because you're likely not building your own serverless solution, you're building something on top of... Sort of standing on the shoulder of giants, as they say.

So you might be building something on top of AWS, which means you might need to access data within their AWS Cloud, or you may ask them to create roles or security tokens that allow you to access their systems and manipulate things, maybe even deploy things to their systems. So that's another thing like, and again, maybe APN is part of it, that the partner network is part of it, but how do you build that trust for one? And then maybe to extend that even further, how do you deal with people that are asking for you to be compliant and have all these global compliance issues that would probably pop up, especially if you're dealing with something like enterprises?

Nofar: Yeah. I think that's in order to be enterprise ready you have to comply and achieve all sort of certifications like HIPAA and ISO and SOC 2 and so on. So that's definitely needed. I don't know an enterprise that would work with you without these kind of certificates. And of course, meeting the AWS best practices and well architected that's another thing that's really helped us to improve the way that we operate.

Jeremy: Yeah. Yeah, no, I agree. And that's the thing too, you're right with enterprises it would be really hard for them to say, "We're not PCI compliant. We're not... " And again, if you use a lot of those other tools, you leverage the existing services that AWS has or Microsoft Cloud or Microsoft Azure, some of those other companies have, then you get a lot further than you would if you were just building through your own data center. But still, definitely a lot to think about there. So, maybe we could talk about the partner thing for a minute, because that was, I think a really good and brilliant move by Epsagon early on is to say, "We want to be part of this larger network so that we get our name injected here and that we get these certifications. So that when it comes to asking, "Who do we choose for this?" that at least your name is on the list, whether it's at the top of the list or not, at least it's on that list. So how did that happen? How did you go about that? I get the thinking behind it, but what was sort of the process that you used to get to that point?

Nofar: Yeah, I think that's what ... The process was that I joined Epsagon, we were like three months before our product was GA, and I was thinking, "Okay, how can we get more exposure? How can we get customers?" And I was starting to think like, "Okay, if we're going to approach different companies they don't know us, right?" So that's really difficult to convince them, "Hey, you should listen to us. Hey, we have an awesome product." Then I just tried to think my potential customer. Who would have these kinds of customers in common? Who would have the same customers that I'm looking to have? So, of course the first name that pop up to my head is AWS. Because before we expanded our offering to Kubernetes and containers and to Microsoft as well so we supported AWS Lambda. So naturally our customers would be AWS customers, right?

Jeremy: Right.

Nofar: So that was okay. That makes sense. But then, okay how do I start to actually partner with a giant like AWS? I mean, how do I navigate these forests? And I just started to see what kind of programs I can leverage and try to also, I think the main thing that I did was to connect with the product teams there, really to understand if they do see the value in Epsagon, and really to build a "better together" story as really Epsagon as enabler of adopting serverless applications. So I think that as enabler we were able to see the commitment from AWS as well and support that helped us through our journey and growing our business in the first years.

Jeremy: Yeah, no, and I mean, and that was one thing too, that was very interesting from the beginning. And I know AWS provided a lot of support for monitoring companies and for that being able to do distributed tracing and things like that. Because AWS just didn't do an excellent job at that and there's still a lot of gaps in their solution. So, having the ability to sort of expand that to their partners I think was very helpful for them as well. So if you can ever find a way that you can help AWS it seems as though that many of these cloud providers will take advantage of your offer to help and being able to kind of fill some of those gaps is definitely a way to do it.

Nofar: Yeah. And it's a bit tricky as well because lots of companies will have a product that most likely will compete with a product that AWS has, because AWS has lots of products. So I wouldn't worry too much about that, because in the end of the day you need to understand what is the focus of AWS. For us, it was okay, the focus of AWS is the monitoring piece or the serverless computing piece. And obviously it's the serverless computing piece so if they do provide some sort of monitoring, we definitely can provide a solution that can complement this solution and not necessarily compete. So that's definitely something that I recommend to take in mind because lots of founders have like, "Oh, I don't want them to steal my idea. I don't want them to think that I'm competing with them." I wouldn't worry too much about that.

Jeremy: Right. Yeah. And actually that is a great point. And I'm glad you brought that up because this is one of those things where I've talked to so many... I mean, I've been doing this for a very, very, very long time. So I see all these new things pop up on Product Hunt or whatever. And I'm like none of these are new ideas. It's just somebody figured out a way how to execute them. And that's one of those things where like, if you have a good idea, you know everyone has good ideas. I'm sure a hundred other people have the same exact idea as you it's just whether or not you can execute it. And that's the other good point about just about dealing with or competing with AWS. AWS is likely going to build a solution so that their customers have a one-stop shop to sort of solve maybe 80% of the problem. But for most customers, there's always a better solution out there and so I do think, and maybe this again, I think you maybe have already said this, but your advice is if you think you're competing with AWS, try to figure out exactly why AWS might be competing with you. And if it's something you can compete with them on which is again, better developer experience, just better tooling, easier to use things like that. Your advice is go for it, right?

Nofar: Yeah. It really depends on the product, but most cases, yeah, I would say go for it. Because in the end of the day you're going to do it much better because this is your entire focus, right? So you really need to ask yourself, is that the focus of AWS or not?

Jeremy: Right. Yeah. No great advice. All right. So speaking of advice, here's what I'd love to get from you. So anybody who is ... Because first of all, I want the market to be flooded with serverless products, right? Deployment engines or monitoring solutions or whatever they are. I mean, maybe not monitoring solutions, we don't want to get in Epsagon's way but you know just things that ... More solutions out there. Because I think the more tooling you have, the more product offerings you have. Now, again, not all of them are going to succeed but the more that you have out there, it just sort of "the rising tide raises all ships" sort of thing. Like the more people hear about it, the more these solutions advertise, the more people figure out why serverless is amazing and hopefully more people adopt it. Which again, start buying the tools and then it keeps raising those ships. So, what would your advice be to people who are just getting started? What's the first step? So I just came up with an idea or I'm in the process of building this product right now. What's the first step that I do to try to start up my sales cycle and get some adoption of my product?

Nofar: So I think collaborating with partners would be something that I would do right at the beginning, identifying the right partners that will help you to get in there, really put the foot in the door in companies that you probably would not have access to, especially the enterprise customers. Because startups would probably adopt your solution even if they don't really know the company. And even if they say, "Okay, maybe they will not be here tomorrow, but I don't mind. It's not such a huge commitment for me." But if you're looking at the enterprise customers, I think this is where you would need a partner to get in, especially the beginning. And really identifying who's this partner? I mean, it can be a cloud vendor, it can be an ISV, really depends on the product that you're selling and trying to think of okay, let's think about my next customers, which kind of tools are they going to use? Which kind of vendors are they going to use? And really to start crafting your partnership strategy.

Jeremy: Yeah, no, and I think a big part of this too, just my own advice, is relationships. And I know that's probably a little cliched to say, but you start making friends, go to these conferences, whether they're online or whatever, start following the people who are in the space, get involved in the community, write some blog posts. Again, we talked about that earlier, but once you start making friends and you start making contacts within the industry, the other thing is, is that you can leverage those partners pretty extensively. I mean, if you find a consultant for example, that you can sort of sell on your product and show them why your product is amazing or whatever. Then hopefully for their consulting clients, they would say, "There's this product that I use or that I really like and that's something that I want to use." So again, value of relationships, again, we're both not salespeople so it's sort of hard to give you overall sales advice, but I guess, development or business development strategy advice, I think the idea of partnerships and just making connections is a huge deal.

Nofar: Definitely, definitely. And always think how you bring value rather than, okay, how do I sell my product? Right.

Jeremy: Right, yes.

Nofar: About like a year ago or so I was thinking, okay, how can I help customers? If I was a customer that is just starting using serverless what would I need to know? And I came up with the idea, okay, let's do a session about best practices. And then I talked to Stackery back then, and I talked to PureSec back then providing security for serverless and planning for serverless and said, "Okay, let's do an event with 45 minutes about monitoring, deployment, and security. And let's see if that will be interesting for serverless customers." And we've done that with AWS and all of a sudden we had more than 100 people registering to the event and we had to stop the registration. And you've seen that, okay, there is a demand for this kind of content. So that was a great way to understand how you can actually bring value to the customers.

Jeremy: Right. Right. Yeah. And I think that's one thing about content creation that is kind of funny. I think we get into this thing where like we discover something really interesting, some really cool way to do X, Y, Z and then we write a blog post about that. And for people who are in the ecosystem who are already using serverless, they might come across it. Maybe it's a problem they're having, and they find it. But from a more global education standpoint, there are a lot of really good, but also a lot of really bad "what is serverless" posts and videos out there. So, yeah having a nice sort of like holistic overview of the whole thing I think is super important. So one thing that I actually wanted to ask you about and this just again goes into, I think, setting expectations.

So it's a long journey, right? If you're building a serverless product, if you're building any product don't expect to be financially independent overnight and be buying a private island. It's going to take a long time. It's a long journey. You've really got to work at it. You've got to make those partnerships. You've got to put the work in, you've got to do that, to grow those relationships and grow those customers. But just maybe another expectation that I think maybe somebody who's like, "Oh, well, I'll just sell this to enterprises." An expectation that not everybody has or an expectation maybe they do have is that it's like selling to anybody else, but enterprise sales are a long and sometimes painful slog. Sometimes it goes faster, but I'd love to just sort of talk about the enterprise sales cycle for a service like this, especially a software service and what that typically looks like, and maybe from your experience, how long that typically takes?

Nofar: Yeah, definitely enterprise sales is a bit more tricky than I'd say a startup sale, obviously. The challenges are different, it takes a lot of time from one call to another, to a PLC to someone to sign the contract it takes a lot of time. In some companies you need to be onboarded as a new vendor then that can take like another nine to 12 months or so. So you need to be patient and you need to find your champion inside the organization, that's for sure. You want someone to be your advocates internally there and I think that another thing that you can definitely leverage, something that we need was to use marketplaces. So if this customer is already paying to Microsoft or paying to AWS, you can save a lot of time instead of onboarding, to be onboarded as a vendor, you can just leverage one of these kinds of marketplaces. And for us, it saved a lot of time.

We had one particular customer that said to me, the champion there told me, "If it wasn't for the marketplace, we probably would not move forward with you because it would take about 12 months to move forward with you. And I would probably just ditch you guys, sorry." So we were able to move pretty fast. And when I say fast, I mean about two months, three months for an enterprise deal, I'd say. And it can be longer ...

Jeremy: Only two.

Nofar: ... only, yeah. It can be longer than that. Specifically for security tools it can be like six months a year. But for us, I think the average would be a few months, I'd say the longest was I think five months, if I'm not mistaken. It's something like that.

Jeremy: Yeah. No, because that's just one of those things where there's a whole process to it, and once it's sort of ... And it depends on how big your tool is, what it is. I mean, again, some companies have the ability to just sort of make those self-service purchases and then those get boiled up. But if you're adopting for an entire company, you know depending on what it is you're building it can get really complex. But you mentioned the idea of identifying a champion. This goes back to relationships, right? You find one person that sees you speak at a conference, or just happens to read one of your blog posts and comments on your blog posts and you can start a back and forth with them. Having somebody in a company though that is advocating for you is a hugely important step because enterprises have no problems sort of pumping the brakes on things and slowing things down if somebody internally is not pushing on the gas.

Again, I'm not criticizing enterprises at all because they are big, heavy machines that have a lot of moving parts that make it sort of difficult to navigate sometimes. So having that champion I think is hugely important. And then the other thing you said, this is another really important thing, is onboarding, like how easy is it to get your solution into that company? And I know that when Epsagon first launched and other monitoring tools, Lambda was limited, there was no such thing as layers, right? You didn't have custom run times, you didn't have the new extensions API and things like that.

Jeremy: Which meant that in order for you to instrument your functions, you had to actually put code within the function itself. You had to put a wrapper in there. And some of that got easier over time I know the serverless framework did something where they would automatically wrap your functions and things like that, which was great. But then it went to just layers. So you add a layer and then suddenly you get this capability and now with the extensions API it's even more amazing. But yeah, I think that is a huge thing to think about is to say, how hard is it for me to enable or turn my product on for a customer?

Nofar: Yeah, definitely. I think that for every partnership, I always divide it into three: co-sell, co-market and co-develop. So there are lots of things you can do under the co-develop category where you actually can bring more value to your customers and extension and Lambda Layers are great examples for that. I remember that when we did the Lambda Layers integration and all of a sudden the number of users that actually completed the onboarding was just amazing. It went up within a week just because it was so much easier for them to onboard to the platform. So those kinds of integrations are super valuable if it helps you really to cut the onboarding time significantly. So that's another thing that a partner can really help you to achieve while working with serverless customers.

Jeremy: Yeah, no, I love it. That's just good advice there so pay attention. No, I mean, if you're building a business that is absolutely huge. So all right. While I have you for a few more minutes, I have a couple of questions that we actually got from the listeners. And if you are a Serverless Chats insider, you can go to serverlesschats.com/insiders, and you can ask questions of our guests and we will try to read them and get the insights of brilliant guests like Nofar here. And one of the questions that we got was about just whether or not serverless might've been a trend? And several years ago, I know you joined a few months before Epsagon went GA, but how did you deal with the possibility that serverless might just be a trend? I mean, how did Epsagon deal with this maybe? That you say, "Well, what if this goes away in three years?" I mean, you made a massive commitment to back serverless.

Nofar: Right. Yeah. It is definitely seems like a trend sometimes where every single company is saying that hey, we support serverless as well. And in the end of the day, when you're starting to use the product you understand that the support for serverless is very, very limited. But I think that's the way that you can use serverless technology and the value it brings to customers. I think that's so significant that more and more companies will definitely adopt serverless and as we move forward and as time pass, more and more companies get more expertise, you see more and more jobs, where the description is saying, "Hey, we need expertise in serverless."

So I'm really happy to see that because you see that the market is going to this direction. I also had a conversation with one of our customers that said that they actually, one of the reasons that they migrated to serverless it was because they wanted to attract brilliant developers to the company. So that was an awesome thing to hear. So I do think it's here to stay and it's here to grow hopefully significantly. But I do understand why it might seems like a trend at least at the beginning where you hear serverless in every direction.

Jeremy: Right. Yeah. I mean, and that was funny too. The first time I sort of came across it was with Lambda in early 2015. And I remember just thinking when I first saw it though, I was like this is something. There's something there, there and it was just one of those things where for me I was like, "There's no way this can be a trend because if this works the way that it's supposed to work and it continues to develop out, I just feel like this could be the way that we just build things from now on or at least how we build things in the cloud." All right. So another really interesting question here was, if you go back to the origins of Epsagon why did you decide that Lambda was the right target to start with?

Nofar: I think that Ran and Nitzan the founders of Epsagon they a very strong technical background. Both of them were in one of the elite intelligence units in Israel, in the IDF. So, Ran is really very geeky, were one of these guys that started to code when they were four or something like that. And both of them recognize that there is something new, serverless, and it's actually very, very different to understand what's going on in your application when you are developing in serverless. You know the most natural thing to understand how different events are correlated that's something that is very difficult to achieve. And you have to do a lot of manual work to have these kinds of understanding. So they investigated and saw this problem also in container-based applications and microservices in general, but they saw that in serverless, it's so much more painful because everything is managed and you don't really have control and cannot simply install an agent and see what's going on.

So this is where they started to play and in the end of the day, they built Epsagon entirely on serverless. So they definitely understood the problem is as they moved forward and say, "Okay, I think we know how to solve it." And today we're actually I'm happy to update that we also have a patent around how we actually provided capability on the tracing, a U.S. patent on that. So that's huge, right? So you see that there is a way that you can actually make things much more easier to manage and you can adopt serverless much easily with these kinds of tools.

Jeremy: Yeah, no, that's a good point. All right. So last question, if you could do it all over again, and I don't know if you can answer this question, but if you could do it all over again, would you stay with initial targeting for serverless and then expand to containers, or would you maybe have done it the other way around or done both at the same time? How would you have done that if you were able to go back in time and do it again?

Nofar: I think it's a good question, because in the end of the day you do want to have one product for more than applications. So whether you're starting with serverless and containers, I don't think it's necessarily make much of a difference if in the end of the day, you do provide a solution that is a one-stop shop for more than applications. So even if we would start with containers and move to serverless, then I don't think it would make much of a difference. And we've seen that pretty early back then when we launched our serverless product, we immediately saw that there is a need for Kubernetes, for ECS, for microservices in general. And, we just implemented the same technology on these kind of environments and launched another product really to provide a complete solution for these kind of environments.

Jeremy: Awesome. All right. Well, Nofar thank you so much for joining me and sharing all this information. If you are thinking about starting a serverless company that is targeting serverless users, hopefully you got a lot of value out of this. But there was a lot of good advice, a lot to unpack there if you are doing this. So, if our listeners want to maybe reach out to you, Nofar, and maybe pick your brain a little bit more, or they want to find out more about Epsagon how do they do that?

Nofar: LinkedIn or Twitter just ping me and I'll be happy to chat.

Jeremy: Awesome. All right. And then you can go to epsagon.com and I will put your Twitter. You also have a blog nofar-asselman.medium.com. So I will put all of that in the show notes. Thanks again, Nofar.

Nofar: Thank you, Jeremy. That was fun. See you.