this is the art of network engineering podcast in this podcast we'll explore tools technologies and talented people we aim to bring new information that will expand your skill sets and toolbox and share the stories of fellow network engineers welcome to the art of network engineering where we talk the tech live the journey and occasionally meet in real life to share a few beers speaking of beers in real life i have dan richards with me this evening dan how are you my friend howdy tim i'm doing great how about yourself i'm doing well i'm not used to uh to not seeing you in person after uh asheville recently so yeah it definitely is uh different right like um after we you know had a show in person and like i could look over and see you you know sitting beside me i don't like this anymore i don't i don't i don't like the whole like being you know it was uh oh yeah well and i'll tell you like one thing i didn't realize like when we were in person is you know we can read the body language better and so we really didn't step over each other or anything like that um it was just one of those things where you're there you can kind of see when someone's ready to say something and you just back off kind of yeah there are no delays in person and that that really showed i think because i didn't even think about it until after that first one we recorded we got done it's like whoa i don't think we stepped on anybody in that entire time so yeah hey it just means we got to have goals to uh to be able to do this full-time in person someday right yeah right that would be awesome yeah probably all right dan let's get into it this is a sponsored episode from net trees and we have alex saroyan alex is the ceo and co-founder of netress alex thank you for joining us how are you this evening hi guys uh thanks for having me uh good to see you i'm doing we're doing good we are so glad that you are joining us yeah so alex so we we said you're the ceo right and the founder what what what is netreece though can you give us a little bit of a background on what that actually is right now um so netrus is uh netrus is software that runs your data center network automatically so so basically networks configures your switches your routers uh automatically providing users with a cloud-like user experience like in public cloud you have this thing called vpc that is running your uh everything related to your network uh that's where that's that's the direction that we're going and eventually netrus will be the vpc for your on-prem private i think i think that's a really interesting stance you're you're kind of taking the standpoint that in the cloud people can easily click button start applications they don't necessarily have to worry as much about the backend infrastructure it's built for them automatically but you know maybe public and some private clouds aren't for everyone so they they wanna you're giving people the ability to have that cloud-like experience in their own private cloud data centers does that sound about right yeah absolutely we so we we try to think about cloud and kubernetes not not not just about technologies but also kind of new kind of expectation of infrastructure practitioners you deploy your applications in kubernetes or and it's live immediately you don't need you you don't need to wait until unix engineers would make it work that's that's kind of becoming de facto norm expectation and the same is happening with the infrastructure when you want to let's say you want to launch a test cluster of kubernetes or or or you just want to launch a bunch of virtual machines to run some tests you create a new vpc call it test whatever you know uh drop couple of vms into that and it's up and running you start your testing you don't need to worry about implementation details you don't need to worry about no you don't need to wait for anything so it's it's all about making resources um and applications ready for the engineers immediately and uh security what about security it's super secure right right out of the box uh that's that's that's a good question uh actually when when things are done uh automatically a lot of a lot of things can be done kind of according to best practices or according to security policies things like that like oftentimes what what becomes uh what creates security problem is because someone forgot to configure something so when things are done automatically there is no this risk we we humans we are great on planning things on architecting things but when it comes to like doing things many many times we're we don't like that we're we're kind of lazy we would rather architect software and technology and make software and technology do that kind of repetitive things for us and therefore we can even increase the security with that kind of i was kind of thinking more along the line of like the cloud approach right i feel like sometimes clouds are made to be very simple throw things together because but then they kind of lack on security side um and so i was just curious if if you know does netrus keep that in mind whenever you're you're because your products almost drag and drop right uh uh correct there's there's a lot of so our product has graphical user interface where where you can drag and drop draw your topology for example if if that's net network engineer using netris like um remember back in baking days uh network network engineers would draw a topology and architecture using whiteboard and would think how to translate that into configuration and of course there are many ways to cut the orange but in case of netrace the idea is that network engineers would draw the desired architecture they would say these are my switches these are my routers these are connections with my upstream provider things like that they they will provide the information which is architectural kind of information just like they would draw on whiteboard and all that drawing inside netras that that turns into objects in nature's database that netry's algorithm will will turn into actual configuration now coming to the security question so when when netrus algorithm translates that uh architectural drawing into configuration uh there's like a lot of layers of analysis that's happening as a part of algorithm so uh the algorithm will not forget to configure something will not forget to like for example set echo to make sure your ssh is not closed from outside is not open from outside the world we'll we'll make sure like for example just just an example let's say you're you're connecting with your upstream provider and like what happened to me when i was engineer many times uh like you you plug in uh you configure a bgp upstream with the internet provider and your your bgp port is you know uh accessible from outside the world and that's not like super critically dangerous but like it's it's a potentially room for a sinful attack that that can be negative for your for the cpu of your router things like this happen all the time but when it's when when configuration is generated by algorithm algorithm kind of will not forget to configure that echo you know it will open only for the ip address of the upstream not for the world so from that perspective that's yeah anything that can help me not to forget things is going to be uh incredibly helpful i i really appreciate that approach because any time that you can create policy and have uh some sort of software script to be able to constantly check and enforce that i think is is really important because especially when you have multiple staff multiple engineers that are physically configuring devices i may have my standard dan may have his standard aj andy all of us may do things you know it's going to be fairly similar but we're going to have that configuration drift over time so anything that that can be in place that can keep us in check i think is is really important so alex um i think we're having some great conversation about that trees already but what we focus on here a lot is is people's stories people's journeys and how you got to where you were now i'm you can correct me but i'm i'm gonna guess you haven't been creating companies since since day one of your career so can you kind of talk about how you got into netres and and how you got into doing what you're doing now do you have a do you have a network engineering background uh yeah that's that's absolutely true i started as a network engineer i i just you know loved technology uh since my childhood since i was in first grade so what and uh after high school i i got into uh network engineering i started working as a network engineer for a little isp that was probably the nicest way somebody could correct me too just nicely gently into it that's excellent so you you hold on you co-founded the first place that you you started your technical career yeah uh but but there was a there was a small isp you know to not a venture funded business but just like small isp like i i started from like sharing my internet connection uh with my neighbors and then i i've got uh the entire neighborhood you know becoming my kind of users and i thought like why don't i turn this into kind of business i'm i'm having fun doing this and kind of it could help me to keep my lights on and uh over over over a year or so my room became like a little data center and my my parents were not entirely happy with the sound of spinning fans and then i uh ended up kind of renting a little data center room uh and moving the equipment there uh yeah that that was really really small one and uh that that was a we went through a tiny acquisition uh and after that i i i decided it's kind of time to get uh an actual job and well i got into into this company i do remember that i remember like google search and email before google i've joined their team uh as an engineer i i kind of knew engineering but joining lycos was like you know uh entering team which i didn't co-found and like becoming part of you know bigger group of professionals and learning from them uh you know having solving new problems for different company and learning from from other people in that company that was a very kind of start of my more professional yeah because running a data center out of your room isn't professional huh there was more of a hobby which just happened to uh make some a little bit of money for me like i i happened to buy my first car kind of i i just want to know like did your parents did they were they like wtf like what is this power bill uh yeah there was a so uh they i i i started paying the power being bills because like that could be an issue but you know that's the noise from from from the servers that that was i guess you guys didn't have to pay a heat build did you yeah you had a room so during this time and so pre lycos did you have any any formal i.t or network engineering training or were you learning this all as you went and teaching yourself just just teaching myself just you know reading uh everything around linux you know searching for information on internet like reading books and uh my uh good very close friend of my father uh he he he happened to be a net network engineer uh like one of this first early network engineers and he helped me a lot like he like i remember when i was a kid like like like in third fourth grade and i i would love when my father was taking me with him to visit his friend and i was asking him about computers about linux and i remember one day he kind of explained i asked him like how how this internet thing works and he explained me how routing works and he he explained that really super simple like how would you explain routing to kit and that was it i was like i wanna be a network engineer i wanna build the internet i wanna be part of the internet this is this is so amazing like this is something big that everyone can be part of it that's how i kind of got into your house major how's the internet yep yeah yeah and start started sharing with neighbors and it was like how do i learn how who who would trust me a network to learn on it well i'm gonna so let me ask you this did your upstream provider know what you were doing no and uh my my very first upstream provider was like 56k uh dial up modem connection and then when i've connected bunch of neighbors i figured that's not enough so i have connected the second 56k and they they were like connected in load balancing mode and few times they emailed me like like that's weird like you have you you keep your connections constantly you know under load and over some time i discovered uh like back then it was a thing like this uh downstream only you know satellite kind of internet access where where you put the you know satellite antenna and you you're using it just for downstream and you use your dial up for upstream so there was kind of for me as in like you know as a junior engineer it was very kind of appealing to me it's like wow this is kind of cool i sent data out one channel and i received through another channel and a bigger channel so that's how i did it was interesting and beneficial because you know the you don't need a lot of uplink connection but you need more downlink connections so two 56ks were like 100 uh about 100k upstream together and i was getting like almost a almost a megabit of downstream and back then that that was huge and well i i i i got the kind of fastest internet connection fastest and cheapest internet connection in in the neighborhood and i know that's that's how i started kind of scaling i really think that it's just a common trend that that we hear and i know that i i personally felt the same way about networking because when i went to school i i tried the uh the calculus and the c plus and all that and and it was it was hard for me to grasp um and and i felt like i had to constantly be working at it every day and then i sat in a cisco netacad class and it you know the like you said those those first concepts really just hit and stuck and i i'm not saying you know networking is easy by any means but a lot of the you can follow the the osi stack from one to seven and concepts are easy to modular modularly put together and i and i think that's what really sticks with people because you can get as in depth as you want and i think that people need to understand once you get into networking you you run the highway for all the applications and all the services and you will quickly learn high-level concepts about what everybody else is doing too and you become incredibly valuable as a technology person getting into networking so i'm really glad you highlighted that so from from lycos what uh what took you from there uh well uh i was just looking for uh a job in in a uh kind of bigger bigger company because i uh like what i did with my hobby type internet service provider thing that was i've learned a lot that was fun it fulfilled my curiosity but i was thinking i want to become kind of more more professional like how i want to learn how other people's work people work like how do they do this in in bigger companies at bigger scale like how do they run these huge data centers uh that's that's how and why i i got into lycos that was a lot of learning everything was so new like this this culture was very uh they back then they had uh almost like a startup culture like from one side they they were uh pretty much systematized in terms of like they had documentation of their infrastructure they had processes they they were using like internal ticketing systems all that was kind of very new for me because running this tiny isp we you can imagine we didn't have all that process right so i've learned that and there were kind of my first steps in uh kind of being part of an enterprise larger company um i i've been there for a little over a year and then i uh i went to another company which was orange france telecom actually i have joined them and they had the project of launching a new operator and somehow i happened to be to become part of that project and participated in that you know designing a bigger you know telco data center and rolling that out which was again a lot of lot of learning so it at what point as we kind of start to tie this back together to net trees and and what you're doing there at what point did you start seeing kind of the vision for for net trees and what you're doing so when when i was working on this project of launching a architecting designing and launching this data centers for uh for orange i happened to work in the same room with my co-founder of netris uh and you know we we've been staying uh until late night you know working on something because there was a lot of kind of a lot of work to do and a lot of a lot of learning for us so we were kind of figuring out things together experimenting trying and that's that's kind of where it where the idea started to kind of born and uh we were not thinking back then to launch a company but like there we we've started asking each other these questions that were kind of bugging us one question was that you know every time someone someone from other teams they required something like let's say database administrator team they would need a new segment a new vlan a new bunch of servers that would require them to come to us networking team to say hey networking team could you provide us more ports more vlan more ip addresses um can you and and then we would ask them create a ticket we would provide like that that life cycle was taking time and we were networking team and of course we were like hey why why why would you need access from this ip to that ip how how come cannot do more with less access like that's not secure things like that like things that all you know many network engineers would like to do and that was part of the the company's uh policy because they they uh they they had like the policy like network engineers and whole bunch of others would need to approve things and would need to stick to these policies but thing that was bugging me it was that like this is not efficient like this is taking time every every time people need to make communication happen from here to there like they need to go to this you know levels of bureaucracy and engineering and implementation and we all know right that implement that that's that's never seamless you you implement something you break things you make mistakes and especially when there's more than one engineer one engineer thinks one way another engineer thinks another when there's many ways to cut orange so these things conflict create conflicts over time and sometimes you just you just blow up the network that that happens so it was bugging me like okay this is how people do networking but there should be like uh projecting that to growth of the world i was like geez like if we do networking like this all the time our humanity cannot scale like we're gonna need more and more networks and if we look at the graph of number of network elements growth and number of network engineers that we produce like we we're not gonna make it there there's no way that network engineers can become like a bottleneck of growth of humanity we need better technologies yeah i definitely agree with that there there does seem to be a point that you hit in certain organizations or certain sides of organizations where at some point the network team does seem to be we gotta we're involved like i said earlier we're the highway so we have to be involved in many uh projects and many conversations and at some point when so many different people need so many different things and and we have to do these very conversational chats with okay what do you need why do you need it every time and then okay i need x amount of time to be able to build that because i've got three projects in front of you yeah at some point we need to lean on technology to to help us so yeah that's really interesting insight that that you came up with that just kind of organically chatting with somebody that you were working with over time yeah to add to that so like when i first started you know our time to market or whatever you want to say our sla on a on a request was like depending on what it was is roughly two weeks right and so we were given two weeks to you know implement a server or make some kind of network change kind of thing but over time it's like especially now it seems like if it's two days that's two days too long you know and and kind of like what you're saying is um you know when people start putting that pressure on i feel like sometimes i can get sloppy with with what i'm putting in because i'm just in a rush trying to get it in place and then i make a mistake and then now it takes more time because now we have to troubleshoot it with you know a developer or whoever put the requests in and um it just it takes time right to fix it to figure out what the problem might have been kind of thing so i definitely see what you're saying there and having you know some kind of i and you know we talk about automation on here every once in a while and and that's kind of like the track that i'm going down right now is trying to figure out how to integrate either python or ansible or both into and the way i'm looking at automation is not to like do a bunch of things like we're super repetitive i mean i do want to do repetitive things or put repetitive things through automation but what i'm really looking forward to is it doing it the same way every single time and not having mistakes whenever i push that button right and so i i can definitely see your your your concern with uh how much network changes are going coming through and then how few of the uh engineers we actually have yeah dan i i think we as network engineering and uh operations teams we can either be seen as a value add to the business or as a roadblock in a cost center and at some point we're humans and we need processes and things that can help us with those daily tasks to be able to provide that value to the business quickly and like you said efficiently because if it's if it's not right the first time then you got to take more time to do it again and who knows what else you broke by doing it wrong the first time so definitely oh yeah yeah 100 so at what point alex did uh did building a company around this idea start to come to fruition at what point did you decide okay we have to do something about this and and starting a company is the right way to do it so back then just like dan said i i i started looking into uh automation i started looking into like how just basically from the perspective of how how can i do my work better that's it i was not thinking about starting a company back then and by then i i moved to another job and uh my co-founder and i we were not we ended up working at different for different employers but i uh i was a network engineer still running a team of network engineers there and it was still bugging me i've tried to experiment i've tried started experimenting with like traditional ways to automate like writing scripts or using different libraries uh where where you can kind of try to automate repetitive tasks and kind of come up with a template give that template to some sort of script and it will kind of configure something for you and you know to to me uh i i remember there was a guy working in in our room he he he loved to use this analogy between network engineer and nuclear physicist he's saying what is common between network engineer and nuclear physicist the common is when each of them are saying oops the impact can be huge so i'm gonna use that i'm gonna use that that is that happened to me a couple of times i did oops and like an entire country like was like experience the blackout for a few minutes and it takes time until you realize what happened you troubleshoot you kind of bring things back right and when i was playing with the with the different you know approaches to automate network engineering tasks what i've discovered i i felt like there's a conceptual problem like uh placing an automation thing between human and cli that that's that's like an amplifier if you if you configure if you make an oops as an input of that amplifier you just you just increase the you know it you you make it like disastrous failure and so i figured no this is like there's conceptual problem there should be a different i should not be in charge of deciding what commands to uh send into cli that that should be on someone else because me as a as a human i'm good on figuring out the architecture the high level things what i want to do but how to do this is the part where where i'm having trouble sometimes not always especially when i'm getting good on something i becoming confident and this is when i make the make the oops so i figured it's not like it's fundamentally kind of not scalable to to trust to to assume that human will not make mistake that's that's how i came to the idea that no there should be a layer of software which kind of is not it's not it's not linear you know it takes something on input it has ability to understand that input and ability to generate the output so so the generation of output should be done by kind of properly developed software test it one million times software test it in many different scenarios software yes software that is following best practices but but like software not human that was kind of the idea which was you know that that was kind of where my head was back then and public cloud was you know growing and um i think kubernetes kubernetes was just starting back then but public cloud it was i could already tell that public cloud is going to be big and public cloud kind of was the the first technology that is sort of opinionated in terms of implementation it was the first technology where you say i want this i want uh this service to communicate with that service and i don't care how what kind of black magic is happening under the hood i just trust them i don't i don't care if they use protocol x or protocol y or ospf or bgp whatever makes it work it's fine so i figured man it's but it's okay to use an opinionated system because that system takes away the risk of oops that's kind of where the the the core like core building blocks of idea uh came in and then uh i've called my uh friend now co-founder and i told him like hey look we're gonna need we're gonna build this remember we were speaking you know uh in front of the building by by night when when we were building this these networks like here's the idea i you know i have created little prototype it kind of shows some tiny tiny signs of potential work like let's do it are you in or out he said i'm definitely in so that's how how we started just put together a little prototype and we said like if we can find someone who can we can say that this makes sense i gonna use in my production if it works i gonna use in my production network maybe it's it's viable we should we should work on it that's that's kind of how it started so one thing i want to kind of go back on is you're you're talking about how cloud is did you say opinionated yeah opinionated and self operating like when you when you ask cloud to provide connectivity when you say hey cloud give me a vpc and give me 25 vms inside this vpc you don't know what kind of technology is working underneath is there a vxlan is there a bgp vpn is there a vlan is is there whatever is working there you you even don't have visibility into that you don't have a control because that's kind of uh that's kind of up to technology to make that work right that's kind of higher level of obstruction traditional networking has like low level of obstruction cloud and vpc in the cloud has a higher level of obstruction and that's level of obstruction is very similar to kubernetes because you essentially don't care you know which container does what as long as it's servicing whatever the need is right yeah exactly what kubernetes did to compute and application provisioning the the same vpc does to cloud networking and the same is we hope netris does to physical on-prem networking you're still going to need net network engineers adopts engineers to to tell netris what what to achieve what architecture we're looking for how do we plug in our upstream providers things like that uh but uh the implementation uh of like right configuring protocols and timers and things like that uh is done automatically by software so that helps to avoid human mistakes from from one side that and that enables uh network engineers to provide solutions that devops engineers of today that are accustomed to public cloud so network engineers with the help of this kind of products are able to provide kind of right products for today's devops engineers today like like just like you said the ticket implementation time was like days or weeks like but that's not acceptable in today's public cloud world you you create a vpc you create you you throw a bunch of vms uh yeah and it's ready to operate it's under one minute it's not like it's not even hours it's just one minute and that's what devops engineers want to see that's what devops engineers expect from networking engineering frustrated when it does take a minute so alex you you mentioned the on-premises data centers can you kind of unpack a little bit more like who directly is the target audience for the netres product is it is it medium to large size companies and infrastructures that run their own data centers where maybe public cloud for whatever um operational or compliance reasons isn't the right fit and they need to do it on premises who's the target audience here uh great question um so from from one side public cloud kind of defined the new uh expectations in terms of user experience devops netops type of user experience but from another and and that's that's great that is you know helping humanity to move forward while public cloud is not one size fits all kind of solution for you know for some for some use cases it's just expensive it's prohibitively expensive for some use cases especially for late stage companies for early stage companies public cloud is amazing place early stage companies don't care about cost they they only care about being fast and innovating fast and engineering their products for for obtaining growth but for late stage companies uh cost efficiency is becoming important when these companies are preparing for ipo or or acquisition because there comes uh the econ economics of the company and they want some sometimes they see that geez we we have very high revenues but like high percentage of revenue is paid is you know is the cost of our infrastructure so for these companies it's a way to reduce the cost in order to increase their market capitalization that's just one case besides that there are there are cases where like applications are latency sensitive especially all kinds of vr and ai applications there and and that creates the the use case for for the edge right you want to move your workloads closer to to your users and that can be users driving on a freeway users working in a shopping mall that can be users in the park there's a lot of use cases there are applications that are crunching large amount of data like all kinds of machine learning applications and it is not economically viable to shuttle data from the source of the data all the way to public cloud we we all know how expensive is uh the traffic uh data transmission uh sometimes that's that's just legal compliancy type requirements some for some businesses that the data needs to be located in specific location or in specific country there are many use cases so my point here is cloud it provides this amazing experience of making infrastructure work immediately but we need this experience beyond the cloud we need this experience everywhere on-prem at the edge everywhere especially when using kubernetes and using other cloud native tools most of these cloud native application platforms and kubernetes especially they are created with the infrastructure that dynamically responds to the needs of your application stack for when you run kubernetes it's it's very common that your kubernetes cluster decide to scale to add more nodes and that means that your your vlans your load balancers your routing everything needs to automatically keep up with that it's you cannot do this manually because this kind of changes happen every hour and it's kind of common part of you know running kubernetes so we we call this type of audience cloud private cloud builders so they are either they either have our customers our users are either companies that that are building a greenfield infrastructure they are either repatriating the cloud or going hybrid so they want to replicate that cloud-like experience of you know automatic infrastructure operations that's because that is part of their business they are you know very devopsy type of organ organization like their business processes are very much tied into thinking about infrastructure like it is a cloud and it is easier for them to build their new infrastructure using cloud native technologies and and use netris for a networking part uh versus like trying to change all their you know development stack to like older stuff that's one use case and another use case is you know some of the users they just uh they just have traditional infrastructure and they are willing to launch a kubernetes cluster like a brownfield type situation where their traditional infrastructure keeps operating the way it was operating last 30 years and next to it they they built little uh cloud native cluster that is running netris that is uh and netris netris cluster in that case is interconnected with their you know traditional networking uh providing just so is that like a move from like legacy apps to like new apps is that kind of like what what they what they're doing there um yeah it's a it's effort by it teams to provide a foundation for for the company to start um moving from legacy ups to so it's like a migration process right yeah that's a really interesting approach because i can see that both as is a migration and kind of an augmentation whereas like like you said if there are traditional apps and traditional infrastructure that isn't going anywhere you're not forcing an organization to do a rip and replace to be able to support what netris can do to help scale with these new cloud-like apps on-premises they're able to migrate side-by-side or be able to run both infrastructures and and connect them together so that's that's really interesting is that is that pretty typical with what you see when when customers come to you saying hey we need to be able to scale for these these new age applications is it typically they start with new infrastructure in a separate cluster and use net trees to to manage and onboard and operate all of that equipment uh yeah we provide uh we we provide uh what we call a sandbox a test environment where netrus is pre-installed and it sandbox comes with a little kubernetes cluster and a few virtual machines and with upstream connections so users that are potentially interested in trying netris they they one way of use trying networks is that using sandbox they of course they can install uh on-prem but installing on-prem would require uh an environment if they have environment they are they are welcome to install netris locally that's that's free but if they don't have environment they they are welcome to use some of the environments that we provide dynamically on our website it's very easy just provide their name and email and we immediately send them credentials and they are ready to use that way they kind of learn and see if if netrace is a fit for their use case they validate their use case uh they're welcome to join our select community and you know learn from other users or our engineers and once they are they see the fit between their needs and netris and they are ready to to to to proceed with the implementation is just like you described they they they set up a little cluster that is running netris they they interconnect networks with their existing network if it's a brownfield scenario and without pressure one by one without stress they start moving whatever works make sense to move for some companies that's that's the migration process for some companies that's just part of plan some companies just want to be hybrid they want to keep their you know standard thing and they want to have their cloud native thing interleaving yeah i was going to ask do you do you foresee you know how we have uh hybrid cloud right and i feel like that is more companies that are would you say mature companies i guess i feel like that's more of a an option for those those type of companies whereas new companies you were saying uh jump on the cloud just off the gate kind of thing because it's wonderful for the speed and and being able to uh scale real quickly right um so i feel like the and i i come from one of those like uh mature companies right it it it's definitely a uh we have our legacy stuff you know and uh and so kind of looking at it like a like a hybrid cloud would this be like a hybrid cloud on-prem essentially but on a networking side of it uh yeah exactly and uh legacy applications gonna be around for for a while and there's there's no problem with that uh the the only thing is that even even large even large companies that that that happen to have this you know happen to have infrastructure for many years like 10 20 30 years at some point they they may want to have a private cloud not uh not uh not legacy private cloud but like cloud cloud so what makes cloud cloud is vpc because what makes cloud cloud is that is that function of providing infrastructure services immediately and that cannot work without bpc without without vpc every network product is uh operating with the with the switch ports or with some kind of network elements you know network we we we have seen this sdn thing right which which was meant to kind of make uh network engineers life easier and devops engineers life easier but it it it actually over complicated for both of them it didn't make any easier for devops engineer but it made things harder for a network engineer like for many for many good network engineers it's it's kind of hard to to figure out uh even simple things with with many sdn solutions that's that's why i think that kind of sdn didn't stick around and we we also have seen this you know uh automation and ibm intent based networking type of products those things are are making things better but but there comes this uh amplification the the amplifier factor you put their wrong things and they just amplify the wrong things and just now even bigger bigger stuff is is is blown up right uh in what is fundamentally different in public cloud is that uh cloud is self operating so opinionated you cannot kind of uh force clout to to change its kind of under the hood decision making process it's a higher level obstruction that's why it's it's kind of more stable in terms of human error but uh another important fun function is that uh the vpc that is running networking for the public cloud that that that is tightly connected and integrated with the compute uh compute systems like when you request your your bunch of virtual machines whatever system provides you that virtual machine environment that system communicates through api with the vpc and it makes networking work automatically like there's no middleman uh telling okay network please provide this this this ports into that service no that happens automatically the exchange of ip information happens automatically when your kubernetes cluster decides to scale and launch more uh more nodes again the networking underneath it keeps up with that change automatically that's what makes cloud cloud and even and that's why i'm saying even even a company with a huge infrastructure that was around for many years may not necessarily need to re rip off that old infrastructure but may need to have a cloud a cloud cloud private cloud and this is when they need a vpc provider like in a cloud scenario you pretty much you provide a subnet and then it does all the rest of like where who gets which ip you know you're not telling it hey you need to be on this vlan you're not doing any of that you're just saying i need this service and by the way i'm applying this security group uh to it and in within that security group i'm allowing these connections and then it just builds everything on the back end right so let's let's pivot a little bit on that because i think from my experience i sometimes obstructing that is a little bit of a turn off for me because it's then then i can't make the decisions and i can't do the tweaking and turning the the nerd knobs have you have you seen people like customers that get frustrated with that or or is it pretty much people are they they buy into the whole uh it's the cloud experience but in a network uh so that's that's that's a great question and uh we were we were very cautious about this uh during early days of you know planning and designing the product so there are knobs that that that kind of makes sense to touch and there are notes that we consider it's better to live to software uh knobs that are like things that are you know around how you implement things like how you organize default gateway on on subnet or how you organize your bgp timers between your switches or how you how you kind of uh organize your uh how you apply echoes to your bgp neighbors things like this are like those are not making any difference to 90 of businesses maybe there's 10 which is different kind of corner case that's fine but for for for the case where where the goal is to have a cloud native uh environment run a kubernetes cluster uh it's not critical how how exactly you you configure your bgp in this mode or that mode as long as uh the the the product that is making the decisions for you does things correctly now whatever we configure it's based on standard things we don't have anything to hide although users don't really need to ssh on on the switches and routers and you know make changes but they are welcome to go there and review what we've configured and when they review they are like huh this is this makes sense this mattress is configuring things right like i like that um rarely people don't agree with that and they come to us they come up with hey like this is not right and we're happy to hear that we need that feedback and there's a lot of places where we've improved the product based on feedback we're we love feedback we love learning together with the with the users because the users are they all are amazing engineers there's a lot to learn from them so i mean my main question i guess is um when the when the dev team is telling us that their application is slow do i have a knob where i can speed her up well uh actually yes uh pretty much so look when when things are configured uh automatically by a single algorithm not by five different algorithms by just one algorithm there's there's almost no room for conflicts so that that helps a lot with with that approach you you avoid a lot of issues that's one but still there are places where uh where we need uh you know human to to turn that knobs and for example when it comes to peering with your upstream provider like you you you still if if you're doing that if you're in that situation that you don't have your you know legacy network and you are connecting your netris cluster directly to upstream provider internet exchange plans you're you're receiving this full routing table things like that there's there's still a lot to do like you as a network engineer you have a lot to do there in terms of defining your strategy you know doing your trace routes your traffic engineering you know playing with the with the bgp communities to like re-engineer your your traffic that's still around we provide you with a good you know tools and a place to like turn a lot of knobs in in places where it makes sense but on the handoff side to your devops engineer like your your devops engineer not gonna ping you when they need a new a new vip a new vip for load balancer or are they not going to ping you when they deploy a new kubernetes cluster because you have configured things insanely great for the devops engineer and they are just happy to use their network i'm very much a traditional network engineer and i'm starting you know to come around on on the aspect of abstraction orchestration and automation but i'm going to get into the weeds with you a little bit um from a netri's perspective do you have when you're working with customers do you have high level guidelines for hardware choices of when they go to implement or high level uh topologies that they're leveraging in a data center what what do those aspects look like so we we do a lot of testing uh on on the hardware and uh our architecture so we want to make sure that uh when users deploy things things will work we we pay a lot of attention to to customers success and uh currently netris supports a few open networking operating systems that's in terms of on switch side so we support cumulus linux we support just pure ubuntu linux with the switchdev driver and we support sonic so whatever hardware can run any of these three operating systems that's supported theoretically but on top of that we do a lot of testing and we have there's list of hardware that we have validated that we say we we have run like thousands of tests on on this this and these models uh you're welcome to use others we will we will still support you but like this is the hardware that went through test testing and over time we will keep adding more and more hardware and the the part that runs on the hardware will will go open source eventually and uh hardware vendors will be able to adapt to new models that they have and so the the goal is to support more hardware eventually but today the goal is support to sufficient amount of hardware that our users will be able to to put together clusters that are stable super stable stability is critically important so that's on on the switching side layer two layer three switching uh on on higher l layers for routing for for border routing for load balancing for network address translation for your vpn those are functions that you still need in your private cloud but your switches cannot cannot do this right so what we have we have we have developed a data plane uh for linux that is using dpdk acceleration and smartening capabilities so basically our users they they take a linux machine uh with a couple of cpus with a lot of ram uh they install a smartnik card on that 100 gig smartnic card they load netrace and just just regular linux and that machine just just using you know open source standard tools uh runs the border routing functionality with the it can handle full routing table a ton and forward packets 100 gigs per second it does your network address translation source not destination not it learns sessions when it makes sense it doesn't learn sessions when it doesn't make sense it has that that kind of understanding and all that that adds layer of you know optimization uh it does your layer 4 load balancing uh and and side to side vpn all is based on standard open source tools and everything is configured by my netris automatically so switches together with that linux machine which we call softgate like a software gateway switches together with softgate and controlled by netris all together provide that vpc type cloud like you know functionality so let me ask this um currently when you go with vin you know like cisco or juniper or any of those kind of vendors right um you buy the hardware and obviously it comes with their software on it right and and and so i think one thing that i have to think about differently is and correct me if i'm wrong but with your product i would have to go out and get whichever switch that i need and i have now a service or a service agreement with which x vendor that i got that that switch from but if i have issues with the hardware i'm not calling netry's right i'm calling whatever that vendor is and then netres is more of the software that i'm putting on top of those those switches right netris is a software that you put on top of the switches there's a switch there's the operating system of the switch and on top of operating system is netris netrus configures the operating system uh in terms of support and troubleshooting if if something goes wrong sometimes it's it's hard to tell immediately where where the where the problem problem is so when whenever you whenever you bootstrap your network with netris uh we we push our agent we we do the the the minimal configuration so we start showing you the heartbeat from every network device and we automatically uh start monitoring the device for for like standard things like like your power supplies your fans your temperature sensors your like cpu load load on your ports laser signals we try to pull out all the necessary information for monitoring all the information that every network engineer would normally like to pull out but we do this automatically so you don't need to kind of worry about how how do i pull that information we just pull that information and show you on the dashboard and if you have a hardware issue of oftentimes that information on our dashboard helps you like we may say hey there's a temperature issue and the fan is is not spinning like that's that's a signal for you that that you need to replace your fan that's that's easier that's that's the easy case right when when we can show a hardware issue through our monitoring sometimes there's a problem we're like hard to tell like you don't know if it's a it's a naturist bug it's an operating system bug it's a routing bug or it's a hardware failure hard to tell so we we kind of uh feel responsible for um for the whole operation and the way we approach to this is this if you have any issue you first reach out to netris because our algorithm has configured your network we we are kind of the best help to to help to troubleshoot this down and and when you collect uh net net risk tech info from your network that collects not only netrus data but also data about your operating system about your hardware and based on analysis of this data we can tell like hey for example there's a hardware issue you you may want to replace your hardware and oftentimes your your hardware is just is from one of our partners and telling partner that these guys from netrex are saying it's because of hardware they have already validated that's that's even sometimes even kind of helpful or if it's an operating system issue we can we can we may tell you like hey there's a problem with the open source component that is part of your whole system here's a workaround take this workaround so your your business that doesn't suffer but we're gonna go back and we're gonna work with the you know with fixing that problem we may we may we may end up working with engineers of partner or if it's an open source thing we may fix that and contribute back to upstream to to the community open source so so basically um it's not going to be a bunch of finger pointing rate now we we we want to be a friend of network engineers no we we're here to uh this is created by network engineers we we want to help network engineers keep staying insanely great keeping up with the progress of the world keeping insanely great i like that i've been calling dan that for for a long time now so alex we we are getting towards the end of our time here is there anything more that you want to delve into that that we haven't touched on yet um yeah take you to thinking i think you you you you did amazing uh job uh and uh i i just enjoyed uh this this whole conversation it just just came like like a casual conversation like at some point i even felt like we're sitting in a bar just three you know net network engineering deals just that that is excellent to hear because that is dan's vision of this show in a nutshell so exactly so we we really appreciate this time alex um where can we point uh people that want to learn more about netres our website netris.ai our documentation is published there uh it's open uh for everyone there's a video demos that that people can watch we have this like uh communities like channel everyone are welcome to join ours lake not just users but like it's a place where where we speak about infrastructure like people are people are welcome to join um twitter uh is is a place where where we share updates uh twitter and linkedin but more twitter yeah we can definitely put those in the show notes well thank you very much alex for your time on this episode of the art of network engineering if you want to learn more about net trees check out netris ai sorry netris.ai and we will see you next time on the art of network engineering take care now hey everyone this is aj if you like what you heard today then make sure you subscribe to our podcast and your favorite podcatcher smash that bell icon to get notified of all of our future episodes also follow us on twitter and instagram we are at art of netench that's art of n-e-t-e-n-g you can also find us on the web at artofnetworkengineering.com where we post all of our show notes you can read blog articles from the co-hosts and guests and also a lot more news and info from the networking world thanks for listening you