What is IaC?

IaC treats servers, networks and storage as software artifacts. Instead of using GUI, you declare your desired state in files. Those files become a single source of truth for building and managing infrastructure.

Key Benefits

• Consistency and repeatability

• Version control and collaboration

• Automation and speed

• Cost management

Popular IaC tools

1. Terraform : a cloud agnostic declarative tool that uses HCL (Hashicorp Configuration Language)

2. CloudFormation : AWS native IaC service using YAML or JSON template to provision AWS resources

3. ARM Template / Bicep: Azure native tool to write IaC to provision Azure resources.

4. Pulumi : You can write IaC in general purpose languages like Typescript, Python or Go

Best practices for writing IaC

• Keep modules small and focused on a single responsibility

• Parameterize values to reuse code across environment

• Enforce code review and merge checks for any infrastructure changes

• Continuously validate templates with linters and automated tests.

Conclusion

IaC is the cornerstone of modern DevOps and cloud native strategies. By using code to deploy resources, teams gain speed, reliability and clarity in their operations.

Service Level Indicator (SLI)

It represents the raw measurement of some aspect of system performance. An SLI is numerical value derived from monitoring data and reflects service health over time. Find some example below:

• Request latency measured in milliseconds

• Success rate defined as the ratio of successful to total requests

• Error rate calculated as percentage of failed transactions

Service Level Objective (SLO)

It is a target value or range for a specific SLI over a defined period. This target serves as an internal reliability benchmark that teams aims to meet consistently. Some example below:

• A percentage goal such as 99.9 percent availability

• A defined measurement window

• Alignment with user expectations

Service Level Agreement (SLA)

An SLA is a formal, often contractual, commitment between a service provider and its customers. It outlines the established SLOs, the measures to address breaches, and any corresponding penalties or credits. Components of an SLA include:

• The exact SLOs that the provider guarantees

• Definitions of service credits or penalties if targets are missed

• Exclusions and limitations such as scheduled maintenance windows

Relationship among SLI, SLO and SLA

SLI, SLO, SLA build on each other in a hierarchy of measurement, targets and commitment. An SLI provides the data, an SLO set the performance goal, and an SLA formalizes that goal at the customer level.

Implementing SRE

Integrating SLIs, SLOs, and SLAs into your reliability strategy follows a structured process. Each step ensures alignment between technical capabilities and customer expectations.

1. Identify critical user journey and select relevant SLIs

2. Defined realistic SLO targets based on historical data

3. Set up alerting and dashboard to monitor SLI performance against SLOs

4. Draft SLAs that reflect SLOs and outlines remedies for breaches

5. Continuously review and adjust targets as the service and user needs evolve

Conclusion

Understanding and applying SLIs, SLOs, and SLAs empowers teams to deliver reliable services while managing risk and expectations. By measuring what matters, setting clear goals, and formalizing commitments, Site Reliability Engineers can foster trust and drive continuous improvement.

What is JWT?

JWT is a compact, URL safe means of representing claims between two parties. It is a way for a server to prove that the client is who they say they are without storing session data on the server side. JWT is a string that securely transmits information as JSON object. This includes a header, a payload and a signature.

• Header: Contains metadata about the token, such as the type of token and the algorithm used for signing (HMAC SHA256)

• Payload: Contains the claims information about an entity (user for instance) and additional metadata. It can include standard fields like the expiration time or custom fields (needed by the system).

• Signature: It’s created by combining the encoded header, payload, and a secret key. This ensures that the token hasn’t be altered.

By design, JWT is self-contained, it carries all the information required for authentication, eliminating the need for storing session data on the server.

How does a JWT work?

A JWT based authentication process involves the steps below:

1. User Login: A user sends their credentials (login/password) to the server

2. Token Issuance: Once the credentials are verified, it generates a JWT that encapsulates the user’s identity an other information. Token is sent back to the client.

3. Client uses token: For future requests to protected routes, the client includes JWT within the HTTP Authorization header.

4. Token verification: When the server receives a request, it extract the token, decodes it, and verifies it by using the secret. If the token is valid and not expired, the server process the request; otherwise, it send an error.

JWT composition

A JWT is made up of three parts separated by dots (.):

Header.Payload.Signature

• Header:

{
  "alg": "HS256",
  "typ": "JWT"
}

• Payload:

{
  "sub": "123456",
  "name": "Alex Joe",
  "iat": 1516239022,
  "exp": 1516242622
}

• Signature:

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

Comprehending this structure is essential for understanding how JWTs maintain data integrity and authenticity. Since any alteration to the header or the payload would result in different signature, the token is only trusted if the signature is valid.

Why use JWT?

There are several reasons for developers to use JWT in applications:

• Stateless Authentication: It allows you to authenticate requests without storing session information on the server, useful in distributed and microservices architecture.

• Scalability: the token carries all the data needed for authentication, scaling your application across multiple servers is easier.

• Interoperability: JWT is not tied to any specific language or platform, which makes it a universal acceptable standard for authentication.

• Security: When implemented correctly, JWTs help ensure that token data remains secure and tamper-proof.

Conclusion

JWTs provide a secure way to handle authentication across distributed systems. By understanding the structure of JWTs, how it is generated, and how to verify it, you can implement robust, scalable authentication in your applications.

What is Gin?

Gin is a web framework written in Golang. It features a Martini-like API, but with performance up to 40 times faster than Martini. If you need performance and productivity, you will love Gin.

• Fast: Radix tree based routing, small memory foot print

• Middleware support: An incoming HTTP request can be handled by a chain of middleware and the final action

• Crash Free: Gin can catch a panic occurred during a HTTP request and recover it

• JSON validation: Gin can parse and validate the JSON of a request

• Routes grouping: Organize your routes better. Authorization required vs non required, different API versions

• Error management: Gin provides a convenient way to collect all the errors occurred during a HTTP request

• etc..

Find more detailed information on the project official page here.

Prerequisites

• Go 1.16 or above

• A text editor (I use VS Code )

• API Client to test your API, like Postman

Project Setup

Open a terminal and create a new project using the command below:

mkdir rest-api
cd rest-api
# Initialize the projet go.mod
go mod init github.com/<user>/rest-api

# Install Gin
go get -u github.com/gin-gonic/gin

You should get two file in your project folder go.mod and go.sum.

Simple API

Let create a minimal API with few lines of code. For instance an hello-world endpoint:

package main

import (
    "github.com/gin-gonic/gin"
)

func main() {
    r := gin.Default()

    // Define a simple GET route
    r.GET("/hello", func(c *gin.Context) {
        c.JSON(200, gin.H{
            "message": "Hello, World!",
        })
    })

    // Run the server on port 8080
    r.Run(":8080")
}

Running the API

To start your server, run:

go run main.go

Now, navigate to http://localhost:8080/hello in your browser or use curl:

curl http://localhost:8080/hello

Conclusion

Building an API with Golang and the Gin framework is an excellent choice for developers looking for speed, efficiency, and simplicity. With its minimalistic design and powerful capabilities, Gin makes it easy to set up routes, handle requests, and scale applications efficiently.

Introduction

Modern software delivery demands that changes roll out smoothly and safely. Enterprise-scale systems require strategies that let teams deploy, test and roll back without disrupting users.We will explore various deployment strategies. Understanding these methods will help you refine your DevOps practices ensuring a resilient process.

Blue/Green Deployment

This deployment involves maintaining two identical production environments. One environment, Blue, actively serves all traffic while the other, Green, holds the new release. Once the release in Green environment passes all testings and validations, traffic is switched over, making Green the active environment.

Benefits:

• Zero-downtime deployments: users experience no service disruption during the switch

• Quick rollback: In case of issues, reverting back to Blue environment is immediate and straightforward

Challenges:

• Cost: Maintaining two parallel environments can double resource usage

• Infrastructure complexity: Requires robust routing and load balancing

Canary Deployment

With canary deployments, new versions are rolled out to a small subset of users first before a full-scale launch. This approach helps to mitigate risk by exposing only a limited audience to potential issues.

Benefits:

• Reduced risk: Potential errors affect only a small percentage of users.

• Data-driven feedback: Early metrics and user feedback enable quick adjustments before full release.

Challenges:

• Complex routing logic: Managing and identifying canary traffic calls for advanced traffic segmentation.

• Monitoring: Continuous performance monitoring is critical to detect anomalies early.

Rolling Updates

This strategy gradually replaces instances of the previous version with the new version, one by one or in small batches. This ensures that a portion of your infrastructure is always running stable version.

Benefits:

• Resource efficiency: No need to duplicate environments fully, reducing costs.

• Availability: The service remains online as only a subset of instances is drained at any given time.

Challenges:

• Inconsistencies: Modifications to shared state (database) during updates can lead to inconsistencies if not carefully managed.

• Strain on load balancing: Requires distributed traffic management to ensure consistent performance across all instances.

A/B Testing

This sophisticated method empowers organization to evaluate and compare two different versions of an application in production environment. Two versions (A and B) of an application or service run simultaneously to compare performance, engagement and reliability.

Benefits:

• User insights: Directly assess how users react to changes

• Incremental improvements: Use metrics to drive decision on version to keep

Challenges:

• Statistics: Determining whether a change is beneficial requires robust data collection and analysis measure

• Resource duplication: May require additional backend logic to support both routes concurrently

Feature Flags

It decouples code deployments from feature releases. This means that new code is pushed to production but hidden behind flags until it’s ready for exposure.

Benefits:

• Granular control: Enable or disable feature in real time without further deployment

• Experimentation: A/B test features without risking overall system stability.

Challenges:

• Technical debt: Overuse or mismanagement of flags can complicate code maintenance.

• Configuration complexity: Managing and tracking flags across different environments requires diligent processes and tooling.

Conclusion

Choosing the right deployment strategy is crucial for the success of DevOps initiative. Each strategy has its own set of advantages and is suited for different scenarios. By understanding these strategies, team can make decisions aligned with their business goals, enhance user experience.

What is Azure Bastion

Azure Bastion is a platform-as-a-service (PaaS) offering that allows you to connect to your Azure VMs without exposing them to the public internet. It acts as a secure gateway, enabling you to access your VMs using RDP and SSH protocols directly from the Azure portal. It eliminates the need for public IP address on the VMs and reducing the attack surface and enhancing security.

Benefits of Azure Bastion

• Enhanced Security: By eliminating the need for public IP addresses on your VMs, it also provides a secure connection over SSL, ensuring that your data is encrypted in transit.

• Seamless Connectivity: Azure Bastion allows you to connect to your VMs directly from the Azure portal without the need for additional client software. You can also use Azure CLI with the bastion extension, but it requires Standard Tier. This simplifies the process of managing your VMs and enhances user experience.

• Integrated with Azure Services: It integrates seamlessly with other Azure services, such as Azure Entra ID (AAD) for authentication, providing a unified security model across your Azure environment.

• Scalability: Azure Bastion automatically scales to meet your needs, ensuring that you have the resources required for your workloads.

How to Set Up Azure Bastion

Setting up Azure Bastion is a straightforward process. Here’s a step-by-step guide to get you started:

1. Create a Virtual Network, ensure that you create a subnet specifically for Azure Bastion named AzureBastionSubnet

2. Create Azure Bastion Host. Fill in the necessary details

   1. Name: Provide a name for your Bastion host.

   2. Region: Select the same region as your virtual network.

   3. Virtual Network: Choose the virtual network you created in Step 1.

   4. Public IP: Create a new public IP address for the Bastion host.

3. Once the Bastion host is deployed, navigate to your VM and choose Bastion under the Connect menu. Enter username and password.

   

Conclusion

Azure Bastion is an essential service for organizations looking to enhance the security of their Azure environments. By providing secure and seamless access to VMs without the need for public IP addresses, Azure Bastion significantly reduces the risk of cyber threats while simplifying the management of your resources.

Managed identity provides seamless authentication to Azure resources.

Prerequisites

• Create ACR

• Create Azure VM with managed identity attached to it (System or User assigned)

• Add AcrPull role on the managed identity

• Install Az CLI on the VM. Follow the documentation here

Login to Az CLI using Managed Identity

az login --identity

Login to ACR

az acr login —name <registryName>

Pull image from the container

docker pull <registryName>.azurecr.io/imageName:tag

What are DORA metrics?

DORA was a team at Google Cloud focused on assessing DevOps practices using standard set of metrics. It’s a set of key performance indicators (KPIs) that help organizations assess their software delivery performance. The four primary DORA metrics are:

Deployment frequency

This metric measure how often an organization deploys code to production. High performing team deploys multiple times a day. Lower performing team deploys may deploy only once a month or less.

Lead Time for Changes

This metric tracks the time it takes for a code change to go to from development to production. Shorter lead times indicate a more efficient development process. Team can respond quickly to customer needs and market changes.

Mean Time to Restore (MTTR)

MTTR measure the average time it takes to recover from a failure in production. A lower MTTR indicates that a team can quickly address an issue and minimize downtime, important to maintain customer satisfaction.

Change failure Rate

This represents the percentage of changes that result in a failure in production. A lower percentage suggest that a team has effective testing and development practice, reducing the risk of disruptions.

How to implement DORA metrics?

To effectively implement DORA metrics in your organization, you should consider the steps below:

1. Establish baseline : measure the current performance against the metrics

2. Set goals : Define clear and measurable (SMART) goals for each metrics.

3. Monitor the progress : Track and review your DORA metrics to assess progress. Use dashboard to visualize your data.

4. Foster a culture of learning : Encourage team to share insights and learning.

5. Iterate and adapt : As you evolve and progress, revisit your goals and metrics to ensure they remain aligned with your business objectives.

Conclusion

DORA metrics provide a powerful framework for organizations looking to enhance their DevOps practices and improve software delivery performance. By focusing on deployment frequency, lead time for changes, mean time to restore, and change failure rate, teams can gain valuable insights into their processes and drive continuous improvement.

What is git for-each-ref?

The command allows you to iterate over and examine refs in your repository. Refs are pointers to commits and are located in directories like .git/refs/heads (branches) and .git/refs/tags (tags).

Basic Syntax

git for-each-ref [<option>] [<ref-path>]

• <option> : Modify the output format

• <ref-path> : Specify the category of refs to include. For example:

  • refs/heads/ list branches

  • refs/tags/ list tags

  • refs/remotes/ list remote branches

Use Cases and Examples

1. List all branches

    git for-each-ref refs/heads/
   

   This command will display the refs for all local branches.

2. Customizing Output

   Use the --format option to control the output. For instance, to display each branch name along with the last commit message:

    git for-each-ref refs/heads/ --format="%(refname:short) - %(subject)"
   

   • %(refname:short): Displays the branch name without the full refs/heads/ prefix.

   • %(subject): Shows the commit message.

3. Sort Branches by Date

    git for-each-ref refs/heads/ --sort=-committerdate --format="%(refname:short) - %(committerdate)"
   

   --sort=-committerdate: Sorts by the committer date in descending order.

4. List Tags with Commit Info

    git for-each-ref refs/tags/ --format="Tag: %(refname:short), Commit: %(objectname), Message: %(subject)"
   

   %(objectname): Displays the commit ID (hash) associated with the tag.

Formatting Placeholders

Here’s a quick reference for some commonly used placeholders in --format:

Conclusion

This command is helpful when you need advanced customization or insights into your refs. Instead or relying on git branch or git tag commands, for-each-ref will tailor the output to your exact needs.

• Azure DevOps organization and projects

• The appropriate permissions to create and manage service connection. See official page here

Create a service connection

If you don’t have service connection ready to be shared, please the steps below to create one.

1. In your DevOps project settings

2. Select service connections

3. On the next page select New service connection at the top right

4. On the opened panel, select the authentication method and enter the required parameters

   

Share a service connection

To share a service connection, go to the service connection menu and select the service connection. Click on the three dots to display the security menu.

On the security page, you will find at he bottom, you will find Project permissions. By adding others projects in your organization, you will be able to use the service connection in those projects.

Conclusion

Having one service connection that is shared between project reduce the maintenance task. If the service need to be updated, a token renewal for instance, it will be done in one place.

The shared service connection name will slightly change in the projects:

In the original project : The service connection will have a tagged Shared

In the other projects : In other project the service connection name will be as follow : OrignalName-ProjectName

For example: if we decide to share the service connection AZ-POC with the project Sandbox. The service connection name in Sandbox will be AZ-POC-Sandbox.

Remove local committed changes

If you have accidentally made a wrong commit in Git on you local repository (not pushed to the remote). You have used git commit command, meaning the commit only exist only locally.

You can use git status to verify the last commit on your branch.

Use the following command to undo you commit:

git reset --soft HEAD~1

The command will undo (remove) the last commit on your branch, but it will keep the changes.

Remove remote committed changes

Sadly your faulty commit was pushed to the remote and you want to undo it.

⚠️ I recommend to not undo commit on the remote as you will rewrite the branch history. Instead use the revert command.⚠️

First identity the commit hash with the command below :

git log --onleline

Then you can undo the faulty commit using the hash and push the modification to the remote

git revert <commit-hash> --no-edit # Revert the commit
git push # Push the modification to the remote

The branch history will show the commit and the revert commit.

Conclusion

There are several ways to remove commits from Git, we exposed two simple methods to perform this task.

• git reset : This command is used to undo a commit that has not been pushed to the remote, allowing you to update your local repository.

• git revert : This command safely undoes a commit that has already been pushed to the remote by creating a new commit that revert the changes