Manage Multiple AWS Accounts Using Direnv

Mad Hacker SkillsI came across a simple yet elegant means of managing multiple Amazon Web Services credentials when using the AWS CLI. This way does not make you have to hack your .aws/config and is the simplest/cleanest way I have found.

First install direnv and make sure it is in your PATH.

Be sure to remember to add the hook to your shell of choice as they outline in their README.

Now that you have direnv setup we can configure it for each client.

I use a directory structure to keep each client in their own directory.

So for example in : .../clients/ACME/ I make a .envrc file and export my AWS keys in it:

export AWS_ACCESS_KEY_ID=****
export AWS_SECRET_ACCESS_KEY=***

Once you make your .envrc file run direnv allow to enable using the config. Then test your AWS CLI to insure working properly.

Then when you are doing work on that client’s account you simply have to cd into their respective directory.

Be sure to either encrypt the whole directory or at least chmod 600 the .envrc files to protect your keys.

 

Managing Multiple Clients on Different Messaging Apps

info_overloadI deal with a lot of different clients on a daily basis. It is a bit of a chore to figure out how to tie together their different messaging apps in order to interact with them and be alerted of any needs or emergencies.

The Problem

Most clients nowadays use either Slack, HipChat, Google Hangouts, and Skype. With Slack and HipChat being most popular in my regards. The main issue I have is that I use Linux and the Slack web interface is a resource hog and can only monitor one client at a time. Whichever one is loaded at the time. The HipChat web interface is a bit lighter but the same issue persists as with Slack.

The Solution

Luckily with Slack you can enable either (or both) XMPP and IRC. With HipChat you can only enable XMPP.

For Slack you go to Admin Settings and enable both or your choice:

Admin Settings | Tarnover Slack 2016-07-21 12-52-29

Continue reading

The Anatomy of a Flash Sale Fail

5108445245_05c05b2647_b

Over Capacity? photo by Tony Alter (Flickr)

Capacity planning is not a black art. But when it comes to sites doing a scheduled flash sale or a person with a large number of social media followers (over 1mil) it can get ugly fast! I witnessed this today for a site that was opening up new memberships at a specific time. Their site runs on Magento and that is about all I know since they are not a client. To not help matters they were also using Cloudflare which just showed their own error message.

error-magento

So how can this be prevented? 

Magento and most LAMP applications like WordPress are known for not scaling very well. You have to leverage caching and CDNs along with using the correct config files such as my.cnf (MySQL) to optimize performance. Using default configurations will NOT do you any favors!

If using Amazon Web Services (AWS) you should be leveraging:

  • Caching
  • RDS Cluster (MySQL)
  • ElastiCache (memcached)
  • Auto-Scaling
  • Correct EC2 Sizing
  • Elastic Load Balancers (ELB)
  • CloudFront (CDN)

Getting back to the example that inspired to me write this. During the first hour the complaints on their Instagram were quick and heavy. Users even taking pictures of the Cloudflare error page and posted those in frustration. Needless to say it is not the best PR after building up to an event and getting more interest than you saw coming. After two hours they gave up and posted a page to postpone their event. With correct capacity planning and configuration of Magento this could have gone much better!

IG-fail

If you’d like help scaling your site please feel free to contact me or visit my company site – http://tarnover.com