DEV Community: Winnie Kiragu

Configuration management (CM); It's origin, equivalence and contrast to IaC.

Winnie Kiragu — Mon, 23 Oct 2023 13:04:43 +0000

Configuration management is a technique used to support high velocity development workflow by identifying and tracking individual configuration items.

Automation really is the heart of configuration management, but CM revolves around treating the underlying infrastructure with exactly as much rigor and automation as we would treat the underlying application/service.

Traditionally CM was implemented to oversee physical enterprise compute and storage and network hardware, today CM is typically implemented in the form of software tools that the organization uses to enforce a desired configuration state for each item and provide timely alerts of any configuration problems.

However the approach should be broadened further to systems engineering and governance to embrace ever-advancing practices such as software-driven infrastructure and it can be codified in standardized frameworks for e.g ITIL.

What is the ITIL Framework?

If you've studied/worked in tech, then this must bring some deja-vu ;
if not, it's totally okay.

ITIL v3 framework is a set of best practices, processes and procedures that organizations can use for digital service management by leveraging its adaptable models and procedures for continuous improvement to end-user services. It's recognized internationally for setting the standard for IT service delivery.

The dimensions, pillars and gemstones of this framework I will leave unto you dear reader, but that may extend a bit outof this post. My intention was to showcase where Configuration Management evolved from.

There are multiple ways how using the configuration management practice would benefit the organization. A few are:

Quick provisioning of new compute hosts
Centrally modify base configurations
Version control for the compute host environments.

While this may sound in an essence like Infrastructure as code, its slightly different. Most times, the two could be used inter-changibly depending on the complexity of your infrastructure. But let's take a look at them abit more closely to see when you may need to use either.

Infrastructure-as-Code

Infrastructure-as-Code is used to automatically create any service or system in the cloud or on-prem with code. Infrastructure-as-Software; which is somewhat similar to IaC in a way, is defining your infrastructure (either on cloud or on-prem) with a general-purpose programming language like Python or Go or with tools such as SST

The key differentiator with Infrastructure-as-Code and the manual way of creating systems and services is that it's done by writing code.

Comparison

Infrastructure as Code (IaC) and Configuration Management are two related but distinct techniques used to manage IT infrastructure. Below are some similarities and differences between them:

Similarities:

Both approaches aim to automate infrastructure management and reduce the manual effort required to provision, configure, and manage infrastructure resources.
Both approaches rely on defining infrastructure resources and configurations as code, which can be version-controlled, tested, and deployed using automation tools.
Both approaches help ensure consistency and reduce the risk of configuration drift, which can lead to performance and security issues.

Differences:

IaC primarily focuses on automating the creation and management of infrastructure resources, such as virtual machines, storage, and networking. Configuration Management, on the other hand, focuses on enforcing consistent configurations across multiple servers and applications.
IaC tools are typically used for cloud infrastructure, while Configuration Management tools can be used for managing both cloud and on-premises infrastructure.
IaC is often used for defining infrastructure as part of the application development process, while Configuration Management is typically used for ongoing maintenance of the infrastructure.

In summary, while both techniques differ in focus and scope. IaC is primarily used for automating infrastructure creation and management, while Configuration Management is focused on enforcing consistent configurations across infrastructure resources.

But keep in mind that both approaches are uniquely important for managing stable, scalable, reliable, and secure infrastructure.

Monitoring in AWS

Winnie Kiragu — Mon, 26 Jun 2023 12:29:14 +0000

Monitoring Containers in AWS

Monitoring is crucial for all deployments as it lets you debug and gain a deeper understanding of the application you are trying to develop/maintain. This article is meant to help you get comfortable with logging/tracing on AWS for serverless infrastructure.

For AWS serverless infrastructure like Lambda/App Runner, troubleshooting may be one of the most difficult tasks, especially for those coming from a more traditional VM-based development infrastructure as you cannot log on to the VM or docker images.

There are several monitoring services that you can use that are easily integrated and managed depending on your use-case or application needs. While working with container workloads on AWS, one of the easiest ways to get started with monitoring is to leverage AWS monitoring tools. You can always use these third-party services. However, be cognisant that they do not increase the operational complexity for maintaining or deploying your application.

To begin, let’s be in the know that AWS CloudWatch collects monitoring and operational data in the form of logs, traces and metrics.

A) Logs

AWS documentation of log concepts cant be beat. They really do capture everything in a very easy to understand way. And as always, its best practice to always refer to the official documentation.
Truthfully, the most difficult thing about navigating this is finding the particular cloudwatch group/stream. To ensure you dont get into this loophole, always ensure you label your log groups properly when creating them.
Enabling logging through AWS Cloudwatch is automated for you if you are working with serverless infrastructure e.g ECS, EKS, Lambda or AWS App Runner. It's as simple as clicking on a checkbox to enable logging.
Self managed infrastructure requires abit more configuration, but be sure to label the log groups to also distinguish log groups for your dev environments and for your prod environments.
Tagging resources is also a great way to easily track the correct log groups, so review AWS documentation on tagging and evaluate if you may need to adapt anything in your current tagging processes.

B) Traces

A trace collects all the segments generated by a single request. That request is typically an HTTP GET or POST request that travels through a load balancer, hits your application code, and generates downstream calls to other AWS services or external web APIs.
X-Ray is also located on the AWS Cloudwatch dashboard under the Xray traces tab.
AWS X-Ray provides a visual map of successes and failures and lets you drill into individual traces for an execution and drill down into the details of how long each leg of the execution took.
You can only view your application traces if you had enabled your application to collect this data. Dont be weary though, AWS Xray does not incur any additional fee or committment fee for either storage of these traces or for retrieving/viewing this data.
The only downside is that as of now is that it is not able to to enable tracing in quite a few AWS services, but if you are setting up your infrastructure with AWS Lambda, this is something you may want to try out.

C) Metrics

A metric represents a time-ordered set of data points that are published to CloudWatch.
Think of a metric as a variable to monitor, and the data points as representing the values of that variable over time. For example, the CPU usage of a particular EC2 instance is one metric provided by Amazon EC2.
Metrics belong to namespaces ie Ec2, Lambda. What this means is that collected metrics are available in CloudWatch automatic dashboards, and also viewable in the Metrics section of the CloudWatch console. Within these dashboards, they are organized into namespaces. Check it out...lolz (see me trying to get you to log into AWS there...haha)
I've mentioned something pretty cool here that I want to also talk more about; i.e CLoudwatch container insights.

CloudWatch Container Insights

CloudWatch Container Insights makes it easy to collect metrics like CPU, memory, disk, and network utilization, as well as log information, in one centralized location.
AWS documentation on using container insights defines that this service can be used for your containerized applications and microservices, meaning this AWS functionality is easily integrated with AWS ECS, EKS, Lightsail, Lambda, App Runner and most recently Kubernetes platforms on EC2.
The metrics that Container Insights collects are available in CloudWatch automatic dashboards, and also viewable in the Metrics section of the CloudWatch console.
SO what's different here, If I can view the metrics on the metrics page too? - I know, it seems redundant, but the difference comes in the categorization....viewing metrics on the Metrics section categorizes these into namespaces i.e Lambda, Ec2, Lightsail, but for the metrics you view on the cloudwatch container insights section, you can view all metrics for all applications running in containers across the entire AWS services.
What does that even mean, right? - In simple terms, If I wanted to evaluate all applications running in all my ECS clusters, instead of viewing each applications metrics individually, Container metrics allows me to pull up all of these stats in one place. There I can evaluate how applications are fairing with resources allocated to them.

All this great, but how will Cloudwatch Container insights affect my wallet?

Metrics that cloudWatch container insights collects are limited i.e it does not automatically create all possible metrics from the log data, however, you can view additional metrics and additional levels of granularity to your log data then use CloudWatch Logs Insights to analyze the raw performance log events.
Be careful though as additional metrics collected by Container Insights are charged as custom metrics. Always make it a point to review Amazon CloudWatch Pricing before committing to any additional service as good practice.

Please take a moment to go through Cloudwatch container Insights, but remember as with any other resource on AWS to decommission your resources after testing to avoid unnecessary costs.

Feel free to go through these reference materials to familiarize yourself better with AWS Cloudwatch and its offerings:

These are a few of the tools I have learnt to use within the AWS eco-system to monitor the containerized applications I deploy. Thankyou for getting to the end of this section of my blog.

Monitoring Databases in AWS

RDS is one of the most expensive resources you can use within the aws eco-system. Especially if not managed right.

I want to recap abit before I get into this second segment of monitoring to help you understand why I felt this necessary to add this segment here.

What are the 3 AWS pricing principles? - compute, storage, and outbound data transfer. Go ahead google it....go on (lolz)

- Every database we create by default incurrs costs.
- The more data we store in each of these databases(per GB), then the more we have to cough up to AWS for costs.
- Also let's be cognisant that every production database might have atleast 1 snapshot taken ,let's say once a month for this article, but we all know we take waaaaay more snapshots per month.
- These snapshots also incur costs, esp if the snapshot also holds alot of data just like the prod db.

What I am trying to point out here is that we need to understand how our database is performing and re-evaluate allocated resources frequently also to avoid unneccessary costs.

So let's expound on this abit more, shall we?

What to Monitor

There are three different types of monitoring that can be captured here:

service monitoring via CloudWatch,
database monitoring via Performance Insights (also submitted to CloudWatch),
OS monitoring with Enhanced Monitoring.

RDS as a AWS service publishes different types of metrics to CloudWatch in this respect. These broken down can be looked at as:

Metrics for your DB instances, e.g., CPU utilization, the number of database connections, available memory, network throughput, and read latency.
Performance Insights metrics, e.g., the number of active sessions for the database engine.
Real-time data about the operating system on which the DB instances are run — more on this later.

Service Monitoring via CloudWatch

By default, RDS sends metrics to CloudWatch in one-minute intervals. These metrics are stored for 15 days, enabling you to run analytics for historical data to gain service performance insights.
To configure your RDS instance to log to Cloudwatch, there are some things you need to do on the AWS Management console. Kindly follow this aws tutorial to set this up.
Usage metrics for RDS service quotes in your AWS account, e.g., the total allocated storage of all your database instances or the number of instances itself.

Performance Insights - Monitoring Database Load

RDS’s default metrics only help you to visualize and analyze the general load on the database, but it does not provide you with detailed insights about the cause of the load for certain types of workloads.
With Performance Insights, you’re able to filter loads in a very fine-grained manner, for example, by using SQL statements. This will help you to determine major contributors to heavy loads or bottlenecks affecting your service’s performance.
Performance Insights need to be enabled explicitly for your DB instance or Multi-AZ cluster. If you want to keep data collected by Performance Insights for longer than seven days, you’ll receive an additional charge.

Enhanced Monitoring - Monitoring Operation System

In addition to monitoring your database instances, you can also monitor the underlying operating system.
The major difference between the default CloudWatch monitoring and Enhanced Monitoring lies in the collection of metrics: Enhanced Monitoring directly collects statistics via an agent running on the DB instance instead of the hypervisor that creates and runs the virtual machines.
Enhanced Monitoring collects a lot of additional metrics from the OS in real time. This is useful if you’re interested in the different processes or threads that are using the CPU.
An important fact here is that Enhanced Monitoring collects its metrics in CloudWatch logs. This means the data transfer and storage of CloudWatch Logs will increase, and you’ll receive an additional charge. Shorter monitoring intervals (meaning a higher frequency of monitoring) or a higher number of DB instances will increase pricing.

So now that we have an inkling on what you need to review for the RDS service, kindly make a point to go and check this out and adapt effectively.

It's always a pleasure to learn and walk you through my thoughts. Kindly drop a comment if you have any other thoughts or questions.

AWS CUR (Cost and Usage Reporting) for beginners

Winnie Kiragu — Mon, 26 Jun 2023 10:06:26 +0000

When anyone sees this image, they instinctively laugh because we have all heard the stories. We all know how cloud platform bills like AWS bills sky rocket because of the simplest things like not decommissioning an ec2 instance.

While managing costs on cloud computing platforms is a topic on every person's mind, it's not really something everyone would want to get involved with. To be honest, when it comes down to overviewing this discussion, most would rather avoid it and cross their fingers hoping for the best.

I'd like to debunk this fear in this article.

Cost and Usage reporting is such a broad topic that you can never really find an article/blog that is very specific to your needs.
This shouldnt dis-hearten you, on the contratry, you simply have to envision the journey with the following steps:

1. Understand your cloud expenditure.
2. Data collection and analysis on existing usage
3. Presentation of your report data

These 3 steps sum up what you need to do. But when said like that, it can still appear like an uphill task for someone new to creating CURs (Cost and Usage Reports).

Let's break these steps down a little further to de-mystify the whole process, shall we?

1. Understand your cloud expenditure

This can often be challenging, esp for individuals/organizations that do not have any kind of reporting procedures in place.

Ultimately this goal can be simplified into understanding these 3 areas:

1. How do you govern usage?
    - Are there specified individuals who can build cloud infrastructure?
    - Are there any existing policies/processes in place for this?
2. How do you monitor usage and cost?
3. How do you decommission resources?

If your the one establishing this new culture, you may need to evaluate the 3 areas and set up strategies around the same. If an existing cost reporting culture already exists, then you may have gotten off on a less upill task.

LIke with any discussion on policies and procedures, you may need to have a conversation with relevant project/product owners to gain better understanding on reources in use, resource creation policies and of course decommissioning policies.

For readers of this article that need to build these processes and procedures from scratch, have a deeper look at how current operations handle the following:

1. Review existing tagging strategies, if any. Cost Allocation Tags (CATs) are crucial to understand here, if they do have any in place.
2. Review existing billing alerts, if any.
3. Review decommissioning policies, if any.

If none of the above already exists, you may need to define these before you proceed. Ensure to build these out with relevant product owners as stated earlier in this article.

To learn more about best practices when creating tags to your cloud resources, see AWS Tagging Strategies. Remember, the same strategies can be applied to other cloud platforms, not just AWS, but with slight tweaks here and there.

Billing alerts and decommissioning policies creation are outside the scope of this article but also play a vital role in establishing an appropriate cost reporting culture within every organisation. Look them up tafadhali.

2. Data collection and analysis on existing usage

So in the first step, we were doing a high level overview for how your particular org goes about reporting. But now we need to put values to these overviews.

All cloud providers provide these figures to you a billing dashboard of some sort. You can always look these up according to your preferred cloud platform.

Fetching this usage data from AWS, for example, can be done in 2 ways; UI Console/ or CLI (Command Line Interface)

If you are working with multiple cloud providers, you will need to aggregate cost data from the different vendors. Same logic, just different user interfaces or CLI commands.

Via Console

AWS, for example, provides to help you get started:

1. AWS Cost and Usage Report feature.
2. AWS Cost explorer.

They sound the same, but they are slightly different.

AWS Cost and Usage Report(CUR) tracks AWS costs and usage at the account or organization level by usage type, operation, and product code.

To view cost and usage breakdown by service, you can view the Cost Explorer tab and generate the same report by service for whichever stipulated timeline you would need this for.

Via CLI

The aws ce command with the appropriate directives returns your data easily. For e.g

To get the daily expenses for the last X days

aws ce get-cost-and-usage \
    --time-period Start=$(date +"%Y-%m-%d" --date="-240 hours"),End=$(date +"%Y-%m-%d") \
    --granularity=DAILY \
    --metrics BlendedCost UnblendedCost \
    --query "ResultsByTime[].[TimePeriod.Start, Total.BlendedCost.[Amount][0], Total.BlendedCost.[Unit][0]]" \
    --output table

To get monthly expenses for the AWS Account

aws ce get-cost-and-usage \
    --time-period Start=2023-01-01,End=2023-06-01 \
    --granularity MONTHLY \
    --metrics "BlendedCost" "UnblendedCost" "UsageQuantity"\
    --query "ResultsByTime[].[TimePeriod.Start, Total.BlendedCost.[Amount][0], Total.UnblendedCost.[Amount][0], Total.UsageQuantity.[Amount][0], Total.BlendedCost.[Unit][0]]" \
    --output table

The two alternatives will give you an easy way to acquire the usage data you need to get started on analysis.

For this, no amount of explaining will help you understand/ get a visual of what I'm saying. You just have to get your hands dirty and explore how to fetch this information from your preferred cloud provider and how to analyse the information you receive in turn.

3. Presentation of your report data

AWS documentation states that a good Cost and Usage report should offer a comprehensive details on the following:

Metadata about AWS services,
Credit,
Pricing,
Fees,
Discounts,
Taxes,
Cost categories,
Savings Plans
Reserved Instances

But this should not get you tripping. You can always start with a simple report containing the following columns:

Service in Use	Spenditure category	Saving Opportunities
RDS	Storage	Text
EC2	Compute	Text
EKS	Outbount transfer	Text
ECS	Outbount transfer	Text

N.B

The level of detail and granularity in cost and usage reporting and monitoring is dependant on your target audience, so always start simple and build according to feedback you receive from your team.

The segment detailing Saving Opportunities is also an important aspect to include in these discussions with your team, so it is essential to make room for this on the report, even if you have nothing on this segment when you are presenting the report, as this will help you easily remember this during your meeting.

Some terminologies you may need to know when working with AWS Billings are:

Blended costs - Blended costs are calculated by multiplying each account’s service usage against something called a blended rate. A blended rate is the average rate of on-demand usage, as well as Savings Plans- and reservation-related usage, that is consumed by member accounts in an organization for a particular service.
Unblended costs - Unblended costs represent your usage costs on the day they are charged to you.
Amortized costs - Amortized costs are a powerful tool if you seek to gain insight into the effective daily costs associated with your reservation portfolio or are looking for an easy way to normalize cost and usage information when operating at scale.

As always refer to aws documentation on costs for reference. Other cloud providers may have different terminologies, so get familiar with those as well.

Lastly, a Cost and Usage report may be needed weekly/monthly, so you can easily automate this process by building a simple REST API application and leveraging the AWS command line. I personally think that is a great next project for anyone who has gotten this far in myblog, don't you reader?