Forem: Taylor Brazelton

Logging Best Practices

Taylor Brazelton — Tue, 22 Jun 2021 18:57:24 +0000

Here are just a few bullet points I've gathered over my career about logging.

Log to STDOUT/STDERR

Stop following all the online tutorials for your framework that configure your application to store logs directly in files. This is a rookie mistake and makes running your application so much more difficult than it needs to be. Instead, give your ops team better lives by sending your logs to stdout/stderr. This allows OPs to decide how to process and send off logs. They might choose to write them to disk, perform some cleanup data processing, or simply send logs to an external system. By logging directly to stdout/stderr you give them the choice.

"A twelve-factor app never concerns itself with routing or storage of its output stream." - 12 Factor App

Format Your Logs

You don't know how important good, standard formatting can be until you have to sift through multiple log files across different machines. Define a standard formatter and enjoy. I personally like the idea of all logs being provided as JSON dicts. Doing so makes parsing so much easier by logstash. I also, don't have to worry as much about log format changes.

Centralize your logs(i.e. devops)

This can't be understated. As the software grows so do the sources of your logs. Moving around amonst EC2 instances that log directly to ephemeral storage is a pain. Especially if one of those instances is terminated by autoscaling, which you needed the logs from to help with a customer support ticket. You'll thank me for this tip one day.

I recommend setting up an ELK stack for this action, or perhaps use a paid tool like datadog.

Auto vs Programmer Generated Logs

The importance of having both auto generated logs and programmer logs can't be pushed enough. Auto-generated logs give you insights into everyday events such as GET and POST events to certain api endpoint, meanwhile programmer logs give you the insight into who did what when. The combination of these two types of logs are instrumental to addressing customer service needs.

Date-Time Formats

Spitting out datetime values as human-readable seems like a good idea, until you are tasked with parsing through the logs using a datetime range. Use the unambiguous format ISO-8601. You'll pat yourself on the back for doing this one, as it makes navigating your logs much easier.

Add Logging Context

It's difficult to navigate logs when they have no context. These are three must haves for any SAAS application.

Tenant ID - Know the active tenant.
User ID - Know the user performing the action.
Request ID - Usually provided by your Load Balancer. Look at the X-REQUEST-ID header. Allows you to see all the logs associated with a single request.

Conclusion

At the end of the day, I hope you take logging a bit more seriously. Your customers and users deserve it. Till next time. Peace

Original Posted on my Personal Blog: https://taylorbrazelton.com/2021/06/22/2021-06-22-logging-best-practices/

Docker Image Size Reduction

Taylor Brazelton — Tue, 05 Jan 2021 16:22:58 +0000

Recently I needed to dockerize an application for a virtual onprem. However, at the end of my project I ended up with a docker image that was 8.4 GB. This is HUGE in terms of size for a container. Thus, I went on a short journey to minimize the image using the following techniques.

1) Prevent APT from installing recommended packages by adding the following parameter to every apt-get install command: --no-install-recommends.

2) Added a .dockerignore file. This allows one to define a list of folders/file globs to ignore when building your Dockerfile.

3) Reduced the amount of layers by merging related commands.

4) Clean up apt cache via: && rm -rf /var/lib/apt/lists/*.

5) Used dive to inspect my image layers to analyze and remove extra unused packages/files.

6) I stumbled across a tool docker-slim that can supposedly reduce a container's size by up to 30x.

7) Check your base image. Think about running an alpine version of the container if you haven't already.

8) Use multistage builds.

9) Use your layers wisely. Put commands that are more likely to change towards the bottom.

10) Lint your dockerfile using FromLatest

Sources:
https://ubuntu.com/blog/we-reduced-our-docker-images-by-60-with-no-install-recommends
https://towardsdatascience.com/slimming-down-your-docker-images-275f0ca9337e

AWS Vault and MFA Setup on my Mac

Taylor Brazelton — Tue, 27 Oct 2020 15:22:57 +0000

Recently, I decided to secure my local machine by downloading and using AWS Vault. To my surprise, setting up MFA with Vault required a step or two more that I wasn't expecting. Here are my findings/steps.

First, I used homebrew to install aws-vault.

brew cask install aws-vault

Then I added my profile and followed the instructions which had me provide my Access ID and Secret.

aws-vault add taylor

Then I tried to list out the S3 buckets via:

aws-vault exec taylor -- aws s3 ls

This resulted in the following error.

An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied

So I opened up my AWS config file in Visual Studio Code.

code ~/.aws/config

Doing so lead me to see that my profile didn't have a mfa_serial variable defined. I found my key in IAM under my own user's Security Credentials tab and added it to the file.

Now, my config file had the following in it:

[profile taylor]
mfa_serial=arn:aws:iam::XXXXXXXXXX:mfa/taylor

And when I performed my s3 listing again, it worked.

AlgoliaQB - First Release

Taylor Brazelton — Fri, 28 Aug 2020 18:21:01 +0000

Today I am releasing the first version of Algolia Query Builder. Its purpose is to make generating a filter query easier. You can then pass the generated query directly into the algoliasearch search function. Hopefully, this can help make others' lives easier as well as my own.

Installation:

pip install algoliaqb

Usage Example:

from algoliasearch.search_client import SearchClient
from algoliaqb import AlgoliaQueryBuilder
from flask import request


aqb = AlgoliaQueryBuilder(
    search_param="search",
    filter_map={
        "group_id": "tenant_id",
        "is_reported": "is_reported"
    }
)

# Extract the search query from our flask apps request.args var.
search_query = aqb.get_search_query(request.args)
# Get the filter query from our request args.
filter_query = aqb.get_filter_query(request.args)

# Now that we have the filter string, we just pass it into the search function.

search_client = SearchClient()
index = search_client.init_index("contacts")
results = index.search(search_query, {"filters": filter_query})

For more information please checkout Github or Pypi.

Minimum Requirements for a SAAS Platform

Taylor Brazelton — Wed, 22 Jul 2020 02:39:19 +0000

Below is a list of minimum requirements I believe are vital to the success of a SAAS platform(Note that this isn't the word product)

Authentication Strategy(Email, Username, Social, etc..)
Multi-Tenant Setup
Database Migrations
Queuing Mechanism(RabbitMQ, Redis, etc..)
Caching(Redis, Memcache, etc..)
Configuration Management
Search Tools(Elasticsearch, Algolia)
Unit Tests
Integration Tests
Deployment Strategy
Dockerfied Development
Dashboard for Statistics(Grafana, Redash, etc..)
Hosting Provider

Always try to think through these items before digging into the code. I have found that by doing so you significantly reduce the problems you will run into when trying to scale your product and team.

Help Validate My Idea (Seeking Home Owners)

Taylor Brazelton — Thu, 16 Jul 2020 01:17:17 +0000

I am working on generating an idea for SAAS that helps homeowners manage their projects at home. Everything from painting, to replacing one's floor, I feel like there should be some digital book you can use to keep track of these changes. Kind of like GitHub but for your home. Therefore I am looking for a few homeowners to answer some quick questions I have in a survey posted below.

https://forms.gle/PX9jrxAGquRK3qKUA

Sincerely

Taylor Brazelton

The Bad Multi-Tenant SAAS Pattern

Taylor Brazelton — Wed, 15 Jul 2020 01:58:51 +0000

Note: This article assumes PostgreSQL.

Multi-tenant web apps are currently all the rage. Just take a look at the top tech stocks for July of 2020. Adobe, Salesforce, Microsoft... most if not all of them provide some sort of software as a service. SAAS has taken the web by storm, but there is one specific hidden pattern that is being taught that I MUST ADDRESS.

The majority of data access strategies for multi-tenant applications are garbage. If you search the web, you'll find lots of articles giving multiple solutions to this problem. Let's go ahead and list the main ones below.

Shared database and shared schema.
Shared data and separate schemas per tenant.
Separate databases per tenant.

From the list above the bottom two are DEAD wrong. You might wonder.. but why Let me dive in deep.

First up is database resources.

Since Postgres defines one file on disk per table, you will have a hard limit at the maximum amount of files allowed in a single folder. What is that limit? Heck, do you even know what operating system your database server is even running on? How good is your kernel at handling this madness?

Next, lets talk about migrations.

SAAS apps use migrations. It's the easiest way to make changes to the database schema while keeping track of them all. This also forces us, developers, to think more in-depth about our changes since they will go through peer reviews. Imagine having to run a migration on a few of your tenant's databases or schemas.. not horrible but the computational complexity for a multi-database or shame approach raises the migration bar from O(1) to O(n), where n is the number of tenants you have. Now imagine your app takes off.. grows to a couple of thousand tenants. That's quite the wrench in your CD/CI process. Might as well use the waterfall methodology from this point forward.

Issues with Active Records ORMs.

ORMs are a tool that almost every app uses nowadays, they are the essential workers of the SAAS world. ORMs that follow the Active Record pattern have one main thing in common, they all reach out to the database to load up a metadata blob full of them juicy table details. This will dramatically increase your process size when starting up your production servers. Thus unnecessarily bloating your app servers. Say bye-bye to those AWS Dollar bills.

Global Reports

Someone from the business side of the house wants a report that contains stats from all of your tenants... Good luck. Who would have realized that you now have duplicate ids across your accounts tables? Joins be damned.

Conclusion

Hopefully, I've given you a little insight into why you shouldn't start that multi-tenant app using multiple databases or schemas. Yet if you must, I'd love to know how you solved my list of problems. Please leave me a comment with some feedback. Perhaps I missed a pain-point you had to deal with. Enlighten me.