DEV Community: Sayan Mondal

LitmusChaos is Heading to KubeCon + CloudNativeCon Europe 2025 – Join the Chaos!

Sayan Mondal — Wed, 26 Mar 2025 05:39:15 +0000

March 26, 2025
Project post by Sayan Mondal, Community Manager, LitmusChaos

The cloud native community is gearing up for one of the most anticipated events of the year, KubeCon + CloudNativeCon Europe 2025, happening in the vibrant city of London from April 1 - 4, 2025. And guess what? LitmusChaos is back and thrilled to be part of the action once again!

No matter if you’ve been doing chaos engineering for a while or you’re just starting to explore the world of reliability, we’re excited to connect with you. We’ve got some fun and insightful talks lined up, hands-on demos at our booth, and lots of conversations waiting to happen. Here’s a sneak peek at what LitmusChaos has planned for KubeCon EU 2025

🔥 Chaos Talks You Won’t Want to Miss

We’re excited to be part of the conference schedule with two impactful sessions that dive deep into chaos engineering and reliability practices in cloud native ecosystems.

Lightning Talk: Project Lightning Talk: Chaos Unleashed: LitmusChaos and Its Journey Towards CNCF Graduation - Vedant Shrotria, Maintainer 🗓 Tuesday April 1, 2025 🕐 14:22 - 14:27 BST 📍 Platinum Suite | Level 3

Join us to explore the essence of LitmusChaos and its roadmap to becoming a CNCF Graduated project

Session Talk: Driving Chaos Engineering Forward: What’s New and Next With LitmusChaos - Sarthak Jain & Saranya Jena, Harness 🗓 Thursday, April 3, 2025 🕐 16:00 - 16:30 BST 📍 Level 3 | ICC Capital Suite 7-9

Explore the latest advancements in chaos engineering for cloud-native systems. This session will cover key updates from recent releases, including enhanced resilience testing, observability, and scalability features, while showcasing how they address real-world challenges faced by Developers and SREs.

📍 Visit Us at the LitmusChaos Booth

Want to get hands-on with chaos engineering? Come meet the maintainers, explore live demos, and learn how LitmusChaos can integrate into your SRE and platform engineering workflows.

Booth Details:

Kiosk Number: 10A
Location: Excel London | Level 1 | North Hall | Entrance N8-N9
Project Pavilion Hours (BST):

Wednesday, April 2: 15:30 – 19:45
Thursday, April 3: 14:00 – 17:00
Friday, April 4: 12:30 – 14:00

We’ll be showcasing new features, running live chaos experiments, and walking through use cases from real production environments. If you’ve been curious about how chaos fits into GitOps, platform engineering, or if you even need an additional layer in your reliability journey, this is the place to be.

🤝 Project Engagement Opportunities

There are multiple ways you can engage with us at KubeCon EU with the latest project engagement opportunities for the community as well as for projects.

☕ Meet us at the Project Pavilion Lounge

The Project Pavilion Lounge, situated at the heart of the Pavilion, offers projects and attendees a retreat for unwinding and networking in a laid-back environment. Come chat with us at booth 10A, where the chaos engineers will be hanging.

☕ Let’s Chat at Coffee Stations:

Coffee stations will be conveniently located on both sides of the Pavilion, offering a refreshing array of hot beverages to energize and invigorate attendees throughout the event.

📍 Ad-Hoc Meeting Tables:

Adjacent to the Project Pavilion, designated tables will be available for projects interested in hosting impromptu on-site meetings. These tables operate on a first-come, first-served basis, providing projects and event attendees the opportunity to convene and collaborate throughout the duration of the week.

Want to plan a quick sync or deep-dive chat with us during the event? Drop a note at sayan.mondal@harness.io and we’ll make sure we catch up at KubeCon EU 2025!

🚀 Come Along and Learn More About Chaos Engineering

Here’s your opportunity to meet the LitmusChaos team, grab some cool LitmusChaos stickers, and ask questions in person. Whether you’re a Chaos Engineering expert, user, enthusiast, or just getting started, the LitmusChaos community is here to help you get the most out of your reliability journey.

At our booth, you’ll get guidance on:

Getting Started with Chaos Engineering
Getting Started with LitmusChaos
Learning more about Chaos Engineering adoption
Questions on LitmusChaos (blockers, doubts, next steps, choosing the right experiments)
Latest updates and enhancements in LitmusChaos
LitmusChaos Roadmap
Participating in the LitmusChaos community
Becoming a contributor or a future maintainer

🌐 Stay Connected with LitmusChaos

Whether you're attending KubeCon EU 2025 or following the updates from afar, there are plenty of ways to stay connected and be part of the LitmusChaos community.

We’re an open, welcoming space for chaos engineering enthusiasts, platform engineers, reliability folks, contributors, or anyone simply curious to learn more about building resilient systems. And we’d love to have you join us!

Here’s how you can get involved:

💻 Visit the LitmusChaos website to learn about the project, use cases, architecture, and everything chaos engineering.
💬 Join the conversation on the #litmus channel in the Kubernetes Slack, ask questions, share ideas, or just hang out with the community.
🛠 Contribute to the project! Check out our Contributing Guide and start with an issue, suggestion, or PR — every contribution counts.
📺 Subscribe to the LitmusChaos YouTube Channel for community meetings, demos, tutorials, and project updates.
🐦 Follow @LitmusChaos on Twitter/X or @litmuschaos on LinkedIn for the latest news, release updates, and community shoutouts.
✍️ Explore the LitmusChaos blog for stories, tutorials, and deep dives. Want to share your own experience with Litmus? Publish a blog on DEV.to and tag it with #litmuschaos, we’d love to read it!

See you in London!

Streamlined Incident Management in a Cloud Native World

Sayan Mondal — Fri, 07 Feb 2025 05:34:17 +0000

Incidents happen. Whether you're running a small startup or managing a large-scale cloud-native infrastructure, downtime, bugs, and unexpected issues are inevitable. The real challenge isn't just fixing the problem—it's managing the chaos that ensues when things go wrong. Who’s on call? How do you notify the right people? How do you ensure everyone is on the same page? These are the questions that keep engineers up at night.

That’s where having a consistent and well-structured incident management approach comes into play. But with so many solutions and frameworks out there, it can be tricky to settle on one that feels right for your organization. This blog aims to unravel why a specialized incident management tool can make life easier for every team—dev, ops, and beyond, when the pressure is on.

The Challenge of Modern Incident Management

Modern distributed systems are complex. There’s the interplay of microservices, container platforms, and a host of monitoring and logging tools. When something goes off the rails, the immediate questions usually revolve around:

How do we alert the right people in real time?
How do we gather all the context needed to quickly understand what went wrong?
How do we keep everyone in the loop without overwhelming them with noise?

A single issue can cascade across multiple services, teams, and even time zones. Traditional incident management tools often fall short in these environments because they weren’t built with cloud-native architectures in mind.

Here’s what typically happens during an incident:

Detection: Something goes wrong. Maybe it’s a spike in error rates, a failed deployment, or a sudden drop in traffic.
Notification: Someone (or something) needs to alert the right people. But who’s on call? Are they even awake?
Coordination: Once the team is alerted, they need to collaborate to diagnose and fix the issue. This often involves jumping between Slack, monitoring tools, and runbooks.
Resolution: Finally, the issue is resolved, but the work isn’t over. You need to document what happened, why it happened, and how to prevent it in the future.

This process can be messy, time-consuming, and stressful—especially when you’re dealing with a production outage at 3 a.m.

A typical approach might involve rummaging through multiple dashboards, scouring logs, or manually pinging team members. While this can work, it’s chaotic enough to slow you down, sometimes with real consequences for customers.

Why an Open Source Incident Management Tool?

Open source software provides the flexibility to mold the tool to your exact needs and integrate with your existing workflows. In many cloud native organizations, open source is the backbone of daily operations—think Kubernetes, Prometheus, and Grafana. Adding an open source incident management layer not only aligns with your existing ecosystem but also fosters community-driven improvements and transparency.

RespondNow is an open source project that offers a straightforward way to handle incidents in modern environments. It integrates neatly with the tools you’re already using, like Slack for communication, and it provides a central place to track what’s going on during an incident.

The neat part? RespondNow is designed with cloud native ecosystems in mind, from its container-friendly setup to streamlined Slack integrations. Think of it as a dedicated incident cockpit. Teams get to rally around issues quickly, gather relevant details, and manage resolution steps without rummaging through separate tools.

The Solution

RespondNow is an open-source incident management tool designed specifically for cloud-native environments. It integrates seamlessly with Slack, Kubernetes, and other tools you’re already using, making it easier to detect, notify, and resolve incidents.

Here’s how it works:

Slack Integration: RespondNow uses Slack as its primary interface. When an incident is detected, it creates a dedicated Slack channel, notifies the right people, and provides a centralized place for collaboration.
Kubernetes Integration: RespondNow can be deployed in your Kubernetes cluster using Helm, making it easy to manage and scale.
Incident Portal: RespondNow provides a web-based portal where you can track the status of ongoing incidents, view historical data, and generate post-mortem reports.

The best part? RespondNow is open source, so you can customize it to fit your team’s workflow and integrate it with the tools you already use.

Getting Started with RespondNow

Now that you know why RespondNow exists and what it can do, let’s dive into how to set it up. We’ll walk you through the key steps to get RespondNow up and running in your environment.

Step 1: Prerequisites

Before you start, make sure you have the following:

A Kubernetes cluster (if you don’t have one, you can use Minikube or Kind for local testing).
Helm installed on your local machine.
A Slack workspace where you have permission to create apps.

Step 2: Create a Slack App with an App Manifest

RespondNow uses Slack as its primary interface, so the next step is to create a Slack app. This might sound intimidating, but it’s actually pretty straightforward.

Click here to create a slack app
Choose option to create an app from a manifest
Select the desired slack workspace from the drop-down menu and click Next
Paste the RespondNow manifest configuration and click Next
Review and verify that the configuration you entered matches the summary and click Create
In the Settings -> Basic Information screen for the created app, generate an App Level Token with the right scope (shown in the screenshot below) by clicking on Generate Token and Scopes. Save all the app tokens and OAuth Tokens to be used later.

Once the app is created, you’ll need to install it in your workspace.

Step 3: Deploy RespondNow with Helm

With your Slack app ready, it’s time to deploy RespondNow to your Kubernetes cluster. Helm is the easiest way to do this, as it handles all the dependencies and configuration for you.

Add the RespondNow Helm Repository

helm repo add respondnow https://respondnow.github.io/respondnow-helm
helm repo update

Install RespondNow server by providing the slack App and Bot tokens noted in the previous steps

helm install respondnow respondnow/respondnow --namespace=respondnow --create-namespace --set server.configMap.data.ENABLE_SLACK_CLIENT=true --set server.configMap.data.INCIDENT_CHANNEL_ID="respond-now" --set server.secret.data.SLACK_APP_TOKEN="FILL-YOUR-SLACK-APP-TOKEN" --set server.secret.data.SLACK_BOT_TOKEN="FILL-YOUR-SLACK-BOT-TOKEN"

Verify that all pods in the respondnow namespace are up and running successfully

Step 4: Verify the RespondNow Portal

Once RespondNow is deployed, you’ll want to make sure everything is working as expected. The RespondNow portal is where you’ll track incidents, view historical data, and generate post-mortem reports.

Access the portal by navigating to the URL provided during the Helm deployment.
Verify that you can see the portal and that it’s connected to your Slack workspace.

Don’t worry if this sounds like a lot, RespondNow’s documentation walks you through every step of the process.

Why RespondNow?

At this point, you might be wondering why you should use RespondNow instead of another incident management tool. The answer is simple: RespondNow is designed for cloud-native environments. It’s lightweight, easy to deploy, and integrates seamlessly with the tools you’re already using.

But more importantly, RespondNow is open source. That means you can customize it to fit your team’s workflow, contribute back to the project, and be part of a growing community of engineers who are rethinking how we handle incidents.

Wrapping Up

Incidents are a fact of life in the cloud-native world, but they don’t have to be a nightmare. With RespondNow, you can streamline the process of detecting, notifying, and resolving incidents, so you can focus on what really matters—building great software.

Ready to get started? Check out the RespondNow documentation and join the community on Slack and star our repository to support us. And if you have any questions or feedback, don’t hesitate to reach out. After all, the best tools are the ones that evolve with their users.

Happy incident managing! 🚀

LitmusChaos is joining Kubecon + CloudNativeCon North America 2024!

Sayan Mondal — Tue, 05 Nov 2024 12:10:29 +0000

Hello LitmusChaos Community! 👋

Over the past few years, LitmusChaos has evolved tremendously, becoming a leading open-source tool for Chaos Engineering within the Cloud Native ecosystem. It's been inspiring to watch our community grow, from engineers just getting started with chaos testing to large teams running complex fault scenarios across cloud and on-prem environments.

On behalf of the maintainers, we’re deeply grateful for the energy and passion each of you brings to the project. Your contributions, ideas, and feedback have fueled LitmusChaos' growth and helped tackle real-world resilience challenges in a collaborative, open-source environment. Whether it’s through insightful discussions in our Slack channels, pull requests on GitHub, or your experiences shared at events, it’s clear we’re building something special—together!

Our maintainers and contributors will be on-site, eager to meet with attendees, discuss how to get started with LitmusChaos, answer questions, and share opportunities to contribute to the project. We invite you to stop by, say hello, and learn more about how chaos engineering is transforming modern cloud-native applications.

Where to Find Us: Project Pavilion Kiosk #16A

Location: Level 1 | Halls A-C + 1-5 | Project Pavilion (Hall 1)

Kiosk: #16A

Shift: Half-shift AM schedule

Project Pavilion Hours:

Wednesday, November 13: 10:45 AM – 3:15 PM
Thursday, November 14: 10:30 AM – 1:45 PM
Friday, November 15: 10:30 AM – 12:30 PM

Our team will be at the Project Pavilion ready to talk chaos engineering, share resources, and hand out some awesome LitmusChaos stickers, candies and more. No matter your experience level—whether you’re an expert or just beginning to explore chaos engineering—this is the perfect opportunity to get personalized guidance and learn best practices for using LitmusChaos.

Project Engagement Opportunities at KubeCon NA

There are plenty of ways to connect with us beyond our kiosk! Here’s where you can find us around the venue:

Project Pavilion Lounge: Located in the heart of the Pavilion, the Lounge is a welcoming spot to relax, network, and have insightful discussions with other community members in a casual setting.
Coffee Stations: Fuel up and chat with us at the coffee stations on both sides of the Pavilion. Grab a coffee, and let’s discuss your ideas for chaos engineering!
Ad-Hoc Meeting Tables: Need more time to dive deeper into LitmusChaos? Ad-hoc meeting tables are available next to the Project Pavilion on a first-come, first-served basis, offering a chance for impromptu discussions.

If you’d like to set up a specific time to meet with us, please feel free to email matthew.schillerstrom@harness.io or sayan.mondal@harness.io, we’d love to connect at KubeCon NA 2024!

What You Can Learn at the LitmusChaos Booth

Our booth offers a hands-on opportunity to dive into chaos engineering, ask questions, and explore the latest developments in LitmusChaos. Here are some highlights:

Getting Started with Chaos Engineering
Introduction to LitmusChaos: First Steps & Best Practices
Adopting Chaos Engineering at Scale
Solving Challenges & Troubleshooting with LitmusChaos
Latest Updates and Enhancements in LitmusChaos
Roadmap for LitmusChaos
How to Get Involved as a Contributor or Future Maintainer

Whether you’re facing blockers, looking for experiment guidance, or curious about the project roadmap, our team is here to help you make the most of chaos engineering with LitmusChaos.

Connect with LitmusChaos Year-Round

Can’t make it to KubeCon NA 2024? You can still stay connected with the LitmusChaos community:

Website: Visit the LitmusChaos Website for the latest resources.
Slack: Join the conversation on #litmus in the Kubernetes Slack to learn, ask questions, and contribute.
Contributing Guide: Get started as a contributor by checking out our Contributing Guide.
YouTube: Subscribe to the LitmusChaos YouTube Channel for the latest demos and tutorials.
Twitter: Stay updated by following @LitmusChaos on Twitter.
LinkedIn: Connect with @litmuschaos on LinkedIn for latest updates.
DEV.to: Share your insights on DEV.to with #litmuschaos, or check out community-written blogs to learn from other contributors.

The What, Why and How of JavaScript bundlers

Sayan Mondal — Fri, 13 Oct 2023 11:38:15 +0000

What is a JavaScript bundler anyway?

A tool people struggle with for hours just to get a basic web app setup? A thing that you use when you bootstrap your React project? Something that your company uses, or that your colleagues/seniors have configured already, which is apparently supposed to optimize your final JS build?

Whether you are starting your web development journey or have already used a bunch of bundlers before, you might have had these questions at some point in time, I certainly did.

To answer the above question, a module bundler provides a method for arranging and merging multiple JavaScript files into a unified single file. Using a JavaScript bundler becomes necessary when your project outgrows a single file or when dealing with libraries with numerous dependencies. As a result, the end-user's browser or client doesn't have to fetch numerous files individually.

In this blog post, we'll go through what bundlers do and how they work in detail, but before that, why do we even need to combine dependencies into a single file? Let's have a look.

The Problem
How bundlers bundle
Bundlers are not transpilers

The Problem

To understand the core problem, let's consider a very simple traditional web app, with HTML, CSS and a script tag injecting an index.js which acts as the entry point for JavaScript. To add some styling we're also injecting some external UI library like Pico CSS via a CDN and linking the same.



<html>  
  <head>
    <script type="module" src="index.js"></script>
    <link
      rel="stylesheet"
      href="https://cdn.jsdelivr.net/npm/@picocss/pico@1/css/pico.min.css"
    />

    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Very Simple Traditional App</title>
  </head>
  <body>
    <button id="redirect-page-btn">Redirect</button>
    <button id="say-hello">Say Hi</button>
  </body>
</html>

Now we'll obviously not chunk all our JavaScript in a single index.js file rather we'd divide our functionalities into individual files (as and when required). For this example, we'll create an alert and one redirect function in alert.js and redirect.js respectively.



// redirect.js

export function Redirect() {
  window.location = "https://exampleURL.com/";
}

export function RandomFunction1() {
  // This is an unused function
}



// alert.js

export function SayHi() {
  alert("Hello Dev.to community");
}

export function RandomFunction2() {
  // This is an unused function
}

In the two files above we have two unused functions RandomFunction1 and RandomFunction2, which we'll get to in a moment but for now, let them hang out there.

Next, let's import the functions we created in index.js and add some interactivity to the HTML elements.



// index.js
import { Redirect } from "./redirect.js";
import { SayHi } from "./alert.js";

document
  .getElementById("redirect-page-btn")
  .addEventListener("click", Redirect);

document.getElementById("say-hello").addEventListener("click", SayHi);

So far our application looks something like this, check the network tab closely, you'd find all the JS chunks referenced/loaded separately.

Unfortunately, it loads the whole script along with all the functions that aren't even in use, i.e. RandomFunction1 and RandomFunction2.

When you consider libraries/packages that you import in your regular application like Loadash, Math, etc where you require just one or two functions for a specific use-case, you can understand the amount of unnecessary network requests it'd make to fetch every single file along with fetching everything your page doesn't need. Here’s where a JavaScript bundler comes into the field.

How bundlers bundle

Circling back to our discussion on bundlers and their pivotal role in modern web development, let's explore the inner workings of these tools in handling dependencies. Essentially, a bundler's operation can be broken down into two primary stages: generating a dependency graph and subsequently bundling the required elements.

Mapping a Dependency Graph

The initial step in module bundling involves creating a map that outlines the relationships among all the served files, known as Dependency Resolution. To do this, the bundler requires an entry file which should ideally be your main file. It then parses through this entry file to understand its dependencies.

Subsequently, the bundler navigates through these dependencies, tracing further dependencies if any, and allocates distinct IDs to every encountered file. Finally, it extracts all dependencies and generates a dependency graph that depicts the relationship between all files.

Why make a simple process so complicated? Good question

When a browser requests functions from the bundler it can easily return the requested function because of the already constructed dependency order.
Since JS bundlers have a good source map of all the files and their dependencies, it prevents name conflicts.
It detects unused files allowing you to get rid of them if you choose.

Bundling

Once the bundler gets all the necessary inputs and sorts out its dependencies in the Dependency Resolution phase, it starts preparing the assets that the browser can handle without any hitch. This preparation stage is what we call Packing. In this step, the bundler cleverly uses the dependency graph to blend our numerous code files, plug in the needed functions and module.exports object, and whip up a neat and tidy bundle that the browser will happily load up.

Bundlers are not transpilers

Firstly, let's clarify their roles. A JavaScript bundler is a tool that helps manage and organize JavaScript code and its dependencies, combining multiple files into a single, efficient bundle that can be easily loaded by the browser. The goal is to minimize HTTP requests and improve page load performance. On the other hand, a transpiler, short for "transformation compiler," is a tool that converts source code written in one programming language (such as ES6+ JavaScript) into another, usually older or more widely supported version (like ES5 JavaScript), making it compatible with a broader range of browsers.

These tools take a bunch of code in one language, and 'compile' it to another language. They're called commonly 'transpilers' rather than 'compilers' because unlike traditional compilers, these tools don't compile to a lower-level representation; they're just different languages at a similar level of abstraction.

These are typically used to run code written against newer JS versions in older JS runtimes (eg. Babel) or to provide custom languages with more conveniences or constraints that can then be executed in any regular JS environment (TypeScript, CoffeeScript).

Conclusion

Lately, developers have come up with some impressive alternatives to JavaScript bundling. I suggest keeping an eye on these options, as webpack is no longer the only go-to choice. Although webpack remains prominent, especially in tools like Create React App (CRA), which is a common approach for starting new React projects, there's flexibility to explore other options.

I recommend giving Parcel, esbuild, and ViteJS a look. These are modern bundlers designed, among other things, to alleviate certain challenges associated with webpack.

That’s all that you need to know about JavaScript bundlers to be able to work with them and understand what’s happening when executing this magic npm run build script

React just got awesome'er!

Sayan Mondal — Fri, 21 Oct 2022 10:31:05 +0000

TL;DR -- React introduced the use hook and converted all its components into server first, which suspends your components until the promise/s has been resolved resulting in a much cleaner UI and no janky loading states.

If you've ever worked on a React or Next.js application, you've probably noticed that it's pretty un-opinionated in general, particularly when it comes to dealing with asynchronous behaviours. However, the initial Server Components proposal made it difficult to access promise-based APIs.

React has finally acknowledged that async is an important part of developing applications on the web. Instead of having multiple useEffects or useSWRs and a ginormous loading hell, React finally decided to provide a seamless integration to resolve promises by wrapping them in special bindings. Which is exactly what this article tends to talk about. So sit tight and lets get reacting!

Proposal

Adds first class support for reading the result of a JavaScript Promise using Suspense:

Introduces support for async/await in Server Components. Write Server Components using standard JavaScript await syntax by defining your component as an async function.
Introduces the use Hook. Like await, use unwraps the value of a promise, but it can be used inside normal components and Hooks, including on the client.

Read the full proposal here: First class support for promises and async/await

What does this mean for us?

In a typical React application we would have components that are dependent on some data to be fetched and while that is done we usually go with a loading state which renders a spinner while our promise isn't resolved, the child components also might have their own data fetching which would also require to be resolved, and thus a very janky UI.

Within React, we can leverage Suspense boundaries and have a tree of components that are all calling data, which needs to resolve promises at individual levels. We can just suspend at the top and let all of the promises below it resolve themselves, resulting in no more interruptions or flaky loading states.

With a significant change like this, React also announced that all its components are now server first by default until you choose for it to not be. You might be thinking now, what about react-query our good old friend, well it helps us remove redundant local states we no longer need by leveraging API states instead, but it also returns a loading state, which no matter how optimised still doesn't keep us from defining the endpoint on the server.

The old vanilla way

// Vanilla.tsx

interface IData {
  author: string;
}

const getData = async () => {
  return await fetch("/api/endpoint").then(res => res.json());
}

const Vanilla: React.FC = () => {
  // Old way of maintaining a state to update it once the data is fetched
  const [data, setData] = React.useState<IData | undefined>()

  React.useEffect(() => {
    getData().then(data => setData(data))
  }, [])

  // Check if data is undefined then handle loading state
  if(!data) return <Spinner>Loading...</Spinner>

  return (
    <div>
      Data has been rendered: {data?.author}
    </div>
  )

}

A better way

// ReactQueryWay.tsx

const getData = async () => {
  return await fetch("/api/endpoint").then(res => res.json());
}

const Better: React.FC = () => {
  // No more local state to maintain the data, instead use API states
  const {data: fetchedData, loading} = useQuery(["example"], getData)

  // Check if loading is true then handle loading state
  if(loading) return <Spinner>Loading...</Spinner>

  return (
    <div>
      Data has been rendered: {data?.author}
    </div>
  )

}

The proposed way

// TheUseWay.tsx

// Making the component async and turning it into a server component
const Current: React.FC = async () => {

  const data = use(await fetch("/api/endpoint").then(res => res.json()));

  // We don't need to check for loading anymore because the state is defined, the `use` hook would suspend the component altogether till the data is not returned
  return (
    <div>
      Data has been rendered: {data.author}
    </div>
  )

}

Conclusion

If I missed out on any point or you want to discuss something feel free to leave a comment down below, I'd hop in ASAP. 🌟

Lastly, Thank you for making it this far down into the article and showing your interest in React. You are amazing and keep making a positive difference every day. Peace out. ✌🏼

Free alternatives to Heroku

Sayan Mondal — Thu, 08 Sep 2022 03:58:47 +0000

Heroku has long been the go-to cloud Platform-as-a-Service (PaaS) for scalable app deployment and management. It saves developers the bother of setting up servers and supporting infrastructure by offering a subscription-based cloud-based managed environment.

Despite its popularity, Heroku just announced that it will discontinue all free services, forcing users to upgrade to premium subscriptions. Beginning November 28, the Salesforce-owned cloud platform as a service will discontinue free product plans and shut down free data services, and it will soon (on October 26) begin removing dormant accounts and related storage for accounts that have been idle for more than a year.

This may no longer be an ideal option for students and hosting hobby projects, therefore be prepared with other good alternatives to Heroku.

Various PaaS companies have attempted to compete with Heroku, and some have succeeded. In this article, we'll take a look at some alternatives which are a close match to the former.

Railway

Railway is an infrastructure platform that allows you to provision infrastructure, develop with it locally, and then deploy it to the cloud. 1GB Disk, 512 MB RAM, $5 limit, or 500 hours of free usage per month.

Link: railway.app

Fly.io

Fly is a platform for globally distributed applications. It executes your code close to users and scales computation in cities where your programme is most popular. Write your code, package it as a Docker image, deploy it to Fly's platform, and let it do the rest to keep your app running smoothly. Free for side projects, $10 per month in service credit that applies to any paid service. Credits will also go a long way if you run very small virtual machines.

Link: fly.io

Deno Deploy

Globally distributed system that runs JavaScript, TypeScript, and WebAssembly at the edge. The free tier includes 100,000 daily requests and 100 GiB of data transmission each month.

Link: deno.com/deploy

Koyeb

Koyeb is a developer-friendly serverless platform for worldwide app deployment. With git-based deployment, native autoscaling, a global edge network, and built-in service mesh and discovery, you can host Docker containers, web apps, and APIs with ease. With its forever-free tier, Koyeb offers two nano services to operate your apps and also sponsors open-source projects with free resources.

Link: koyeb.com

Napkin

Instantly create and deploy serverless cloud operations from the browser. Easily add API authentication, schedule tasks, and replay events. A FaaS with 1Gb of memory, a default timeout of 15 seconds and 1,000,000 free API calls/month.

Link: napkin.io

Deta

Get your Python and Node.js apps and APIs online in seconds. Unlike Heroku, which lets you to operate up to two free dynos, Deta allows you to construct an unlimited number of micros. The size of your application's source code and dependencies, however, cannot exceed 250MB. Deta is forever free.

Link: deta.sh

Meteor Cloud

Galaxy hosting. Meteor's platform-as-a-service for Meteor apps, with free MongoDB Shared Hosting and automated SSL. Build, monitor and host your application on the only platform designed with your Meteor app in mind.

Link: meteor.com

Conclusion

That's all folks 👨‍🏫, Thank you for making it this far down. All the resources mentioned are not just the only resources available, I'm sure there must be tons of other amazing project out there too. These are the ones that I really found helpful and often get myself indulged into. 👨🏻‍💻 Peace out ✌🏼

Understanding React Higher Order Component (HOC)

Sayan Mondal — Sun, 08 May 2022 16:52:58 +0000

Almost everything about using a SPA library influences you to abstract the business logic and write quality code. React has been enforcing such quality controls for the last few years using a variety of amazing design patterns and we are no strangers to that!

In this article, we'll discuss one such addition to the quality control mechanism of React using Higher Order Components. By the end of this article, you should be confident and ready to tackle/improve a codebase by using this principle whenever necessary.

What is a Higher Order Component?

Higher Order Components is a great pattern that has proven to be very valuable for several React libraries. According to the official documentation of React -

A higher-order component (HOC) is an advanced technique in React for reusing component logic. HOCs are not part of the React API, per se. They are a pattern that emerges from React's compositional nature.

JavaScript is a well-suited language for functional programming as it can accept higher-order functions. A higher-order function is a function that can take another function as an argument and/or that returns a function as a result.

Higher-order functions allow us to abstract over actions, not just values. With HOCs we can wrap over our child component and either add business logic on top of it or extend the abilities of the child component itself.

What can I do with HOCs?

At a high-level HOC enables you to:

Reuse code, reuse logic, and bootstrap abstraction
Render Highjacking
State abstraction and manipulation
Props manipulation

Third-party React libraries, such as Redux or React Router, frequently use HOCs. I'm sure you've used some of them without even realising it.

In React, the main purpose of a higher-order component is to share common functionality between components without having to repeat code.

Types of HOCs

The two main ways of implementing HOCs in React are:

Props Proxy (PP)
Inheritance Inversion (II)

Both enable different ways of manipulating the WrappedComponent. Both are simply a function, that takes a Component as an argument and produces a new component containing the WrappedComponent.

Props Proxy

Props Proxy, as the name suggests, passes properties received from Higher-Order Component.

The crucial element here is that the HOC's render method returns a React Element of the WrappedComponent's type. The HOC receives what we pass through the props, hence the name props proxy. The HOC returns a React Element that describes what React should render in its reconciliation process.

You can also wrap the Wrapped Component with other JSX elements changing its UI according to your app needs.

Props Proxy HOCs are useful in the following situations:

Manipulating props
Accessing the instance via Refs
Abstracting State
Wrapping/Composing the WrappedComponent with other elements

Inheritance Inversion

This HOC can gain access to WrappedComponents instances. This provides us with access to the state, props, component lifecycle hooks, and the render method.

The returned HOC class (Enhancer) extends the WrappedComponent, as you can see. It's termed Inheritance Inversion because, instead of the WrappedComponent extending some Enhancer class, the Enhancer passively extends it. In this way, their relationship appears reversed.

Inversion Inheritance HOCs are useful for the following situations:

Render Highjacking
Manipulating state

Let's dive into some examples

To get a solid grip on the fundamentals we've learned, let's take an example of an application that has a single input that takes a name and changes the name.

Imagine we have a scenario where our business application requires lots of form validation and different use cases have different input validations, in such a case rather than duplication code and making multiple input forms with use case-based components, we can abstract it into a HOC which takes an input field or a little more of your child component and manipulates the states as well as the actions (validations, etc) and wraps your child component with the necessary business logic for each use case.

Consider the example below -

Here we have made Form as the child component which is being wrapped around the withHandlers HOC. It gives the child component its own freedom and doesn't overcomplicate the base component with overhead logic and justifies separation of concern.

The HOC is now in control to add/remove validations and any extra actions as deemed fit by the developer.

Conclusion

This was a relatively simple example to give you an idea of how the ideas work in practice. It takes some time to become accustomed to and comfortable with this type of abstraction, so don't lose the drive or focus with HOCs.

Also once you are comfortable and want more deep and complex explanations, I'd recommend checking out this detailed blog and exploring the concepts.

If I missed out on any point or you want to discuss something feel free to leave a comment down below, I'd hop in ASAP. 🌟
Lastly, Thank you for making it this far down into the article and showing your interest in React. You are amazing and keep making a positive difference every day. Peace out. ✌🏼

How the Resilience Score Algorithm works in Litmus!

Sayan Mondal — Tue, 27 Jul 2021 11:04:34 +0000

What really is Resilience? For practitioners, psychologists, etc, Resilience is the process of adapting well in the face of adversity, trauma, tragedy, threats, or significant sources of stress, for an SRE or Chaos Engineering however Resilience can be defined as the ability of a system to fail gracefully in the face of—and eventually recover from—disruptive events.

Litmus is a Cross-Cloud Chaos Orchestration framework for practising chaos engineering in cloud-native environments. Litmus provides a chaos operator, a large set of chaos experiments on its hub, detailed documentation, and a friendly community.

Find the video format of this blog here:

In this blog, we'll deep dive into how the Resilience Score is calculated for your Workflows in Litmus and also understand the concept of Weights.

Weights in Litmus

You might have often seen the term weightage pop up quite a few times when you construct your Workflows in Litmus. Typically attached to Resilience, these weights have an important role to play to determine the appropriate Resilience score for your use case.

Giving a weightage to your experiment is a way of signifying/attaching the importance/priority of that experiment in your workflow. The higher the weight, the more importance it holds.

For instance, consider this example where you have two Chaos Experiments, Pod Delete and Pod Network Loss in your workflow. Imagine you have a use case where you cannot bear having a network loss but an eviction of a pod does not really bother you that much because you are confident that the pod would re-spawn back up, but you still want to test for pod eviction as a part of your Chaos Test Suite.

In such a scenario, the Pod Delete Chaos Experiment doesn't hold much of an importance for you but on the other hand, Pod Network Loss does.

The weight priority is generally divided into three sections:

0-3: Low Priority
4-6: Medium Priority
7-10: High Priority

Therefore considering your scenario, you would want to assign Pod Delete with a Low Priority weightage, whereas, Pod Network Loss would be in the High Priority category.

Now that we know why we set the weights the way we do! As we progress further in the blog, we'd also get to know how they actually come into play to determine the Resilience Score.

Resilience Score

A Resilience Score is the measure of how resilient your workflow is considering all the chaos experiments and their individual result points. This calculation takes into account the individual experiment weights (from a range of 1-10) which are relative to each other.

Once a weight has been assigned to the experiment, we look for the Probe Success Percentage for that experiment itself (Post Chaos) and calculate the total resilience result for that experiment as a multiplication of the weight given and the probe success percentage returned after the Chaos Run.

Total Resilience for one single experiment = (Weight Given to that experiment * Probe Success Percentage)

If an experiment doesn't have a probe in it, the probe success percentage returned can either be 0 or 100 based on the experiment verdict. If the experiment passed then it returns 100 else 0.

The Final Resilience Score is calculated by dividing the total test result by the sum of all the weights of all the experiments combined in a single workflow.

Let's take our above scenario again, considering we have given a weightage of 2 to Pod Delete and 10 for Pod Network Loss, this is how the Resilience Calculation would look like.

Considering Probe Success Percentage is 100

Here is why weights play such an important role in your use case specific Resilience Calculation. For the scenario mentioned above, even if Pod Delete would have failed for whichever reason, your Resilience Score would only drop down by a few numbers.

Resilience Score = Total Test Result / Weight Sum 
                 = (0 * 100) + (10 * 100) / 12                  
                 = 1000 / 12 
                 = 83.33%

However if they both were of the same weights, lets say 10. Then your Resilience Score would drop to 50% straight.

With that I hope you are now an expert of weights, and would use them wisely. With great power comes great responsibility.

Conclusion

That's all folks 👨‍🏫, Thank you for reading it till the end. I hope you had a productive time learning about Litmus and how you can construct your workflows with more confidence now.

Contribute to LitmusChaos and share your feedback on Github. If you like LitmusChaos, become one of the many stargazers here.

Join the LitmusChaos slack community following these simple steps!

Step 1: Join the Kubernetes slack using the following link: https://slack.k8s.io/
Step 2: Join the #litmus channel on the Kubernetes slack or use this link after joining the Kubernetes slack: https://slack.litmuschaos.io/

Looking forward to having you in our community and learning together!

SQL vs NoSQL - Which is better for you?

Sayan Mondal — Tue, 25 May 2021 14:22:57 +0000

Whether you have worked with databases, are about to work with one, or haven’t worked at all, this topic is something you should know irrespective.

You need to always think about how your data looks like first, how you are about to query it and what are your scalability requirements. Whether it's you choosing the perfect database for your personal project or it’s an organisation, It is an important decision whether to pick a relational (SQL) or non-relational (NoSQL) data structure.

This article is not about which type is better but about which type suits you for your current project requirements. Each one has clear advantages and disadvantages which must be kept in mind.

If you just want to see the key-points mentioned in this article skip directly to the end.

Now with that said, let’s get started

What is SQL?

SQL or Structured Query Language is pronounced as “S-Q-L” or sometimes as “see-quel” is a standard language to access and manipulate Relational Databases.

It gives the users the power to create queries to INSERT, DELETE, UPDATE, SEARCH, ALTER, and to do a lot more with the Database. It is a very powerful language and is preferred by lots of developers as it can handle very complex queries as well.

Common and Popular Examples of Relational Databases which use SQL are —

MySQL
Oracle
SQLite
Postgres
MS-SQL

A very Basic syntax pattern of SQL statement is —

    General--
    SELECT * FROM <TABLENAME> WHERE <ATTRIBUTE> = <VALUE>

    Practical--
    SELECT * FROM EMPLOYEE WHERE Salary > 90000

What is NoSQL?

As the name suggests NoSQL is “not” SQL, in other words, it is a non-relational database and is unstructured. Due to its unstructured nature, it is sometimes called as UnQL

It follows a database design which can take all sorts of data models. It mainly consists of key-value pairs, graphs, documents, etc. It is especially used to store large sets of distributed data.

Common and Popular Examples of NoSQL Databases are —

Mongo DB
BigTable
Cassandra
Hbase
Redis

Information may be stored in many ways in this type of unstructured databases, but a widely followed approach is to store the information in **JSON **format.

    {
      role: "employee", 
      salary: "90000"
    }

Comparing SQL vs NoSQL

Now that we have a basic understanding of what SQL and NoSQL database means, it would be much easier to compare the two types and figure out which one better suits your needs. Let’s go ahead and compare them now.

Database Structure

A SQL Database follows a table like structure which can have an unlimited number of rows and every data present inside the database is properly structured with Predefined Schemas, it is basically used to manipulate Relational Databases Management Systems.

A NoSQL Database is a Distributed Database where the data is very unstructured with Dynamic Schema. Unlike SQL it cannot have unlimited rows but it follows a **Standard Schema Definition *and can store all sorts of data models with large distributed data in the form of **key-value pairs, graph databases, documents or wide-column stores*.

Syntax

SQL is a very powerful language and is very handy when it comes to access as well as manipulate not just simple but very complex queries as well. It uses SQL syntax to define and manipulate data. An example of this syntax is —

SELECT * FROM STUDENT WHERE NAME = "Sayan" AND MARKS > 80;

Whereas in NoSQL the queries are mainly focused on the **collection of large documents *and it is not a good option to manipulate complex queries. As there are different types of NoSQL databases available therefore it *doesn’t follow a single syntax base, the syntax differs from database to database. The most commonly used format to store data is **JSON.

    {
       name:"Sayan",
       marks:"85"
    }

Hierarchy

SQL Databases are stored in the form of tables consisting of n number of rows thus it cannot follow a hierarchical approach rather all the data is present individually in each row under a specific attribute with its own significance.

Whereas NoSQL is a very good fit for hierarchical data storage as it stores the data in the form of key-value pairs in JSON format and thus serves as a better fit for large distributed data.

Scalability

A SQL Database is always vertically scalable. The meaning of this sentence is that if there is more load on the server then it can be handled by increasing the CPU, SSD, RAM, etc. This will work only on a single server. Thus by this, you may already be aware that this requires more strain on a single server.

A NoSQL Database, on the other hand, is horizontally scalable. This means that if there is excess load on the server then it will simply add a few more servers to handle the large traffic. It is simple and very efficient and prevents the server from being non-responsive.

Stability

A SQL Database is more stable and is always preferred when doing heavy duty transactions. The reason being it keeps the data very secure through data integrity and atomicity. It follows ACID Property which stands for Atomicity, Consistency, Isolation, and Durability.

Click to know more about ACID

A NoSQL Database is less stable than a SQL Database when there is high load on the server or even when performing complex transactions. It follows Brewers CAP Theorem **which stands for **Consistency, Availability, and Partition Tolerance.

Click to know more about Brewers CAP Theorem

What is the right choice for your business?

This decision completely depends on the business type and the ideation of the business. If you want to work with pre-defined structures and set schemas then SQL Databases is the correct choice for you. If you are building anything similar to an inventory monitoring system or accounting system then SQL Database is a better fit.

But if you want to build an application with dynamic schema or if your business has a very rapid growth and no schema definition then NoSQL Databases is what you need. If you cannot determine the type of schema your application wants or you want to keep it changing from time to time like in case of mobile apps, analytics or content management then NoSQL is a better fit.

Key-points in Short

Thank you for reading this. I really appreciate all the effort. If you’re having any doubts comment below and I’ll try to answer them.

Peace Out. ✌🏼

Exploring Litmus 2.0 Beta with Civo

Sayan Mondal — Thu, 29 Apr 2021 12:19:54 +0000

Have you ever had the need to execute, monitor and manage all your services in one place with minimal effort! Sounds like a dream isn't it! Well not for long. With the upcoming Litmus 2.0 we're excited to try out some groundbreaking features like GitOps, Enhanced Teaming, Workflow Visualization, Workflow Sequence Editing, adding custom templates and so much more.

Before starting this blog, do check out the previous blog on running Chaos Engineering Tests with LitmusChaos on Civo: https://www.civo.com/learn/chaos-engineering-kubernetes-litmus

In this blog, we’re going to explore how to use Civo’s amazingly fast managed k3s clusters to pick LitmusChaos app from the Civo Marketplace and set it up with no more than two clicks.

Find the technical demo with Litmus 2.0 on Civo here:

What is CIVO Cloud?

Civo is a cloud hosting platform powered by k3s which helps cloud-native developers manage and build their Kubernetes-native applications easily. The powerful k3s distribution helps you bring up a cluster in just a couple of minutes. Developers can now sign-up for Civo’s Early Launch Access as Civo comes out of their beta program, #KUBE100.

Loaded with features and with considerable focus on simplicity, speed & value for money, Civo allows agile Kubernetes development and hosts various Open Source Cloud-Native projects in its marketplace to induce various functionalities according to your needs.

One of them is LitmusChaos which can be found in the CI/CD section of the marketplace.

LitmusChaos 2.0 Advanced Beta is out!

Litmus is a toolset to do cloud-native chaos engineering. Litmus provides tools to orchestrate chaos on Kubernetes to help SREs find weaknesses in their deployments. SREs use Litmus to run chaos experiments initially in the staging environment and eventually in production to find bugs, vulnerabilities. Fixing the weaknesses leads to increased resilience of the system. Litmus takes a cloud-native approach to create, manage and monitor chaos.

With the launch of Litmus Chaos 2.0 Advanced Beta, a new way of chaos engineering can be performed by the users, capturing a few high-level features. A detailed list can be found on the release page

Chaos experiments become building blocks of a ChaosWorkflow, to allow users to create a larger chaos scenario using sequential or parallel experiment execution.
A cross-cloud control plane has been built which can be used to
- Predefined workflow for easy onboarding.
- Construct a custom workflow from a UI interface for both parallel and sequential workflow from both public or private hub.
- Orchestrate chaos workflow across K8S agents(clusters) from a single control plane.
- Centrally visualize the chaos workflows, get chaos analytics and compare the same.
- Get the teaming in place for collaboration of chaos workflows.
- Agents can work in namespace scope or cluster scope.
Chaos workflow can be stored in Git
Chaos GitOps for highly scalable automation of chaos workflows. Chaos can now be triggered as a result of a change to an application. This integrates with other CD tools like ArgoCD and FluxCD
Chaos Interleaved dashboards. A step toward open observability that is interleaved with chaos incident details.

Litmus itself is composed of microservices. And we made sure that by adding the above features for 2.0, seamlessly integrates the additional microservices in conjunction with the existing one. Litmus 2.0 is completely backwards compatible. No features are deprecated. The migration path is about constructing new artifacts such as ChaosWorkflows that include the current chaos experiments in use by the users.

Prerequisites

A Kubernetes cluster you control. We'll take advantage of Civo's super-fast managed k3s service to experiment with this quickly. If you don't yet have an account, sign up to join Civo Cloud now as it is production ready & open for business. Join Civo as its early access launch comes out on the 4th of May!

Alternatively, you could also use any other Kubernetes cluster.

kubectl installed, and the kubeconfig file for your cluster downloaded.

Installing Litmus 2.0 Beta on Civo

To ensure Litmus runs perfectly in sync with your cluster, make sure you have installed Helm from the Civo marketplace along with Litmus since Litmus 2.0 is dependent on Helm for pulling the updated chaos charts.

Once you click on Create all you have to do is sit back and relax for 80 seconds while Civo creates the cluster at jet speed. Once installed and you can verify if litmus is up and running in your system by viewing the pods.

$kubectl get pods -n litmus

NAME                                                READY   STATUS      RESTARTS   AGE
chaos-litmus-2-0-0-beta-frontend-7b76655b6b-s9989   1/1     Running     0          72m
chaos-litmus-2-0-0-beta-mongo-0                     1/1     Running     0          72m
chaos-litmus-2-0-0-beta-server-bc884dcc7-v6bwj      2/2     Running     1          72m

You should be able to view the front end, server as well as mongo pod successfully running in your cluster.

Accessing the Litmus Control Plane

To set up and log in to Litmus Portal expand the available services just created and copy the PORT of the frontend service.

$kubectl get svc -n litmus

NAME                            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                         AGE
litmusportal-frontend-service   NodePort    10.43.24.252    <none>        9091:31054/TCP                  81m
chaos-litmus-2-0-0-beta-mongo   ClusterIP   10.43.223.208   <none>        27017/TCP                       81m
litmusportal-server-service     NodePort    10.43.167.201   <none>        9002:32678/TCP,9003:31672/TCP   81m

From this example, we can note that the frontend port is 31054 but it’s dynamic and will be different in your case.

Once you have the PORT copied in your clipboard, simply use your NodeIP and PORT in this manner <NodeIP>:<PORT> to access the portal. To get the NodeIP of the Civo cluster in this case, visit the UI and pick up the IP of the master node from the Nodes section.

So in this case, since my master node is 212.2.240.142 and PORT is 31054. I’ll be able to access the Litmus Control Plane by visiting http://212.2.240.142:31054

You should be able to see the Login Page of Litmus. The default credentials are

Username: admin
Password: litmus

Deploying our target application

Just like an application is incomplete without Chaos Engineering, a chaos injection is incomplete without selecting a target application to inject the chaos on. In this demo, we’ll target Nginx as the target application on which we’ll apply pod-delete to terminate the application pod and check if it's resilient enough to come back up by itself.

The hypothesis of this demo experiment is to kill the application pod of Nginx and wait to see if it spawns back up by itself. To deploy Nginx on the cluster do the following.

$kubectl create deploy nginx --image nginx

This would install the Nginx deployment in the default namespace, you can also create the same in the namespace of your choice.

Creating the Pod Delete experiment through the Litmus Control Plane

Once we are able to successfully launch the Control Plane we can select the respective agent that we want to use to run the Chaos on. By default, you’ll have a Self Agent connected and we’re also going to use the same to move forward in this demo.

Since this is a custom workflow that involves adding pod-delete as an experiment, we’d focus on adding it as a part of the custom workflow and not a pre-defined one. We have two options for custom workflows -

Choosing from MyHub
Uploading a YAML

We’ve selected MyHub to ease the flow of the demo and added pod-delete from the list of generic experiments present in ChaosHub.

Once we’ve added the same in the workflow table we can click on the experiment to reveal the metadata which is tunable.

If you have installed the Nginx deployment in any other namespace or if you want to tune your experiment to set annotations to true, then this is the right place to do so. For our application, we just need to set the app label to app=nginx so that it can target the right application.

Post-editing we can schedule the workflow by verifying the information in the Verify and Commit page.

Analysing the Workflow

Post creation our workflow would be available to us where we can see the live visualization of the chaos injection. The UI would map and visualize the steps in a sequential fashion and display all the metadata and logs along with Chaos Results of the workflow nodes.

If you want more granular control over the nodes, you can switch over to Table View to get a better view of the same. Upon workflow completion, the Chaos Result of the Chaos Engine would return the verdict of the workflow which specify the score of probe success percentage, the overall verdict of the experiment, phase, and other vital information.

Conclusion

Thank you for reading it to the very end and trying out Litmus Beta on Civo! Civo is a great platform to build your Kubernetes applications! With a community of 4000+ members, the community initiative is taking centre stage while Civo comes out of Beta and gears up for the Early Access Launch!

Apply for Early Access for Civo here: https://www.civo.com/

LitmusChaos 2.0 beta is out now and we await the launch of 2.0 GA within the next few months. Are you an SRE or a Kubernetes enthusiast? Does Chaos Engineering excite you?
Contribute to LitmusChaos and share your feedback on Github. If you like LitmusChaos, become one of the many stargazers here.

Join the LitmusChaos slack community following these simple steps!

Looking forward to having you in our community and learning together!

How Litmus Orchestrates Chaos

Sayan Mondal — Sat, 27 Mar 2021 10:20:39 +0000

In this blog, we'll take a look at how Litmus Orchestrates Chaos Experiments and the individual components/resource breakdowns to get a perfect step by step understanding of how things happen behind the hood.

The Basics First

Litmus takes a cloud-native approach to create, manage and monitor chaos. Litmus orchestrates Chaos using the following Primary Kubernetes Custom Resources:

Chaos Experiment: This is a low-level definition of the Chaos Experiment itself, in this CR you'd find the different chaos parameters, the libraries used to implement chaos, the permissions associated with the particular experiment as well as some Operational characteristics like if the privileged mode is enabled, the security context of your experiment, etc. The experiment tunables like the TOTAL_CHAOS_DURATION, LIB_IMAGE, etc, is already set to a default value with the help of this CR. (The default experiment parameters are pulled from the ChaosHub)

Chaos Engine: This user-facing CR helps in binding the application instance with the ChaosExperiment. It defines the Run Policies and also holds the status of your experiment. This CR helps you customize the experiment according to your need since it can override some of the default characteristics/tunables in your experiment CR. This CR reconciles with the Chaos Operator (We'll get to more details about Chaos Operator soon, but for now think about it as a chaos generator that takes your tuned settings and applies the chaos).

Chaos Result: This resource is created by the experiment and is used to store details of the experiment run. It contains important experiment level details like the current Verdict (Awaited, Passed, Failed), the current status and the nature of the experiment results, the Chaos Engine reference, salient application/result attributes. It is also a source for metrics collection. It is updated/patched with the status of the experiment run. It is not removed as part of the default cleanup procedures to allow for extended reference.

The Run Time Flow

The first and foremost step is to install Litmus, either by directly applying the Kubernetes manifest or by doing a helm install of the litmus chart.

helm install litmuschaos  --namespace litmus ./charts/litmus-2-0-0-beta/

kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-portal/cluster-k8s-manifest.yml

NOTE: Take a look at the detailed installation instructions to have Litmus installed step by step in your system

Once Litmus has been installed in your cluster, it'd create the CRDs and the Chaos Operator as a part of the installation. Once you have the basic CRDs up and running in your cluster, you can pull your experiments from the Hub of experiments, the ChaosHub, containing 30+ experiments for you to try out.

After successfully pulling the experiment in your cluster as CRs, the ChaosEngine has to be created which binds your application instance to the chaos experiment you just pulled. This whole time, the Chaos Operator keeps a watch at the ChaosEngine and as soon as it detects a new experiment installation it spawns up a Chaos Runner which is responsible for executing the Chaos Experiment with the help of Experiment Jobs (The Jobs are spawned by the Chaos Runner based on how you have created the Chaos Engine)

These Experiment Jobs then create the Chaos Results, which are continually updated as the experiment is being executed. The Chaos Runner listens to these results and patches them to the Chaos Engine accordingly.

How the Chaos Operator works

Now at this point, we are already aware of Chaos Engine being one of the important Custom Resources in this project, but there's much more to it that just binding application instances. The Chaos Engine CR is what holds the crucial information of which is the target application to induce chaos on!

The Operator on the other hand is responsible for identifying whether the target application is existing on the cluster from the Chaos Engine (It does so with the help of app namespace and app label which is defined as a part of the Chaos Engine CRD). Once it gets confirmation that these applications are present on the cluster, it does a routine annotation check (Can be turned off as well, but in case you are someone worried about controlling the blast radius, do keep it enabled).

Next comes validating the policies/run properties that have been constructed as a part of Chaos Engine (Default as well as when modified), the Engine is what holds the service accounts which is responsible for creating the Chaos Runner and Experiment Pods (RBAC). Role Bindings are very helpful when it comes to assessing the permissions you have given for a workflow or individual experiments. It is then followed by a validation of the experiment tunables that had been overridden on added, for example, adding a new ConfigMap to push some secret to it, Overriding the default experiment parameters, pushing instance-specific data dynamically during experiment run, etc.

The operator also takes note/validates the Chaos Runner attributes as well, it checks whether the pull policy, the set of images and arguments are correct or not, it comes really handy when you are targeting infra changes.

Job Cleanup Policy

This is a tunable property of the workflow which decides whether you want to clear all the resources used for inducing chaos in your application and revert it back to the original state, or you want to retain all the resources created and use it to export metrics in your own Analytical solutions.

Monitoring

The operator is also responsible for monitoring your application state, if this tunable is set to true then the experiment metrics are monitored. The operator ensures that these metrics are collected and enables the exporter to scrape them from the Chaos Engine.

In the future releases, Litmus won't have this tunable parameter anymore, since it won't be available anymore in the Chaos Engine the users can't use this tunable from there, instead, if they don't want to collect the metrics of their workflows they have to skip the installation of the chaos-exporter.

Apart from all the above Jobs of the Chaos Operator, it also reconciles the state of the Chaos Engine and takes certain steps based on the result of the Chaos Experiment.

The Three modes of the Operator

Litmus provides certain operational modes when it comes to diversifying the range of chaos operations for different personas making it suitable for use-cases of SREs, Developers, Service Owners, etc so that they can induce chaos on their specific cluster (individual or shared).

There are three modes that the Chaos Operator supports

Standard
Admin
Namespaced

Standard - The Standard Mode is where Litmus run on a centralized namespace (typically litmus) and it watches for Chaos Engines created in the cluster in different namespaces. Mostly suited for SREs, DevOps Admins, etc.

Admin - Admin mode is one of the ways the chaos orchestration is set up in Litmus, wherein all chaos resources (i.e., install time resources like the operator, Chaos Experiment CRs, Chaos Service Account and runtime resources like Chaos Engine, Chaos Runner, etc) are set up in a single admin namespace (typically, litmus). This mode typically needs a "wider" & "stronger" ClusterRole, albeit one that is still just a superset of the individual experiment permissions. In this mode, the applications in their respective namespaces are subjected to chaos while the chaos job runs elsewhere, i.e., admin namespace.

Namespaced - This mode constraints developers to very strict environments where they are very conscious about the blast radius and the policies are set in such a way that they don't get the visibility to watch the Chaos Operators in any other namespace.

Chaos Orchestration

Now that you are aware of all the Chaos Resources and the primary details which make up the Chaos Experiment, its time to take a look at the main Orchestration. There are three main states of Chaos Orchestration namely

Initialization
Completed
Stopped

Initialization

Once the operator triggers Chaos and spawns the Chaos Runner Pod, the experiment is in the Initialization phase. The Chaos Operator is instrumented with Kubernetes Finalizers which ensures to only delete the supporting chaos resources if and only if all the child resources have been exhausted/reached a logical conclusion and your experiment have been finished.

Completed

The execution of the experiment is verified by the Chaos Runner with the help of the Chaos Result resource which then states/validates that the experiment has been completed. At this point, re-applying the Chaos Engine would repeat the same steps and the experiment would be repeated seamlessly. Depending upon your job cleanup policy the Chaos Operator might either remove or retain your experiment Pods. If you decide to remove all the Chaos Resources, the Finalizer would be removed as well.

Stopped

Once initialized, you are having second thoughts about your experiments and want to abruptly stop it in the middle! You can actually do so by either patching the Engine state to stop or delete the Chaos Engine resource completely. If you have patched the Operator then it will set the Engine Status to Stopped. If you re-apply the experiment at this point, it'll re-trigger the experiment run. As a part of this abort operation, it forcefully deletes the Chaos Pods.

Conclusion

That's all folks 👨‍🏫, Thank you for reading it till the end. I hope you had a productive time learning about Litmus and how it works internally.

Are you an SRE or a Kubernetes enthusiast? Does Chaos Engineering excite you?
Join Our Community On Slack For Detailed Discussion, Feedback & Regular Updates On Chaos Engineering For Kubernetes: https://kubernetes.slack.com/messages/CNXNB0ZTN
(#litmus channel on the Kubernetes workspace)

Check out the Litmus Chaos GitHub repo and do share your feedback: https://github.com/litmuschaos/litmus
Submit a pull request if you identify any necessary changes.

Don't forget to share these resources with someone who you think might need some help learn/explore more about Chaos Engineering. Peace out. ✌🏼

Amazing Productivity Tools for Developers

Sayan Mondal — Sat, 13 Mar 2021 11:21:02 +0000

Whenever it comes to work, whether you are casually working on your side project while sipping a cup of coffee or have intense working hours to deliver your task before the deadline, you want to know that you’re doing your best. That’s when productivity tools for developers come in handy.

In this article, I'll not mention tools like Trello, Slack, Jira, etc which are pretty widely known instead I'm going to talk about tools that are underrated and not really that famous(but definitely should be adopted more).

Keeping in mind how software developers work best, the following productivity tools for developers are recommended for individuals as well as teams.

Cold Turkey

If you blame yourself for being unable to stay away from social media or get easily distracted by AI driven notification of your favourite streamer streaming right now! Then this is the perfect application for you.

Using Cold Turkey, you can proactively restrict your access to specific desktop applications, websites, or even your access to the internet in general. You set your own schedule and daily limits for access, based on areas of weakness. RescueTime pairs nicely with this tool, in that it can help you audit major timesucks.

Find it here: https://getcoldturkey.com/

7pace

Do you follow a DevOps practice pretty often in your development cycle! I'm assuming you/your team is using Kanban or Scrum boards to manage your work already. Well, wouldn't it be convenient if you could fit a time tracker solution right into your development team's board and keep track of your activities, automate burndown reports and also manage resources and budget in large organizations! Well, then 7pace is the right solution for you.

7pace Timetracker was built specifically for software development teams that work in an Agile, Scrum, or Waterfall environment. Individuals using the tool experience an average of just three seconds to log each task. 7pace Timetracker integrates with Microsoft Team Foundation Server (TFS) and Visual Studio Team Services (VSTS) for even greater efficiency.

Even if you use GitHub project boards to manage your projects 7pace has a beta offering to integrate their time tracking solution right in.

Check it out here: https://www.7pace.com/

Time Out

Unfortunately only available for the macOS currently, Time Out definitely tops the list of the best productivity tools for programmers to organize breaks. We love it for the plain & clear interface as well as wide customization capabilities.

You can take either a short break of 15 seconds every 15 minutes or long ones for 10 minutes every hour. Thus whether you want to do a short 15 seconds eye exercise or brew your coffee in a 10 minutes break is all up to you.

Check it out here: https://apps.apple.com/us/app/time-out-break-reminders/

F.lux

During the day, computer screens look good—they're designed to look like the sun. But, at 9 PM, 10 PM, or 3 AM, you probably shouldn't be looking at the sun. If you have a bad sleeping habit like me and you're probably coding late nights! Trust me, you just might want to consider this tool.

f.lux makes your computer screen look like the room you're in, all the time. When the sun sets, it makes your computer look like your indoor lights. In the morning, it makes things look like sunlight again.

Tell f.lux what kind of lighting you have, and where you live. Then forget about it. f.lux will do the rest, automatically.

Check it out here: https://justgetflux.com/

WakaTime

This tool follows your work when you’re programming. It shows you all the details of your work as a developer – what file you’ve been working on, operating system, and even language. You can also compete against your teammates on the Leaderboard and see who has the highest score in coding.

It is very useful when it comes to managing your budget and productivity as a developer at once. Since this is also a time tracking solution, if you combine this with TimeCamp you basically become the time god.

Check it out at: https://wakatime.com/

Habitica

One of my personal favourites, Habitica is a free habit-building and productivity app that treats your real life like a game. With in-game rewards and punishments to motivate you and a strong social network to inspire you, Habitica can help you achieve your goals to become healthy, hard-working, and happy.

Habitica takes you to the old pixel-like platform world in which you’re a hero fighting through daily, weekly, and long-term goals, habits, and to-do lists. For every goal achieved you receive points, discover new animals, and can buy weapon to gain strength. The more you fail at your tasks, the more strength you lose. And the challenge is to keep your character alive.

Check it out here: https://habitica.com/static/home

Conclusion

That's all folks 👨‍🏫, Thank you for reading it till the end. These are the resources I found to be really helpful for me.
I'm sure there must be tons of other amazing tools out there too. These are the ones that I really found helpful and often get myself indulged into. 👨🏻‍💻

Don't forget to share these resources with someone who you think might need some help being more productive at work too. Peace out. ✌🏼

DEV Community: Sayan Mondal

LitmusChaos is Heading to KubeCon + CloudNativeCon Europe 2025 – Join the Chaos!

🔥 Chaos Talks You Won’t Want to Miss

📍 Visit Us at the LitmusChaos Booth

Booth Details:

🤝 Project Engagement Opportunities

🚀 Come Along and Learn More About Chaos Engineering

🌐 Stay Connected with LitmusChaos

Streamlined Incident Management in a Cloud Native World

The Challenge of Modern Incident Management

Why an Open Source Incident Management Tool?

The Solution

Getting Started with RespondNow

Step 1: Prerequisites

Step 2: Create a Slack App with an App Manifest

Step 3: Deploy RespondNow with Helm

Step 4: Verify the RespondNow Portal

Why RespondNow?

Wrapping Up

LitmusChaos is joining Kubecon + CloudNativeCon North America 2024!

Where to Find Us: Project Pavilion Kiosk #16A

Project Engagement Opportunities at KubeCon NA

What You Can Learn at the LitmusChaos Booth

Connect with LitmusChaos Year-Round

The What, Why and How of JavaScript bundlers

What is a JavaScript bundler anyway?

Table of contents

The Problem

How bundlers bundle

Mapping a Dependency Graph

Bundling

Bundlers are not transpilers

Conclusion

React just got awesome'er!

Proposal

What does this mean for us?

The old vanilla way

A better way

The proposed way

Conclusion

Free alternatives to Heroku

Railway

Fly.io

Deno Deploy

Koyeb

Napkin

Deta

Meteor Cloud

Conclusion

Understanding React Higher Order Component (HOC)

What is a Higher Order Component?

What can I do with HOCs?

Types of HOCs

Props Proxy

Inheritance Inversion

Let's dive into some examples

Conclusion

How the Resilience Score Algorithm works in Litmus!

Weights in Litmus

Resilience Score

Conclusion

SQL vs NoSQL - Which is better for you?

What is SQL?

What is NoSQL?

Comparing SQL vs NoSQL

Database Structure

Syntax

Hierarchy

Scalability

Stability

What is the right choice for your business?

Key-points in Short

Exploring Litmus 2.0 Beta with Civo

What is CIVO Cloud?

LitmusChaos 2.0 Advanced Beta is out!

Prerequisites

Installing Litmus 2.0 Beta on Civo

Accessing the Litmus Control Plane

Deploying our target application

Creating the Pod Delete experiment through the Litmus Control Plane