DEV Community: Héctor Vela

Seeing the Big Picture: A Key Skill for Software Engineers

Héctor Vela — Fri, 17 Nov 2023 22:00:13 +0000

Introduction

Have you heard the expression "missing the forest for the trees" ? It's a classical example of not being able to see the big picture, to put all your attention and focus on just a small part of a larger situation. Big picture thinking refers to a thinking strategy that focuses on the entirety of a concept or idea instead of on each individual detail1.

Being able to appreciate the big picture is an essential skill for any professional, but I think it is particularly important for IT consultants. We, as software engineers, quality engineers, project managers, SREs and all other IT professions, are usually part of a complex ecosystem of technologies, processes and business rules and decisions. Nobody is an island.

Once, in a project, a seemingly simple change needed to be implemented. The task involved adding a "tag" to the objects within a system. This "tag" was obtained from another system. The change itself was straightforward: adding an extra field to the object, making a call to the service, and storing the data in the object. The ticket was rated at 1 story point.

The tagging system was maintained by a team in a different time zone, and it took a couple of days to adjust the integration. Subsequently, validating and testing the change took a couple more days. Thus, what was initially a 1-point change ended up taking almost two weeks and at least 3 teams working on it, needless to say, our stakeholders were not pleased with the delay.

This serves as an example of how overlooking the bigger picture can hinder progress. Considering the problem holistically and making accurate estimations allows for better planning and task coordination. In an alternate scenario, identifying all actors and actions during estimation could have reduced the time. Timely notifications to the involved teams and individuals would have contributed to a more efficient integration. While the task estimation might be more than a single story point, it would have taken less time than the other scenario, and the stakeholders would have been reassured by seeing that everything went smoothly and without delays and the integration would have been carried out more efficiently.

Developing big picture thinking allows us to see how our work fits into the overall system, understand the balance of trade offs, improve our communication and collaboration, and be more productive and innovative.

Understanding the Big Picture

In software development big picture thinking goes way beyond just code. Is about understanding or, at the very least, being aware of the relationship between the different parts of a software project. For example:

The needs of the users and other stakeholders. Oftentimes we work on isolated teams/services/areas and it's easy to lose perspective and make decisions that we think are the best for our context, but sometimes what is the best for a part of a system, is not the best for the system as a whole.
The overall architecture of the system. We need to be able answer the questions: what are the main components of the system? How do the components interact with each other? How's the system deployed and operated? What are the non-functional requirements of the system, such as performance, security, and scalability? These are not the only questions to answer, but you have the idea. If you don't have the answer for these questions, you better start asking for answers.
The business goals and objectives that the system is intended to support. By keeping the business goal in mind, we can design and implement new systems/processes/features that are more likely to succeed.

These are not the only points we can or should consider, but are a good starting point.

Benefits of Big Picture Thinking

Developing big picture thinking can give us great benefits, for example: knowing the goal of your project, what services to consume, the technologies used in the system, can help us make better decisions about the design and implementation of our code and be prepared about how future changes might impact the system or the project. It can also help us be more productive by helping us to identify the most important tasks, detect dependencies and estimate the effort to complete and prioritize them. Innovation is also easier once we start to understand the big picture, you start thinking in broader solutions, foreseeing future problems and start taking measures to mitigate them.

When you can understand the big picture, everybody benefits from it. You can help others understand it, you can justify and communicate better your decisions and understand the ones taken by your stakeholders.

In the early 1990s, Apple was on the brink of collapse. The company was facing increased competition from IBM and Microsoft, which had both released successful operating systems and computer products. Its bloated product lineup and ineffective marketing led to a deteriorating relationship with customers.

Key Decisions:
In 1997, Steve Jobs returned as CEO, focusing on innovation and simplifying the product lineup to two desktops and two laptops. He improved the marketing strategy and restored customer relations, stating, "Innovation distinguishes between a leader and a follower."

Results:
Under Jobs, Apple introduced the iMac in 1998, followed by successful products like the iPod, iPhone, and iPad. Today, Apple, valued over $2 trillion, reflects the power of big picture thinking and bold decisions in turning around adversity.

How to Develop Big Picture Thinking?

Although some people are able to see it at first glance, naturally, being able to see the big picture is a skill that can be learned and honed. The following are some techniques that can help you to improve your ability to think:

Have a "think" checklist. Whenever you have to start working in something ask yourself a couple of questions like:
- Who's going to use it?
- Which other entities (services, teams, actors) will be involved?
- What is most likely to change over time?
Practice Second-Order thinking. This is a technique of strategic thinking that is, thinking in terms of interactions and time. Second order thinkers ask themselves the question “And then what?” 2 this exercise will help you conceptualize the consequences of your decisions over time.
Make it a habit. Practice makes perfect, right? Making habits is hard, but not impossible. First, you need to make time for thinking, you can start blocking some time out of your calendar to make time to think, or you can introduce this "thinking time" into your daily routine and multitask and do it while doing a mechanical task (like walking, showering, doing the dishes). The important thing is to think.3
Create To-Focus-On Lists. Where should your attention be concentrated?
Consider the future and the past. Consider past successes, post mortems / case analisys, and future trends while making decisions.
Capture your ideas. Take notes, and review them regularly.
Ask for feedback. Nobody is an island, remember? You need to sync and talk with people, so you don't end up misinterpreting anything important.

Conclusion

Big picture thinking is a critical skill for IT professionals, particularly software engineers, quality engineers, project managers, SREs, and others involved in complex technological ecosystems. It allows us to understand the context of our work, see how it fits into the overall system, and make informed decisions that align with business goals and objectives.

Developing big picture thinking takes practice and effort, but it is well worth it. By cultivating this skill, we can enhance our productivity, innovation, and communication, ultimately leading to greater success in our careers.

Remember:

Big picture thinking goes beyond code and encompasses the entire software ecosystem.
Understanding the needs of users, system architecture, and business goals is essential.
Big picture thinking brings significant benefits, including better decision-making, improved productivity, and enhanced innovation.
Develop big picture thinking skills through techniques like having a "think" checklist, practicing second-order thinking, and regularly reflecting on past experiences and future trends.

And the most important thing to remember: Big picture thinking is an ongoing journey, not a destination.

Do you want to know more?

Here's some recommended reading.

Thinking in Systems. by Donella H. Meadows: This book offers a framework for understanding how systems work and how to make effective interventions.
Range: Why Generalists Triumph in a Specialized World by David Epstein: This book argues that generalists are often more successful than specialists, as they are able to see connections across different domains.

Sources:

[1] Big Picture Thinking: Definition, Strategies and Careers
[2] Second-Order Thinking: What Smart People Use to Outperform
[3] Strategic Thinking (2017)

Introduction to Maps in Golang

Héctor Vela — Wed, 13 Sep 2023 21:56:25 +0000

Recently, I had the opportunity to participate as a mentor in an introductory Golang bootcamp. It was a very fulfilling experience to introduce engineers to the fantastic world of Go.

One of the subjects I had the opportunity to teach was about maps.

Introduction to maps

Maps are one of the most useful and versatile data structures. They are present in most of programming languages, you might already know them as Dictionaries in Python, Hash-maps in Java, Objects in JavaScript or associative arrays in PHP, to mention some.

They provide fast lookups (Maps provide constant-time (O(1)) average-case complexity for insertion, retrieval, and deletion operations), automatic key uniqueness, and dynamic size among other features.

We can think about maps as containers where we can easily store information and retrieve it.

Declaring maps in Go

A map declaration looks like:

map[KeyType]ValueType

Where KeyType is a type that can be compared, such as boolean, numeric, string, pointer, channel, interface, struct, or arrays containing only other comparable types.

ValueType can be any kind of value.

var products map[string]float64
fmt.Printf("products is of type %T and its value is %#v\n", products, products)
fmt.Println(products == nil)

After declaring a map, its value will be nil. A nil map behaves as an empty map for reads, but if you try to write on it, a runtime panic will be triggered.

fmt.Println(products["non existent key"]) // Prints an empty value as the key doesn't exist
// Attempting to write to a nil map will result in a runtime panic: assignment to entry in nil map
products["FashionCap"] = 99.99

Initializing maps

Same as with other types of values, there are a couple of different ways to initialize maps. You can use the make function, which is a built-in function that allocates and initializes objects like slices, maps, or channels. Alternatively, you can use the short variable declaration. The choice between these methods depends on your specific requirements and team coding standards.

After initializing a map, we can start adding values to it.

var products = make(map[string]float64)
products["Cool Hat"] = 99.99
fmt.Printf("products is of type %T and its value is %#v\n", products, products)

Working with map elements

The syntax needed to work with maps is simple and familiar.

As mentioned, we can initialize a map with the short variable declaration, so we can use it to initialize a populated map:

account := map[string]string{
    "dev": "691484518277",
    "qa":  "691515518215",
    "stg": "632515518875",
}

We add values to a map using the map name, the key, and the data to add.

// mapName[key] = valueToStore
account["prod"] = "369524578943"
fmt.Printf("%#v\n", account)

We can obtain values from a map by specifying the key for the data we want.

devAccount := account["dev"]
fmt.Printf("%q\n", devAccount)

If the map doesn't contain a value associated with a given key, the map will return the "zero value" for the value type.

uatAccount := account["uat"]
fmt.Printf("%q\n", uatAccount)

Map operations

Go provide us with some tools to work with maps. For example, we can count the keys a map has:

account := map[string]string{
    "dev":  "691484518277",
    "qa":   "691515518215",
    "stg":  "632515518875",
    "test": "",
}
fmt.Println("number of keys:", len(account))

Delete a map entry by key:

key := "dev"
delete(account, key)

When getting a value from a map using its key, the operation returns two values. The second value is a boolean that indicates whether the key exists in the map or not. You can use this boolean value to check if a key is present in the map before attempting to access its value.

if _, ok := account[key]; !ok {
    fmt.Printf("key '%s' not found\n", key)
    return
}

Go introduced a new maps package in its 1.21 version that introduces new utilities such as copy, clone, maps comparison functions and more!

Iterating over maps

We can iterate over a map by using a for loop with range. range allow us to loop through a map obtaining each key and value present in the map:

a := numberToStr{
    0:  "zero",
    1:  "one",
    2:  "two",
    3:  "three",
    4:  "four",
    5:  "five",
    6:  "six",
    7:  "seven",
    8:  "eight",
    9:  "nine",
    10: "ten",
}
for key, value := range a {
    fmt.Println(key, value)
}

If you tried to run the previous sample code, you will find that the map elements are print out of order. The order is random by design. This encourages developers to not rely on key order and prevent developers to make wrong assumptions about the order.

If you wish to loop through a map in order, then you'll need to do it by yourself. That is, extracting the keys into a slice or array, sort it, and then use the sorted iterable to retrieve the map values by key:

a := numberToStr{
    0:  "zero",
    1:  "one",
    2:  "two",
    // ...
}
// Extract the keys into a slice.
keys := make([]int, 0, len(a))
for key := range a {
    keys = append(keys, key)
}

// Sort the keys.
sort.Ints(keys)

// Iterate through the sorted keys and access the map elements.
for _, key := range keys {
    fmt.Println(key, a[key])
}

Maps and reference types

Maps are a reference type. This means that a map variable doesn't hold any value, but rather, it points to where the data is present in memory. When you assign a reference type to another variable or is passed as function argument, you are copying the reference, not the data.

You can think about this somewhat similar to real life tags. You might have a box with toys (the actual map data) labeled with a tag "Toys". You can slap a new tag labeled "Playing items" to the same box. The data is the same (the toy box), but now we have two variables ("Toys"/"Playing items") pointing to the same data.

// Maps are like tags on a box of toys.
toys := map[string]string{
    "1": "car",
    "2": "doll",
}

// Copy the tag to another box.
playingItems := toys

// Change the contents of the new box.
playingItems["1"] = "ball"

// The original box is also updated.
fmt.Println(toys["1"]) // "ball"

Key and values of different types

As previously mentioned, the keys of a map are of a comparable value and the keys can be of any value.

So, we could think about a case where we could have structs as map keys, this can be useful when associating addresses with specific individuals.

type person struct {
    firstName string
    lastName  string
}
type address struct {
    streetName   string
    number       string
    neighborhood string
    zipCode      string
}
peopleAddresses := map[person][]address{
    person{
        firstName: "Makko",
        lastName:  "Vela",
    }: []address{
        {
            streetName:   "Evergreen Terrace",
            number:       "742",
            neighborhood: "Henderson",
            zipCode:      "90210",
        },
        {
            streetName:   "Spalding Way",
            number:       "420",
            neighborhood: "Adamsbert",
            zipCode:      "63637",
        },
    },
}
makko := person{
    firstName: "Makko",
    lastName:  "Vela",
}
fmt.Println(peopleAddresses[makko])

We can also have cases where we need to use nested maps, for example when representing a hierarchical structure:

familyTree := map[string]map[string]string{
    "Juan": {
        "father": "Miguel",
        "mother": "Ana",
    },
    "María": {
        "father": "Alfredo",
        "mother": "Guadalupe",
    },
}

// Accessing nested map values
fmt.Println("Juan's dad is:", familyTree["Juan"]["father"])
fmt.Println("María's mom is:", familyTree["María"]["mother"])

Map use cases

Among the most common use cases we have:

Data association

For example, looking up definitions for words in a dictionary.

dictionary := map[string]string{
    "map": "a diagram or collection of data showing the spatial arrangement or distribution of something over an area",
}
fmt.Println(dictionary["map"])

Count items

Counting word occurrences in a text is useful, such as in text analysis or generating word clouds:

song := "Baby Shark, doo-doo, doo-doo, doo-doo, Baby Shark, doo-doo, doo-doo, doo-doo, Baby Shark, doo-doo, doo-doo, doo-doo, Baby Shark"
song = strings.ReplaceAll(song, ",", "")
words := strings.Split(song, " ")
lyricMap := map[string]int{}
for _, word := range words {
    if _, found := lyricMap[word]; !found {
        lyricMap[word] = 1
        continue
    }
    lyricMap[word]++
}
fmt.Printf("%#v\n", lyricMap)
// output would be: map[string]int{"Baby":4, "Shark":4, "doo-doo":9}

Cache

Maps can also serve as a basic in-memory cache to store and retrieve previously computed values efficiently:

func cache(key string) int {
    data, ok := cacheMap[key]
    if !ok {
        // do some expensive operation here to get `data`
        data = 123
        cacheMap[key] = data
        fmt.Println("expensive operation")
        return data
    }
    fmt.Println("serve from cache")
    return data
}

func main(){
    // prints "expensive operation"
    cache("key")
    // prints "serve from cache"
    cache("key")
}

Switch

We can take advantage of maps allowing any value types, we can even use functions as map values for implementing dynamic behavior.

calculator := map[string]func(a, b float64) float64{
    "sum": func(a, b float64) float64 {
        return a + b
    },
    "subtraction": func(a, b float64) float64 {
        return a - b
    },
    "multiplication": func(a, b float64) float64 {
        return a * b
    },
    "division": func(a, b float64) float64 {
        return a / b
    },
}
fmt.Println(calculator["sum"](3, 4))
fmt.Println(calculator["division"](3, 4))

Common errors

We already discussed some caveats we can find while using maps. Lets summarize them:

Nil map panic

Remember, maps need to be initialized using make or by using a composite literal before adding values to them.

var myMap map[string]string
myMap["value"] = "something"

Key not found

Reading a non existing key from a map results in the zero value for the type. It's essential to check for the existence of a key to avoid unexpected behavior in your code.

// key not found
var myMap map[string]string
fmt.Printf("%#v\n", myMap["non-existing-key"])

Maps are reference types

Remember that a map variable doesn't contain de data, but points to its memory location. Failing to account for this can lead to unexpected side effects when passing the map as parameter and this map is modified in the function.

func updateKey(myMap map[string]string) {
    myMap["key"] = "some other value"
}

func main() {
    var myMap = map[string]string{}
    myMap["key"] = "value"
    updateKey(myMap)
    fmt.Printf("%#v\n", myMap)
}

Maps and concurrent access

This is a more advanced topic I won't delve into this post, but just a word of warning, maps are not safe for concurrent writes (reads are ok). Concurrent safety is important because it ensures that a program behaves correctly when multiple threads are executing concurrently.

You can read more about this here, and if you need to implement concurrent writes, you can use sync.Mutex

Conclusion

In conclusion, maps are incredibly versatile and powerful data structures in Go, offering a convenient way to associate keys with values. Whether you're looking to create data associations, count items, implement a cache, or even switch between functions dynamically, maps have got you covered.

However, as with any tool, it's essential to be aware of common pitfalls, such as nil map panics and concurrent access issues, and to handle them with care. By mastering the art of using maps effectively and understanding their behavior, you'll unlock the full potential of this fundamental data structure in your Go programming journey.

So, go ahead, map out your data, and explore the endless possibilities that maps offer in your Go applications!

Post Script

You can find all the code used for this post in this gist.

Deploying Lambdas with AWS SAM & GitHub Actions: Step by Step

Héctor Vela — Fri, 30 Jun 2023 18:02:08 +0000

As a Web Developer with over 13 years of experience, I've witnessed the incredible evolution in code delivery. Uploading PHP files onto shared servers is almost ancient history, nowadays we embrace the power of CI/CD Pipelines in the cloud.

Having a Continuous Integration/Continuous Delivery pipeline becomes invaluable when working in complex applications. It allows for faster and more frequent releases, automating the deployment process and minimizing human errors. This not only saves us time but also ensures consistency across different environments, from development and QA to production and everything in between.

In this post, I'll walk you through some exciting stuff. We'll create a Lambda to handle GET requests and an authorizer Lambda to validate JWT and control API access, both under the same API Gateway. And we'll finish strong by configuring GitHub Actions to effortlessly deploy our Lambdas to AWS. Ready? Let's get to it!

Prerequisites

Before diving in, please ensure that you meet the following requirements:

An active AWS account with administrative IAM user access.
AWS CLI installed on your machine.
Configured AWS credentials for seamless interaction with AWS services.
AWS SAM CLI installed to facilitate serverless application development.
A GitHub repository to store your code.
A local development environment already set up. In this guide, we'll be using Go.
Docker installed on your machine for local testing purposes.

If you're starting from scratch and need assistance with the initial setup, you can refer to the Getting Started with AWS SAM guide in the AWS Documentation. It provides in-depth information to help you get up and running in no time.

Creating your lambdas

We'll be using SAM (Serverless Application Model) to create all of our resources. SAM is an open-source framework designed for building serverless applications on AWS. It utilizes a YAML format, which is a subset of the CloudFormation syntax. With SAM templates, you can easily define functions, APIs, databases, and various other AWS resources using just a few lines of code per resource. During deployment, SAM transforms and expands the SAM syntax into AWS CloudFormation syntax, simplifying the development process and accelerating serverless application building.

SAM offers a range of templates tailored for common use cases, and with the help of SAM CLI, creating a lambda function is very easy. You can start by using the "hello world" example and modify it according to your requirements.

Let's get started. Open your terminal and run sam init to launch the assistant.



$ sam init

You can preselect a particular runtime or package type when using the `sam init` experience.
Call `sam init --help` to learn more.

Which template source would you like to use?
    1 - AWS Quick Start Templates
    2 - Custom Template Location
Choice:

You'll be presented with two options. Choose option 1. Next, a list of templates will appear, and once again, choose option 1 (Hello World Example).

Now, it's time to select your runtime. For this guide, I'll select go1.x. As for the package type, let's choose zip.

The assistant will prompt you with a question about enabling X-Ray tracing and CloudWatch Application Insight for the function. Answer y to enable both.

Lastly, when asked for the name of your application, provide a suitable name. In my case, I'll name it hello-lambda.

SAM will create a new folder called hello-lambda with the following structure:



.
├── Makefile                    <-- Make to automate build
├── README.md                   <-- This instructions file
├── hello-world                 <-- Source code for a lambda function
│   ├── main.go                 <-- Lambda function code
│   └── main_test.go            <-- Unit tests
└── template.yaml

Now, you can begin by renaming the hello-world references with the desired name for your lambda or project, and add the functionality you need. For the sake of simplicity, I'll leave this hello world lambda as is.

Next, repeat the same process to create the foundation for a Lambda authorizer. I named my lambda lambda-authorizer and updated the folder and references from hello-world to authorizer.

Your folder structure should resemble something like this:



.
├──hello-lambda
│  ├──  Makefile
│  ├── README.md
│  ├── hello-world
│  │   ├── main.go
│  │   └── main_test.go
│  └── template.yaml
└──lambda-authorizer
   ├── Makefile                    <-- Make to automate build
   ├── README.md                   <-- This instructions file
   ├── authorizer                  <-- Source code for a lambda function
   │   ├── main.go                 <-- Lambda function code
   │   └── main_test.go            <-- Unit tests
   └── template.yaml

Note: Make sure to update the go version in the lambdas' go.mod files to ensure compatibility with the SAM tooling. It is recommended to use at least Go 1.18 (I'm using 1.20).

The code for the authorizer is quite straightforward. Currently, it simply validates the presence of a Bearer token in the Authorization header. An authorizer lambda must return an APIGatewayCustomAuthorizerResponse with either an Allow or Deny IAM policy.

Here is the complete code for the authorizer. Feel free to add any additional validation logic you require within the handleRequest method:



package main

import (
    "context"
    "strings"

    "github.com/aws/aws-lambda-go/events"
    "github.com/aws/aws-lambda-go/lambda"
)

func handleRequest(ctx context.Context, event events.APIGatewayCustomAuthorizerRequest) (events.APIGatewayCustomAuthorizerResponse, error) {
    token := event.AuthorizationToken
    if token == "" || !strings.HasPrefix(token, "Bearer") {
        return generatePolicy("Deny", event.MethodArn), nil
    }

    return generatePolicy("Allow", event.MethodArn), nil
}

func main() {
    lambda.Start(handleRequest)
}

func generatePolicy(effect, resource string) events.APIGatewayCustomAuthorizerResponse {
    authResponse := events.APIGatewayCustomAuthorizerResponse{PrincipalID: "user"}

    if effect != "" && resource != "" {
        authResponse.PolicyDocument = events.APIGatewayCustomAuthorizerPolicy{
            Version: "2012-10-17",
            Statement: []events.IAMPolicyStatement{
                {
                    Action:   []string{"execute-api:Invoke"},
                    Effect:   effect,
                    Resource: []string{resource},
                },
            },
        }
    }

    return authResponse
}

Building and Packaging Lambdas with SAM

We have our lambdas ready, and technically, we can use the SAM command sam deploy to deploy each lambda individually to AWS. However, before doing that, we need to take a few steps to:

Deploy our lambdas as part of the same API gateway.
Create the necessary roles for SAM to create resources and enable interaction between our resources.
Deploy everything with a single command.

To achieve this, let's create a new template.yaml file in the root folder, at the same level as hello-lambda and lambda-authorizer.

In this file, we'll define a few important components:

The API gateway where our lambdas will be accessible.
A role that grants permissions to our lambdas to write to CloudWatch.
The build method for our lambdas.

To save time, let's copy the contents of the template.yaml file from hello-lambda and start adding our additional resources.

First, let's add the resource definition for the authorizer lambda. Note that it will have the same definition as the one in lambda-authorizer/template.yaml, but without the Events section.



  AuthorizerFunction:
    Type: AWS::Serverless::Function
    Metadata:
      BuildMethod: makefile
    Properties:
      CodeUri: lambda-authorizer/
      Handler: authorizer/authorizer
      Runtime: go1.x
      Architectures:
        - x86_64

Then, we will define our API Gateway and specify the authorizer function.:



  HelloWorldApiGateway:
    Type: AWS::Serverless::Api
    Properties:
      StageName: v1
      Auth:
        DefaultAuthorizer: TokenAuthorizer
        Authorizers:
          TokenAuthorizer:
            FunctionArn: !GetAtt AuthorizerFunction.Arn
            Identity:
              ReauthorizeEvery: 0

Things to note here are:

StageName is optional, but this value represents the name of the deployment stage for your REST API. It is typically used to distinguish different versions or environments of your API.
FunctionArn, as the name implies, is the ARN of the authorizer lambda. Because we are just creating the lambda and we don't know the ARN yet, we are obtaining the ARN value with the GetAtt function. If you already have a lambda created anddeployed, you can use its ARN here.
ReauthorizeEvery: This property of Identity controls the cache for the authorizer lambda. Here, we are disabling the cache by setting the value to 0. This means that every call will pass through the authorizer lambda.

Next, let's add another resource. This resource will define the role our lambda will assume to be able to write to CloudWatch and send traces to X-Ray.



  ConfigurationLambdaRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - lambda.amazonaws.com
            Action:
              - sts:AssumeRole
      Policies:
        - PolicyName: HelloLambdaRolePolicy
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - logs:CreateLogGroup
                  - logs:CreateLogStream
                  - logs:PutLogEvents
                  - xray:PutTraceSegments
                  - xray:PutTelemetryRecords
                  - xray:GetSamplingRules
                  - xray:GetSamplingTargets
                Resource: '*'

Then, we are going back to the definition of our HelloWorldFunction to add the role to assume.

This is the final resource definition:



  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Metadata:
      BuildMethod: makefile
    Properties:
      CodeUri: hello-lambda/
      Handler: hello-world/hello-world
      Role: !GetAtt HelloLambdaRole.Arn
      Runtime: go1.x
      Architectures:
        - x86_64
      Events:
        CatchAll:
          Type: Api
          Properties:
            Path: /hello
            Method: GET
            RestApiId:
              Ref: HelloWorldApiGateway

Note that we removed the environment section as we don't need it, but you can use this section to pass Env Var values to your lambda code.

The values for CodeUri and Handler have also changed. The new values follow the pattern:



CodeUri: <folder created by sam init>/
Handler: <lambda name>/<binary filename>

We also added a new property, Metadata. This is used to specify a custom build command when compiling the lambda. However, we need to go to each of our lambda's Makefiles and add the following:



# hello-lambda/Makefile
build-HelloWorldFunction:
    cd hello-world; GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o hello-world main.go
    mv hello-world $(ARTIFACTS_DIR)
.PHONY: build-HelloWorldFunction

# lambda-authorizer/Makefile
build-AuthorizerFunction:
    cd authorizer; GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -o authorizer main.go
    mv authorizer $(ARTIFACTS_DIR)
.PHONY: build-AuthorizerFunction

What's happening here? let's take hello-lambda as example:

The Makefile is located at the root level of the hello-lambda folder. So, we need to change the directory to hello-lambda, which is the folder containing our go.mod file.
We set some flags for building the project:
- GOOS=linux: This flag sets the target operating system to Linux.
- GOARCH=amd64: This flag indicates that the resulting binary is optimized for 64-bit systems, specifically x86_64 processors.
- CGO_ENABLED=0: This flag is commonly used when you want to create a pure Go binary without relying on external C libraries. It makes your Go application more easily compiled and executed on different platforms without worrying about compatibility issues with C libraries.

The last change to make in our global template.yaml file is to update the outputs to reference the API Gateway we just defined and the role we are creating:



Outputs:
  HelloWorldAPI:
    Description: API Gateway endpoint URL for Prod environment for First Function
    Value: !Sub "https://${HelloWorldApiGateway}.execute-api.${AWS::Region}.amazonaws.com/v1/hello/"
  HelloWorldFunction:
    Description: First Lambda Function ARN
    Value: !GetAtt HelloWorldFunction.Arn
  HelloWorldFunctionIamRole:
    Description: Explicit IAM Role created for Hello World function
    Value: !GetAtt HelloLambdaRole.Arn

You can view the final and complete template.yml file here

Now we can start checking if everything works as expected. So lets build the project!

In your terminal, change directories to the project root and run:



$ sam build

If everything is correct, you should see something like:



Build Succeeded

Built Artifacts  : .aws-sam/build
Built Template   : .aws-sam/build/template.yaml

Commands you can use next
=========================
[*] Validate SAM template: sam validate
[*] Invoke Function: sam local invoke
[*] Test Function in the Cloud: sam sync --stack-name {{stack-name}} --watch
[*] Deploy: sam deploy --guided

If you encounter any errors, here are some common issues to check:

Misspelled resource names or wrong paths in template.yaml.
Incompatible (old) Go version.
Misspelled attributes in template.yaml. A common error is using .arn instead of .Arn.

At this point, we should be able to deploy our lambdas using SAM CLI. You can do so by running:



$ sam deploy --guided

An assistant will ask you for some information about your project and your AWS account, such as the name to give the stack, the region for deployment, and if you need to review changes before applying. Once you provide the required details, you should be good to go! However, we don't want to manually deploy our lambdas. Let's see how we can set up a GitHub workflow and leverage some cool features of SAM.

After building our project and ensuring everything is in order, it's a good time to run:



$ sam pipeline init --bootstrap

This command will initiate an interactive assistant that guides you through creating the necessary AWS infrastructure resources for SAM to deploy your code. During the process, you will be prompted to select a user permissions provider. Choose OpenID Connect (OIDC), which will create a role for the GitHub workflow to deploy our project and monitor the creation process.

The assistant will also assist you in setting up a multi-stage deployment. It will ask you which branches should be pushed to the Dev environment (usually dev or development) and which branch should be deployed to the Production environment (usually main branch).

Once you complete the questionnaire, the bootstrapping process will begin. When it finishes, you'll have:

A new CloudFormation Stack with the resources required by SAM and GitHub Actions.
An IAM role assumed by AWS CloudFormation when applying the changeset.
An IAM role assumed by the GitHub Workflow to deploy our artifacts.
A pair of S3 buckets used to upload your AWS CloudFormation template and store output logs.
A new GitHub workflow file that contains everything you need to run your deployment pipeline upon merging. Remember to add, commit, and push this file to your repository.

If you are the owner of both the AWS account and the repository, and you have successfully completed the bootstrap process, you're all set! You can now create a new pull request to the specified Dev or Production environment branch, and the GitHub workflow will kick off.

You can monitor the deployment process either in the Actions tab of your GitHub repository or in the AWS console, specifically in the CloudFormation service panel.

Note that in the logs displayed for the deployment job in GitHub, there is an "Outputs" section where you can find the API Gateway URL for the lambda function. Let's give it a try!

First, let's check if the authorizer lambda is working correctly by making a request to our API without an Authorization header:

Request



curl --location 'https://qk1d1uv590.execute-api.us-east-1.amazonaws.com/v1/hello/'

Response
We should receive an HTTP status code 401 (Unauthorized).



{
    "message": "Unauthorized"
}

Now, let's add a JWT to our request:

Request



curl --location 'https://qk1d1uv590.execute-api.us-east-1.amazonaws.com/v1/hello/' \
--header 'Authorization: Bearer token.jwt.value'

Response



Hello, <your IP should appear here>

And there you have it! We did it! Let's recap and see what we have accomplished:

Created a Lambda function
Created an authorizer lambda
Created a SAM template to manage all of our resources in one place
Used SAM CLI to create the necessary roles for resource creation and deployment, as well as an OIDC role for GitHub Actions to assume and run our jobs
Completed the setup of our CI/CD pipeline

But wait! There's more!

If you are the owner or admin of the AWS account, you can stop reading here. But what happens when you have a limited AWS role, or you don't need to deploy to multiple stages?

That was the case for me. I was working for a client (the owner of the AWS account) and my AWS role couldn't create resources "directly". Additionally, SAM was already bootstrapped, and I only needed to deploy to a single stage. As a result, I didn't benefit from running sam pipeline init --bootstrap or sam pipeline bootstrap, which would have set up the OIDC role, GitHub Workflow definition, and AWS stages.

So let's go back a bit and imagine that we just finished modifying our template.yaml file and ran sam build.

Setting Up GitHub Actions Workflow

Ok. Let's take a step back for a moment. What exactly are these GitHub Actions?

GitHub Actions is a feature of GitHub that allows us to automate our software development workflows within GitHub repositories. It can be used for continuous integration and continuous delivery (CI/CD) of code, as well as automating other software workflows such as building or testing code directly from GitHub.

To create and define a workflow, you need to create a YAML file in the .github/workflows/ folder of your repository. The name of the file doesn't matter. A workflow consists of one or more events that trigger the workflow, one or more jobs that execute on runner machines, and a series of steps within each job. Each step can run a script that you define or an action, which is a reusable extension that simplifies your workflow.

Now, let's create our workflow file. I'll create the file .github/workflows/dev-deploy.yaml.

First, we specify the permissions we want to give to the GitHub Workflow runner. These permissions modify the default permissions granted to the GITHUB_TOKEN, allowing us to add or remove access as required:



permissions:
  id-token: write # This is required for requesting the JWT
  contents: read # This is required for actions/checkout

Next, we indicate the event that will trigger this workflow:



on:
  push:
    branches:
      - main

In this case, we're telling the Workflow runner to execute the workflow whenever there are new changes pushed to the main branch. You can utilize various events for different triggers.

Now, let's move on to the main part of the workflow: the jobs. Each job runs in a runner environment specified by runs-on. A job consists of a sequence of tasks called steps. Steps can run commands, set up tasks, or execute an action within your repository, a public repository, or an action published in a Docker registry.

For more information about Jobs and Steps, you can refer to the official documentation site.

Now, let's take a look at the job and steps we'll be using to deploy our resources:



    steps:
      - uses: actions/checkout@v3
      - uses: aws-actions/setup-sam@v2
        with:
          use-installer: true
      - uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-region: us-east-1
          role-duration-seconds: 1800
          role-skip-session-tagging: true
          role-to-assume: arn:aws:iam::269174633178:role/aws-sam-cli-managed-dev-pipe-PipelineExecutionRole-1TGFGMZ8QQ4DO
      - uses: actions/setup-go@v2
        with:
          go-version: '1.20'
      - run: |
          # Define a list of folders (lambda_folder/code_folder) to run go mod tidy in.
          folders=(
            "lambda-authorizer/authorizer"
            "hello-lambda/hello-world"
          )
          # Loop through each folder and run 'go mod tidy'
          for folder in "${folders[@]}"; do
            echo "Running 'go mod tidy' in $folder"
            cd $folder
            go mod tidy -go=1.20
            cd ../..
          done
      - run: sam build
      # Prevent prompts and failure when the stack is unchanged
      - run: sam deploy --no-confirm-changeset --no-fail-on-empty-changeset --role-arn arn:aws:iam::269174633178:role/aws-sam-cli-managed-dev-p-CloudFormationExecutionR-830GQUQ9J19P --stack-name sam-lambdas --resolve-s3 --s3-prefix "sam-lambdas" --region us-east-1 --capabilities CAPABILITY_IAM

Here, we have only one step, but several things are happening. First, we are utilizing some existing GitHub Actions. The uses keyword is used to specify an action that should be executed as part of the workflow, and with: <parameters> is a set of key-value pairs where the key represents the input parameter name expected by the action, and the value represents the value you want to assign to that parameter. In this case, we are using actions to check out the code, install SAM CLI in the GitHub runner, and build and deploy our project.

Lastly, the run command is used to execute command-line programs using the operating system's shell. As you can see here, we are running the go mod tidy command in each of our lambdas, ensuring that our project builds reliably and uses the correct versions of its dependencies.

The final run command deploys our project with the following parameters:

--no-confirm-changeset: Prompts to confirm whether the AWS SAM CLI should deploy the computed changeset.
--no-fail-on-empty-changeset: Specifies whether to return a non-zero exit code if there are no changes to make to the stack. This prevents the workflow from being marked as failed if there are no changes in the project.
--role-arn: The Amazon Resource Name (ARN) of an IAM role that AWS CloudFormation assumes when applying the changeset. In this case, I'm reusing the roles created during the SAM bootstrap process. However, you can refer to this guide to create a role specifically for use in GitHub workflows.
--stack-name: The name of the CloudFormation stack.
--resolve-s3: Automatically creates an Amazon S3 bucket to use for packaging and deploying during non-guided deployments.
--s3-prefix: The prefix added to the names of the artifacts that are uploaded to the Amazon S3 bucket.
--region: The AWS Region to deploy to.
--capabilities: A list of capabilities that must be specified to allow AWS CloudFormation to create certain stacks.

You can learn more about these and other sam deploy options in the official documentation.

And that's it! Once you have pushed your workflow file to your repository, you should see the workflow start. You can monitor its progress in the "Actions" tab of your repository.

Some common issues you might encounter are:

"An error occurred (AccessDenied) when calling the PutObject operation: Access Denied."
- This means the OIDC role doesn't have the necessary permissions. It should have access to most CloudFormation and S3 actions.
"Missing option 'some option', 'sam deploy --guided' can be used to provide and save the needed parameters for future deployments."
- As the message implies, an option might be missing in your sam deploy command.

Conclusion and Best Practices

We have covered a lot in this article! In conclusion, we explored the capabilities of AWS Serverless Application Model (SAM) templates for creating Lambdas, implementing Authorizer Lambdas, defining AWS resources in a stack, deploying our stack, and setting up a CI/CD pipeline with GitHub Workflows.

SAM templates are a powerful and efficient approach to developing serverless applications. They allow us to define our application's infrastructure and functions in a single template file. With SAM, we can easily manage and deploy our serverless applications, ensuring scalability, reliability, and fast evolution. When combined with GitHub Workflows, we have a seamless CI/CD pipeline that automates our deployments and keeps our application updates flowing smoothly. With these awesome tools at our disposal, we are ready to build and deploy apps like professionals!

However, this article only scratches the surface, and there are many more topics to explore. For example, we didn't cover best practices. When deploying Lambdas with SAM and GitHub Actions, there are some best practices and recommendations to consider:

Continuous Integration and Deployment (CI/CD): We set up a CI/CD pipeline to deploy our stack, but it's common to use GitHub Actions to automate the build, test, and deployment process.
Environment-specific Configuration: Use environment variables to manage configuration values such as API keys, database connections, and other sensitive information. GitHub Secrets or AWS Systems Manager Parameter Store can be used to securely store and retrieve these variables during the CI/CD process.
Automated Testing: Implement automated tests for your Lambdas to ensure their functionality.
Security and Permissions: Follow the principle of least privilege when assigning IAM roles and permissions to your Lambdas. Only grant the necessary permissions required for their specific functionality. Avoid using long-lived AWS credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) and use roles instead.
Logging and Monitoring: Enable logging in your Lambdas and use CloudWatch Logs for log management. Implement monitoring and alerting using CloudWatch Alarms or third-party monitoring tools to detect issues and ensure your Lambdas work as intended.

And that's it, friends! You can take a look at the repository with the full code here.

Some recommended reading

Would you like to know more? click here to know more!

AWS SAM:

AWS SAM Developer Guide - Official documentation for AWS SAM, providing an overview, concepts, and examples.
AWS SAM GitHub Repository - The official GitHub repository for AWS SAM. It contains code samples, templates, and community contributions.

AWS Lambda:

AWS Lambda Developer Guide - Official documentation for AWS Lambda, covering various aspects, including deployment, programming model, and best practices.
AWS Lambda GitHub Repository - The official GitHub repository for AWS Lambda. It includes examples, guides, and resources specifically for working with Lambda in Go.

GitHub Actions:

GitHub Actions Documentation - The official documentation for GitHub Actions, covering topics such as workflows, syntax, and available actions.
GitHub Actions Marketplace - A marketplace of pre-built actions that can be used in your GitHub Actions workflows. You can search for actions related to AWS, SAM, or other specific needs.

Examples and Tutorials:

AWS Serverless Application Repository - A repository of serverless applications built using AWS SAM. You can explore and deploy ready-to-use applications or learn from their implementation.
GitHub Actions Examples - Example workflows that demonstrate the CI/CD features of GitHub Actions.

Instrumenting Go microservices with Gin and AWS X-Ray

Héctor Vela — Tue, 21 Mar 2023 22:57:24 +0000

In a microservice architecture, operations often span multiple services and resources such as gateways, microservices, load balancers, and databases. The distributed nature of microservices is what makes software instrumentation valuable.

If our code provides traces, metrics, and logs, we can say that it is instrumented, meaning we are able to observe how our system is performing.

Service instrumentation is especially useful for identifying and troubleshooting performance issues and errors. The data collected can also be used for capacity planning by helping us understand the traffic and usage patterns of our applications.

There are several solutions for services instrumentation, such as OpenTelemetry, Zipkin and datadog. AWS also offers an OpenTelemetry Distro to be able to use OpenTelemetry as observability backend while using X-Ray or any other third party solution to receive tracing telemetry data and provide processing, aggregation, and visualizations of that data.

In this post, I'm going to tell you about my experience instrumenting a Go microservice using Gin, with X-Ray.

Gin

Gin is a lightweight and high-performance web framework for the Go programming language, designed to make it easy to build fast and scalable web applications.

It features a minimalistic API, a robust router, middleware support, and built-in security features, making it an ideal choice for building microservices and other high-performance web applications.

While Gin may have a steep learning curve and limited built-in features, its simplicity and extensibility make it a popular choice for developers who prioritize performance and scalability.

Creating a gin service from scratch is out of the scope of this post, but you can read more about gin in the official documentation page.

AWS X-Ray

AWS X-Ray is an AWS service that collects data about requests served by your application and provides tools for viewing, filtering, and gaining insights into that data to identify issues and optimization opportunities.

Some pros of X-Ray over other similar tools are:

Integration with some AWS services
No extra infrastructure to manage (daemon included on AWS Elastic Beanstalk and AWS Lambda platforms)
Can work as a visualizer only (using OpenTelemetry as Tracer)
For supported services, X-Ray SDK can automatically send and trace request IDs across services
Managed by AWS
First 100k traces per month are free
First 1,000,000 traces retrieved or scanned each month are free.

However, some of its cons are:

AWS X-Ray can only be used with applications running on Amazon EC2, Amazon EC2 container service, AWS Lambda, and AWS Elastic Beanstalk.
After exhausting the free traces for the month, every trace indexed or queried has a cost.
Limited language support: While X-Ray provides SDKs for several programming languages, it doesn't support every language or platform, which may limit its usefulness in certain scenarios.
Vendor lock-in: Using X-Ray may lead to vendor lock-in with AWS, as it is a proprietary service only available on the AWS platform. This may limit your ability to switch to other cloud providers or tools in the future.

If, after reading some of the pros and cons, you are still inclined to use X-Ray, then you can continue reading.

Requirements

To view trace information in AWS, you need an AWS account and an application running on AWS infrastructure or integrated with AWS services. In addition, you'll need:

An instance of the X-Ray daemon, which can be run as a binary or as a Docker container. You can find detailed instructions on how to run and configure it here. For this article, I'll be using the OS X binary.
Your application must have the necessary permissions to interact with AWS X-Ray service and other AWS services that it uses.

IAM Role

To enable your application to send traces to X-Ray, you need to provide the X-Ray daemon with a role. To create the role, go to the "Roles" section in the AWS Web Console for the IAM service and click on the "Create Role" button.

In the wizard, select "AWS Account" for Trusted Entity and click "Next". On the next screen, search for the permissions policy named "AWSXRayDaemonWriteAccess". Click "Next" to proceed.

Add a name and description for the role, and then click "Create Role". This will take you back to the roles list. Look for the role you just created to view and copy the role ARN.

X-Ray Daemon

Now that we've created the daemon role, let's configure and run it.

For my local setup, I only needed to change a few settings, such as the log level, setting the local mode to true, and adding the X-Ray role and the AWS region.

Here's the config file I used:



# Send segments to AWS X-Ray service in a specific region
Region: "us-west-2"
Socket:
  # Change the address and port on which the daemon listens for UDP packets containing segment documents.
  UDPAddress: "127.0.0.1:2000"
  # Change the address and port on which the daemon listens for HTTP requests to proxy to AWS X-Ray.
  TCPAddress: "127.0.0.1:2000"
Logging:
  # Change the log level, from most verbose to least: dev, debug, info, warn, error, prod (default).
  LogLevel: "dev"
# Turn on local mode to skip EC2 instance metadata check.
LocalMode: true
# Assume an IAM role to upload segments to a different account.
RoleARN: "arn:aws:iam::269174633178:role/X-Ray_Daemon_role"
# Daemon configuration file format version.
Version: 2

You can learn more about other config values in the AWS X-Ray Developer Guide.

Instrumenting your Go microservice.

Now that we have the X-Ray daemon configured and running, we can add instrumentation to our service.

AWS recommends to start by tracing incoming requests by wrapping the service handlers with xray.Handler. However, since we are using Gin, the approach we'll implement is slightly different.

While looking for resources about how to instrument a gin application, I found this middleware by Oroshnivskyy which is based in the x-ray handler function.

This middleware will start and close a segment for every request received. It also, will take care of handling the trace ID header ("x-amzn-trace-id"), which is a header that contains an ID value that will be generated for each new request and will be propagated across all of our microservices.

So let's add the middleware to the routes we want to instrument:



// as part of my gin routes
v1.GET("/auth/roles", xraymid.Middleware(xray.NewFixedSegmentNamer("GetRoles")), controller.GetRoles)

Here, we are adding the (aliased as xraymid) x-ray gin middleware to a route of the group v1. The value passed as argument to NewFixedSegmentNamer must be set to a descriptive name for your route. This will be the name of the main trace group for this endpoint.

Alright! now let's see if it works! Start the service and verify the Daemon is running.

After making a request, we can see the in the daemon logs something like:



2023-03-21T13:10:47-06:00 [Debug] Received request on HTTP Proxy server : /GetSamplingRules
2023-03-21T13:10:48-06:00 [Debug] processor: sending partial batch
2023-03-21T13:10:48-06:00 [Debug] processor: segment batch size: 1. capacity: 50
2023-03-21T13:10:48-06:00 [Info] Successfully sent batch of 1 segments (0.109 seconds)
2023-03-21T13:10:49-06:00 [Debug] Send 1 telemetry record(s)

It looks like it's working! Let's see the trace in the AWS web console.

In your AWS web console, go to CloudWatch and in the side panel, look for X-Ray and click on the "traces" option.

If everything went well, you'll see the number of recently received traces, and the traces table will be populated with such traces.

In the traces table, click in an entry. We'll be taken to the trace view, were we can see the traced information.

Here we can see the trace data. We only are creating a segment and closing it for each call, so we don't have much other data, but we can see the response status code, the time it took for the request to be served, and, of course, the trace map, which for now includes only the client and the service.

Creating sub segments

So now that we have our basic instrumentation setup, what else can we trace?

As of now, we are only tracing a request and some of its metadata. But what if we want to be more granular?

Let's say we have an intensive process running as part of the request; we can add a subsegment to monitor it.

Somewhere in my service, the following code is executed when I call the auth/roles endpoint:



// inside a function
roles := make([]Role, len(rolesList))
for i, roleItem := range rolesList {
    role, err := u.buildRole(roleItem)
    if err != nil {
        return model.RoleList{}, err
    }
    roles[i] = role
}

We can wrap the for loop in a subsegment so we can see how much of the request time is spent in this process.

To add a subsegment, we wrap the loop as:



err = xray.Capture(ctx, "BuildRolesDetail", func(ctx1 context.Context) error {
    for i, roleItem := range rolesList {
        role, err := u.buildRole(roleItem)
        if err != nil {
            return err
        }
        roles[i] = role
    }
    if err = xray.AddMetadata(ctx1, "No. roles built", len(roles)); err != nil {
        return nepErrors.InternalServerError.WithDetail(err.Error())
    }
    return nil
})

Let's run our service and call again our instrumented endpoint.

This is the new trace in AWS CloudWatch -> Traces:

Now we see that the request took 215ms, and of those, the BuildRolesDetail loop took 205ms.

Are you starting to think about the tracing posibilities? You should! You can use xray.AddMetadata to add any extra information you need. Just take into consideration that X-Ray Daemon only sends to AWS up to 64KB of metadata per Segment.

Instrumenting AWS Clients with X-Ray

Instrumenting AWS clients using the SDK-V1 is fairly simple, you can follow the official guide.

There isn't much documentation about how to instrument AWS SDK-v2 clients, but the configuration is also simple.

Somewhere in your service code, you'll be initializing your AWS client(s). To add instrumentation to them, you just need to provide the clients with an X-Ray HTTP client and pass the request context along for every call.



cfg, err := config.LoadDefaultConfig(ctx)
if err != nil {
    return nil, err
}

// Create an HTTP client
httpClient := &http.Client{}

// Set the HTTP client as the AWS configuration's HTTP client
cfg.HTTPClient = httpClient

// Create an X-Ray client
xrayClient := xray.Client(httpClient)

dynamoClient := dynamodb.NewFromConfig(cfg, func(options *dynamodb.Options) {
    // Wrap the http.Client with an xray.Client
    options.HTTPClient = xrayClient
})

Here, I'm adding the X-Ray HTTP Client to the AWS DynamoDB Client.

Let's call again our instrumented endpoint.

I'm currently running DynamoDB locally, but you can already see how much time is spent per call to DynamoDB. We can also see that the Trace Map has been updated to show my local instance of DynamoDB.

Takeaways

Instrumenting a service with X-Ray is relatively simple, but it can get complex really fast depending on the things we want to monitor. Because of this, the effort to add tracing to your service might vary based on your use case.

Another thing to consider is the 64KB limit per segment. It might not be enough if you want to trace lots of subsegments or add more metadata. There are ways to circumvent this, but they are out of the scope of this post.

In conclusion, implementing X-Ray in a Go microservice is a straightforward process that can greatly benefit your application's observability and troubleshooting capabilities. The integration process is relatively easy, and the X-Ray SDK provides a range of useful features that make it easy to trace requests and identify bottlenecks. However, it's important to keep in mind that X-Ray does have some drawbacks, such as the cost associated with using it and the limitations of its sampling capabilities.

Nonetheless, with careful consideration and proper implementation, X-Ray can be an invaluable tool for debugging and optimizing your microservices architecture. So don't hesitate to give it a try and see how it can enhance the performance and reliability of your Go microservices.