Tag Archives: Websites

What Is An SLI?

In a previous post I covered what an SLO is: What is an SLO?



To provide a brief summary, an SLO is a Service Level Objective, or rather a target that we aim for when providing a service to customers. It allows us to draw a line in the sand in regards to how well we are operating.

Once we know where we want to aim with our SLO, we have to dive deeper into knowing if we are getting there. While the SLO defines what our objective is, we need a measuring stick to truly know if we are meeting that objective or not. Insert the SLI.

An SLI, or Service Level Indicator, is that measuring stick. But how does it actually work? I think the best way to understand the relationship between an SLO and an SLI is with an example.

Advertisements

Let’s say we’re at a carnival and we happen to stroll by a few games. One of the games is a basketball game. Make as many baskets as you can in 1 minute. Well there’s your objective right there, make baskets.

But it’s not quite an SLO yet. To be an SLO, we need to have a target, so let’s be really aggressive in this example and say that we want to make 99% of our shots. Two 9’s of bucketability.

photo cred: Markus Spiske

Now that we have our SLO (99% of buckets made) we need an SLI… Something to measure how well we are doing. We could of course count the number of shots made by hand but let’s say we’re a single carnival vendor running 3 or 4 booths. Go even bigger, let’s say we’re a multi-million dollar company trying to put an SLO on system Response Times. You gonna count those by hand?

Me either.

So let’s automate this and have our basketball game install a little flipper inside the basket so every time a shot goes in, the flipper gets pressed down, and the score on the game goes up by one. That little flipper is our SLI. It is our tool for measuring how well we are doing. How close we are to being at two 9’s of bucketability.

Now let’s bring in a player. Our player comes in and starts shooting. They play quite a few games and they end up making 194 out of 200 shots (ballin‘) which translates into a 97% shot rate. Since our SLO is 99% of buckets made, this would fall below our SLO.

Our SLI, or indicator, should then properly alert and/or notify us that we are not meeting our objective and that we may need to make changes. So let’s send our player out to training for a few days. Let’s improve the system that makes buckets per se.

Once our player returns, we line them back up, and have them start shooting again. This time around they make 198 out of 200 shots nailing the 99% SLO!

Advertisements

We’ve just used our SLI to track how many shots were made and then to notify us when we were below our SLO. We used our SLO to recognize we need to provide more training for our player and after doing so, we’re able to re-utilize our SLI to confirm the improvement. Buckets!

While this example was very simple, in a world of technology where counting goes from 200 buckets to 2 million web requests over an hour, having an automated SLI becomes critical to properly measuring where your system is at in regards to the service it is providing to your customers.

The only thing worse than not providing great service with your products is not knowing the service you’re providing at all.


Where to Store Website Credentials

I have searched the internet far and wide trying to find the best answer to this question. Where is the best place to store website credentials and API keys?

There are a lot of options ou there but none of them have really given me any level of satisfaction that I’m looking for. I could store credentials like usernames and passwords in a web.config but then I would have to consider how I store that in source control as well as the risks of storing it in plain text.

Sure I could encrypt that web.config before deployments but I still have the problem of dealing with source control. That just isn’t going to work.

I could go about storing the credentials and API keys in a database. This is a slightly improved solution but then again… how do I store a database connection string and credentials to that database outside of the database to allow connection to it?

photo cred: Campaign Creators

I could use Windows Authentication but what if my stack changes or doesn’t support Windows Auth? I also then still need to consider encrypting my database and the credentials or API keys so they aren’t stored in plain text. And then what if I wanted to check one of those values, I’d have to decrypt it as well…. omg what a pain in the ass this is…

The real truth is there isn’t an easy or best way to store website credentials and API keys… until AWS Secrets Manager came along.

AWS Secrets Manager offers an offsite option for storing all of your credentials, database strings, and API keys. It is quite literally a one stop shop for all your secret storage needs.

Advertisements

The way it works is by allowing you to use your AWS Access Key ID and AWS Secret Access Key (basically your AWS authentication) to create an AWS Secrets Manager client. Using this client you can then request credentials from AWS to be served back to your code repository. It’s actually so easy to implement that I managed to do it in a handful of lines of code:

new AmazonSecretsManagerClient(RegionEndpoint.GetBySystemName(region));

One of the best things is AWS allows you to handle authentication by creating environment variables for your AWS client and allowing your code base to utilize those to complete the authentication to AWS. This makes it very easy to move your code base through various test environments without having to worry about changes in each environment.

AWS also offers a cache solution for your Secrets Manager Client. You see each time you connect to AWS to retrieve a secret like credentials there is a small cost associated (we’re talking pennies here). This isn’t much until you consider having to grab these credentials on each web request which can easily climb into the thousands and skyrockets costs.

Advertisements

Thankfully AWS offers the cache solution which let’s you pull the secrets once and then cache them on the server side. This avoids having to poll AWS for a the secret every time it’s needed and greatly reduces cost. Thanks AWS! Oh and it’s also very easy to implement:

new SecretsManagerCache(client);

And when you’re ready to actually pull the secret from AWS:

var secret = await cache.GetSecretString(secretId);

AWS Secrets Manager also offers a handful of other sweet benefits. You’re able to automate password rotation for AWS services like RDS, Redshift, and DocumentDB and of course you get the security that comes with using AWS. There are also some fantastic Auditing features, my favorite being that when a password is deleted it is stored for 7 additional days and managing parties are notified of the delete. No accidents!

All-in-all AWS Secrets Manager is a fantastic solution to the, “How do I manage my credentials for my applications” problem. The cost is very minimal when used in conjunction with the caching feature and the overall complexity to implement the solution is minimal. If you’re looking for a next-gen solution to managing sensitive application data I highly recommend AWS Secrets Manager.