Yeah, Kubernetes is great at making sure your workloads run as needed. But another of its amazing benefits is its ability to recover from failure all by itself. On an everyday basis, Kubernetes takes care of the complicated task of container orchestration. However, as with any complicated system, there is always the chance that you’ll experience failures and downtime.
Hey there. Welcome to the fifth and final installment in our series on successfully deploying an app to AWS with the least effort. This week, we'll discuss things you need to worry about now that you've released, plus optimizing your app. Ok, so you've released your app. Congrats! However, we both know your work doesn't end here. You should continue improving your app, both on the end-user side and the back end.
Since launching in 2014, AWS Lambda has dramatically grown in popularity. Lambda allows you to run code 7without having to manage the underlying compute resources. From a monitoring standpoint, you no longer have the need or ability to observe traditional performance metrics like CPU and memory. That doesn't mean you don't need to keep an eye on other things, though. So what metrics should you monitor for your Lambda functions?
In our series on how to deploy an app to AWS with the least effort, we've talked about getting started, preventive measures, and securing your app. Today, we're going to focus on DNS (domain name system), specifically the AWS DNS service Route 53. As you're deploying your web app, you will inevitably use DNS.
AWS security is an ongoing battle that you must address during every release, every change, and every CVE. When you’re first launching your production application, it’s impossible to check all the boxes; you simply don’t have the time. Until your application gets more adoption, you only have the time to do the bare essentials of security.
There’s a lot out there about Amazon CloudWatch already, but since Amazon’s default EC2 monitoring service pushes regular updates, most of what you’ll find will be dated (last updated: 9/26/2018). Let us know what you think about our take on CloudWatch 101. The plan is to get you up to speed in a hurry.
Editor's note: This blog is part two of our series on launching an app to AWS. For the first installment, "How to deploy an app to AWS: Getting started," click here. So, your application is ready for production. You’ve taken an inventory of your applications, dependencies, and configuration. Now, you’re ready to create a new AWS account and start launching resources.
Launching a production app onto the cloud is a big task with a ton of tiny sub-tasks, and it can all be pretty overwhelming. We're here for you. We've launched an app ourselves (Blue Matador, our cloud infrastructure monitoring software). In the coming weeks, we will walk you through everything you need to know and do to successfully launch your app—with the least amount of effort.
IAM is the de-facto method of authorization in AWS. Most Kubernetes “Quick Start” guides for AWS do not adequately cover how to manage IAM access in your pods. This blog series will first go over the security issues specific to AWS IAM on Kubernetes, then compare solutions, and then we will end with a detailed walkthrough for setting up your cluster with one of those solutions.
In the last post, we compared kiam and kube2iam head-to-head. While kube2iam was declared the winner of that comparison, I feel that the case for kiam too compelling, and the setup too complicated, to not share my experience setting it up in production.
