DEV Community: Luciano Bastet

🚀 Scaling GitOps on EKS with Helm + FluxCD: Lessons from the Field

Luciano Bastet — Mon, 14 Jul 2025 17:59:55 +0000

Some time ago, I led the design and implementation of a GitOps model for Kubernetes deployments using Helm and FluxCD, tailored for Amazon EKS. We built a multi-repo, multi-environment structure to support a fast-growing platform with dozens of microservices.

🔍 What challenges did we face?

Manual, inconsistent deployments across environments
CI/CD pipelines not integrated with Kubernetes state
Limited scalability for new teams and services
Slow feedback loop for developers

🛠 Our solution?
We combined Helm (for reusable, templated manifests) with FluxCD (for Git-driven, continuous delivery). CI pipelines update image tags and trigger Helm chart updates, while FluxCD takes care of the sync and rollout.

🏗 Key design principles:

Multi-repo structure per environment and service
Developer ownership via Git workflows
Full rollback and audit trail through Git
Onboarding process defined and reproducible

📉 Impact:
🔄 60% reduction in deployment cycle time
🧪 Reproducible environments from Git
🔐 Improved compliance and traceability
💪 Empowered dev teams, simplified ops

💡 What I’d do differently next time:

Gradual adoption with sandbox environments
Assign GitOps champions per squad
Invest earlier in visual dashboards
Automate more of the Helm chart templating

GitOps WORKS — when it's done with purpose, clarity, and strong team support.

If you're thinking about scaling GitOps in your org, happy to share insights!

AWS Security Specialty - I failed (721), Then I passed! (810)

Luciano Bastet — Tue, 20 Aug 2024 13:38:39 +0000

It is a very challenging certification. At first I prepared it in 3 weeks and went to take it... I was very close since I failed because of one question (721). We learn from mistakes and successes emerge from failures. I reviewed the notes again, took new notes, review the mistakes from the mock exams results (TD), watched some lessons again, looked for answers to questions that left me thinking more than expected in the first attempt.

As I could see the question bank is very large because in my second round no questions appeared like in the first exam. In both exams, the questions are a little more complicated or more difficult than those from Tutorial Dojo.

The secret to pass;

It is essential to have good reading comprehension in English and have knowledge of each of the services to be able to pass this exam.

1- Read thoroughly and understand the fundamental requirements of the questions. Be attentive to connectors and the service they are asking you about (some times they include many services but then only ask about one).

2- When the scenario is complex, use the WHITEBOARD (I know it is very uncomfortable sometimes, but it works)

3- When you are between two possible answers, or the scenarios are too large, mark one answer and leave that question with a flag to carefully check later that the one you chose is the correct one.

Courses to prepare the exam:

Udemy: Stephane Mareek for sure! (I also printed the slides and studied from there too)
Exam test practice: Tutorial Dojo
Exam Topics: There are like 173 questions, answers and discussion about what are the responses per question.
AWS Skill Builder (If you get above 80% you are probably good to go)

Topics to handle for the exam:
Aws signer & Lambda
Forensic analysis for ec2
Access analyzer Vs credential report
EBS snapshot security & lifecycle, s3 lifecycle rules
Compromised EC2 instance, EBS snapshots. NACLs, SG
Alb vs NLB, performance & certificate configurations, encryption end-to-end
EC2 auto-scaling, EBS encryption with kms, permissions
Organizations, SCP, IAM, Control Tower and Service Catalog
CloudFormation stack sets
Cognito, Identity Center
IAM policies, resource policies, key policies. NotAction, NotResource
Organizational trails
ECS and task role permissions
S3 object lock
Cross-account access
CloudFront security
Scenarios with NGW, Internet Gateway, SG, NACL
Direct Connect, VPN
VPC endpoints
WAF & Shield
Inspector, GuardDuty, Systems Manager
KMS, Customer Managed Keys
KMS rotation
VPC Flow Logs

Hope this information is useful for you. Good Luck on your exam!

PRE-SALES Team

Luciano Bastet — Wed, 31 Jul 2024 17:14:26 +0000

Large software / consulting companies need a multidisciplinary pre-sales team where each role is very important and key; whether from the point of view of interviewing, obtaining requirements, being attentive to opportunities that may arise, having a vision of the future, being able to demonstrate professional technical and sales capacity, having human capital and skill in the presentation of numbers and conveniences of partnerships. The objective is to achieve a win-win on both sides. Aspire to a long lasting relationship as partners that complement each other with a common objective; thrive.
A Pre sales team is normally composed of: Client Partner, Solution Owner, Architect and Contributors (names and profiles could varied between companies and the sale nature; Business Analyst, Product Expert, Industry Leader, etc). These roles work together to ensure that a client's needs are understood, a suitable solution is designed, and the solution will resolved the need. In the context of AWS, this involves leveraging a wide range of AWS services, mastering architecting and AWS partnerships program that will give the deal a booster efficiently impacting issues of costs, credits, work frameworks that accelerate processes in order to efficiently meet an objective. In this pre-sale stage it is important to demonstrate capacity and professionalism.

**The team:

Solution Owner**

Define the overall vision and strategy for the solution.
Gather and prioritize requirements from stakeholders.
Oversee the solution design and ensure it aligns with client needs and business goals.
Coordinate with development teams to ensure the solution is built as planned.
Ensure the solution is delivered on time and within budget.

** Client Partner**

Act as the main point of contact between the company and the client.
Develop and maintain strong relationships with key client stakeholders.
Understand the client's business objectives and technological needs.
Identify opportunities for upselling or cross-selling additional services.
Oversee the delivery of services to ensure client satisfaction.

*Architect: *

Design the technical architecture of the proposed solution.
Choose appropriate technologies and AWS services to meet client requirements.
Ensure the solution is scalable, secure, and cost-effective.
Provide technical guidance and leadership to the development team.
Create detailed architecture documentation and diagrams.

The Importance of Collaboration and Continuous Learning

It's crucial for the pre-sales team to foster a culture of collaboration and continuous learning. Given the rapid evolution of technology, especially in the cloud computing domain, staying updated with the latest AWS services, best practices, and industry trends is vital. Regular training sessions, workshops, and certifications can empower the team to stay ahead of the curve.

*Leveraging AWS Resources
*
AWS provides a wealth of resources, such as the AWS Well-Architected Framework, AWS Training and Certification programs, and various partner tools, which can significantly enhance the team's efficiency and effectiveness. Utilizing these resources can help ensure that the proposed solutions are not only innovative but also adhere to AWS best practices, thereby adding value to the client engagement.

Customer-Centric Approach

Ultimately, the success of a pre-sales team hinges on its ability to maintain a customer-centric approach. This involves not only addressing the immediate technical and business needs of the client but also anticipating future challenges and opportunities. By building strong, trust-based relationships and demonstrating a deep understanding of the client's industry and goals, the pre-sales team can position itself as a strategic partner, driving long-term success for both parties.

Conclusion

A multidisciplinary pre-sales team is indispensable for large software and consulting companies aiming to secure and sustain successful client relationships. By combining roles such as Client Partner, Solution Owner, and Architect, these teams ensure a comprehensive approach to understanding client needs, designing appropriate solutions, and delivering results. Leveraging AWS services and partnership programs enhances their capability to provide scalable, secure, and cost-effective solutions. This collaborative effort not only meets immediate business goals but also lays the foundation for long-term, synergistic partnerships that drive mutual growth and success.

AWS BLACKBELT PROGRAM

Luciano Bastet — Mon, 22 Jul 2024 14:10:11 +0000

WHAT IS?
The purpose of the blackbelt is to address various topics in greater technical depth such as: AI/ML, Gen-AI, Compute, Containers, Serverless, migration, security, observability, among others. The course modality is virtual, 5 hours per day, from Monday to Friday (2 or 3 breaks no more than 15 minutes).

FOR WHOM?
The AWS Blackbelt program is available for AWS partners. Those who can access these programs must have at least associate level certifications and be current at the time of the date on which the program will be taught.

COMPLETION REQUIEREMENTS?
Starting in 2024, they began to give attendance certificates to those who met the requested requirements; attendance of 80%, participate in the CSAT at the end of each day and sometimes they may ask for the completion of laboratories and an activity that can be a group activity to present on the final day or develop an idea or use case with what has been seen in those days.

MY EXPERIENCE
It is a very rich experience. Apart from learning certain services in more depth, you can meet other expert professionals who develop AWS technologies from the inside. Added to that, receiving a certificate and all the material taught (It cannot be shared since is under a confidentiality contract). It is also a good time to ask questions that have to do with a business need!!! Enjoy the next BlackBelt

Improving the operating model of service deployments in AWS EKS

Luciano Bastet — Mon, 22 Jul 2024 14:07:51 +0000

Deploying Applications on Amazon EKS with Essential Plugins

Deploying applications on Amazon Elastic Kubernetes Service (EKS) involves setting up several essential plugins to ensure smooth operation and integration with AWS services. This guide covers key plugins you need to activate and configure, including those that can be activated directly from the AWS console, as well as those requiring manual setup like the ALB Ingress Controller and External DNS. Combined, they automate the mapping of the creation of a new load balancer with the existence DNS record, improving the operating model of the platform.

In this article, we assume that the cluster is up and running, and the kubeconfig is configured on your terminal and you can interact with the cluster.

Plugins Activated from the AWS Console

AWS EKS allows you to activate several essential plugins directly from the console:

Amazon VPC CNI: This plugin is installed by default and can be updated from the console.
kube-proxy: This plugin is responsible for network routing within the cluster and can be managed via the AWS console.
CoreDNS: CoreDNS handles service discovery and DNS resolution within the cluster and can also be managed from the console.

To ensure these plugins are up-to-date and correctly configured, navigate to the "Add-ons" section of your EKS cluster in the AWS Management Console and check the status of each.

Setting Up the ALB Ingress Controller and External DNS

1. Setting Up the ALB Ingress Controller

The AWS Load Balancer (ALB) Ingress Controller manages Kubernetes ingress resources and provides load balancing. Here’s how to set it up manually:

Create IAM Policy for the Controller:

curl -o alb-ingress-controller-iam-policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/main/docs/install/iam_policy.json

aws iam create-policy \
  --policy-name ALBIngressControllerIAMPolicy \
  --policy-document file://alb-ingress-controller-iam-policy.json

Associate IAM Role with EKS Service Account:

eksctl create iamserviceaccount \
  --cluster <your-cluster-name> \
  --namespace kube-system \
  --name alb-ingress-controller \
  --attach-policy-arn arn:aws:iam::<account-id>:policy/ALBIngressControllerIAMPolicy \
  --approve

Deploy the ALB Ingress Controller:

kubectl apply -k github.com/aws/eks-charts/stable/aws-load-balancer-controller//crds?ref=master

helm repo add eks https://aws.github.io/eks-charts

helm repo update

helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=<your-cluster-name>

2. Deploying External DNS

To automatically update Route 53 records when services are deployed, set up External DNS:

Create IAM Policy for External DNS:

curl -o external-dns-policy.json https://raw.githubusercontent.com/kubernetes-sigs/external-dns/master/docs/tutorials/aws.md

aws iam create-policy \
  --policy-name ExternalDNSPolicy \
  --policy-document file://external-dns-policy.json

Deploy External DNS with Helm:

helm repo add bitnami https://charts.bitnami.com/bitnami

helm repo update

helm install external-dns bitnami/external-dns --set provider=aws --set aws.zoneType=public --set policy=sync --set txtOwnerId=external-dns

Configure External DNS for Route 53:
Ensure your services have the correct annotations:

apiVersion: v1
kind: Service
metadata:
  annotations:
    external-dns.alpha.kubernetes.io/hostname: myservice.example.com
spec:
  ports:
    - port: 80
  selector:
    app: myservice

Editing External DNS Deployment:
After deploying External DNS, you need to add a domain filter in the External DNS deployment manifest matching the DNS record:
```
kubectl edit deployment external-dns -n kube-system
```

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: external-dns
  namespace: external-dns
spec:
  selector:
    matchLabels:
      app: external-dns
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: external-dns
    spec:
      containers:
      - args:
        - --source=service
        - --source=ingress
        - --domain-filter=example.com
        - --provider=aws
        - --policy=upsert-only
        - --aws-zone-type=public
        - --registry=txt
        - --txt-owner-id=my-hostedzone-identifier
        image: registry.k8s.io/external-dns/external-dns:v0.13.4
        imagePullPolicy: IfNotPresent
        name: external-dns
```

This setup ensures that any subdomain of example.com will route to your ALB, allowing for dynamic service discovery and load balancing.

Conclusion

By activating essential plugins from the AWS console and manually setting up the ALB Ingress Controller and External DNS, your EKS cluster will be well-equipped to handle dynamic workloads with seamless integration into AWS services. These steps ensure your cluster is robust, scalable, and easy to manage, allowing you to focus on building and deploying your applications.