DEV Community: Luis Serra

The journey to the main stage

Luis Serra — Thu, 14 Nov 2024 21:27:43 +0000

Introduction

Recently, I had the opportunity to present at my first international conference, and wow, what an experience! It feels amazing… though I’ll admit, it feels much better once the talk ends 😅.

Until that point, it’s all about sweaty palms, a racing heartbeat, and a constant need to have a bathroom near around!

But you know what? That’s part of the process. It might seem painful while you’re in it, but I have to say, it’s incredibly rewarding.

For some, being on stage feels natural, but not everyone is like that. Some people are just pretty good at faking it and I’ll confess, I’m one of them.

Maybe you’re thinking, “Yeah, yeah, nice story, but I don’t buy it.”

I don’t blame you. I used to feel that way. However, over time, I realized I could only handle these situations because I kept putting myself in uncomfortable positions again and again.

So, in the next few paragraphs, I’ll share some of those experiences and how they’ve helped me become more comfortable speaking to a crowd.

The first “stage” is always the hardest

I’ve been playing the clarinet for over 20 years now, at my hometown’s philharmonic.

When I was around sixteen, our president told me, “I won’t be able to present at the next concert, so I need you to step in as the host.” Pure terror, I think is that better describes what I felt in that moment. But my first question to him was, “What do I even say?”.

He gave me a few tips, so I went home, wrote down my speech, and got his feedback. Thankfully, it was positive — what a relief!

On the day of the concert, I barely looked at the audience. My eyes were glued to my notes. I only dared to look up once I’d finished reading the whole thing. But you know what? That didn’t matter, because the important thing was that I’d made it through that first experience. Looking back now, I realize how important that moment was.

What did I learn? Put yourself in uncomfortable situations, but try to control a few variables first. For me, the text was already prepared, so my main fear was just facing the crowd. Sometimes, that’s the first step to taking a risk.

How can you do it if you are not part of a philharmonic, are you asking? No problem! Volunteer to read in church. Not religious? That’s okay — prepare a toast for your next birthday and read it out loud to your friends. Feeling too much comfortable with them? Invite your boss or neighbours next time. Find your own first stage.

Body language talks more than words

I’m not sure how to start this part because I want this article to feel timeless, yet I also want to mention COVID-19 so, if you know what I’m talking about, this will be simpler to explain. If not, good for you — it means you didn’t have to experience being stuck at home during a global pandemic.

Crazy world problems apart, I have to say I was getting restless once restrictions began to be lifted. I wasn’t the only one, my girlfriend and a friend felt the same. So we took the time to do something productive and decided to take a formal training course.

Long story short, in Portugal, if you want to deliver certified training or become a technical instructor, you need specific qualifications.

In the course, we covered topics like group dynamics, engaging attendees, how to use digital platforms for e-learning and so on. But the most interesting part was the practical sessions.

In these sessions, you’re presenting to a room full of strangers on topics they may not know much about (everyone has different backgrounds). While they may not judge your content, they will notice your presentation style and body language.

It was incredibly useful. We were all there to improve, so it felt safe. I became more aware of habits like filler words, posture, and audience engagement — details I hadn’t fully noticed before.

Body language is crucial when presenting to a crowd. If you don’t make eye contact or if you only focus on one part of the room, people will lose interest quickly.

Ask colleagues or friends for feedback on your posture and delivery. Even remote feedback is valuable — it’s harder but still possible. Encourage them to give honest feedback, some people hold back, unsure of how it will be received.

This can also be a solo exercise. Just found good Instagram reels about this some days ago, by Vinh Quang Giang, about a process called Record and Review. Give it a check here.

What if I tell you that presenting sometimes it’s just like acting?

As usual, here’s another story from my life.

Imagine you’re having dinner with a friend, and he casually says, “Hey, I have news. I just started an improv theatre course.”

How would you react? My immediate response was, “Cool, can I join too?” Not sure if that’s the most typical reaction, but feel free to tell me in the comments 😅!

My initial thought was that I could learn something valuable for my professional life. And guess what? I was right (at least this time!).

In improv, we practised handling the unexpected — an essential skill for being on stage. All that confidence you build up can suddenly disappear if something goes wrong.

Your computer could crash, something falls getting out of your focus, and who knows, might burst into the room. Okay, maybe that last one might be scribbled 🦸.

But if things go sideways, embrace it — don’t let it throw you off. Check in with the audience, make a joke about the situation, or simply move around the stage.

One of the most important things I learned in improv was how movement can help us get out from blocking moments.

Or, just like a classic soap opera villain in a tense scene. Take a sip of whiskey…or better yet, stick to water this time!

Search for smaller stages at the beginning

No one starts on huge stages, right? It’s like running a marathon, you need to build up gradually. So, where to start?

It depends. In the tech world, which I’m familiar with, you could begin by presenting a topic within your company. If they don’t support your idea, look outside. There are meetup groups for nearly everything, so you’ll likely find one that matches your interests.

Are they all too far away? Ask one of your teachers if your school might be interested in an open session on a specific topic, and volunteer as the first speaker.

Still can’t find anything? Maybe it’s time to brush up on those Google skills — or ask AI for ideas!

Still no luck? No excuses. Get creative! I’m pretty sure that there is a stage waiting for you.

Test your talk when you’re bored

First, let me confess — I don’t have a set method.

I like things to flow organically, and I probably don’t test my talks as much as I should before going live. I like the thrill of a little risk.

That said, I do have a rough outline of what I want to cover and the flow that I what to follow during it.

Where do I finalize most of my ideas? In the car, on my way to the office or home. If “anything” hears all my dry runs, it’s my car seats! 😄

Why? Because I’m relaxed. Driving is a pleasure for me, and ideas just flow naturally during those moments. And actually, it’s a pretty good way to make the most of that time lost in traffic. Turns it productive.

Give it a try! Instead of setting aside a specific time to rehearse, try practising your talk in small chunks while doing something else.

Of course, this isn’t the only way — it works for me, but it might not for you. Thankfully, we’re all different, so find what suits you best!

Conclusion

If you’ve made it to this section, it likely means you’ve read the entire article — thank you for that! 😊 It also suggests you’re interested in stepping onto the stage and wondering how to get there.

As you’ve seen, achieving this goal involves taking small, consistent actions that build confidence over time, helping you become someone ready to take on the next challenge and stand confidently before an audience.

Embrace the process — that’s the most important part. Remember, sometimes the experiences that help you grow most aren’t directly related to public speaking, so stay open to all forms of growth along the way.

How about you? Do you have any tips or experiences to share? We’d love to hear them in the comments section!

Best,

Luis

Why ephemeral and immutable infrastructure are so important in Cloud Native environments

Luis Serra — Fri, 17 Feb 2023 17:40:42 +0000

In the cloud, we know exactly what we want a server to be, and if we want to change that we simply terminate it and launch a new server with a new AMI. This is enabled by a change in how you think about managing your resources in the cloud or a virtualised environment. Also it allows us to fail as early in the process as possible and by doing so mitigate the inherent risk in making changes.
Greg Orzell in “Building with Legos” a Netflix Tech Blog article

Introduction

For years, infrastructure management was based on various processes and routines that required manual intervention by engineers or technicians. While these practices were effective, the development landscape has undergone significant changes in recent years. The advent of agile methodologies, shorter development cycles, increased focus on time-to-market speed, distributed systems, and scaled environments have made it challenging for traditional infrastructure management to keep pace. Cloud transformation and the cloud-native trend were the ultimate push that evidenced a change need.

A new, more agile approach to infrastructure management was needed to respond to these challenges. Instead of treating infrastructure as unique, valuable “pets” that required significant time, effort, and resources to maintain, a more standardised, commoditised approach was needed. By viewing infrastructure as replaceable “cattle,” organisations can standardize their systems, reduce the risks associated with manual management, and ensure their infrastructure is equipped to meet the demands of modern development.

The pets vs cattle analogy were first used by Randy Bias to explain the difference between traditional and new approaches to server management.

In the old way of doing things, we treat our servers like pets, for example Bob the mail server. If Bob goes down, it’s all hands on deck. The CEO can’t get his email and it’s the end of the world. In the new way, servers are numbered, like cattle in a herd. For example, www001 to www100. When one server goes down, it’s taken out back, shot, and replaced on the line.

In this article, we delve into the challenges of utilising mutable and long-lived infrastructure and its effect on cloud-native transformations. We also explore the benefits of adopting an immutable and ephemeral infrastructure approach.

To provide practical insights, we will illustrate each topic with a real-world scenario from our experiences at xgeeks, demonstrating how utilising immutable and ephemeral infrastructure has aided one of our clients in achieving a cloud-native transformation.

Let’s get deep into the constraints of long-lived and mutable infrastructure

To understand the real benefits of immutable and ephemeral infrastructure, we need to get deep into the main challenges and constraints of a long-lived and mutable infrastructure in an agile development world:

An increase in operational complexity and consequently reduced reliability, the increase in distributed service architectures and dynamic scaling leads to a significant increase in maintenance and monitoring requirements, mainly due to changes in the runtime environment. Maintenance and configuration processes across multiple machines or servers are not compatible with flexible and continuously changing environments.
The previous point was a clear impact in the second, slower deployments. As infrastructure becomes unpredictable due to the multiple configurations and processes, the accuracy and consistency of information are diminished. This leads to a waste of time fixing configuration issues and debugging the runtime environment due to possible configuration drifts.
Next, there are also problems with the monitoring pain, imagine yourself searching for errors on a system running for a long time, with several processes running and several configuration changes over time.
And finally, there are fire drills or out-of-control events, like interventions, updates or patches that you don’t have full control of, a cloud provider reboot or a zone outage could be a good example. This will increase the costs with on-call teams, being notified to put your infrastructure up and running again.

n our client scenario at the beginning presented several challenges in implementing agile development processes. Despite initial efforts, the corporation has struggled to achieve desired results due to infrastructure issues.

Previously, the company was delivering their product every 3 months, allowing for manual correction of any configuration drift. However, with an increased push for more frequent product delivery, the simple task of managing four virtual machines where the backend and frontend were hosted became a significant challenge. Configuration drift caused by independently configured instances and later resource starvation resulting from missing log rotations causing database problems were just a few of the difficulties faced.

So, what is exactly immutable and ephemeral infrastructure?

To understand immutable infrastructure, first, we need to understand what immutable means. “Immutable” refers to something that cannot be changed, altered, or modified.

In the context of software development and infrastructure, “immutable” is used to describe systems, components, or resources that remain unchanged during their entire lifecycle. This means that once they are deployed, they cannot be updated or modified in any way. Instead, a new version of the system, component or resource must be created if changes are needed.

Now is the time to talk about ephemeral but first, let’s get deep into what the ephemeral term means. “Ephemeral” refers to something that is short-lived or temporary and does not persist for a long time.

In the context of infrastructure, the term “ephemeral infrastructure” refers to computing resources or components that are created dynamically and destroyed as needed, rather than being persistent and long-lived. This allows for greater flexibility, scalability, and ease of management in cloud-based or other dynamic computing environments.

As observed, both types of infrastructure differ in their design principles. While immutable infrastructure prioritizes stability through unchanging components, ephemeral infrastructure values flexibility through its ability to be easily replaced. By combining these two, an infrastructure is created that can quickly scale, deploy, and recover in response to changes in demand or conditions.

Coming back to our scenario, it became evident that those virtual machines needed to be transformed into immutable and ephemeral components. The persistence of these machines was hindering the client’s deployment process, so we needed to find a way to make these instances reproducible and externalize any non-reproducible elements.

What are the main advantages of using this type of infrastructure?

Now, let’s delve into the advantages of this method and why it helps organisations with their cloud-native transformation.

First, simplifying operations, once utilising automated deployment techniques allows for the substitution of outdated resources with updated versions, ensuring your systems remain in their original “known-good” state.
Second, there is continuous and faster deployment, and awareness of what is being run and its behaviour is maintained. Updating becomes a regular, ongoing process with fewer errors occurring during the production and all updates can be monitored through source control and CI/CD processes.
Next, we have mitigation of errors and increase reliability, new instances can be raised almost instantly and their lifecycle is now much shorter, this will reduce the risk of data loss or corruption, as well as the risk of configuration drifts, vulnerability surface, and the level of effort required to meet service level agreements. This helps organizations maintain a high level of reliability and stability, even as their workloads change and evolve over time.
Another advantage is preparation for fire drills or cloud-ready components. Once you know the desired state of each machine, operations like reboot, recovery and running can happen and you are much more confident when cloud reboots happen that your underlying instances should be handled gracefully and with minimal if any, application downtime.
The added benefit of improved scalability comes with the aforementioned advantage and this makes it easy to scale up or down as needed, without having to worry about the underlying hardware. This allows organisations to quickly respond to changing demands and to take advantage of new market opportunities.
And finally potential reduction of costs. Immutable infrastructure is ready to be dynamic which is very important when we are talking about provisioning infrastructure in a cloud provider. Another outcome in terms of reducing costs is a reduction in expenses related to the upkeep and upgrading of conventional, persistent servers.

Seems good so far, right? But now you are asking how did you implement it? Let’s get back into our scenario then. To begin with, we started to externalise the database instance to a Platform-as-a-Service (PaaS) solution to reduce the risk of downtime, which allows us to simplify operations and increase reliability. Then, we followed three steps to make these machines immutable resources: externalization of configurations, packaging, and provisioning. We transferred all configuration management responsibilities to tools such as Consul and Vault from HashiCorp to achieve service discovery, configuration management, health checks, and secure storage of sensitive data. We used Packer also from HashiCorp to create pre-configured virtual machine templates that can be quickly deployed to save time and reduce manual configuration errors. Finally, we established a deployment process for these machines using Terraform from HashiCorp, a leading Infrastructure as Code tool for provisioning.

After all these steps, the cloud was only one command away, since we were able to create reproducible infrastructure, which happened some months after, along with containerisation and so much more.

Immutable and ephemeral infrastructure can be found in all sizes and forms

So far we have repeatedly mentioned the terms infrastructure, machines and servers, but what can be turned into immutable and ephemeral infrastructure? Nearly everything can be, but let’s delve deeper.

Virtualization was the catalyst for the growth of immutable and ephemeral infrastructure. It was easy to create new servers, firewalls, etc. on a hypervisor, and if something went wrong, a new machine could be brought online with just a few clicks.

However, virtual machines became cumbersome due to their heavy weight and numerous layers of management, including the kernel, operating system, packages and dependencies, applications, and more. To address these issues, newer concepts such as containerization emerged, resulting in smaller, lighter, and simpler components for our infrastructure.

With the advent of tools such as Kubernetes, Apache Mesos, Nomad, OpenShift, and others, the concept of immutable and ephemeral infrastructure gained a new perspective. Not only can our servers be transformed into immutable and ephemeral components, but our services and applications can also be made easily replaceable.

Finally, cloud providers delivered the finishing touch to the world of immutable infrastructure. With the ability to provision infrastructure through simple API requests, nearly everything can be turned into immutable. Resources such as servers, firewalls, load balancers, applications, functions and more can now be set up quickly, efficiently, and most importantly, automatically, allowing us to keep pace with our company’s evolving requirements and demands.

To finalize our scenario follow-up, currently, our client has all kinds of sizes and forms of immutable infrastructure resources running in his company. After the cloud transformation, business increased, and with containerization already in place, Kubernetes implementation was just around the corner. At the moment, we have pods running our client applications, virtual machines for specific workloads and even serverless functions to automate some processes. The main key behind all these changes and implementations is an immutable and ephemeral infrastructure which gave our client the opportunity to follow the market with flexibility, speed, stability and reduced costs.

What do we use Gitlab schedule pipelines for?

Luis Serra — Fri, 03 Feb 2023 10:59:25 +0000

How schedule pipelines help us implement processes

Introduction

In software development, and especially in the DevOps area, there is a common need not only to automate processes but also to trigger their execution repeatedly.

However, controlling the execution of these repetitive processes raises several questions, such as:

what is the right tool to perform this control?
where can this tool be hosted? On-premises?
if we use a company device, how do we ensure that it is always operational?
if we set up this tool in the cloud, what are the costs of operating and maintaining it?
what types of flows/work can it control?
how can we easily obtain outputs about the success or failure of the various executions?
among others…

One of the most common tools used in software development is a version control system. Here we have several options, such as GitHub, Bitbucket, Gitea, etc., but it’s in GitLab that we find a very interesting feature, the Schedule Pipelines.

These, as the name indicates and according to the documentation run pipelines in the future, repeatedly, for specific branches or tags, that are disputed in regular time intervals.

With these characteristics, several of the previous questions can be answered, since it already has a graphic interface, easy to consult, even by non-technical people, it can be run remotely or on-premise, it’s a feature included on a free tier and since we are talking about fully configurable pipelines, the type of flows/work they control is easy to implement.

Regarding outputs, besides the dashboard with the status of the last iteration, we also have several integrations with communication platforms such as Slack, or if you need something more customized, again there is no problem because we can create jobs to run custom notifications.

In this article, I will present to you some scenarios where Schedule Pipelines were useful and how you can set up your own pipelines.

Which workflows did we automate?

1. Database Sync

In the software development process, it’s common for there to be different development environments (development, staging, production, etc.) to which there is a similar element, data. This data will populate the applications so that programmers, QA engineers, designers, etc., can test one or many applications in a way closer to production, however, it is not always easy to have similar data in all these environments.

This issue was the first where we used the Schedule Pipelines of GitLab to help us, sync databases between the various environments. Using two scripts written in bash, we defined a process to perform a dump from production, sanitize it and restore this data to each development process environment on a weekly bases.

2. Cleaning the Container Registry

One of the cost problems we encountered was the increase in the size of a company’s container registry. Frequently, these solutions have configurations to automatically delete the oldest images, however, this configuration in Azure is only available for the most expensive SKU tier, which would increase the costs of this registry. After a search, Azure itself provides a script written in bash to delete tags older than a certain date, so after some adjustments to it, it was easy to create a flow to purge the older images from the container registry, this time on a monthly bases.

3. Container Security Check

All our docker base images of our projects are hosted in our internal container registry, however, these are based on other well known public images (node, java, python, etc.), plus some base tools and software. This approach has some advantages like creating custom base images with cross-platform software already installed, but there are always new vulnerabilities so it’s good to have some kind of vulnerability check happening once in a while to check if there are no new security breaches with the pre-installed software. To achieve this, using trivy we created a job to check our base docker images every week, looking for new vulnerabilities.

4. Rebuild Base Docker Images

Following the problem before, it’s good to once in a while recreate our docker base images, to update the latest packages that we could have been installing, so to achieve that we set up a scheduled pipeline to perform a docker build command to rebuild those images.

5. Lokalise translations synchronization

To handle our application internationalization, we use Lokalise as a collaborative translation software platform, however, we need to sync the translators’ work with our local files, to do so we have implemented a scheduled pipeline to, twice a week, download the translations from Lokalize platform and check if there is any change between the new and the old translations. If there is any, then a new merge request will be created with those diffs.

How can I use schedule pipelines then?

Using their UI is pretty simple to set up a new pipeline. On your project just go to CI/CD > Schedules > New Schedule and where you can configure everything.

What are the cool features of this? Ok, let me enumerate them so:

cron syntax that you can find on other systems, pretty standard
target branch or tag, so you can have several behaviours using different branches
variables to configure and enrich your pipelines
easy on/off feature using the active toggle

How can I configure a job to be executed only on schedule pipelines?

Using the rules keyword, you can use the predefined CI/CD variable CI_PIPELINE_SOURCE, which has the value schedule when a scheduled pipeline is triggered.

rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"

But that approach will trigger all jobs with CI_PIPELINE_SOURCE variable rule set to schedule, am I right? So, show me the magic…

How can I select only some of them using the same ci file at the same branch?

Is that possible? And the answer is yes, with something that I talked about before, variables. Using schedule pipeline variables you can create a new var that will control which job will be executed. Below you can find a little example of this approach, where you can find two jobs at the same GitLab-ci file, at the same branch as well, but using setting up a variable OPERATION on each configuration.

...
container_scanning:
  stage: scanning
  ...
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule" && $OPERATION == "scan"'
....
delete-old-images:
  stage: acr-clean
  ...
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule" && $OPERATION == "acr-clean"'

This was a short introduction to the schedule pipelines feature from Gitlab CI, and how we use them on a daily basis. I hope that those examples gave you a better understanding of which processes or flows you can automate easily in your organization. If you already use this feature, please share your use cases in the comments section 😉.

If you enjoy working on large-scale projects with global impact and if you like a real challenge, feel free to reach out to us at xgeeks! We are growing our team and you might be the next one to join this group of talented people 😉

Check out our social media channels if you want to get a sneak peek of life at xgeeks! See you soon!

Azure Private DNS on-premises

Luis Serra — Fri, 03 Feb 2023 10:47:58 +0000

Using Azure Private DNS to give access to private resources

Azure Private DNS is a service that gives you an easy and secure solution to register your private DNS records for all your infrastructure elements inside Azure. But how does Azure Private DNS work? First, you need to create your private DNS zone and link it within a Virtual Network. The private DNS zone is a resource where you will place the records and link to a Virtual Network.

You can find all the information about the benefits, capacities, prices, and so on here, on the Azure Documentation web page.

But what to do if giving domain resolution only for your cloud services is not enough? Most of the time, not all your network components, like servers or employees’ computers are on the cloud network scope, being on-premise or at your employee’s home. So what to do if these elements need access to those DNS records as well?.

In this article, we will explain a simple solution to achieve that.

1. Let’s set a VPN

To give those elements access to your Azure Private DNS solution, we had to ensure that they have access to the Azure network somehow. To do that, let’s start to set up a VPN solution, using a virtual machine with a Unix-based operating system installed. To easily install an OpenVPN Server, we suggest angristan OpenVPN installer that you can find here and counts with more than 9.4k stars.

2. Configure your VPN

Now that we have a working VPN solution, there are some configurations that you need to do, to ensure that your clients can use your Azure Private DNS on-premises. These configurations are to:

users are using your DNS when they are connected to the VPN
DNS requests are forwarded from your VPN machine to the private DNS
On macOS and Windows clients it’s only needed to add the following line to your VPN server config:

push “dhcp-option DNS <internal-vpn-server-ip>”

On Linux clients, apart from the configuration above, make sure to add the next three lines on the client VPN file, because resolve.conf will be edited, and a refresh must be done.

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

3. Add a DNS forwarder

With those changes, the first two phases are done, so let’s continue to the next one. As mentioned on Azure docs), to use this DNS service on-premises, we have to somehow forward our on-premises machine's DNS requests that are arriving at the VPN server to the Azure Private DNS. To do that, we implemented a DNS server (bind9) that is working only to cache and forward DNS requests.

acl vpn {
    <vpn-network>/24;
};
options {
    directory "/var/cache/bind";
    listen-on port 53 { <vpn-interface-ipv4>; };
    listen-on-v6 { <vpn-interface-ipv6>; };
    forwarders { 168.63.129.16; };
    forward only;
    recursion yes;

    allow-query { vpn; };
    dnssec-enable yes;
    dnssec-validation yes;
    auth-nxdomain no;    # conform to RFC1035
};

As you can see, there are several configurations that you need to do on the bind9 service. First, for security reasons, we created an ACL, called VPN with our VPN network to have better control over who can access the name server. Next, let’s enable bind9 service only on the VPN interface. This way, we implemented another layer of security, because port 53 will be listening only on that interface. If you are using IPv6, make sure that you include it too.

As our forwarders, we set 168.63.129.16, a virtual public IP address that is used to facilitate a communication channel to Azure platform resources. With that forwarder, and with a virtual network link between our VPN machine virtual network and our Private DNS Zone (image below), we are ensuring that DNS requests are being made to our private DNS too.

Last but not least, let’s use our ACL created previously, on the allow-query section to ensure that only requests from our VPN network are accepted.

And it’s done, now you are able to resolve your private domains on-premise!

This article was co-written by Luís Serra and João Sousa, from the xgeeks team.

Check out our social media channels if you want to get a sneak peek of life at xgeeks! See you soon!