A hands-on guide to ECS Managed Daemons, AWS's answer to Kubernetes DaemonSets, with step-by-step setup for running agents like CloudWatch on ECS.

ECS Managed Daemons:

Every DevOps engineer who is working with ECS and managing monitoring for services knows how hard it can be. You have more than 30 services. A new version of the CloudWatch Agent is released. To update services, you're coordinating with five application teams, creating 30 new task definition revisions, and triggering 30 rolling deployments - just to bump an agent version. One mistake and you have a gap in your monitoring. \
 \
[Kubernetes](https://kubernetes.io/ ) had a clean answer to this problem for years: the DaemonSet. One resource, one agent per node, managed independently of applications. Now, ECS is catching up, also. \
 \
[AWS announced ECS Managed Daemons in April this year](https://aws.amazon.com/blogs/aws/announcing-managed-daemon-support-for-amazon-ecs-managed-instances/). This is a native construct that decouples operational agents from application task definitions. In this post, I'll walk you through what it is, how it works, and how to set it up using the AWS Console.

**In short:** 

ECS Managed Daemons are a native AWS construct that decouples operational agents - like the CloudWatch Agent - from your application task definitions, much like a Kubernetes DaemonSet. 

Instead of bundling a monitoring sidecar into every service and redeploying dozens of services just to bump an agent version, you define the daemon once at the cluster level and ECS guarantees exactly one agent per instance - started before your apps and drained last, so monitoring never has a gap. 

Platform teams can update agents independently of application teams, with automatic start-before-stop rollouts and circuit-breaker rollback. The one catch: Managed Daemons work only with ECS Managed Instances capacity providers - not the classic EC2 launch type or Fargate. 

This post covers what they are, how they work, and how to set one up from the AWS Console.

## The Problem with the Sidecar Pattern

Before Managed Daemons, the standard way to run a monitoring agent for your application on [ECS](https://aws.amazon.com/ecs/) was the sidecar pattern: add an agent container directly inside your task definition. This is a problem for more than one reason:

* **Tight coupling:** If I want to update a new version of the monitoring agent, I need to update the task definition, which will create a new revision, and I need to redeploy the whole service, which includes the application container
* **Resource waste:** Every task runs a side container for monitoring. If you have 30 tasks, you will have 30 monitoring containers running.
* **Inconsistency risk:** Teams can accidentally omit the sidecar, leaving some services unmonitored without anyone noticing.

## What Are ECS Managed Daemons?

ECS Managed Daemons are a dedicated service for operational agents that is completely separate from your application task definitions. You define it once at the cluster level, and you are assured that it will execute for every service.

Key benefits:

* **One daemon per instance:** ECS creates exactly one daemon task per managed instance
* **Start before applications:** The daemon is guaranteed to be running before any application task is placed on that instance.
* **Drain last:** When an instance is being replaced or drained, the daemon is the last thing to stop, ensuring no gap in observability coverage.
* **Independent lifecycle:** Platform teams can update the daemon without touching application task definitions or coordinating with application teams.

One thing to keep in mind before you get excited: Managed Daemons only work with ECS Managed Instances capacity providers. Classic EC2 launch type and Fargate are not supported. 
 
## Step-by-Step: Setting Up a Managed Daemon via the Console

Before getting started, we need to create:

* An ECS cluster with a Managed Instances capacity provider configured
* An IAM task execution role
* The container image you want to run as a daemon (we'll use the CloudWatch Agent) 
* Created log group /ecs/cloudwatch-agent-daemon

### Step 1: Create a Daemon Task Definition

![slika 1png.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/slika_1png_9590d0fe26.png)

Configure the following:

* **Daemon task definition family:** Give it a name, like cloudwatch-agent-daemon
* **Task execution role:** Select ecsTaskExecutionRole
* **Create a CloudWatch Agent Task Role:** Create a new IAM Task role, with name **CloudWatchAgentTaskRole,** and attach** CloudWatchAgentServerPolicy** AWS managed policy
* **CPU:** 1 vCPU
* **Memory:** 512 MB

Under Container, add your agent container:

* **Name:** cloudwatch-agent
* **Image URI:** public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest
* Set configuration for CW Agent; create one env variable:


```
key: CW_CONFIG_CONTENT
value: {\"metrics\":{\"metrics_collected\":{\"cpu\":{\"measurement\":[\"cpu_usage_idle\"],\"metrics_collection_interval\":60}}},\"logs\":{\"metrics_collected\":{\"emf\":{}}}}
```
![slika 2.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/slika_2_bc9df2d3f8.png)

### Step 2: Create the Daemon on Your Cluster

Go to Clusters tab → Select your cluster → Open Daemons tab
![slika 3.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/slika_3_5fed36817f.png)

Click Create daemon and configure:
* **Daemon name:** e.g., monitoring-agent
* **Daemon task definition:** Select the family you just created
* **Capacity provider:** Select your Managed Instances capacity provider
* **Drain percentage:** Controls the pace of rolling replacements during updates (50% means at most half your instances can be in the drain state simultaneously)

![Slika 4.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Slika_4_ae8141d024.png)

### Step 3: Verify the Daemon is Running

Create a testing service which will be monitored (e.g., nginx, hello world).

You'll observe that the daemon was already running before the application task was placed - no manual intervention required.
![Slika 5.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Slika_5_32c06917b4.png)

Before the nginx service deployment, there was no instance of the cloudwatch-agent daemon, but when the deployment of the service started, the cloudwatch agent deployed one task first, and then the deployment of the service continued.

## How Updates Work

In this part, I will explain the main advantage of daemons over the sidecar pattern. When you need to update the agent to a new version, ECS handles the rollout automatically using a "start before stop" strategy.

The old daemon on the outgoing instance stays alive until all application tasks have successfully migrated to a new instance running the updated daemon. Service will have one available agent in every moment, there is no gap in monitoring or logs shipping.

ECS also includes automatic rollback via circuit breaker. If the new daemon fails health checks during a rollout, ECS stops the replacement and rolls back, protecting your services.

## When to Use Managed Daemons?

Managed Daemons are a great fit for any agent that needs to run on every instance, independently of which applications are deployed. 

When NOT to use Managed Daemons:

* Application-specific sidecars that only make sense alongside a specific service
* Init containers or one-time setup tasks

## Conclusion

My recommendation is to use Managed Daemons every time there is a need for a sidecar agent. One of the biggest wins for me is that I can work separately on updating or creating agents without clashing with developers' work and progress. And there's another thing worth mentioning - no more gaps in monitoring.

The only problem I have currently is that on some projects, we are not using managed instances for ECS, and there are no plans in the future for using them, so we are limited to going the old way. 

If you're currently running monitoring agents as sidecars on ECS Managed Instances, this feature is worth evaluating immediately. The migration path is straightforward - extract the agent container from your task definitions, create a daemon task definition, and let ECS manage the rest.

Found this useful? [Check out our other blog posts for more insights on cloud architecture](https://www.cyberlab.rs/blog ).

## Resources
* [AWS Blog: Announcing managed daemon support for Amazon ECS Managed Instances](https://aws.amazon.com/blogs/aws/announcing-managed-daemon-support-for-amazon-ecs-managed-instances/)
* [Amazon ECS Managed Daemons Documentation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-daemons.html)
* [Amazon ECS Managed Instances product page](https://aws.amazon.com/ecs/managed-instances/)
* [CloudWatch Agent on ECR Public Gallery](https://gallery.ecr.aws/cloudwatch-agent/cloudwatch-agent)

The DaemonSet Equivalent ECS Was Always Missing

For the third year in a row, CYBERLAB joined the KTJ Club Business Challenge running 1,237 km to support a child in need of ongoing medical treatment.

Running for Neda: 

For the **third year in a row,** the [CYBERLAB](https://www.cyberlab.rs/meet-the-team) team joined the [KTJ Club](https://www.linkedin.com/company/ktj-club/posts/?feedView=all) Business Challenge. A month-long initiative where companies across Serbia convert their employees' kilometers into donations for children in need. This May, our team ran **1,237 kilometers** and raised **100.000 RSD** to support the ongoing medical treatment of a little girl named [Neda Ranđelović](https://pokrenizivot.com/cir/korisnik/neda-randjelovic-239). Here's what that month actually looked like from the inside.
## Our Why - Neda Ranđelović 
Neda was born after a healthy, regularly monitored pregnancy. However, complications during delivery later resulted in a diagnosis of cerebral palsy.

When we heard about Neda’s story, we were deeply moved by her strength and the dedication of her family. During the first year of the challenge, we decided to direct our fundraising efforts toward helping Neda. By the end of that month, we had built a genuine connection with her and her family, who, in turn, supported and cheered us on throughout the entire challenge. Seeing how much the treatment had helped her progress made us proud to have played even a small part in her recovery.

Earlier this year, when we heard that Neda needed a new cycle of therapy, the answer was simple: we wanted to help again.

![2.jpg](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/2_7572d98eff.jpg)
## About the KTJ Club Business Challenge
The **KTJ Club Business Challenge** founded in April 2024, a simple idea by KTJ Club: turn everyday kilometers into meaningful support for children in need. From the start, six companies joined the initiative, and **CYBERLAB was among them**. Back then, 190 colleagues took part. This year, that number grew to 26 companies with more than 1,000 participants.

The concept was designed from the ground up for everyday runners, not just seasoned athletes. Teams of up to 25 colleagues form a running squad; companies could register more than one, and convert their kilometers into donations for a child or children's institution of their choice. Every kilometer counts, every step carries a meaning beyond the finish line.
## How a Shared Purpose Brought Our Team Closer
On paper, the challenge was simple: run, log kilometers on Strava, repeat. In practice, it quietly rewires how a team operates for an entire month.
For those joining the challenge for the first time, the motivation came naturally from the team itself. There was always someone in the group chat sending an invite for a run, and **when you run with others, you inevitably push past what you thought you could do**. A kilometer or two more than planned, a limit quietly crossed. 

**The company played its part too** by providing our runners with proteins and healthy food throughout May, giving the whole initiative an extra push.

And then there was **Bojan Čakar**, **our colleague and unofficial captain, who kept the team's energy up throughout the month with protein pancakes and shakes**. By the end of May, that same energy carried a part of the team all the way to Fruška Trail, 15 kilometers through Fruška Gora, a serious challenge by any standard, and proof that what started as a charity run had become something the team genuinely wanted to push further.

Without overthinking it, that's how 1,237 kilometers happened logged across two countries, with teammates running in Novi Sad, Belgrade, Bijeljina, and Banja Luka.
![KTJ Kraj izazova 2026 (1).jpg](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/KTJ_Kraj_izazova_2026_1_bcc68383e4.jpg)
## More than a finish line
By the end of May, we were all in better shape than when we started, and not just physically. We pushed past our own limits, ran through rain without thinking twice, and finished the challenge as a tighter, closer team.

As individuals, we grew. As a collective, we bonded. And as part of a wider community, we made a contribution that we hope made a difference.
When it comes to helping others, no gesture is too small. Every kilometer, every donation, every share matters. If you'd like to add your voice to this story and support Neda's ongoing treatment, you can do so right now by sending an SMS with the text **239** to **3800**.

As for us,  we had a great time, and this is far from the only initiative we're part of. If you'd like a peek into our team culture and what we're up to, we'd love to have you follow along. Stay connected with us on [LinkedIn](https://www.linkedin.com/company/69988472/admin/notifications/all/), [Instagram](https://www.instagram.com/wearecyberlab/), and [Facebook](https://www.facebook.com/cyberlabsolutions/).




The Story Behind CYBERLAB's 1,237km

The “Claude Code 101” event in Novi Sad showcased practical AI-assisted development with Claude Code, led by Uroš Petrić from CYBERLAB.

How AI Is Changing the Way We Write Code:

On Tuesday, **April 21st, 2026,** we hosted an event at [Prostor](https://www.facebook.com/prostorgradic/?locale=sr_RS) in Novi Sad titled **“Claude Code 101: From Zero to Full Potential.”** Interest in the event was exceptionally high, with 100 attendees joining us, including software engineers, frontend and backend developers, students, and IT enthusiasts.

The venue was at full capacity, reflecting how quickly AI-assisted development tools have evolved from a curiosity into an essential part of everyday work in modern software teams.

## Speaker: Uroš Petrić - Software Engineer with Hands-On AI Development Experience

The session was delivered by our colleague [Uroš Petrić](https://www.linkedin.com/in/urospetric/), [Software Engineer](https://www.cyberlab.rs/meet-the-team) at [CYBERLAB](https://www.cyberlab.rs/), who brings extensive experience in application development and the practical use of AI tools in everyday engineering work. Within [CYBERLAB](https://www.cyberlab.rs/), Uroš successfully led the development of an internal application from idea to production in just a few weeks, with AI assistance playing a key role throughout the entire process. He regularly shares his knowledge and experience with colleagues through internal knowledge-sharing sessions.

![Software Engineer at CYBERLAB Leading hands-on AI-assisted development with Claude Code](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/1_2_3ca0a3f73f.png)

In this session, he demonstrated what a real-world AI-assisted development workflow looks like in practice, and how tools like [Claude Code](https://claude.ai/) can become a natural extension of a developer’s daily toolkit.

## What Does AI-Assisted Development Look Like in Practice?

Uroš walked participants through the complete picture of working with [Claude Code](https://claude.ai/), from understanding what a coding assistant actually is, to configuring advanced automation, parallel agents, and external integrations. The presentation covered the following core topics:

#### 1. Coding Assistant - Beyond the Chat Interface

The audience learned how [Claude Code](https://claude.ai/) differs from a simple chat interface and how it bridges the developer and the language model through a structured tool layer. **A key insight:** the language model does not execute actions itself; it requests the coding assistant to perform them, which means the developer retains full control over what happens in their codebase.

#### 2. Tools - What Claude Code Can Do

Uroš walked through the full set of built-in tools available to [Claude Code](https://claude.ai/), including Bash, Edit, Glob, Grep, Read, Write, WebFetch, WebSearch, and the Agent tool for launching subagents. Participants gained an understanding of how Claude decides which tool to use and how additional capabilities can be added through MCP server integrations.

#### 3. Context - Giving Claude What It Needs

One of the most practical segments of the talk focused on context management. Providing the right information and avoiding irrelevant or misleading context directly determines the quality of Claude's output. Uroš explained how context windows work, why they fill up, and how to manage them effectively during long sessions.

![PROSTOR I Novi Sad I CYBERLAB](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Uros_Petric_Claude_Code_101_From_Zero_to_Full_Potential_e4b707dfb4.jpg)
#### 4. CLAUDE.md and Auto Memory

The session covered CLAUDE.md, the single most impactful configuration file in any [Claude Code](https://claude.ai/) project. Loaded automatically at the start of every session, it acts as Claude's persistent memory,  documenting the tech stack, architecture, build commands, workflows, and project-specific gotchas. Alongside CLAUDE.md, Uroš introduced Auto Memory, which accumulates knowledge across sessions without any manual effort, storing learnings in plain markdown files that Claude reviews at the start of each new conversation.

#### 5. Planning and Thinking Modes

Participants learned how to shift [Claude Code](https://claude.ai/) into different operational modes depending on the task at hand. Plan Mode restricts Claude to read-only tools, allowing it to thoroughly explore the codebase and produce a detailed implementation plan before touching a single file. Thinking modes, from basic Think to Ultrathink, give Claude progressively more reasoning capacity for complex logic problems, difficult debugging scenarios, and algorithmic challenges. Uroš also clarified an important distinction that often causes confusion: effort and thinking are separate controls, and increasing one does not automatically increase the other.

#### 6. Commands

The talk explained how commands extend Claude Code's functionality through simple slash notation. Participants saw examples of both built-in commands, such as /compact, /clear, /memory, and /agents, as well as custom commands stored in the .claude/commands directory. The $ARGUMENTS pattern for parameterized commands proved particularly popular among attendees.

#### 7. Skills

Skills are markdown guides that Claude auto-invokes based on the context of a conversation. Unlike commands, which require manual triggering, skills activate automatically when Claude recognizes a relevant situation. Uroš demonstrated how a well-written description field in a SKILL.md file is the key to reliable auto-activation, and walked through several practical skill ideas including code-review, testing-patterns, explain-code, and docker-deploy.

![CYBERLAB](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Uros_Petric_7e15908ce3.jpg)

#### 8. Agents and Subagents

The second half of the session was dedicated to subagents, which drew considerable attention from the audience. Subagents are specialized AI assistants that handle specific tasks in fully isolated contexts, each running with its own system prompt, tool access, and independent permissions. Through concrete examples, Uroš demonstrated how subagents help preserve the main conversation context, enforce constraints on tool usage, enable parallel task execution, and even control costs by routing lighter tasks to faster, cheaper models. He also walked through the three built-in subagent types, Explore, Plan, and General Purpose, each with different model and tool configurations suited to different stages of a workflow.

#### 9. MCP Servers

Model Context Protocol servers unlock integrations with external services directly from Claude Code. The talk covered a range of practical integrations, including GitHub for repository and pull request management, Figma for design-to-code workflows, Notion for workspace connectivity, Slack for messaging and data retrieval, and Playwright for automated browser testing. Participants left with a clear picture of how MCP transforms Claude Code from a standalone coding assistant into a connected development hub.

#### 10. Hooks

The final topic covered Hooks, one of the most powerful and underused features in Claude Code. Hooks allow developers to run a command before or after Claude Code performs any action, and optionally block that action entirely. Use cases demonstrated during the session included automatically running a code formatter after every file edit, blocking commits that introduce deprecated function calls, checking for TODO comments and logging them to a file, and enforcing naming conventions across the codebase. Participants saw how PreToolUse hooks can serve as safety gates and can block an action by returning exit code 2, while PostToolUse hooks provide a way to react to Claude's actions without interrupting the flow.

![Q and A](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/NEM_187_resized_7efcc9e449.jpg)

## Learning Resources

At the end of the presentation, attendees received a curated list of resources for further exploration:

* [Claude Code in Action course](anthropic.skilljar.com/claude-code-in-action) 
* [Claude Code official documentation](docs.anthropic.com/claude-code) 
* [Claude Code Templates](https://www.aitmpl.com/)
* [Claude Code Best Practices](https://github.com/shanraisshan/claude-code-best-practice)
* [CYBERLAB blog](www.cyberlab.rs/blog) 

These materials provide an excellent starting point for anyone looking to integrate Claude Code into their daily development workflow.

## Networking 

After the presentation, participants enjoyed an informal networking session, where they had the opportunity to talk with Uroš and the [CYBERLAB](https://www.cyberlab.rs/) team about their projects, questions, and early experiences with Claude Code. Topics ranged from practical CLAUDE.md setups and skill configurations to broader questions about where AI-assisted development is heading and how teams can adopt it gradually without disrupting existing workflows.
![Networking I CYBERLAB](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Uros_Petric_I_Claude_Code_81335a7dde.jpg)

## Conclusion

The **"Claude Code 101: From Zero to Full Potential"** event demonstrated that the local developer community is actively exploring AI tools and looking for concrete, practical guidance on how to use them well. AI-assisted development, intelligent context management, and autonomous coding agents are becoming increasingly relevant across all types of software projects, and this meetup once again highlighted how shared learning strengthens the entire community.

See you at the next [CYBERLAB](https://www.cyberlab.rs/) event!

We're always happy to share our knowledge and experiences. Feel free to follow or reach out to us on [LinkedIn](https://www.linkedin.com/company/cyberlabsolutions) |[ Facebook](https://www.facebook.com/cyberlabsolutions/) |[ Instagram](https://www.instagram.com/cyberlabsolutions/). 


Insights from a Community Talk on Claude Code and AI-Assisted Development

Pozivamo vas da nam se pridružite na događaju koji organizujemo na temu “Claude Code 101: From Zero to Full Potential", 21. 4. sa početkom od 18h u Prostoru, u Novom Sadu.

Claude Code 101:

Pozivamo vas da nam se pridružite na događaju koji organizujemo na temu **“Claude Code 101: From Zero to Full Potential"**, **21. 4.** sa početkom od **18h** u [Prostoru](https://www.facebook.com/prostorgradic/?locale=sr_RS), u Novom Sadu.

Evo svega što trebate da znate:

## Ko je predavač?

U ulozi predavača naći će se [Uroš Petrić](https://www.linkedin.com/in/urospetric?skipRedirect=true&miniProfileUrn=urn%3Ali%3Afs_miniProfile%3AACoAACIr7FIBfVR4sK3Q_p4JwLgaqomQg9uoimg), softver inženjer sa višegodišnjim iskustvom u razvoju aplikacija i aktivnoj primeni AI alata u svakodnevnom radu. U okviru [CYBERLAB](https://www.cyberlab.rs/)-a Uroš je, uz pomoć AI, uspešno vodio razvoj interne aplikacije od ideje do produkcije za svega nekoliko nedelja. Svoje znanje i iskustvo Uroš redovno deli sa kolegama kroz interne knowledge sharing sesije.

Na predavanju vas očekuju jasni uvidi u to kako AI alati mogu da unaprede svakodnevni razvojni proces, bez obzira na tehnologiju koju koristite.

## O čemu će biti reči?

Ovom prilikom, Uroš će govoriti o tome:

* Šta je Claude Code i kako funkcioniše kao coding assistant
* Ključnim konceptima: Tools, Context, CLAUDE.md, Memory, Commands, Skills, Agents, MCP Servers i Hooks
* Kako efikasno kontrolisati razgovor i maksimalno iskoristiti Claude Code u svakodnevnom radu

## Kome je predavanje namenjeno?

* Developerima i softver inženjerima koji žele da ubrzaju svoj workflow
* IT profesionalcima koji žele da razumeju kako AI menja način na koji se piše kod
* Svima koji su radoznali, predavanje kreće od osnova i pokriva sve najbitnije celine

## Zašto da se prijavite?

Ova tema može biti posebno zanimljiva ukoliko:

* Još niste počeli da koristite coding assistente, ali razmatrate tu mogućnost
* Koristite AI alate u svom radu, ali niste sigurni da li ih koristite na optimalan način
* Tražite konkretne tehnike i prakse koje možete odmah primeniti u svom projektu

Pozivamo vas da nam se pridružite i steknete vredne uvide koji će vam pomoći da izvučete maksimum iz Claude Code-a u svakodnevnom radu.

## Kako da se prijavite?

Broj mesta je ograničen, stoga je neophodno da potvrdite svoje prisustvo popunjavanjem forme koja se nalazi u nastavku. Prijave su otvorene **ponedeljka, 20. aprila do 12h** a u slučaju popunjavanja svih mesta, prijave će biti zatvorene i ranije.

## **[PRIJAVITE SE OVDE 👈](https://forms.gle/c4wgUrTq9PfYx1xe8)**

Nakon predavanja vas očekuje networking i neformalno druženje tokom kojeg ćete imati priliku da sa Urošem diskutujete o različitim temama i postavite sva pitanja koja vas zanimaju o korišćenju Claude Code-a i AI alata u svakodnevnom radu. Vidimo se u **utorak, 21. aprila u 18h** u [PROSTOR](https://share.google/om60XImwwLZ5tjHkE)-u! 🙂


From Zero to Full Potential

CYBERLAB is now an AWS Select Tier Services Partner, recognized for technical expertise, secure and scalable cloud solutions, and proven customer success.

CYBERLAB Achieves:

We’re proud to announce an important milestone for [CYBERLAB](https://www.cyberlab.rs/): **we are now an [AWS Select Tier Services Partner](https://aws.amazon.com/partners/services-tiers/)**. This recognition reflects our technical expertise, strong customer success record, and commitment to delivering secure, scalable, and high-performing cloud solutions.

At a time when organizations face increasing cloud complexity, rising cost pressure, and stricter security demands, this achievement reinforces our role as a **trusted engineering partner** that helps teams move faster with confidence.

## What AWS Select Tier Status Means 

The AWS Select Tier Services Partner designation is awarded to companies that meet strict standards across technical capability, customer success, and operational excellence. For us, it validates that we:

* Design and deliver architectures aligned with AWS best practices for **security, reliability, and performance**
* Successfully support **mission-critical and production workloads** on AWS
* Apply **deep, hands-on expertise** across cloud infrastructure, [DevOps](https://www.cyberlab.rs/devops) automation, and modern application platforms

As a Select Tier Partner, we gain access to enhanced AWS enablement, direct technical guidance, and closer collaboration with AWS experts, allowing us to continuously refine how we design, build, and operate cloud platforms for our partners.

## Tangible Benefits for Our Partners

This milestone translates directly into measurable value for the organizations we work with:

* **Secure and resilient cloud foundations** designed for real production traffic, not just proofs of concept
* **Scalable architectures** that adapt to growth, peak demand, and long-term evolution
* **Faster delivery and innovation**, combining AWS-native services with our DevOps-first approach
* **End-to-end ownership**, from cloud strategy and migration to optimization, automation, and ongoing operations

Whether you’re modernizing legacy systems, migrating to AWS, or optimizing an existing environment, [we](https://www.cyberlab.rs/meet-the-team) help you reduce risk, improve reliability, and shorten time to value.

## What Sets Us Apart

Many organizations hold AWS partner status. What differentiates us is how we deliver and operate:

* **A DevOps-first mindset** focused on automation, observability, and reliability from day one.
* **Extensive experience running complex, production-grade environments**, including high-availability and regulated workloads.
* **Full lifecycle responsibility**: we design, build, operate, and continuously improve cloud platforms.
* **A partner-led delivery model** where we own solution quality and customer experience end-to-end.

AWS provides us with tools and technical support, but we remain fully accountable for results.

## Our Commitment Going Forward

We see this designation not only as a recognition of our past achievements but also as a foundation for **future innovation and collaboration**. It strengthens our ability to help clients navigate cloud adoption, modernization, and optimization, while staying focused on what matters most: **delivering reliable systems and measurable business outcomes**.

If you’re planning a cloud migration, platform modernization, or optimization initiative, we are ready to support you with proven expertise and hands-on delivery.

Discover how [CYBERLAB](https://www.cyberlab.rs/), together with [Amazon Web Services](https://aws.amazon.com/), can help your business build, scale, and operate with confidence in the cloud. [Contact us](https://www.cyberlab.rs/contact) today to get started.


AWS Select Tier Services Partner Status

Over 150 participants came together at our New Year’s Charity Pub Quiz in Novi Sad, raising 1,400 EUR to support Minja, Strahinja, and Vukašin in their fight against a rare ADSL gene mutation.

New Year’s Charity Pub Quiz:

On **December 23, 2025,** we held our[ New Year’s Charity Pub Quiz](https://www.cyberlab.rs/blog/cyberlab-novogodisnji-humanitarni-pub-kviz-minja-strahinja-vukasin) at The Pub in Novi Sad, bringing together colleagues, friends, and members of the local community for an evening dedicated to knowledge, teamwork, and giving back.

Thanks to the generosity of all participants, **we raised and donated 1,400 EUR** to support **Minja, Strahinja, and Vukašin** in their fight against a rare ADSL gene mutation and to help fund the treatment they needed.
![New Year’s Charity Pub Quiz: Supporting Minja, Strahinja, and Vukašin](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/New_Year_s_Charity_Pub_Quiz_Supporting_Minja_Strahinja_and_Vukasin_7e762b2e07.jpg)

## A Tradition Built by People and Ideas

The story of our quiz began a few years ago as an internal [CYBERLAB ](https://www.cyberlab.rs/)initiative, launched by **Dragan Perić** and **Andrija Vojnović**. What started as a small team event gradually grew into a tradition that brings people together beyond the company walls.

Last year, this tradition took an important step forward with the [DragiAndro Quiz Special](https://www.cyberlab.rs/blog/dragiandro-quiz-for-childrens-smile), the first open charity edition of the quiz, which marked the transition from an internal gathering to a community-focused event with a humanitarian goal.

Building on that momentum, the concept continued to evolve through the efforts of **Nemanja Radoičić** and **Bojan Baškalo**, who brought new energy to the format through the **BN Quiz** and helped further strengthen the quiz culture within the team. This year, for the first time, these initiatives came together in a joint charity event with an even greater impact.

![New Year’s Charity Pub Quiz: Supporting Minja, Strahinja, and Vukašin - Hosts](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/New_Year_s_Charity_Pub_Quiz_Supporting_Minja_Strahinja_and_Vukasin_Bojan_Baskalo_Andrija_Vojnovic_Nemanja_Radoicic_a65d9aa698.jpg)

## Turning Knowledge into Support

A great atmosphere, friendly competition, and a shared sense of purpose marked the quiz night. With a symbolic ticket price and strong community participation, the event showed how small individual contributions can turn into meaningful collective support.

Raising **1,400 EUR** in a single evening is a clear example of what can be achieved when people come together around a common goal.

![Participants in a quiz ](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/New_Year_s_Charity_Pub_Quiz_Supporting_Minja_Strahinja_and_Vukasin_61511c83dd.jpg)

## Thank You for Making It Possible

We would like to thank [Elite Tennis Academy](https://tennisacademyelite.com/), [Bossi Pizza](https://www.facebook.com/p/Bossi-Pizza-100052412786270/), and [Arena Cinaplex](http://www.arenacineplex.com/) for supporting the quiz and providing prizes. A special thank-you goes to [Andrija, Nemanja, and Bojan](https://www.cyberlab.rs/meet-the-team), whose dedication and enthusiasm helped turn an idea into a successful charity event.

Most of all, thank you to everyone who participated and contributed.

![Quiz Question](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/New_Year_s_Charity_Pub_Quiz_Supporting_Minja_Strahinja_and_Vukasin_67e0572ae0.jpg)

## United for a Common Goal

This quiz once again showed how much can be achieved through collaboration and shared effort. By combining knowledge, teamwork, and community support, we created an event with a real and measurable impact

Although the quiz night is over, the initiative continues. We invite everyone who would like to contribute further to support Minja, Strahinja, and Vukašin by following the donation instructions **[here](https://www.budihuman.rs/korisnik/1417/minja-lapcevic)**. 

Stay connected with us on [LinkedIn](https://www.linkedin.com/company/69988472/admin/notifications/all/), [Instagram](https://www.instagram.com/wearecyberlab/), and [Facebook](https://www.facebook.com/cyberlabsolutions/) to keep up with future initiatives.


 Supporting Minja, Strahinja, and Vukašin

Setting up a local Kubernetes cluster using Kind, deploying a demo app, and seeing how Skaffold streamlines the process for faster development and testing.

Kubernetes Development:

As more organizations shift towards cloud native software approach, whether it be tight or loosely coupled technique, the challenging part is to provide developers with development environments that can support a smooth transition. \
On the cloud native palette there are a couple of tools that can provide this loop for developers with one topic in focus - “write code”.


## What is Skaffold?

[Skaffold](https://skaffold.dev/) is an open-source project released by Google with some key areas that covers:



* It is lightweight client-side only tool, that developers can easily install on local machine 
* It must works everywhere, meaning easy share project with other developers
* If covers all container and[ kubernetes]( https://kubernetes.io/) features that makes developers productive more
* It must provide continuous feedback to developers while developing

Now that I get your attention, shall we dive a little further?


## Prerequisites

In order to follow my presentation, I’ve prepared code available for you at [skaffold-demo](https://github.com/Igor992/skaffold-demo ) 


There is **Makefile**, just in case that you’re wish to follow along with the reading this blog

```
➜ skaffold-demo git:(main) ✗ make
Usage:
  make [ COMMAND ]

Commands:
  all        Run all targets
  tools      Install necessary tools
  cluster    Install local cluster
  ingress    Setup ingress-nginx controller
  skaffold   Generate voting-app images
  certs      Make locally trusted development certificates
  hosts      Add hosts to /etc/hosts

```

When we finish this setup you can use **make all** to get all-at-once prepared, but for now let’s start step-by-step. \
By that said, use **make tools** and you will be prepared on tools that we will need on local machine \
**in my case this is already up-to-date*


```
➜ skaffold-demo git:(main) ✗ make tools

🍺 Install necessary tools
brew install --quiet homebrew/core/kind
brew install --quiet homebrew/core/kubernetes-cli
brew install --quiet homebrew/core/helm
brew install --quiet homebrew/core/skaffold
brew install --quiet homebrew/core/mkcert
brew install --quiet homebrew/core/nss

```



### Setup local cluster

We will use Kind as a local cluster that operates over Docker installed on your machine. 

I will assume that you know what Docker is and that it is already installed on your machine. \
As a good practice I always run the below command to keep the machine clean.

**docker system prune --all --force --volumes**

Now run **make cluster** and wait couple of minutes (time for coffee)


```
➜ skaffold-demo git:(main) ✗ make cluster

🚀 Install local cluster
kind create cluster --config /Users/igor/Documents/CyberLab/skaffold-demo/k8s/kind.yaml --wait 5m
Creating cluster "develop" ...
 ✓ Ensuring node image (kindest/node:v1.32.2) 🧊
 ✓ Preparing nodes 🧱
 ✓ Writing configuration 📝
 ✓ Starting control-plane 🧑‍✈️
 ✓ Installing CNI 🌐
 ✓ Installing StorageClass 💾
 ✓ Joining worker nodes 🧩
 ✓ Waiting ≤5m0s for control-plane = Ready 🏁
 ✓ Ready after 1s 🎉

Set kubectl context to "kind-develop"

You can now use your cluster with:

kubectl cluster-info --context kind-develop

Have a nice day! 👋
```

At this point you should get pointed to kind context locally as 

```
➜ skaffold-demo git:(main) ✗ kubectl config current-context
kind-develop

➜ skaffold-demo git:(main) ✗ kubectl cluster-info
Kubernetes control plane is running at https://127.0.0.1:54784
CoreDNS is running at https://127.0.0.1:54784/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
```




### Setup ingress controller

You can skip this if you want, but I prefer to set up ingress and prepare later locally trusted development certificates. 
If want to follow use **make ingress** and wait until we met the condition meaning that’s all good and running to be used inside this local cluster.


```
➜ skaffold-demo git:(main) ✗ make ingress

🧩 Setup ingress-nginx controller
kubectl apply --filename /Users/igor/Documents/CyberLab/skaffold-demo/k8s/ingress/deploy.yaml
namespace/ingress-nginx created
serviceaccount/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
service/ingress-nginx-controller created
service/ingress-nginx-controller-admission created
deployment.apps/ingress-nginx-controller created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
ingressclass.networking.k8s.io/nginx created
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission created

⏳ Wait condition to met
kubectl wait --namespace ingress-nginx --for=condition=ready pod \
  --selector=app.kubernetes.io/component=controller \
  --timeout=120s
pod/ingress-nginx-controller-697950d654-2m7zc condition met

```


### Provide registry

This section we need to provide in order to tag our local images. It will ask you for input based on you desired registry. In this case Dockerhub as you can see below

```
⬇️ Configure DockerHub registry
Provide your DockerHub account: igor992

⬇️ Updating configuration with registry: igor992
✅ Registry configuration updated

```

*<span style="text-decoration:underline;">NOTE:</span>* For this demo, as you will see later we will not push those images, instead we will use them locally from Kind cluster. If you want for any reason to push those to Dockerhub, you will need to prepare [connection](https://docs.docker.com/reference/cli/docker/login/) and change **skaffold.yaml** at section *local.push = true*

As placeholder code has *&lt;registry>* on two location [helm values](https://github.com/Igor992/skaffold-demo/blob/main/helm/values.yaml) and [skaffold](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml)

When you provide above information those will be changed. 



### Generate images

Now that we have a cluster ready for usage, we need to prepare images locally for our demo application. \
For this we use **make skaffold** 



```
➜ skaffold-demo git:(main) ✗ make skaffold

🧱 Using skaffold to generate starting images
cd voting-app && \
  export IMAGE_TAG=latest && \
  skaffold build --profile vote-images,--seed-image && \
  skaffold build --profile vote-images,--seed-image

Generating tags...
 - igor992/result -> igor992/result:latest
 - igor992/vote -> igor992/vote:latest
 - igor992/worker -> igor992/worker:latest

Checking cache...
 - igor992/result: Not found. Building
 - igor992/vote: Not found. Building
 - igor992/worker: Not found. Building

Starting build...
Found [kind-develop] context, using local docker daemon.
Building 3 artifacts in parallel
Building [igor992/result]...
Target platforms: [linux/arm64]
#0 building with "default" instance using docker driver
```


As you can see it will use at this point something new as **skaffold build –profile**

This is coming from **skaffold.yaml** [spec](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml#L73-L76) that we have under **voting-app** directory. \
Here **build** act as control how artifact will be build and **–profile** control order of building those artifacts, as we have two profiles minus sign e.g. **-seed-image** excludes that [profile](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml#L105-L108) to be executed.


###  
Trust development cluster

We will now add these locally trusted certificates for our development application by **make certs**


```
➜ skaffold-demo git:(main) ✗ make certs

🔐 Make locally trusted development certificates
cd .tls && \
  mkcert "*.kind.local" && \
  kubectl create namespace dev && \
  kubectl --namespace dev create secret tls demo-cert \
    --key=._wildcard.kind.local-key.pem \
    --cert=._wildcard.kind.local.pem && \
  mkcert --install

Created a new certificate valid for the following names
 - "*.kind.local"

🔎 Reminder: X.509 wildcards only go one level deep, so this won’t match a.b.kind.local 🧠

✅ The certificate is at "./_wildcard.kind.local.pem" and the key at "./_wildcard.kind.local-key.pem" 🗝️
📅 It will expire on 1 June 2027 🎉

namespace/dev created
secret/demo-cert created
The local CA is already installed in the system trust store! 👍
The local CA is already installed in the Firefox trust store! 👍
The local CA is already installed in Java’s trust store! 👍

```




**I’ll not explain above part on this blog*

Last one in order to use configured ingress with trusted certificates we need to change **/etc/hosts** over **make hosts**. 

This will require from you to allow this (type your password) so we can add two entries as

 
**127.0.0.1 	dev-vote.kind.local dev-result.kind.local**


## Deploy application

 
**Application is for demo purpose only  and not focused on best-precites on Docker images and other container topics.*

Under the **voting-app** directory you will see **skaffold.yaml** [definition](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml). Let’s give a short introduction into this configuration before we use it.

In this demo we are going to use stable *skaffold/v3* schema version followed by three *profiles*.



* local-develop
* vote-images
* seed-image 


Profile *[vote-images](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml#L73)* and *[seed-image](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml#L105)* we already used over **make skaffold** step before.  \
This prepared locally for us three images for *result*, *vote* and *worker* services and one more *seed-data*, to be able to provide fake clicks and populate the database.



```
➜ voting-app git:(main) ✗ docker images -a

REPOSITORY        TAG       IMAGE ID       CREATED          SIZE
igor992/seed-data  4d58b8c   4d58b8c6cf34   18 minutes ago   132MB
igor992/seed-data  latest    4d58b8c6cf34   18 minutes ago   132MB
igor992/worker     247d9c7   247d9c79b44f   18 minutes ago   139MB
igor992/worker     latest    247d9c79b44f   18 minutes ago   139MB
igor992/result     7d6ef7e   7d6ef7e45c8e   18 minutes ago   138MB
igor992/result     latest    7d6ef7e45c8e   18 minutes ago   138MB
igor992/vote       5706951   570695168d11   18 minutes ago   184MB
igor992/vote       latest    570695168d11   18 minutes ago   184MB
kindest/node       <none>    9ba0a97d7488   2 weeks ago      1.68GB
```


In order to deploy the whole stack on our local cluster, we are going to use a *local-develop* [profile](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml#L6) over command **skaffold dev**



```
➜ voting-app git:(main) ✗ skaffold dev

Generating tags...
 - igor992/result -> igor992/result:8181ec5
 - igor992/vote -> igor992/vote:8181ec5
 - igor992/worker -> igor992/worker:8181ec5

Checking cache...
 - igor992/result: Found Locally
 - igor992/vote: Found Locally
 - igor992/worker:
```


As we already prepared images before, it will use local ones. 
You can see part when we hit the deploy phase of our configuration defined under *[skaffold.yaml ](https://github.com/Igor992/skaffold-demo/blob/main/voting-app/skaffold.yaml#L40)* file (*Starting deploy…*) 
Images will be loaded under a local cluster, in our case Kind.  
To be able to check those use command below \
**docker exec -it $(kind get clusters | head -1)-worker crictl images**

This will interact with one of the nodes locally and print images that’s there present. 



```
➜ skaffold-demo git:(main) ✗ docker exec -it $(kind get clusters | head -1)-worker crictl images

IMAGE                                   TAG                                         IMAGE ID            SIZE
docker.io/igor992/result                15439a086162c0cc9c8ebc01a2b789b730175785e5a2faf7eb550b51cc9407   138MB
docker.io/igor992/vote                  4d861b51985c372cbad13b79b9f9d8e24eb47e64bb172c947528b8009e9799   184MB
docker.io/igor992/worker                1865a8b7f235469d1124e9105d934874bb1bef86793e                      139MB
docker.io/kindest/kindest               v1.32.0@sha256:a8abac                                             1.68GB
```


**There are other images also present in node*

Wait a bit to stabilize deployment as we have checks that perform if redis and database are first ready for connection.


```
Happy Helming!
Waiting for deployments to stabilize...
 - dev:deployment/dev-worker is ready. [1/5 deployment(s) still pending]
 - dev:deployment/redis is ready. [2/5 deployment(s) still pending]
 - dev:deployment/dev-result is ready. [3/5 deployment(s) still pending]
 - dev:deployment/dev-vote is ready. [1/5 deployment(s) still pending]
 - dev:deployment/db is ready.

Deployments stabilized in 1.144 second

Port forwarding service/redis in namespace dev, remote port 6379 -> http://127.0.0.1:6379
Port forwarding service/db in namespace dev, remote port 5432 -> http://127.0.0.1:5432

Listing files to watch...
 - igor992/result
 - igor992/vote
 - igor992/worker

Press Ctrl+C to exit
Watching for changes...
```


At this point skaffold will perform next job for development lifecycle



* allow developers access to redis and database locally
* constantly loop over changes under three services
    * if there is any code change made by developer it will sync those


```
Syncing 1 files for igor992/vote:4d861b51985c372cbad13b79b9f9d8e24eb47e64bb172c947528b8009e9799
Watching for changes...

[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [18] [INFO] Worker reloading: /app/app.py modified
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [19] [INFO] Worker reloading: /app/app.py modified
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [20] [INFO] Worker reloading: /app/app.py modified
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [21] [INFO] Worker reloading: /app/app.py modified
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [22] [INFO] Worker exiting (pid: 19)
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [23] [INFO] Worker exiting (pid: 20)
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [24] [INFO] Worker exiting (pid: 21)
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [25] [INFO] Booting worker with pid: 24
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [26] [INFO] Booting worker with pid: 25
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:13 +0000] [27] [INFO] Booting worker with pid: 26
[dev-vote-5480b9c78b-655m5 dev-vote] [2025-08-02 14:36:14 +0000] [27] [INFO] Booting worker with pid: 27
```



In order for this to work, under the hood it uses the **kubectl cp** command and if you ever worked with this one, it is [required](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cp/#examples) to have **tar** binary installed under a running container. 
Another catch is to allow the service to reload its process on file changes. 
This will add *<span style="text-decoration:underline;">hot code reloading</span>* ability so that we can live see changes after sync. 
For this we always have separate image that will skaffold use during development and not the same one as we bake for the production best-practice usages. 
In our case as we use *[gunicorn](https://docs.gunicorn.org/en/latest/settings.html#reload)* we added flag --reload to support this process changes.


## Simulate voting

At this point as this dummy application supports one vote per time, we will simulate that we have “external” users to perform this voting for us. \
For this we first needs to push image inside Kind over  \
**kind load docker-image igor992/seed-data -n develop** \
where it will add this on each nodes for usage



```
➜ skaffold-demo git:(main) ✗ kind load docker-image igor992/seed-data:4d58b8c6cf34 --name develop

Image: "igor992/seed-data:4d58b8c6cf34" with ID "sha256:fbf75323215720f3b3c3143c1dd73b1b09cba97f5959349614ecaf7d4a5ea0e7" not yet present on node "develop-control-plane", loading...
Image: "igor992/seed-data:4d58b8c6cf34" with ID "sha256:fbf75323215720f3b3c3143c1dd73b1b09cba97f5959349614ecaf7d4a5ea0e7" not yet present on node "develop-worker", loading...
```

Then just use command

**kubectl run seed-data --namespace dev --rm --tty -i --restart='Never' --image igor992/seed-data:latest**

 \
Wait a bit and it will populate “fake” votes on our application. That will be shown as result over *[https://dev-result.kind.local](https://dev-result.kind.local) \
*And if you really want jump into locally database to validate those also \
**psql --host localhost --port 5432 --no-password --username postgres \
SELECT id,vote FROM public.votes;**

To prove that redis is also there use **redis-cli INFO server** or **redis-cli ping** to get response as **pong** 



## Conclusion

With this presentation I wanted to bring closer to developers a new approach on how development can be faster in terms of cloud computing service. If this implements another layer of shit-left practice, developers get feedback much faster even before the first real image gets deployed as permanent to be shared with the rest of the team.

With this said, keep learning each day something different and new is what makes a cloud native experience more fun.

For more information on [Kubernete]( https://kubernetes.io/)s and [Skaffold](https://skaffold.dev/), feel free to visit their official websites, which I also referenced while writing this blog.

 \
Until my next [blog,](https://cyberlab.rs/blog) Happy Helming! 👋


 Building with Skaffold

Looking for the best data storage approach for your project? Explore our full blog to learn about the pros and cons of each method to make an informed decision!

Database Paradigms: 

Are You Using the Right One?

Discover how the JavaScript Event Loop, APIs, and Promises enable async, non-blocking execution for fast, responsive apps.

JavaScript Event Loop: 

An **event loop** is a programming construct - pattern that allows the program to handle multiple operations or tasks concurrently without the need for multiple threads. The event loop is most often mentioned in pairs with the [Javascript](https://www.javascript.com/) programming language and it represents the crucial part of Javascript’s event-driven concurrency model.

## Event Loop and Javascript

[Javascript](https://www.javascript.com/) is a single-threaded programming language, which implies that it can process only one task at any point in time. 

Considering that, one could ask questions like:

1. If we have a backend application written in Javascript that needs to process multiple HTTP requests, does that mean that all requests will be processed sequentially, as Javascript can do only one task at a time?
2. If we have a frontend application that on initial load needs to fetch some data from some API, will the render of the page be slow as it needs to wait for the API call to finish?

The answer to these and other similar questions is “No”. Runtime Environment for the Javascript leverages an Event Loop among other mechanisms to allow processing of multiple operations seemingly at the same time. Having said that, we can add that Javascript is also asynchronous and non-blocking.

## Javascript Runtime Environment

The Javascript Runtime Environment, as the name suggests, is the environment in which the Javascript code executes. It consists of:

* APIs (I/O API, Storage API, Networking API, etc)
* Engine
* Event Loop with the queue(s)


![Javascript Runtime Environment Architecture Simplified](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Javascript_Runtime_Environment_af35215f18.png)

Image: Javascript Runtime Environment Architecture Simplified

The blue circle with the red square represents the Event Loop which takes tasks from the Queues, one by one, and provides them to the Engine that is executing them. The Microtask queue has an advantage over Task and View Task queues.

## How Does the Engine Work?

The main part of the Engine, important for understanding the purpose of the **Event Loop**, is the Call Stack. The **Call Stack** is used to track the execution of the function(s) inside the task provided by the Event Loop. Whenever a function is called it is added to the Call Stack, and whenever its execution is finished it is removed from the Call Stack. After the function is removed from the Call Stack, the execution of the caller function continues. If there are no more functions on the Call Stack, the Event Loop provides another task for execution.

Hereby an example the execution of a series of functions and how that execution reflects on the Engine.

![State of the engine just before printFooBaz function starts executing](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Print_Foo_Baz_ed6fc62a20.png)
Image: State of the engine just before ***printFooBaz*** function starts executing

![slika 3.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/slika_3_76994fe609.png)

Image: The ***printFooBaz*** function is added to the Call Stack and it’s execution starts

![slika 4.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/slika_4_86b58f415e.png)

Image: The program continues by calling a ***foo*** function
![slika 5.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/slika_5_d082fa400f.png)

Image: The ***foo*** function is added to the Call Stack and it’s execution starts

![slika 6.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/slika_6_f3da236c6e.png)
Image: Calculation of the ***foo*** variable

![slika 7.png](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/slika_7_09a572054b.png)

Image: Before the return statement, the program continues by calling a ***baz*** function
![Before the return statement, the program continues by calling a baz function](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/baz_function_c4e4afdfbf.png)

Image: The ***baz*** function is added to the Call Stack and it’s execution starts
![The baz function returns a calculated value and finishes its execution](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/baz_function_returns_a_calculated_07fc3d958a.png)

Image: The ***baz*** function returns a calculated value and finishes its execution
![The baz function returns a calculated value and finishes its execution](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/The_baz_function_returns_a_calculated_863bdf3b99.png)

Image: The execution is returned to the ***foo*** function and function ***baz*** is removed from the Call Stack

Execution goes on and on, until the end of the execution of the ***printFooBaz*** function. After the ***printFooBaz*** function is executed the Call Stack will be empty, and only then will another task be able to be loaded for the execution.


## Why Do We Even Need the Event Loop

As we saw in the example above, the Engine, with the Call Stack and the Heap, is pretty comfortable executing the Javascript code. Considering mentioned, one would ask, why do we even need an Event Loop, Queues, and APIs. Why can’t we just work with the Call Stack and the Heap. The answer is:  maybe we could, but then we will have a slow program as without the mentioned components Javascript cannot handle concurrent execution of multiple operations.

To demonstrate the purpose of the Event Loop, Queues and APIs let's analyze one example of fetching text from an API on a simple HTML page using Javascript.
![The image you see above represents the basic HTML page that consist of a few parts:](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/basic_HTML_page_0793e9f105.png)
The image you see above represents the basic HTML page that consist of a few parts:

1. **Fetch Text** button
2. **Call a Friend** button
3. **Extra Cool Animation** Made with Javascript representing stars moving in circles.

![The state of the Runtime Environment after the page is loaded](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Runtime_Environment_8936c78150.png)

The state of the Runtime Environment after the page is loaded

Now, let’s start interacting with the page by clicking on the **Fetch Text** button. What happens under the hood?

![The state of the Runtime Environment after the Fetch Text button is clicked](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Runtime_Environment_after_the_Fetch_Text_75d055ddf5.png)

The state of the Runtime Environment after the **Fetch Text** button is clicked

The new task, representing (containing) a function ***handleOnClick***, appears in the Task Queue which is then taken by the Event Loop and given to the Engine for execution. The Event Loop is stuck and it cannot give new tasks to the Engine before the Engine finishes the execution of the current one. That implies that until the execution of the ***handleOnClick*** function ends, the engine will be doing only and exactly that, executing the ***handleOnClick*** function.

![The function code that handles onClick event for the Fetch Text button](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/The_function_code_that_handles_on_Click_d465deb7fd.png)

The function code that handles ***onClick*** event for the **Fetch Text** button
![The current state of the Runtime Environment during the fetchText API request:](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Runtime_Environment_during_the_fetch_Tex_51cc82dff4.png)

The current state of the Runtime Environment during the ***fetchText*** API request:

What happens with the rest of the page? It will be unresponsive. The Engine works on handling the latest task and it cannot process others, like view tasks, therefore cannot re-render UI, nor can it do anything else. This means that our **Extra Cool Animation** written in Javascript will stop working and also **Fetch Text** and **Call a Friend** buttons will become unclickable which will drastically slow the web application and ruin the user experience. 

How do we solve this problem? By leveraging the concept of Promise and APIs component of the Runtime Environment.

## Promise

Before we get to the solution there is another important mechanism that needs to be understood. Namely, the Promise. 

So, what is a **Promise object**, is it an instance of a Promise class? According to the [Mozilla Developer Network](https://developer.mozilla.org/en-US/) (Ref.): “The Promise object represents the eventual completion (or failure) of an asynchronous operation and its resulting value.” 

So, it is an object that at the moment of instantiation does not have a value. Its value will either be resolved successfully or will be rejected. In our example of fetching text, we will either get the text for which we sent a request for, or an error.

The promise mechanism is mostly used in situations like we have right now. We want to fetch some data from somewhere, but instead of making the Engine do the work synchronously, we will call a ***fetch ***function, which will return us a Promise and do the fetching asynchronously. After the Promise is either resolved or rejected the callback functions registered with ***.then()***, ***.catch()***, or ***.finally()*** are scheduled to run in the microtask queue, where they will be later picked up by the Event Loop and given to the Engine for execution.

## Leveraging Promises, APIs, Event Loop and Task Queues for Asynchronous Non-blocking Execution

Let’s return to our solution. Instead of letting the Engine do the fetching of the text and block the execution of other tasks we should assign that task to the Networking API and provide the callback function which will execute after the text is fetched. By doing that, we block the Engine only for the time the job is assigned to the Networking API and after that, the Engine is free and can accept new tasks. The code snippet below shows exactly that:
![Handling mouse click using fetch function that returns Promise](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/fetch_function_694496829a.png)
Handling mouse click using ***fetch*** function that returns Promise

1. We call the ***fetch*** function which under the hood sends the HTTP GET request using the Networking API of the Runtime.
2. The ***fetch*** function returns a Promise to which we specify an anonymous function that will execute after the promise is either resolved or rejected - then and catch.
3. After the Networking API finishes its job the Runtime will create a new Microtask and add it to the microtask queue, which contains the response and the callback function.
4. When the Call Stack becomes empty The Event Loop will take the task and give it to the Engine for execution.

Below are the series of pictures representing the state of the Runtime Environment after the **Fetch Text** button is clicked.
![The Engine executes the fetch function which triggers the Networking API and returns the Promise object](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/executes_the_fetch_function_6ad442b6f8.png)

1. The Engine executes the ***fetch*** function which triggers the Networking API and returns the Promise object
![The Call Stack is empty and the Event Loop can provide new tasks for the Engine to execute](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Event_Loop_142f1ca24b.png)
2.  The Call Stack is empty and the Event Loop can provide new tasks for the Engine to execute
![The Call Stack is empty and the Event Loop can provide new tasks for the Engine to execute](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Event_Loop_3e0c858e97.png)
3.  The Networking API finished it’s job and the Runtime Environment scheduled a new Microtask
![The Networking API finished it’s job and the Runtime Environment scheduled a new Microtask](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Runtime_Environment_scheduled_a_new_Microtask_5fcf304f95.png)
4.  The Microtask gets picked up by the Event Loop and gives its callback to the Engine for execution
![The Microtask gets picked up by the Event Loop and gives its callback to the Engine for execution](https://cyberlab-website-images.s3.eu-central-1.amazonaws.com/Event_Loop_b0c81298c6.png)

With this asynchronous approach, we do not wait for the Engine to do the [API ](https://aws.amazon.com/what-is/api/#:~:text=API%20stands%20for%20Application%20Programming,other%20using%20requests%20and%20responses.)call, instead, we delegate that job to the Networking API by calling the ***fetch*** function which also returns the promise. By doing that, we relieve the Engine and enable it to do other tasks like render the page, etc. After the promise either resolves or rejects, we can continue to execute our logic which happens after the API call in then and catch functions.

## Conclusion

When I first started learning Javascript and found out that it is a single-threaded language, I couldn't understand how it can be used to build responsive web applications with so many things happening at the same time. The answer to my question was The Event Loop, along with [API](https://aws.amazon.com/what-is/api/#:~:text=API%20stands%20for%20Application%20Programming,other%20using%20requests%20and%20responses.)s and Queues and their cooperation and coordination orchestrated by the Javascript Runtime Environment which I hope you understand now. See you in the [next blog](https://cyberlab.rs/blog) post with a new topic!


We're Wired In.
Latest news.

ECS Managed Daemons:

The DaemonSet Equivalent ECS Was Always Missing

Running for Neda:

The Story Behind CYBERLAB's 1,237km

How AI Is Changing the Way We Write Code:

Insights from a Community Talk on Claude Code and AI-Assisted Development

Claude Code 101:

From Zero to Full Potential

CYBERLAB Achieves:

AWS Select Tier Services Partner Status

New Year’s Charity Pub Quiz:

Supporting Minja, Strahinja, and Vukašin

Kubernetes Development:

Building with Skaffold

Database Paradigms:

Are You Using the Right One?

JavaScript Event Loop:

The Key to Faster Apps

ELEVATE
YOUR
CLOUD.

We're Wired In. Latest news.

ECS Managed Daemons:

The DaemonSet Equivalent ECS Was Always Missing

Running for Neda:

The Story Behind CYBERLAB's 1,237km

How AI Is Changing the Way We Write Code:

Insights from a Community Talk on Claude Code and AI-Assisted Development

Claude Code 101:

From Zero to Full Potential

CYBERLAB Achieves:

AWS Select Tier Services Partner Status

New Year’s Charity Pub Quiz:

Supporting Minja, Strahinja, and Vukašin

Kubernetes Development:

Building with Skaffold

Database Paradigms:

Are You Using the Right One?

JavaScript Event Loop:

The Key to Faster Apps

ELEVATE YOUR CLOUD.

We're Wired In.
Latest news.

ELEVATE
YOUR
CLOUD.