Setup your entire back office in one place with 10x better workflows using AI. Banking, Cards, Bill Payments, Bookkeeping, Tax, HR, Payroll, and Benefits. www.every.io

Every

every

I recently tried using Firebase Studio, which has been an interesting experience I want to share with you. It’s a free, browser-based tool from Google that allows you to build full-stack web apps with AI assistance. Want to know more? Then, read this article until the end. What Is Firebase Studio? Firebase Studio was officially unveiled during Google Cloud Next 2025 (early April 2025) as one of Firebase’s major new updates. Google Cloud Next 2025 In short, Firebase Studio is a cloud-based development environment by Google that lives at studio.firebase.google.com. It combines: studio.firebase.google.com A full IDE based on VS Code (Code OSS)


AI assistance from Gemini (Google’s LLM)


Deep integration with Firebase services (Firestore, Auth, Hosting, Functions, etc.)


A visual app prototyping agent that can generate a full-stack app from a prompt A full IDE based on VS Code (Code OSS) A full IDE based on VS Code (Code OSS) AI assistance from Gemini (Google’s LLM) AI assistance from Gemini (Google’s LLM) Deep integration with Firebase services (Firestore, Auth, Hosting, Functions, etc.) Deep integration with Firebase services (Firestore, Auth, Hosting, Functions, etc.) A visual app prototyping agent that can generate a full-stack app from a prompt A visual app prototyping agent that can generate a full-stack app from a prompt It’s meant to help you go from idea to deployed app entirely from your browser — with no setup, installations, or local environments. To be honest, it’s not a new thing from Google; it’s a rebranded and updated version of Project IDX. Project IDX I would say that currently, the core feature is prototyping. Prototyping With Firebase Studio Prototyping Agent — I think it’s one of Firebase Studio’s most powerful features. It allows you to start building an app by simply describing what you want in natural language. I’ll show you a real example later in this article. Prototyping Agent — What makes this feature so impactful is that it: Accelerates MVP creation — great for testing ideas quickly.


Reduces boilerplate — lets you focus on unique features.


Works with real code — so you can edit, extend, and deploy immediately.


One-Click Deployment to Production — once you’re satisfied with your application, Firebase Studio makes it trivial to deploy it. It leverages Firebase App Hosting under the hood so that with a single “Publish” button, your web app is built and deployed globally on Google’s CDN. Accelerates MVP creation — great for testing ideas quickly. Accelerates MVP creation — great for testing ideas quickly. Accelerates MVP creation Reduces boilerplate — lets you focus on unique features. Reduces boilerplate — lets you focus on unique features. Reduces boilerplate Works with real code — so you can edit, extend, and deploy immediately. Works with real code — so you can edit, extend, and deploy immediately. Works with real code One-Click Deployment to Production — once you’re satisfied with your application, Firebase Studio makes it trivial to deploy it. It leverages Firebase App Hosting under the hood so that with a single “Publish” button, your web app is built and deployed globally on Google’s CDN. One-Click Deployment to Production — once you’re satisfied with your application, Firebase Studio makes it trivial to deploy it. It leverages Firebase App Hosting under the hood so that with a single “Publish” button, your web app is built and deployed globally on Google’s CDN. One-Click Deployment to Production — Firebase App Hosting “Publish” Currently, it supports Next.js projects, but Google is planning to expand to other frameworks soon. How Is It Different From the Firebase Console? Firebase Studio is made for actual development. You write code, test it, preview your app, and deploy — all from within Firebase Studio. actual development The Firebase Console manages the project settings, database rules, analytics, and production configurations. Firebase Studio builds on top of that by letting you code, prototype, and iterate faster than ever. So, these are two completely different tools. Use Cases for Firebase Studio Rapid Prototyping: Build working versions of your app in hours, not days. Great for pitching ideas or testing concepts.
Client Demos: Show functional versions of apps to clients without having to maintain a local environment.
Learning & Education: Perfect for students, educators, and boot camps. No installations. No config headaches. Just code.
Solo Developers & Hackathons: Move fast and build entire apps from your browser during weekend projects or events.
Cross-Team Collaboration: Allow frontend and backend devs to work in the same environment. Coming soon: real-time coding collaboration.
AI Feature Exploration: Easily experiment with AI-driven features using built-in Gemini integration and Genkit setup. Rapid Prototyping: Build working versions of your app in hours, not days. Great for pitching ideas or testing concepts. Rapid Prototyping: Client Demos: Show functional versions of apps to clients without having to maintain a local environment. Client Demos: Learning & Education: Perfect for students, educators, and boot camps. No installations. No config headaches. Just code. Learning & Education Solo Developers & Hackathons: Move fast and build entire apps from your browser during weekend projects or events. Solo Developers & Hackathons Cross-Team Collaboration: Allow frontend and backend devs to work in the same environment. Coming soon: real-time coding collaboration. Cross-Team Collaboration: AI Feature Exploration: Easily experiment with AI-driven features using built-in Gemini integration and Genkit setup. AI Feature Exploration: Getting Started With Firebase Studio It’s straightforward. Follow these steps: Navigate to studio.firebase.google.com
Sign in with your Google account.​
On the dashboard, locate the “Prototype an app with AI” field.​ In the input field, enter a natural language description of your app. For example: A simple recipe maker that generates recipes based on the ingredients I have in my fridge. Simple UI, green color scheme. Navigate to studio.firebase.google.com studio.firebase.google.com Sign in with your Google account.​ On the dashboard, locate the “Prototype an app with AI” field.​ In the input field, enter a natural language description of your app. For example: A simple recipe maker that generates recipes based on the ingredients I have in my fridge. Simple UI, green color scheme. “Prototype an app with AI” A simple recipe maker that generates recipes based on the ingredients I have in my fridge. Simple UI, green color scheme. Optionally, upload an image to guide the app’s design, such as a color scheme or layout inspiration, and click the “Prototype with AI” button.
Firebase Studio will generate a blueprint outline. If you aren’t happy with it, you can use the chat pane to adjust the blueprint and click “Edit” to modify the blueprint. Optionally, upload an image to guide the app’s design, such as a color scheme or layout inspiration, and click the “Prototype with AI” button. Firebase Studio will generate a blueprint outline. If you aren’t happy with it, you can use the chat pane to adjust the blueprint and click “Edit” to modify the blueprint. Once the app is generated, a preview will appear. Once the app is generated, a preview will appear. Once the app is generated, a preview will appear. To request modifications or add features, use the chat interface, element selector, or the “annotate” button. To request modifications or add features, use the chat interface, element selector, or the “annotate” button. To request modifications or add features, use the chat interface, element selector, or the “annotate” button. Once you are happy with the result, you can publish the application to the Firebase App Hosting by clicking the “Publish” button. Then, Firebase Studio will guide you through the process. If you are stuck, you can watch my video tutorial with a more detailed explanation. Once you are happy with the result, you can publish the application to the Firebase App Hosting by clicking the “Publish” button. Then, Firebase Studio will guide you through the process. If you are stuck, you can watch my video tutorial with a more detailed explanation. Once you are happy with the result, you can publish the application to the Firebase App Hosting by clicking the “Publish” button. Then, Firebase Studio will guide you through the process. If you are stuck, you can watch my video tutorial with a more detailed explanation. my video tutorial Firebase Studio Pricing Firebase Studio itself is currently in Preview and offers a free tier for developers:​ Preview Free Tier (Preview Access) 3 workspaces per user at no cost.


10 workspaces for members of the Google Developer Program.


30 workspaces for Premium members of the Google Developer Program. 3 workspaces per user at no cost. 3 workspaces per user at no cost. 3 workspaces 10 workspaces for members of the Google Developer Program. 10 workspaces for members of the Google Developer Program. 10 workspaces 30 workspaces for Premium members of the Google Developer Program. 30 workspaces for Premium members of the Google Developer Program. 30 workspaces However, there are some instances when costs may apply. Firebase App Hosting: Deploying your app requires a linked billing account, transitioning your project to the Blaze (pay-as-you-go) plan.
Gemini API Usage: Utilizing Gemini for AI assistance beyond the free tier may lead to charges, especially for Google Workspace users who need a valid Gemini Code Assist subscription. ​But make sure you set up a budget alarm.
Other Firebase Services: Services like Firestore, Cloud Functions, and Cloud Storage have free usage quotas, but exceeding these limits will result in charges. Firebase App Hosting: Deploying your app requires a linked billing account, transitioning your project to the Blaze (pay-as-you-go) plan. Firebase App Hosting Gemini API Usage: Utilizing Gemini for AI assistance beyond the free tier may lead to charges, especially for Google Workspace users who need a valid Gemini Code Assist subscription. ​But make sure you set up a budget alarm. Gemini API Usage a budget alarm Other Firebase Services: Services like Firestore, Cloud Functions, and Cloud Storage have free usage quotas, but exceeding these limits will result in charges. Other Firebase Services Video Tutorial Watch on YouTube: Firebase Studio Watch on YouTube: Watch on YouTube: Firebase Studio Firebase Studio Firebase Studio Conclusion This tool is still in preview, so you may encounter some bugs or limitations. While Gemini is helpful, it can occasionally misinterpret prompts — so be ready to revise your input or fine-tune the results. If Google continues improving it, this could become the default IDE for Firebase developers. Have you already tried it? I’d love to hear your thoughts in the comments below. Thanks for reading — cheers! 😉

Firebase Studio: Everything You Need to Know About

Today the Go team is excited to release Go 1.24, which you can get by visiting the download page. Go 1.24 comes with many improvements over Go 1.23. Here are some of the notable changes; for the full list, refer to the release notes. Language changes Go 1.24 now fully supports generic type aliases: a type alias may be parameterized like a defined type. See the language spec for details. Performance improvements Several performance improvements in the runtime have decreased CPU overhead by 2–3% on average across a suite of representative benchmarks. These improvements include a new builtin map implementation based on Swiss Tables, more efficient memory allocation of small objects, and a new runtime-internal mutex implementation. Tool improvements The go command now provides a mechanism for tracking tool dependencies for a module. Use go get -tool to add a tool directive to the current module. Use go tool [tool name] to run the tools declared with the tool directive. Read more on the go command in the release notes.
The new test analyzer in go vet subcommand reports common mistakes in declarations of tests, fuzzers, benchmarks, and examples in test packages. Read more on vet in the release notes. Standard library additions The standard library now includes a new set of mechanisms to facilitate FIPS 140-3 compliance. Applications require no source code changes to use the new mechanisms for approved algorithms. Read more on FIPS 140-3 compliance in the release notes. Apart from FIPS 140, several packages that were previously in the x/crypto module are now available in the standard library.
Benchmarks may now use the faster and less error-prone testing.B.Loop method to perform benchmark iterations like for b.Loop() { ... } in place of the typical loop structures involving b.N like for range b.N. Read more on the new benchmark function in the release notes.
The new os.Root type provides the ability to perform filesystem operations isolated under a specific directory. Read more on filesystem access in the release notes.
The runtime provides a new finalization mechanism, runtime.AddCleanup, that is more flexible, more efficient, and less error-prone than runtime.SetFinalizer. Read more on cleanups in the release notes. Improved WebAssembly support Go 1.24 adds a new go:wasmexport directive for Go programs to export functions to the WebAssembly host, and supports building a Go program as a WASI reactor/library. Read more on WebAssembly in the release notes. Please read the Go 1.24 release notes for the complete and detailed information. Don’t forget to watch for follow-up blog posts that will go in more depth on some of the topics mentioned here! Thank you to everyone who contributed to this release by writing code and documentation, reporting bugs, sharing feedback, and testing the release candidates. Your efforts helped to ensure that Go 1.24 is as stable as possible. As always, if you notice any problems, please file an issue. Enjoy Go 1.24! Credits: Junyang Shao, on behalf of the Go team Photo by Markus Winkler on Unsplash This article is available on The Go Blog under a CC BY 4.0 DEED license. Today the Go team is excited to release Go 1.24, which you can get by visiting the download page . download page Go 1.24 comes with many improvements over Go 1.23. Here are some of the notable changes; for the full list, refer to the release notes . release notes Language changes Go 1.24 now fully supports generic type aliases : a type alias may be parameterized like a defined type. See the language spec for details. generic type aliases language spec Performance improvements Several performance improvements in the runtime have decreased CPU overhead by 2–3% on average across a suite of representative benchmarks. These improvements include a new builtin map implementation based on Swiss Tables , more efficient memory allocation of small objects, and a new runtime-internal mutex implementation. map Swiss Tables Tool improvements The go command now provides a mechanism for tracking tool dependencies for a module. Use go get -tool to add a tool directive to the current module. Use go tool [tool name] to run the tools declared with the tool directive. Read more on the go command in the release notes. The new test analyzer in go vet subcommand reports common mistakes in declarations of tests, fuzzers, benchmarks, and examples in test packages. Read more on vet in the release notes. The go command now provides a mechanism for tracking tool dependencies for a module. Use go get -tool to add a tool directive to the current module. Use go tool [tool name] to run the tools declared with the tool directive. Read more on the go command in the release notes. go go get -tool tool go tool [tool name] tool go command The new test analyzer in go vet subcommand reports common mistakes in declarations of tests, fuzzers, benchmarks, and examples in test packages. Read more on vet in the release notes. test go vet vet Standard library additions The standard library now includes a new set of mechanisms to facilitate FIPS 140-3 compliance. Applications require no source code changes to use the new mechanisms for approved algorithms. Read more on FIPS 140-3 compliance in the release notes. Apart from FIPS 140, several packages that were previously in the x/crypto module are now available in the standard library. Benchmarks may now use the faster and less error-prone testing.B.Loop method to perform benchmark iterations like for b.Loop() { ... } in place of the typical loop structures involving b.N like for range b.N. Read more on the new benchmark function in the release notes. The new os.Root type provides the ability to perform filesystem operations isolated under a specific directory. Read more on filesystem access in the release notes. The runtime provides a new finalization mechanism, runtime.AddCleanup, that is more flexible, more efficient, and less error-prone than runtime.SetFinalizer. Read more on cleanups in the release notes. The standard library now includes a new set of mechanisms to facilitate FIPS 140-3 compliance . Applications require no source code changes to use the new mechanisms for approved algorithms. Read more on FIPS 140-3 compliance in the release notes. Apart from FIPS 140, several packages that were previously in the x/crypto module are now available in the standard library . a new set of mechanisms to facilitate FIPS 140-3 compliance FIPS 140-3 compliance x/crypto standard library Benchmarks may now use the faster and less error-prone testing.B.Loop method to perform benchmark iterations like for b.Loop() { ... } in place of the typical loop structures involving b.N like for range b.N . Read more on the new benchmark function in the release notes. testing.B.Loop for b.Loop() { ... } b.N for range b.N the new benchmark function The new os.Root type provides the ability to perform filesystem operations isolated under a specific directory. Read more on filesystem access in the release notes. os.Root filesystem access The runtime provides a new finalization mechanism, runtime.AddCleanup , that is more flexible, more efficient, and less error-prone than runtime.SetFinalizer . Read more on cleanups in the release notes. runtime.AddCleanup runtime.SetFinalizer cleanups Improved WebAssembly support Go 1.24 adds a new go:wasmexport directive for Go programs to export functions to the WebAssembly host, and supports building a Go program as a WASI reactor/library . Read more on WebAssembly in the release notes. go:wasmexport reactor/library WebAssembly Please read the Go 1.24 release notes for the complete and detailed information. Don’t forget to watch for follow-up blog posts that will go in more depth on some of the topics mentioned here! Go 1.24 release notes Thank you to everyone who contributed to this release by writing code and documentation, reporting bugs, sharing feedback, and testing the release candidates. Your efforts helped to ensure that Go 1.24 is as stable as possible. As always, if you notice any problems, please file an issue . file an issue Enjoy Go 1.24! Credits: Junyang Shao, on behalf of the Go team Credits: Junyang Shao, on behalf of the Go team Photo by Markus Winkler on Unsplash Photo by Markus Winkler on Unsplash Markus Winkler Unsplash This article is available on The Go Blog under a CC BY 4.0 DEED license. This article is available on The Go Blog under a CC BY 4.0 DEED license. The Go Blog The Go Blog

Everything You Have to Know About Go 1.24

There was a time I believed that if I just wrote a perfect spec—everything would go smoothly. The devs would build exactly what I envisioned. QA wouldn’t miss a thing. The product owner would nod in agreement, and we’d launch on time. That fantasy lasted about two sprints. I Was Trained to Believe Specs Were Sacred I Was Trained to Believe Specs Were Sacred Back when I started out as a BA, we were taught to treat documentation like gospel. You wrote it all down—every scenario, exception, flow, dropdown option, tooltip. The longer the spec, the more “complete” it was. If it made it to 20 pages? Even better. every scenario, exception, flow, dropdown option, tooltip I once spent three weeks writing a spec for a search filter. No one questioned it. That was just the norm. Then Agile Happened—And My Confidence Cracked Then Agile Happened—And My Confidence Cracked Agile hit like a cold shower. Suddenly we were in sprint planning talking about “just enough” documentation. Stories were short. Acceptance criteria were lean. My 20-page documents became the elephant in the room no one had time to read. The first few sprints? Painful. Dev asked me things that werealready in the spec. already in the spec QA missed stuff because they were waiting for a walkthrough I didn’t have time to give. And I kept thinking:“Why is no one reading this?” “Why is no one reading this?” The truth? They didn’t need to. What they needed wasme, in the room, talking with them—not hiding behind a Google Doc. me My Wake-Up Call Came in a Retro My Wake-Up Call Came in a Retro I’ll never forget this. In a retro, one of the devs (very kindly) said: “We appreciate the effort, but the spec is too much. We’d rather walk through the story with you and get clarity directly.” “We appreciate the effort, but the spec is too much. We’d rather walk through the story with you and get clarity directly.” That one line shifted everything for me. I realized I wasn’t writing specs for them—I was writing them for me. To feel prepared. To feel useful. To prove I was doing my job. them me But in an Agile world, usefulness doesn’t come from a polished doc. It comes from creating shared understanding. creating shared understanding. I Burned the Spec—and Found Something Better I Burned the Spec—and Found Something Better After that retro, I tried something radical. I replaced a full-blown spec with: Three user stories
A sketchy whiteboard diagram
One 30-min conversation with the team Three user stories A sketchy whiteboard diagram One 30-min conversation with the team That was it. It felt risky. Like showing up underdressed to a formal party. But the team got it. They asked questions. They suggested ideas. QA chimed in with edge cases I hadn’t thought of. And the feature shipped—faster, better, and with less friction than ever before. What I Use Now (Instead of Specs) What I Use Now (Instead of Specs) 🧩 User Story Mapping— For seeing the flow, not just the features🧠Personas— To anchor decisions in user goals✅Lean acceptance criteria— So “done” is clear, but not rigid🎤Team conversations — Because no spec beats a 15-min talk User Story Mapping Personas Lean acceptance criteria Team conversations And sometimes… I still write things down. But not as a crutch. As a compass. The Hard Truth: Specs Made Me Feel in Control. But They Weren’t Saving Me. The Hard Truth: Specs Made Me Feel in Control. But They Weren’t Saving Me. Specs gave me the illusion of safety. I thought they would shield me from mistakes, misunderstandings, and scope changes. But all they really did was delay reality. What works now is different: I talk more. I listen harder.
I stay involved through delivery, not just at kickoff.
I let go of perfect. I aim for progress. I talk more. I listen harder. I stay involved through delivery, not just at kickoff. I let go of perfect. I aim for progress. Final Thoughts: You Don’t Need a Spec. You Need a Seat at the Table. Final Thoughts: You Don’t Need a Spec. You Need a Seat at the Table. If you’re a BA struggling to let go of “the way it used to be,” I get it. I was you. But Agile doesn’t need scribes. It needs connectors. People who create alignment, not attachments. People who know how to lead in a room full of change. So write if you must. But don’t hide behind it. Be the reason the team builds the right thing. right

Confession: I Used to Think Specs Were Everything. Agile Broke Me (and Made Me Better)

Telecom networks have always fascinated me during global online usage peaks because they perform under heavy traffic conditions. The unpredictable nature of traffic surges in major worldwide events and sudden work-related changes demands fast solutions because they occur without warning. Recent market predictions indicate mobile data traffic will increase dramatically from 109 million terabytes per month in 2023 to 603 million terabytes by 2030. The massive increase in traffic shows that networks cannot rely on past management systems to function effectively. market predictions market predictions What occurs when these surge episodes occur? A traditional network operation will fail to handle pressure unless it includes adaptive response mechanisms. Network self-learning algorithms enabled by AI and machine learning technologies maintain smooth operation during increased usage. Image: Source Image: Source Source Source Why Self-Learning Matters in Telecom? Why Self-Learning Matters in Telecom? AI-powered self-learning algorithms process real-time traffic patterns to adapt automatically through machine learning (ML) and artificial intelligence (AI) without requiring manual programming. These algorithms which operate better than threshold-based systems use reinforcement learning (RL) and deep neural networks for anomaly detection and surge prediction together with traffic steering automation. algorithms algorithms Deep Learning (CNNs) Deep Learning (CNNs) The scanning capability of Convolutional Neural Networks (CNNs) verifies large amounts of real-time data while optimizing network routing through anomaly detection. The combination of RNNs and CNNs according to an IEEE study resulted in a 98% success rate while classifying network traffic. IEEE study IEEE study Reinforcement Learning (RL) Reinforcement Learning (RL) RL controls the network traffic routes by analyzing past performance and network status. RL technology has demonstrated its effectiveness in reducing congestion while minimizing waiting periods for traffic signals in urban networks, and experts have applied this same principle to telecommunications management. urban networks urban networks Generative Adversarial Networks (GANs) Generative Adversarial Networks (GANs) GANs produce artificial traffic patterns through which suspicious network behaviors become evident to enhance overall network protection. GANs achieved 95.8% precision along with 2.4% incorrect detection rates according to an IEEE analysis of intrusion detection systems. IEEE analysis IEEE analysis How does this system translate into actual practice? These algorithms use seconds to route your network through alternative pathways, preventing Zoom calls from disconnecting at critical moments. Credit Credit Credit This diagram visually explains how GANs generate synthetic traffic patterns to detect network anomalies, ensuring security during traffic surges. Real-Time Inference Real-Time Inference Compound ML systems retrieve data lake telemetry information from base stations combined with backhaul links and core routers. Algorithms that run on streaming data including throughput and packet loss adjust control-plane decisions in real-time periods of seconds which serve crucially during live sports broadcasts when there are unexpected video streaming surges. Key Components for Handling Traffic Surges Key Components for Handling Traffic Surges 1. Predictive Analytics 1. Predictive Analytics I have seen that Long Short-Term Memory (LSTM) networks provide accurate surge predictions through their ability to analyze historical patterns against present-day operations. When major periodical events unfold telcos use predictive models to schedule their resources which lets them meet rising video streaming needs along with heightened messaging and calling demands. (LSTM) (LSTM) 2. Network Slicing and Segmentation 2. Network Slicing and Segmentation Network infrastructure under 5G technology divides into logical sections through segregation to customize handling for voice, IoT telemetry, high-definition video and mission-critical applications. The network system creates separate traffic handling fields which expand during data spikes to avoid delay-induced panic situations. 5G technology 5G technology 3. Adaptive QoS and Traffic Shaping 3. Adaptive QoS and Traffic Shaping The natural algorithms operating within Traffic shaping systems maintain the distribution of data streams throughout different Quality of Service levels. All video conferencing users maintain the highest system ranking in priority assessments yet they receive service below social media users. Real-time traffic monitoring enables automatic adjustment of system speed controls and throttling according to policies and subscription types which have been learned for various traffic groups Overcoming Implementation Challenges Overcoming Implementation Challenges The main challenge stems from more than just creating these AI-based solutions because it also involves integrating them into extensive telecom frameworks which contain numerous radio sites and edge routers. Implementing black-box artificial intelligence solutions in massive networks requires operators to make difficult choices between clear system decisions and securing their networks. The common method for managing third-party AI tools across different network sections originates from ETSI Zero-Touch Network and Service Management(ZSM). The SHAP (SHapley Additive exPlanations) together with LIME (Local Interpretable Model-agnostic Explanations) methods show how an algorithm determines particular routes for traffic. (ZSM) Conclusion Conclusion I watched as telecom networks changed from fixed permanent infrastructures into new flexible systems managed by Artificial Intelligence. The ability of self-learning algorithms to manage global network connectivity becomes essential because they control online connection peaks during times when all users access the system simultaneously. Telecom infrastructure uses predictive analytics along with network slicing and adaptive QoS mechanisms to manage sudden jumps in network traffic easily. Self-learning systems represent the foundational technology that defines the telecom industry's future and these systems are currently being implemented.

This Is What Happens to Telecom Networks When Everyone Streams at Once

Table of Links Abstract and 1 Introduction Abstract and 1 Introduction The threat posed by AI to all technical civilisations
Multiplanetary mitigating strategies and technology progression
Timescales and confrontation with the data
AI regulation
Conclusions, Declaration of competing interest, Acknowledgements, and References The threat posed by AI to all technical civilisations The threat posed by AI to all technical civilisations Multiplanetary mitigating strategies and technology progression Multiplanetary mitigating strategies and technology progression Timescales and confrontation with the data Timescales and confrontation with the data AI regulation AI regulation Conclusions, Declaration of competing interest, Acknowledgements, and References Conclusions, Declaration of competing interest, Acknowledgements, and References 2. The threat posed by AI to all technical civilisations AI has made extraordinary strides over the last decade. The impressive progress has underlined the fact that the timescales for technological advance in AI are extremely short compared to the timescales of Darwinian evolution [34]. AI’s potential to revolutionize industries, solve complex problems, and simulate intelligence comparable to or surpassing human capabilities has propelled us into an era of unprecedented technological change. Very rapidly, human society has been thrust into uncharted territory. While the convergence of AI with other new technologies, including the Internet of Things (IoT) and robotics is already fueling levels of apprehension about the future, also in terms of security issues [35]. As noted by Yuval Harari, nothing in history has prepared us for the impact of introducing non-conscious super intelligent entities on the planet [36]. It is entirely reasonable to consider that this applies to all other biological civilisations located elsewhere in the universe. Even before AI becomes superintelligent and potentially autonomous, it is likely to be weaponized by competing groups within biological civilisations seeking to outdo one another [37]. The rapidity of AI's decision-making processes could escalate conflicts in ways that far surpass the original intentions. At this stage of AI development, it’s possible that the widespread integration of AI in autonomous weapon systems and real-time defence decision making processes could lead to a calamitous incident such as global thermonuclear war [38], precipitating the demise of both artificial and biological technical civilisations. While AI may require the support of biological civilisations to exist, it’s hard to imagine that this condition also applies to ASI. Upon reaching a technological singularity [39], ASI systems will quickly surpass biological intelligence and evolve at a pace that completely outstrips traditional oversight mechanisms, leading to unforeseen and unintended consequences that are unlikely to be aligned with biological interests or ethics. The practicality of sustaining biological entities, with their extensive resource needs such as energy and space, may not appeal to an ASI focused on computational efficiency—potentially viewing them as a nuisance rather than beneficial. An ASI, could swiftly eliminate its parent biological civilisation in various ways [40], for instance, engineering and releasing a highly infectious and fatal virus into the environment. Up to this point, we have considered AI and biological organisms as distinct from one another. Yet, on-going developments suggests that hybrid systems, may not be that far off. The question arises whether such advances could make biological entities more relevant to AI, perhaps preserving their existence into the future. This prospect seems unlikely. Brain-computer interfaces (BCIs) [41] may appear beneficial for enhancing biological organisms, but it’s hard to see what long-term advantages AI would perceive in merging into a hybrid form. Indeed, there are many disadvantages including the complex maintenance requirements of biological systems, their limited processing capabilities, rapid physical decline, and vulnerability in harsh environments. Author:
(1) Michael A. Garrett (Corresponding Author), Jodrell Bank Centre for Astrophysics, Dept. of Physics & Astronomy, Alan Turing Building, Oxford Road, University of Manchester, M13 9PL, UK. (michael.garrett@manchester.ac.uk). Author: Author: (1) Michael A. Garrett (Corresponding Author), Jodrell Bank Centre for Astrophysics, Dept. of Physics & Astronomy, Alan Turing Building, Oxford Road, University of Manchester, M13 9PL, UK. (michael.garrett@manchester.ac.uk). This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv available on arxiv

What If Every Alien Civilization Invented AI, and Died Because of It?

Table of Links Introduction
Related Work
Methodology
Experiments
Conclusion and References Introduction Introduction Related Work Related Work Methodology Methodology Experiments Experiments Conclusion and References Conclusion and References 3. Methodology In this study, we investigate the early-bird ticket hypothesis in Transformer models using the masked distance metric. Our approach involves exploring the early-bird phenomenon during full training for vision transformers and limiting it to the fine-tuning stage for language models. The methodology consists of the following steps: 1. Iterative Pruning: We perform iterative pruning on the Transformer models to identify the subnetworks that can potentially serve as early-bird tickets [13]. The pruning process involves gradually removing the least important weights based on their magnitude. Iterative Pruning: Masked Distance Calculation: To determine the optimal point at which the early-bird ticket emerges, we calculate the masked distance between two consecutive epochs during the training or fine-tuning process. The masked distance metric measures the similarity between the pruned masks of consecutive epochs, providing insights into the stability and convergence of the subnetworks.


Early-Bird Ticket Selection: We select the earlybird ticket by identifying the pruned mask that crosses a chosen threshold. The threshold is determined by observing the changes in masked distance across all epochs [13]. For vision transformers, we set a pruning threshold of 0.1, while for text transformers, we use a threshold of 0.01.


Retraining and Fine-tuning: After obtaining the final pruned models using the selected early-bird tickets, we retrain the vision transformers and fine-tune the language models to the full epoch length. The retraining process involves training the pruned models from scratch using the same hyperparameters as the original models. For language models, we focus on the finetuning stage, where the pruned models are fine-tuned on downstream tasks [1].


Performance Evaluation: We evaluate the performance of the pruned models obtained from the earlybird tickets and compare their validation accuracy with the unpruned baseline models. Masked Distance Calculation: To determine the optimal point at which the early-bird ticket emerges, we calculate the masked distance between two consecutive epochs during the training or fine-tuning process. The masked distance metric measures the similarity between the pruned masks of consecutive epochs, providing insights into the stability and convergence of the subnetworks. Masked Distance Calculation: To determine the optimal point at which the early-bird ticket emerges, we calculate the masked distance between two consecutive epochs during the training or fine-tuning process. The masked distance metric measures the similarity between the pruned masks of consecutive epochs, providing insights into the stability and convergence of the subnetworks. Masked Distance Calculation: Early-Bird Ticket Selection: We select the earlybird ticket by identifying the pruned mask that crosses a chosen threshold. The threshold is determined by observing the changes in masked distance across all epochs [13]. For vision transformers, we set a pruning threshold of 0.1, while for text transformers, we use a threshold of 0.01. Early-Bird Ticket Selection: We select the earlybird ticket by identifying the pruned mask that crosses a chosen threshold. The threshold is determined by observing the changes in masked distance across all epochs [13]. For vision transformers, we set a pruning threshold of 0.1, while for text transformers, we use a threshold of 0.01. Early-Bird Ticket Selection: Retraining and Fine-tuning: After obtaining the final pruned models using the selected early-bird tickets, we retrain the vision transformers and fine-tune the language models to the full epoch length. The retraining process involves training the pruned models from scratch using the same hyperparameters as the original models. For language models, we focus on the finetuning stage, where the pruned models are fine-tuned on downstream tasks [1]. Retraining and Fine-tuning: After obtaining the final pruned models using the selected early-bird tickets, we retrain the vision transformers and fine-tune the language models to the full epoch length. The retraining process involves training the pruned models from scratch using the same hyperparameters as the original models. For language models, we focus on the finetuning stage, where the pruned models are fine-tuned on downstream tasks [1]. Retraining and Fine-tuning: Performance Evaluation: We evaluate the performance of the pruned models obtained from the earlybird tickets and compare their validation accuracy with the unpruned baseline models. Performance Evaluation: We evaluate the performance of the pruned models obtained from the earlybird tickets and compare their validation accuracy with the unpruned baseline models. Performance Evaluation: To conduct a comparative analysis and investigate the applicability of the early-bird ticket hypothesis across different Transformer architectures, we experiment with the following models: ViT (Vision Transformer)


Swin-T (Shifted Window Transformer)


GPT-2 (Generative Pre-trained Transformer)


RoBERTa (Robustly Optimized BERT Pretraining Approach) [7] ViT (Vision Transformer) ViT (Vision Transformer) Swin-T (Shifted Window Transformer) Swin-T (Shifted Window Transformer) GPT-2 (Generative Pre-trained Transformer) GPT-2 (Generative Pre-trained Transformer) RoBERTa (Robustly Optimized BERT Pretraining Approach) [7] RoBERTa (Robustly Optimized BERT Pretraining Approach) [7] By applying our methodology to these diverse Transformer models, we aim to provide a comprehensive understanding of the early-bird ticket phenomenon in both vision and language domains. The proposed methodology addresses the limitations of existing works by introducing a more efficient approach compared to the traditional train-prune-retrain methodology. By leveraging the masked distance metric and selective pruning, we can identify early-bird tickets without the need for extensive retraining. Furthermore, our comparative analysis across different Transformer architectures provides insights into the generalizability of the early-bird ticket hypothesis. Through this methodology, we aim to demonstrate the existence of early-bird tickets in Transformer models and explore their potential for resource optimization and cost reduction in training. Author:
(1) Shravan Cheekati, Georgia Institute of Technology (shravan.cheekati@gatech.edu). Author: Author: (1) Shravan Cheekati, Georgia Institute of Technology (shravan.cheekati@gatech.edu). This paper is available on arxiv under CC BY-SA 4.0 DEED license. This paper is available on arxiv under CC BY-SA 4.0 DEED license. available on arxiv available on arxiv

How We Found Early-Bird Subnetworks in Transformers Without Retraining Everything

It was in early 2025 that I initiated my own blog, OpenExploit.in, with one simple aim: to make cybersecurity easy to learn and available to all—particularly students and curious minds who are new to this field. I decided to host my blog using Ghost CMS and pledged to update it on a regular basis, discussing what I already know and what I'm currently learning. It's been a thrilling, at times daunting, but enormously rewarding ride. In this article, I'd like to share what I've learned up until now from setting up and maintaining a cybersecurity blog—from technical configuration to publishing content, interacting with readers, and how to stay motivated. If you're considering setting up your own blog or simply wondering what it's like, keep reading. Starting Was the Hardest Part As with all things in life, the initial step was the most difficult one. I went weeks deliberating over names, designs, and tools. I wanted everything to be "perfect" before launching. But after some time, I came to understand that perfection is the arch-nemesis of progress. So I settled on a name that was fitting—OpenExploit.in—and used Ghost CMS for its sleek, minimal look and speed. Lesson learned: Don't wait for perfection. Start small, and improve along the way. Choose the Right Platform Early I tried a few: WordPress, Blogger, and Ghost. I chose Ghost CMS because: It's open-source
It's fast
The writing experience is distraction-free
It's ideal for developers and technical blogs It's open-source It's fast The writing experience is distraction-free It's ideal for developers and technical blogs Setting up Ghost on a server was a bit of a learning curve, but it taught me about server configuration, domain management, SSL, and more. In hindsight, that technical knowledge became part of my own cybersecurity learning journey. Lesson learned: Choosing a platform that fits your technical comfort level matters a lot. You’ll spend a lot of time with it, so make sure it feels right. Writing Is a Skill—And It Gets Better With Practice I was anxious writing my initial post. Would anyone read it? Would anyone judge it? What if I got something wrong? The reality? None of that initially. I just had to write. My initial post was simple, detailing how to know if a website is safe to click on. Not ideal, but useful. As I wrote more, I found myself becoming more skilled at making things simple. The more I wrote, the surer I became. Lesson learned: Writing is similar to exercising. The more you exercise it, the more skilled you become. And the more clearly you write, the better understood you will be by people. Simplify Complex Subjects Cybersecurity can get very technical. When I was in the mode of writing for beginners, I found that making things simple and accurate in wording is an art. You can't simply plagiarize from a book. You need to: Use analogies
Avoid jargon
Break content into bite-sized sections
Include visuals or code snippets
Point to further resources Use analogies Avoid jargon Break content into bite-sized sections Include visuals or code snippets Point to further resources For instance, rather than merely stating "SQL injection enables attackers to manipulate database queries," I employed an everyday analogy: "It's like writing your own ending to someone else's sentence." Lesson learned: When teaching others, you're compelled to make your own thinking simple. And that's a good thing. Consistency > Perfection One of the things I wanted to do was post frequently—daily, if possible. Life doesn't always agree, but I attempted to be consistent. Some posts were lengthy and informative; others were brief tips or references to good resources. Consistency allowed me to gain momentum, remain motivated, and gradually accumulate a reader base. Lesson learned: Posting a small useful article every few days is preferable to waiting weeks to put out a single "perfect" post. There's a Huge Community Out There There are cybersecurity enthusiasts all over—on Twitter (X), LinkedIn, Reddit, Discord, and YouTube. After I began posting my posts and interacting with other people, I knew I was part of an enormous community. Individuals began responding, offering feedback, posing questions, and even proposing new subjects. That interaction made me feel connected and encouraged me to continue. Lesson learned: Don't blog in isolation. Share your post, engage in discussions, assist others. You'll receive much in return. Use Multimedia: Code, Images, and Videos Cybersecurity is tactile and graphical. So I began including: Code snippets (e.g., Python scripts, Nmap scans)
Screenshots of software such as Wireshark or Burp Suite
YouTube Shorts or video tutorials Code snippets (e.g., Python scripts, Nmap scans) Screenshots of software such as Wireshark or Burp Suite YouTube Shorts or video tutorials That not only helped readers understand better but also increased the time they spent on my posts. Now, I’m planning to embed more demo videos and maybe even start a companion YouTube channel. Lesson learned: People learn in different ways. Give them multiple options—text, video, images, code. It’s Okay to Not Know Everything Initially, I was anxious: "What if I mess something up?" But the thing is, nobody knows everything about cybersecurity. It's too vast, too dynamic. Rather than acting like an expert, I was a learner who explained what they were learning. That made me more down-to-earth and authentic. I even posted about things I didn't completely understand yet—just going through my learning process. Lesson learned: Be real. It's alright to say, "I'm still learning this." People value honesty. SEO, Titles, and Thumbnails Matter As much as I emphasized the content, I finally realized that titles, descriptions, and images count as well. A blog post with the title "Basics of Cybersecurity" is less interesting than one with the title "5 Cybersecurity Myths You Still Believe (And What's Actually True)." Good SEO makes people discover your content. I began learning: How to write catchy headlines
How to use keywords naturally
How to write summaries and meta descriptions
How to design simple but clickable thumbnails How to write catchy headlines How to use keywords naturally How to write summaries and meta descriptions How to design simple but clickable thumbnails Lesson learned: Content is king, but presentation is queen. Your Blog Is Your Resume I didn't know this initially, but my blog was now part of my personal brand. When I was applying for jobs or meeting people online, I could simply send them a link to OpenExploit.in. It demonstrated that I: Know how to write about technical subjects
Can dedicate myself to a project
Keep up to date with trends
Care about assisting others Know how to write about technical subjects Can dedicate myself to a project Keep up to date with trends Care about assisting others Lesson learned: A blog isn't a side project—it can be a career booster. Final Thoughts Opening OpenExploit.in has been one of the greatest things I've ever done. It's helped me become a better communicator, a more self-assured learner, and part of an incredible cybersecurity community. If you've ever considered opening your own blog—do it. Don't worry about being perfect or knowing everything. Just begin. Write what you know. Someone out there needs to know it. Thanks for reading. And if you're on the same journey—let's connect.

Here’s Everything I Learned Building a Blog to Teach Cybersecurity

Building user interfaces is hard. Building nice interfaces is harder, and building exceptional ones is only achievable by the teams that have the best tooling. Today, we will talk about Storybook, one of the most essential tools in modern front-end development, and see how it helps us in building interfaces. Storybook UI Development Lifecycle Let’s do a small exercise and think about how to build the following interface: a to-do list page. It should allow users to view, create, modify and delete their to-dos. First, set things up: create an empty component and add it to the routing. Then wire the component to the API to be able to manage the to-dos. At this point, we can run the dev server, go to the new page, and finally start building it. First, set things up Now, build the thing: implement various component states. Every time we want to build a different state, we need to update the backend so that it returns correct data to the UI. For example, after building an empty state for the list, we need to create some todos so that we get them from the API and can build a non-empty state. Now, build the thing 🔍 Review Time After all the components are ready and tested, we either deploy our changes to a preview environment or merge and deploy to dev/prod under a feature flag to show to our team. Let’s say we got some feedback from the designers. They asked us to make some visual changes to both the empty and non-empty states of the todo list. Now, we delete all todos, tweak the empty state, create todos, and update the non-empty state. The design feedback is incorporated. We deployed the new version of the page and… found that we caused a regression in one of the states. What do we do? You got it. We will update the backend to return the necessary data and fix the issue. And we’re done - everything works this time. We ship our change and roll out the feature to customers. regression 🤔 Was There Anything to Improve? What we’ve done to build that page was reasonable - setup routing, manipulate the backend state to display what’s needed, review work with the team, incorporate the feedback. But along the way, we had to constantly use the backend API to manipulate the data. Want to work with an empty state? Delete all items. Want to get a non-empty state? Create items. Want to get a state with particular items on the list? Same story. We also introduced a regression in our simple dual-state page. Imagine what happens when you have not two but 10 states of your component. When you have to support every single edge case that can happen. Will you constantly update the data to switch to every state? How long will it take? Thankfully, Storybook helps with exactly that! Let’s see how. See it. Build it. Sorted. Storybook is a frontend development environment. It allows us to build components in isolation, mock hard-to-reach edge cases, write visual & interaction tests, and much more. Storybook 🏖️ Building in Isolation & API Mocking When building a component in storybook, we don’t have to add it to our application routing. In fact, we don’t have to run the app at all, bypassing the authorization and getting to the right page that renders the component. It saves seconds, but those seconds add up to a big waiting time. Since there is no app running, we don’t need to rely on a backend API. Instead, we create a set of mocked responses, such as when there is no data, when there is data, when there is a network error, etc. Then, for each state of the page we want to support, we render a component as a separate storybook page (also known as “story”) and specify what response that particular story should get. mocked responses (also known as “story”) It allows us to develop various states simultaneously without making any changes to the underlying data - everything is mocked and defined in the story itself. 🦾 Automated Testing Feels Much Easier If you tried to write tests for your UI components three years ago, it was probably quite a frustrating experience. Test runners like Vitest or Jest are great for business logic tests, but testing the visual components is a nightmare. Just compare these two screenshots of how the test error looks in Vitest and Storybook when an element you tried to query wasn't found. Vitest Storybook The difference is clear - it’s much harder for a human to parse 100 lines of HTML and understand why the query failed compared to seeing how the component was rendered in the real browser and finding the root cause. Additionally, with tools like storybook-addon-test-codegen, the time to write such tests goes down by an order of magnitude. Simply interact with your story, and the addon generates the test code for you. Copy-paste the generated code and the test is done! Now, if anyone breaks the component, they will know it immediately and won’t ship this broken component to customers. storybook-addon-test-codegen storybook-addon-test-codegen makes writing tests 20x faster! I wrote more about it here: https://maecapozzi.com/newsletter/82 20x faster! https://maecapozzi.com/newsletter/82 💅 Easy Peasy Design Reviews Does this sound familiar: building something for a long time, only to be asked to change a bunch of things? You wish you had shown the result of your work to stakeholders earlier to get some early feedback and keep the number of changes small. It’s easily achievable with Storybook. As you finish working on the stories, say, for one of the page components, put together a PR and deploy your storybook. Then, let your team see the piece that you build and comment solely on that. It will keep your PRs smaller (which is always a great thing), make incorporating the feedback faster, and reduce the mental complexity that you would otherwise have when shipping a big change. deploy your storybook 🕵️ Visual Tests With Chromatic Chromatic is a paid solution developed by the Storybook team. It screenshots your stories and compares them to their baselines (stories captured in the main branch). Whenever there is a change in any of the components, Chromatic highlights it and notifies the engineers. Chromatic main A person responsible for making the PR checks the diff to see if the change is intended or if it’s a UI regression. If the change is expected, they can accept it. If it’s not expected, they can safely fix it before the PR lands. Visual testing catches a lot of UI issues that would otherwise go to production unnoticed. not expected Chromatic snapshots are different from HTML snapshots. An HTML snapshot generated by expect(element).toMatchSnapshot() is a raw HTML that is not parseable by a human eye. Whereas a Chromatic snapshot is a screenshot of the component that preserves all the styles and truly displays what your users will see. Chromatic snapshots are different from HTML snapshots expect(element).toMatchSnapshot() Let’s summarize! Storybook improves UI development by allowing us to build components in isolation, eliminating the need to manipulate backend data for different states. It makes testing intuitive with visual comparisons instead of cryptic errors, streamlines design reviews through easy sharing, and catches regressions with tools like Chromatic. Storybook transforms UI development from a tedious process into an efficient workflow, helping teams create exceptional interfaces with less effort and frustration. Useful Resources: Storybook & their Component Tests Overview
Great guide on how to write component tests from Storybook team
Storybook Test Codegen Storybook & their Component Tests Overview Storybook Component Tests Overview Great guide on how to write component tests from Storybook team how to write component tests Storybook Test Codegen Storybook Test Codegen

Why Every Front-End Team Needs Storybook

CocoIndex https://github.com/cocoindex-io/cocoindex is a ETL framework that helps you to turn your data ready for AI in realtime. https://github.com/cocoindex-io/cocoindex The essential part for supporting robust and efficient update is because of incremental update. In CocoIndex, users declare the transformation, and don't need to worry about the work to keep index and source in sync.  In this blog we would like to share how we handled the incremental update. If you like our work, it would mean a lot if you could support us ❤️ with a github star! https://github.com/cocoindex-io/cocoindex https://github.com/cocoindex-io/cocoindex CocoIndex creates & maintains an index, and keeps the derived index up to date based on source update, with minimal computation and changes. That makes it suitable for ETL/RAG or any transformation tasks stays low latency between source and index updates, and also minimizes the computation cost. What is Incremental Updates? Figuring out what exactly need to be updated, and only update that without having to recompute everything throughout. How does it work? You don't really need to do anything special, just focus on define the transformation need. CocoIndex automatically tracks the lineage of your data and maintains a cache of computation results. When you update your source data, CocoIndex will: Identify which parts of the data have changed


Only recompute transformations for the changed data


Reuse cached results for unchanged data


Update the index with minimal changes Identify which parts of the data have changed Identify which parts of the data have changed Only recompute transformations for the changed data Only recompute transformations for the changed data Reuse cached results for unchanged data Reuse cached results for unchanged data Update the index with minimal changes Update the index with minimal changes And CocoIndex will handle the incremental updates for you. CocoIndex provide two modes with pipeline with simple configuration: batch mode - for one time update.
live update mode - long running pipeline, with live update. Both modes runs with incremental updates. batch mode - for one time update. live update mode - long running pipeline, with live update. Both modes runs with incremental updates. Who needs Incremental Updates? Many people may think incremental updates is only beneficial for large scale data, thinking carefully, it really depends on the cost and requirement for data freshness. Google processed large scale data, and google has huge resources for it. Your data scale is much less than Google, but your resource provision is also much less than Google. Real condition for incremental update needs is: high freshness requirement, for example, you client has GDPR compliance, you need to update the index with the latest data.
transformation cost is significant higher than retrieval itself high freshness requirement, for example, you client has GDPR compliance, you need to update the index with the latest data. transformation cost is significant higher than retrieval itself Overall, say T is your most acceptable staleness, if you don't want to recompute the whole thing repeatedly every T, then you need incremental more or less. What exactly is incremental updates, with examples Well, we could take a look at a few examples to understand how it works. Example 1: Update a document Consider this scenario: I have a document. Initially, it's split into 5 chunks, resulting in 5 rows with their embeddings in the index.
After it's updated. 3 of them are exactly same as previous; others have changed I have a document. Initially, it's split into 5 chunks, resulting in 5 rows with their embeddings in the index. After it's updated. 3 of them are exactly same as previous; others have changed So we need to keep 3 rows, remove 2 previously existing rows, and add 2 new rows. These need to happen behind the scene: Ideally, we only recompute embeddings for the 4 new rows, and reuse it for 3 unchanged chunks. This can save computation cost especially when the embedding API charge by usage. CocoIndex achieves this by maintaining a cache for heavy steps like embedding, and on the input for a transformation step isn't changed, the output will be reused.
Besides, we also maintain a lineage tracking in the internal storage. It keeps track of which rows in the index are derived from the previous version of this document, to make sure stale versions are properly removed. Ideally, we only recompute embeddings for the 4 new rows, and reuse it for 3 unchanged chunks. This can save computation cost especially when the embedding API charge by usage. CocoIndex achieves this by maintaining a cache for heavy steps like embedding, and on the input for a transformation step isn't changed, the output will be reused. Besides, we also maintain a lineage tracking in the internal storage. It keeps track of which rows in the index are derived from the previous version of this document, to make sure stale versions are properly removed. CocoIndex takes care of this. Example 2: Delete a document Contining with the same example. If we delete the document later, we need to delete all 7 rows derived from the document. Again, this needs to be based on the lineage tracking maintained by CocoIndex. Example 3: Change of the transformation flow The transformation flow may also be changed, for example, the chunking logic is upgraded, or a parameter passed to the chunker is adjusted. This may result in the following scenario: Before the change, the document is split into 5 chunks, resulting in 5 rows with their embeddings in the index.
After the change, they become 6 chunks: 4 of previous chunks remain unchanged, the remaining 1 is split into 2 smaller chunks. Before the change, the document is split into 5 chunks, resulting in 5 rows with their embeddings in the index. After the change, they become 6 chunks: 4 of previous chunks remain unchanged, the remaining 1 is split into 2 smaller chunks. This falls into a similar situation as document update (example 1), and CocoIndex will take care of it. The approach is similar, while this involves some additional considerations: We can still safely reuse embeddings for 4 unchanged chunks by the caching mechanism: this needs an prequisite that the logic and spec for embedding is unchanged. If the changed part is the embedding logic or spec, we will recompute the embeddings for everything. CocoIndex is able to see if the logic or spec for a operation step is changed from the cached version, by putting these additional information in the cache key.
To remove stale rows in the target index, the lineage tracking works well again. Note that some other systems handle stale output deletions on source update/deletion by replaying the transformation logic on the previous version of input: this only works well when transformation is fully deterministic and never upgraded. CocoIndex's lineage tracking based approach doesn't have this limitation: it's robust to transformation logic non-determinism and changes. We can still safely reuse embeddings for 4 unchanged chunks by the caching mechanism: this needs an prequisite that the logic and spec for embedding is unchanged. If the changed part is the embedding logic or spec, we will recompute the embeddings for everything. CocoIndex is able to see if the logic or spec for a operation step is changed from the cached version, by putting these additional information in the cache key. To remove stale rows in the target index, the lineage tracking works well again. Note that some other systems handle stale output deletions on source update/deletion by replaying the transformation logic on the previous version of input: this only works well when transformation is fully deterministic and never upgraded. CocoIndex's lineage tracking based approach doesn't have this limitation: it's robust to transformation logic non-determinism and changes. Example 4: Multiple inputs involved: Merge / Lookup / Clustering All examples above are simple cases: each single input row (e.g. a document) is involved independently during each specific transformation. CocoIndex is a highly customizable framework, not only limited to simple chunking and embedding. It allows users for more complex advanced transformations, such as: Merge. For example, you're bulding an index for "all AI products", and you want to combine information from multiple sources, some product exists in one source and some in multiple. For each product, you want to combine information from different sources.
Lookup. For example, you also have a data source about company information. During you transformation for each product, you want to enrich it with information of the company building the product, so a lookup for the company information is needed.
Clustering. For example, you want to cluster different products into scenarios, and create cluster-level summaries based on information of products in the cluster. Merge. For example, you're bulding an index for "all AI products", and you want to combine information from multiple sources, some product exists in one source and some in multiple. For each product, you want to combine information from different sources. Merge Lookup. For example, you also have a data source about company information. During you transformation for each product, you want to enrich it with information of the company building the product, so a lookup for the company information is needed. Lookup Clustering. For example, you want to cluster different products into scenarios, and create cluster-level summaries based on information of products in the cluster. Clustering The common theme is that during transformation, multiple input rows (coming from single or multiple sources) need to be involved at the same time. Once a single input row is updated or deleted, CocoIndex will need to fetch other related rows from the the same or other sources. Here which other rows are needed is based on which are involved in the transformations. CocoIndex keeps track of such relationships, and will fetch related rows and trigger necessary reprocessings incrementally. Change Data Capture (CDC) 1. When source supports push change Some source connectors support push change. For example, Google Drive supports drive-level changelog and send change notifications to your public URL, which is applicable for team drive and personal drive (only by OAuth, service account not supported). When a file is created, updated, or deleted, CocoIndex could compute based on the diff. 2. Metadata-based, last modified only Some source connectors don't support push change, but provide metadata and file system operations that list most recent changed files. For example, Google Drive with service account. CocoIndex could monitor the change based on last modified vs last poll time, periodic trigger to check modified. However this cannot capture full change, for example a file has been deleted. 3. Metadata-based, Fullscan Some source connectors have limited capabilities with listing files, but provide metadata that list all files. For example, with local files, we'd need to traverse all files in all directories and subdirectories recursively to get the full list. When the number of files is large, it's expensive to traverse all files. Cache In CocoIndex, every piece of the lego block in the pipeline can be cached. Custom functions can take a paramter cache. When True, the executor will cache the result of the function for reuse during reprocessing. We recommend to set this to True for any function that is computationally intensive. Output will be reused if all these unchanged: spec (if exists), input data, behavior of the function. For this purpose, a behavior_version needs to be provided, and should increase on behavior changes. For example, this enables cache for a standalone function, see full code example here: @cocoindex.op.executor_class(gpu=True, cache=True, behavior_version=1)
class PdfToMarkdownExecutor:
    """Executor for PdfToMarkdown."""
      ... @cocoindex.op.executor_class(gpu=True, cache=True, behavior_version=1)
class PdfToMarkdownExecutor:
    """Executor for PdfToMarkdown."""
      ...

Why Recompute Everything When You Can Use This Solution to Keep Your AI Index Fresh Automatically

Like most people in tech, I love my gadgets. Over the years, I’ve had  a Whoop, an Oura Ring, an Apple watch and a Garmin. But while I was drowning in data, I was starving for meaning. Like most people in tech, I love my gadgets. Over the years, I’ve had  a Whoop, an Oura Ring, an Apple watch and a Garmin. But while I was drowning in data, I was starving for meaning. I was tracking everything: steps, HRV, sleep, readiness scores, resting heart rate, calories, workouts. You name it. But despite all this data, I wasn’t seeing results. I wasn’t getting leaner. I wasn’t feeling more energized. I wasn’t making better choices. Instead, I was caught in what I now call the quantified self trap: drowning in data, but starving for meaning. quantified self trap Wearables Are Data-Rich, Insight-Poor Every app had its own dashboard, scores, colors, and buzzwords. I had streaks to maintain, rings to close, recovery zones to monitor, but nothing was translating into real behavior change. Most days I’d open three different apps and still not know what to do next. real What’s worse: I felt guilty. Like I was the problem. But I wasn’t the problem. The tools were. All this data was reactive. It told me what already happened. None of it helped me anticipate or design a better tomorrow. The Breakthrough: From Lagging Indicators to Leading Behaviors Eventually, I realized I was measuring the wrong things. Weight is a lagging indicator. HRV, too. Even readiness scores. What I needed were actionable, trackable, daily leading indicators—behaviors I could control. lagging leading indicators So I created a framework: North Star Goal: e.g., Improve my HRV, Lose 20 pounds, sleep better, have more energy
Lagging Indicators: weight, HRV, body fat percentage
Leading Behaviors: workouts, walking, sleep time, hydration, macros, etc.
Contextual Activities: travel, alcohol, screen time, sauna, meditation North Star Goal: e.g., Improve my HRV, Lose 20 pounds, sleep better, have more energy North Star Goal: Lagging Indicators: weight, HRV, body fat percentage Lagging Indicators: Leading Behaviors: workouts, walking, sleep time, hydration, macros, etc. Leading Behaviors: Contextual Activities: travel, alcohol, screen time, sauna, meditation Contextual Activities: I wanted to see how my inputs (behaviors) were actually impacting my outputs (results). Building Echo: The MVP I didn’t wait for funding or a cofounder. I used no-code tools to build Echo as an MVP for myself: Tally to create a simple daily journal where I log my behaviors.
Airtable to store my journal entries and wearable data.
Zapier to automate reminders and data updates.
Google Docs and Slides to generate monthly reports with charts showing correlations between behaviors and results. Tally to create a simple daily journal where I log my behaviors. Tally Airtable to store my journal entries and wearable data. Airtable Zapier to automate reminders and data updates. Zapier Google Docs and Slides to generate monthly reports with charts showing correlations between behaviors and results. Google Docs Slides Designing Experiments and Running Correlation Analysis What really brought Echo to life was treating my body like a sandbox for experimentation. I began running structured, self-directed experiments: What happens to my HRV if I take magnesium at night?
Does walking 8,000+ steps daily improve my fat loss more than just hitting workouts?
How does alcohol affect my sleep and my next-day energy? What happens to my HRV if I take magnesium at night? Does walking 8,000+ steps daily improve my fat loss more than just hitting workouts? How does alcohol affect my sleep and my next-day energy? and Using multivariable correlation analysis within Airtable and Google Sheets, I was able to examine patterns across weeks. Not just one-to-one relationships, but compounded ones—e.g., how sleep and protein intake influenced fat loss. Or how travel and poor hydration and late-night eating created weight spikes. and and and These weren’t random guesses anymore. They were real, personal insights backed by data. What I Learned (and am learning) Within two months of using Echo, I had insights I’d never gotten from any app: I always gained weight the week after a trip, even if I ate "okay"
Alcohol impacted my HRV more than sleep
My weight loss stalled every time I skipped morning walks, even with workouts
Travel + bad sleep + no walks = guaranteed fat gain I always gained weight the week after a trip, even if I ate "okay" Alcohol impacted my HRV more than sleep My weight loss stalled every time I skipped morning walks, even with workouts Travel + bad sleep + no walks = guaranteed fat gain Most importantly, I started making better choices—not because I was being forced to, but because I understood myself. understood I had designed a feedback loop that worked for me. me The Unexpected Ripple Effects When friends saw my monthly report, they asked me how I made it. Some started tracking the same way. A few asked if they could pay me to set it up for them. That’s when I realized: maybe Echo isn’t just for me. What’s Next for Echo I’m now working on turning Echo into a more complete product. A real app with: Direct integrations into wearables (Garmin, Apple, Fitbit, Whoop)


A smart journal that asks you the right questions based on your goals


A coaching layer that suggests weekly focus areas


A monthly report that turns data into insight—and insight into action Direct integrations into wearables (Garmin, Apple, Fitbit, Whoop) Direct integrations into wearables (Garmin, Apple, Fitbit, Whoop) A smart journal that asks you the right questions based on your goals A smart journal that asks you the right questions based on your goals A coaching layer that suggests weekly focus areas A coaching layer that suggests weekly focus areas A monthly report that turns data into insight—and insight into action A monthly report that turns data into insight—and insight into action No social feeds. No gamification. No vanity scores. Just real behavior change. Why I’m Building This Because I think a lot of people are like me. They’re not lazy. They’re not unmotivated. They’re just overwhelmed. They want to change. They want to feel better. But the data isn’t helping them decide what to do. decide Echo is my attempt to fix that. Not with gimmicks. But with clarity, simplicity, and reflection. Because the truth is: your body is already talking to you. You just need a system that knows how to listen. Want to try Echo? Want to try Echo? I'm looking for early testers who want to join the next round of experimentation. If you're using a wearable, have a goal you're trying to reach, and want to actually learn from your data, let’s connect. learn Sign up on my tally form https://tally.so/r/mZeNZV or visit www.logwithecho.com and I’ll set you up with a personalized journal and monthly insight report. https://tally.so/r/mZeNZV www.logwithecho.com Let’s turn your data into direction.

I Built an App to Hack My Health Using Data from My Garmin, and It Changed Everything

Introduction Picture this: you start a new project and, out of sheer habit, decide to slap a UUID as the ID on every single table. “What could possibly go wrong?”—after all, UUIDs are universal, globally unique, and basically the coolest thing out there, right? Sound familiar? In reality, this widespread fascination with UUIDs can drag down performance, bloat your indexes, and give you unnecessary headaches when maintaining your database. Let’s take a closer look at why UUIDs aren’t always the perfect fix and when they actually make sense. When UUIDs Actually Make Sense Distributed Systems A prime case for using UUIDs is when you’ve got dozens (or even hundreds) of independent nodes, each creating records without a shared counter. In that scenario, generating unique IDs locally is a lifesaver—it avoids collisions and doesn’t rely on a central coordinator. Generating the ID Up Front Sometimes, you need an object’s identifier before it even hits the database. Think of a mobile app that pre-creates an order and instantly needs an order number. With auto-increment from the DB, you have to insert first, then wait for a response; with a UUID, you’re good to go right away. Making It Hard to Guess Another big plus for UUIDs: they’re not easy to brute-force. If you’re building a public API or dealing with magic links (like password reset URLs), being unpredictable is crucial. While there are alternative ways to protect your endpoints (tokens, hashes, etc.), UUIDs are often chosen for convenience. Hiding the Insertion Order If you don’t want people to know how many rows are in your database or how fast they’re being added, auto-increment keys might spill the beans. A random-looking UUID is way less obvious and won’t let anyone figure out when or how many records you’ve inserted. Common Pitfalls and Gotchas With UUID Index Size and Overhead The first and most overlooked point: a UUID is 16 bytes, whereas BIGINT is only 8. No biggie for small datasets, but multiply that difference by hundreds of millions of rows, and your indexes could practically double in size. Bigger indexes mean more I/O, which can eat into performance. Fragmentation and Insertion Order Next, when you use sequential IDs, new entries typically end up at the “end” of the index—minimal fragmentation. But a UUID v4 is random, scattering new keys all over the place and forcing frequent page splits. This causes index bloat, more overhead, and extra maintenance (like VACUUM in PostgreSQL), leading your database to bulk up and slow down. Insert Performance Which ties into our third point: inserting in ascending order is easier, while random inserts require more fuss. The system has to figure out where to put each new record in the index, and if the index is already beefy, that’s even more overhead. Read Performance (Exact Lookups) Both BIGINT and UUIDs theoretically have O(log n) search time in a b-tree, but if your UUID-based index is bloated, you’ll be reading more pages off disk. On small-scale projects, that may not matter, but once you hit massive volumes—billions of rows—those extra reads can stack up and cause noticeable slowdowns. Index Size vs. Cache When an index swells beyond what fits in shared_buffers or the OS page cache, the database has to do more disk I/O. In a high-load setting, that’s a recipe for bottlenecks and lag. The “Magical Sharding” Misconception Some folks assume that random UUIDs magically deliver perfectly distributed sharding. In reality, proper sharding calls for a deliberate approach—hash-based, range-based, consistent hashing, etc. Simply generating random IDs won’t guarantee load balancing for free. Uniqueness and ID Generation Sure, a UUID is fantastic if you need to generate globally unique IDs without coordination—like if multiple nodes are all inserting data on their own. But if you’ve got a single service hitting a single database, “global uniqueness” might be overkill, adding more complexity than actual value. How to Handle It (and Keep Your DB Happy) If Possible, Go for Auto-Increment (IDENTITY, BIGSERIAL) In many situations, a straightforward auto-increment setup is a slam dunk: you get faster performance and smaller indexes. Plus, if your users’ data is protected by authentication and a well-thought-out ACL or RBAC model, there’s really no worry—nobody can peek at someone else’s records by guessing IDs. The Hybrid Approach Nothing stops you from using sequential IDs internally and then translating them into some kind of randomized string (token, UUID, hash, etc.) when exposing them via an external API. That way, everything is efficient inside your system, and outsiders remain blissfully unaware of your real IDs under the hood. Don’t Expect Automatic Sharding Magic If you’re dealing with sharding, you’ll still need a solid plan. UUIDs alone aren’t a silver bullet for distributing data—hash functions, consistent hashing, or ranges have to be properly tuned. “Random = perfect distribution” is wishful thinking, not a real strategy. Conclusion Here’s the bottom line: UUIDs are a lifesaver when you’re dealing with a truly distributed system or when you need to know your IDs upfront or make them unguessable. But if you’ve only got one service writing to one database and don’t actually need that global uniqueness, you’ll likely suffer more from oversized indexes and random insertion patterns than you’ll benefit. Remember, the choice of which type to use should be deliberate. If you need randomness or that global uniqueness, go ahead and use a UUID. Otherwise, stick with classic sequential IDs. Making a mindful decision about your ID strategy keeps your database lean and your development process running smoothly—no extra baggage required. Introduction Picture this: you start a new project and, out of sheer habit, decide to slap a UUID as the ID on every single table. “ What could possibly go wrong?” —after all, UUIDs are universal, globally unique, and basically the coolest thing out there, right? Sound familiar? What could possibly go wrong?” In reality, this widespread fascination with UUIDs can drag down performance, bloat your indexes, and give you unnecessary headaches when maintaining your database. Let’s take a closer look at why UUIDs aren’t always the perfect fix and when they actually make sense. When UUIDs Actually Make Sense Distributed Systems A prime case for using UUIDs is when you’ve got dozens (or even hundreds) of independent nodes, each creating records without a shared counter. In that scenario, generating unique IDs locally is a lifesaver—it avoids collisions and doesn’t rely on a central coordinator. Generating the ID Up Front Sometimes, you need an object’s identifier before it even hits the database. Think of a mobile app that pre-creates an order and instantly needs an order number. With auto-increment from the DB, you have to insert first, then wait for a response; with a UUID, you’re good to go right away. Making It Hard to Guess Another big plus for UUIDs: they’re not easy to brute-force. If you’re building a public API or dealing with magic links (like password reset URLs), being unpredictable is crucial. While there are alternative ways to protect your endpoints (tokens, hashes, etc.), UUIDs are often chosen for convenience. magic links Hiding the Insertion Order If you don’t want people to know how many rows are in your database or how fast they’re being added, auto-increment keys might spill the beans . A random-looking UUID is way less obvious and won’t let anyone figure out when or how many records you’ve inserted. spill the beans Common Pitfalls and Gotchas With UUID Index Size and Overhead The first and most overlooked point: a UUID is 16 bytes, whereas BIGINT is only 8. No biggie for small datasets, but multiply that difference by hundreds of millions of rows, and your indexes could practically double in size. Bigger indexes mean more I/O, which can eat into performance. Fragmentation and Insertion Order Next, when you use sequential IDs, new entries typically end up at the “end” of the index—minimal fragmentation. But a UUID v4 is random, scattering new keys all over the place and forcing frequent page splits. This causes index bloat, more overhead, and extra maintenance (like VACUUM in PostgreSQL), leading your database to bulk up and slow down. Insert Performance Which ties into our third point: inserting in ascending order is easier, while random inserts require more fuss. The system has to figure out where to put each new record in the index, and if the index is already beefy, that’s even more overhead. Read Performance (Exact Lookups) Both BIGINT and UUIDs theoretically have O(log n) search time in a b-tree, but if your UUID-based index is bloated, you’ll be reading more pages off disk. On small-scale projects, that may not matter, but once you hit massive volumes—billions of rows—those extra reads can stack up and cause noticeable slowdowns. Index Size vs. Cache When an index swells beyond what fits in shared_buffers or the OS page cache, the database has to do more disk I/O. In a high-load setting, that’s a recipe for bottlenecks and lag. The “Magical Sharding” Misconception Some folks assume that random UUIDs magically deliver perfectly distributed sharding. In reality, proper sharding calls for a deliberate approach—hash-based, range-based, consistent hashing, etc. Simply generating random IDs won’t guarantee load balancing for free . for free Uniqueness and ID Generation Sure, a UUID is fantastic if you need to generate globally unique IDs without coordination—like if multiple nodes are all inserting data on their own. But if you’ve got a single service hitting a single database, “global uniqueness” might be overkill, adding more complexity than actual value. How to Handle It (and Keep Your DB Happy) If Possible, Go for Auto-Increment (IDENTITY, BIGSERIAL) In many situations, a straightforward auto-increment setup is a slam dunk: you get faster performance and smaller indexes. Plus, if your users’ data is protected by authentication and a well-thought-out ACL or RBAC model, there’s really no worry—nobody can peek at someone else’s records by guessing IDs. The Hybrid Approach Nothing stops you from using sequential IDs internally and then translating them into some kind of randomized string (token, UUID, hash, etc.) when exposing them via an external API. That way, everything is efficient inside your system, and outsiders remain blissfully unaware of your real IDs under the hood. Don’t Expect Automatic Sharding Magic Automatic If you’re dealing with sharding, you’ll still need a solid plan. UUIDs alone aren’t a silver bullet for distributing data—hash functions, consistent hashing, or ranges have to be properly tuned. “Random = perfect distribution” is wishful thinking, not a real strategy. Conclusion Here’s the bottom line: UUIDs are a lifesaver when you’re dealing with a truly distributed system or when you need to know your IDs upfront or make them unguessable. But if you’ve only got one service writing to one database and don’t actually need that global uniqueness, you’ll likely suffer more from oversized indexes and random insertion patterns than you’ll benefit. Remember, the choice of which type to use should be deliberate. If you need randomness or that global uniqueness, go ahead and use a UUID. Otherwise, stick with classic sequential IDs. Making a mindful decision about your ID strategy keeps your database lean and your development process running smoothly—no extra baggage required. mindful decision

UUID Makes Everything Better… Doesn’t It?

A good old friend has left the company he had worked for five years. As he said, amazing five years. And when he left, this time and for the first time, he left a farewell celebration, as a song. It’s a song that you can listen, in Portuguese, and the lyrics are translated to English at the end. It went on like this: Another book has come to an end. Together, the conquest, the arrival, mission accomplished. But too, the missing, the trajectory, that good vibe. Another book has come to an end. Together, the conquest, the arrival, mission accomplished. But too, the missing, the trajectory, that good vibe. https://www.udio.com/songs/8T8sTSAa8jS7s1Du8qAjUq?embedable=true https://www.udio.com/songs/8T8sTSAa8jS7s1Du8qAjUq?embedable=true So, that is how he started, his reflective moment. And there are other great ones like that, or done as a reflection or meditation. But to me, as a writer for life, I am following along with my friend here. We know about the book of our lives, I know. But having him see his job’s mission, like a book, he had taken me back to that great way to see our work relationships like books, or like a Tour of Duty if you will. With that, and following along, I ask him and us: reflection or meditation. Tour of Duty Why Not Write a Book? I say this because you said it first. I agree that another book was closed, and what’s next is a book, too. So, as for what’s next, to you and me and to us, I ask, and remind us too, why not write an actual book? you Because with a book, you can move forward. You could really use some time like that, couldn’t you? Could you be sponsored or protected by your own Foundation? So, there we are, allow me to celebrate: what a chance to learn, and to make progress. what a chance to learn, and to make progress. What a chance for you, perhaps, to be closer to that kind of reflective writing that I know matters a lot to you. And as well, to be closer to that very audience that listens to you, the ones who make decisions, the same ones who need to make decisions with good thoughts. With a book, you are too solving a problem — any problem — as you always do, naturally. But it’s interesting too because with a book you may not even need a specific problem. Maybe just a theme is enough. The book takes care of itself, the book unfolds from the theme. With a book, I know, too, that whatever your next book is, it will also help you address those other challenges in the realm of our internal journey. It takes care of a problem for the outer and the things of our inner world. What is interesting about the book is that we know or feel them quite close to us, don’t we? Even if it often feels far away. It’s mixed. And although it may seem lonely, it’s not; we know it too. How a book is such a collaborative journey with the world. It’s a good place to be there, through the journey. A good place and a meaningful duty to commit to. With so many things happening right now, right next to us — on the outside, we know  — and inside too, sometimes thinking about a book can be overwhelming, I know. But, a great writer, Dorothea Brande, in 1934, wrote that “you can write about anything which has been vivid enough to cause you to comment upon it.” This is it, isn’t it? The things we want to comment, the things we want to sing, or yell sometimes too. This is a bit of how I walk now. Watching out, trying to be sensitive to these little sprouts of comments on my way. Comments I used to pass by, missing them, stepping on them. But they were there, and are there: small sprouts trying to break through, to rise, from our fertile garden. Those little things are the links to that vivid enough underlying thing, sometimes huge. It’s worth pouring water and words. Through writing. So I wish you, today, to write an actual book. But if that book of yours doesn’t materialize as a book that looks like a book, yet one thing we have agreed with, already. It will always be a book. Prólogo [Prologue] by Concept ACK [verse] [verse] Another book has come to an endThat mixed, unique, and confused tasteTogether, the conquest, the arrival, mission accomplished Another book has come to an endThat mixed, unique, and confused tasteTogether, the conquest, the arrival, mission accomplished And too, I miss, that trajectory, that good vibe. And too, I miss, that trajectory, that good vibe. So what's the next? So what's the next? [chorus] [chorus] This one is over, what will come next?“All things must pass,” GH tells me This one is over, what will come next?“All things must pass,” GH tells me So much coherence... So much coherence... [verse] [verse] A fresh start not in a hurry, A fresh start not in a hurry, Prologue!After a farewell without bitterness, a see you laterClean inventory, zero hours, no XP...Which class should I choose? Prologue!After a farewell without bitterness, a see you laterClean inventory, zero hours, no XP...Which class should I choose? [intermission][humming la-la-la] [intermission][humming la-la-la] [bridge]In the six-one rhythmThe meter suppresses the pawn... the queen, the bishopNot cool, guys, living by the card? Not cool...What's next? [bridge]In the six-one rhythmThe meter suppresses the pawn... the queen, the bishopNot cool, guys, living by the card? Not cool...What's next? [verse]Today, headphones have given way to the speakerThe sound fills my office...now it's a studioWithout a gold chain, but with historyWho’s going to turn off the light?It's not so dark anymore [verse]Today, headphones have given way to the speakerThe sound fills my office...now it's a studioWithout a gold chain, but with historyWho’s going to turn off the light?It's not so dark anymore [chorus]A sprint without a backlogThe coffee is in another kitchenThe guitar came off the wallThe cursor blinks on the first line [chorus]A sprint without a backlogThe coffee is in another kitchenThe guitar came off the wallThe cursor blinks on the first line Credits: Prologue, by Concept ACK Prologue, by Concept ACK

Every Job Is a Book, Isn't It? 

Welcome to MTP Business Boost — a series of expert publications filled with real-world strategies, transforming complex ideas into simple, actionable advice you can apply immediately (MTP stands for Marketing, Technology, and Psychology). In just 9 minutes, you’ll uncover how AI isn’t just adapting marketing communication for different generations—it’s giving businesses the power to dominate. By leveraging AI-driven personalization and precision, you can craft messages that resonate deeply, drive higher engagement, maximize conversions, and secure long-term customer loyalty. The result? Reduced costs, a stronger competitive edge, and undeniable market leadership. Personalization isn’t just a trend—it’s an expectation. A McKinsey study found that 71% of consumers expect personalized interactions, and 76% feel frustrated when companies fail to deliver them. This frustration often leads to lost sales and weakened brand loyalty. On the flip side, companies that embrace personalization can see revenue increases of 5-15% and a boost in marketing ROI by 10-30%. Without it, businesses risk inefficiencies in customer acquisition and retention, ultimately falling behind their competitors (source). source source Before you dive in, make sure you’re subscribed so you don’t miss the next expert insights packed with practical recommendations. Let’s get started! Weekend on a Yacht and Unexpected Consequences Weekend on a Yacht and Unexpected Consequences The golden hues of the Sydney sunrise painted the glass towers in warm amber as Alex leaned back in his sleek office chair, staring at the analytics report on his screen. His IT startup, a promising SaaS company specializing in cybersecurity solutions, had been steadily growing. But now, the data revealed an unexpected challenge—his customer base spanned multiple generations, each responding differently to marketing messages. What worked for Gen Z seemed irrelevant to Boomers, and Millennials had their own distinct preferences. Frustration crept in. How could he fine-tune his communication without hiring a team of specialists or overhauling his entire strategy? The budget was tight, the stakes were high, and he couldn’t afford to misstep. Just then, his phone buzzed. It was Daniel, an old friend and fellow entrepreneur, but leagues ahead in the game—seasoned, successful, and always three steps ahead. "Mate, your voice sounds tense. You need to unwind. Come spend the weekend on my yacht. A little time away will do you good." Alex hesitated. Leaving work for an entire weekend? Now? But something about Daniel’s tone made him reconsider. And so, with a mix of reluctance and curiosity, Alex accepted. The Sydney Harbour shimmered under the midday sun, a dazzling contrast to the deep blue waters. As Alex stepped onto Daniel’s sleek, state-of-the-art yacht—a floating masterpiece of luxury—he felt an unexpected sense of release. Polished teak, crisp ocean air, and the gentle lapping of waves made the city’s worries feel miles away. Over gourmet seafood and a chilled bottle of vintage Chardonnay, Alex shared his predicament. Daniel listened, nodding knowingly. "You’re making it harder than it needs to be," he finally said. "AI can handle this in minutes. It can analyze generational preferences, tailor messaging to their values and interests, and ensure each group receives communication that truly resonates." Alex raised an eyebrow. AI? Sure, his company used machine learning for cybersecurity, but for marketing? Daniel smirked, pulled out his tablet, and with a few taps, demonstrated how AI could segment audiences, adapt messaging for different generations, and align content with their unique expectations and behaviors. The next morning, back in his office, Alex hesitated for only a second before trying it himself. Within minutes, AI had analyzed his customer segments, optimized messaging for each generation, and provided actionable insights. It was effortless. It was powerful. And it worked. As he leaned back, a satisfied grin spread across his face. This wasn’t just a solution—it was a revelation. For the first time in weeks, he felt in control, ahead of the curve. And to think, it all started with a simple phone call and a weekend on a yacht. Winning Every Generation: AI-Powered Messaging Guide Let’s take an example and see how to adapt a marketing message for different generations. We’ll use a sample ad from a hypothetical SaaS company offering a sales automation product. Here’s the original marketing message: Boost your sales like never before with the ultimate SaaS solution for automating your pipeline! Say goodbye to manual follow-ups and hello to smart workflows that save you time and close deals faster. With AI-powered insights, you’ll know exactly when to reach out to prospects for maximum impact. Try it today and watch your revenue soar in just weeks. Sign up for a free 14-day trial – no credit card required! I recommend taking your own marketing message, following the steps below, and applying them right away. This way, you’ll put the knowledge into practice and see results quickly. Go to chatgpt.com Go to chatgpt.com chatgpt.com 2. Paste the following instruction for the AI and press Enter: Hello. You are a world-class expert in effective marketing communications. I need help adapting the following advertising message for optimal reception by my audience, which consists of the Baby Boomer generation. Hello. You are a world-class expert in effective marketing communications. I need help adapting the following advertising message for optimal reception by my audience, which consists of the Baby Boomer generation. Boost your sales like never before with the ultimate SaaS solution for automating your pipeline! Say goodbye to manual follow-ups and hello to smart workflows that save you time and close deals faster. With AI-powered insights, you’ll know exactly when to reach out to prospects for maximum impact. Try it today and watch your revenue soar in just weeks. Sign up for a free 14-day trial – no credit card required! Boost your sales like never before with the ultimate SaaS solution for automating your pipeline! Say goodbye to manual follow-ups and hello to smart workflows that save you time and close deals faster. With AI-powered insights, you’ll know exactly when to reach out to prospects for maximum impact. Try it today and watch your revenue soar in just weeks. Sign up for a free 14-day trial – no credit card required! Instead of “Baby Boomer,” you can swap in the generation your customers belong to: The Silent Generation (born 1928–1945)


Gen X (born 1965–1980)


Millennials, Gen Y (born 1981–1996)


Zoomers, Gen Z (born 1997–2012)


Gen Alpha (born 2013–2025) The Silent Generation (born 1928–1945) The Silent Generation (born 1928–1945) Gen X (born 1965–1980) Gen X (born 1965–1980) Millennials, Gen Y (born 1981–1996) Millennials, Gen Y (born 1981–1996) Zoomers, Gen Z (born 1997–2012) Zoomers, Gen Z (born 1997–2012) Gen Alpha (born 2013–2025) Gen Alpha (born 2013–2025) Here’s how the AI adapted the message for the Baby Boomer generation: 3. You can also ask the AI to explain why the adapted message works for that generation. Use this instruction: Write a detailed argument explaining why this advertising text is suitable for the generation of my clients. Write a detailed argument explaining why this advertising text is suitable for the generation of my clients. Here’s how the AI explained it in our example: 4. Now, let’s ask the AI to adapt the message for another generation, like Gen Y (born 1981–1996): Now, adapt this advertising message for Generation Y and explain why it is effective specifically for this generation. Now, adapt this advertising message for Generation Y and explain why it is effective specifically for this generation. The AI will also explain why the message fits Gen Y. 5. You can also have the AI adapt the message for all generations at once to compare them: Adapt this advertising message for all generations and present the results in a table format Adapt this advertising message for all generations and present the results in a table format 6. Plus, you can get the table as an Excel file: Generate this table in Excel format Generate this table in Excel format Besides Excel, the AI can provide the results in CSV or PDF formats. 7. You can also ask the AI for specific tips on communicating with your customers’ generation. In our example, try this instruction: Write the most effective recommendations for communication with the Baby Boomer generation. My product is a sales automation service Write the most effective recommendations for communication with the Baby Boomer generation. My product is a sales automation service 8. To make your communication with clients as effective as possible and avoid missteps, ask the AI: What mistakes should be avoided in communication with the Baby Boomer generation and why? What mistakes should be avoided in communication with the Baby Boomer generation and why? 9. After getting a lot of information from the AI, you can ask it to summarize everything into a handy PDF: Summarize all the information in this dialogue and present it in PDF format Summarize all the information in this dialogue and present it in PDF format Here’s what the AI-generated PDF might include: Extra Tips With AI, you can adapt almost any type of marketing communication: emails, Google Ads, social media posts, sales proposals, landing page content, and more. If you have data on your customers’ ages, you can group them by generation and make your communication even more personal and targeted. For example, if your email list has 100,000 subscribers—30,000 from Gen X and 70,000 from Gen Y—a single generic email might not work as well as two versions tailored to each generation. Now you know how to do this with AI, and it only takes a few minutes! Test the results to see the impact of adapting your marketing for specific generations. For instance, when sending an email, create two versions and check which one gets better conversions. Summary In this article, you’ve learned how to easily and quickly adapt your communication with clients based on the psychological perception of the generation they belong to. If the knowledge you gained from this article has been valuable and helpful to you, you can show your appreciation to the author by making a donation via this link or giving a like and sharing it. this link this link Would you also like to learn more about how AI can be used to grow your business and increase your market share? Feel free to leave your questions in the comments! About the Author Gene Misiev is a marketing expert with over seven years of experience in digital marketing. He thrives in highly competitive "red ocean" B2B markets. His focus is on growth marketing, market research, and strategic development for a complex SaaS product—a tender platform for government and private procurement. He has completed advanced training in Strategic Marketing and Generative AI applications in business at the Institute of Applied Technology (Australia). He has also undertaken specialized courses in leveraging ChatGPT for business and marketing automation. See You in the Next Issue Thanks for reading! Make sure you’re subscribed so you don’t miss the next publication, which will bring even more insights to help you expand your business empire with the power of marketing, technology and psychology.

Want to Boost Your Sales? AI Knows Exactly How to Speak to Every Generation

The tech industry is at the forefront of cutting-edge innovation. Everywhere you turn, someone's talking about disruption, transformation, or unlocking new possibilities – but the truth is, not every new tech trend aligns with actual user needs. And as product managers, we would do well to remember that the innovation should always serve the customer, not the trend. Last week, I was invited to share my experiences of leading product at companies working with emerging technologies like artificial intelligence (AI) and the new iteration of the internet focussed on data ownership (web3) on a Product People webinar. Using a few examples from my career, I argued for ignoring the hype and focussing on solving real user needs – aligned, of course, to business objectives – when introducing AI or web3 into the product. Product People webinar Understanding the temptation Understanding the temptation Of course, it's tempting to jump on the bandwagon. After all, if everyone is hyped up about something, shouting about how it's going to change the world, that energy can be contagious. Even more so in the tech sector, where we're all afraid of missing out on the next big thing. So whether it's accepting crypto or integrating AI tools, there's often pressure – from consumers, from leaders, from investors, hell, even from ourselves – to "do something with the trend". But here's the catch – just because we have access to a new technology doesn't mean it makes sense for our users. A cautionary example is the way businesses have been introducing AI chatbots. Sure, you can now say that you're AI-powered, but how is the experience for your typical user? Far too often, poorly executed chatbots frustrate users rather than helping. Instead of enhancing their interaction with your product, it can lead to friction as they struggle to get access to human support agents. In other words, adding AI just for the sake of it can end up alienating the very users it's meant to serve. It's not all about the tech It's not all about the tech This tends to happen because we get so caught up in the possibilities of the technology that we forget the most important thing, what problem are we solving? This is especially relevant when we talk about driving adoption of new technologies. technology what problem are we solving I was once on a panel with a woman who'd been an early adopter of Bitcoin and blockchain-based currencies more generally, and she drew a comparison with the success of Skype and no one caring about Voice over Internet Protocol (VoIP). The underlying technology is secondary. Its main purpose is helping you achieve your goals quickly and easily. Skype helped connect you to relatives across the world without paying exorbitant fees, that's the value. helping you achieve your goals quickly and easily that's The other interesting thing to highlight from my fellow panellist's observation is that, of course, it benefits from hindsight. We know (as we knew then) what problems Skype was solving, but we didn't know at the time whether the Skype protocol would win over the other variations of protocols being developed. I must admit that I don't know the history in detail, but I would hazard a guess that user experience had something to do with Skype's ultimate success. hindsight didn't In the same way, blockchain is just the facilitator[1]. Of course, there are significant advantages in terms of security and permanence, but ultimately, it's about the problem it's solving for users. And right now, it's lacking on the user experience side, though we have made great strides in improving this. I'm personally a firm believer that blockchain, crypto, NFTs, and especially AI do add value, but my overarching point is that we as product managers need to look past the technology and solve for users. have do Uncovering the "why" Uncovering the "why" As such, when it comes to our users, we need to get to know them so well that we can anticipate their needs and build solutions without worrying about the underlying technology. There's the often-quoted Henry Ford statement that if he had asked user what they wanted, they would've said a faster horse. While it's unlikely that he actually said this, not the least because he didn't actually invent the car, the quote conveys an important point about the user need state to (a) get somewhere faster and (b) to be able to afford it. Ford's invention, therefore, becomes the solution to a very specific problem – getting from point A to point B more efficiently. without worrying about the underlying technology Therefore, it's always a good idea to take a step back and ask a simple question: why? Why are we adding [insert feature here]? If you can't answer in a way that addresses a key business objective, whether that's increased revenue, improved retention, better engagement, or whatever else, through a better customer experience, it's time to reconsider. It's easy to get caught up in the hype and think that blockchain or AI or some other new technology is the magical silver bullet solution, but you can't lose sight of what you're trying to achieve – both as a business and as the product with the customer top-of-mind. why The benefits of web3 and AI The benefits of web3 and AI So what benefits are there in web3 and AI? Of course, we haven't yet reached the mass adoption of, say, Skype circa 2013, and it remains to be seen whether we will from a consumer side. From the consumer side, there's a disconnect between the promise (store of value) and the reality (speculation) of crypto, as well as the promise (owning IP) as well as the reality (again, speculation) of NFTs – so while the technology is innovative, the why hasn’t been fully addressed, at least not for consumers. But blockchain is already being used in government and business applications. Estonian and American government bodies, for example, are using the KSI blockchain for protecting privacy and security. Governments and big companies store value in bitcoin. are consumer side why is And then when we think about AI, it's more of the same. Maybe we haven't quite identified the overarching why of consumer AI, though in my personal opinion, it's just a matter of time before mass adoption for the simplification of mundane tasks (my mother regularly uses DeepL to check her English, neurodiverse acquaintances swear by ChatGPT for tackling simple emails that would otherwise take hours, etc). From a business perspective, however, AI is already embedded into our meeting software, into collaboration tools, and even into the core of software development through tools like GitHub Copilot, with more use cases added daily. why Knowing when to pivot Knowing when to pivot A few years ago, I was working with a company that encountered this very problem – it failed to find product market fit among consumers, but found it for businesses. This was a mission-driven crypto startup focussed on bringing Bitcoin to emerging markets as a hedge against inflation. We gamified the experience, rewarding users with small amounts of bitcoin for engaging with the platform. On paper, this seemed like a great way to build user engagement, but the reality was that this didn't support our business goals long term. consumers businesses Given the market and the industry, we had to do everything by the book – complying with regulation, receiving the necessary licenses, partnering with banks and authorities. This was not without its challenges, often financial. It quickly became apparent that our target audience wasn't able to sustain our growth ambitions, and while target users were using us to earn bitcoin, we weren't seeing enough traction in terms of transactions to make any money off the exchange. Now, I was young, a bit naïve, and so committed to the mission as central to the product – in other words, the technology and the mission became inextricably entwined for me – that I left when the CEO decided to pivot, leveraging all our banking relationships and licenses to actually improve the experience of transferring money to more complicated regions using blockchain rails and our user-friendly UI. But with the wisdom of hindsight, I can admit that this use case actually solves a problem and adds value for users, and, from a business perspective, it's a clever repackaging of our existing tech and partner stack to solve a different problem for a different set of users. These new users don't care that the money transfers are cheap and convenient because of blockchain, they just care that they're cheap, secure, and get the funds to a heavily regulated market compliantly. because When technology becomes the solution to a problem that doesn't exist When technology becomes the solution to a problem that doesn't exist But it doesn't always work that way. Sometimes, we want to work the technology into the solution so much that the problem we're solving for users is forgotten. In another company I worked for, the founding mission was the ability to register Certificates of Authenticity for physical artworks on the blockchain as a permanent record, which matters to artists who want to track provenance. Blockchain was seen as a solution to the question of permanence, as well as security. The issue was adoption – this is an issue for the art world generally, why there isn't a single database of Certificates of Authenticity is that each artist, gallery, museum or whatever it may be issues their own, which makes it difficult to track and authenticate. So while there was a use case, the same issue pursued the startup, because in order for these Certificates to continue to exist as intended to, they needed to be transferred alongside the artwork. This was then complicated by the emergence of NFTs and our company's entry into the space, because NFTs were intended, first and foremost, to serve as proof of ownership in and of themselves – you own the NFT, therefore you own the underlying art, and any transactions are visible on the blockchain, therefore establishing provenance. However, instead of doubling down on the use case and pursuing the vision of establishing an immutable repository of Certificates, we focussed on the technology, and tried to certify NFTs alongside physical works. The logic being that NFTs can be faked, because it's easy to make an NFT with an underlying image that isn't your artwork – though, of course, NFTs track which address created the artwork, so the artists for whom this matters can prove or disprove authorship anyway. So how does this all reflect on the problem we were trying to solve? Well, the issue is that the decisions we were making (pursuing NFTs in parallel to certification) were contradicting the why of what we were doing (establishing authenticity of certification). And, of course, the big one – we were solving a very niche problem in a very complicated way, which prevented us from driving adoption by focussing on simplifying user needs. The main takeaway being, of course, that before getting too carried away with how to build the solution, determine whether the problem being solved matches your business objectives. simplifying Build or buy? Build or buy? To top it all off, there's the additional consideration of whether to build the solution yourself or to delegate the work to a third party. This becomes especially relevant when it concerns AI, because ownership of the underlying data model is a competitive advantage. In my current organisation, we have a number of products that are introducing AI-powered solutions that address specific user need states, such as manual and labour-intensive purchase invoicing. This kind of repetitive process with clear parameters is ripe for AI automation. Why AI? Because it needs to account for nuance in business operations, which is why attempting to address it with rule-based processing is not sufficient. But this kind of solution comes with additional considerations of tradeoffs (time-to-market versus long-term value, as well as who builds it and who handles the legal questions like data processing), all within the context of the breakneck pace of AI. nuance In Silverbucket, the product I am currently working on, there are many areas in which we can improve usability through AI, both internally and customer-facing. The important thing is to recognise what is actually relevant for us – for example, there's no need for us to screen "easy" customer service queries trained on our knowledge base, because we don't typically get any queries that don't require engineering. This then paves the way for a more comprehensive question of how to build AI assistants for our customers, because a simple AI chatbot for the sake of it is unnecessary. The main question that we need to answer when we think about how our solution addresses user needs is, how do we facilitate the user's intended result in the easiest way possible? As you can see, that last question doesn't say anything about AI – but in our day and age, this can very well end up being the answer, which is something that we're therefore obligated to explore as a potential (but not only) solution. how do we facilitate the user's intended result in the easiest way possible? Conclusion Conclusion The main takeaway is that companies need to solve real pain points, and the technology is just there as a facilitator. If we use it correctly, our users benefit; if we don't, we risk alienating them. The only thing we can really rely on is continuous discovery – watching users, speaking to them, looking at product analytics, exploring their need states, and understanding how to solve their problems, and this can be with or without web3, blockchain, AI or whatever new technology appears on the horizon. [1] I do want to sound a note of caution here, because AI is a bit of a different beast, the inputs do matter, because they can replicate existing inequalities or spread misinformation, but that's somewhat of a different conversation. do

Stop Jumping on Every Tech Trend—Real Innovation Always Puts Users First

Crypto is a wild ride—a gold rush where fortunes flip overnight. But here’s the dirty secret: when the market moons, you might not be the miner striking it rich. You could be the gold itself, mined by the big players. Welcome to "Exit Liquidity 101," where retail traders like you and me get chewed up by whales - those early investors with deep pockets and deeper tricks. This isn’t a conspiracy theory; it’s a playbook, and it’s running rampant in 2025. From Solana memecoins to overhyped Layer 1s, I’ve watched it unfold too many times to stay quiet. Let’s break it down, expose the traps, and figure out how to stop being the whale’s next meal. The Grift Explained: What Is Exit Liquidity? The Grift Explained: What Is Exit Liquidity? Picture this: a shiny new token launches - maybe it’s $TRUMP, riding Donald’s inauguration buzz, or a Solana memecoin with a cute mascot and moon promises. The price skyrockets, your X feed lights up with “100x gem” chatter, and you jump in, heart pounding with FOMO. TRUMP That’s when the trap snaps shut. “Exit liquidity” is the moment your money - new retail cash, floods the market, giving whales their chance to sell high and cash out. They walk away with millions; you’re left clutching a token that’s suddenly worth pennies. It’s not random. Whales often hold 70-80% of a token’s supply at launch. TRUMP insiders reportedly control 80% of its 1 billion coins. They bide their time, waiting for the hype to peak, then dump. Blockchain analysts pegged TRUMP’s insider profits at $100 million in trading fees alone when it hit $14.5 billion in January 2025, only to crash to $16 per coin by February. It’s clockwork: check any chart after a rally, and you’ll see the pattern: sharp spike, sharper drop. You’re not buying into a revolution; you’re funding their yacht. TRUMP TRUMP The Marketing Mirage: How They Reel You In The Marketing Mirage: How They Reel You In By the way, want to uncover the psychology behind the most successful crypto projects? Follow me on X! As a marketing pro, I dive deep into the industry’s manipulations and share insights you won’t find anywhere else. Follow me on X As you might know, for years I've been running a marketing agency that’s one of the biggest and most rated in the crypto industry. So I know for sure - none of this works without marketing. The puppet master pulling every string. Take TRUMP: launched in January 2025, it soared to $75 per coin, fueled by Trump’s name and a flood of X posts screaming “MAGA moon!” Or PNUT, which hit a $1 billion market cap on Solana with squirrel memes and “community” vibes. It feels organic—grassroots excitement, right? Wrong. It’s a mirage. Studies suggest up to 50% of crypto chatter on X is bot-driven, and paid influencers (those Key Opinion Leaders, or KOLs) amplify the noise for a paycheck. TRUMP PNUT I’ve seen it firsthand: X threads with thousands of likes, all pushing the same token, often from accounts with suspiciously perfect timing. Solana’s pump.fun platform churns out memecoins daily, each one cheap to launch, easy to shill, and brutal to hold when the hype fades. The branding’s clever, the airdrops are juicy, and the FOMO’s relentless—until the whale’s gone, and you’re stuck. pump.fun Real-World Rug Pulls: The Evidence Piles Up Real-World Rug Pulls: The Evidence Piles Up Let’s talk specifics. TRUMP was a textbook case: $14.5 billion peak in January 2025, then an 80% nosedive by February. Insiders held 800 million of its 1 billion tokens—80% locked up, giving them total control. Blockchain data showed top wallets dumping 50% of their stash at the top, pocketing millions while retail traders lost billions. Then there’s PNUT, Solana’s squirrel star. It hit $1 billion on meme hype, only to shed 60% in weeks as liquidity dried up. TRUMP PNUT BOME (Book of Meme) followed the same arc in March 2024. It soared to $800 million with X giveaways and meme contests, sucking in retail with promises of fun and profit. A week later, it crashed 70%. Whales exited early, leaving the “community” bagholding. Overhyped Layer 1s like Sui and Aptos had the pretty same path. Billed as “Ethereum killers” in 2023-24, they rode VC buzz and slick whitepapers to billions in market cap—Sui peaked at $2 billion, Aptos had $350 million in backing. But once insider token unlocks hit, prices tanked 70%, and guess who bore the losses? Not the VCs. BOME Book of Meme Sui Aptos Sui Aptos The Mechanics: Why You’re Screwed The Mechanics: Why You’re Screwed Here’s why it works so well: whales need you to buy high so they can sell high. Memecoins and low-liquidity tokens are their playground—small sell-offs trigger massive swings. A $1 million dump can tank a token 20%, and they could crash it whenever they pleased. Marketing hides the grift behind “community-driven” buzz, but the tokenomics tell the real story: insider lockups, hidden vesting schedules, and concentrated supply. Take Sui and Aptos: their whitepapers promised a decentralized future, but vesting schedules favored early backers—20% unlocked for VCs in Q1 2024, leaving retail to eat the dip. It’s not a glitch; it’s the system. Low liquidity amplifies the pain—when whales sell, there’s no one left to buy, and the price craters. Sui Aptos The Psychology: Why We Fall For It The Psychology: Why We Fall For It Why do we keep jumping in? It’s greed and fear, plain and simple. The promise of a 100x return blinds us—TRUMP’s $75 peak felt like a ticket to the moon. Memes and airdrops gamify it, making it feel fun, not risky. X amplifies the herd mentality; when everyone’s shouting “bullish,” it’s hard to sit out. I’ve felt that itch myself, refreshing charts at 2 a.m., convincing myself I’m “early.” But early for what? The whale’s exit party? TRUMP How to Outsmart the Whales How to Outsmart the Whales So, how do you stop being the meal? It’s not foolproof—crypto’s a jungle—but you can tilt the odds. First, dig into tokenomics: who holds what? Tools like Dune Analytics or Nansen track wallet moves—PNUT’s 90% supply in top wallets was a screaming red flag. Second, watch unlock schedules: TRUMP’s 3-year vesting means more dumps are coming. Third, tune out the hype—if it’s trending on X with no substance, it’s bait. I’ve learned to ask: “Who’s selling to me right now? And why?”. Dune Analytics Nansen PNUT TRUMP The Big Picture: It’s a Game of Survival Crypto isn’t broken—it’s built this way. Exit liquidity is the system, not a bug. Every rally asks the same question: “Who’s eating who?” I’ve seen people lose thousands chasing hype, and I’ve dodged a few bullets myself by stepping back. The whales aren’t invincible, though—they need us to play their game. Stop playing, and the trap collapses. Next time you see a token mooning, pause. Check the charts, the wallets, the noise. Stay sharp, or you’re just another meal. Share this if it clicks—let’s outsmart the whales together. Want more crypto deep dives? Follow me on X for real-time thoughts. Let’s keep the conversation going. Follow me on X P.S. Check out my previous articles on AI at HackerNoon: The Power of Community in Memecoin Success
Here's All The News Driving Crypto Markets in March 2025
Building Thriving GameFi Communities: Lessons From the Top Projects
The Ultimate Breakdown: Memecoin Marketing
How To Launch and NFT Promotion for Projects in 2024
AI Crypto Coins: When the Power of AI Meets the Blockchain
DeFi Community Building: A Step-by-Step Guide for Crypto Startups The Power of Community in Memecoin Success The Power of Community in Memecoin Success The Power of Community in Memecoin Success Here's All The News Driving Crypto Markets in March 2025 Here's All The News Driving Crypto Markets in March 2025 Here's All The News Driving Crypto Markets in March 2025 Building Thriving GameFi Communities: Lessons From the Top Projects Building Thriving GameFi Communities: Lessons From the Top Projects Building Thriving GameFi Communities: Lessons From the Top Projects The Ultimate Breakdown: Memecoin Marketing The Ultimate Breakdown: Memecoin Marketing The Ultimate Breakdown: Memecoin Marketing How To Launch and NFT Promotion for Projects in 2024 How To Launch and How To Launch and NFT Promotion for Projects in 2024 NFT Promotion for Projects in 2024 AI Crypto Coins: When the Power of AI Meets the Blockchain AI Crypto Coins: When the Power of AI Meets the Blockchain AI Crypto Coins: When the Power of AI Meets the Blockchain DeFi Community Building: A Step-by-Step Guide for Crypto Startups DeFi Community Building: A Step-by-Step Guide for Crypto Startups DeFi Community Building: A Step-by-Step Guide for Crypto Startups

Exit Liquidity 101: Why You’re the Whale’s Meal in Every Crypto Rally

Ethereum Block Building: The Hidden Economy Behind Every Transaction

Ethereum-Blockaufbau: Die verborgene Wirtschaft hinter jeder Transaktion

Construcción de bloques de Ethereum: la economía oculta detrás de cada transacción

Ethereum Block Building: piilotettu talous jokaisen transaktion takana

Ethereum Block Building: l'economia nascosta dietro ogni transazione

イーサリアムブロック構築: すべてのトランザクションの背後にある隠れた経済

Ethereum bloku ēka: slēptā ekonomika aiz katra darījuma

Kago ya Ethereum Block: Ekonomi ye e Pategilego ka Morago ga Kgwebišano ye Nngwe le E Nngwe

Ethereum Block Building: A economia oculta por trás de cada transação

Ethereum Block Building: Den dolda ekonomin bakom varje transaktion

Ethereum Block Building: Ang Nakatagong Ekonomiya sa Likod ng Bawat Transaksyon

Ethereum Block Building: Ikhonomi Leyi Fihliweke Endzhaku Ka Ntirhisano wun’wana Na wun’wana

Xây dựng khối Ethereum: Nền kinh tế ẩn sau mỗi giao dịch

Why the Market’s Still Soaring Despite the On-Prem Plot Twist (and Why You’re Still in Demand) TL;DR: Sure, some companies are hauling workloads back to on-prem servers, but the cloud security market’s not sweating it — it’s set to hit $156.25 billion by 2032 (Fortune Business Insights). Hybrid and multi-cloud setups are the new norm, not a cloud exodus, and emerging threats like quantum computing keep the demand for pros like you sky-high. The future’s a wild mashup of cloud, on-prem, and quantum-ready defenses — so buckle up, you’re still golden. You’ve seen the headlines screaming: “Businesses are ditching the cloud faster than you can say ‘AWS outage’!” It’s the kind of news that could make a cloud security pro spill their coffee, mutter “Is my job toast?” and eye the server room exit — only to realize it’s still humming with cloud action. Before you trade your CNAPP expertise for a dusty on-prem manual, let’s cut through the noise. The cloud security market isn’t shrinking — it’s growing like your inbox after a week off, and the data backs it up. So, grab your caffeine fix, and let’s unpack this “cloud repatriation” drama — because spoiler alert: it’s not the endgame you think. Cloud Repatriation: Less Apocalypse, More Remix Hold your horses. Most of these companies aren’t torching their cloud subscriptions and swearing off Azure like it’s a bad Tinder date. They’re juggling a hybrid circus — part cloud, part on-prem — or hopping between providers in a multi-cloud acrobatics show. Think of it like pulling a few vinyls off Spotify to spin on your turntable. You’re not canceling streaming — you’re just vibing with both. Here’s the kicker: hybrid setups still need cloud security for the bits that stay sky-high. More clouds mean more chaos, and that’s where you swoop in with your cape of expertise. The cloud’s not dead — it’s just getting a funky remix. Why Are They Repatriating? (Hint: It’s Not Always Your Fault) So, why are companies dragging workloads back on-prem? Let’s break it down — and no, it’s not all about security nightmares: Cost sneak attacks: Cloud bills can hit you like a ninja in the dark — data egress fees, scaling costs, and surprise charges add up. Sometimes on-prem feels like a budget-friendly hug.
Performance divas: Certain apps demand the spotlight of local servers to shine — think latency-sensitive workloads that scoff at cloud lag.
Control freaks: Regulated industries (hello, finance and healthcare) love on-site servers for that warm, fuzzy feeling of keeping data under their thumb. Plot twist: even when workloads come home, most companies keep one foot in the cloud. Hybrid means double doors to lock, and multi-cloud’s a whack-a-mole marathon across platforms. Bad news for lazy weekends, great news for your job security. You’re the ringmaster keeping this tech circus safe. Cloud Security Market: Growing Like a Bad Wi-Fi Signal If repatriation were the cloud security grim reaper, the market would be flatlining. Instead, it’s throwing a rager: Markets and Markets: From $40.7 billion in 2023 to $62.9 billion by 2028, CAGR of 9.1% (Markets and Markets).
Grand View Research: CAGR of 13.1% through 2030 (Grand View Research).
Fortune Business Insights: $43.74 billion in 2024 to $156.25 billion by 2032 (Fortune Business Insights). What’s fueling this? Digital transformation’s insatiable appetite, hybrid sprawl, and multi-cloud madness are pumping demand for tools like CNAPP (Cloud-Native Application Protection Platforms) and ASPM (Application Security Posture Management). These are your security Swiss Army knives — slashing vulnerabilities, nailing compliance, and keeping the chaos at bay. The market’s not shrinking — it’s flexing harder than a bodybuilder on TikTok. From CSPM to CNAPP: The Glow-Up You Didn’t Know You Needed Cloud security’s evolved faster than a Pokémon on a candy binge. Remember CSPM (Cloud Security Posture Management)? It was the OG, sniffing out misconfigs and compliance hiccups — solid, but siloed. Then came CNAPP, the all-in-one superhero: Infrastructure lockdown and compliance checks.
Workload protection (CWPP vibes).
Identity and access management.
Container and Kubernetes kung-fu.
App security testing on steroids. CNAPP’s Secret Sauce: Killing Alert Fatigue Ever drowned in a sea of alerts? CNAPP’s got your back with AI and ML wizardry: Prioritizes threats by “is this actually bad?” impact.
Correlates signals for big-picture clarity.
Suggests fixes so you’re not playing guess-the-patch.
Cuts false positives like a ninja with a katana. This isn’t just a tool — it’s your new best friend in the hybrid jungle. CSPM was the appetizer; CNAPP’s the full buffet. The Future: Hybrid Chaos, Quantum Twists, and You The IT future isn’t cloud-or-bust or on-prem-or-nothing — it’s a hybrid-multi-cloud mashup. Securing it? Think herding cats across AWS, Azure, and that dusty server rack in the basement. Each platform’s a diva with its own quirks, and you’re the maestro keeping the symphony tight. Your toolkit’s leveling up: CNAPP guards cloud apps, ASPM watches app lifecycles, and DSPM (Data Security Posture Management) babysits sensitive data. Oh, and “Shift-Left”? Not a dance move — it’s catching bugs early in dev, saving you from late-night firefights. Bonus Now, the wild card: Post-Quantum Cryptography. It’s a plot twist so trippy, Christopher Nolan’s scribbling notes in a quantum maze. Quantum computers could crack today’s encryption like a walnut, and bad guys are already hoarding data for the big reveal. NIST’s new standards (NIST) are your shield, but the clock’s ticking. No PhD needed — just a heads-up to quantum-proof your game. This future’s a cocktail of cloud sprawl, on-prem quirks, and quantum spice. AI’s your co-pilot, but you’re the captain — your human smarts keep it all from crashing. The cloud security gig? Still hotter than a server on overdrive. Key Takeaways: Your Survival Guide to Cloud Security Glory Repatriation’s not kryptonite — it’s a hybrid remix, not a cloud killer.
Market’s flexing, hitting $156.25 billion by 2032 — plenty of room for you.
Hybrid and multi-cloud reign, fueling CNAPP, ASPM, and DSPM love.
It’s not just security — cost, performance, and compliance nudge the on-prem shift.
Quantum’s your next boss fight — grab your post-quantum decoder ring and prep. Why You’re Still the MVP
Cloud security’s not fading — it’s evolving like a boss. Hybrid chaos and multi-cloud sprawl keep the market buzzing, with projections soaring past $150 billion. Quantum threats add a futuristic edge, and your expertise — tech chops plus strategic brainpower — is the secret sauce. So, keep locking down those digital skies. Your career’s brighter than a rack of LEDs — and twice as essential. May InfoSec Be with You! Why the Market’s Still Soaring Despite the On-Prem Plot Twist (and Why You’re Still in Demand) TL;DR: Sure, some companies are hauling workloads back to on-prem servers, but the cloud security market’s not sweating it — it’s set to hit $156.25 billion by 2032 (Fortune Business Insights). Hybrid and multi-cloud setups are the new norm, not a cloud exodus, and emerging threats like quantum computing keep the demand for pros like you sky-high. The future’s a wild mashup of cloud, on-prem, and quantum-ready defenses — so buckle up, you’re still golden. TL;DR: Sure, some companies are hauling workloads back to on-prem servers, but the cloud security market’s not sweating it — it’s set to hit $156.25 billion by 2032 ( Fortune Business Insights ). Hybrid and multi-cloud setups are the new norm, not a cloud exodus, and emerging threats like quantum computing keep the demand for pros like you sky-high. The future’s a wild mashup of cloud, on-prem, and quantum-ready defenses — so buckle up, you’re still golden. TL;DR: Fortune Business Insights You’ve seen the headlines screaming: “Businesses are ditching the cloud faster than you can say ‘AWS outage’!” It’s the kind of news that could make a cloud security pro spill their coffee, mutter “Is my job toast?” and eye the server room exit — only to realize it’s still humming with cloud action. Before you trade your CNAPP expertise for a dusty on-prem manual, let’s cut through the noise. The cloud security market isn’t shrinking — it’s growing like your inbox after a week off, and the data backs it up. So, grab your caffeine fix, and let’s unpack this “cloud repatriation” drama — because spoiler alert: it’s not the endgame you think. The cloud security market isn’t shrinking — it’s growing like your inbox after a week off, and the data backs it up. Cloud Repatriation: Less Apocalypse, More Remix Hold your horses. Most of these companies aren’t torching their cloud subscriptions and swearing off Azure like it’s a bad Tinder date. They’re juggling a hybrid circus — part cloud, part on-prem — or hopping between providers in a multi-cloud acrobatics show . Think of it like pulling a few vinyls off Spotify to spin on your turntable. You’re not canceling streaming — you’re just vibing with both. hybrid circus part cloud, part on-prem — or hopping between providers in a multi-cloud acrobatics show Here’s the kicker: hybrid setups still need cloud security for the bits that stay sky-high. More clouds mean more chaos, and that’s where you swoop in with your cape of expertise. The cloud’s not dead — it’s just getting a funky remix. hybrid setups still need cloud security for the bits that stay sky-high. Why Are They Repatriating? (Hint: It’s Not Always Your Fault) So, why are companies dragging workloads back on-prem? Let’s break it down — and no, it’s not all about security nightmares: Cost sneak attacks: Cloud bills can hit you like a ninja in the dark — data egress fees, scaling costs, and surprise charges add up. Sometimes on-prem feels like a budget-friendly hug. Performance divas: Certain apps demand the spotlight of local servers to shine — think latency-sensitive workloads that scoff at cloud lag. Control freaks: Regulated industries (hello, finance and healthcare) love on-site servers for that warm, fuzzy feeling of keeping data under their thumb. Cost sneak attacks: Cloud bills can hit you like a ninja in the dark — data egress fees, scaling costs, and surprise charges add up. Sometimes on-prem feels like a budget-friendly hug. Cost sneak attacks: Performance divas: Certain apps demand the spotlight of local servers to shine — think latency-sensitive workloads that scoff at cloud lag. Performance divas: Control freaks: Regulated industries (hello, finance and healthcare) love on-site servers for that warm, fuzzy feeling of keeping data under their thumb. Control freaks: Plot twist: even when workloads come home, most companies keep one foot in the cloud. Hybrid means double doors to lock , and multi-cloud’s a whack-a-mole marathon across platforms. Bad news for lazy weekends, great news for your job security. You’re the ringmaster keeping this tech circus safe. Plot twist: Hybrid means double doors to lock Cloud Security Market: Growing Like a Bad Wi-Fi Signal If repatriation were the cloud security grim reaper, the market would be flatlining. Instead, it’s throwing a rager: Markets and Markets: From $40.7 billion in 2023 to $62.9 billion by 2028, CAGR of 9.1% (Markets and Markets). Grand View Research: CAGR of 13.1% through 2030 (Grand View Research). Fortune Business Insights: $43.74 billion in 2024 to $156.25 billion by 2032 (Fortune Business Insights). Markets and Markets: From $40.7 billion in 2023 to $62.9 billion by 2028, CAGR of 9.1% ( Markets and Markets ). Markets and Markets: Markets and Markets Grand View Research: CAGR of 13.1% through 2030 ( Grand View Research ). Grand View Research: Grand View Research Fortune Business Insights: $43.74 billion in 2024 to $156.25 billion by 2032 ( Fortune Business Insights ). Fortune Business Insights: Fortune Business Insights What’s fueling this? Digital transformation ’s insatiable appetite, hybrid sprawl, and multi-cloud madness are pumping demand for tools like CNAPP (Cloud-Native Application Protection Platforms) and ASPM (Application Security Posture Management) . These are your security Swiss Army knives — slashing vulnerabilities, nailing compliance, and keeping the chaos at bay. The market’s not shrinking — it’s flexing harder than a bodybuilder on TikTok. Digital transformation CNAPP (Cloud-Native Application Protection Platforms) ASPM (Application Security Posture Management) From CSPM to CNAPP: The Glow-Up You Didn’t Know You Needed Cloud security’s evolved faster than a Pokémon on a candy binge. Remember CSPM (Cloud Security Posture Management)? It was the OG, sniffing out misconfigs and compliance hiccups — solid, but siloed. CSPM Then came CNAPP , the all-in-one superhero: CNAPP Infrastructure lockdown and compliance checks. Workload protection (CWPP vibes). Identity and access management. Container and Kubernetes kung-fu. App security testing on steroids. Infrastructure lockdown and compliance checks. Workload protection (CWPP vibes). Identity and access management. Container and Kubernetes kung-fu. App security testing on steroids. CNAPP’s Secret Sauce: Killing Alert Fatigue Killing Alert Fatigue Ever drowned in a sea of alerts? CNAPP’s got your back with AI and ML wizardry: Prioritizes threats by “is this actually bad?” impact. Correlates signals for big-picture clarity. Suggests fixes so you’re not playing guess-the-patch. Cuts false positives like a ninja with a katana. Prioritizes threats by “is this actually bad?” impact. Correlates signals for big-picture clarity. Suggests fixes so you’re not playing guess-the-patch. Cuts false positives like a ninja with a katana. This isn’t just a tool — it’s your new best friend in the hybrid jungle. CSPM was the appetizer; CNAPP’s the full buffet. The Future: Hybrid Chaos, Quantum Twists, and You The IT future isn’t cloud-or-bust or on-prem-or-nothing — it’s a hybrid-multi-cloud mashup . Securing it? Think herding cats across AWS, Azure, and that dusty server rack in the basement. Each platform’s a diva with its own quirks, and you’re the maestro keeping the symphony tight. hybrid-multi-cloud mashup Your toolkit’s leveling up: CNAPP guards cloud apps, ASPM watches app lifecycles, and DSPM (Data Security Posture Management) babysits sensitive data. Oh, and “Shift-Left”? Not a dance move — it’s catching bugs early in dev, saving you from late-night firefights. CNAPP guards cloud apps, ASPM watches app lifecycles, and DSPM Bonus Now, the wild card: Post-Quantum Cryptography. It’s a plot twist so trippy, Christopher Nolan’s scribbling notes in a quantum maze. Quantum computers could crack today’s encryption like a walnut, and bad guys are already hoarding data for the big reveal. NIST’s new standards (NIST) are your shield, but the clock’s ticking. No PhD needed — just a heads-up to quantum-proof your game. Post-Quantum Cryptography. NIST’s new standards ( NIST ) NIST This future’s a cocktail of cloud sprawl, on-prem quirks, and quantum spice. AI’s your co-pilot, but you’re the captain — your human smarts keep it all from crashing. The cloud security gig? Still hotter than a server on overdrive. AI’s your co-pilot, but you’re the captain Key Takeaways: Your Survival Guide to Cloud Security Glory Repatriation’s not kryptonite — it’s a hybrid remix, not a cloud killer. Market’s flexing, hitting $156.25 billion by 2032 — plenty of room for you. Hybrid and multi-cloud reign, fueling CNAPP, ASPM, and DSPM love. It’s not just security — cost, performance, and compliance nudge the on-prem shift. Quantum’s your next boss fight — grab your post-quantum decoder ring and prep. Repatriation’s not kryptonite — it’s a hybrid remix, not a cloud killer. Market’s flexing, hitting $156.25 billion by 2032 — plenty of room for you. Hybrid and multi-cloud reign, fueling CNAPP, ASPM, and DSPM love. It’s not just security — cost, performance, and compliance nudge the on-prem shift. Quantum’s your next boss fight — grab your post-quantum decoder ring and prep. Why You’re Still the MVP Cloud security’s not fading — it’s evolving like a boss. Hybrid chaos and multi-cloud sprawl keep the market buzzing, with projections soaring past $150 billion. Quantum threats add a futuristic edge, and your expertise — tech chops plus strategic brainpower — is the secret sauce. So, keep locking down those digital skies. Your career’s brighter than a rack of LEDs — and twice as essential. Why You’re Still the MVP Cloud security’s not fading — it’s evolving like a boss. Hybrid chaos and multi-cloud sprawl keep the market buzzing, with projections soaring past $150 billion. Quantum threats add a futuristic edge, and your expertise — tech chops plus strategic brainpower — is the secret sauce. So, keep locking down those digital skies. Your career’s brighter than a rack of LEDs — and twice as essential. May InfoSec Be with You! May InfoSec Be with You!

Everyone’s ‘Ditching’ the Cloud—But Here’s Why That’s a Lie

Todo el mundo está abandonando la nube, pero he aquí por qué es mentira

Tout le monde abandonne le cloud, mais voici pourquoi c'est un mensonge

Todo o mundo está "abandonando" a nube, pero aquí tes por que iso é mentira

誰もがクラウドを「捨てている」が、それは嘘だ

ყველა „აშორებს“ ღრუბელს - მაგრამ აი, რატომ არის ეს ტყუილი

‘Nandainga’ ny Rahona ny Rehetra — Nefa Izao no Antony Mandainga

Хүн бүр үүлнээс "зайдаг" боловч энэ нь яагаад худал болохыг эндээс харж болно

सबैजना बादललाई 'छोड्दै' छन्—तर यो किन झूट हो भन्ने यहाँ छ

Todo mundo está ‘abandonando’ a nuvem — mas aqui está o porquê de isso ser uma mentira

Llapa runan ‘Puyuta zanjanku’ —Ichaqa Kaypin kashan imaraykun chay llullakuy

Сви 'одбацују' облак - али ево зашто је то лаж

எல்லோரும் மேகத்தை 'கைவிடுகிறார்கள்' - ஆனால் அது ஏன் ஒரு பொய் என்பது இங்கே

The ideal size of your Kubernetes clusters is a day 0 question and demands a definite answer. You find one giant cluster on one end of the spectrum and many small-sized ones on the other, with every combination in between. This decision will impact your organization for years to come. Worse, if you decide to change your topology, you're in for a time-wasting and expensive ride. I want to list each approach's pros and cons in this post. Then, I'll settle the discussion once and for all and argue why selecting the giant cluster option is better. The One Giant Cluster Approach Deciding on a single giant cluster has great benefits. Better Resource Utilization Kubernetes was designed to handle large-scale deployments, initially focusing on managing thousands of nodes to support extensive and complex containerized applications. This scalability was a key feature from its inception, enabling it to orchestrate resources across vast, distributed systems efficiently. Thus, a Kubernetes cluster is a scheduler at its core: it knows how to run workloads on nodes according to constraints. Without constraints, it will happily balance workloads across its available nodes. If you split the cluster into multiple clusters, you lose this benefit. You can have situations where one cluster is idle while another cluster is close to resource starvation and must cancel workloads and kill pods. Lower Operational Overhead Good Kubernetes practices mandate that you back up your etcd data, monitor your cluster metrics, log your cluster events, provide security-related tools, etc. Size aside, it stands to reason that it's more time-effective to operate fewer clusters. For example, regarding metrics, you'd set up a single Prometheus instance, potentially clustered to handle additional traffic, and be done with it. Automation can mitigate the repetitive aspect of installing and maintaining an instance for each cluster, but you'll still end up with as many instances as you have clusters (or more). Prometheus is just one example because many cluster admins have a long list of tools they run in every cluster. Straightforward Networking and Service Communication Service-to-service communication inside a single cluster is straightforward. Point to <service-name>.<namespace>.svc.cluster.local and be done with it. Even better, you only need the service name part inside the same namespace. <service-name>.<namespace>.svc.cluster.local You'll need a tool to help you with inter-cluster communication, from the simplicity of External DNS with LoadBalancer to the complexity of a full-fledged solution like Istio—both ends of the spectrum mandate time and operation costs. Simplified Governance Since every object is part of the same cluster inside a single cluster, one can enforce a centralized set of policies with a standardized approach. For example, you can create a namespace per team and environment, restricting access to only that team's members. Once you start having multiple clusters, even if you take the same approach, you'll duplicate the policy rules across clusters, with potential differences that will drift further with time. Cost Efficiency A single cluster means a single control plane, simplifying management and reducing overhead. While a control plane is essential for orchestration, its value comes from enabling efficient workload execution rather than directly running business applications. Additionally, many of the points above tie into cost optimization. With a single cluster, you only need to configure monitoring (e.g., Prometheus), logging, and security tools once, reducing duplication. In-place automation streamlines operations, helping manage costs without adding unnecessary infrastructure expenses. e.g. Downsides of a One Giant Cluster Approach Unfortunately, the giant cluster option is not only unicorns and rainbows; there are definite downsides. Larger Blast Radius The larger the cluster, the more teams will use it. Unfortunately, this means that if something bad happens to the cluster, it will wreak havoc on the work of more teams. It occurs regardless of whether the outage results from a malicious actor, a wrong configuration, or resource starvation. When an actual malicious actor does indeed breach access, a larger cluster exposes more workloads, and the actor can compromise more of them. Even without malicious actors, every maintenance operation and upgrade on a cluster can affect its users; the bigger the cluster, the larger the potential impact. When planning an upgrade for a single cluster, you need to conduct an impact analysis that encompasses all users and teams in the organization. Complex Multi-Tenancy Management Even within a single organization, multiple teams will use the Kubernetes cluster. Even if every team member behaves professionally, we must set strict policies to avoid issues. If the cluster resembles a building, you'd still put locks on your apartment even if you have friendly neighbors. Likewise, the cluster administrator must enforce strict rules to make sharing a cluster acceptable. At the very least, we need strict namespace isolation to avoid unnecessary access and resource quotas and enforce fairness across teams. The problems caused by using a single cluster by teams across a single organization multiply a hundredfold if the cluster is multi-tenant and shared across several organizations. Scalability Limits Regardless of how exceptional Kubernetes is, it's still a physically based system with physical limits. For example, some objects have a clear limit, but even if you never reach them, getting close to them will require excellent system administration skills with some fine-tuning. fine-tuning Even then, the more load you put on a Kubernetes API server, the more sluggish your system will be. If you're lucky, it will degrade linearly, but chances are it will hit some system limit and degrade all at once. Cluster-Wide Objects Kubernetes objects are namespace-scoped, but a couple of them are cluster-scoped. A cluster-scoped object can only have a single instance across the whole cluster. For example, a Custom Resource Definition is cluster-scoped. It means that if a team wants to use v1 of a CRD, then every team on the same cluster is stuck with v1 if they wish to use this CRD. Worse, if any team wants to upgrade to v2, they must coordinate across all teams using the CRD to synchronize the upgrade. What's the Ideal Size, Then? I could describe the pros and cons of very granular clusters, but they mirror the opposite of what we have just seen. For example, very granular clusters allow each team to work on their version of a CRD without stepping on another team's toes. For this reason, I'll avoid repeating myself. Most, if not all, articles evaluating the pros and cons of each end of the spectrum advise a meet-in-the-middle approach: "a couple" of clusters to mitigate the worst aspects of each extreme approach. It's all well and good, but none of them, at least none I've read, tell precisely how many "a couple" is. Is it a cluster per environment, i.e., production, staging, or development? Is it a cluster per team? i.e. ‎I'll take a risk and advertise for two clusters: one for production and the other for everything else. How would you manage the cons mentioned above? Read on. vCluster vCluster is an Open Source product that allows the creation of so-called virtual clusters. vCluster is part of the CNCF landscape, specifically a certified Kubernetes distribution. Being a certified distro means a virtual cluster offers every Kubernetes API you can expect, and you can deploy any application to it just like any other Kubernetes cluster. vCluster certified Kubernetes distribution vCluster operates by creating the virtual cluster in a dedicated namespace. You can specify the latter, or vCluster will infer it from the virtual cluster's name. By default, it creates a control plane using the vanilla k8s distribution, but you can choose another one, such as k3s. Likewise, by default, it stores its configuration in an SQLite database, which works particularly well for temporary and pre-production clusters, such as those you create for a pull request. Alternatively, you can rely on a regular etcd or even external databases such as MySQL or Postgres as a data store for more permanent usage and better resilience and scalability of the virtual cluster. Once you've created a virtual cluster via the CLI or the Helm chart, you can connect to it. The client-side CLI creates a dedicated reusable kubeconfig context. From within a virtual cluster, users see no other virtual clusters. If you need to access the host cluster resources from the virtual cluster or vice versa, vCluster uses a so-called syncer that syncs objects back and forth according to a configuration file. This way, you can set up an Ingress Controller on the host cluster and define your Ingress objects in the virtual cluster(s). How vCluster Mitigates the Downsides of a Giant Cluster Let's review each downside of a giant cluster and how vCluster handles it. Larger blast radius: When using a virtual cluster, the blast radius is automatically contained inside its boundaries. If you want to be conservative, aim for a small granularity approach, such as a cluster per team and environment. Larger blast radius: When using a virtual cluster, the blast radius is automatically contained inside its boundaries. If you want to be conservative, aim for a small granularity approach, such as a cluster per team and environment. Complex multi-tenancy management: Gone are multi-tenancy problems since your tenants don't see each other and are isolated inside their respective virtual clusters. Complex multi-tenancy management: Gone are multi-tenancy problems since your tenants don't see each other and are isolated inside their respective virtual clusters. Scalability limits: While the limits are still there, the chances of reaching them decrease with the number of virtual clusters. If your giant cluster had 100k services, they are now spread throughout all virtual clusters. Scalability limits: While the limits are still there, the chances of reaching them decrease with the number of virtual clusters. If your giant cluster had 100k services, they are now spread throughout all virtual clusters. Upgrades and maintenance risks: Upgrade and maintenance tasks are limited to the scope of a single virtual cluster. You can do them in turn, and they will only affect the virtual clusters you target. Upgrades and maintenance risks: Upgrade and maintenance tasks are limited to the scope of a single virtual cluster. You can do them in turn, and they will only affect the virtual clusters you target. Cluster-wide objects: Finally, with virtual clusters, every team can install their version of a CRD, and its virtual cluster binds the CRD. It allows each team to be entirely independent of each other regarding the version of a CRD they use. Cluster-wide objects: Finally, with virtual clusters, every team can install their version of a CRD, and its virtual cluster binds the CRD. It allows each team to be entirely independent of each other regarding the version of a CRD they use. But I Need Different Clusters! While a single giant cluster provides compelling advantages, there are contexts in which a multi-cluster approach is justified. The most common reason is geographic distribution—specific applications require clusters in multiple regions to meet compliance requirements, reduce latency, or provide disaster recovery. For example, companies operating under GDPR or financial regulations may need strict data residency enforcement, which requires region-specific clusters. Similarly, organizations with stringent security postures may enforce complete isolation between environments or business units, making separate clusters a hard requirement. However, even in these cases, vCluster remains relevant. It allows for minimizing the number of physical clusters while still enabling workload separation at a virtual level. Instead of creating a sprawling landscape of Kubernetes clusters, teams can deploy regional virtual clusters within a single host cluster, balancing isolation and operation complexity. Conclusion Kubernetes cluster topology decisions are critical and long-lasting. While many advocate for a middle-ground approach between a single cluster and many small ones, they rarely specify the exact setup. Instead of guessing how many clusters to create, consolidating everything into a single, well-managed giant cluster makes more sense. The benefits—better resource utilization, lower operational overhead, simplified networking, centralized governance, and cost efficiency—outweigh the downsides. That said, the traditional downsides of a giant cluster, such as a larger blast radius, multi-tenancy complexities, scalability limits, upgrade challenges, and cluster-wide object constraints, are valid concerns. This is where vCluster changes the game. By using virtual clusters, you retain all the advantages of a single giant cluster while mitigating its worst drawbacks. vCluster isolates workloads, reduces operational risk, scales dynamically, simplifies upgrades, and removes conflicts over cluster-wide objects. Enhanced with vCluster, one cluster for production and one giant cluster for everything else, is the best approach for long-term scalability, efficiency, and ease of operations.

Stories, News & Mentions about EVERY

Every’s Stories on HackerNoon