We're Smartfrog&Canary, an international IoT tech company focused on making everyday objects and places more intelligent and connected by enabling our users to access them from anywhere at any time. We want the latest technologies to be affordable and user-friendly so that our everyday lives become more comfortable, efficient and secure. With a global footprint and users in over 180 countries, multiple subscription products and an innovative product pipeline, we are a clear category leader in the consumer SaaS IoT space. We are disrupting the consumer markets starting with the traditional security and building tech segments by offering cutting-edge, AI driven technology, and easy-to-use, affordable DIY subscription services.

Canary

canary

In a few words, the idea behind canary releases is to deliver a new software version to only a fraction of the users, analyze the results, and decide whether to proceed further or not. If results are not aligned with expectations, roll back; if they are, increase the number of users exposed until all users benefit from the new version. In this post, I'd like to detail this introduction briefly, explain different ways to define the fraction, and show how to execute it with Apache APISIX. Introduction to canary releases The term "canary" originates from the coal mining industry. When mining, it's not uncommon to release toxic gases: In a small enclosed space, it can mean quick death. Worse, the gas may be odorless, so miners would breathe it until it was too late to leave. Carbon monoxide is quite common in coal mines and is not detectable by human senses. For this reason, miners brought canaries with them underground. If the canary suddenly dropped dead, chances were high that such a gas pocket had been breached, and it was high time to leave the place. Years ago, we brought this approach to releasing a new software version. The analogy goes like this: miners are the Ops team deploying the version, the canary consists of all tools to measure the impact of the release, and the gas is a (critical) bug. The most crucial part is that of the release, including failure rates, HTTP status codes, etc., and compare them with those of the previous version. It's outside the scope of this post, but again, it's critical if you want to benefit from canary releases. The second most important part is the ability to roll back fast if the new version is buggy. you need to measure the impact Canary releases vs. feature flags Note that canary releases are not the only way to manage the risk of releasing new code. For example, feature flags are another popular way: The canary approach delivers the complete set of features in the new component version Feature flags deploy the component as well, but dedicated configuration parameters allow activating and deactivating each feature individually Feature flags represent a more agile approach (in the true sense of the word) toward rollbacks. If one feature out of 10 is buggy, you don't need to undeploy the new version; you only deactivate the buggy feature. However, this superpower comes at the cost of additional codebase complexity, regardless of whether you rely on third-party products or implement it yourself. On the other hand, canary requires a mature deployment pipeline to be able to deploy and undeploy at will. Approaches to canary releases The idea behind canary releases is to allow only a fraction of users to access the new version. Most canary definitions only define "fraction" as a percentage of users. However, there's more to it. The first step may be to allow only vetted users to check that the deployment in the production environment works as expected. In this case, you may forward only a specific set of internal users, , testers, to the new version. If you know the people in advance, and the system authenticates users, you can configure it by identity; if not, you need to fallback to some generic way, , HTTP headers - . e.g. e.g. X-Canary: Let-Me-Go-To-v2 Remember that we must monitor the old and the new systems to look at discrepancies. If nothing shows up, it's an excellent time to increase the pool of users forwarded to the new version. I assume you eat your own dog food, ; team members use the software they're developing. If you don't, for example, an e-commerce site for luxury cars, you're welcome to skip this section. i.e. To enlarge the fraction of users while limiting the risks, we can now indiscriminately provide the new version to internal users. We can configure the system to forward to the new version based on the client IP to do this. At a time when people were working on-site, it was easy as their IPs were in a specific range. Remote doesn't change much since users probably access the company's network via a VPN. Again, monitor and compare at this point. The whole nine yards At this point, everything should work as expected for internal users, either a few or all. But just as no plan survives contact with the enemy, no usage can mimic the whole diversity of a production workload. In short, we need to let regular users access the new version, but in a controlled way, just as we gradually increased the number of users so far: start with a small fraction, monitor it, and if everything is fine, increase the fraction. Here's how to do it with Apache APISIX. Apache APISIX offers a plugin-based architecture and provides a plugin that caters to our needs, namely the plugin. traffic-split The Plugin can be used to dynamically direct portions of traffic to various Upstream services. traffic-split This is done by configuring , which are custom rules for splitting traffic, and which is a set of Upstreams to direct traffic to. match weighted_upstreams -- traffic-split Let's start with some basic upstreams, one for each version: upstreams:
  - id: v1
    nodes:
      "v1:8080": 1
  - id: v2
    nodes:
      "v2:8080": 1 We can use the plugin to forward most of the traffic to v1 and a fraction to v2: traffic-split routes:
  - id: 1
    uri: "*"                                                     #1
    upstream_id: v1           
    plugins:           
      traffic-split:           
        rules:           
          - weighted_upstreams:                                  #2
            - upstream_id: v2                                    #3
              weight: 1                                          #3
            - weight: 99                                         #3 Define a catch-all route Configure how to split traffic; here, weights Forward 99% of the traffic to v1 and 1% to v1. Note that the weights are relative to each other. To achieve 50/50, you can set weights 1 and 1, 3 and 3, 50 and 50, etc. Again, we monitor everything and make sure results are as expected. Then, we can increase the fraction of the traffic forwarded to v2, : e.g. routes:
  - id: 1
    uri: "*"
    upstream_id: v1
    plugins:
      traffic-split:
        rules:
          - weighted_upstreams:
            - upstream_id: v2
              weight: 5                                          #1
            - weight: 95                                         #1 Increase the traffic to v2 to 5% Note that Apache APISIX reloads changes to the file above every second. Hence, you split traffic in near-real time. Alternatively, you can use the Admin API to achieve the same. More controlled releases In the above, I moved from internal users to a fraction of external users. Perhaps releasing to every internal user is too big a risk in your organization, and you need even more control. Note that you can further configure the plugin in this case. traffic-split routes:
  - id: 1
    uri: /*
    upstream_id: v1
    plugins:
      traffic-split:
        rules:
          - match:
            - vars: [["http_X-Canary","~=","Let-Me-Go-To-v2"]]   #1
          - weighted_upstreams:
            - upstream_id: v2
              weight: 5
            - weight: 95 Only split traffic if the HTTP header has the configured value. X-Canary The following command always forwards to v1: curl http://localhost:9080 The following command also always forwards to v1: curl -H 'X-Canary: Let-Me-Go-To-v1' http://localhost:9080 The following command splits the traffic according to the configured weights, , 95/5: i.e. curl -H 'X-Canary: Let-Me-Go-To-v2' http://localhost:9080 Conclusion This post explained canary releases and how you can configure one via Apache APISIX. You can start with several routes with different priorities and move on to the plugin.  The latter can even be configured further to allow more complex use cases. traffic-split The complete source code for this post can be found on . GitHub To go further: Implementation of canary release solution based on Apache APISIX Canary Release in Kubernetes With Apache APISIX Ingress Smooth Canary Release Using APISIX Ingress Controller with Flagger Originally published at on December 3rd, 2023 A Java Geek

Implementing Canary Releases with Apache APISIX

Apache APISIX এর সাথে ক্যানারি রিলিজ বাস্তবায়ন করা

Implementieren von Canary-Releases mit Apache APISIX

Implementación de versiones Canary con Apache APISIX

Implémentation des versions Canary avec Apache APISIX

Apache APISIX के साथ कैनरी रिलीज़ को कार्यान्वित करना

Apache APISIX を使用したカナリア リリースの実装

Apache APISIX를 사용하여 Canary 릴리스 구현

Implementando versões Canary com Apache APISIX

Реализация Canary-релизов с помощью Apache APISIX

Canary Sürümlerini Apache APISIX ile Uygulamak

Triển khai các bản phát hành Canary với Apache APISIX

使用 Apache APISIX 实施 Canary 版本

DUCKS—GOOSE—PEACOCK—TURKEY—GUINEA-FOWL—CANARY-BIRD—GOLD-FISH—HIVE-BEES—SILK-MOTHS

Introduction Kusama is a decentralized network of nodes that can be used to build and run decentralized applications (dApps). Kusama uses the same system architecture as Polkadot, which makes it a suitable testing ground for new features and functionality before they are integrated into the main network. Kusama is designed to be a platform for experimentation, allowing developers to try out new ideas in a live environment. Kusama is still in development, it is subject to change and may not be fully stable. What is Kusama? Kusama is a blockchain platform that enables developers to build and launch decentralized applications. The Kusama network uses the same technology as Polkadot, which makes it easy for developers to get started. Kusama also has its own native currency, called KSM, which can be used to purchase goods and services on the platform or traded on cryptocurrency exchanges. As a playground for developers, Kusama offers a safe environment in which they can experiment with new ideas and test their applications. Key features of Kusama Kusama is a decentralized network designed for canary releases, rapid development cycles, and experimentation for Polkadot. Kusama uses Substrate, an open-source framework for building blockchain applications, to create a platform that is censorship-resistant and scalable. Changes to the network must be approved by a two-thirds supermajority of the validators in order to be implemented. The native token of Kusama is called KSM and it is used for staking, paying transaction fees, and voting on governance proposals. Who are the developers behind Kusama? Kusama is a decentralized network designed to incentivize early adoption of Polkadot and its ecosystem. Kusama is owned by the Web3 Foundation, a Swiss non-profit foundation that promotes decentralized technologies. The Foundation provides grants and funding to support the development of the Kusama network and ecosystem projects. Kusama also has a governance model that allows for community involvement in decision-making processes. The native currency of the Kusama network is KSM, which is used for staking and transaction fees. Why Kusama is important for the innovation of the Polkadot ecosystem? Kusama is a Polkadot-based canary network that allows developers to experiment with new features and scalability solutions before they are implemented on Polkadot. This helps to ensure that the platform remains scalable and reliable and that the user experience is consistent across all devices. Kusama is also known as the because it's a place where development can happen more quickly and with fewer constraints than on mainnet. This makes Kusama ideal for testing new ideas and solutions before they are implemented on Polkadot's mainnet. "wilderness" or "parachain testnet" Anyone can join in on the fun by using Kusama parachains to access its unique features without having to be a developer or know about blockchain technology. Simply sign up, stake your tokens, and get started! To get started, check out where I explain how to create a Polkadot account. Making a Kusama account is the same as making a account. Once populated one can easily toggle any KSM or DOT parachain. Once set up a user can seamlessly, without leaving one central control board, utilize the whole ecosystem. my other article on Polkadot Polkadot Also published . here

What Is Kusama and Why Is It the Canary Network to Polkadot?

Is Continuous Integration enough for testing? With Continuous Integration, every code from developers’ workstations gets incorporated into a shared repository or a central repository, after which with automated build and tests, these codes are checked and merged. What we notice here is that these are synthetic tests, in simpler words, the scripts on the basis of which these tests happen only emulate user experience. They cannot help the IT team understand the actual end-user experience. This also doesn’t give insights on device resources and health state, which can also affect the application performance. Understanding “Canary” of Canary Deployment Before diving into the fact of - how Canary Deployment helps us in understanding the actual end-user experience, let’s begin our discussion by learning the significance of its name. Well, if somewhere your mind is comparing it with “Canary birds,” then you’re on the right track! In British Mining History, these humble birds were used as “toxic gas detectors.” While mining for coals, if there is any way emission of toxic gasses like Carbon Monoxide, Nitrogen dioxide, etc, these birds alerted the miners about its presence. These birds are more sensitive to airborne toxins as compared to human beings. The miners filled those caves with these soft-singing birds, and the moment they notice them falling sick or dying, they evacuate the place immediately before it was too late. Similarly, the DevOps Engineers perform a canary deployment analysis of their code in CI/CD pipeline to gauge any possible errors present. However, here the figurative canaries are a small set of users, who will experience all the glitches present in the update. Let’s define Canary Deployment! Canary deployment is a process or technique of controlled rolling of a software update to a small batch of users, before making it available to everyone. Thereby, reducing the chances of widescale faulty user experience. When the update is examined and feedback is taken, this feedback is again applied and then released on a larger scale. Steps Involved in Canary Deployment Strategy To keep our customers happy and engaged, it’s important to roll out new updates from time to time. Not ignoring the fact that every new change introduced, might have an error or two attached to it, we need a Canary Release Deployment analysis before releasing it to all our customers. With the level of competition in the market, any bug left unattended is going to attract customers’ displeasure and might cause a good loss of the Company’s reputation. Start off by understanding the basic structure of the canary deployment strategy. We can elucidate it under the following headings: Creation Analysis Roll-out/Roll-back Creation To begin with, we need to create a canary infrastructure where our newest update gets deployed. Now, we need to direct a small amount of traffic to this newly created canary instance. Well, the rest would be still continuing with the older version of our software model. Analysis Now, it’s showtime for our DevOps team! Here they need to constantly monitor the performance insights received — data collected from network traffic monitors, synthetic transaction monitors, and all possible resources linked to the canary instance. After the very awaited data gets collected, the DevOps teams then start comparing it with the baseline version’s data. Roll-out/Roll-back After the analysis is done, it’s time to think over the results of the comparative data, and whether rolling out a new feature is a good decision, or is it better to stick back to our baseline state and roll back the update. Well, then how are we benefitted? Zero Production Downtime You know it when there’s small traffic, and the canary instance is not performing as expected, you can simply reroute them to your baseline version. When the engineers are conducting all sorts of tests at this point, they can easily pinpoint the source of error, and can effectively fix it, or roll back the entire update and prepare for a new one. Cost-Efficient — Friendly with smaller Infrastructure The goal of Canary Release Deployment analysis is to drive a tiny amount of your customers to the newly created canary instance — where the new update is deployed. This means you’re using a little extra of your infrastructure to facilitate the entire process. In addition to that, if we compare it with the blue-green deployment strategy, it requires an entire application hosting environment for deploying the new application. As compared to blue-green deployment, we don’t really have to put our efforts into operating and maintaining the environment, in canary deployment, it’s easier to enable and/or disable any particular feature based on any criteria. Room for Constant Innovation The flexibility of testing new features with a small subset of users, and being able to receive end-user experience immediately, is what motivates the dev team to bring in constant improvements/updates. We can increase the load of the canary instance up to 100% and can keep track of the production stability of the enrolled features. Do we have any Limitations? Well, everything has limitations. What’s important for us is to understand how to counteract them. Time-consuming and Prone to Errors Enterprises executing a canary deployment strategy, perform the deployments in a siloed fashion. Then a DevOps Engineer is assigned to collect the data and analyze it manually. This is quite time-consuming as it is not scalable and hinders rapid deployments in CI/CD processes. There might be some cases where the analysis might go wrong and we might roll back a good update or roll forward a wrong one. On-Premise Applications are difficult to update Canary Deployment looks like an appropriate and quite a possible approach when it comes to applications present in Cloud. It is something to think about — when the applications are installed on personal devices. Even then, we can have a way around it by setting up an auto-update environment for end-users. Implementations might require some skill! We are focussing right now, is on the flexibility it offers to test different versions of our application, but we should also bring our attention to managing the databases associated with all these instances. For performing a proper canary deployment and to be able to compare the old version with the new one, we need to modify the schema of the database to support more than one version of the application. Thereby, allowing the old and new versions to run simultaneously. Wrapping Up The essence of the “canary in a coal mine” has been captured so well in strategizing the modern deployment strategy - Canary Deployment Strategy. Back in the old days the major concern was - “ ” to the present-day concept saying - “ ,” our lives have evolved much. Technology is the reason for this change. That which began with simplifying our lives is now aiming at giving us a personalized experience. save the human lives save the human interests With an increasing interest of Enterprises to perform canary deployment analysis, it is to note that we need to counteract the limitations and make processes smoother. We need some good ( , , etc) to automate certain functionalities to keep errors at bay, and also integrate security at every stage of development. continuous delivery solution providers or Managed Kubernetes orchestrators Buildpiper Platform9 Also Published here

Does your Business Need Canary Deployment?

New service releases deployed into DoorDash’s microservice architecture immediately begin processing and serving their entire volume of production traffic. If one of those services is buggy, however, customers may have a degraded experience or the site may go down completely. Although we currently have a traffic management solution under development for gradual service rollouts as a long-term solution, we needed an interim solution we could implement quickly. Our short-term strategy involved developing an in-house deployment process powered by a custom controller. Getting this solution in place gives our engineers the ability to gradually release code while monitoring for issues. With this short-term solution, we were able to ensure the best possible user experience while still ramping up the speed of our development team. Canary Kubernetes The problems with our code release process Our code release process is based on the approach implemented using . This setup gives us quick rollbacks. However, the drawback is that the entire customer base is immediately exposed to new code. If there are problems with the new release, all our customers will find a degraded experience. blue-green deployment Argo Rollouts Our long-term answer to this problem consists of a service mesh that can provide more gradual control of the traffic flow and a special purpose deployment tool with a set of custom pipelines. This solution would allow us to release new code gradually so that any defects do not affect our entire customer base. However, this new system will take several cycles to build, which meant we needed to come up with a short-term solution to manage this problem in the meantime. A quick overview of the blue-green deployment pattern At DoorDash, we release new versions of our code following the blue-green (B/G) deployment pattern, as shown in Figure 1, below. B/G reduces the risk of downtime by keeping two versions of the same deployment running simultaneously. The blue version is stable and serves production traffic. The green version is idle and considered the new release candidate. The actual release happens when the production traffic is switched from the blue version to the green version. After the switch, the blue version is still kept on hold as a backup in case there are problems with the green version. Rolling back to the blue version is instantaneous and immediately resolves any issues coming from the green version. Utilizing Argo Rollouts for B/G deployments Argo Rollouts is a framework that provides a set of enhanced deployment strategies, including B/G deployments, and is powered by a Kubernetes controller and some (CRDs). The Kubernetes objects created as part of the Argo Rollouts B/G CRD are called Rollouts. Rollouts are almost identical to , to which they add more advanced functionalities needed in scenarios such as B/G deployments. Kubernetes Custom Resource Definitions Kubernetes Deployment objects Figure 1: The blue-green (B/G) deployment process deploys the release candidate, called the green version, alongside the stable version, called blue, which is serving all production traffic. The green version is promoted by switching traffic from the blue version to the green version. The blue version is kept around idle for some time to allow for quick rollbacks. The Argo Rollouts B/G implementation in detail The Argo Rollouts B/G implementation is based on the Rollouts Kubernetes controller, a Kubernetes Rollout object, and two : one named Active Service and another named Preview Service. There are two separate versions of the Rollout: the blue and the green. Each version comes with a label that stores the (unique) hash of its specs and is computed by the controller. Kubernetes Services rollouts-pod-template-hash The controller injects a selector into the Active Service with a value that matches the blue hash, effectively causing the Active Service to forward production traffic to the blue version. In the same way, the Preview Service can be used to target the green version in order to perform all tests needed to qualify it as production-ready. Once the green version is deemed ready, the Active Service selector value is updated to match the green hash, redirecting all production traffic to the green version. The blue version is then kept idle for some time in case a rollback is needed. The ability to almost instantaneously switch the incoming traffic from the blue version to the green version has two important consequences: Rolling back is very fast (as long as the blue version is still around). The traffic switch exposes the production traffic to the green version all at once. In other words, the entire user base is affected if the green version is buggy. Our objective is a gradual release process that prevents a bug in the new release candidate code from negatively affecting the experience of our entire customer base. A gradual deployment strategy requires a long-term effort The overall solution to the deployment process problem we faced was to pursue a next-generation deployment platform and a traffic management system that can provide us with more granular control of the traffic flow. However, the scope of such a workstream and the potential impact over our current setup make these changes only feasible within a time range spanning multiple quarters. In the meantime, there were many factors pushing us to find a short-term solution to improve the current process. Why we needed to improve the current process While our long-term strategy for gradual deployments was in the works, our systems were still at risk of disappointing all our customers at every deployment. We needed to ensure that customers, merchants, and Dashers would not be negatively affected by future outages that could erode their trust in our platform. At the same time, our strong customer obsession pushed many of our teams towards adjusting their deployment schedules to minimize the potential customer impact of a buggy release. Late-night deployments became almost a standard practice, forcing our engineers to babysit their new production instances until early morning. These and other motivations pushed us towards finding a short-term solution to provide our engineers with gradual deployments capabilities, without having to utilize non-optimal working requirements. Our short-term strategy for gradual code releases: an in-house Canary solution A Canary solution would be a fast, easy-to-build short-term solution that would allow teams to monitor gradual rollouts of their services so that buggy code would have minimal impacts and could be rolled back easily. This process involved figuring out our functional requirements, configuring our Kubernetes controller, and avoiding obstacles from Argo Rollouts. Short-term solution requirements We started by laying down a list of functional and non-functional requirements for our solution. It had to: leverage native Kubernetes resources as much as possible to reduce the risk and overhead of introducing, installing, and maintaining external components use exclusively in-house components to minimize the chance of our schedule getting delayed by factors, such as external dependencies not under our control provide an interface that is easy to use and integrated with tools our engineers were already familiar with provide powerful levers to control gradual deployments, but at the same time put guardrails in place to prevent potential issues like excessive stress on the Kubernetes cluster lay out a streamlined adoption process that is quick, easy, and informed avoid the additional risks of changing the existing deployment process, and instead integrating it as an additional step Core idea: leverage the Kubernetes Services forwarding logic Our solution was based on the creation of an additional Kubernetes Deployment, which we called Canary, right next to the Kubernetes Rollout running the blue version serving our production traffic. We could sync the labels of the Canary Deployment with the selectors of the Kubernetes Active Service, causing the latter to start forwarding a portion of production traffic to the Canary Deployment. That portion could be estimated starting from the fact that a Kubernetes Service load balances the incoming traffic among all the instances with labels matching its selectors. Therefore, the approximate percentage of incoming traffic hitting the Canary Deployment was determined by the following formula: where #canary and #production represent, respectively, the number of instances belonging to the Canary Deployment and to the existing production Rollout. Our engineers can increase and decrease the number of instances in the Canary Deployment, respectively increasing and decreasing the portion of traffic served by the Canary Deployment. This solution was elegant in that it was simple and satisfied all our requirements. The next step was to figure out how to sync the labels of the Canary Deployment with the selectors of the Active Kubernetes Service in order to implement the Canary solution. Building a custom Kubernetes controller to power our Canary logic One challenge to implementing our solution was to come up with a way to inject the Canary Deployment with the right labels at runtime. Our production Rollouts were always created with a predefined set of labels which we had full control over. However, there was an additional label injected by the Rollouts controller as part of the Argo Rollout B/G implementation. Therefore, we needed to retrieve the value of these labels from the Kubernetes Active Service and attach them to our Canary Deployment. Attaching the labels forces the Kubernetes Active Service to start forwarding a portion of the production traffic to the Canary Deployment. In line with the , we wrote a custom Kubernetes controller to perform the label-syncing task, as shown in Figure 2, below: rollouts-pod-template-hash Kubernetes controller pattern Figure 2: Our custom Kubernetes controller listens to Kubernetes Events related to the creation or update of Canary Deployments. Once a matching Event is received, the controller updates the labels of the corresponding Canary Deployment so that the Kubernetes Service will start forwarding a portion of production traffic to it. This portion can be increased by scaling up the Canary Deployment. A Kubernetes controller is a component that watches the state of a Kubernetes cluster and performs changes on one or more resources when needed. The controller does so by registering itself as a listener for generated by actions ( , , ) targeting a given Kubernetes resource (Kubernetes Pod, Kubernetes ReplicaSet, and so on). Once an event is received, the controller parses it and, based on its contents, decides whether to execute actions involving one or more resources. Kubernetes events create update delete The controller we wrote registered itself as a listener to and events involving resources of type Kubernetes pods with a label set to . After an event of this kind is received, the controller takes the following actions: create update canary true unwraps the event and retrieves the pod labels stops handling the event if a label is already present rollouts-pod-template-hash constructs the Kubernetes Active Service name given metadata provided in the pod labels sends a message to the Kubernetes API server asking for the specs of a Service with a matching name retrieves the selector value from the Service specs if present rollouts-pod-template-hash injects the value as a label to the pod rollouts-pod-template-hash Once the design of our Canary deployment process was concluded, we were ready to put ourselves in the shoes of our customers, the DoorDash Engineering team, and make it easy for them to use. Creating a simple but powerful process to control Canary Deployments With the technical design finalized, we needed to think about the simplest interface that could make our Canary Deployment process easy to use for the Engineering team we serve. At DoorDash, our deployment strategy is based on the model and is powered by a called / . Our engineers type build and deploy commands in Slack channels where multiple people can observe and contribute to the deployment process. ChatOps Slackbot ddops We created three additional /ddops commands: , to create a new Canary Deployment with a single instance only. This would immediately validate that the new version was starting up correctly without any entry point issues. canary-promote , to grow or shrink the size of the Canary Deployment. This step provides a means to test out the new version by gradually exposing more and more customers to it. canary-scale , to bring down the entire Canary Deployment. canary-destroy Once the interface was ready to use, we thought about how to prevent potential problems that may come up as a result of our new Canary Deployment process and build guardrails. Introducing guardrails During the design phase, we identified a few potential issues and decided that some guardrails would need to be put in place as a prevention mechanism. The first guardrail was a hard limit on the number of instances a Canary Deployment could be scaled to. Our Kubernetes clusters are already constantly under high stress because the B/G process effectively doubles the number of instances deployed for a given service while the deployment is in progress. Adding Canary pods would only increase this stress level, which could lead to catastrophic failures. We looked at the number of instances in our services deployments and chose a number that would allow about 80% of services to run a Canary Deployment big enough to achieve an even split between the Canary and non-Canary traffic. We also included an override mechanism to satisfy special requests that would need more instances than we allowed. Another guardrail we put in place prevented any overlap between a new B/G deployment and a Canary Deployment. We embedded checks into our deployment process so that a new B/G deployment could not be started if there were any Canary pods around. Now that the new Canary Deployment process was shaping up to be both powerful and safe, we moved on to consider how to empower our engineers with enough visibility into the Canary metrics. Canary could not exist without proper observability Our new Canary Deployment allows our engineers to assess whether a new release of their service is ready for prime time using a portion of real-life production traffic. This qualification process is essentially a comparison between metrics coming from the blue version serving production traffic and metrics coming from the Canary Deployment running the new release candidate. Looking at the two different categories of metrics, our engineers can evaluate whether the Canary version should be scaled up further to more customer traffic or should be torn down if it’s deemed buggy. The implementation of this observability aspect was completely in the hands of our engineers, as each service had its own naming conventions and success metrics that could vary substantially based on the nature of the service. A clear separation between Canary and non-Canary metrics was possible thanks to specific labels injected only to the Canary pods. This way, teams could just replicate the queries powering their dashboard, adding an additional filter. We designed adoptions to be easy, quick, and informed The next and final step was to plan for helping the Engineering team adopt the Canary Deployments. As always, our objective was a quick and painless adoption. At the same time, we were providing our engineers with a powerful tool that was using our production traffic as a testbed, so we needed them to be empowered with knowledge about potential pitfalls and how to act in case things went wrong. To onboard engineers quickly and safely, we designed a four-step adoption process that they could follow without any external help, as it was simply re-using concepts they were already familiar with. In this case, we tried to stay away from fully automating the adoption process as we wanted them to understand its details. We also added a validation step at the end of the process that required explicit approval. This validation step enabled us to sit down with first-time users and guide them through their first Canary Deployment, explaining what was happening under the hood and what to do in case of failure. The adoption campaign went better than anticipated Initially, we prioritized adoptions for about a dozen services on the golden path of our workflows. Reducing the chances of those services suffering from a full outage meant improving by a great deal the reliability of the core customer flows that power our business. We had a lot of positive feedback about the adoption procedure and the new Canary process overall, and what we observed was that additional teams onboarded their services and scheduled time with us to review their configuration. We ended up onboarding about twice the number of services we anticipated before the end of the year, which was a huge success, taking into account a deploy freeze during the holiday season. Conclusion Releasing new code carries risk and associated costs that can be mitigated using a gradual rollout strategy. However, Kubernetes does not provide this capability out of the box. All the existing solutions require some form of traffic management strategy, which involves significant changes at the infrastructure level and an engineering effort that can last multiple quarters. On the other hand, the Kubernetes controller pattern is a simple but extremely powerful technique that can be used to implement custom behavior for Kubernetes resources, like advanced deployment strategies. Thanks to our new Canary Deployment process powered by a custom Kubernetes controller and other company-wide efforts towards improving the reliability of DoorDash services, our customers, merchants, and Dashers can put their trust in our platform while our engineers work with greater velocity. Interested in taking on challenging problems with practical solutions in a collaborative team environment? ! Consider joining DoorDash engineering Acknowledgments The author would like to thank Adam Rogal, Ivar Lazzaro, Luigi Tagliamonte, Matt Ranney, Sebastian Yates, and Stephen Chu for their advice and support during this project. Previously published at https://doordash.engineering/2021/04/14/gradual-code-releases-using-an-in-house-kubernetes-canary-controller/

Gradual Code Releases: An In-House Kubernetes Canary Controller

Perform Canary Deployments with AWS App Mesh on Amazon ECS Fargate

The Canary Dies

In this post we’ll walk through different AWS services and features that enable canary deployments of Lambda Functions , although you can check the Canary Deployments Serverless Plugin if you just want to safely deploy your functions and you are not interested about the details. Deployment in a Serverless application is an all-at-once process, when we release a new version of any of our functions, every single user will hit the new version. We must be really confident about the new version, because if anything goes wrong and the function contains an error, all of our users will be experiencing ugly issues. However, AWS recently introduced a new feature that can make our deployment process much more reliable and secure: traffic shifting using aliases. How can alias traffic shifting help us? Usually, deploying a Lambda function involves that all the function invocations will execute the new code, either because we are updating or because we are pointing an alias to a new version. That means that if anything goes wrong, 100% of the invocations will be errored and we should quickly roll back to the previous version or, what is even worse, we might not notice the bug and we leave our system in an inconsistent state. However, with the introduction of alias traffic shifting, we can now specify on an alias, so that not all the invocations hit the new release, but only a certain amount of traffic is routed to the latest version. This means that Lambda will automatically between the two latest versions, allowing us to check how the new release behaves before completely replacing the previous one, minimizing the impact of a possible bug. $Latest version weights load balance requests As we see that the new version behaves correctly, we could then gradually update its weight, increasing the load it receives. We can do that in the AWS Console, through the or with some , but there’s a better way to handle Lambda function deployments. CLI open source tools that handle weight updates automatically Automating the deployment process Even though being able to do traffic shifting is a huge leap forward, let’s admit that having to update weights manually (or deploying our own management system) is not really convenient. Don’t worry, as usual AWS has us covered. With we can just specify how we want traffic to be shifted over the time and it the . There are three different types of deployment preferences: CodeDeploy automatically adjusts weights : we specify the percentage of traffic we want to shift and the time we want the deployment to last. So, if we pass 10% and 30 minutes, for example, the 10% of the traffic will be routed to the new version during half an hour. When that time has passed, all the traffic will be shifted to the new version. Canary : the amount of the traffic routed to the new version will be incremented according to the provided percentage and interval. So, if we configure it to increment a 10% of the traffic every 5 minutes, CodeDeploy will update the alias weights adding a 10% to the new version in intervals of 5 minutes, until all the traffic has been shifted. Linear : all the traffic is shifted to the new version straight away. All-at-once This way, we let CodeDeploy do all the heavy lifting in the deployment process, and change alias weights according to our preferences. Traffic will be shifted gradually and, in the meantime, we can check if our new function is behaving correctly and cancel the deployment if we see anything weird. How could we automate the roll back process, so that we don’t have to manually check how the system is performing? CodeDeploy has thought about that as well. Rolling back to the previous Lambda Function version CodeDeploy allows us to configure a and a traffic shifting , which are in fact Lambda functions that are triggered before and after the traffic shifting process. They’re suited for performing tasks like running . CodeDeploy expects to get notified about the success or failure of the hooks , otherwise it’ll assume they failed. In any case, if the hook failed either for not calling CodeDeploy or for explicitly calling it with a failure response, the deployment will be aborted and all the traffic will be shifted to the old function version. pre post hook integration tests within one hour Hooks are not the only way we can check that our function is behaving as expected, since we can provide CodeDeploy with a list of to monitor the deployment process. As the traffic shifting begins, CodeDeploy will track those alarms, cancelling the deployment and to the previous function version if any of them is . CloudWatch Alarms rolling back triggered Deployment process with CodeDeploy and Lambda weighted alias Hooks and alarms allow us to monitor the whole deployment process. We can perform some tests before routing any traffic to the new function version, track alarms during the traffic shifting process and run more tests right after all the traffic is hitting the new version. If CodeDeploy notices something wrong in any of those steps, it will automatically roll back to the old, stable function version. CloudFormation all the things All that sounds really good, but how do we set it up? Well, doing it manually doesn’t seem to be a reasonable option, but fortunately AWS has an awesome service for defining and provisioning infrastructure: . This tool gives us a way to model our system in YAML or JSON templates, which we can use to create a collection of related AWS resources. As you can guess, the syntax of a template where we can define almost any imaginable resource in the AWS ecosystem and its configurations it’s intricate. They even built a simplified syntax to define Serverless applications, the , although it only supports a tiny subset of the AWS resources. The best way to deal with CloudFormation in a Serverless environment is, hands down, the , that provides a nice an easy DSL, which then turns into a CloudFormation template, so that we don’t have to deal with its complexity. However, when the DSL falls short, we can still include chunks of CloudFormation template syntax to create the resources we need. It turns out that the framework has not implemented the canary deployments feature, so we’ll have to specify the resources ourselves. So, we’ll need to include the following: CloudFormation Serverless Application Model Serverless framework A . CodeDeploy::Application An with and permissions for CodeDeploy. IAM::Role AWSCodeDeployRoleForLambda AWSLambdaFullAccess A for every function, where we’ll specify the deployment preference type and alarms. CodeDeploy::DeploymentGroup A for every function including , where we specify the CodeDeploy Application and DeploymentGroup it belongs to, and the associated hooks. Lambda::Alias CodeDeployLambdaAliasUpdate The Serverless Framework always triggers the Lambda function version upon any event, so we must replace any reference to the function by the newly created alias in the event sources. $Latest If this sounds like a lot of hassle… it’s just because it is. Luckily, the Serverless Framework is really modular and there are tons of plugins to complement its features, so you can use the to create all those resources in a much more convenient way (Note: I’m the author of the plugin, any contribution, comment or feature request is welcome). Serverless Plugin Canary Deployments Happy safe deployments! : Reference _By default, an alias points to a single Lambda function version. When the alias is updated to point to a different…_docs.aws.amazon.com Traffic Shifting Using Aliases - AWS Lambda _This post courtesy of Ryan Green, Software Development Engineer, AWS Serverless The concepts of blue/green and canary…_aws.amazon.com Implementing Canary Deployments of AWS Lambda Functions with Alias Traffic Shifting | Amazon Web… _If you use AWS SAM to create your serverless application, it comes built-in with AWS CodeDeploy for safe Lambda…_docs.aws.amazon.com Gradual Code Deployment - AWS Lambda

Canary deployments in Serverless applications

Safely and easily deploying new version of your web app is the technique that we use to “softly” deploy a new version of an into Production. It consists of letting only a part of the audience get access to the new version of the app, while the rest still access the “old” version one. This is very useful when we want to be sure about stability in case of any changes which may be breaking, and have big side effects. Canary Release application The point is: canary release has never been easy to be put into practice. Depending on the environment we have, it can take so long to be put in place that we often prefer to leave this away. However, with Docker containers and Kubernetes orchestration it is quite friendly to do that. Here I am going to show how to do a small canary deployment of a new version of a dummy website using this tool. Those are the versions of our website: On the left, musicstore v1; on the right, the new version v2 Setup environment In order to use Kubernetes locally, we are going to install and . We are going also need to install . minikube kubectl Docker With everything installed, we launch minikube in order to have Kubernetes up and running: minikube start As a response, the terminal will display: Starting local Kubernetes cluster...Starting VM...SSH-ing files into VM...Setting up certs...Starting cluster components...Connecting to cluster...Setting up kubeconfig...Kubectl is now configured to use the cluster. Second step: call this command in order to run Docker inside Minikube: eval $(minikube docker-env) Setting up DB and backend For this app, the backend side will be an API developped in Go, querying against a Mongo DB. We are not going into details about this part, as it is not the goal here to show . how to develop a REST API in Go To deploy the backend, and build the docker image with the command below: clone the repository docker build -t api-musicstore . Optional step: insert some data in the DB: Enter the docker container with the following command: docker exec -t -i <mongo_container> /bin/bash where is the id of the container running against the mongo image. You can discover it after running <mongo_container> docker ps CONTAINER ID        IMAGE                                                        COMMAND                  CREATED             STATUS              PORTS               NAMES3304ee6ab94e        api-musicstore:v1                                            "/go/bin/musicstore"     3 minutes ago       Up 4 minutes                            k8s_backend.72a7365d_api-musicstore-931708012-g4grg_musicstore_442ad9d4-123c-11e7-ae23-0800275d1cac_9f1e978d**75b2eca8cf1f        mongo **                                                       "docker-entrypoint..."   4 minutes ago       Up 4 minutes                            k8s_db.b9d32dcd_api-musicstore-931708012-g4grg_musicstore_442ad9d4-123c-11e7-ae23-0800275d1cac_67653438 In this case, <mongo_container> is . So we run: 75b2eca8cf1f docker exec -t -i /bin/bash 75b2eca8cf1f Inside the container, we open mongo command-line tool with the following command: mongo Once we are inside mongo, copy-paste the following contents and hit Enter: That’s it! Now we have some seed data in our DB, let’s now deploy our REST API that will communicate with the website! Deploying the backend: REST API Normally, I like to organize my deployments and services inside namespaces. Here, I create a namespace musicstore to deploy my Music Store dummy application. To create this namespace, locally and run the following command: copy this file kubectl create -f namespace.yaml After, and run the following command in order to create the API/DB deployment in Kubernetes: copy these files kubectl create -f deployment.json Note: configuration files for Kubernetes can be created in both structures JSON and YAML. In order to create replica controllers, run this command: kubectl create -f rc.yaml Finally, we can create the service, and our backend is ready to run: kubectl create -f service.json We can see that our API is well deployed consulting the URL and opening it in a web browser: minikube service api-musicstore --url --namespace=musicstore http://<url>:32495 Don’t forget to specify the namespace musicstore, otherwise kubectl is going to search for the service in the default namespace and it is not going to find it! Deploying version 1 of the Music Store dummy website Now we are going to build the image for the version 1 of the website. In order to do this, you are going to need to clone and run the following command: this repository docker build -t musicstore:v1 . With our container built, we can proceed with the deployment. First, we create our service: kubectl -f service.yaml This will create the musicstore-website service. We are going to create the deployments, so that we can deploy our code to be served by this service. Let’s get its URL and keep it for later testing: minikube service musicstore-website --url --namespace=musicstore http://<url>:32000 Let’s take a look at the deployment config file: we are going to ask Kubernetes to create 3 replicas of this website in order to handle traffic and load balancing. All of the replicas will be, in a first moment, pointing to the image corresponding to the image of version v1 of the musicstore-website: Let’s deploy it: kubectl create -f deployment-without-canary.json Now, if you open the website you are going to see its version 1: Website after first deployment Deploying version 2 of the Music Store dummy website using canary deployment First step in order to deploy version 2 is to create a docker image for it, just like we did for version 1. So, and run the following command in a terminal: copy the contents from here docker build -t musicstore:v2 . As seen before, we created 3 replicas of our front-end service. As explained before, the idea of canary deployment is getting a part of the traffic and redirect it to a new version. We are going to achieve this pointing one of the replicas of our service to the new version of the Music Store. Like this, most part of the traffic will still be redirected to version 1. To achieve this, we run the following commands: kubectl apply deployment.jsonkubectl apply deployment-canary.json With this command, we tell Kubernetes to apply this deployment to our environment. If we take a look in the file, we see that the only thing it changes regarding the deployment of version 1 is the label “canary” (the other version is considered “stable”), and the number of replicas (1 to the new version, and 2 serving the old one). And of course, it points to the Docker image : musicstore:v2 And here is how the deployment of version 1 looks like, with 2 replicas pointing to the stable version: Now, we can see that some of the traffic are already seeing the version 2 of our Music Store dummy app: Musicstore version 2 Rolling out the new version Now we feel safe and sound to go for the new version. With the canary delpoyment, this is kind of easy: we just need to set all of the replicas to point to a stable version running the image of the version 2 of the Music Store: kubectl apply deployment-new-version.json This is how our deployment-new-version.json will look like: Very good! Now, everybody will be able to see the new version of the Music Store web site! All the files used in this tutorial can be found . here A great example of Canary Release can be found as well. here

Canary Release with Kubernetes

Hacking Backward and Forward-Compatible Application Releases

Heavy is the head that wears the crown during a Wall Street bull run, and Nvidia’s status as the king of the ongoing generative AI boom means that the stock can be especially vulnerable to the prospect of weakening investor appetite. Nvidia (NASDAQ:NVDA) became Wall Street’s most exciting story in 2023. The chipmaker rallied some 239% throughout the year, smashing through the $1 trillion market capitalization glass ceiling before peaking at a cap in excess of $2tn. The optimism, fuelled by the ongoing generative AI market rally, continued to make waves in the first-quarter of 2024. NVDA rallied almost 90% in the opening three months of the year to continue its strong spell of dominance. But finally, at the beginning of April, the stock took its biggest tumble in four years. The wider implications of the Nvidia sell-off are likely to shake up the entire generative AI market. Counting the Cost of NVDA Sell-Offs The first three weeks of April 2024 saw NVDA shed more than 15% of its value amid widespread investor sell-offs. Although greater degrees of volatility can be expected for stocks caught up in the hype phase of an emerging market, Nvidia’s April downturn has been the company’s biggest dip since the initial outbreak of the Covid-19 pandemic in March 2020. For Nvidia, the pandemic era must seem like a lifetime ago. Its March 2020 sell-offs saw the stock tumble to $51.44. The stock’s peak closing price in March 2024 was $950.02. But after four years of meteoric growth, Nvidia’s recent market downturn is particularly concerning–particularly now the stock’s gained the status as a tech pioneer that’s been driving the S&P 500 higher on a consistent basis. Nvidia’s position at the pinnacle of the generative AI boom could mean that the stock would always be the first to absorb the impact of a change in investor sentiment, and the fears are that NVDA would be the canary in the mine should we suddenly discover that generative AI has been in a hype bubble that’s ready to burst for some time. Although Nvidia’s recent difficulties have coincided with the news that US inflation rates have continued to defy expectations, placing the prospect of interest rate cuts on hold for the foreseeable future, analysts suggest that fears over a cooling generative AI boom remain the key cause of investor concern in the wake of the underperformance. “The stock pullback has very little to do with rates,” explained Parag Thatte, strategist at Deutsche Bank, in a recent Financial Times interview. “It’s more to do with investors pricing in slower earnings growth.” There’s also a growing concern that generative AI has begun to transform from its hype phase towards the question of implementation. While Large Language Models (LLMs) like ChatGPT have been excellent tools in showcasing the sheer power and potential of generative AI, they’ve also been largely error-prone in a manner that could cause more hesitancy among enterprises seeking to embrace the technology. It’s for this reason that Gil Luria, analyst at DA Davidson, warned that a 20% slide in Nvidia stock could take place by the end of 2024. Luria suggests that the implementation phase of Nvidia’s products, which are currently being bought en masse by the likes of Microsoft and Amazon, could run into trouble when key buyers reach capacity and demand begins to fall. However, other analysts suggest that the end of the generative AI hype phase will be met by a more strategic implementation phase which could keep the industry growing. “Concerns about GenAI failing to meet expectations in 2024 should be seen in the context of the natural cycle of hype and maturity of new technologies,” said Maxim Manturov, head of investment research at Freedom Finance Europe. “While some industry leaders have expressed frustration with the speed of progress in artificial intelligence and GenAI in their organisations, others remain optimistic about its potential.” “Companies heavily invested in GenAI are under pressure to prove profitability, and industry reports indicate a shift to more strategic AI initiatives in the coming years,” Manturov added. Is the Generative AI an Exceptional Case? Here, it’s worth reminding ourselves that we’re talking about the generative AI boom. This is an industry that Bloomberg Intelligence last year suggested would grow at a CAGR of 42% into a $1.3 trillion industry by 2032. Fresh demand for generative AI products was predicted to add around $280 million in new software revenue. Could we be talking about an emerging technology that’s market impact is without precedent? Morgan Stanley analysts have underlined the indecisive outlook for Nvidia and the wider generative AI market in Q2 2024 by proposing a more bullish outlook for NVDA as well as the generative AI-focused Amazon (AMZN). As Nvidia reported Q4 2023 revenue increases of 265% to $22 billion, CEO Jensen Huang claimed that "accelerated computing and generative AI have hit the tipping point," before adding that "demand is surging worldwide across companies, industries and nations." The company’s innovations in recent weeks have included the text-to-3D tool, LATTE3D, which Nvidia described as a ‘virtual 3D printer’, as well as a collaboration with Hipocratic AI to develop a network of generative AI nurses that could cost $9 an hour. Nvidia’s quick 5% rebound following its record sell-offs should serve as a wider vote of confidence in the innovation that the company is capable of. Regardless of whether its success has made it the GenAI canary, NVDA is certainly an innovative stock that’s capable of sustaining its impressive growth. Bubble or Boom? Ultimately, Nvidia’s performance over the past 12 months means that the stock has become a live litmus test for investor sentiment in generative AI. Whether that’s a good thing or not depends wholly on the capabilities of the industry itself. Nvidia’s rapid growth has seen the stock rub shoulders with the likes of Microsoft, Apple, and Alphabet, and the company will be keen to follow the lead of other industry giants to continue sustaining its growth through innovation. As a semiconductor leader, the possibilities are nearly endless for Nvidia. As long as the capabilities of generative AI continue to astound clients and deliver on its promises, NVDA remains a stock that can continue to grow. If investors get a whiff of saturation or inefficiency, the Nvidia litmus test could face some further challenges ahead. Heavy is the head that wears the crown during a Wall Street bull run, and Nvidia’s status as the king of the ongoing generative AI boom means that the stock can be especially vulnerable to the prospect of weakening investor appetite. Nvidia (NASDAQ:NVDA) became Wall Street’s most exciting story in 2023. The chipmaker rallied some 239% throughout the year, smashing through the $1 trillion market capitalization glass ceiling before peaking at a cap in excess of $2tn. Nvidia The optimism, fuelled by the ongoing generative AI market rally, continued to make waves in the first-quarter of 2024. NVDA rallied almost 90% in the opening three months of the year to continue its strong spell of dominance. But finally, at the beginning of April, the stock took its biggest tumble in four years. The wider implications of the Nvidia sell-off are likely to shake up the entire generative AI market. Counting the Cost of NVDA Sell-Offs The first three weeks of April 2024 saw NVDA shed more than 15% of its value amid widespread investor sell-offs. Although greater degrees of volatility can be expected for stocks caught up in the hype phase of an emerging market, Nvidia’s April downturn has been the company’s biggest dip since the initial outbreak of the Covid-19 pandemic in March 2020. For Nvidia, the pandemic era must seem like a lifetime ago. Its March 2020 sell-offs saw the stock tumble to $51.44. The stock’s peak closing price in March 2024 was $950.02. But after four years of meteoric growth, Nvidia’s recent market downturn is particularly concerning–particularly now the stock’s gained the status as a tech pioneer that’s been driving the S&P 500 higher on a consistent basis. Nvidia’s position at the pinnacle of the generative AI boom could mean that the stock would always be the first to absorb the impact of a change in investor sentiment, and the fears are that NVDA would be the canary in the mine should we suddenly discover that generative AI has been in a hype bubble that’s ready to burst for some time. Although Nvidia’s recent difficulties have coincided with the news that US inflation rates have continued to defy expectations, placing the prospect of interest rate cuts on hold for the foreseeable future, analysts suggest that fears over a cooling generative AI boom remain the key cause of investor concern in the wake of the underperformance. prospect of interest rate cuts on hold prospect of interest rate cuts on hold “The stock pullback has very little to do with rates,” explained Parag Thatte , strategist at Deutsche Bank, in a recent Financial Times interview. “It’s more to do with investors pricing in slower earnings growth.” explained Parag Thatte explained Parag Thatte There’s also a growing concern that generative AI has begun to transform from its hype phase towards the question of implementation. While Large Language Models (LLMs) like ChatGPT have been excellent tools in showcasing the sheer power and potential of generative AI, they’ve also been largely error-prone in a manner that could cause more hesitancy among enterprises seeking to embrace the technology. largely error-prone largely error-prone It’s for this reason that Gil Luria, analyst at DA Davidson, warned that a 20% slide in Nvidia stock could take place by the end of 2024. Luria suggests that the implementation phase of Nvidia’s products, which are currently being bought en masse by the likes of Microsoft and Amazon, could run into trouble when key buyers reach capacity and demand begins to fall. 20% slide in Nvidia stock 20% slide in Nvidia stock However, other analysts suggest that the end of the generative AI hype phase will be met by a more strategic implementation phase which could keep the industry growing. “Concerns about GenAI failing to meet expectations in 2024 should be seen in the context of the natural cycle of hype and maturity of new technologies,” said Maxim Manturov, head of investment research at Freedom Finance Europe . “While some industry leaders have expressed frustration with the speed of progress in artificial intelligence and GenAI in their organisations, others remain optimistic about its potential.” Freedom Finance Europe Freedom Finance Europe “Companies heavily invested in GenAI are under pressure to prove profitability, and industry reports indicate a shift to more strategic AI initiatives in the coming years,” Manturov added. Is the Generative AI an Exceptional Case? Here, it’s worth reminding ourselves that we’re talking about the generative AI boom. This is an industry that Bloomberg Intelligence last year suggested would grow at a CAGR of 42% into a $1.3 trillion industry by 2032 . $1.3 trillion industry by 2032 $1.3 trillion industry by 2032 Fresh demand for generative AI products was predicted to add around $280 million in new software revenue. Could we be talking about an emerging technology that’s market impact is without precedent? Morgan Stanley analysts have underlined the indecisive outlook for Nvidia and the wider generative AI market in Q2 2024 by proposing a more bullish outlook for NVDA as well as the generative AI-focused Amazon (AMZN). more bullish outlook more bullish outlook As Nvidia reported Q4 2023 revenue increases of 265% to $22 billion, CEO Jensen Huang claimed that "accelerated computing and generative AI have hit the tipping point," before adding that "demand is surging worldwide across companies, industries and nations." claimed that claimed that The company’s innovations in recent weeks have included the text-to-3D tool , LATTE3D, which Nvidia described as a ‘virtual 3D printer’, as well as a collaboration with Hipocratic AI to develop a network of generative AI nurses that could cost $9 an hour. text-to-3D tool text-to-3D tool collaboration with Hipocratic AI collaboration with Hipocratic AI Nvidia’s quick 5% rebound following its record sell-offs should serve as a wider vote of confidence in the innovation that the company is capable of. Regardless of whether its success has made it the GenAI canary, NVDA is certainly an innovative stock that’s capable of sustaining its impressive growth. Bubble or Boom? Ultimately, Nvidia’s performance over the past 12 months means that the stock has become a live litmus test for investor sentiment in generative AI. Whether that’s a good thing or not depends wholly on the capabilities of the industry itself. Nvidia’s rapid growth has seen the stock rub shoulders with the likes of Microsoft, Apple, and Alphabet, and the company will be keen to follow the lead of other industry giants to continue sustaining its growth through innovation. As a semiconductor leader, the possibilities are nearly endless for Nvidia. As long as the capabilities of generative AI continue to astound clients and deliver on its promises, NVDA remains a stock that can continue to grow. If investors get a whiff of saturation or inefficiency, the Nvidia litmus test could face some further challenges ahead.

Nvidia’s Shaky Q2 Underlines the Stock as Generative AI’s Sentiment Litmus Test

এনভিডিয়ার শ্যাকি Q2 জেনারেটিভ এআই এর সেন্টিমেন্ট লিটমাস টেস্ট হিসাবে স্টককে আন্ডারলাইন করেছে

Nvidias wackeliges zweites Quartal unterstreicht die Aktie als Lackmustest für die Stimmung von Generative AI

El inestable segundo trimestre de Nvidia subraya la acción como prueba de fuego del sentimiento de la IA generativa

Le Shaky Q2 de Nvidia souligne le titre en tant que test décisif du sentiment de Generative AI

एनवीडिया की अस्थिर Q2 स्टॉक को जेनरेटिव एआई के सेंटीमेंट लिटमस टेस्ट के रूप में रेखांकित करती है

エヌビディアの第2四半期の不安定さは、ジェネレーティブAIの感情リトマス試験として株価を浮き彫りにする

Nvidia의 Shaky Q2는 Generative AI의 감정 리트머스 테스트로서 주식을 강조합니다.

Shaky Q2 da Nvidia destaca o estoque como teste decisivo de sentimento da IA generativa

Нестабильный второй квартал Nvidia подчеркивает, что акции являются лакмусовой бумажкой настроений генеративного ИИ

Nvidia'nın Titrek 2. Çeyreği Hisse Senedinin Üretken Yapay Zekanın Duyarlılık Turnusol Testi Olduğunu Vurguluyor

Q2 run rẩy của Nvidia nhấn mạnh cổ phiếu là bài kiểm tra tình cảm của AI sáng tạo

Nvidia 第二季度业绩表现不佳，凸显其股票是生成式 AI 情绪的试金石

Digital Forensics and Incident Response (DFIR) is a specialized field within information security focused on managing cybersecurity incidents. It involves identifying, mitigating, and investigating these incidents, which is known as incident response. Additionally, the field includes the application of forensic techniques, referred to as digital forensics, to analyze and gather evidence. Digital forensics typically begins with an incident, but sometimes, merely detecting signs of unauthorized scanning of a company's IT infrastructure can thwart an attack. Hackers often infiltrate systems in phases and might remain inactive for a while, only to strike a critical digital asset suddenly. For this reason, it is highly effective when digital forensics teams collaborate closely with threat monitoring teams to intercept and block hacking attempts early on. Paths to a Digital Forensics Career This profession demands extensive practical knowledge of IT, encompassing everything from operating systems to mobile apps, telecommunications solutions to IoT devices, and from databases to hardware configurations. A digital forensic expert must not only have a deep understanding of how IT systems function - ideally at an admin level - but also grasp how these systems are protected and how exactly they can be compromised. The transition of someone from a job in cybersecurity, IT administration, or a backend development job into digital forensics can be incredibly valuable. There is no quick training method; the most effective approach is "learning by doing," where individuals learn on the job by tackling specific practical tasks while addressing real-world problems. While there are now excellent courses on digital forensics that can significantly enhance this hands-on learning experience, they should only serve as a supplement, not a replacement. Main Tasks in Digital Forensic Investigations The role of incident responders is to analyze traces of intrusions to answer practical questions: What exactly happened? After a cyber incident, it is vital to determine exactly how hackers gained access and what actions they took. This detailed understanding helps to more accurately assess both the direct damage from the incident and the potential reputational risks. How did this happen? It is necessary to reconstruct the entire sequence of the attack. This knowledge allows information security specialists to mitigate future cyber threats by addressing vulnerabilities that were exploited in the attack, preventing hackers from using the same or similar tactics again. What should you do at the moment? Sometimes, digital forensics specialists need to be actively involved in responding to an incident, not just analyzing the traces. There are situations where hacker activity within a company's IT infrastructure is ongoing. In such cases, it is important to respond carefully, in coordination with all members of the security team, to contain the threat. New challenges are emerging. For example, digital forensics is now used to perform compromise assessments, which involve identifying traces of IT infrastructure compromise. Detecting signs of past breaches can lead cyber investigators to uncover unpatched vulnerabilities or weaknesses in the information security framework. Often, discovering such previously unnoticed issues necessitates thorough investigations. How Long Investigations Last Usually, after a cyber incident, the investigation lasts about two to three weeks. While there are complex cases that require significantly more time, these are quite rare. Most of the time is devoted to the investigation itself, which includes all its stages and the analysis of data collected. Sometimes, this also involves actions to contain the attackers. Please remember that several days are also spent on writing detailed reports. Documentation is crucial: it is necessary to provide comprehensive information for the management of the client company, its security service, and external cybersecurity providers. In some cases, this information is also vital for law enforcement agencies, as digital forensics plays an important role in the apprehension and exposure of cyber criminals. Investigating a company's infrastructure for signs of possible intrusion is a time-consuming task due to the extensive amount of work involved. This process can take anywhere from a month to two months, depending on the size of the customer company's IT infrastructure. It is noteworthy that traces of intrusion, such as 'fingerprints' left by malware, backdoors installed by attackers, or suspicious traffic typical of specific post-exploitation frameworks, are often found. All these findings necessitate further research and detailed analysis. Evaluating a Digital Forensics Profession Strengths

Weaknesses



[+] This is interesting and creative work that requires a blend of competencies, practices, and intuition.

[-] Entering the profession involves a multistage, lengthy, and complex process.



[+] The specialty is rare, which typically means the average salary is higher than that of cybersecurity officers and admins.

[-] The working day can be irregular - for example, when it is necessary to detain malefactors, one might have to spend the night at the client's office.



Opportunities

Risks



[+] Continuous learning about the latest developments in IT, cybersecurity, and forensics keeps you sharp and well-informed.

[-] Switching fields of activity can be problematic due to technical specialties and psychological factors. Investigations are adrenaline-driven, making it difficult to easily walk away from forensics. The Ever-Learning Digital Forensic Expert A digital forensic specialist needs to engage in continuous learning, constantly updating and expanding their knowledge in IT and cybersecurity. This includes not only general IT development but also specialized knowledge in forensics, such as new findings, current challenges, and new cases. This practice introduces new techniques and tools while fostering proficiency in identifying malicious acts. For example, over time, forensic experts begin to recognize the distinct "styles" of different hacker groups. Attribution is crucial as it helps quickly untangle the chain of evidence and traces. A forensic expert continually develops their skills through practical experience and theoretical study. Specialists often need to learn independently, access information from free and paid courses, read articles and books related to their field, watch videos, and attend infosec conferences. They regularly consult specialized information resources such as This Week In 4N6,, The DFIR Report, and Sentinel Labs, along with Mandiant, Red Canary, and TrustedSec blogs. YouTube is another rich source of information, featuring channels like SANS Digital Forensics and Incident Response, 13Cubed, and John Hammond's channel. Additionally, X (formerly Twitter) is a valuable platform where tags like #DFIR and #DailyDFIR provide timely and helpful information. Conclusion The demand for digital forensics is growing along with the expansion of the cybersecurity market, but still exceeds the average for the segment. Most businesses do not require specialists with these skills; instead, digital forensic experts are often employed by specialized firms that offer various information security services. The cost of hiring a forensics specialist is usually open to negotiation and heavily relies on their qualifications and hands-on experience in handling incidents. These specialists have always been and will continue to be in short supply because there are no quick paths to becoming proficient in digital forensics. Digital Forensics and Incident Response ( DFIR ) is a specialized field within information security focused on managing cybersecurity incidents. It involves identifying, mitigating, and investigating these incidents, which is known as incident response. Additionally, the field includes the application of forensic techniques, referred to as digital forensics, to analyze and gather evidence. DFIR Digital forensics typically begins with an incident, but sometimes, merely detecting signs of unauthorized scanning of a company's IT infrastructure can thwart an attack. Hackers often infiltrate systems in phases and might remain inactive for a while, only to strike a critical digital asset suddenly. For this reason, it is highly effective when digital forensics teams collaborate closely with threat monitoring teams to intercept and block hacking attempts early on. hacking attempts Paths to a Digital Forensics Career This profession demands extensive practical knowledge of IT, encompassing everything from operating systems to mobile apps, telecommunications solutions to IoT devices, and from databases to hardware configurations. A digital forensic expert must not only have a deep understanding of how IT systems function - ideally at an admin level - but also grasp how these systems are protected and how exactly they can be compromised. The transition of someone from a job in cybersecurity, IT administration, or a backend development job into digital forensics can be incredibly valuable. There is no quick training method; the most effective approach is "learning by doing," where individuals learn on the job by tackling specific practical tasks while addressing real-world problems. While there are now excellent courses on digital forensics that can significantly enhance this hands-on learning experience, they should only serve as a supplement, not a replacement. backend development job excellent courses on digital forensics Main Tasks in Digital Forensic Investigations The role of incident responders is to analyze traces of intrusions to answer practical questions: What exactly happened? What exactly happened? What exactly happened? After a cyber incident, it is vital to determine exactly how hackers gained access and what actions they took. This detailed understanding helps to more accurately assess both the direct damage from the incident and the potential reputational risks. How did this happen? How did this happen? How did this happen? It is necessary to reconstruct the entire sequence of the attack. This knowledge allows information security specialists to mitigate future cyber threats by addressing vulnerabilities that were exploited in the attack, preventing hackers from using the same or similar tactics again. What should you do at the moment? What should you do at the moment? What should you do at the moment? Sometimes, digital forensics specialists need to be actively involved in responding to an incident, not just analyzing the traces. There are situations where hacker activity within a company's IT infrastructure is ongoing. In such cases, it is important to respond carefully, in coordination with all members of the security team, to contain the threat. New challenges are emerging. For example, digital forensics is now used to perform compromise assessments , which involve identifying traces of IT infrastructure compromise. Detecting signs of past breaches can lead cyber investigators to uncover unpatched vulnerabilities or weaknesses in the information security framework. Often, discovering such previously unnoticed issues necessitates thorough investigations. compromise assessments unpatched vulnerabilities How Long Investigations Last Usually, after a cyber incident, the investigation lasts about two to three weeks. While there are complex cases that require significantly more time, these are quite rare. Most of the time is devoted to the investigation itself, which includes all its stages and the analysis of data collected. Sometimes, this also involves actions to contain the attackers. Please remember that several days are also spent on writing detailed reports. Documentation is crucial: it is necessary to provide comprehensive information for the management of the client company, its security service, and external cybersecurity providers. In some cases, this information is also vital for law enforcement agencies, as digital forensics plays an important role in the apprehension and exposure of cyber criminals. Investigating a company's infrastructure for signs of possible intrusion is a time-consuming task due to the extensive amount of work involved. This process can take anywhere from a month to two months, depending on the size of the customer company's IT infrastructure. It is noteworthy that traces of intrusion, such as 'fingerprints' left by malware, backdoors installed by attackers, or suspicious traffic typical of specific post-exploitation frameworks, are often found. All these findings necessitate further research and detailed analysis. Evaluating a Digital Forensics Profession Strengths

Weaknesses



[+] This is interesting and creative work that requires a blend of competencies, practices, and intuition.

[-] Entering the profession involves a multistage, lengthy, and complex process.



[+] The specialty is rare, which typically means the average salary is higher than that of cybersecurity officers and admins.

[-] The working day can be irregular - for example, when it is necessary to detain malefactors, one might have to spend the night at the client's office.



Opportunities

Risks



[+] Continuous learning about the latest developments in IT, cybersecurity, and forensics keeps you sharp and well-informed.

[-] Switching fields of activity can be problematic due to technical specialties and psychological factors. Investigations are adrenaline-driven, making it difficult to easily walk away from forensics. Strengths

Weaknesses [+] This is interesting and creative work that requires a blend of competencies, practices, and intuition.

[-] Entering the profession involves a multistage, lengthy, and complex process. [+] The specialty is rare, which typically means the average salary is higher than that of cybersecurity officers and admins.

[-] The working day can be irregular - for example, when it is necessary to detain malefactors, one might have to spend the night at the client's office. Opportunities

Risks [+] Continuous learning about the latest developments in IT, cybersecurity, and forensics keeps you sharp and well-informed.

[-] Switching fields of activity can be problematic due to technical specialties and psychological factors. Investigations are adrenaline-driven, making it difficult to easily walk away from forensics. Strengths Weaknesses Strengths Strengths Strengths Weaknesses Weaknesses Weaknesses [+] This is interesting and creative work that requires a blend of competencies, practices, and intuition. [-] Entering the profession involves a multistage, lengthy, and complex process. [+] This is interesting and creative work that requires a blend of competencies, practices, and intuition. [+] This is interesting and creative work that requires a blend of competencies, practices, and intuition. [-] Entering the profession involves a multistage, lengthy, and complex process. [-] Entering the profession involves a multistage, lengthy, and complex process. [+] The specialty is rare, which typically means the average salary is higher than that of cybersecurity officers and admins. [-] The working day can be irregular - for example, when it is necessary to detain malefactors, one might have to spend the night at the client's office. [+] The specialty is rare, which typically means the average salary is higher than that of cybersecurity officers and admins. [+] The specialty is rare, which typically means the average salary is higher than that of cybersecurity officers and admins. [-] The working day can be irregular - for example, when it is necessary to detain malefactors, one might have to spend the night at the client's office. [-] The working day can be irregular - for example, when it is necessary to detain malefactors, one might have to spend the night at the client's office. Opportunities Risks Opportunities Opportunities Opportunities Risks Risks Risks [+] Continuous learning about the latest developments in IT, cybersecurity, and forensics keeps you sharp and well-informed. [-] Switching fields of activity can be problematic due to technical specialties and psychological factors. Investigations are adrenaline-driven, making it difficult to easily walk away from forensics. [+] Continuous learning about the latest developments in IT, cybersecurity, and forensics keeps you sharp and well-informed. [+] Continuous learning about the latest developments in IT, cybersecurity, and forensics keeps you sharp and well-informed. [-] Switching fields of activity can be problematic due to technical specialties and psychological factors. Investigations are adrenaline-driven, making it difficult to easily walk away from forensics. [-] Switching fields of activity can be problematic due to technical specialties and psychological factors. Investigations are adrenaline-driven, making it difficult to easily walk away from forensics. The Ever-Learning Digital Forensic Expert A digital forensic specialist needs to engage in continuous learning, constantly updating and expanding their knowledge in IT and cybersecurity . This includes not only general IT development but also specialized knowledge in forensics, such as new findings, current challenges, and new cases. This practice introduces new techniques and tools while fostering proficiency in identifying malicious acts. For example, over time, forensic experts begin to recognize the distinct "styles" of different hacker groups. Attribution is crucial as it helps quickly untangle the chain of evidence and traces. cybersecurity A forensic expert continually develops their skills through practical experience and theoretical study. Specialists often need to learn independently, access information from free and paid courses, read articles and books related to their field, watch videos, and attend infosec conferences. They regularly consult specialized information resources such as This Week In 4N6 ,, The DFIR Report , and Sentinel Labs , along with Mandiant , Red Canary , and TrustedSec blogs. YouTube is another rich source of information, featuring channels like SANS Digital Forensics and Incident Response , 13Cubed , and John Hammond's channel. Additionally, X (formerly Twitter) is a valuable platform where tags like #DFIR and #DailyDFIR provide timely and helpful information. This Week In 4N6 The DFIR Report Sentinel Labs Mandiant Red Canary TrustedSec SANS Digital Forensics and Incident Response 13Cubed John Hammond's Conclusion The demand for digital forensics is growing along with the expansion of the cybersecurity market, but still exceeds the average for the segment. Most businesses do not require specialists with these skills; instead, digital forensic experts are often employed by specialized firms that offer various information security services. The cost of hiring a forensics specialist is usually open to negotiation and heavily relies on their qualifications and hands-on experience in handling incidents. These specialists have always been and will continue to be in short supply because there are no quick paths to becoming proficient in digital forensics.

The Journey into Digital Forensics: Exploring Career Opportunities (Revealing Insights)

Using Firebase Authentication with the Latest Next.js Features

সর্বশেষ Next.js বৈশিষ্ট্য সহ Firebase প্রমাণীকরণ ব্যবহার করা

Verwenden der Firebase-Authentifizierung mit den neuesten Next.js-Funktionen

Uso de la autenticación de Firebase con las últimas funciones de Next.js

Utilisation de l'authentification Firebase avec les dernières fonctionnalités Next.js

नवीनतम Next.js सुविधाओं के साथ फायरबेस प्रमाणीकरण का उपयोग करना

Usando o Firebase Authentication com os recursos Next.js mais recentes

Использование аутентификации Firebase с новейшими функциями Next.js

Firebase Kimlik Doğrulamasını En Son Next.js Özellikleriyle Kullanma

Sử dụng Xác thực Firebase với các tính năng Next.js mới nhất

将 Firebase 身份验证与最新的 Next.js 功能结合使用

Kubernetes is a leading container orchestration tool that significantly streamlines containerized applications' deployment, scaling, and management. The Kubernetes framework supports a wide range of deployment environments, from cloud to on-premise. Kubernetes makes agile development practices more manageable, ensuring high availability and enabling microservices architectures. It has revolutionized how businesses deploy and manage their applications at scale. Let’s look at some of those use cases in more detail. 1. Microservices Architecture Kubernetes provides a flexible platform that automates many of the challenges associated with . The easy deployment of services within containers ensures each microservice can be developed, deployed, and scaled independently. This independence enables you to roll out updates and development cycles without impacting the entire system. running microservices architecture Maintaining service availability during updates can be achieved because Kubernetes supports zero-downtime deployments and rollbacks. Then, Kubernetes' service discovery and load-balancing capabilities ensure that microservices can communicate efficiently and are always accessible, enhancing overall system reliability and agility. And the auto-scaling feature automatically adjusts the number of running instances based on demand, ensuring optimal resource utilization and performance 2. CI/CD Pipelines Integrating Kubernetes with Continuous Integration and Continuous Deployment (CI/CD) streamlines the entire development lifecycle, from code commit to production rollout. Kubernetes serves as the execution environment where containerized applications are deployed, managed, and scaled. Developers can automatically build, test, and deploy applications using features like . When incorporating Kubernetes into CI/CD pipelines, they get a consistent and isolated environment, ensuring that the application behaves as expected in production. Kubernetes Operators Kubernetes' role in this process includes managing container orchestration, service discovery, and load balancing. Automated rollouts and rollbacks in Kubernetes allow for quick iteration and reliable application updates, reducing downtime and the risk of deployment failures. 3. Cloud-Native Applications Kubernetes also plays a big role in deploying and managing . Its architecture is designed to facilitate the automatic scaling of applications based on demand, ensuring that resources are optimally utilized without manual intervention. cloud-native applications Examples of cloud-native deployment strategies utilizing Kubernetes include blue-green deployments, where two identical environments run different versions of an application to ensure seamless rollbacks and minimal downtime during updates. Another example is canary deployments, where a new version is gradually rolled out to a small subset of users before a full-scale launch, allowing teams to monitor performance and user feedback. 4. Multi-Cloud and Hybrid Cloud Strategies Kubernetes can manage applications seamlessly across multiple cloud providers and hybrid environments that blend cloud and on-premise resources. This orchestration system abstracts the underlying infrastructure and allows you to deploy and manage their applications without being tied to the specifics of any cloud provider. This approach enables companies to leverage the best features and pricing models of different clouds or to utilize existing on-premise investments alongside cloud resources. The biggest benefit here is the avoidance of vendor lock-in, granting you the freedom to shift workloads between cloud providers in response to changing requirements, cost optimizations, or strategic considerations. This flexibility ensures that you are not overly dependent on a single vendor. Moreover, Kubernetes follows a consistent deployment and management experience, streamlining operations and improving efficiency regardless of the environment. 5. Machine Learning Workflows Kubernetes is great at managing complex , making it an interesting tool for teams working with data science and machine learning workflows. It optimizes resource allocation through its auto-scaling capabilities, dynamically adjusting computing resources based on the workload demands of training and inference processes. This ensures that have access to necessary resources while conserving resources when demand wanes, leading to cost-effective operations. machine learning (ML) pipelines ML models When managing dependencies within ML pipelines, Kubernetes allows you to containerize each pipeline component, from data preprocessing to model training and inference. It ensures that each step operates within its isolated environment with specific dependency requirements met. This isolation reduces conflicts and increases reproducibility. The Kubernetes platform also helps with the efficient scaling of ML models. It can deploy multiple instances of a model across a cluster to handle increased inference requests, ensuring that ML applications remain responsive as demand fluctuates. Wrapping Up Kubernetes stands out for its versatility and power in orchestrating containerized applications, catering to a wide array of use cases from microservices and CI/CD pipelines to cloud-native applications and complex machine-learning workflows. Its capabilities in automating deployment, scaling, and management across diverse environments underscore its significance in modern technological landscapes. You should explore Kubernetes and try its extensive applicability to unlock new efficiencies and innovations in your operations and projects.

5 Kubernetes Use Cases: What You Need to Know

The Bitcoin Layer2 project BEVM has announced the completion of its seed round and also a part of its Series A round, raising tens of millions of USD. The 20+ investors include RockTree Capital, Waterdrip Capital, Arkstream Capital, ViaBTC Capital, Satoshi Lab, Web3port, Cogitent Ventures, MH Ventures, Mapleblock, Electrum Capital, Zephyrus Capital, Lotus Capital, 7UPDAO, TimeTells, plus others. BEVM's Series A valuation reached $200 million and accelerated the project’s international development and roll-out. is the first EVM-compatible Bitcoin Layer2 network built on Taproot Consensus and uses $BTC as gas, aiming to bring 10% of $BTC into its Layer2 network environment. BEVM’s testnet Canary network went live in July 2023, which to date has nearly 100,000 on-chain users, processed over 6 million transactions, and currently has more than 30 ecosystem projects. BEVM’s mainnet is scheduled to launch on March 28th. BEVM Gavin Guo, Core Builder of BEVM said “Taproot Consensus is the final result of our team’s six years of exploring Bitcoin Layer2 solutions. BEVM architecture is the most native and decentralized implementation of Bitcoin primitive & ethos into a Layer2, with the complete BEVM product shipped to the community based on MuSig2 + Bitcoin SPVs. BEVM is currently the most decentralized and secure BTC layer2 solution.” BEVM has already implemented decentralized Bitcoin cross-chain custody services through Schnorr Signature, MAST, and Bitcoin SPVs. In the future, BEVM will also launch “ ” to help developers launch ‘BTC layer2’ with one click; it will also launch the protocol to allow $BTC to circulate on any chain in a decentralized manner. BEVM-Stack DBFX Omer Ozden, Chairman of RockTree Capital, said, “We anticipate significant scaling in the Bitcoin ecosystem space over the coming years, as crypto purists seek the most decentralized chain, and also into the longer term future, as TradFi investors with tens of billions of dollars of digital assets seek the highest safety of Bitcoin chain from a Securities Law perspective and the Lindy Effect. BEVM is one of the foremost innovation advancements in this space and is years more advanced in development and users than other L2s we have seen. It won major technical competitions and has significant traction in the Asian market already, the geography where we see the most Bitcoin ecosystem innovation and usage.” The BTC EVM is the primary vision of BEVM; building a decentralized BTC Layer2 compatible with EVM allows seamless deployment of various EVM ecosystem applications on BEVM, increasing Bitcoin usage and commercial scenarios. To find out more about BEVM, visit: Website This story was distributed as a release by BTCWire under HackerNoon’s Business Blogging Program. Learn more about the program here: https://business.hackernoon.com/

BEVM Bitcoin Layer2 Closes Seed Round with RockTree Capital, Sathoshi Lab & 20 Others

BEVM Bitcoin Layer2 RockTree Capital, Sathoshi Lab এবং অন্যান্য 20 এর সাথে সীড রাউন্ড বন্ধ করে

BEVM Bitcoin Layer2 schließt Seed-Runde mit RockTree Capital, Sathoshi Lab und 20 anderen ab

BEVM Bitcoin Layer2 cierra la ronda inicial con RockTree Capital, Sathoshi Lab y otros 20

BEVM Bitcoin Layer2 clôture son cycle de démarrage avec RockTree Capital, Sathoshi Lab et 20 autres

बीईवीएम बिटकॉइन लेयर2 ने रॉकट्री कैपिटल, सातोशी लैब और 20 अन्य के साथ सीड राउंड बंद किया

BEVM Bitcoin Layer2、RockTree Capital、Sathoshi Lab、その他20社とのシードラウンドを終了

BEVM Bitcoin Layer2, RockTree Capital, Sathoshi Lab 및 기타 20개 업체와 시드 라운드 종료

BEVM Bitcoin Layer2 fecha rodada inicial com RockTree Capital, Sathoshi Lab e 20 outros

BEVM Bitcoin Layer2 закрывает посевной раунд с RockTree Capital, Sathoshi Lab и 20 другими

BEVM Bitcoin Layer2, RockTree Capital, Sahoshi Lab ve Diğer 20 Kişiyle Tohum Turunu Kapattı

BEVM Bitcoin Layer2 Kết thúc vòng hạt giống với RockTree Capital, Sathoshi Lab và 20 dự án khác

BEVM Bitcoin Layer2 与 RockTree Capital、Sathoshi Lab 及其他 20 家公司完成种子轮融资

Retrieval-Augmented Generation (RAG) blends the generative abilities of LLMs with the retrieval of information from diverse knowledge bases (KBs). However, traditional implementations of RAG have often relied on pre-scripting the logic for selecting and utilizing these KBs. This conventional method, while effective, places limits on the flexibility and adaptability, and performance of the applications. But consider an alternative: applications that empower the LLM itself to determine which actions are necessary to generate a response. This approach not only harnesses the LLM's generative capabilities but also its ability to make contextual decisions on-the-fly, thereby opening up a more dynamic and responsive way to handle knowledge search tasks. As a result, you can build targeted KB's and use the power of LLMs to write application-specific queries that retrieve better, more relevant results. To demonstrate this approach, we'll build backed by a custom tool.
The chatbot will have access to a KB containing product information - any time you ask a question the chatbot determines could be answered using this tool it will query the KB and show both the in-progress query and retrieved results as custom UI elements before responding with the retrieved products as context. a simple chatbot We'll use Vercel's to render the chat window and Dewy to implement the information storage and retrieval used by our tool and as the knowledge store backing the tool. Generative UI library Dewy Why Dewy and Vercel? is designed to simplify the creation of custom LLM "tools" and to render rich, interactive UI elements that are specific to each tool the LLM chooses to use. Vercel's Generative UI library) What this means in practice is that your UI can dynamically adapt to the specific tools chosen by the LLM, displaying tool-specific information and progress indicators to the user. is an OSS knowledge base with the simplicity and ease-of-use of a document store: insert your documents and Dewy takes care of preparing them for semantic search.
Dewy's flexibility and ease of use allow developers to focus on building amazing user experiences rather than complex data-processing pipelines. Dewy Prerequisites Before diving into the tutorial, ensure you have the following prerequisites covered: Basic knowledge of Typescript and React A NextJS environment setup on your local machine A copy of Dewy running on your local machine (see Dewy's if you need help here). installation instructions Access to the platform. OpenAI API Set up your project : Create a NextJS app by running the following command in your terminal: Initialize a new NextJS project pnpm dlx create-next-app@canary rag-tool Navigate into your new project directory: cd rag-tool : Next, we'll install , Vercel's AI library, , OpenAI's official JavaScript SDK compatible with the Vercel Edge Runtime, and , the Dewy client library. Zod will be used to describe the input types for our custom tool. Install required packages ai openai dewy-ts pnpm install ai openai zod dewy-ts : Configure your OpenAI key and Dewy endpoint. Prepare your environment touch .env.local OPENAI_API_KEY=xxxxxxxxx
DEWY_ENDPOINT=localhost:8000 Create a custom tool First, create the custom tool the LLM will use to answer product-related questions.
This tool describes its purpose and parameters so the LLM knows when and how to use it, and defines the implementation and UI logic to complete the tool invocation. In this case, the tool will "get information about products", given a search query and a result count. When the LLM determines this tool should be used, it will generate the query string and choose how many results are appropriate, then execute the function defined below. render On execution, the tool searches Dewy for relevant products, then calls the LLM again to pick up where it left off. Since this process can take awhile, the function 's components indicating that the tool is being used and its progress. These components allow the UI to reflect the specific information relevant to this tool's outcomes. render yield import { z } from 'zod';
import { Dewy } from 'dewy-ts';
import { OpenAIStream } from 'ai'
import { Tokens } from 'ai/react';

import AssistantMessage from './AssistantMessage';
import ResultCard from './ResultCard';
import SearchCard from './SearchCard';

// Create a Dewy client.
const dewy = new Dewy({
    BASE: process.env.DEWY_ENDPOINT
})

// Implement the tool's logic.
// In this case, we search for the given query
// and return the `count` most similar chunks in the KB.
// The returned chunks are used in the `render` method below.
async function searchProducts(query: string, count: number) {
    const context = await dewy.kb.retrieveChunks({
        collection: "product_info",
        query: query,
        n: count,
    })
    return context.text_results.map(c => c.text)
}

// Define the behavior of the product search tool.
export default function productSearch(aiState, openai) {
    return {
        // A description of the tool.
        // This used by the LLM to decide when to use the tool
        description: 'Get information about products',

        // Parameters control how the tool behaves.
        // These values will be picked by the LLM,
        // so be sure to clearly explain what they're
        // used for.
        parameters: z.object({
            query: z.string().describe(```
                A description of a product 
                or what the product can be used for.
            ```),
            count: z.number().describe(```
                The number of products to return.
            ```),
        }).required(),

        // Configure the tool's behavior.
        // This function will be called after the LLM has
        // chosen to use the tool and generated values for
        // the parameters we configured above.
        render: async function* ({ query, count }) {
            // Let the user know we're looking for 
            // products related to their message
            yield <SearchCard query={query} count={count} />

            // Search for products related to the user's question
            const products = await searchProducts(query, count)

            // Update the message history 
            // with the results we found
            aiState.update([
                ...aiState.get(),
                {
                    role: "function",
                    name: "product_search",
                    content: JSON.stringify(products),
                }
            ]);

            // Now reply to the user.
            // The products we retrieved are part of the state 
            // provided as the messages parameter
            const resp = await openai.chat.completions.create({
                model: 'gpt-4-0125-preview',
                messages: aiState.get(),
                stream: true,
            })

            // Stream the results back as they're generated
            const stream = OpenAIStream(resp, {
                onFinal: (completion) => {
                    // Update the conversation history 
                    // once the full response is received
                    aiState.done([
                        ...aiState.get(),
                        {
                            role: "assistant",
                            content: completion,
                        }
                    ])
                }
            });

            // Display the response alongside 
            // the products provided to the model.
            return <div className="flex flex-col gap-2">
                <ResultCard query={query} results={context} />
                <AssistantMessage>
                    <Tokens stream={stream} />
                </AssistantMessage>
            </div>
        }
    }
} Setup the server-side message handler Configure a message handling action to receive new messages from the client.
This handler configures the initial state of the chatbot and defines the server's behavior when a message is received from the user. import { OpenAI } from 'openai';
import { createAI, createStreamableUI, getMutableAIState, render } from 'ai/rsc';

import productSearch from './productSearch';
import AssistantMessage from './AssistantMessage';

// Configure the LLM, in this case OpenAI
const openai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
});
 
async function submitUserMessage(userInput: string) {
  'use server';
 
  // The AI state. This contains our message history,
  // and will be provided to the LLM each time a 
  // chat completion is generated.
  const aiState = getMutableAIState<typeof AI>();
  aiState.update([
    ...aiState.get(),
    {
      role: 'user',
      content: userInput,
    },
  ]);
 
  // Helper function for building streamable UI components.
  const ui = render({
    model: 'gpt-4-0125-preview',
    provider: openai,
    messages: [
      { role: 'system', content: `
        You are a product recommendation engine. 
        Respond only with information about products 
        retrieved using the "product_search" function role.
        `},
      { role: 'user', content: userInput }
    ],

    // This determines how generated text 
    // (as opposed to function calls) will
    // be rendered.
    text: ({ content, done }) => {
      if (done) {
        aiState.done([
          ...aiState.get(),
          {
            role: "assistant",
            content
          }
        ]);
      }
      return <AssistantMessage>{content}</AssistantMessage>
    },

    // Configure the tools available to the LLM
    tools: {
      product_search: productSearch(aiState, openai),
    }
  })
 
  return {
    id: Date.now(),
    display: ui
  };
}
 
// Define the initial state of the AI. It can be any JSON object.
const initialAIState: {
  role: 'user' | 'assistant' | 'system' | 'function';
  content: string;
  id?: string;
  name?: string;
}[] = [];
 
// The initial UI state that the client will keep track of, which contains the message IDs and their UI nodes.
const initialUIState: {
  id: number;
  display: React.ReactNode;
}[] = [{id: 0, display: <AssistantMessage>Hi! How can I help you today?</AssistantMessage>}];
 
// AI is a provider you wrap your application with so you can access AI and UI state in your components.
export const AI = createAI({
  actions: {
    submitUserMessage
  },
  // Each state can be any shape of object, but for chat applications
  // it makes sense to have an array of messages. Or you may prefer something like { id: number, messages: Message[] }
  initialUIState,
  initialAIState
}); Setup the chat UI on the client Finally, set up the chat UI on the client. Map over the UI state's messages and insert their property. display Configure a form to update the AI state, then call the server side handler. submitUserMessage 'use client'
 
import { useState } from 'react';
import { useUIState, useActions } from 'ai/rsc';
import type { AI } from './action';
import { Input } from '@/components/ui/input';
import { Button } from '@/components/ui/button';
 
import UserMessage from './UserMessage';
import { PlaneIcon } from './icons';

export default function Page() {
  const [inputValue, setInputValue] = useState('');
  const [messages, setMessages] = useUIState<typeof AI>();
  const { submitUserMessage } = useActions<typeof AI>();
 
  return (
    <>
      <div className="flex-1 overflow-auto px-4 mt-4">
        <div className="grid gap-4 md:gap-8">
          {
            messages.map((message) => (
              <div key={message.id}>
                {message.display}
              </div>
            ))
          }

        </div>
      </div>

      <form onSubmit={async (e) => {
        e.preventDefault();

        // Add user message to UI state
        setMessages((currentMessages) => [
          ...currentMessages,
          {
            id: Date.now(),
            display: <UserMessage>{inputValue}</UserMessage>,
          },
        ]);

        // Submit and get response message
        const responseMessage = await submitUserMessage(inputValue);
        setMessages((currentMessages) => [
          ...currentMessages,
          responseMessage,
        ]);

        setInputValue('');
      }}>
        <div className="border-t-2">
          <div className="flex items-center h-14 px-4">
            <Input
              className="rounded-full flex-1 min-w-0 bg-gray-200 dark:bg-gray-800"
              placeholder="Type a message..."
              value={inputValue}
              type="text"
              onChange={(event) => {
                setInputValue(event.target.value)
              }}
            />
            <Button className="ml-2 h-8 w-8 rounded-full bg-gray-200 dark:bg-gray-800" size="icon">
              <PlaneIcon className="h-4 w-4" />
              <span className="sr-only">Send message</span>
            </Button>
          </div>
        </div>
      </form>
    </>
  )
} To keep this post from going any longer than it is already, several basic UI components have been omitted, but you can checkout the full implementation in the of the Dewy repo. examples directory Conclusion In conclusion, this blog post has guided you through the process of building a Retrieval-Augmented Generation (RAG) tool using Vercel's Generative UI components. This approach moves away from the traditional methods of pre-scripting logic for selecting and utilizing knowledge bases. By empowering the LLM to determine which knowledge bases are necessary and how best to use them, we've showcased a more dynamic, efficient, and user-centric way of handling information retrieval tasks. By utilizing Dewy as our knowledge base, we've emphasized the importance of a flexible, easy-to-use platform for storing, organizing, and retrieving information. This synergy between Dewy's streamlined data management and Vercel's dynamic UI rendering paves the way for developers to create more intelligent, responsive, and user-friendly applications. Also appears . here

How to Build a "RAG Tool" With Vercel's Generative UI Components

Let's learn about via these 46 free stories. They are ordered by most time reading created on HackerNoon. Visit the to find the most read stories about any technology. Product Launch /Learn Repo 1. OpenBB Terminal 2.0 is More Than an Alternative for Bloomberg Terminal OpenBB Terminal 2.0 is more than an application, it’s a platform. 2. Why is a Product Owner Needed (PO)? This article explains the day-to-day responsibilities and the skills required to be a successful Product Owner in a SaaS tech company. 3. What Makes a Successful Product Launch: 6 Lessons for First Time Founders Launch is neither the beginning nor the end. It is a series of overlapping sequences. A typical one may include pre-build, pre-launch, launch, and post-launch. 4. Introducing ApiHome: Home of API Testing OpenAPI based API Testing Tool 5. The First Week of YourStack 2,281 days ago Product Hunt launched as a tiny newsletter. The early days were especially chaotic. I didn’t get much sleep, skipped the gym, and buried my head into work. While unsustainable (I'm not advocating overworking yourself!), it was sooo fun and energizing to build something brand new. It was also scary. New products – especially those driven by community – are incredibly fragile. 7 days ago we launched a beta of YourStack (with a grammatically incorrect, non-editable tweet – lol). Instantly those same nostalgic feelings from the early days of Product Hunt re-emerged. The response has been very encouraging. Alex was kind enough to write about it on BuzzFeed. Lucas followed with a story on TechCrunch. And a bunch of folks shared support on Twitter and Product Hunt. But the product is very early and our roadmap is deep. So far we've onboarded only ~4% of those that have signed up as we build tooling to scale (thanks for all your patience!). I wake up each morning nervous but excited to read your feedback and wild ideas as the team and I continue building. If you get a chance, create your account and start stacking. We're whitelisting new friendly folks each day. Feedback? I'd love to hear it at ryan@yourstack.com. Cheers,
Ryan Hoover (@rrhoover) 6. How to Print Your Tweets onto Tshirts Tech Startup Allows Customers to Easily Print Any Tweet on a T-Shirt 7. I Launched on New Year's Eve and This is What I've Learned Three months ago in the Bay Area, I was working on another project, had an ex-Google tech co-founder, and a chat bot nobody cared about. 8. A Complete Guide To SKU Management For Retailers SKU management is the process of creating, organizing, and perfecting an alphanumeric SKU system for the items in your inventory. SKUs give inventory details. 9. How To Start an App Business in 8 Simple Steps Starting an app startup can be overwhelming. Here's how to go all the way from ideation to marketing in 8 (relatively) easy steps. 10. How to Bridge the Developer Experience Gap with raise.dev I founded Raise.dev to help every developer advance their career. 11. Bye Bye Google: How I Botched My Company's Launch After Leaving I like to analyze my past work through the prism of evaluating my mistakes (I’m sure my therapist would have a field day with that one). I launched my first publicly available engineering project in early December and as George W. Bush once said, “Mistakes were made”. 12. How to Get Over 1000 Beta Testers for Your SaaS App in 1 Week A couple of weeks ago, we released our new SaaS app MagicFlow (2K+ MRR) to the public after a 1.5 months beta period. 13. I Built a Tool to Help You Sketch Out an MVP Proposal in Minutes How would you go from an idea to a potential product? 14. Wikipedia Sucks: There's a Solution by Wiki’s Real Daddy Dr. Sanger, a respected internet visionary highlights Wiki’s shocking deterioration and provides a solution for the monster that has become Wikipedia. 15. How I Got 78 Criticisms on Show Hacker News for My Zoom Competitor Last month, I launched the app on Show HN. As a result, it got 82 points and 78 comments. Ranked in the toppest 10 of popular posts in a day also. Actually, we have pros and cons about it and people tend to criticize it more. Anyway, it felt so amazing that a lot of the people across the world visited my website and said hi to me. What an exciting moment! Today, I’d like to share how to develop and launch a landing page. 16. 5 Tips For Launching a Successful Product Many new products get launched in the market every day. But not every product is a hit. 17. The Archethic Mainnet Has Officially Been Launched "Fully decentralized, open-source public blockchain with high speed and low transaction fees made by the people, for the people" 18. Tech News Playlist: Nigerian Founder is Back, Retail Startup Wins Ignite 2022 Today’s news includes the foundation of Venture Studio, the 2022 Startup World Cup, as well as the latest on aerospace, cybersecurity, and crypto. 19. How Slack's Huddles Gave Us The Boost We Needed To Launch Remote working makes it hard to have the spontaneity that offices can bring. Slack Huddles managed to bring that to one team's successful bid for ProductHunt 20. Just Launched ConnectDome to Solve Networking for Developers Interacting to exchange info and develop professional or social contacts can be tricky. Check out the newly launched ConnectDome for a potential solution. 21. Compare Twitter Social Graphs with Vennly Search Vennly to see the intersection of any 2 Twitter social graphs. 22. Every GTM Should Be A Phased Launch and Here's Why The “big splash” rollout is often a big mistake. Methodical phased launches lead to higher success rates and lower churn rates 23. How I Got To #1 on Product Hunt as a Nobody I am a nobody on the internet; not an influencer, not a VC, and not a serial entrepreneur. I only had about 100 followers on Twitter prior to launching. But my product, One Profile, was recently awarded #1 Product of the Day on Product Hunt (PH) and that has changed my life. 24. I Outsourced Label Manufacturing To Jump Start My eCommerce Business Private label manufacturers can be a game-changer for any e-commerce business.  We're discussing how they help and how to work with them. 25. Why Do Product Managers and Product Designers Need Each Other? Teammates, not opponents. That’s how product managers and product designers are expected to work in product teams. 26. I Took Ownership of a Major Product Feature as a PM Intern This post will cover Denis’ workflow from planning to execution around the Preferences project as well as his experience working with the Courier team. 27. 7 Benefits of MVP for Startups In this article, we are considering key peculiarities and benefits of a minimum viable product that will help you enter the market more successfully. 28. Efficient Deployment and Release Management “Do not deploy on Friday” is not a joke after all even if you have continuous deployment. With deciding to deploy anyway comes the subtle concern... 29. How We Made a Slack App in 11 Days Hey, everyone! We, the Indie Hackers SPB Community, organized a one-week Bootcamp: in our free time, we built a product from scratch and launched it on Product Hunt. We got the #3 Product of the Day badge and over 30 installs of our app in the Slack Workspaces. Now, I want to share our experience. At the end of this article, I will share our Notion checklist, that we found extremely helpful for the launch preparation :) 30. Convert PDF Document in Three Steps using DynamicDocs API Advicement newly launched DynamicDocs API gives businesses the ability to automatically generate PDF documents with dynamic text, tables and charts. 31. How to Launch a Product Successfully The phone balanced high-end quality with a mid-range price tag, offering a top of the range smartphone on the level of a flagship Samsung Galaxy for half the price. When word got out — through social media and tech sites who marvelled at the quality to price ratio — consumer interest spiked. 32. Kempus is What Facebook was Intended to Be An interview with a CEO you're about to hear a lot about. 33. SPARQ Launches on App Store and Google Play After months of validating the concept and testing the app, SPARQ’s time has finally come! 34. Chase Bowers Got His First Thousand Customers Without Spending Any Money - Here's How! How Did Chase Bowers Get 1,000+ New Customers Without Spending a Dime? He gave away 1,000 free plans, used feedback to improve, & then launched paid plans. 35. Don't Make These Common Mistakes When Launching Your Website On October 22 I've launched online my first website. I'd like to share with you my experience. 36. How To Sustain Your Business In The Post-Pandemic World I decided to cover today the concept of how to push your business in the post-pandemic world since I think it is more than ever a tragic and unprecedented situation that we are in today. 37. 4 Creative Ways to Generate Buzz for Your Product Launch Are you having trouble generating buzz around your new product launch? Check out our guide on how to generate buzz for your new product launch. 38. Looking for a New Smartphone Led Me to Create a Platform That Aims to Reverse the Product-Market Fit We have hundreds of brands producing the same things and no one catering for any other needs, be it in terms of size, keyboard, or other characteristics. 39. How to get featured on Product Hunt Everyone dreams of making it to the front page of Product Hunt. It’s a chance to show off your creation to thousands of tech enthusiasts. 40. Gradual Code Releases: An In-House Kubernetes Canary Controller Our short-term strategy involved developing an in-house Canary deployment process powered by a custom Kubernetes controller. 41. Hacking Your Product Hunt Launch [A How-To Guide] If you still don’t know what Product Hunt is and why you should do your launch on this platform, I suggest you read this article, this is the official Product Hunt post, a must read. 42. Scoping Out The Elements Involved In Effective Product Management Product management has seen a lot of takers in the last few years. This field is so varied and versatile that putting bounds to it is a daunting task. Nevertheless, based on my experience and knowledge gained from the circles of product community; I have listed down different fundamental elements of product management. 43. An Overview of our PH Launch for AskMakers v2.0 Oh…I am so sleepy…because I launched AskMakers 2.0 on Product Hunt and I have been monitoring it almost without sleeping😪 44. How to Get Featured on Product Hunt Without a Hunter How to launch on Product Hunt and get to the top-5 products of the day? I share fresh tips and heads-up based on successful and failed 2021 ProductHunt launches 45. 🚀 Ultimate Startup Launch Checklist: 2020 Edition 🚀 Over the past few years, I've had the great chance to help some awesome SaaS startups with their digital marketing. 46. Minimize Risk When Launching Digital Products And Make Passive Income Launching a new digital product is risky... unless you're following this zero-risk validation model Thank you for checking out the 46 most read stories about Product Launch on HackerNoon. to find the most read stories about any technology. Visit the /Learn Repo

46 Stories To Learn About Product Launch

266 Stories To Learn About Product Development

Stories, News & Mentions about CANARY

Canary’s Stories on HackerNoon