Traditional vs Cloud Native Applications

everyone my name is Tony Burke I'm from datacenter overlords calm and you can find me on twitter at t-- burke that's tbo you are ke and right now we're going to do a quick little bit on traditional versus cloud native applications so as we are transitioning into the traditional virtualization world into the cloud world one of the things that we're seeing is the way that applications are written are being written differently so on the left here we have traditional applications sometimes refer to as pets and then on the right side we have cloud native applications and and they're fundamentally different in how they're architected so they both typically make use of load balancers which is right here so when new users come in from the internet here they hit the load balancer and then they'll get directed to a server now there's one thing we almost always turn on on load balancers traditionally and that's persistence also known as server sticky or affinity or something like that so that keeps a user this guy right here a little stick figure tied to a specific server in this case the server on the left now the reason why we do that is most applications are written in what most traditionally most applications have been written in what we call a stateful manner so sometimes referred to as the shopping cart problem so if this user has a shopping cart and let's say this is some sort of Web Store application here's a little shopping cart and he puts an item in that shopping cart that shopping cart is only going to exist on that particular server so that's why we need server sticky we need to keep that user tied to that specific server because the items in that shopping cart are only stored in that particular server this is known as a stateful application and the problem here is that each server maintains its own individuals State with the users so that's why we have to keep sending users to that particular server now if that server were to die if we had a some sort of server failure here of course the load balancer would detect the failure of the server because the load balancers typically people do health checking and they direct traffic to an available server that is surviving now the problem there is that their shopping cart will be empty now most applications aren't shopping carts these days of course there are a bunch but this meant miss may manifest itself in other ways for example if you have to login to any what given website if you were to be if you were sent to a different server if that application was stay full you'd have to read login and that results in a negative user experience it also means I can't really dynamically adjust the number of servers that I have running at any given time because if I have to switch a user to another server for example if I if I kill off a server then I'm going to have to to tolerate a negative user experience cloud native applications on the other hand are written in a fundamentally different way they are known colloquially as stateless applications but I think a better term would be a shared state application so they'll typically also use load balancers but these load balancers don't need to be as fancy they can be just layer for load balancers and they can they can skip a sticky so there's no sticky sticky server sticky so we don't need that so a user comes in from the internet hits the load balancer and a load balancer can send that user request at any given moment to any of these servers because the servers have a shared State so this web application or this cloud native application will have a shared state so if the user puts an item if this were shopping cart the user puts an item in one of these shopping carts it automatically gets added to the other servers as well so these servers will have known what's known as a shared State now there's any number of mechanisms that allow this to happen sometimes it's a back-end database server sometimes it's a shared storage space maintained between the servers there's really a couple different ways you can do it and some of the some of the web frameworks will allow you to do this it is considered this is considered to be the superior way of doing applications for a couple of reasons one we especially when Amazon first came out the the virtual machines that you created the instances were on shaky ground so to speak so we're on traditional applications we rely on VMware and things like the motion and H a and ers to make sure that that servers are nice and stable and that they have their the resources that they need and if a server were to have a failure the VM will get be motioned so in the traditional application world the virtual machine and the application are very tightly intertwined and state is individual on a cloud native application in the cloud world is fish in the beginning that the VMS were or the the infrastructure was considered unstable so you had to make sure that you built your application so that no one given vm you could never trust that a vm would be around at in a given moment so what that allows us to do is we rely less on features like the emotion in fact if any of these servers were to die back to my read here that server were to die no problem the load balancer just continued sending traffic to the surviving servers the user has no idea that anything happened I don't have to real Augen they don't lose their shopping cart or something like that so none that all of the session information from the user is shared amongst all the servers one big advantage for that is elasticity so in a traditional application if I have three back to my black ink here good to bloom if I have for example three web servers so these are the web servers that I have running or application servers and I have a load balancer which I typically will if I have a sudden surge in demand I'm going to have to add servers now the problem with that is that up until I have it surgeon to man the load balancer should load balance about 33 percent to each server of the original trio and when I add rapidly add a new servers it's going to take a while for these guys to ramp up because only new users are going to be sent to these newly web servers remember we've got typically in traditional applications we've got sticky so if we do have sticky turned on the existing users are still going to be crammed onto these three servers now we may get to a degraded state because they're running over capacity and just because I added these three new servers existing users are not going to be transferred to these and to these servers unless I kill off these old servers and that's going to result in a negative experience also what happens when that demand that surge in demand goes away and I start having to call servers especially if I'm on Amazon I'm paying per peruse so I don't want to have VM spun up for any longer than I have to so again that involved that involves a negative user experience so cloud native applications do things very differently like we mentioned before state is shared so in that case we don't need sticky so so no server sticky state is shared across all of these servers now back to blue so let's say I've got an original three servers I have a sudden uptick and demand I add three more servers or three more VMs and then immediately traffic is divided amongst them equally so I've got all of my traffic divided amongst only these three servers now I have a drop in demand I don't need all these servers I can immediately kill those servers and the users will be sent to the remaining three servers without any interruption news or experienced only has two real aughh in no one loses their shopping cart so this is the primary difference between traditional applications and virtual applications or traditional applications and cloud native applications it's just the way the applications are architected now you can take a traditional applications and refactor it and the term refactoring means we're going to change the underlying code or change the underlying infrastructure without changing the function of the site so we can move it into this into this cloud native style really if you're developing applications you should be developing them as cloud native it doesn't it's not that difficult to start out that way but it may involve a new new tool set a new tool chain it may involve a new skill set for the developer so that's the primary difference between cloud native applications and traditional applications also sometimes refer to as pets versus cattle again my name is Tony Burke you can finally find me online at datacenter overlords com or you can tweet at me at t-- burke that's at tbo you are ke thank you for watching

Channel: Tony B

Views: 109,115

Rating: 4.75351 out of 5

Keywords: Cloud Computing (Industry), Application Software (Software Genre), Software (Industry), load balancing

Id: osz-MT3AxqA

Length: 9min 59sec (599 seconds)

Published: Tue Sep 01 2015