Go Networking with Sneha Inguva

Automatic TRANSCRIPT

Guba. Welcome to software engineering daily. Thank you thank you for having me here have been a huge fan for a while so. I'm super excited and humbled to be on the show right. Well happy to have you on you work at Digital Ocean which is a cloud provider. Give me a few examples of engineering problems that you've worked on so digital ocean. We are cloud hosting provider. We have a variety of products in different areas for example with storage with networking as well as compute. Which is probably. I guess what most people are familiar with who used digital ocean we have droplets serve virtual machines that they can use but the interesting thing as cloud hosting providers that it's a little different from other companies in which in that we have both physical hardware issues we also have software issues and then we also have a web application so we've had interesting problems kind of all over the place when I joined the company. I wasn't actually network engineer. I was working on. One of the internal delivery. Teens is what we call the and on that team the biggest problem we were addressing was the difficulty in deploying and updating applications so namely working with Kubrick so that was definitely an interesting problem because I think we addressed. Both you know the challenge in building an abstraction layer on top of Kuban as that increased the just ease of deploying because before that people use chef chef was a little complicated in general and then on top of that also getting buy in from different teams to kind of use this new internal tool that we had so that would. That's kind of one of the problems we've had that we've addressed as you've mentioned digital ocean is built around these abstractions called droplets. Can you say much about what droplet is? Is it a VM? Is it a container? What am I actually interfacing with? When I spin up a digital ocean instance of course so it is a virtual machine. I think droplet just our marketing speak for everything oceanic themed in our company but it is essentially a virtual machine that is I guess. Technically Co located on servers with other virtual machines and you can spin up really in any location around the world. I think we have about thirteen data centers. So that super fine I I also heard you mentioned container so right now. We don't have containers as a service but we have coober. Netties is a service so technically speaking you could manage your containers as well although droplet itself is just a ritual machine. Got It now when you join a company. It's always tricky to find the bounds of what you should learn. And what you should know. R- it's hard to know just how deep to go and I know that when one of these virtual machines spun up. There's a ton of stuff that is going on under the hood. What was your process for figuring out what to learn the the life cycle of a user spinning up a VM. That's a really good point. In fact I think I think we still do this. When someone we have a for networking at least we have a really good on boarding process. Or when I joined the company not a networking we also had still had a pretty good on boarding process but it was more generic and there is in fact I guess. An on boarding session called how. The cloud works where an engineer who's been at the company for a while actually goes through the entire process and kind of goes through all the micro services that I guess receive a request and send a response. You know down to the schedulers that actually are scheduling the droplet placement on a particular hyper visor. Down to everything. So the thing is I think most people probably have a general idea of the different services that are being touched but then when it comes down to the nitty gritty of how exactly he's Networking Setup Hauser. Sdn configured all of that. I don't think unless you're on that specific team. You are aware so. It's it's kind of a t shaped process in a way so you have a general like breath of knowledge of how I guess the cloud works quote unquote but when it comes to the nitty gritty details. You probably have a very good idea of just your specific area. And I think it's impossible to have a very deep knowledge of absolutely every single service when you're at a company this large with this many micro services and with this many domains of expertise totally now. The reason I want to have you on the show is because I saw some talks. The you gave one specific talk about networking and the term networking can mean a lot of different things. But I know that now working at a cloud provider and you being a systems engineer working at a cloud provider. You probably have some insights on the engineering that goes into the actual nitty gritty of something spending up within digital ocean. What does networking mean at a cloud provider? What does that term networking so networking at a cloud provider? I think has two layers. There's of course the physical infrastructure that is set up so of course I think every cloud provider has physical switches physical address physical gateway so that is definitely one layer but then another thing that you have to consider especially at a cloud provider where you are dynamically. Creating and deleting virtual machines is that you are constantly adding different paths for networking packets traverse and removing them as well. So that's where software defined networking comes in and that's a completely different layer that you have to consider especially at a cloud provider and in fact at digital ocean. We actually have a team that deals with a lot of the physical details when it comes to physical switches in our data centers but we also have a SDN team which has a lot of sub teams that deal with a lot of the micro services that are interfacing and communicating with obvious open switch which is our virtual switch of choice that are actually making a lot of our networking products. Possible such as you know such as VP see or firewalls or even DHCP. A lot of these different things about some of the lower level networking concepts that you needed to know to build some of the projects that you've built within digital ocean. Of course so I'll just take you through. I guess when I first joined the networking team we were coming out with a product called. Bring Your own image so previously when people typically spin up a virtual machine or droplet they can select predefined image whether it's a boon to or I don't think we have Microsoft but a different version of a boon to or one of many different options however with Byu Hawaii we started giving them the option of bringing their own image. So the only issue with that is when we control the image ourselves. We can kind of control the cloud configuration meaning allocating IP addresses and setting up a lot of configuration. But when they're bringing their own image we need a way to dynamically allocate Ip addresses for those droplets using that image and that's where the DHCP protocol came in. And that was something that I had heard of. But I wasn't super familiar with but in general I guess whenever you're building a new networking product. That's using a new protocol my first step typically is to read the RMC so I pulled up the DHCP are of C and then the DHCP C. Which is a little different and started to learn about the protocol and I guess most people at home are probably familiar with it when they log into their computer and they fire up the Internet their ISP Rod are actually allocates Ip address for their home computer and so that's essentially using the DHCP protocol so we were implementing our own. I guess a hyper visor level demon to do that for different droplets in our data center and so that was something that I started to learn about. And then the other thing. When you're a cloud hosting provider is you start to learn about perhaps the ways in which you might have abusive actors and kind of look into security and so that was very interesting and then you you start to do a lot of load testing and try to figure out how to mitigate any possible issues so that was also something else. I started to look into when it came to the server that phrase you mentioned. Rfc reading the RFC. I've read some core answers and wikipedia recommendations about you WANNA learn networking concepts you should read the RFC which chance for the request for comments. Why is that the best path to learning about networking protocols? I mean that is fundamentally where the networking protocols were designed and some of these protocols redesigned like decades ago so I think that of course you could read wikipedia articles encyclopedia articles youtube videos. All of those are helpful. But I think that going to kind of the original source of where this communication protocol was defined. And of course to be honest the first time you read through any networking RFC. It won't one hundred percent make sense so obviously going through it marking up everything you don't understand which then and then of course every RC is somehow linked Tillich twenty other RC's so then go jumping to another RFC to kind of understand. Maybe another protocol that is used within a particular protocol kind of helps you build sorta like in a mental map or like a mental knowledge tree of what that protocol actually does what it

Coming up next