Helm is a popular open-source tool used to manage and configure your Kubernetes cluster. Basically, it is a package manager (think Homebrew or NPM) built for Kubernetes. It helps automate processes like installing, configuring, upgrading, and removing items. This post will give you a brief introduction to Helm and how it might help you manage your Kubernetes cluster.
We’ve all been there. A new tool is trending, it is getting mentioned all over the place, and you get dropped into a conversation about it. The last thing you want to do is embarrass yourself by pronouncing something wrong and revealing you don’t know anything about the latest thing. We want to make sure you avoid that happening. When it comes to Kubernetes, there are really only four terms that you might need some help with pronouncing.
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.
