Founders on Fire, Mansour Karam, Founder and President, Apstra Founders on Fire Podcasts Posted by Jon Howell | 17/04/2020 Fresh from winning the Cloud Trailblazers Award, Apstra’s Founder and President Mansour Karam talks to Chief Trailblazer Rose Ross. Mansour explains how the firm pioneered intent-based networking and how it enables deadlines to be quickly met, without compromising the reliability of your network. He also recounts how pressure in the early days can lead to company-defining successes to be proud of. Listen to the full podcast here: You can also listen to the podcast on YouTube or Anchor FM. Interview transcript RR: Welcome everyone. This is the Founders on Fire podcast, and I’m delighted to welcome our Cloud Trailblazer’s winner Mansour Karam who is the president and co-founder of Apstra. Good morning to you, hello. MK: Good morning, excited to be here. Thank you for the opportunity. RR: Well, excited to have you with us. I’m very, very interested in you guys, because obviously you’re bringing, or you’ve brought a new concept to market, this intent-based networking, and I’m very also curious about your founders team, because obviously there’s yourself who’s got an incredible pedigree, and then you’ve got your CEO David Cheriton, and also Sasha Ratkovic. So I’m curious to ask you a little bit about that whole side of things, but first off it would be great to understand more about what actually is intent-based networking? MK: Intent-based networking is an approach that we pioneered back when we came out of stealth in 2016, and now it’s an industry term which we’ve seen many established vendors use it. What it is, think of it as powerful automation, and as part of automation essentially think of abstraction of infrastructure. Our focus up to now has been the data centre network, but ultimately what you’re doing is that you’re taking away all the manual tasks, and instead replacing them with software that is providing powerful automation of the tasks that architects and operators are doing day-in and day-out. The key concept here is that you’re separating the ‘what’ from the ‘how’; so what is it that you’re trying to achieve? Generally you’re trying to deliver on connectivity, which ability essentially is our policies that you’re implementing. You have some goals regarding compliance and security, and quality of experience. So, essentially with the way intent-based networking works, is that as the operator or the architect you’re describing those types of goals, objectives. And then the software then takes care of translating those goals into implementation, by configuring all of the devices or all of the systems underneath, that together will then deliver on this goal. It doesn’t stop there; you also have to gather all the telemetry and ensure that ultimately the infrastructure is delivering on this goal, and usually I use this analogy of the self-driving car. Ultimately the goal here with intent-based networking is autonomous operations, where the software is essentially doing the bulk of the work of automating your network. And if you think of a self-driving car, it’s not about changing the way the car is designed. Similarly here we’re not changing the way the network is designed, we follow standards and industry best practices, but what we’re doing though is we are collecting a lot of telemetry. The same way with the self-driving car, the software can’t work if it doesn’t get awareness of its environment through all of the telemetry that its gathering. Then we’re building the software that takes into account user intent, in the case of the car it’s “I’d like to get to this destination for us”, it’s the concepts I’ve described. Then essentially then the software is taking on all the complexity, of then marrying the intent to the operational state of the network to deliver on your intent. RR: Got you, absolutely. MK: So, that’s intent-based networking, and we can get into the pain points as to why that is needed, if you’d like? RR: Well, complexity is never a great thing to deal with when you’ve got lots of other objectives. MK: That’s exactly right, and I think especially in today’s world where technology is paramount, and organisations are digitally transforming; the business requirements are driving a requirement for infrastructures to transform. I think what Gartner has said is that if you don’t transform your infrastructure, you’re three times more likely to fail in your digital transformation initiative. The reasons are clear, you need an infrastructure that is more distributed and closer to your end-user, but also you need to be responding to change a lot more quickly. So, there are new business requirements that come up every day, that essentially change what we call your intent, essentially what you’re trying to get out of your network. You may want to be adding a rack, or adding a new application, or new users, and every time you do this you need to make changes to your network. In doing so, with this new requirement, operators and architects are experiencing this painful trade-off, especially operators, between on one hand agility, the ability to respond quickly to those requests, and on the other hand reliability. So, you could try to make changes quickly without the proper tools or the proper software to meet your business demand, but then what you’re risking is causing outages. We certainly have seen many stories over the years of catastrophic outages caused by operators making changes quickly, to meet those business-driven deadlines. So, reliability becomes an issue, and of course the primary source of failure is this human error, with a human attempting to make all of those changes quickly to meet those deadlines. So that’s if you try to make those changes quickly. Well the alternative then is to make changes really slowly, but then you’re impacting your ability to respond to the business need. And today that’s what we see, it’s common for enterprises to take weeks, up to six months in some cases, and dozens of people are involved to make a change because of all the procedures, approvals, tech reviews etc., required to ensure the level of reliability that they need. So, ultimately it keeps the operators squeezed between the business and the process, including all these manual actions and approvals. That’s one of the pain points, it’s kind of like this trade-off between agility and reliability. The other pain point is this constrained vendor choice, in fact we see a lot of customers, or a lot of organisations that just use one vendor. Of course this results in best of breed, and no best of breed, and then non-competitive bidding. So procurement is affected, essentially they can’t have multiple options where they can bring costs down. The reason the organisations have had this lack of flexibility, or are a single vendor or have this constrained vendors choice, is that it takes a lot of time and investment required for operators to get training on those multiple vendors. So instead of making this investment, they’d rather just use one vendor and have that expertise with just that one vendor. Last but not least, architects. If you look at the architecture side, and these are architecture pain points, there is a speed pain point. Think of it from an architecture’s standpoint, the business requirement comes in, you need to build up a new data centre, and it needs to be done by this deadline. It takes a long time to manually deploy and activate an infrastructure from scratch, once the business requires it, which ultimately can result in business delays. So, if you look at all these problems, we’re talking about agility, we’re talking about reliability, lack of options of constraint, vendor choice, and then speed, ultimately the overall theme is that it’s a people problem, it’s a human capital problem. You want to use your human capital in the most effective way, and certainly doing things manually is just not the right option. Current technologies essentially don’t help with this trade-off between agility, speed on one side and then reliability on the other side, and so what we saw is the need for this powerful automation solution that covers all of Day Zero, Day One, all the way to do plus, so that you can meet all of those requirements and address these pain points, and that’s essentially what Apstra was founded to deliver. I think the big idea here is this realisation that what you need is a tool that both architects and operators use. So the architects use it to automate to get design, and the build of their network infrastructure, and then the operators use it to operate it, including troubleshooting, including making changes etc. So it’s bringing these architects and these operators together in this very effective, streamlined solution that allows them to effectively address those pain points. Then ultimately with the smallest number of architects and operators they can become a lot more effective, responding quickly to the business demand whilst maintaining these high levels of reliability. RR: Brilliant, thank you. That was very useful. I’ve certainly got a much better understanding of that now. Going away from the technology itself, looking more at the journey that you, David, and Sasha have been on as the founders of Apstra, what would you say have been some of the challenges that you’ve faced, and hopefully overcome? MK: We built a business from scratch, and I think every founder will tell you that every day you wake up, there are problems and challenges to solve! So, essentially it requires this extraordinary effort, and this massive amount of energy by everyone to execute essentially on the vision, and translate this vision to reality. So if I were to pick one example, I’d say one challenge which I think for us was company defining, was when we had a lot of interest from a particular company in the early days of Apstra. This was our first organisation that was going to deploy in production, and they had their own deadlines. It was our 1.1 product. So, it was a very early version of the software, and they had some requirements that they wanted us to deliver on, which meant that we needed to make changes to the software, and at the time because it was an early version of the software we were still in testing, and there were quite a few bugs we were still in the process of resolving. So, when you looked at it, it was like how are we going to get from this point where we are now, to delivering a production-ready version of the software for this customer in their environment, that essentially is going to run the network within a month, it was four weeks. To me what was amazing was how the team just came together so tightly and so intently to deliver on this challenge. Ultimately it was a very stressful month, but we delivered and the deployment was successful. I will always remember it as this beautiful company-defining moment. RR: Well you’ve just answered the next part of the question, what you’re particularly proud of? So well done, you’ve wrapped that up! MK: Yes, certainly that was something that I was definitely proud of. Again, I think as a startup every time you meet a goal or there’s something that you achieve that was part of the original plan, you feel really proud of it. Certainly for us that was our first customer deployed in production. Another moment was when a customer deployed beyond their initial deployment, and then scaled it out to hundreds of racks. It’s a huge difference to deploy in a small environment and then take it to scale. That tests the scalability of the solution, and first of all it’s a validation that what we’re doing matters, that they saw so much value that ultimately they’re going to be scaling it to the rest of their environment. But then it gives us validation also that it was the right thing to spend that much time on building the right architecture, so that we are able to scale. Then when that deployment happened, and you see that the technology is essentially able to scale, that becomes a moment of one relief, but also of pride that we are able to scale this technology, and address our most-demanding customer needs. RR: Brilliant, and you talked about another thing which was validation, and the customer validation is incredibly important, but obviously you won our award and that’s one of the reasons we’re chatting today, and I know you… MK: Well that’s another proud moment of course, winning that Trailblazer Award! We were excited about that, and of course we’ve also won other accolades in the industry. RR: Yes indeed, which is better isn’t it, that you get continuous validation from external parties, which is wonderful. We always wonder, how important is that to an organisation, particularly in those early days when you are asking people to make miracles happen in a month! And sometimes there’ll be low points within that, and certainly others have said that getting something like an accolade like the Tech Trailblazers and others that you’ve had, helps lift those spirits and just gives everybody an opportunity to celebrate that their work is being recognised, beyond obviously the customer satisfaction that they get from people. MK: Absolutely, there is no question, I think we see a lot of value in that. We’re always very grateful and humbled when we get these accolades, and then we internally celebrate them. In fact, all of the physical awards that we have, like the statues and the plaques and so on, they’re all displayed at our office when you get in. So, every employee when they get in the door they see them, every visitor, every customer sees them. So we certainly see a lot of value in those awards, and certainly it’s an honour to be recognised in the industry. We personally, as in Apstra, speaking for ourselves, we’ve always put a priority in applying for industry awards, and it’s really valued the importance of these industry associations, to help us with creating this awareness to a much broader audience. I’d say awareness is always a key goal for organisations, for startups. At the end of the day when you’re a startup, when we’re starting a company, the only people that are aware of it are the founders! RR: Well particularly since you’ve been off for two years, while you were stealthing through your initial development side of things. MK: Yes, exactly. Then when you’re out, I think it’s always a challenge to go out and create awareness. We need the type of customers that have those pain points to know that Apstra addresses those pain points, and I think industry awards are a great way to create this awareness to this much larger audience. It’s also industry validation from if they’re a third-party group of judges. So it’s not us saying it, it’s the experts in the field, third-party neutral experts that are giving us those awards. So it’s super-helpful again especially at an early stage, it gives us the credibility, further credibility in the broader market amongst our customers, our partners, and also from a recruiting standpoint for a startup such as Apstra, having the right people and the right talent is always critical and it helps there as well. RR: Yes definitely. So to wrap up, obviously we’re facing incredibly difficult times at the moment, personally and also professionally, and from a startup’s perspective obviously that’s no different, although I’m sure there are additional challenges. But generally speaking, what advice are you giving to your counterparts in other startups, what would you say to them about ensuring that you continue to build on the success you’ve made so far? MK: Absolutely, this is a great question, and having been in the industry for a long time we have, as the founders, a lot of experience with downturns, the last big one was of course in 2008. To me the way I see it is there is a lot of opportunity in downturns if you play them right. I think a lot of great companies today emerge from difficult economic times. In a sense, by doing the right things you can emerge as a future leader. So, I think to achieve that I think the first thing is, and it’s not going to be surprising, but it’s really a focus on the execution. The way I like to describe it is, turn up the TV, and I know it can’t be the TV but social media or whatever your news sources are, just essentially focus on delivering. Ultimately a downturn gives you time to build in all of the product features or the capabilities that your customers require, and that you have never had a chance to deliver on, because you’ve just got caught up in the day in and day out. So, it’s an opportunity to invest on delivering on these capabilities. The other thing is, if you’re in an economic downturn it kind of levels the playing field a bit, especially I think in this one where everyone is stuck at home. It almost doesn’t matter if you have 10,000 sales people meeting with customers versus staying at home, you have a captive audience of customers that are looking at this as an opportunity to get educated on new technologies. So, as a startup you can leverage the ability to be agile and just adapt to this new situation, and then put out offerings that then attend to this captive audience. For example for us what we’ve done is, that prior to this whole crisis we had launched out AOS Academy, it’s essentially a certification on intent-based networking. So if you wanted to learn about intent-based networking AOS Academy is the place to go. So what we’ve done is, when we saw this crisis what we said was that we need to do our part, and we made it free. We’re seeing tremendous interest, hundreds of engineers essentially are using this opportunity to get educated, certified on intent-based networking. So, this is an example of us essentially seizing the moment, and essentially doing something mutually beneficial to the industry, and to Apstra. The other thing is of course one has to be smart, control expenses, essentially invest in the critical areas, again raising awareness and building the product, and even setting up the right incentives. As I said, we know cash is tight and so providing opportunities for customers either to learn or to deploy, without having to reach to their cash, I think is something that we are doing, free product training, free consultations with our sales engineers, etc. RR: Well I did actually notice on your LinkedIn profile that you’ve actually been through your own Academy, so you have sampled your own educations. MK: Yes, I had to get certified on the product and the technology, and the approach that we promote. Certainly, yes. I’m actually excited to hear that you’ve noticed! RR: Well there we go, that’s my job to go and have a look at what you guys have all been up to recently. I thought, ‘Oh, I wonder what that is?’ and clicked through and had a lovely look at your certificate in fact, in fact two certificates. That’s great advice, and I think one of the things around this is, it’s great to speak to you. You’ve had a fantastically exciting journey, challenging journey, both from the point of view of your customers, and getting a startup off the ground in the first place is an amazing achievement. So, congratulations on that, and congratulations again on winning your award, and thank you for joining us on the Founders On Fire podcast today. Thank you Mansour, it’s been brilliant, I’ve enjoyed chatting with you. MK: I enjoyed it as well, thank you very much, and have a great day. RR: Brilliant, lovely, thank you very much. Bye bye now. MK: Thank you, bye bye.