This meetup has already happened, but you can still watch the videos! Check out four presentations on DevOps-focused topics. 

Amazon RDS Proxy is a service from Amazon Web Services (AWS). It's a fully managed, highly available database proxy for Amazon Relational Database Service (RDS) that makes applications more scalable, more resilient to database failures, and more secure.  What I like most about RDS Proxy is its ability to speed up recovery from RDS failovers, from as much as 10 minutes down to 15 seconds or less. I'm sure all you SREs and TPOs will appreciate this too.

That sounds great, right?  Well, the truth is RDS Proxy is not easy to set up, and getting the configuration right takes extensive searches of the internet including both AWS documentation and third-party sources, and you STILL may need to contact AWS Technical Support.

I'm going to show you how to set up RDS Proxies via ClickOps, both for a new environment and for adding a new service. Future articles will cover CLI and TerraForm approaches.

Overview

As a member of the DevOps/SRE team at Bitovi, I was asked by one of our Bitovi clients to investigate POC RDS Proxy for use in a large-scale microservices system.  After trial and error and time spent on a call with AWS support to better understand a cryptic error message or two, I was able to get things working well.  From that experience, I built a procedure to set up an RDS Proxy between your services and RDS/Aurora clusters with a minimum of time and headaches.  I am sharing that procedure with my fellow infrastructure engineers here.

Below are the steps needed to successfully set up RDS Proxy, as well as some helpful debugging information. First set up your AWS account and your RDS instances if you have not already done so.  To get started on the RDS Proxy-specific steps, you will create Secrets in AWS Secrets Manager in the format required by RDS Proxy.  Next, you will create an AWS IAM Policy and IAM Role.  Then you will be ready to create the RDS Proxy.  Finally, I'll show you some testing ideas so you can be sure everything is working correctly.

You can't just say "we do DevOps" anymore. If DevOps best practices aren't followed, teams inevitably waste the potential gains that DevOps practices enable, and infrastructure problems still aren't resolved.

With the continued success of DevOps and Infrastructure as Code(IaC) conversions, it's no wonder that IT teams across the world are adopting these new practices.

Ready to get started? The first DevOps best practice you need to know is the separation of application and operations repositories. Avoid common pitfalls by using Bitovi's recommended DevOps practices. You'll learn what an OpsRepo is and why and how to separate your application and operation logic into their own repositories.

What Happens Without Best Practices?

When your DevOps team doesn't invest in proper operation management practices, you end up with slow, unaware infrastructure provisioning, redundant resources eating up infrastructure budget, and a critical failure point where all the knowledge of the infrastructure and its configuration is held by just one or two people.

Managing application infrastructure can be frustrating and prone to error. Configuration, builds, tagging and deployments are just a few of the many vectors SREs need to consider to create successful CI/CD pipelines.

And if these resources are handled through logging on to a server or clicking buttons on a cloud console, aka  ClickOps, the complexity of configuration management and the likelihood for error grows.  

Having some way to play around with multiple cloud technologies while keeping your whole process adaptable makes BitOps the perfect testbed for your DevOps efforts! 

HeyEmoji is a fantastic reward system teams can use to recognize each other's accomplishments, dedication, and hard work. Once you get it set up, you can mention a colleague's Slack username in any channel along with a pre-configured reward emoji - you can even include a short description of what they did that was so awesome it deserved a shoutout.

The best part? When you send an emoji to a colleague, they get emoji points, which can be tracked on a leaderboard. Competing to see who can be most helpful, considerate, or skilled at their jobs is a pretty fun way to make the day fly by. 

Want to get HeyEmoji on your own work Slack channel? This tutorial walks you through how to deploy the HeyEmoji Slack app to AWS using Terraform+Ansible so your team can enjoy Slack-generated kudos. 

In a recent series of blog posts, I drew up how to go from a basic StackStorm installation and pack deployed using Ansible, to moving that entire custom deployment to a one-touch cloud deployment using BitOps while only modifying a handful of files in the process.

We only barely scratched the surface of our implementation, and we can always go further. One aspect I tried to be mindful of throughout the guides was the various ways of managing of secrets. In this guide we will detail how we can utilize an AWS Key Management Service (KMS) key as well as AWS Systems Manager (SSM) and Parameter Store to take that a step further.

In practical terms: we'll create a BitOps before hook script we use to retrieve all of the secret variables we need from AWS, and demonstrate how we can load those into the BitOps container environment for usage within our existing Ansible StackStorm playbook.

Last time, we had refactored our basic one-line install of StackStorm and our custom pack into an Ansible playbook. The Ansible playbook works well enough on its own but still requires us to already have a server setup for Ansible to execute the playbook on. What if we didn't need that pre-existing server and were able to on-the-fly provision one for our playbook? This arena is where Infrastructure-as-Code (IAC) initiatives really shine and where I would now like to introduce BitOps.