DEV Community: Developers @ Asurion

All the MongoDB Commands that You Need to Know

Kaye Alvarado — Fri, 24 Jan 2025 08:44:45 +0000

Here is a collection of common NoSQL queries and the mongodb commands needed for them:

1. Exact Match

Collection Name: users
Object Field: first_name
Search for: Kaye

db.getCollection('users').find({"first_name":"Kaye"})

2. Like Match

Collection Name: users
Object Field: last_name
Search for: varad

db.getCollection('users').find({"last_name":/varad/})

All the Git Commands that You Need to Know

Kaye Alvarado — Tue, 07 Jan 2025 05:29:52 +0000

Here is a collection of common scenarios of code management and the git commands needed for them:

1. Clone a repository to your local branch

git clone https://github.com/<organization>/<repository_name>.git

2. Check if the current state of your local branch

git status

3. Commit a change from your local to the remote repository

After doing edits (add/update/delete) to the files in your local repository, you can make them available to other developers by pushing your changes to the remote branch. First, stage the changes:

git add <path>

Alternatives

git add --all
git add .
git add ../subpath

You can then add a commit message to your check-in. Some developer teams follow the Conventional Commit specification when adding commit messages, which dovetails SemVer and makes it easier to publish release notes based on widely known standards.

git commit -m "commit message"

After adding a commit messsage, you can then push the change to a remote repository. If the remote_branch_name already exists in the remote repository, a simple git push command will do.

git push -u origin <remote_branch_name>

4. Revert to a previous commit in the remote branch

There are times when you accidentally push a commit to an incorrect remote branch and wishes to revert to a previous commit. You can follow the following steps in order to do this.
First identify the commit id by checking the git history

git log

You can then switch your local to an older commit_id

git reset --hard <commit_id>

Then, force push the current state of the branch to the remote branch. Make sure that there are no restrictions in the remote branch against force pushes.

git push -f origin <remote_branch_name>

5. Reset commit history in a git repository

These sequence of steps will essentially reset the git commit history of the remote repository by overwriting the main branch (which contains all commit history) with a fresh branch that contains all the files of the main branch:

git checkout --orphan temp-branch
git add -A
git commit -m "reset history"
git checkout main
git reset --hard temp-branch
git branch -D temp-branch
git push -f origin main

6. Deleting local and remote branches

[for local branch]
git branch -D [branch-name]
[for remote branch]
git push origin -d [branch-name]

7. Squash multiple commits

View the list of commits in the current branch with git log, then identify the start of the commit that needs to be squashed.

222bb33  Adjust tests
99aa111  add feature
def5678  fix: type
abc1234  initial commit

In the results above, I want to combine the commits from def5678 to 222bb33 to a single commit. With this, start interactive rebase with the commit before the first in the range which should be abc1234

git rebase -i abc1234

In the editor that opens, change the top commit as pick and change the subsequent ones that needs to be squashed to that commit as squash. Then, save and exit.

pick def5678  fix: type
squash 99aa111  add feature
squash 222bb33  Adjust tests

Push to the remote branch.

git push --force-with-lease

And that's it! Let me know if you have questions in any of the use-cases!

Are there any other common scenarios in code management that is useful to you? Leave them at the comment section for others!

K8s QuickBites: Helm Basics

Kaye Alvarado — Mon, 26 Aug 2024 01:12:00 +0000

Hey there! Welcome to another quick bites blog on Kubernetes. Read time, 2 minutes! I like to keep it short and serve as quick references only when doing common tasks as a K8s administrator.

The focus of this discussion is on Helm.

What is Helm?

Think about bringing up an end-to-end application in Kubernetes with multiple yaml files that includes various resources such as deployments, service accounts, secrets, and others. A simple application would have some complexity in management, but as it becomes larger, it would be very difficult to manage. This is what helm is trying to solve.

Helm is nothing but a package manager for Kubernetes. Helm is used to manage Charts, which are packages of pre-configured Kubernetes resources making application management in Kubernetes way easier.

Installation of helm is pretty straightforward and options can be viewed here.

Basic Helm Commands

First, search and download from a helm repository to your local machine. You can also update it if it already exists.

$helm search repo <repository>
$helm repo update <repository>

To view the existing repositories on your local machine, you can use the list command

$helm ls 
NAME         CHART VERSION   APP VERSION.  DESCRIPTION                                       
chart/name   1.0.0           1.0.0         App Description

Install Helm Charts

You can install a helm chart overriding the default values with a values.yaml file.

$helm install <chart> <repo> -n <namespace> -f <path to values.yaml file>

Once installed, you can then verify the deployments, daemonsets, or other resources that was installed

$kubectl get deploy -n <namespace>
$kubectl get ds -n <namespace>
$kubectl get pods -n <namespace>

You can also use the values used in the helm installation and modify this for a later update

$helm get values <release-name> -n <namespace>

Upgrade Helm Charts

Everytime you upgrade a helm chart, a revision is added and this allows you to easily rollback to a previous version if an upgrade becomes problematic. List the versions with the list command (for the current deployed chart), or the history command.

$helm list -n <namespace>
NAME   NAMESPACE  REVISION  UPDATED     STATUS   CHART  
chart  namespace  2         <datetime>  deployed chart-1.0.0
$helm history <chart> -n <namespace>
REVISION    UPDATED                     STATUS      CHART                   APP VERSION DESCRIPTION     
1           Thu May 23 18:53:23 2024    superseded  chart-0.9.9 0.9.9       Install complete
2           Mon Jun  3 19:52:28 2024    superseded  chart-1.0.0 1.0.0       Upgrade complete

To rollback to a previous version, you can use the rollback command

$helm rollback <chart> <version> -n <namespace>

There may be times when a simple upgrade will fail due to a major change in the helm package. An option here is to do an uninstall and install.

$helm uninstall <chart> -n <namespace>
$helm install <chart> <repo> -n <namespace> -f <path to values.yaml file>

...and that's it! Happy helming! 😄

Don't Dead End Your Dev Career: Using Communication to Amplify Your Possibilities

Bradston Henry — Thu, 22 Aug 2024 14:06:37 +0000

NOTE TO READER FROM AUTHOR:
This blog is primarily intended for Developers and Software Engineers looking for new ways to improve their career growth potential and attraction to possible future employers.

This is a practical approach to differentiating yourself from amongst your peers and is a brief summary of learnings I have gained from my experience as an Engineer, Software Developer, Team Lead, Interviewer, and Manager. I hope this information is as helpful to you, as it has been for me.

Thanks for reading and enjoy!

As a self-taught software developer, a developer relations manager and an aspiring and ever-growing writer, I've always clung to the belief that it's "All about what you do, not what you say".

That your 'work' should speak for itself, and that 'words' are "nice", but offer very little real value in a tangible sense.

But as I near my 10th year in the tech industry, I've discovered that the adage, “Talk is cheap” may not be as true as I once thought it was.

But that the real adage, especially for my fellow developers and software engineers, should be, “Talk isn't cheap, Talk is ESSENTIAL”.

Do What You Say and Say What You Do

As I look back on my software development career and my overall journey that has brought to where I am now, I have started to recognize a specific skill that has helped me to stand out amongst my peers. That skill is...

The ability to communicate clearly and effectively to those who I work with and those who I engage with, on any level.

I've truly come to realize, that the key to continued success is simply the ability to “talk” or, more aptly said, communicate.

My capacity to express my ideas clearly, if not always succinctly, has allowed me to convey my technical skills and abilities while adeptly navigating the minutia of the complex dynamics that come with intra-organizational functional growth.

“Wait?!? What did you just say?!?”

Essentially, having the ability to communicate has allowed me to showcase my technical skills more readily, while allowing me to navigate the difficulties that come with pursing “that promotion” or that position that I desire.

Having the acumen to speak on my technical ability to diverse audiences has made it a “no brainier” to hire me (or promote me) over candidates with similar skill sets and experience.

I haven't just “walked the walk”, I've “talked the talk”.

Over time, I've discovered that one of the most important skills needed to have an impactful career in software engineering, is the ability to communicate well.

"But I'm a Talented Software Engineer, Shouldn't my Skills Speak for Themselves?"

In a perfect world, humans would be able to easily identify exactly who is the best person for any given role by just simply looking at them.

“Yup! They’ll be the perfect accountant. I can see it in their eyes”

But in reality, determining competency and the ability to perform is a complex task. Finding the best person for any given role or opportunity can be incredibly difficult.

Great things (and even great people) are not easy to recognize, without something “speaking on its behalf”.

Let's take the cautionary tale of the movie Elemental.

Elemental, a Disney Pixar movie that was released in the summer of 2023, has the unfortunate honor of having the 2nd worst box office opening for the animation studio Pixar, since the release of Toy story in 1995.

But oddly enough, Elemental currently has a 93% audience score on Rotten Tomatoes, which shows that the movie was not just enjoyed by those who saw it, but loved.

So what happened to Elemental?

Rua Fay at Cinemasters does a great job of summarizing the events that lead to the fiasco in her blog, but in short, Disney didn't do a great job at marketing the movie. The movie's marketing focused on the wrong elements (pun not intended) of the Elemental while targeting a niche audience.

Luckily, Elemental ended up finding its audience and performing better at the box office (keeping it from being a financial loss for Disney), but it's success was massively hindered by what was communicated about it.

It wasn't successful at the box office because of its quality as a movie.

It was less successful because of what Disney communicated about it.

So take a moment and ponder...

What do you communicate about yourself to others you work with?

How well do you communicate the value you bring to the table?

And lastly..

Are the only people who know your capabilities, competencies and strengths, those who have worked with you directly and/or those who have managed you directly?

Breaking the Curse of the 'Silent Engineer'

Even if you're currently not doing well in the realm of communicating your skills and what you have to offer, I want to ensure you that it's never too late to make a change.

You may not believe this (if you were to follow my career, watch my behaviors and have awareness of the activities I engage in) but I'm an introvert who suffers from social anxiety.

When I was younger, I found managing social scenarios immensely difficult. Though I've grown substantially through out the years, I sometimes still feel incredibly anxious doing simple social things; like raising my hand to answer a question in a classroom setting.

But my personal weaknesses and my general social preferences, have very little to do with my ability to communicate and express myself in a professional setting.

So how does a software developer grow in their communication skills and set themselves apart for more opportunities to flourish in their career?

Well, here are a few things I recommend doing to help yourself grow and build your communications skills:

1. Create a "Personal Elevator Pitch"

If you only had 30-60 seconds to communicate what value you bring to the table as an engineer, what would you say?

If you can't answer the above question easily, spend some time crafting a succinct way to express your value. Think through how you would explain what you have to offer to a person who could have a direct impact on your career growth.

Once you do that, practice sharing your elevator pitch with those you trust. Get feedback on you're communicating and refine your messaging.

Having an elevator pitch in mind better prepares you to express the value you have to offer at anytime, in any place, at any length.

Also, as an added benefit, it helps to build confidence and better define your personal strengths.

2. Find a mentor to help with communication skills

Finding a person who is willing to guide you on your journey of growth in communication is crucial. Your mentor doesn't have to be a software engineer and your mentor doesn't have to work with you.

Your mentor should be someone you trust, you admire and who has the experience to help you navigate your path to success. Someone you can ask honest questions, get genuine feedback, and who will encourage you throughout the process.

In all honesty, a mentor can truly be a "cheat code" when it comes to building skills you lack. Having a mentor(s) is an absolute game-changer to achieving success and growth in communication.

If you don't have a mentor, reach out to someone you think of highly today, and start the conversation.

3. Practice, Practice, Rehearse

Sadly, there is no shortcut to building stronger communication skills, BUT there is a method that works almost every time in helping you be a better communicator; practice.

In the Asurion Developer Advocacy Program, this is one of the topics I hone in on in my lesson on Public Speaking.

A key component of successful communication is confidence. In order to build confidence, you must first build competence. And to build competence, you must practice.

Practice can come in many forms: Speaking in the mirror to yourself, preparing a presentation with a colleague, joining Toastmasters, or creating a podcast. (Note: This is not an exhaustive list)

But what's most important is intentionally taking time to work on communicating ideas more effectively in a "safe space", where you can make mistakes and grow.

As they say, "Practice makes perfect", and building communication skills is no exception.

4. Speak up! Advocate For Yourself!

This is hands down one of the most important lessons I was taught in the latter half of my career (from one of my mentors).

Advocating for yourself is understanding that it is absolutely your responsibility to own you career and speak up for yourself.

No matter how great your support system, noone, and I mean noone, will ever be able to advocate for you as well as yourself.

When you believe you are able to do something, say it.

When you get a new certification or achieve a new accomplishment, share it.

If you feel you are not getting opportunities for growth and advancement that you believe you deserve, speak up about it.

This specific principle has been one of the keys to my personal career success. I would not have achieved what I have to this point in my career, without truly adopting this principle.

5. Watch the Masters

If you really want to become great at communication, watch and emulate those who are already great at it.

Sometimes, the best way to learn and grow is to imitate. By watching an individual who is recognized by their peers and community as a strong communicator, you have the opportunity to pick up on obvious and subtle skills that makes them great.

Also, make sure to watch a diverse set of communicators and see if you can learn the common tactics and approaches they all use. Sometimes, it's hard to recognize what makes any particular individual great without having a greater perspective on different communication styles.

And if possible, consider asking one of those "masters" if they'd be willing to be your mentor. You never know, you might just get lucky!

6. Volunteer to be Uncomfortable

The former CEO of IBM, Ginni Rometty, once said...

One sign an idea is a good one is if it makes people a little bit uncomfortable. That’s because growth and comfort never coexist.

In order to grow, you have to be willing to be uncomfortable.

And this principle is true in almost all aspects of life and even more so when it comes to communicating.

In order to really grow and build your communication skills as a developer or a software engineer, you need to put yourself in situations that challenge you and take you out of your comfort zone.

Sometimes, it will work out that you will be given a task or assignment that will force you to use your communication skills in new and challenging ways. But, you should never wait for that opportunity to come to you.

Instead, you should be seeking out opportunities of growth and putting yourself in situations that will force you to grow.

Is your manager looking for someone to volunteer to communicate some technical details to stakeholders? Volunteer to speak on behalf of the team.

Is there a need, at the end of a Sprint, for a person to share a summary of work completed by the dev team to the greater team? Speak with your team lead and volunteer to give that summary.

Are there seemingly no opportunities for communication roles on your team? Speak with your team lead or manager and ask if they can create those opportunities for you.

Be active in seeking out opportunities to grow in your communication skills.

Volunteer and take the chance to be uncomfortable and discover the growth that follows.

In Conclusion

I feel I have been very blessed in my career and have been able to experience both substantial skill growth and positional growth. I would attribute that, not only to my technically proficiency, but also to my goal of focusing on communicating more effectively.

And I can confidently say, that when competing for roles or opportunities, where I am equally qualified or even less qualified than my peers, that my ability to communicate has helped me to outpace the competition.

If you are looking to advance your career, expand your influence within your company or community at large, or if you aim stand out amongst candidates all vying for the same open role at an organization, consider building your communication skills.

I know without a shadow of a doubt, I owe much of my career success to the ability to not just “walk the walk” but also “talk to talk”.

All the best,

Bradston Henry

Do you have any other suggestions on how developers and engineers can grow their communication skills? If you do, please share them the comments below. I would love to hear them!

Note:
I am very passionate about this topic and believe that for many software engineers, that this area of expertise that can be difficult to master. If you'd like me to expand on this topic and go into more depth into the specifics of how to grow proficiency in communication, please let me know. I'd love to continue diving into this topic if others would find value in it. Thanks!

Photo Credits(Order of Appearance):

Cover Photo by Dustin Tray from Pexels

Photo by Startup Stock Photos

Photo by Pixabay from Pexels

Follow me on my Socials:
https://linktr.ee/bradstondev

K8s QuickBites: Creating Secure TLS Certificates for Kubernetes Deployments

Kaye Alvarado — Wed, 21 Aug 2024 12:50:47 +0000

This is the first of a series of blogs about Kubernetes Fundamentals, providing a quick step-by-step guide for each management scenario that is relevant when maintaining K8s workloads.

A Kubernetes application can be secured by adding a an SSL certificate to the deployment configuration. This quick bites shows how to manually do this.

Pre-requisites

It is assumed that the reader has set up their kube config file in addition to having the following tools available in their machine:

openssl
kubectl

Let's dive in to the steps!

Creating the Private Key and Certificate Files

Create a private key file using an encryption of your choice

openssl genrsa -aes256 -out privatekey.pem 4096

Now, create a certificate signing request (csr) from the key. A series of questions will come after this command prompting for details of the certificate such as country, state, city, domain name, etc.

openssl req -new -sha256 -key privatekey.pem -out certreq.csr

Then get a trusted certificate authority (CA) to sign your certificate. Optionally, you can also make the certificate self-signed. Download the generated crt tls.crt and key file. To get the unencrypted privatekey, decrypt it. You can use openssl to do this.

#for CA-signed
openssl rsa -in privatekey.pem -out tls.key
#for self-signed
$ openssl req -x509 -new -nodes -days 365 -key privatekey.pem -out tls.crt -subj "/CN=domain.com"

Rename the private key to tis.key. By this time you would have the two files needed for the K8s deployment.

$ls tls*
tls.crt tls.key

Now, create the secret in the namespace that you need it for, replacing secretname and namespace with the proper values respectively

kubectl create secret tls <secretname> --cert=tls.crt --key=tls.key -n <namespace>

A secret will be created in the namespace you specified. You can verify this with the commands below:

kubectl get secrets -n <namespace>
kubectl get secret <secretname> -n <namespace>

The secret will have values for tls.crt and tls.key. You can decode this using base64 to view the value.

echo <tls.crt value>|base64 --decode
echo <tls.key value>|base64 --decode

Adding the TLS secret to the Deployment
—--
The second part is how you will update the K8s deployment to include the certificate files and update the config to use this as the application’s certificate.

First, get the deployment name that you need to edit. Then open the file for editing.

kubectl get deployments -n <namespace>
kubectl edit deployment <deployment_name> -n <namespace>

In the volumes section, add an item for the secret

      volumes:
      - name: <secretname_used_for_deployment>
        secret:
          defaultMode: 420
          secretName: <secretname_in_secrets>

In the volumeMounts section, add the mount path where the certs will be stored

        volumeMounts:
        - mountPath: /etc/ssl/certs
          name: <secretname_used_for_deployment>
          readOnly: true

Once done, you can quickly verify if the certificate is present in the path you provided.

kubectl get pods -n <namespace>
kubectl exec -it <gateway_pod_name> -- ls /etc/ssl/certs

Depending on the configuration of the deployment, you can point it to pick up the certificate from the path of the certificate and private key paths. Deployments may use different directories so just replace the /etc/ssl/certs directory when applicable.

...and that's it!

Let me know if there are any quick bites requests you want me to publish next!

Taking Your Releases Into Overdrive with GitHub Actions

Derek Berger — Wed, 14 Aug 2024 20:04:36 +0000

Introduction

GitHub Actions’ seamless integration with version control simplifies creating and executing operations and infrastructure workflows. Two key features of Actions for building efficient workflows are:

Composite actions. Composite actions let you create combinations of steps that you can reuse across different kinds of workflows.
Job outputs. Outputs make values derived from one job's steps available to downstream jobs' steps.

In this article, I’ll share how Actions’ integration with version control, composite actions, and job outputs helped my team advance our use of Actions to automate production deployments.

Mostly manual automation

The workflow that my team built for disaster recovery uses a composite action that cuts off DNS traffic to the impaired region. It lets us execute failover in just one step, and the same workflow can be used for any operation that requires rerouting production traffic for an extended time. We just manually trigger it exactly the same way we would when failing over, specifying which DNS to change and which region to cut off.

While that can be helpful for major changes like infrastructure upgrades, major changes are not common. More often we simply deploy application or configuration updates via pull requests, following GitOps practices. To keep our uptime as high as possible and avoid disrupting customers, we tried using the failover workflow to reroute DNS during these everyday changes.

That at least rerouted traffic how we wanted, but it required multiple manual steps:

Trigger failover workflow to change DNS.
Merge pull request to deploy application change.
Verify pods roll out.
Trigger failover workflow to restore DNS.

Considering the workflow required thinking about which DNS needed to change, and manually selecting the right DNS and region options, the procedure took more like five steps. And despite automation for applying DNS changes and verifying pods, it became a drudgery to deploy anything.

Even worse, whenever we wanted to apply the change to multiple clusters, we’d have to repeat every step multiple times.

This was counterproductive, inefficient, and discouraged us from deploying as frequently as we could have.

Eradicating the toil

What we needed was a workflow to deploy everyday changes in one step, not four or five, so we set out to build a new workflow that uses the same composite actions as the failover workflow, but makes better overall use of GitHub Actions' automation capabilities.

First, since all production changes are deployed via pull request, instead of workflow_dispatch we use pull request triggers based on branch, path, and event type.

name: Production deployment
on:
 pull_request:
   branches:
     - main
   paths:
     - "path/to/region1/releases/namespace1/"
     - "path/to/region1/releases/namespace2/"
     - "path/to/region2/releases/namespace1/"
     - "path/to/region2/releases/namespace2/"
   types:
     - closed

We broke the new workflow down into 4 jobs, which correspond to the old manual steps.

Determine what changed.
Make DNS change to stop traffic.
Verify services’ pods roll out successfully
Make DNS change to restore traffic.

In the first job, we start by ensuring the workflow only proceeds upon merged pull requests, and not just any pull request closed event, by adding this if condition:

job1:
   if: (github.event_name == 'pull_request') && (github.event.pull_request.merged == true)

Unlike the failover workflow, the new workflow must automatically determine the right region and DNS to cut off. The dorny paths-filter action was our help for this.

We first use it to determine region based on change path:

     - name: Determine region
       uses: actions/checkout@v4
     - uses: dorny/paths-filter@v3
       id: region-filter
       with:
         filters: |
           region-1: 'path/to/cluster/account/region1/**'
           region-2: 'path/to/cluster/account/region2/**'

Next, we have a filter for DNS, which is important to get right because the DNS we want to reroute will vary depending on which services change:

     - name: Determine DNS to change
       uses: actions/checkout@v4
     - uses: dorny/paths-filter@v3
       id: dns-filter
       with:
         filters: |
           dns1: 
             - 'path/to/services/1'
             - 'path/to/services/2'
           dns2:
             - 'path/to/services/3'
             - 'path/to/services/4'
           dns3:
             - 'path/to/services/1'
             - 'path/to/services/2'
           dns4:
             - 'path/to/services/1'
             - 'path/to/services/2'
             - 'path/to/services/5'
             - 'path/to/services/6'

The final filter determines which pods to validate, also based on which services have changed:

     - name: Determine services
       uses: actions/checkout@v4
     - uses: dorny/paths-filter@v3
       id: service-filter
       with:
         filters: |
           service-1:
             - path/to/services/1
           service-2:
             - path/to/services/2
           service-3:
             - path/to/services/3
           service-4:
             - path/to/services/4

Finally, job outputs are what makes all these filtered values available to downstream jobs.

   outputs:
     dns: ${{ steps.dns-filter.outputs.changes }}
     services: ${{ steps.service-filter.outputs.changes }}
     region: ${{ steps.region-filter.outputs.region-1 == 'true' && 'region-1' || 'region-2' }}

The second job applies the DNS change, but includes a condition to only proceed if it finds values in the outputs for DNS and region.

 job2:
   needs: [ job1 ]
   if: ${{ needs.job1.outputs.dns != '[]' && needs.job1.outputs.dns != '' && needs.job1.outputs.region != '[]' && needs.job1.outputs.region != '' }}
   strategy:
     matrix:
       dns: ${{ fromJSON(needs.job1.outputs.dns) }}

It calls the same composite action as the failover procedure:

   steps:
     - uses: actions/checkout@v4
     - name: Stop traffic to ${{ needs.job1.outputs.region }} ${{ matrix.dns }}
       uses: './.github/actions/dns-change'
       with:
         dns: ${{ matrix.dns }}
         action: stop
         region: ${{ needs.job1.outputs.region }}

The third job verifies pods roll out, applying the values from the services output to a matrix:

job3:
   needs: [ job1, job2 ]
   if: ${{ needs.job1.outputs.services != '[]' && needs.job1.outputs.services != '' }}
   name: Validate pods
   strategy:
     matrix:
       service: ${{ fromJSON(needs.job1.outputs.services) }}

And calling the composite action to execute the pod validation steps:

- uses: actions/checkout@v4
     - name: validate deployments and pods
       uses: './.github/actions/pod-validation'
       with:
         deployment: ${{ matrix.service }}
         cluster: ${{ needs.job1.outputs.region == region-1' && '1' || '2' }}

If every pod rolls out successfully, the workflow proceeds to restore the traffic cut off in job 2.

 job4:
   name: Restore traffic to ${{ needs.determine-changes.outputs.region }} in ${{ matrix.dns }}
   strategy:
     matrix:
       dns: ${{ fromJSON(needs.job1.outputs.dns) }}
   steps:
     - uses: actions/checkout@v4
     - name: Restore traffic to ${{ needs.job1.outputs.region }} ${{ matrix.dns }}
       uses: './.github/actions/dns-change'
       with:
         dns: ${{ matrix.dns }}
         action: start
         region: ${{ needs.job1.outputs.region }}

If any step fails, the workflow fails and traffic remains routed away from the failed cluster while the team investigates. If necessary, we can open a pull request to revert the change. Merging it will trigger the workflow again, effectively validating the rollback.

Success!

By combining the composite actions we created for the failover workflow with path filters and job outputs into a new workflow, deployments now take one manual step: merging a pull request.

The workflow takes over from there, automatically making the proper DNS changes, verifying impacted pods roll out, restoring DNS traffic, and notifying us of results.

Unburdened by multiple manual steps, our team deployed 32 changes to production in the first month of using the workflow. In the previous month, we deployed 17 changes. The results so far have been promising, and we'll continue looking for ways to make our release practices even better with Actions.

What Idiot Wrote This Code? ...Oh It Was Me

Alex Micksch — Fri, 09 Aug 2024 22:46:53 +0000

Entering this world as a Level 1 engineer, I soon realized that my ambition was greater than my knowledge - a humbling part of my growth. The first big project I took on was creating a snapshot of our production database cluster for use in lower environments. This process involved creating a copy of the production cluster into a temp DB, anonymizing customer data, updating api keys and passwords, and then generating a snapshot that was ready to be used by developers and QA testers. At the time, it was a massive undertaking, and I was eager to prove myself. Now, looking back, I can see there were many things I could have done better with how much I've learned since then. Could I have anticipated these improvements ahead of time? In some cases, yes, though I lacked the skills to implement it. But in others, it was experience that guided my progress.

The process I developed was functional, but fragile. Any small error would require manual intervention, which made the process less reliable. Still, it worked - albeit just barely. It was a delicate machine that could break down if someone so much as looked at it. During this period, our team began to focus heavily on a new project, and time/energy/motivation to return to this original project became scarce. Manual workarounds, while inefficient, were the most effective solution. But as the inefficiencies piled up, so did my mental list of tech debt. Finally, I reached a point where I had enough and decided to revisit my once biggest achievement turned my now biggest headache. I had a list of issues to work on:

What to do with the temp DB's that were generated if the process failed overnight? At the time, I was just deleting them and restarting the process. But this was... not great.
Next was the time it took to add the encryption key to the snapshot. Initially it took about 10 minutes, but over time, that ballooned to nearly 45 minutes. When I consulted AWS support, their suggestion was to "just increase the sleep." While this was a quick fix, it didn’t address the root of the problem.
Sometimes the DB would reject the connection while it was running my laundry list of SQL queries. This would cause the job to return an error code and fail outright. Ugh.
Most importantly, this job is shared between multiple applications. This was one of the main reasons why it was so fragile. Should I separate it out into a different job per application?

When I set out to revisit this project, I had an epiphany. It was like coming back to the video game you struggled with six months ago and beating it on the first try. Every day, you make small improvements that seem insignificant on a day-to-day basis, but over time they accumulate. When I started working on the project again I realized how much I had grown. Not just in my technical skills, but in my approach to problem-solving. Here's how I went about it:

For the orphaned temp DB's: Reuse them! While I created some logic around the rest of the process to make it more resilient, if the job had failed and left around the temp DB's, just reuse them and start the job from the steps after they would get created. Hindsight is 20/20, etc, but I for whatever reason I couldn't see it my first time around.
The encryption key time... Admittedly I still haven't found an answer for this. And AWS support was never able to provide me with a clear answer as to why this happened. In the end, I increased the sleep time to compensate for this mysterious time increase, but I pray in the future I will gain additional knowledge that will grant me an "aha!" moment if I come back around.
I'm still unsure why the DB randomly rejects the SQL connection. But for now I've added a catch and retry. A good solution doesn't have to be complicated!
After considering whether to split out the job for each application, I decided to stick to my guns and share the same job file between our three apps. I think splitting it up would be easier, but this gives me a self-enforced challenge to work into my development. And with my increased experience and skills, I was able to make it work.

Looking back, I can clearly see what my original implementation was lacking. But for a long time, other tasks and complacency with manual workarounds kept me from addressing them. Once I decided to revisit it, I was amazed at how quickly I was able to come up with solutions for my prior shortcomings. Just a few days of work and testing compared to the drawn-out struggle I had faced before. The experience was a powerful reminder of how much I had grown. Not just in my technical ability, but also in my confidence and approach to problem-solving. This project, which for a long time seemed so daunting, now serves as a marker of my progress.

In conclusion, my encouragement to you dear reader, is to revisit that old project you know could be better. The one you worked on so long ago. You may not realize it now, but once you start looking at how you can improve it you'd be surprised at how far you've come!

Software Design Principles in Note-taking

Mark Castillo — Fri, 09 Aug 2024 11:25:36 +0000

Those of us who've been writing code for some time have likely applied these design principles in our work. These help our code become clear and readable - maintainable. It helps collaborators (and your future self) better understand your creation.

I started to entertain strategies for note-taking when I realized that it was time to stop dumping all of my notes into Notepad and start compiling and organizing them into something that sentient beings could understand. However, those that I've read were mostly geared towards capturing ideas (for book writing, graduate studies, etc.)

And so I thought, "I'm familiar with principles to write clean code... could I apply those to my notes, maybe?" I've found success in translating these into note-taking. As I share them with you, I hope you do too.

Single Responsibility Principle

"A class, method, or function should only have one responsibility."

In line with it's traditional definition, each note or page should contain only one focal idea or purpose. The main goal: don't dump everything on a single document. Give each major component an island of their own.

Using application support as an example - responsibilities include supporting weekly requirements and troubleshooting of reported issues. Respectively, I've organized my notes as such:

Deployment Steps - a detailed, step-by-step guide on how to do the deployment. Screenshots and all.
Troubleshooting - the first aid kit. A compilation of valid, known, and even weird issues encountered and how they were solved. This comes in handy especially when someone else performed the resolution.
Overview - the page that ties them all together. Contains top-level information like the AWS account and region, access requirements, relevant URLs, plus it references the Deployment Steps and Troubleshooting pages.

Looks something like this:

You might think that having separate pages for each topic would be counterproductive in the long run, but it's actually the opposite. I know exactly where something is. No more guessing which piece contains what information. It also makes everything shareable and easier to build on to.

Open-Close Principle

"Entities should be open to extension, but closed to modification."

Chain your notes together, but don't weld them. Build them up as if you were making notes using pen and paper - give each idea or article, no matter how small, it's own space to grow. Then make use of links to connect the dots, like the choose-your-own-adventure books of old.

It could look something like this - let's say you have an application issue that's been a pain point for quite some time. And so, you add it to your wish list of improvements. Fast forward in time, you're writing about what's shiny and new in the enhancement's you've made and the story behind it.

Don't Repeat Yourself

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

Your mileage may vary on this one as it depends on your use case. But the idea is to link your notes whenever you can.

One possible use of this could be: you encounter an issue or error that has the same nature as one that you've encountered and/or resolved before. When you get around to documenting, instead of writing everything down again from scratch, you could just make a reference to the existing document.

Bonus: Single Source of Truth

"There should be one definitive data repository that all users and systems refer to."

This is more a personal preference of mine. Having a "master copy" of my notes in one place eliminates the mental load of having to keep track of what is where. Gone are the days of Did I have that in Confluence? OneNote? Or was it in Slack Canvas? 😬

I like to use Obsidian. All of the notes I keep and its revisions go through there first before being shared anywhere else. I find it convenient to have the updated copy within reach, as the ones in Confluence or even GitHub can fall behind when I jump from project to project.

But! Having a single source of truth does not mean that you should limit yourself to a single tool. Go with whichever you fancy the most, but there's no one app to rule them all; use the right tool for the right job. I use a combination of Logseq and Obsidian as they both use markdown formatting - Obsidian excels in long-form notes whereas Logseq excels in short-form (bulleted, quick notes and to-do lists).

Note-taking is not much different from any other skill we learn. And it's tools are the equivalent of an IDE. Pick the one that works with your style and you end up with a second brain that works for you.

Related: Zettelkasten Method

Create your own Kubernetes "kind:"

raymundmelvinchua-github — Thu, 08 Aug 2024 15:25:04 +0000

Imagine each Kube object is a unique dinosaur specie and you're a novice Kube user/operator or a seasoned Kube application developer.

The term "KIND" would have a double connotation:

it could mean the your shortcut framework to create a Kube cluster inside Docker... or
it may mean creating your own Kube YAML "KIND:" objective.
it could mean a specific KIND of dinosaur. Just joking.

But you, as my reader here in Dev.to, will not be indulged by run-of-the-mill tips and tricks. You want more action and value... you want something to showcase to your senior colleagues that Kubernetes can indeed be extended by writing your own Kube API objects.

So by choosing the second bullet above, all are possible by leveraging the Kubernetes API's CRD: "Custom Resource Definition". Let's discuss that second bullet above and create your own KIND of dinosaur... I mean Kube Object !

Use Case! Create your new kind of dinosaur!

To demonstrate the WHY and the HOW of CRD's, let us imagine these points in your Kube cluster:

you need multiple ingressControllers to avoid single point of failures.
you need unique ingressClasses that correspond to each ingressController mentioned above, to avoid traffic route mixing.

For our solution, you want to use a CRD as a "wrapper" of sorts, so you can "bootstrap" multiple Kube objects in one go, at the same time give the user some freedom to enforce UNIQUENESS by making some Kube metadata configurable.

Diagram flow

So here's the flow of how the CRD will work:

Above image illustrates how a CRD would act as a bootstrap with configurable metadata.

To start off, imagine these steps:

STEP 1

Prepare your consolidated YAML file that contains all needed components for your ingress-controller & ingressClass pattern:

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: primary-ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.1.3
  name: primary-ingress-nginx-controller
spec:
  externalTrafficPolicy: Local
  ports:
  - appProtocol: http
    name: http
    port: 80
    protocol: TCP
    targetPort: http
  - appProtocol: https
    name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: primary-ingress-nginx
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: primary-ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.1.3
  name: primary-ingress-nginx-controller-admission
spec:
  ports:
  - appProtocol: https
    name: https-webhook
    port: 443
    targetPort: webhook
  selector:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: primary-ingress-nginx
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: primary-ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.1.3
  name: primary-ingress-nginx-controller
spec:
  replicas: 2
  minReadySeconds: 0
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app.kubernetes.io/component: controller
      app.kubernetes.io/instance: ingress-nginx
      app.kubernetes.io/name: primary-ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/component: controller
        app.kubernetes.io/instance: ingress-nginx
        app.kubernetes.io/name: primary-ingress-nginx
    spec:
      containers:
      - args:
        - /nginx-ingress-controller
        - --publish-service=kube-system/primary-ingress-nginx-controller
        - --election-id=ingress-controller-leader
        - --controller-class=k8s.io/ingress-nginx
        - --ingress-class=primary-ingress-nginx-class
        - --configmap=kube-system/primary-ingress-nginx-controller
        - --validating-webhook=:8443
        - --validating-webhook-certificate=/usr/local/certificates/cert
        - --validating-webhook-key=/usr/local/certificates/key
        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: LD_PRELOAD
          value: /usr/local/lib/libmimalloc.so
        image: k8s.gcr.io/ingress-nginx/controller:v1.1.1
        imagePullPolicy: IfNotPresent
        lifecycle:
          preStop:
            exec:
              command:
              - /wait-shutdown
        livenessProbe:
          failureThreshold: 5
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        name: controller
        ports:
        - containerPort: 80
          name: http
          protocol: TCP
        - containerPort: 443
          name: https
          protocol: TCP
        - containerPort: 8443
          name: webhook
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /healthz
            port: 10254
            scheme: HTTP
          initialDelaySeconds: 10
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          limits:
            memory: 1Gi
          requests:
            cpu: 100m
            memory: 90Mi
        securityContext:
          allowPrivilegeEscalation: true
          capabilities:
            add:
            - NET_BIND_SERVICE
            drop:
            - ALL
          runAsUser: 101
        volumeMounts:
        - mountPath: /usr/local/certificates/
          name: webhook-cert
          readOnly: true
      dnsPolicy: ClusterFirst
      nodeSelector:
        kubernetes.io/os: linux
      serviceAccountName: primary-ingress-nginx
      terminationGracePeriodSeconds: 300
      volumes:
      - name: webhook-cert
        secret:
          secretName: primary-ingress-nginx-admission
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: dedicated
                operator: In
                values:
                - essentials
      tolerations:
        - key: dedicated
          operator: Equal
          value: essentials
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: primary-ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.1.3
  name: primary-ingress-nginx-class
spec:
  controller: k8s.io/ingress-nginx
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  labels:
    app.kubernetes.io/component: admission-webhook
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: primary-ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.1.3
  name: primary-ingress-nginx-admission
webhooks:
- admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: primary-ingress-nginx-controller-admission
      namespace: kube-system
      path: /networking/v1/ingresses
  failurePolicy: Fail
  matchPolicy: Equivalent
  name: validate.nginx.ingress.kubernetes.io
  rules:
  - apiGroups:
    - networking.k8s.io
    apiVersions:
    - v1
    operations:
    - CREATE
    - UPDATE
    resources:
    - ingresses
  sideEffects: None

The value of using CRDs

In above YAML example, we consolidated 2 Kube SVC objects, alongside a DEPLOYMENT object and an ingressClass object.

But at his point you may be thinking? I can simply & easily instantiate these objects using above consolidated YAML. So why need CRD?

That is a valid concern! However, the value of CRD comes when you want to have metadata configurable prior to object instantiation.

Imagine the challenge of externalizing the metadata "ingress-nginx"? How would you make a single configurable item for this? Does that mean you have to refactor your consolidated YAML each time you need to implement this pattern? Kind of time-consuming and prone to human errors.

For our use case, we want to externalize these three metadata, to make it user-defined:

app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
name: primary-ingress-nginx-*

STEP 2

Define the Custom Resource Definition itself:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: ingresscontrollerclass.example.com
spec:
  group: example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                instanceName:
                  type: string
                partOf:
                  type: string
                name:
                  type: string
                replicas:
                  type: integer
                ingressClassName:
                  type: string
                serviceAnnotations:
                  type: object
  scope: Namespaced
  names:
    plural: ingresscontrollerclass
    singular: ingresscontrollerclass
    kind: IngressControllerClass
    shortNames:
      - icc

There are alot of conceptual attributes to introduce in above example, but I have faith in your capacity to associate new stuff with your stock knowledge. Here, you are instantiating a widely accepted Kubernetes object of "kind: CustomResourceDefinition".

But the more critical attributes we need to introduce here, the mechanism to externalize the needed metadata, defined here as object properties:

     properties:
    instanceName:
      type: string
    partOf:
      type: string
    name:
      type: string
        ingressClassName:
          type: string

        # extra properties:
    replicas:
          type: integer
        serviceAnnotations:
          type: object

The crucial stuff to externalize here are instanceName, partOf, name and ingressClassName because these properties enforce uniqueness of ingress-controllers and their corresponding ingress classes. The extra properties are nice to have but are still helpful.

Step 3: Create your very own Kube KIND (Custom Resource)!

So here's the reason why you need a CRD, because you need a hard pattern so users can create a "Custom Resource".

After instantiating your CRD, feel free to create your very own customized Kube Kind --> kind: IngressControllerClass

apiVersion: example.com/v1
kind: IngressControllerClass
metadata:
  name: my-nginx-ingress-setup
spec:
  instanceName: "melvin-nginx"
  partOf: "melvin-nginx"
  name: "melvin-ingress-nginx"
  replicas: 2
  ingressClassName: "melvin-ingress-nginx-class"
  serviceAnnotations:
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"

^
As you can see in the "spec" part of your new YAML KIND, the operator now has the freedom to define the name of the new ingress controller, with corresponding ingress class name and associated metadata.

That way, the CRD enforces tight coupling, thereby ensuring that the resulting ingress-controller and ingressClass will be tighty associated with each other and enforce uniqueness from other parallel implementations.

A proper Kube coupling like the image below:

If you like this article, tell my boss to buy me a coffee! =)
~

Cost Effective Way of Travelling in the “Cloud”- Quite Literally!!

Saikrishna Annavajjula — Wed, 07 Aug 2024 19:21:16 +0000

I came to realize recently that, similarities between cloud computer and award traveling is quite intriguing. As we delve into these realms, we'll uncover how meticulous planning and critical thinking can harness maximum benefits, be it through optimizing credit card points for travel enthusiasts or choosing the perfect AWS services for tech-savvy professionals. Join me as I draw insightful parallels between these seemingly disparate worlds.

The Art of Point Transfers in Award Travel
In the realm of award travel, savvy individuals don't merely redeem credit card points for flights or hotel stays. Instead, they leverage the power of point transfers to enhance the value derived from each point spent. This often involves transferring points to airline loyalty programs or even to partner airlines, where the value per point can be significantly higher than redeeming points directly with the issuing airline.

Drawing Parallels in AWS
Similarly, in AWS, the journey towards cost optimization extends beyond a simple choice between EC2 instances and other services. Just as travelers explore various avenues to increase the value of their points, AWS users should consider a broader range of services and configurations to tailor their infrastructure to specific needs and budgets.

AWARD TRAVEL

Lets assume you have a requirement to embark on a seamless journey from Washington DC to Alaska with a direct flight, departing from an airport of your choice on your chosen dates.

Lets look in to our options.

Cash You can take an easy route by spending some $$$ book the most convenient flight..The simplest way to travel with least amount of effort.

CreditCard points Perhaps you're hesitant to spend actual money and would rather utilize credit card points instead. This way, you're not directly spending cash. It requires some effort in strategic planning and selecting a card that offers a superior sign-on bonus. Based on 1 cents per point valuation, you will need 43,000 points.

Airline points May be you do a bit more discovery work and found out that you get even better value if you transfer to airlines which is your credit card’s preferred travel partner. We now need 15K points to travel. Now compare with above two options and this seems to be the cheapest option, yielding us 2.86 cents per chase point.

You are not done yet.... more research gives you even better value.

Partner airline points By transferring the credit card points to a partner airline of united airline, you will travel in same united flight and an exact itinerary. But you only spend 10K points one way. Which yields you a whopping 4.3 Cents value per creditcard point spent.

Conclusion: By employing strategic thinking, you can optimize the value derived from your credit card points. Utilizing credit card points instead of cash may seem economical; however, maximizing their potential by transferring them to airlines or partner airlines could yield greater benefits.

Lets draw some parallels..

AWS SERVICES

Lets assume you have a requirement of running a web application that processes user requests and performs lightweight data transformations. This application experiences variable traffic, peaking during business hours and dropping significantly overnight.

Example Workload Specifications:
CPU Usage: 1 vCPU
Memory Usage: 2 GB RAM
Traffic Pattern: Variable, with peaks during business hours
Monthly Traffic Volume: Approximately 500,000 requests

EC2 INSTANCES

On-Demand
Probably an easiest and least effort way to spin up and configure your application. Go to console launch and EC2 and configure your app...
$0.092 per Hour for t3.medium instance = ~$66/month (assuming full month usage).
Reserved
Perhaps you're hesitant about investing heavily and creating a single point of failure. In that case, consider applying some planning ahead to configure your application to operate on an reserved instance, allowing for not spending as much as on-demand.
Using EC2 Reserved Instances (1-year term): Assume 40% savings over On-Demand = ~$39.6/month

CONTAINERIZE May be you do a bit more discovery work and found out that you can run the same workload in a container running on EKS or ECS and get high availability and scaling.

Containerize your app and running on ECS/EKS Fargate:
$0.04048 per vCPU-Hour + $0.004445 per GB-Hour = ~$58/month (estimation)

SERVERLESS May be you dont want to build a container or maintain an EC2 but you still want to run it as efficiently as it is but even cheaper.

Assume average execution time of 200ms per request at 128MB memory = $0.00001667 per GB-second + $0.20 per million requests = ~$12/month (estimation)

Analysis and Recommendations

Cost Efficiency: For variable workloads with significant traffic fluctuations, Lambda offers the most cost-efficient option due to its pay-per-use model, charging only for actual execution time and memory used.

Predictable Workloads: For applications with predictable, steady-state workloads, committing to EC2 Reserved Instances can offer substantial savings compared to On-Demand pricing.

Flexibility vs. Cost: Spot Instances provide a balance between cost and flexibility, offering lower prices than On-Demand instances but with the risk of interruption.

Containerized Workloads: For containerized applications, both ECS Fargate and EKS Fargate offer simplicity and cost predictability, charging based on actual resource consumption without the need to manage underlying servers.

Conclusion:
The choice of service depends on the workload characteristics and cost considerations for highly variable workloads or those that can benefit from serverless architecture, Lambda is often the most cost-effective.For steady-state applications where cost predictability is crucial, EC2 Reserved Instances offer significant savings.
Spot Instances are suitable for fault-tolerant applications where cost savings outweigh potential interruptions.ECS/EKS Fargate provides a good balance for containerized applications, offering simplicity and scalability without managing server infrastructure.
It's essential to monitor actual usage and costs closely, as AWS pricing models can vary based on region, instance types, and other factors. Additionally, consider using AWS Cost Explorer and Savings Plans for further optimization.

Empowering Decisions with AWS Cost Management Tools

To navigate this complex landscape effectively, AWS provides a suite of cost management tools. These tools offer insights into spending patterns, enabling users to make informed decisions about service allocation and optimization strategies. Just as travelers rely on apps and websites to track rewards and find the best deals, AWS Cost Explorer and Budgets empower users to analyze their cloud spending and identify opportunities for improvement.

Embracing the Journey of Continuous Optimization

The quest for cost optimization in both award travel and AWS is a journey of continuous learning and adaptation. Whether it's mastering the art of point transfers or navigating the intricacies of AWS pricing models, the key to success lies in staying informed, being adaptable, and making strategic choices that align with your goals.

By applying the same level of critical thinking and strategic planning to AWS service selection as you do to award travel, you can unlock significant savings and ensure that every dollar spent—whether in points or cloud resources—delivers maximum value. Remember, the ultimate goal is not just to save money but to ensure that every investment supports your broader objectives and enhances your ability to innovate and grow.

If you have made this far… Thank you for reading!! I would love to hear your feedback, thoughts and comments below..

From Code to Game: My Unity Adventure

Spencer Steed — Wed, 07 Aug 2024 16:09:30 +0000

As a software engineer, I've always been fascinated by the intricate world of game development. Despite my experience in coding, stepping into this realm felt like opening a door to an entirely new universe. This blog aims to share my journey as a beginner in Unity game development, along with some initial tips and tricks I've picked up along the way.

Why would I make a video game when I can just play them?

I have been playing video games as long as I can remember. I have always used them as a release from stress and anxiety, but its also how I met some of my best friends. Countless nights of staying up late on a variety of games, weekends of competing in fps (first person shooter) tournaments, and even hosting LAN parties at my house.

Often, I hoped for a way to combine some features from different games. I began to think, "What if I could merge these fun mechanics into a single game?" The idea grew even more exciting when I imagined my friends' voices as the characters' voice lines.

Then it dawned on me…..

Why not create a game that combines the best elements of my favorite games, featuring the unique touch of my friends' voices? That's when this journey began.

Let's Start Simple.

Learning The Basics: First thing I did was look up some tutorials for Unity on Youtube. I quickly found one called "The Unity Tutorial for Complete Beginners". This video helped me create a new project, understand the Unity ui, and create a simple flappy bird style game.

Starting Small: I knew I was brand new to this and needed something that wouldn't require extensive knowledge of advanced features in Unity and something that would get my feet wet in game development. Therefore, I decided to start with a 2D Zombie Survival Game. This would also allow me to practice leveraging what I learned in the tutorial video and also add some custom flair to the project.

Leveraging Online Resources: Now that I had my project idea and some new base principles to try out, I went back to Youtube to find some examples of similar style games to what I was looking to build. That's where I found "Make a 2D Top Down RPG in Unity". This video series is quite long (~100 videos), but I was able to jump around a bit and utilize some core teachings they offered.

Practice, Practice, Practice: Watching someone else implement a new sprite with new animations and collision does not grant you the ability to do it yourself. It also won't help you retain that knowledge. Practice is key when implementing and improving anything in your game. This is something that I have carried over from being a software engineer for the past 10 years.

Join or Create a Community: A community is crucial for feedback and improvements to your game. It also can provide the help you need for new ideas, bug fixes, and even with new assets to add to your game! I was fortunate enough to have a group of Discord friends that were willing to help with this. We opened a channel and ideas started flooding in. "What should the zombies look like?" or "What should the sniper class look like?" which was then followed by someone from the community adding some new sprites to use.

Setup The New Project: Once I figured out I wanted to make a 2D Zombie Survival Game, I created the project in Unity with the prebuilt "2D" template and pushed the code to a new private Github repository. This allows you to add any contributors to the project later and also serves as a way to rollback if you make a mistake or change your mind on something (it will happen). Also PC issues happen, so never hurts to have a backup.

Lets get started on the game!

Building this game in 2D largely determines how I will have to control the character. While I enjoy the classic full keyboard controls of games like Final Fantasy XI, most users prefer using the mouse to control the direction the character is facing. Additionally, using the mouse makes fighting hoards of zombies easier since they will be coming from every direction. Therefore, I decided to go with simple WASD movement, having abilities set to 1–2–3–4 , and mouse for camera directional controls.

How does Unity handle player movement?

Unity offers various methods for handling movement inputs, including Transform, Rigidbody, and CharacterController. For my project, I am utilizing Rigidbody. Below are some examples of Rigidbody methods essential for the PlayerMovement script:

Update() Handles input for movement (WASD keys) and call the RotateTowardsMouse method to rotate the player towards the mouse position.



void Update()
{
  movement.x = Input.GetAxis('Horizontal');
  movement.y = Input.GetAxis('Vertical');

  RotateTowardsMouse();
}

FixedUpdate() Moves the player based on the movement vector and speed.



void FixedUpdate()
{
  rb.MovePosition(rb.position + movement * moveSpeed * Time.fixedDeltaTime);
}

RotateCharacterTowardsMouse() Calculates the angle between the player and the mouse position, then rotates the player to face the mouse.



void RotateCharacterTowardsMouse()
{
    Vector3 mousePosition = Camera.main.ScreenToWorldPoint(Input.mousePosition);
    Vector2 direction = (Vector2)(mousePosition - transform.position);
    float angle = Mathf.Atan2(direction.y, direction.x) * Mathf.Rad2Deg;
    rb.rotation = angle;
}

Most components created for the project will require scripts for customization. Note that Unity will automatically update the script as you make changes through the UI.

Once you have created the PlayerMovement script, you can assign it to the player GameObject by dragging and dropping it from the Project window into the Inspector window. Alternatively, you can click the Add Component button in the Inspector window, search for PlayerMovement, and select it.

After configuring the movement, you will be able to move an empty square model around.

Lets add some custom sprites!

Setting up the player and zombie sprites is a fun process that I enjoyed. My friend Joey created the sprites and I was able to build all the surrounding pieces to make them work. I imported the custom sprites for player models, zombies, and scenery into their folder, plugged them in, and worked on setting up idle/running states.

Wow, I got stuck on a bush in the dark and couldn't get the zombie off me!

Nothing is worse than getting stuck on an object and your character dying due to poor coding. This is something that I wanted to make sure I got right. I added a combination of Collider and RigidBody2D to set a collision perimeter for the player, the zombies, and all scenery that was added. Unity fortunately does a good job with the ability to duplicate the models and maintain their collision.

How should the zombies behave?

For the Zombie AI I want them to behave similar to how they do in Project Zomboid. If you are detected in their sight or hearing range, they will immediately start trying to attack and chase you. The player should have a slight speed advantage over the zombies while sprinting. However, there should be a balance between choosing to outrun the zombie at the risk of depleting stamina or confronting the zombie and potentially attracting more due to the noise.

What should we do next?

Combat: Animations and feedback will require a significant amount of time because each weapon type has unique requirements. Melee weapons need different rotations, ranged weapons need distinct animations, and any change to the weapon's size necessitates updates to the animations.

UI: Creating a clean UI is crucial for maintaining game fluidity and providing players with essential information about their health, stamina, and, if applicable, mana for magic mechanics. It's also important to have visibility into ability cooldowns and which weapon is currently equipped.

Advanced Animations: Implementing features like player death, bullet animations, destructible objects, and blood can be challenging, but they significantly enhance the game's depth.

Add Multiplayer: To add multiplayer, you will likely need to do some research on implementing Photon or mirror. These will give you the networking you need for adding other players to be controlled.

Don't forget to play your game!

After investing countless hours in building your game, I recommend taking some time to play it. Identify areas for improvement and jot them down. Many of the enhancements I worked on originated from bugs I discovered in existing features.

Thank you for reading!

As I conclude this talk about my Unity adventure, I reflect on the invaluable lessons learned along the way. It has been filled with challenges, creativity, and continuous learning.

Each bug fixed and feature implemented brought new insights and a deeper understanding of game development. It is important to identify areas for improvement, and embrace every obstacle as a stepping stone to growth.

Thank you for following along, and I hope my experiences inspire you to pursue your own adventures in the world of Unity and game development.

References:

The Unity Tutorial for Complete Beginners

Make a 2D Top Down RPG in Unity

Why You Should Learn Kubernetes

Vince Llauderes — Wed, 07 Aug 2024 12:39:46 +0000

Introduction

Kubernetes is one of the fastest-growing open-source projects in the community since it was released by Google in 2014. It became one of the de facto APIs for building and deploying cloud-native applications in the public cloud.

As an increasing number of companies shift to cloud-native applications to modernize their systems into smaller, microservice-based components, they require a robust technology that can manage scalability, reliability, and automated deployment. This enables them to operate with greater agility as the demand for their application increases.

What is Kubernetes?

Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation.

source from https://kubernetes.io/docs/concepts/overview/

Let’s take a look at why Kubernetes is so useful today

In IT, there are three common ways to deploy our applications (to name a few before the advent of Function as a Service known as FaaS)

Figure: 1.0 "Evolution of application deployment"

Traditional deployment

In the early days of computing, organizations ran their applications on their physical servers (on-premise setup). By doing this, you cannot define resource boundaries between your application in a physical server, which might cause resource allocation issues.

For example, suppose you have multiple applications running on the same physical server. In that case, there can be instances where one application would take up most of the resources and as a result, the other applications would underperform (see Figure: 1.1). A solution for this is to host your other applications on a different physical server. But the problem with this approach is that it might not scale, because you’ll end up buying more and more physical servers to accommodate the load when increases. When you allocate your application to different servers, it often results in underutilized resources on the physical server. This is where the virtualized deployment era comes in.

Figure: 1.1 "No resource boundaries between application"

Virtualized deployment

As a solution to traditional deployment, Virtualized deployments were introduced. It allows us to isolate different applications to separate Virtual Machines (VMs). In such a way that other applications won’t take up more resources even if they're on a single server (see Figure: 1.2). Multiple Virtual Machines can run on a single physical server which reduces our hardware cost and allows us to maintain lesser physical servers compared to traditional deployment approach.

But here’s the thing, by using Virtualized Deployment, there are still underutilized resources. Each VM has its own Operating System which can take up resources on the physical server. Would it be better if we remove the layer of the Operating System so that we could have more storage in the physical server to use? This is where the containerized deployment is introduced.

Figure: 1.2 "Virtualized Deployment to define resource boundaries"

Container deployment

Container deployments are similar to Virtualized deployments they can isolate your applications from the rest of the applications in a “Container” fashion. Containers are lightweight (see Figure: 1.3) compared to VMs because containers, don’t have the whole Operating System layer. Similar to VMs, containers have their own filesystem, memory, and CPU but container uses a generic Operating System called Kernel. This Kernel Operating System is typically Linux.

Figure: 1.3 "Container has its own filesystem"

In order for us to run “Containers” we need to have a Container Runtime on top of our physical server which is typically Docker. (Docker is a container technology. There are lots of container technologies exist in the market and not only Docker see link)

Since containers are lightweight, we can easily add & remove applications without the boot-up of the server.

This is where the Microservices pattern became popular. With Microservices (see Figure: 1.4), we can host each microservice to each individual container. We can have hundreds or even thousands of running containers on a single physical server. Just imagine that 🤯.

Figure: 1.4 "Applications are decomposed into smaller services or known as Microservices"

To name a few, containers have lots of benefits. With containers, we can be more agile, scale our application on demand, and achieve portability in our applications which we will not end up having dependency issues when deploying applications in production. Because the container is packaged to include all the application dependencies in order for it to run.

But that great power comes with great responsibility 💪🏻

How do we manage our containers? I mentioned earlier that containers enable us to deploy hundreds or even thousands of containers on a physical server. How do we start, and stop each individual container? How do we ensure each individual container is healthy? How do coordinate each individual container? How do you handle the scaling of containers, Deployment, Load Balancing, Service Discovery, and even Rolling Updates? These are things that you need to keep in mind in running containers in production.

Of course, we can develop a script that can handle these tasks but that’s not ideal unless you want to invent a new technology. For some companies it’s not worth it for them to develop new technology, instead, they want a proven and working technology in the market that is capable of doing this instead of developing their own. This is where Container Orchestration comes in.

What is Container Orchestration?

Container Orchestration is a tool that orchestrates/manages the containers. It helps us solve the problem that arises in managing containers. Container orchestration helps us manage each individual piece of a container such as scaling, automated deployments, and health checks. It also ensures each container is alive even in uncertain circumstances.

“Container orchestration is the same concept of an orchestra in music which manages each individual part of the instrument to perform great music (see Figure: 1.5)”

Figure: 1.5 "Container Orchestration is like an Orchestra in Music"

There are lots of tools that are available for choosing container orchestration, but Kubernetes is one of the most popular.

(Docker Swarm can manage containers but docker swarm doesn’t scale well and has limited features compared to Kubernetes. see link: Docker Swarm vs. Kubernetes)

Benefits of Learning Kubernetes?

Industry demand

Big tech companies like Google, Amazon & Microsoft are highly invested in this technology, which creates a huge job opportunity for engineers who will learn this.

Also, with more and more companies embracing the Kubernetes model to deploy their cloud-native applications, it creates huge community support on the market and allows you to become more productive in using the technology.

In a recent 2024 Stackoverflow Developer Survey, Kubernetes ranked among the top 5 most used tools by Professional Developers.

Figure: 1.5 "Kubernetes became top 5 by most used by developers"

Portability

One of the best selling points of Kubernetes is its use of containers to run applications (Thanks to containerization tools). Since containers are portable, you can run your applications in a wide variety of environments, along with their required dependencies. With this kind of approach, it is possible to reduce the number of issues shown in Production because of missing configuration.

Gone are the days of saying...

“Your application is running in DEV but not in PROD. That's because there’s is a different configuration in the environment.“

Scalability & Flexibility

One of the common issues that we face on On-Premise setups is how do we scale our applications like Horizontal scaling. Horizontal Scaling in an On-Premise setup is a nightmare for some because we typically buy a new physical server and set up the configuration required in order to spin up a new one. This kind of approach is not very productive and you’ll waste a lot of time.

With Kubernetes, you can easily scale up and scale down your applications depending on the demand. Whether it is Horizontal or Vertical Scaling (see: Horinzontal vs. Vertical Scaling).

It is flexible because it can adapt to your needs in such a way that if the demand is low, it can scale down. But if the demand is high, it scales up your resources.

High Availability & Stability

Kubernetes by nature is self-healing and monitors our applications whether it was healthy or not. If it’s not healthy, it replaces a new instance to become functional and healthy again (Figure: 1.0). With this kind of feature, we can rely on technology to ensure our application is reliable in uncertain circumstances.

Figure: 1.6 "If the Container isn't healthy, it replaces a new one to become healthy again"

You can also perform rollbacks if your recent deployments didn’t work as expected and Kubernetes can seamlessly perform rollbacks.

Community & Support

Cloud Providers such as AWS, Azure, & GCP have created Managed Kubernetes Services that allow customers to use Kubernetes with ease without worrying too much about its underlying infrastructure. This is a huge advantage for the community who wants to use and try Kubernetes immediately 👏🏻.

There are also lots of tools developed by the community that you can use in Kubernetes to make your setup more versatile like integrating it into CI/CD Pipeline or following the GitOps approach. Tools like ArgoCD, Kustomize, and Helm can make you more productive by embracing the Kubernetes model in your deployment.

Where should you start?

Start with the basics. I will share below the resources that helped me get started on my journey of learning Kubernetes.

First, start getting better and understanding how containers work. Start using a container technology like Docker and containerizing your application.

Familiarize yourself with how to create Dockerfile from scratch and learning the important Dockerfile commands like FROM, COPY, ENTRYPOINT, and CMD might help.

Get your hands dirty on how to use docker cli commands. Commands like docker build, docker tag, and docker push.
Be familiar with how to troubleshoot docker containers by using docker logs and dig deeper with the container image like docker exec to inspect the container filesystem.
Once you know containers, Learn how to work with YAML. You’ll get heavily reliant on YAML once you start working on Kubernetes. A basic understanding of how YAML files work is a huge advantage in learning Kubernetes.
Next, set up a local Kubernetes cluster on your local machine. The Docker desktop application can help you easily get started on this by enabling Kubernetes.

Deploy lots of applications and get your hands dirty. Understanding
Kubernetes objects like Pods, Deployments, and Services are a good start to get your applications up and running.

You’ll heavily use the Kubernetes CLI commands like kubectl -f <filename.yaml>, kubectl get pods, kubectl describe, & kubectl exec. To interact with applications.
Apply what you learn out there. Maybe in your team or organization, introduce some container orchestration tools like Kubernetes if you haven’t used them yet. Or if you’re using it, collaborate with those people who heavily use Kubernetes on their day-to-day job and start volunteering to help them with that task.
This is optional but, Get certified! Having a certification in a particular technology can enhance professional credibility and recognition within the industry. It’s also a huge plus for those people who don’t have certification. This also serves as a personal accomplishment in your journey as a Software Engineer and can help you stay up to date with the latest trends in technology.

Certifications like CKAD, CKA, and CKS might be great option to validate and show your credibility and competitiveness in the Kubernetes field.

This certification was released by the Cloud Native Computing Foundation. This Certification has a cost and you will need to review and practice a lot to pass it.

I just got my certification in CKAD last year and it was one of the best decisions that I have made.

Having a certification is a win-win scenario for Software Engineers!

Call to Action

Ready to dive into the Kubernetes world? Start your learning journey today with these beginner-friendly resources and courses.

A miniseries created by Google Cloud Tech on How to run containers on Kubernetes — https://www.youtube.com/watch?v=_2fiMli8p3E
This YouTube Tutorial Kubernetes series by TechWorld with Nana —https://www.youtube.com/watch?v=X48VuDVv0d
I’m a huge fan of reading an E-book if I want to learn a particular technology that’s new to me I want to dig deeper. Having an Ebook which greatly helps me understand better the bigger picture of Kubernetes
- Kubernetes In Action by Marko Luksa - https://www.manning.com/books/kubernetes-in-action
- Kubernetes Up & Running 2nd Edition By Brendan Burns, Joe Beda, Kelsey Hightower - https://www.oreilly.com/library/view/kubernetes-up-and/9781492046523/
There's also an Udemy course that I recommend. I bought this because It allows you to prepare for the CKAD certification exam experience with actual exam scenarios and try challenges which helps me get better at debugging and allows you to get your hands dirty with the technology. https://www.udemy.com/course/certified-kubernetes-application-developer/?couponCode=ACCAGE0923 by Mumshad Mannambeth

Let me end this blog post with a quote from one of the famous Kubernetes Advocate.

“Kubernetes has become the de facto standard for container orchestration. Its ability to abstract the underlying infrastructure makes it easier for developers to focus on writing code rather than managing infrastructure”

— Brendan Burns, Co-Founder of Kubernetes and Distinguished Engineer at Microsoft.

If you enjoy this blog, please give me a heart reaction ♥️. Comment below for some additional tips as well 😊

“Don’t be a mediocre Software Engineer”

Follow me on twitter https://twitter.com/llaudevc/