Start-up Architecture: VPS vs Container

[00:00:00]
>> Erik Reinert: All right, so the startup phase. Just get it working. If you've ever worked at a startup company before, if you've ever been on a project that's been growing or starting to be developed as an application, you've probably heard this quite a bit. Just get it working. You've probably heard it from your manager too.

[00:00:16]
This is normally a phase that is heavily focused around we need to get things out the door. The highest priority right now is users features, being able to get more people onto the application. And that's really what we talk about, a business priority. That's all business is caring about.

[00:00:35]
Something to note about DevOps and platform, especially as you move up higher in it, it will become more and more about business and less and less about technology because a lot of it eventually ends up becoming okay, well I want to convince you why we should make these changes and why we should actually move from this platform to this platform.

[00:00:55]
And so in this phase, normally you'll deal with the hardest pushback. Normally people will be like, no, I don't care about any of this. Just get it run, just get it working. Our phase scenario. Each phase, like I said, has a scenario. The phase scenario here is that we have source code managed by a development team.

[00:01:11]
We didn't write this source code. We don't really have any understanding of it. We know that there takes some environment variables and we know that if we run the binary it should work. But that's really about as far as we're going with the source code itself. We're not going to really be doing any actual source source code changes or anything like that.

[00:01:29]
And this is pretty common in a DevOps platform deployment scenario. You don't really know. You might not have a deep knowledge of the actual source code itself, but you are going to be maintaining the infrastructure around it. So that's the mindset I want you to be in. We need the quickest deployment with minimal effort required.

[00:01:49]
So again, the goal here should be I don't want to have to hire another person to get this out the door. I want to be able to do it myself. I want to be able to get this up and running pretty easily. We're looking for the biggest wins with minimal required setup.

[00:02:06]
So again, going back to that whole minimal effort, we want to just again just get it working. We want it to be online, set up and running. I don't want to have to put in a ton of effort to do that. Then the last thing is we're learning about what needs to be maintained.

[00:02:21]
None of you know what we're deploying. I do, but in this scenario I wouldn't either. So this would be also a learning part as well. So you can't expect in your first phase to be optimizing. That's something I want you to take away from this. This is like normally in a startup phase, you're not optimizing, you're focusing on getting the fundamentals down and again, just get it working.

[00:02:46]
The goals here are actually very simple. We're going to create a repository to store source code. Each of you are going to do that. We're going to create a database deployment for production and we're going to create an application production or a deployment for production as well. So really three simple things.

[00:03:01]
Repo database deployment and application deployment. Before each phase, I'm going to quickly talk about what we're building, why we're building it, and you get to see a fun flowchart, because I like flowcharts. So in the startup phase, we're going to be focused on building the infrastructure that you see right in front of you.

[00:03:21]
It looks complex, but it's actually very, very simple. So the goal of this infrastructure is, as we said before, to just get it working. I don't want to worry about managing things. So what are the things that we have to manage? Well, we need to manage an application running and we need to manage a database that that application connects to, right?

[00:03:42]
Those are the two things that we will have to figure out solutions for now, you may immediately go, okay, well let's build on top of Amazon and use VPCs and Da Da da. But you don't need any of that, right? Like you can, sure, if you want to, if you want to become a cloud architect, you can go out and learn that stuff, but you don't really need that.

[00:04:04]
And like when you're in the startup phase of a company or in the startup phase of an application, you've probably heard like, you know, host my WordPress on Kubernetes. Like that's definitely one of those scenarios where it's like, dude, you don't need, just put it on a vps.

[00:04:21]
Again, just simple, put it on a vps, have it running, just do whatever you need to, just get it online. Now there's a couple of things that we do want to kind of make decision wise. The first one is do we want to use a VPS or do we want to at least try and be containerized?

[00:04:41]
That's probably a decision you'll end up making whenever you start trying to Deploy something. Here's what I will say about that. VPSs are great, but in terms of technology and the things we can do today, they are a little outdated. A vps, when we mean a vps, it's just an instance.

[00:05:01]
You get a Linux instance, ussh into it, you set up all the programs you need, you copied the files over to the instance, all that work, and then you run a command and then boom, there you go. You can do that. And I'm not trying to say you shouldn't.

[00:05:16]
If you wanna set up a VPS, go for it. I'm not here to necessarily tell you what to do, but again, I want you to hear me out When I say there's reason as to why every single one of these components were picked. It wasn't just because I like Amazon products.

[00:05:34]
So for me personally, we are using Containers now. We have the day of images, right? I can ship an operating system with Docker, right? I can at least ship a image of that VPs basically with a Docker image, right? And so one of the decisions that were made in the startup phase was to say, okay, we're going to do containers.

[00:05:57]
We're gonna at least out the gate, we're gonna do containers to make it so that we can at least also move in the future, right? Because we know we're going to eventually probably want to move to bigger orchestrators and stuff like that. So why not make this decision now, right at the startup phase and then let that grow as the organization or as the project goes.

[00:06:17]
So containers was a strategic decision here, right? And so, whenever you're thinking about infrastructure, these are the kind of things and the kind of arguments that you can make in these discussions to help solidify what you're trying to do or help your argument basically, yeah.
>> Speaker 3: Is there any argument for not using containers?

[00:06:40]
>> Erik Reinert: Tons, VPS are actually still used heavily. Yeah, I have this problem myself personally because I've been in the industry for a little while now that you're up here, you know what I mean? You're so used to kubernetes, da da da, you're up here. But the majority of development and stuff like that is still very much down here, you know what I mean?

[00:07:04]
And so, you may be used to Terraform and IEC and Kubernetes and cloud, blah, blah, blah, but no, honestly, a lot of storefronts and things like that today are still like either running co-located even or yeah, still running VPSs or VPCs sorry, VPSs and stuff like that. Because it's just.

[00:07:23]
It's this startup phase mentality of like, I just want to get it running. I don't know how to get to that point. So, I know how to run commands, right? I know how to. And then they just stay, right? And that's it. And then there you go.
>> MALE: Right, and so no, VPS are actually super common still, yeah.

[00:07:40]
>> Erik Reinert: What is a vps? Gosh. What is it? It's a virtual private cloud. Well, vpc. That's VPC server. VPS is server. Yeah, Virtual private server, basically. So in the good old days when we didn't have massive scaling and horizontal whatever, everybody would go to their favorite hosting provider and pay for a little slice of compute and RAM, basically.

[00:08:12]
And so, we called them VPSs back in the day. That was like the marketing term. That sounded cool, I guess. I don't know. I actually hated it. I was just like, just call it an instance, man. I don't know. But yeah, VPSs are just, you go to a provider.

[00:08:28]
I want two cores, four gigs of RAM. Cool. I'll take care of the rest in the full stack. Learning path on frontend Masters, which is something you guys, I would definitely recommend. Jem made a course that focuses basically on a lot of what you guys are talking about.

[00:08:43]
Like, okay, I want to deploy a vps, I want to go with cli, Create, setup, Docker, manage it, all that kind of stuff. Yeah, that would absolutely be a good starter to this course because then it would at least get you more comfortable with even some of these concepts.

[00:08:59]
And what is this versus this? If you don't understand what a VPS is at all, I would recommend checking out that course. It'll probably help you a bit. But yeah, these are all like, there's the engineer in the room who will give suggestions, but then there's the engineer in the room that will make decisions, right?

[00:09:19]
And you normally don't want to be the engineer, just making suggestions. Like, if you really want to impact a company and even grow in your career, you want to be making decisions. So again, if there's two people who are like, I like Azure. I like Amazon. Well, it's like, okay, that's great, but what works for us, right?

[00:09:37]
And so again, just to go back off of what you said earlier, that would be a massive argument that could be solvable by simply saying, well, Azure can get us in and on the cloud without even needing Docker knowledge or anything like that. We do take a similar Approach.

[00:09:52]
Again, I did take on the expectation or the responsibility of saying, well, I want it to be containerized, but again that's also a decision around. I know I'm going to be running containers in the future, so might as well just do it now.
>> Speaker 3: Yeah, I was just getting at like kind of maybe what's like the trade off.

[00:10:14]
>> Erik Reinert: Yep.
>> Speaker 3: It seems like the VPS is like the lowest level and then you got kind of like the managed like Azure app service or elastic Beanstalk and then you got the containerized approach. Like yeah, what's the trade off there?
>> Erik Reinert: Normally the managed services are containerization abstracted away, right?

[00:10:33]
Like normally that's what they are, like Beanstalk. Again, the reason why I said what I said was is because I have used Beanstalk at least like years ago. And from what I recall it would take your code, bundle it up for you and ship it out for you, right?

[00:10:47]
And then they would containerize it and take care of all of it for you. But yeah, I mean, and kind of just to give a little bit more of, which is better. So technically a VPS will give you more dedicated resources. The reason for that is just based off of the pure and simple fact that it's a virtual machine.

[00:11:13]
A virtual machine takes a specific piece of compute and a specific piece of memory and says, that is mine now. Thank you. I only own this if you have scale. If you're really worried about I want as much compute power as possible. A VPS might be better for you.

[00:11:30]
The reason why I say that is because I don't know why Bitcoin came in mind, but that would be a good example. It's like, I know I'm going to be throttling the CPU the entire time. I know it's going to be consuming tons of resources. Probably don't want to put that on a container with thousands of other containers.

[00:11:50]
You're going to be a bad neighbor and you're going to probably make the provider mad. A VPS would be more helpful there. Not that I'm saying go to your cloud provider and start running Bitcoin miners. But yeah, there's trade offs there. So yeah, it's really good to think about what works best for you guys.

[00:12:09]
The application that we're going to be deploying is very simple. It's just a go application that connects to a database. We're not really worried about tons of processing power and stuff like that. So like I said, I knew that I wanted to be on containers in the future.

[00:12:23]
So, containers is kind of where we're starting. That's like the first layer of the foundation of the house. It's like, okay, containers, great. We made one decision, now where do we want to run that container?
>> MALE: Right, that's the next decision to go back to what you said as well.

[00:12:39]
>> Erik Reinert: The nice thing about cloud providers is they normally provide some kind of managed easy solution. They'll have an entry point solution because they want you to drink the Kool Aid and then eventually get to the big solution. They want you on Kubernetes, but they know you can't get there.

[00:12:56]
So they've built smaller, more again, abstracted away solutions that make it so that you can just drop your application and then two years later you're giving them $100,000 a year or something. In this case, the service I chose was App Runner. Now, App Runner is probably similar to Azure's app service, where its goal is really just to be like, I have absolutely nothing.

[00:13:22]
I just want to get my thing running in the cloud. That's exactly what App Runner focuses on. It will take your source code. It will potentially, or if you want it to, it'll even run its own backend builds for you, it'll containerize it and then it'll put it up in the cloud and run it for you.

[00:13:40]
What's nice about that? Well, technically, again, talking about that abstraction level, it's containerization and it's using all of Amazon's existing tooling underneath the hood. That's how Amazon works. Most cloud providers do that. They'll be like, okay, well we've already got ecs. Well, let's build another service that's even easier on top of ECS and then charge more for it.

[00:14:03]
And then there we go. Now we're making two handed money in both hands basically. And that's what App Runner is. App Runner is basically a service on top of a service that makes it easier for you to get into the door. But it does mean that underneath the hood you're going to have horizontal scalability out of the box.

[00:14:23]
With App Runner, you'll be able to scale to however many instances you need. It'll still have that. I don't know if you guys remember, years ago, Google had a keynote where they showed off the first horizontal scaling Kubernetes and everybody was amazed and was like, my gosh, he's creating thousands of instances.

[00:14:45]
We're at the point now where these low level, simple entry level services, they do that, like they'll do that out of the box. So, there's kind of an argument here to say as well that, you could never leave the startup phase too, right? Like, you could pick a solution that works so well that you could be like, well, why do I need kubernetes?

[00:15:05]
Like, it's already doing that for me. I'm already getting auto scaling, I'm already getting automatic restarts and stuff like that. And so these do become like vendor lock ins. Is really what I'm trying to say is like, you know, at some point you'll either be running on App Runner or you'll be running an ec.

[00:15:22]
Yes, but it's really all the same Kool Aid, it's all the same sauce. At the end of the day, it's just, how much of that ownership do you want to take on? It's really my only point that I'm trying to make. So in the diagram, you'll see that our client makes a request and it goes directly to App Runner.

[00:15:38]
Now, from us, from our mentality, that's all we know. We just know it goes to App Runner. Does that mean there's a CDN underneath it? Does that mean that there's caching? Does that mean. I have no idea. So that's the other side of using services like this is you're putting a lot of responsibility on that one thing to solve a lot of different problems.