Design principals - Amazon Web Services (AWS) Tutorial

- [Instructor] When looking at performance efficiency in your organization for your applications, Amazon suggests that you follow the design principles that they've found work for most customers and AWS themselves. And the first design principle sounds like a bit of a buzzword, doesn't it? Democratize advanced technologies. Well, what do they mean by this? Well, you've seen some technology that gets announced by Amazon and you might think, ah, that's pretty cool. I don't know when I'd have time to learn how to set that up and build it. Or maybe you would look at a new technology and say we should build that from scratch ourselves. Well, Amazon's suggesting that maybe you should consider anything new that you want to use at Amazon and take a look whether there is a service that has already been built for you. So you don't have to waste time. You want to remove the burden of saying to your IT staff let's build this and maintain it and we need more people. No, let's use the service that's already running. Get rid of that burden of hosting and running the services. After all, you're in the cloud. That's Amazon's job. So if you wanted a NoSQL database, and if you're not familiar with NoSQL, it's something like Mongo, maybe you want to use it. Maybe you want to try something out, a new application that doesn't have the burden of any legacy decisions. Well, don't create it from scratch on EC2 instances. I mean you could, but why don't you see if it works first? Then after it works, maybe you come to that decision we're going to build it ourselves. But maybe you'll come to the decision that this is great. It works and it's built and deployed better than we could ever do it. You could also embrace other services that are pre-built such as media transcoding or machine learning services. There are many, many new services being announced by Amazon every day. Take advantage of the services they've built for you. Now, you also might want to go global in minutes. This is a bit of a buzzword for sure because maybe it will take more than minutes. But maybe you want to use archive storage and you could upload your content in minutes into S3 Glacier storage and archive it and store it around the world in minutes. Maybe you want to load a very complicated application stack. Well, maybe you'd like to look at some of the blueprints. Blueprints are cloud formation scripts that allow you to deploy pretty well anything at AWS. And you could deploy these application stacks across AWS regions. In fact, you could create a cloud formation script that would build your existing application stack in different regions fairly quickly. You also might want to move resources closer to end users in different regions. Maybe it's storage. Maybe you want to replicate storage from one S3 bucket in one region to another S3 bucket. That can happen in minutes, for sure. Perhaps you want to consider using serverless architecture. Another buzzword. What it really means is less servers. Kind of a play on words. A serverless architecture means Amazon is managing the servers. So you could host a static website in an S3 bucket. Behind the scenes, there's some compute, Let Amazon deal with that. Maybe you want to create functions in any language to automate responses to metrics and alarms that you've set up for your application stack. Lambda is a service where you have to upload your function that you create. But then you say to Lambda this is the RAM, the CPU, and how long it's going to run. And that function, when it runs, is all you're charged, is that compute RAM and the amount of time. You don't have to worry about the servers. So maybe you say, I've got this application. And if I break it down it's 14 different steps, 14 different functions. If I created 14 Lambda functions, I could have an application running on Amazon servers. I don't have to maintain the servers. It could be a real win-win. And it removes that burden of managing your virtual and physical servers and monitoring them and scaling them. Let Amazon do that. So it's a consideration, perhaps for a new application with no legacy baggage. Here's one that isn't a buzzword. Experiment. Amazon will say experiment more often. I say in our busy world, experiment on a schedule. Use the cloud as a playground. Say, we're going to play in this area and see what happens. We're going to test compute. We're going to test databases. We're going to test out storage. We're going to break things deliberately. We're going to figure out what works which could benefit our current designs. And finally, the last design principle, a true buzzword if there ever was one, consider mechanical sympathy. Sounds like, I don't know, mechanical music. Well, what does this mean? Well, what it means is that have some sympathy for the technology. Consider using the best piece available, the best service available for your application stack. Maybe you don't know anything about it. That's where the playing comes in. Or maybe that's where you use the service and you don't have to know how it exactly works. Remove the legacy decisions from your thought process when moving to the cloud when you can. This might also mean removing the political decision. They probably won't work long term in the cloud.