EPISODE · Dec 19, 2022 · 19 MIN
[Tech] Separation of Control vs Data Planes - Steve Yegge
from The Swyx Mixtape · host Swyx
Listen to Stevey's podcast: https://youtubetranscript.com/?v=Wi8SL-Tot-8&t=1212Transcriptso let me tell you about service mesheskind of like the terminology just to geteverybody up to speed because i knowsome of you haven't looked at this spaceor haven't looked at it recentlyyou're going to hear two terms controlplane and data plane bandied about a lotand it's very confusing at first okaybecause first of all they are sort ofpoorly named and second of all there isactually a fair amount of overlapbetween the two in the in the serviceofferings that we have today all rightand in the tech stacks that we haveavailable so let me walk you throughthem all rightso starting at the uh at the servicelevel so you have a bunch of servicesmaybe they're on vms maybe they're inkubernetes maybe they're in nomad orfargate or whatever right but you've gotservices vms or containers and you wantto have them communicate with each otherall rightwell having rather than having them allcommunicate with each otherwhich obviously means you're going tohave to build like service discoverylogic into the service itselfso if i have a player servicelet's say i have a game server and itwants to go call the player service andsay is this player real okay if so giveme their give me their information giveme their credentials okay typicalservice to service uh you know functioncall rpcall right well you could have the gameserver say well i'm going to call theservice registry service to see uh wherethe player service lives and then i'llmake a call to the player service rightbut now you're building that i'm goingto call the service registry servicewhich is this other service right thatyou would have to build or whatever oruse ncd like grab did or whateverand then it has to call and get theaddress of the player service and thenand then it makes the call and it's likeyou've builtrouting logicand discovery logic into your actualapplication logic which you do not wantyou do not want that okaysoalmost immediately people started movingto proxiesyou have a proxy that's your local proxythey call it a sidecar proxy inkubernetes land because it actually runsin your little cluster as anotherservice along alongside all of yourother servicesand it handles allnetwork uh ingress and egress for youso you the idea is that your applicationonly knows about the sidecar proxy rightso to your application the proxy is theoutside world if if you you know itknows about the service locations and italso knows about circuit breakers andtraffic splitting and load balancing andscaling and everything else that we'lltalk about in a bitand that proxy becomes the thing thatother people use to talk to your serviceas well because your service may be acluster right and so people if peoplewant to send something to the playerservice and there's a bunch of instancesof it your proxy is the one to choosewhich one maybe maybe it interacts withan external load balancer or maybe itdoes the load balancing itself the proxydoes okay by doing the health checks onits local service instances yeahdoes this model make sense so as soon asyou get this basic model of the of thesidecar proxy you've got a helperservice that goes along with everyclusterand it knows about the services in thatcluster and it knows about the outsideworldand your cluster talks to the outsideworld through the proxy and the outsideworld talks to your cluster through theproxy okay you can use nginx for thatand that's what dropbox is doing rightbut these days people always almostalways use envoy or link or d there area couple of other options in addition tothose in nginx but i mean those are thereally popular ones okayenvoy is the the super industrialstrengthdoes everything swiss army knife amazingdata plane okay by the way those sidecarproxies i'm going to introduce you nowto the to the second term you hear dataplane the other one being control planedata planes is just all of your sidecarproxies in aggregate because if you ifyou've got a whole bunch of clustersright uh or even a whole bunch ofservices and you want proxies for eachof them thenthat mesh of proxiesthat are all talking to each otherto work out the service discovery andthe routing and everything on behalf ofthe application services now you'veextracted all of that you know who who'stalking to who what where and how muchand all that you've extracted it intoyoursidecar proxiesthat's your data planeit's because the network data is goingthrough that and i think it's a terriblename it should have been called thenetwork plane or the proxy point proxyplane would have been an absolute greatname for it rightproxy plane but no they call it dataplane so it's completely confusingbecause you'd think the data plane wouldbe either your application logic or itwould be the data layer behind yourapplication logic but noso stupid name really stupid shame onwhoever chose that name really you justyou did a huge disservice to theindustry so if you patent yourself onthe back because you came up with a namedata plane like seriously like punchyourself in the mouth okay it just itwas a bad namenaming you know naming stuff matters manyou don't want to confuse everybody forthe rest of their liveswhatever but the name is stuck and thename is the name now and in fact thereare well we've been ahead of ourselveshere but they're even becoming universalstandards now for data plane uhinterfacesso the data plane i mean like you'rejust going to have to learn what dataplane means it means it's the proxylayer okay the proxies that can uh couldload balance and they can they theyhandle the network for you it's softwareload balancing they actually in envoythey actually communicate through aprotocol called a gossip protocol whichis a family protocols where they're sortof like udp multicast whereeverybody just kind of like spits outthe state and consumes the state and itsort of floods the networkand it's eventually consistentso that's one thing to know about envoyis they chose an eventually consistentmodelif you'll recalli said that etcd and technologies likeit like google's chubby or uhzookeeper or uh even hashicorp consolethey're all they're all key value storesthat areum transactional highly available andstrongly consistent okayuh and that actually makes them uh sortof a pain to operateuh in practiceall of the ones that i just mentionedchubby is an interesting one google'schubby it was probably the first uh mikeburrows i think uh did chubby and if youhaven't heard the name mike burrowsuh you really should know his namebecause you know he's easily one of thethe people who had 10 people who've hadthe most impact of google rightuh he's you know i don't know he's a deor whateverand uh and he he came up with chubby asfar as you know among other things andchubby is umchubby is distinguished ashaving something like seven nines ofavailability it was down for 30 secondsin 10 years something like thatso umso yeah and it's because google has acore competency of operating chubby atscaleright because it's the it's the centralyou know key value service for serviceuh discovery and information ...
What this episode covers
Yegge explains Service Meshes and Control vs Data Planes
NOW PLAYING
[Tech] Separation of Control vs Data Planes - Steve Yegge
No transcript for this episode yet
Similar Episodes
Dec 5, 2025 ·50m
Oct 9, 2025 ·33m
Oct 3, 2025 ·40m
Sep 11, 2025 ·31m
Aug 27, 2025 ·39m
Aug 18, 2025 ·54m