Welcome to Day Two Cloud. You know how when you create a VPC in the cloud, it’s a pretty simple thing? A few dropdowns and clicks, and you’re there. Not a bunch of nerd knobs and questions you’re not sure how to answer. What if you could bring that DevOps-friendly, easy-to-use experience on premises? That is, make your local network as easy for a DevOps-minded human to consume as a public cloud VPC?
Our sponsor today is Netris, and they promise to deliver a cloud-like experience for running your physical network. Our guest is Alex Saroyan, and he’s the CEO and Founder of Netris.
We discuss:
- How Netris provisions networking on premises
- Building a VPC-like experience that network engineers control and DevOps teams hook into
- How Netris differs from other platforms
- Network hardware and software it works with
- Terraform and Kubernetes integration
- More
Show Links:
Try Netris – Netris.ai
Netris Documentation – Netris.ai
@alex_saroyan – Alex Saroyan on Twitter
Transcript:
Please note this transcript is provided as-is without error corrections.
[00:00:04.390] – EthanWelcome to Day Two Cloud. You know how when you create a VPC in the cloud, it’s a pretty simple thing. A few dropdowns and clicks and you’re there not a bunch of nerd knobs and questions you’re not sure how to answer. What if you could bring that devopsfriendly, easy to use experience onpremises that is make your local network as easy for a DevOps minded human to consume as a public cloud VPC? Our sponsor Day is Netris, and they are delivering exactly this experience. And our guest is Alex Saroyan, and he’s the CEO and founder of Netris. Alex, welcome to the show. If you would give our engineering audience the 10,000 foot view of Netris, just a few sentences describe what Netris is all about. [00:00:48.170] – Alex
Hi, Ethan. Hi, Ned. Hi, everyone. Thanks for having me on the show. Very excited to be on one of my favorite shows in the industry. I’m a former network engineer. Like many of you guys, I started from configuring Cisco devices, network devices, using conft and storing IP information in spreadsheets. And then over time, I’ve learned programming, started to try automation, then embrace Sdn and APIs over the time. But cloud kind of changed the way we think about infrastructure. In terms of in public cloud, infrastructure services are kind of self service. So you like Ethan described really well in public cloud, you just developers, DevOps engineers, networks engineers, infrastructure engineers, they just go to public cloud. They create a VPC, they throw a bunch of EC, two instances or Kubernetes cluster applications, they throw all that into the VPC and it’s ready to work. Now, when we think about on premises or when we think about a bunch of metal serverless somewhere in a data center, the experience shouldn’t be any different. Should be the same. And thinking of networking, what we have to provide that experience and we can’t provide that experience with the CLI’s and automation. [00:02:22.910] – Alex
No, industry wise, we have seen software defined networking. But like, can DevOps engineers self service through service? Software defined networking or through even intent based networking? That’s not I was afraid to let DevOps engineers go and self service using any of these platforms. So what DevOps engineers need, they need exactly the VPC, something which takes understands applications, can talk with the compute platforms and behind the scenes can provide the networking. So what Netris is network is a software that is purpose built to automatically run networking and provide users with a cloud like user experience. So our users can use Terraform, can use very simple web console, and feel like they are using public cloud, but on premises or in their own environment. [00:03:28.070] – Ethan
So you mentioned software defined networking along the way, Alex. So would you say Netris is software defined networking, or would it be intent based networking? Or maybe it’s neither of those. Really. [00:03:39.210] – Alex
Neither of those. I mean, software defined networking and intent based networking. These two technologies, they exist for a reason. They are really good for servicing traditional data centers, for servicing telcos and Internet providers, but not for cloud native use cases. Because the key thing is that in cloud native environments, DevOps engineers, they need to sell service. They need to be able to request network resources immediately, not ask a network engineer to create something, not ask a human to configure something, but to get their load balancer up and running immediately, get their VPN connection up and running immediately. That’s kind of the key difference between key requirements that cloud native situations bring in. [00:04:38.350] – Ethan
So it feels like the network is more about the consumption model. Is that the right way to categorize it? [00:04:44.460] – Alex
Yeah. Consumption self service. [00:04:47.390] – Ned
Now, there’s already tools out there that exist from the major network vendors that would allow for some level of network provisioning. I mean, Juniper, Cisco, Arista, they all have some tool out there to manage networking. What is different specifically about networks versus these other network provisioning tools? [00:05:06.360] – Alex
That’s a good question. So let’s break this down into I like to think about this in few types of tools that you’ve mentioned. There is one category where network vendors, they would kind of map device by device configuration into Terraform, kind of like one to one thing, which is kind of you still do the same but using different tools. So they changed the tool, but they don’t change the amount of input that the user needs to provide to get things working. And there’s this other category which is Sdn and intent based networking like Juniper has this product called Abstract, which is a good example of intent based networking or Cisco has Cisco ACI Sdn example. Again, all these things, if we think about it from NetOps engineer perspective and DevOps engineer perspective, how easy or hard it is for Netops engineer to use manage operate this product and how easy and hard it is for DevOps engineer to consume services that these products create. Vendor provided Terraform type configuration or vendor provided intent based networking or Sdn type configurations. Those are really good for network engineers. They make things better for network engineers, but they don’t contribute much to DevOps experience. [00:06:35.240] – Alex
There is nothing that DevOps engineers can use immediately without going through kind of specialized network engineering type learning what network engineers want. They know how to use AWS, right? They know how to use Google Cloud and VPC experience in these two. And actually all cloud providers is pretty much the same. They just want to replicate the same experience. And it is up to network engineers to provide that experience. Because for us network engineers, DevOps engineer is like our customer. They need that experience. And we need to kind of take their requirements, what they need, what device engineers need, and kind of engineer it back to technology to provide them what they need, what they want. And we need tools for this. And we can do this with traditional tools that’s why we have created Netris. [00:07:35.750] – Ned
Okay, that makes sense. The Net Ops is responsible for providing sort of an abstraction layer to the DevOps persona. And you’ve mentioned these two personas a few times, the Net Ops person and the DevOps person. Where does the line of responsibility or the scope of responsibility lay for those two different roles? What is the Net Ops responsible for and what is the DevOps responsible for. [00:08:00.380] – Alex
In cloud native situation, which can be a little different from traditional data center doing this on premises, right? Not specifically in public cloud, because it’s a little different in public cloud. Some functions are handled by the cloud provider. Like cloud provider takes care of your hardware, your switches and routers. They do exist, but they are hidden somewhere under the hood of cloud provider. When you do this onprem your network, engineers are responsible for this network. Engineers still need to decide which hardware to buy, how to connect them, how to configure them, what to run on top of this hardware, how to connect with the upstream providers, how to connect with the carriers, how to connect with ISPs this is part of the male engineers responsibilities that are kind of similar to traditional data center. But the key difference is that whatever they do on plan, it needs to be done in a way that DevOps engineers will be able to consume in similar ways that they consume in public cloud. So kind of DevOps engineers need to provide with this user experience, cloud like VPC like user experience that DevOps engineers will consume. So whatever technology they are using to manage their switches and routers and load balancers and the whole network, that technology needs to be ideally fundamentally created providing this experience. [00:09:33.950] – Ethan
So would you say then the Net Ops team probably installs Netris and maybe builds some sort of a service catalog that then the DevOps folks are going to consume? Or would the DevOps team actually be buying and installing metrics? [00:09:47.120] – Alex
So most of our customers, they are either born in cloud and they are on the way to go hybrid and they are building their private infrastructure. So these Azure, usually startups or former startups, cloud born and grown up, or those are large enterprises, like government type enterprises that have large, large network. And they’re not going to rip off their network. No, they just need a little cloud native island in their enterprise network. In both cases, the idea is that they are building some kind of new piece of network or some new data center. And in both cases, it usually starts with the planning by network engineers. So they go to whiteboard, they draw their topology, they probably have some IP addresses. They may need to kind of pull that spreadsheets of IP addresses to kind of picture what they have and what they are trying to achieve. Then they order hardware, they prepare the rack. Maybe they are renting a colossal space. They get power, they get cooling. And even before they reckon stake hardware, the first thing that they need to do is to reckon stake. One server, one unit server for Netris controller. [00:11:06.370] – Alex
So network engineers and NetOp, they install Netris controller which is very easy, just one liner command. They copy and paste preinstalled Linux system. It brings up networks controller and then they connect a management internet connection to networks controller so they can access it. And then they need to translate the drawing on the whiteboard so the topology that they are planning to put together, they need to translate that information into networks. We have this easy tool where they kind of drag and drop and kind of draw that topology. They need to copy and paste their IP information from spreadsheet into Netris. And now when NETRIS knows your IP addresses and your topology, your data center person can look into Netris and connect switches the way it is described on Netris. When it’s connected, the operating system can be installed on the switches. Networks agent will communicate with controller and will generate configuration on the switches. There is no need to kind of touch and change configuration of the switches by network engineers. It’s all done by Netris agent. So network engineers job is to get that switch fabric up and running, get network soft gate notes which are Linux machines with the DPDK acceleration that do load balancing border gateway functionality. [00:12:42.390] – Alex
They do network address translation functionality, they do VPC. So network engineers get the switch fabric. They plug in a couple of soft gate nodes, just the machines for network functions. And when that is done they plug into either directly into upstream providers. Network can take full routing table and terminate upstream providers or internet exchanges locally. Or if they are building a little island AWS a part of enterprise plug into that enterprise network. Either way works. Now when that part is done, network engineers main job is done. Network engineer then can delegate network resources to infrastructure Ops and DevOps. So network engineer will go to IPAM and will say these blocks of IP addresses I’m delegating to my infrastructure Ops, to my DevOps engineers, they can do whatever they want. These other blocks are reserved for network. No one can touch them. Same for switch ports, they go to switch ports. They say this amount of ports on all switches are delegated to develop engineers. They can do whatever they want that way. Network engineers kind of safely delegate control over the network to infrastructure Ops and DevOps people. Now when Infrast and DevOps people, they log into Netris console, they’re going to see a lot less nodes. [00:14:26.870] – Alex
They’re not going to see network topologies, they’re not going to see upstreams. They’re going to see only things that are relevant to them. Very similar to VPC in public cloud. In their view, it will be a system that magically has internet connection and they only need to create a new thing, new VPC, new virtual network, and plug their application platforms. [00:14:53.750] – Ned
Okay, so I think I have a pretty firm idea of where the separation lies between what DevOps is doing and the DevOps and infrastructure Ops folks are doing. And that really they’re setting up all the network in the background and then providing this abstraction and sort of guardrails around what the DevOps folks can do. Now I want to back up to the part where you racked and stacked hardware, because that’s probably a pretty important part. There’s a lot of different networking hardware vendors out there and different software network operating systems. I’m curious, what platforms does the network solution currently support for the physical switches. [00:15:31.140] – Alex
We currently support open networking switches. So switches. That can run Cumulus. That can run Sonic. That can run just Ubuntu Linux with the switch Dev driver for a soft gate. It’s just a Linux machine with a smart NIC card. We currently support Ubuntu Linux. At this stage, we are not super focused on supporting more hardware platforms because our main focus is user experience, but on the hardware. We are using standard networking constructs. Things that Netris agent configures is just BGP VXLAN VPC. We don’t use anything proprietary. Everything is standard. Everything is open. So basically, whenever timing is right and business reasons are right, we can relatively easily integrate with other switch vendors. That’s fine. But even more, we can integrate with the switch fabric vendors. And what I mean by that is like in some data centers. Let’s take a Equinix metal as an example. They have this fabric that they provide to their customers. Like as a Linux Metal customer, you can request physical servers and they have API and console where you can request Equinix to provision you a layer two networking. Now, this is not a VPC, but it’s a layer to networking. And for us Netris, that is a fabric. [00:17:02.300] – Alex
It’s like one large switch, like a switch fabric. So we don’t necessarily need a switch. We can use something like Equinix fabric too. So networks user in Equinix environment would just install Netris softgate on one of Equinix provided machines and would use Equinix fabric as a layer to kind of provider. [00:17:25.590] – Ned
Yeah. Actually, I’ve used the Equinix metal platform to do a few different projects, and the networking constructs they provide to you are fairly primitive. You said it’s down at layer two, and then on top of that, I was able to install software defined networking solution. In this case, it was VMware, so it was their NSX product. But the fact that they gave me access to that lower primitives, let me do that. It sounds like same thing with Netris. If I wanted to consume Equinix metal and then provide that DevOps experience to the folks in my organization, I could build it on that. [00:17:58.760] – Alex
Yeah. And to your point, that’s actually a very good example. You can use some kind of layer two fabrics, something that provides layer two and you can bring in VMware, NSG, for example, VMware and SX makes a lot of things easier, but it’s still not a VPC experience for the engineer. Yeah, because if you run multiple platforms, how do you network these platforms together? If you run multiple locations, multiple regions, how do you connect these multiple regions together? Let’s say you run VMware cluster and you run Linux cluster, you run range or cluster. How do you control access between these different networks? And there are no easy ways for doing this. Of course, you can engineer things, you can install Linux router. You can always create kind of custom engineering. That’s always possible. But when we are speaking about DevOps experience, when we are saying network engineers need to provide this experience to develop, they understand VPC and VMware and NSX is not VPC. [00:19:11.280] – Ned
So if I’m bringing Netris into my environment and I want to use it as part of my infrastructure as code stack, would I use Netris as a replacement for something I might be using today? Like if I’m using Terraform today, am I going to replace that with Netris or is there some other format I’m using to configure my networking gear, like at the physical or the layer two level? What am I using to actually push configs out to switches and routers? [00:19:36.270] – Alex
So the way it works, little software agent runs on switches and Netris soft gate routers. The agent does the configuration, how people tell networks what to configure. So all the interaction by networks engineers and by DevOps engineers, all interaction happens between human and Netris controller. So Netris controller has web console similar to public cloud. But Besides, you can also configure networks using Terraform. We have Terraform provider and our Terraform provider is different from traditional network vendor provider, because traditional network vendors, they would map networking detailed specific networking constructs like VXLAN, like Port configurations, like protocols to Terraform. We call it like a one to one mapping in Netris Terraform provider. It’s not like that. It’s more like in public cloud. You configure abstraction through Terraform. You describe your abstraction, you say, hey, if you’re a DevOps engineer and you can either use web console or Terraform and those are equal, it’s just different user interfaces. We think about Terraform as a user interface. Like your browser is user interface and your Terraform is user interface and they are equal and DevOps engineer, they can say, hey, I want a load balancer to send traffic to these five backend IP addresses and the request that using Terraform and Netris will find what is the next available public IP address. [00:21:23.690] – Alex
We’ll assign you with the public IP address and we’ll see what’s the possibility to organize a load balancer so networks will see, okay, I have these two sodgate notes. Let me configure load balancer instances on this sodgate notes. Or if you’re a network engineer and let’s say you deal with a lot of switches and a lot of links and it’s like hard to kind of drag and drop and describe this many links on the GUI, network engineers also can use Terraform. It’s an amazing tool. And because in Netris controller, everything are just simple objects. This is podcast. I cannot show this, but I will describe in words. So there is a situation where network engineer needs to provision like a large leaf spine fabric and they need to describe like hundreds of links. This part of the switch is connected to that part of that switch and there’s hundreds, they are very much symmetric, but there’s a lot. And in Terraform you can use cycles and you can describe in a cycle. You can say hey, connect every 15th Port for example, or 53rd Port of the switch with the first Port and second Port and third part. [00:22:51.470] – Alex
And in Terraform, it’s like five, six lines of Terraform code. But that actually creates hundreds of links. In Netris, you apply the Terraform file and in hundreds of links showing on your topology diagram. And behind the scenes, Netris will do thousands of lines of configuration on all the switches. Because Netris has this logic how to translate that high level abstraction into actual BGP configurations and protocols and all these low level things. [00:23:30.550] – Ethan
So Alex, since there’s a Terraform provider, I’m assuming that means Netris has some kind of a robust API sitting back there. Could I interact with the API directly? And if I can, do you have customers that are doing that? [00:23:43.660] – Alex
Our controller is kind of API first type development. So our GUI Terraform provider, and we also have this Kubernetes operator, all these integrations that are using our Rest API, and we have some customers that are building some products and they want to embed networks as a part of their product. And those type of customers, they use our Rest API for embedding networks into their product. So if you’re embedding, you most probably won’t want to use our Rest API. If you’re in a NetOps DevOps situation, you probably want to use a mix of Terraform provider and web console and those things don’t conflict with each other. You can do something, there is no problem of source of truth. You can start with somewhere and continue in other place without breaking things. And if companies into Kubernetes, they can use our Kubernetes operator. So that way Netris understands standard Kubernetes constructs. [00:24:56.070] – Ned
Okay. And if I’m interacting with the API or I’m logging into the web portal, et cetera, I’m assuming there’s some sort of authentication process. So what do you integrate with to support authentication for Netris we have this. [00:25:11.230] – Alex
Role based access control thing where you can create users, user groups, user roles, user permissions. So the idea is that for different users you can tell networks what parts, what functions of the product they can use. So practical use case for this is that let’s take the example of DevOps engineers. You as a network engineer who’s setting up networks controller. Who are the admin of networks controller. You want to give those engineers access into network controllers so they can control things that they care about. But you don’t want them to mess around with your switches, with your upstreams, with the very networking, networking things. So this is done through role based access control and tenants. So basically, you create a user role for DevOps and you say, hey, they can use VPC, they can use virtual networks, they can use load balancers, but they cannot use BGP upstream. They cannot use switch management, they can use network topology. And with that metrics, when those engineers log in, they see different views of the Web console. They don’t see networks, they don’t see routers, they see load balancers, they see virtual networks, only things that they care and they understand. [00:26:34.790] – Alex
So that’s kind of more of a standard role based access control. But on top of that, we have this concept of tenants, which allow us to map network resources to permissions. So basically, you have IP addresses and switch ports from network engineers perspective. And network engineer wants to safely delegate some part of IP addresses and switch ports to different groups of engineers. It can be DevOps, it can be in larger organization, it can be even multiple teams. Network engineers may want to say, hey, this by cat of IP addresses goes to this team, and that bike of IP addresses goes to that team. So they use rolebased access control and tenants for safely or delegating network resources to their internal users. [00:27:28.410] – Ned
Okay. So network supports like a multi tenant architecture, especially if I’m a service provider and I want to provide this experience out to different customers. They all have their own isolated tenant that they would go into, and they can’t step on each other’s toes, as it were. [00:27:44.850] – Alex
No. [00:27:46.410] – Ethan
So if I’m an Active Directory user in house, can I map my Netris RBAC configuration to Ad? [00:27:55.240] – Alex
Yeah, we support Active Directory. Some customers are using that. [00:27:59.540] – Ned
Okay. [00:28:00.170] – Ethan
All right, Alex, talk to me about pipelines. If I’m all demo infrastructure as code and I’ve got a provisioning, pipeline does not just fit into that. [00:28:08.400] – Alex
Yeah, absolutely. Both networks and DevOps, they both can use pipelines. We see that DevOps people tend to use pipelines more. So since we support every construct that we have can be described using Terraform. And actually, we even support configuration through Kubernetes CRDs custom resource definitions, too. So depending on what they prefer using Kubernetes or Terraform, they can create pipelines. And the idea is that most of the users are in hybrid situation. Right? They have not just on Prem, they also have something in public cloud, and it’s kind of mixed of public and private. So most probably they already have pipelines for deploying their applications and for deploying their infrastructure. And they can reuse that same pipelines. Like they can use Githubs, for example. And in GitHub, they can either use Terraform more common use case, or they can also use Kubernetes CRDs. If it’s a team very much into Kubernetes, they can use Kubernetes CRDs too. [00:29:18.160] – Ned
Okay, so if I already have a pipeline and I’m using it to provision my application in AWS, let’s say and I have a portion of my pipeline that provisions a VPC or grabs a subnet out of an existing VPC, all I really have to do is just switch out that portion of the code to look at the network presence I have in my data center and the rest of the application gets laid down the same, right? [00:29:44.270] – Alex
The part of your pipeline that is related to application, let’s say part of the pipeline that is working with Kubernetes and launching an application with the Kubernetes. Kubernetes API is standard. Every Kubernetes distribution in the world is the same. It’s standard. So that part you can have the same YAML that describes application. In public cloud, you can just use exactly the same with the networks. If your Kubernetes wants to request a load balancer, for example from the cloud environment, it works in public cloud. It also works in networks and there is no need to make any changes because those are standard Kubernetes constructs. So you just copy paste or use the same file. Now you mentioned application pipeline and VPC pipeline. Now VPC, there’s no standard for VPC VPC in different public cloud providers is very much the same. Very much similar. There’s no standard standard. So even between public clouds you need to make a little bit of changes like in the syntax or very tiny changes in the concept. Same here. It’s like your metrics operated private infrastructure. Your on Prem infrastructure is like another cloud. It will require slight changes, but it will not require DevOps Engineer to become network engineer. [00:31:19.720] – Alex
It will let both roles to be insanely awesome doing their jobs. [00:31:27.390] – Ned
I want to be insanely awesome. That’s good to me. You’ve mentioned Kubernetes a few times and the integration. I just want to dig a little deeper into that. What components are you talking about? When you mentioned the Kubernetes integration, one. [00:31:44.000] – Alex
Of the major things that you need to get Kubernetes running is this. How do you route traffic into your Kubernetes cluster? Because your Kubernetes notes and posts, they all have private IP addresses. You run, your containers, interact with each other that’s provided by Kubernetes. But how do I get public traffic entering my Kubernetes cluster and in public cloud? This is done through elastic load balancer service. And in Kubernetes you have service construct called type load balancer. So when you describe in your application that I wish I exposed my application to the world using type load balancer that is signal to Kubernetes. An elastic load balancer will be provided by the environment. Now Network operator provides a few things, including the very first and kind of minimal thing that you need to get your Kubernetes running on premises. That’s one as an essential thing. But Besides, we have integration with CNI Calico. Cni networking is transparent to us. It’s no different for us what CNI users are using. All CNIS are wonderful. Some CNIS, they require special care when you go for production, for scalable clusters. And that’s the case with Calico. When you use Calico in a default configuration, that’s fine. [00:33:15.820] – Alex
There’s nothing specific. But when you want to scale your cluster that is using Calico, Calico recommends to create BGP sessions between your physical network and your Kubernetes nodes. And you need to plan this. You need to maintain this, because in Kubernetes world, adding more nodes is a regular thing that happens every day, every hour, and it’s really hard to keep up with that large number of BGP sessions. So what we do there, our Kubernetes operator is watching Calico, is watching Netris. And when DevOps Engineer enables Netris turns that function on, Netris would learn IP addresses that Kubernetes is using will assign as numbers to both Kubernetes and networks and will organize all that BGP sessions between all your Kubernetes node and all your network switches. That way fulfilling the requirement of Calico. [00:34:22.830] – Ethan
Alex, a point of clarification. You were mentioning Calico, and it’s just a CNI and networks can consume whatever the CNI provider is. Does that mean you could consume all Calico primitives because that product keeps getting updated. I mean, I just read release notes for the latest thing, and I think they’re including now, like EVPN VXLAN over IPV, six is now supported. Does that mean Netris could consume that? Or is it more whatever the network based functionality is, is what I’m able to consume. [00:34:52.590] – Alex
We consume just part of primitives, those that have something to do with the physical network. So big part of CNI is that they create kind of overlay network over the physical network and they do their own thing in a private network. But that works great for small clusters and sometimes even with big clusters. But for large clusters, sometimes you want to pair your physical network with that CNI network. That’s one use case. Another use case is sometimes you want your other components like your Dev machines, like your virtual machines, to have access into a container network. That’s another reason when you want to peer your Kubernetes network with your physical network. So when for whatever reason, you need to get access into Pod network because you just want access or beat it because of scaling reasons, we consume standard primitives and make that integration just a one command thing versus like months of figuring out and implementation. [00:36:06.930] – Ethan
All right, Alex. Now, Netris is not just something that you’re hoping it’s going to work out. You actually have customers that are using the product. And you got some good stories here. So we’d like to close out the show here in a couple of those. And one you were telling us we were prepping the show there’s an ad tech company, as you put it, born in the public cloud, and they’ve become networks, consumers. Tell us about those folks. [00:36:28.170] – Alex
Yeah. So they started in public cloud. Just like many of these Silicon Valley startups and early days. It is incredibly important for companies to be in public cloud. Why? Because it enables them to improve fast, to engineer their product toward growth. Because no growth, no reason. Right. They engineer their company and product for the growth they get. Growing. They don’t care about overhead, they don’t care about cost, that’s kind of secondary. But when they get to adoption, when they know, okay, now our business is going. And now to get to next stage, we need to scale. And this is pretty much when they start caring about cost and efficiency. And they found that the cost of the cloud is becoming prohibitive for their business model. And their application is using AI, machine learning, very CPU cycle heavy, that’s one. Their application is very network heavy. Load of traffic exchange between their users and their application. And it’s latency sensitive. They cannot have just one data center. They need to have multicloud locations, so they need to take their applications closer to their users. But they were cloud born company. Their entire team was created around skills, mindsets of public cloud operations. [00:37:59.100] – Alex
When they decided to build their physical onprem data center, they’ve tried to go the traditional networking route with Cisco routers, Arista switches like traditional networking. And they found that, well, it’s doable, yes, but it’s going to require them to change some of the processes in their company. And that would make their DevOps deployment cycle slower. They don’t want to slow down their development, their delivery cycle. They want to kind of replicate the cloud experience, but on premises. And this was their reaction when they saw networks. They said, wow, this is just like the cloud. We all can do this. So they deployed networks in one location to give it a try. They use Nvidia switches, a lot of servers, like 201 unit servers that worked out. And then they decided to deploy in five data centers to get it closer to their customers. So now in these five data centers, altogether, they probably run around 3000 physical servers. In each data center, they have two sold gate nodes. So with this salt gate nodes, they handle the full routing table. Because I described that they are latency sensitive and they have a lot of traffic. [00:39:26.400] – Alex
So they want to have their own relations with upstream providers, with Internet exchanges. And they manage all that using Netris. They plug into managed switches and use Netris softgate for terminating all that BGP traffic. They are using load balancers. They are using network address translation and VPNs that we provide through our soft kit and VPC functionalities. [00:39:55.000] – Ned
Oh, okay. Well, let’s turn to the polar opposite of a Silicon Valley startup, ad tech company, a government agency. You also mentioned the government agency is one of your customers. So can you tell us a little bit about that scenario? [00:40:07.990] – Alex
Yeah, that’s also a cool case. So for them, not a start up. Like your point, they have their large enterprise network and they are not going to change this large enterprise network anytime soon. But what they needed, they needed little cluster for one particular project and they wanted that cluster to be kind of easy to operate, easy to change with a cloud like experience. So kind of like a little cloud native island. This is what they needed to do. They don’t connect up streams or Internet exchanges into this cluster. No, because their policies doesn’t allow a single project to communicate with the public Internet. No, but what they do, they have switches managed by Netris agents, they have Netris Soft gates, and they peer sold gates with their existing network. So their existing network is kind of providing upstream connectivity to this cloud native cluster running networks. So from Netris experience perspective, it’s just the same, but it also fits the security policy requirements of their organization. They are consuming their internal secured Internet, which is kind of behind their internal firewall. [00:41:31.070] – Ethan
So, Alex, both good stories. It’s really cool to hear when you have a new product that’s out there. But you got major customers that are consuming this thing in a major way. Thousands of servers and ports that you’re dealing with and consuming it in the DevOps way. Very fashionable. So if people listening to day two cloud want to try Netris, Alex, where would you send them? [00:41:56.130] – Alex
There are two ways to try Netris. One way, if you have hardware, if you want to set up an environment, you can download Netris for free and install it and try it out. If you want to try Netris, but you don’t want to put together an environment, we are happy to provide a sandbox environment for you to use in sandbox environments. There’s six switches to soft gate routers and about ten Linux servers and Kubernetes cluster. Everything preinstalled and created for you to start testing immediately without overhead. You can go to Netris dot ai. Try and you’ll find more about these two trial options there. For packet pusher listeners, we have created a landing page, Netris dot AI PacketPushers. You’re welcome. Please check it out. [00:42:56.400] – Ethan
And your documentation is also public. So, I mean, if people want to get a taste, they can just go poke around the networks. Documentation. [00:43:02.450] – Alex
Yeah, absolutely. Netris dot ai docs. [00:43:06.580] – Ethan
Now, Alex, if people want to harass you, I mean ask you questions on the Internet about Netris or anything else networking and cloud related. Are you out there on Twitter? You got a blog LinkedIn anyway that people can get in touch with you? [00:43:19.010] – Alex
I’m active on Twitter. My handle is Alex underscore Sayoran. I’m on Twitter too. And also we have our Slack community where our users, potential users, and our engineers, developers, they all are on the slack community. Sometimes we’re having some interesting cool guests there cool conversations. So you’re welcome to join our select community. [00:43:42.380] – Ethan
Very good. Thank you, Alex, for joining us today on day two cloud and thank you for sponsoring today’s day two cloud episode. That is how Ned and I feed our families. So we do appreciate it when sponsors come on board and if you’re here still listening out, there virtual high fives to you for tuning in. If you ring up Netris to find out more or to queue up a proof of concept test with that Netris dot AI try let them know you heard about it on day two cloud part of the packet pushers podcast network. And if you have suggestions for future shows, either vendors you want us to talk to or explore open source projects you want to know more about anything cloudy you’d like us to talk about tweet at day two cloud show or if you’re not a Twitter person, fill out the form of Ned’s fancy website nedinthecloud.com and until then, just remember cloud is what happens while it is making other plans.
Podcast: Play in new window | Download
