Cloud Deployment Models

Cloud Deployment Models

Estimated reading time: 10 minutes

Introduction

We repost our vlog here along with the full transcript. If your embed above isn’t working, here is the direct link to the video here.

If you’d like a bit of background on what cloud computing is, check out our What is Cloud Computing page.

Cloud Deployment Models

Search for the phrase cloud deployment models and you’ll end up getting articles that reference public, private, and hybrid clouds. In some instances, they’ll use the word Multi-cloud as well. While that’s accurate, I really wanted more depth and nuance to the topic. The Public, Private and Hybrid cloud terms aren’t prevalent in many of the discussions I have with my clients. This is a pretty vast topic so I hope to do it justice. Please note, this is certainly by no means authoritative because there are many ways you can view and categorize the various ways to deploy your systems into the cloud.

A Tangent About Horizontal vs Vertical Scaling

Before we get into the deployment models used in cloud, I’d like to start with brief primer on horizontal and vertical scaling because I’ll use these terms a lot in this video. Simply put: Vertical scaling…. Take your web, app and DB layers of the environment. Picture them on top of each other and remember there are limitations when sharing the workload at the application and database layers of the environment. Let me pick on Microsoft SQL server for a moment: Clustering a Microsoft SQL database was really about failing it over when 1 of the 2 servers went down. It wasn’t designed to share the load amongst 2 machines. Said differently, originally Microsoft SQL clusters were for uptime and not for processing more work. To scale this environment, because you were relegated to using a single database server at time, your options were to add CPU and RAM to the same single server. So that server got bigger (this way), and so we represent that as being vertical. You could not easily scale it to a second machine which is what horizontal scaling refers to. Also, Microsoft has long since addressed this issue and other database vendors struggled with this as well and so I only use it as an example. Application servers suffer from this same issue. If the logic isn’t built into the application enabling it to look for other instances to process the workload, you end up having to build massive single instances of servers. Let’s move on to horizontal scaling… imagine that you can take these original 3 tiers and you can have an array of these devices going left and right as wide as you’d like. Each server can literally be garbage because if one of them fails, they can be kicked out of the rotation and the load is split amongst the remaining working servers. We’ve done this fantastically at the presentation, or web layer forever. When you are able to do this at all 3 layers, you start moving in the direction of being elastic. { } Let’s move into what the video was really supposed to be about which is the different methods of cloud deployment we see. So I’d like to outline all the options available to us. Some housekeeping stuff: I will lump somethings in here that aren’t considered cloud at all, but they are still relevant to the discussion and so I’ll keep them in. Also, I am going from oldest to newest technology. Lastly, I am not going to dive deep, this is a super technical topic which would be hard to cover int he 10 minutes we get together each week. So, Don’t laugh, but I am going to start with

the deployment models used in the cloud

Mainframes

While you’d think mainframes are the opposite of cloud, in a manner of speaking it could be argued that mainframe is the original cloud but without the internet to make it universally accessible. Let me explain. You had massive horsepower in a single concentrated machine that could be partitioned to run different functions. Folks from around the company would connect to this using fairly low powered terminals and all the data resided in a single area. Take a mainframe, give access to it over the internet and it’s cloud. Just a really old, hard to maintain and expensive cloud. The Second deployment method is:

Client Server

is not really cloud but has been adapted to the cloud. The easiest way to outline client/server is to think of any desktop application you use. It’s an executable file that runs on a computer and its data is typically stored on that same computer. There’s no web, app, and database layer to it but it’s still a staple for many businesses. In the healthcare field, many applications are still client-server with software publishers trying to offer hosted versions of those applications. To “enable” it for the cloud, You basically are allowing folks to all login to a terminal server which “presents” the application screen to you, almost like streaming a video of the screen. If you’ve ever used log me in, or if you’ve gotten remote IT support where your keyboard and mouse are taken over by a technician, it’s very similar. So the terminal services are how these are deployed in the cloud but the application scaling itself is a bit tricky. To scale, the application is run on one machine and the database on another for scaling and you just get more RAM and more processors to scale. Most of those software providers I imagine are working on re-coding their application to run in the cloud using a more modern method. #3:

Server

3 Tier Web Application

This was the happening thing when I started in IT in the 90’s. There are 3 tiers: Web, Application and Database. Users could use any web browser and they experienced The Web layer which does the presentation of the data, the application layer processed the logic and was really the brains of the application, and the database stored all the data. Many of these applications scaled vertically, meaning you’d just get bigger servers but with the exception of the web or presentation layer which allowed you to scale using load balancing. In time, applications and databases began to more easily be load balanced which allowed them to scale horizontally. This allowed the distribution of processing to leave that original app or database server for one sitting next to it. If there was a version 2 of 3 tier application architecture it would have been virtualization. Method #4 is

Microservices

Microservices

based architecture. Since this is new and just so different than what we are used to, it may take the longest to explain. If you are familiar with the way an API works, you can quickly grasp what microservices-based architecture is. Rather than writing a lot of code into a monolithic, single program with all the components in one place. You build containers for your application. Each container contains all the libraries needed to execute a specific aspect of the software in a very single tasked sort of way. Let me do a simple example, you build an application for your online store. You have a shipping microservice in your application, which would receive an address and a weight from the invoicing microservice and compute the shipping cost and estimated delivery times and hand it back to the invoicing microservice. Let’s say, it’s holiday time and the invoicing microservice if getting clobbered, the orchestration and scheduling app would fire up more invoicing microservices and would let the system know, hey, there’s 2 of me of now and you are free to request invoice creation from me. As this increases, the load on the shipping microservice will increase too. Scheduling and Orchestration will say, hey, we need to spin up another instance of this shipping microservice until I notify you otherwise. If the app is truly elastic, it will note the decrease in requests after this surge, and turn off those extra instances, meaning you are handing resources back to the infrastructure. If this is a public cloud, you are no longer being charged for this computing resource. The take away is you’ve broken your application into small sections, each responsible for processing very specific tasks and being available always to provide the computation that is requested of it on demand. This model is very easy to scale horizontally again meaning you can scale instances left and right of that instance with lower-powered containers and then share the compute load over those new instances. You don’t need to add massive CPU and RAM to single instances which is what we did when we scaled vertically.

Serverless Diagram

Serverless Computing

is our 5th deployment method. This of serverless this way. It’s a system that just runs code. It says, give me your code, I’ll execute just your code and I’ll output it to where you want as many times as you ask me to do so. In the serverless world major players would be the likes of AWS Lambda or Googles Firebase. You can set up your code to automatically trigger from other cloud services or call it directly from any web or mobile app. Serverless really shines is if you have a process that kicks off that needs horsepower but in small intervals and the results are handed off to some other infrastructure. I think serverless is probably the trickiest of all these models to explain so I’d like to just give a real world example of how something like this could be used. Lets say you run a site where you take a rectangular profile picture and you spit it back out to end users with rounded edges which incidentally is a service I’ve used because my photoshop skills are garbage. So you would have a simple website, and folks would upload their rectangular picture to the server. To convert this, you would need some code to run a bunch of computations and convert the image. It may not be worth having an entire environment built out to execute this code that may sit idle for long periods of time. So you have this very simple website which would take the file, and then push it to a serverless instance that would crunch it, round the corners and then place the resulting file in some online storage with a download link presented to the client. The total computation and processing of that function could almost be free especially when sent to some massive infrastructure that processes code all day. So you are not occupying any compute online 24 hours a day but just tapping a service that can execute your code like a utility. So let me wrap this up and pray that I haven’t made this more complicated than it needs to be BUT when looking at these deployment models, one may sound better than another but they are really the continuum of how our application delivery technology is developing. The goal of this video is not to promote or push an angle since changing deployment models without changing the code is not something you can aspire to. You are relegated to the cloud deployment model you have, based on how the code is written. You can choose to code all new applications using something modern that runs on these newer cloud methods but you can’t simply take your existing application and deliver it through a cloud technology that can’t serve it to your clients at a reasonable price. I thank you for joining me this week for this explanation and I hope it shed some light on the various ways that applications are delivered.

«
»