Google AI Studio: Full Guide to Google’s AI Tools

If your online store is growing, sooner or later a key infrastructure question arises: cloud or dedicated server? Which one can be launched faster, which will survive peak loads without “crashes,” and how much will it cost with backups and administration? In this article, we will examine the key differences between the cloud and a dedicated server, ways of calculating the total cost of ownership (TCO), and typical bottlenecks in e-commerce: the database, cache, and static files. Cloud and Dedicated Server: Main Differences Let’s draw a simple analogy. The cloud is like a room in a hotel: you can move in quickly, request another room if necessary, cleaning and maintenance are included.  A dedicated server is like owning a house: it is completely yours, no one shares resources, but you need to take care of it yourself. How the Cloud Works You create a cloud server with the necessary configuration and can quickly change its parameters: increase memory, disk space, or add another server for web applications. Usually, this is accompanied by a flexible payment system—for example, in Hostman it is hourly.  The advantages are quick launch, scalability, convenient backups and snapshots. The disadvantages are that with excessive resources it is easy to overpay, and with round-the-clock high load, the cost may be higher than that of a dedicated server. How a Dedicated Server Works This is renting a physical server in a data center. The resources are entirely yours: CPU, memory, disks—without any “neighbors.”  The advantages are stable performance and a favorable price with constant heavy traffic. The disadvantages are slower scaling (waiting for an upgrade or migration), service downtime during failures may last longer, and administration of the server and organization of backups are entirely the responsibility of the client. What’s More Important for a Small Store You can launch an online store in the cloud today, in mere hours. When renting a dedicated server, allow time for its preparation: engineers need to assemble and test the configuration, especially if you ordered a custom one. Usually this takes a couple of days.  In the cloud, resources can be increased in a few clicks. On a dedicated server, the scaling process takes longer: you need to coordinate changes with engineers, wait for components, and install them in the data center. In some cases, it may require migration to a new server. Cloud offers many ready-made tools and automation. A dedicated server, as a rule, will require more manual configuration and regular involvement of an engineer. Money: if you have 20–300 orders per day and traffic “jumps,” the cloud is usually more profitable and quite suitable for solving such tasks. If orders are consistently high, 24/7, without sharp spikes, a dedicated server will be more reliable. In short: if you are just starting out, choose the cloud. When the load becomes consistently high, you can consider a dedicated server. Key Criteria When Choosing Infrastructure for an Online Store Let’s look at the key criteria to pay attention to when choosing between a cloud and a dedicated server. Speed of launch It is important for a business to launch in hours, not days. A cloud server and database are ready in just minutes. A dedicated server takes longer to prepare: on average, about an hour, and when ordering a custom configuration, it may take several days. Expenses Expenses in a small project can be calculated as the sum of these items:  Infrastructure: server, disks, traffic, IP, domains, CDN.  Reliability: backups and storing copies separately.  Administration: updates, monitoring, on-call duty.  Downtime: how much one hour of downtime costs (lost revenue + reputation). Peak loads Sometimes stores run sales, order promotions from bloggers, or it is simply the business season.  In the cloud, you can scale horizontally, setting up another VM, and vertically, by adding more vCPU and RAM.  To speed up images and static files loading, you can connect a CDN—this is equally available in the cloud and on a dedicated server.  With a dedicated server, you either have to pay for all the reserve capacity year-round, or request installation of additional modules—which, again, can take some time (hours or days, depending on component availability). Reliability and recovery There are two main parameters to consider when planning recovery time.  RTO: how much time the project can take to recover after downtime (goal: up to an hour).  RPO: how much data you are ready to lose during recovery (goal: up to 15 minutes, meaning that after the system is restored, you may lose only the data created in the last 15 minutes before the failure). Check: are backups scheduled, are copies stored outside the production server, will the system be able to recover automatically if production goes down. Security At a minimum, configure the site to work through an SSL certificate, set up multi-factor authentication in the control panel for administrators, and create a private network between the web server and the database. Performance Usually the bottlenecks of e-commerce are the database, cache, and images. To avoid problems when scaling, put images and videos in object storage, keep the database as a separate service, preferably with data replication. Monitor the response times of the cart and checkout pages—this is where sales most often fail if pages respond slowly. Growth and flexibility We recommend starting with a simple and reliable scheme: one cloud server + one separate database (DBaaS) + object storage for media. If you plan a sale, add another cloud server and a load balancer to distribute user traffic. Afterwards, return to the original scheme. Flexibility in this case may be more important than the “perfect” architecture at the start. Team competencies If there is no system administrator or developer in the team who can perform sysadmin functions, choose simple solutions: ready CMS images, managed DBs, automatic backups, built-in monitoring. The less manual work, the fewer risks. Building Reliable Infrastructure For a small store, a simple logic works: start with minimal but healthy architecture, and quickly increase capacity during sales. And just as quickly return to normal mode. Start with a clean cloud server on Ubuntu LTS, connect access via SSH keys, and disable password login. At the firewall level, leave only ports 80/443, the others are better disabled.  An alternative option is to use control panels (cPanel, FastPanel, etc.), where the stack is deployed “out of the box” and administration is available through a convenient graphical interface. Place the database separately and connect it to the application through a private network. This way it will not be accessible from the internet, and delays will be reduced. Create a separate DB user with minimal rights for the site, enable daily backups and store them outside the production environment. For sessions and cache use Redis: it will reduce load on the database and speed up product cards, search, and order processing. Transfer media files to object storage: CMS can easily be configured so that new uploads go to S3. On top of this, connect a CDN for images, JS, and CSS—this will provide a stable response speed for users from any region and relieve a significant load from web servers. Do not forget about Cache-Control and ETag headers: they will allow users’ browsers to keep static files longer in local cache, which speeds up site loading and reduces server load. Backups are part of the daily routine. For the database, make a daily full backup and several incremental points during the day, store copies for at least 30 days, and place them in another project or storage. Protect files and media with versioning in S3 and weekly server snapshots. Once a quarter perform a recovery “from scratch” on a clean machine to check your RTO and RPO. Monitoring allows you to reduce risks and prevent losses before failures occur. Monitor the response time for the cart and checkout, CPU load, and free disk space. Threshold values should be tied to your traffic: if response time goes down and CPU stays high, get ready to scale. A sales campaign should be prepared as carefully as a separate release. A day or two before launch make a snapshot and bring up a second machine, enable the load balancer, and check that sessions are in Redis so carts are not lost. Prepare the CDN in advance: open the most visited pages, product cards, and search results. Increase database resources in advance and check indexes on fields used for filtering and sorting. After the campaign ends, disable additional servers. Approach security issues without excessive measures, but consistently and systematically. In the store’s admin panel, enable multi-factor authentication and roles, on servers, prohibit SSH passwords, limit by IP, and use fail2ban against password brute force. To avoid overpaying, calculate infrastructure by roles: server, DB, S3 storage, CDN, snapshots and admin hours. Launch additional capacity only during peak days, and under normal load, plan infrastructure based on basic needs. Evaluate the cost of downtime: if it is higher than the cost of an additional server for a week, reserving resources for a promotion will be economically justified. Migration from a dedicated server to cloud hosting is safe if done in two phases. Prepare a copy of the infrastructure, place media files in S3 storage, and run the site on a test domain with regular DB synchronization. On migration day, freeze changes, make the final dump, lower TTL, and switch DNS. After switching, monitor metrics and logs, and keep the previous production environment in “read-only” mode for a day for emergency access. If you need size guidelines, think in terms of load.  Up to one hundred orders per day is usually enough with a server of 2 vCPU and 4–8 GB of memory, a separate DB of 1–2 vCPU and 2–4 GB, SSD of 60–120 GB, and a combination of S3+CDN with Redis.  With a load of 100–500 orders per day it is reasonable to use two cloud servers and a load balancer, a database with 2–4 vCPU and 8–16 GB, and if necessary, add a read replica.  With stable peak loads, the infrastructure is scaled to 2–3 cloud servers with 4–8 vCPU and 16 GB, a database with 4–8 vCPU and 32 GB, replication, and mandatory CDN.  These are starting points; further decisions are dictated by metrics. Conclusion There is no single correct answer in this subject. The choice between cloud and dedicated server depends on traffic, frequency of peaks, team competencies, and how much one hour of downtime costs you. It is important not to guess, but to rely on numbers and understand how quickly you can increase capacity and recover after a failure. If the store is small or growing, it is reasonable to start with the cloud: one server for the application, a separate DB, and object storage for media. Such a scheme can be launched in an evening, handles sales without long downtime, and does not force you to pay for “reserve” all year. The main thing is to immediately enable backups, configure a private network between the server and the DB, and have a scaling plan ready for sales days. When traffic becomes steady and high 24/7, and requirements for performance and integrations tighten, it makes sense to consider a dedicated server or hybrid. Often a combination works where the frontend application and static files remain in the cloud for flexibility, while the heavy DB or specific services move to “hardware.” The decision should be made not by preference, but by TCO, RTO/RPO, and load metrics.

The year 2025 has truly become the year of flourishing AI agents, and this trend continues to gain momentum. Not long ago, many were only discussing the concept, but today we can see real-world applications of AI agents actively being integrated into development processes. Of particular interest are open-source AI agents, which allow teams not only to use but also to adapt the technology to their own needs. In this article, we will look at how these AI tools have evolved and how they help solve complex software engineering tasks. We’ll start with an overview of the early but important players, such as Devstral, and move on to more up-to-date AI agent applications available now. Overview of the Open-Source AI Agent Landscape for Coding The first noticeable steps toward open agents for development were made with models such as Devstral. Developed in collaboration between Mistral AI and All Hands AI, Devstral became a breakthrough solution. Thanks to its lightweight architecture (only 24 billion parameters), it could run on a single Nvidia RTX 4090, making it accessible for local use. With a large context window of 128k tokens and an advanced tokenizer, it handled multi-step tasks in large codebases very well. However, the AI world doesn’t stand still. Today, many new, more productive and functional agents have appeared. Among them, the following stand out: OpenHands: One of the most popular open-source frameworks today. It provides a flexible platform for creating and deploying agents, allowing developers to easily integrate different LLMs for task execution. Moatless Tools: A set of tools that expand agent capabilities, allowing them to interact with various services and APIs, making them especially effective for automating complex workflows. Refact.ai: A full-fledged open-source AI assistant focusing on refactoring, code analysis, and test writing. It offers a wide range of functions to boost developer productivity. SWE-agent and its mini version mini: Tools developed by researchers from Princeton and Stanford. SWE-agent allows LLMs, such as GPT-4o, to autonomously solve tasks in real GitHub repositories, demonstrating high efficiency. The compact mini version (just 100 lines of code) can solve 65% of tasks from the SWE-bench benchmark, making it a great choice for researchers and developers who need a simple yet powerful agent-building tool. Each of these projects contributes to the development of agent-based coding, providing developers with powerful and flexible tools. SWE-Bench: The Standard for Evaluating Agent Coding To understand how effectively these agents work, a reliable evaluation system is necessary. This role is played by SWE-Bench, which has become the de facto standard for measuring LLM capabilities in software engineering. The benchmark consists of 2,294 real GitHub issues taken from 12 popular Python repositories. To improve evaluation accuracy, SWE-Bench Verified was created—a carefully curated subset of 500 tasks. These tasks were analyzed by professional developers and divided by complexity: 196 “easy” (less than 15 minutes to fix) and 45 “hard” (over an hour). A task is considered solved if the changes proposed by the model pass all unit tests successfully. Originally, Devstral was among the leaders on SWE-Bench Verified among open-source models. For example, in May 2025, the OpenHands + Devstral Small 2505 combo successfully solved 46.8% of tasks. But the AI-agent world is evolving incredibly fast. Just three months later, in August 2025, these results don’t even make the top ten anymore. The current leader, Trae.ai, shows an impressive 75.20% of solved tasks—a clear demonstration of how quickly these technologies are progressing. Not Just Benchmarks, But Real Work At first glance, it might seem that the only important metric for an AI agent is its performance on benchmarks like SWE-Bench. And of course, impressive numbers like those of Trae.ai speak volumes. But in practice, when solving real tasks, functionality and workflow integration matter much more than raw percentages. Modern AI agents are not just code-generating models. They’ve become true multi-tool assistants, capable of: interacting with Git, running tests, analyzing logs, even creating pull requests. Still, they differ, and each has its strengths: Devstral is great for multi-step tasks in large codebases. Its lightweight design and large context window make it valuable for local workflows. OpenHands is less of an agent itself and more of a flexible platform for building and deploying agents tailored to specific needs, easily integrating different language models. Refact.ai is a full-fledged assistant focusing on analysis, refactoring, and test writing, helping developers maintain high code quality. And let’s not forget SaaS solutions that have been breaking revenue records since the start of the year: Replit, Bolt, Lovable, and others. Ultimately, the choice of an agent depends on the specific task: do you need a tool for complex multi-step changes, a flexible platform to build your own solution, or an assistant to help with refactoring? In the end, their main advantage is not just the ability to write code but their seamless integration into workflows, taking over routine and complex tasks. Launching Your Own Agent Let’s look at how to deploy one of the modern agents, OpenHands. We’ll use the Devstral model, since it remains one of the open-source models that can run on your own hardware. Preparing the GPU Server First, you will need a server. Choose a suitable configuration with a GPU (for example, NVIDIA A100) to ensure the necessary performance. After creating the server, connect to it via SSH. Installing Dependencies Update packages and install Docker, which will be used to run OpenHands. Example for Ubuntu: sudo apt update && sudo apt install docker.io -y Setting Up and Running OpenHands We’ll use a prebuilt Docker image of OpenHands to simplify deployment: docker pull docker.all-hands.dev/all-hands-ai/runtime:0.51-nikolaik docker run -it --rm --pull=always \ -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:0.51-nikolaik \ -e LOG_ALL_EVENTS=true \ -v /var/run/docker.sock:/var/run/docker.sock \ -v ~/.openhands:/.openhands \ -p 0.0.0.0:3000:3000 \ --add-host host.docker.internal:host-gateway \ --name openhands-app \ docker.all-hands.dev/all-hands-ai/openhands:0.51 This command will launch OpenHands in a Docker container, accessible via your server’s address at port 3000. During startup, you’ll get a URL for the OpenHands web interface. The option -p 0.0.0.0:3000:3000 means OpenHands will be accessible externally. By default, the web interface does not require login or password, so use caution. Connecting to the Agent Open in your browser: https://SERVER-IP:3000 You’ll see this screen: Installing the Language Model (LLM) To function, the agent needs an LLM. OpenHands supports APIs from various providers such as OpenAI (GPT family), Anthropic (Claude family), Google Gemini, and others. But since we’re using a GPU server, the model can be run locally. The OpenHands + Devstral Small combo is still a top open-source performer on SWE-Bench, so we’ll use that model. First, install the model locally. The method depends on the service you’ll use to run it. The simplest option is via Hugging Face: huggingface-cli download mistralai/Devstral-Small-2505 --local-dir mistralai/Devstral-Small-2505 You can run the model with Ollama, vLLM, or other popular solutions. In our case, we used vLLM: vllm serve mistralai/Devstral-Small-2505 \     --host 127.0.0.1 --port 8000 \     --api-key local-llm \     --tensor-parallel-size 2 \     --served-model-name Devstral-Small-2505 \     --enable-prefix-caching Adding the Model to OpenHands In the LLM settings of OpenHands, go to “see advanced settings” and fill in: Custom model: mistralai/Devstral-Small-2505 Base URL: http://127.0.0.1:8000/v1 (depends on your service setup) API Key: local-llm (may vary by setup) The Future of Agent-Based Coding: More Than Just Autocompletion The evolution from Devstral to platforms like OpenHands shows that we are moving from simple models to full-fledged autonomous tools. LLM agents are no longer just “improved autocompletes”; they are real development assistants, capable of taking on routine and complex tasks. They can: Implement features requiring changes across dozens of files. Automatically create and run tests for new or existing code. Perform refactoring and optimization at the project-wide level. Interact with Git, automatically creating branches and pull requests. Agents like Refact.ai are already integrating into IDEs, while OpenHands enables building a full AI-driven CI/CD pipeline. The future points to a world where developers act more as architects and overseers, while routine work is automated with AI agents.

Computer performance in any segment often comes down to the speed of reading and writing data from storage devices. This is one of the main reasons for the widespread transition to SSD drives, which offer speeds at least 3 to 5 times higher than HDDs. Partly because of this, devices such as RAID arrays began to appear. They allowed building relatively fast systems, even using outdated hard drives. And this is not the only advantage of RAID technology. Its second key function is increasing the reliability of the data storage subsystem, including the ability to preserve information even in the event of a hardware failure of one of the drives. In practice, these capabilities are often combined. Consumer systems usually represent a "simple combining" of a pair of drives into a single cluster to increase speed or consolidate their capacity. What Is a RAID Array? The term RAID stands for Redundant Array of Independent Disks. The technology allows combining several storage devices into a single logical unit. Depending on the type of RAID array, the user gets improved fault tolerance, increased performance, or both. Its configuration in technical environments is called the RAID level. There are four common types (marked by numbers): RAID 0 — involves striping data across disks during reading and writing, resulting in nearly double the speed compared to a single drive. Fault tolerance does not increase; this is only about improved performance. RAID 1 — mirrors disks, doubling fault tolerance. However, it does not affect data transfer speeds. In case of a disk failure, the system remains operational, and after replacing the disk, the mirror is restored. RAID 5 — a combined option with striping for reading/writing and parity data for fault tolerance. Requires at least 3 drives. It offers higher read speeds and safety, but slightly slower write speeds. RAID 10 — a combination of RAID 0 and RAID 1. It includes a number of disks divisible by 4. The first pair of drives is striped and mirrored onto the second pair, creating a single array with high performance and fault tolerance. RAID arrays are created from either SSDs or HDDs. It is preferable to use identical models from the same manufacturer, though formally, there are no strict restrictions. For data centers or large server enterprises, these recommendations are usually followed because it is more cost-effective to buy bulk identical drives for equipping computers and creating a spare pool for technical failures. When upgrading, often the entire block is replaced to reset its lifecycle. There are two ways to create a RAID array. The first involves installing special drivers (software). In this case, it is managed by the operating system. The second involves installing a dedicated hardware controller card. Such chips have long been integrated into motherboards, even for home use, but the CPU still controls them. The optimal choice is to use external controllers that handle most functions in hardware. Types of RAID Controllers Typically, a modular RAID controller connects to a free PCI-E slot. It includes its own cache memory used for temporarily storing data being read or written. It operates under its own microcontroller, and the cards may include backup power sources (BBU, Battery Backup Unit) or flash memory with supercapacitors. Linux Software RAID On Linux, the mdadm utility can create and manage software RAID arrays of most common levels. Requires permanently connected drives (internal or always-attached). Consumes some CPU cycles, but modern CPUs handle this overhead easily for most workloads. Status and configuration are accessible via /proc/mdstat and mdadm commands. Example creation of a RAID 1 array: mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/nvme1n1 /dev/nvme2n1 The result is a single block device /dev/md0 that abstracts the underlying drives. Intel Virtual RAID on CPU (VROC) Intel VROC is a firmware-assisted NVMe RAID solution built into Intel Xeon Scalable platforms. It requires a VROC license key to unlock RAID functionality beyond RAID 0 and works with Intel Volume Management Device (VMD) technology for NVMe hot-swap capability. As of 2025, supported OS/platforms include: Windows 11, Windows Server 2022, Windows Server 2025 RHEL 7.3–9.x, SLES 12 SP3–15 SP6, Ubuntu 18.04–24.04 LTS VMware ESXi 7.0 U3 and 8.x (ESXi 9.0 planned) The RAID levels are 0, 1, 10 with standard license, while premium license also adds RAID 5 (RAID 6 not supported). Notes: Supported drive count varies by platform (commonly up to 32+ drives on modern Xeons). Arrays are created in UEFI BIOS Setup Utility under VROC/VMD menus. Linux mdadm can manage but not create VROC arrays—initial setup must be done in BIOS. Windows uses the Intel VROC GUI or CLI tools. Broadcom/LSI MegaRAID 9460-8i Now let's look at a fully hardware NVMe RAID controller—a PCI-Express x8 card supporting up to 8 drives with SAS/SATA ports.  We should note that while the 9460-8i is still supported it is considered legacy. The Broadcom MegaRAID 9600 series with PCIe 4.0 is the recommended choice for new high-performance NVMe deployments. Features of the NVMe MegaRAID 9460-8i controller: NVMe support is limited to drives connected through SAS-based U.2/U.3 backplanes or tri-mode expanders—not direct PCIe lanes like VROC. Presents RAID volumes to the OS as single logical devices (member drives are hidden). Typically configured once during initial server provisioning using the UEFI RAID BIOS, Broadcom MegaRAID Storage Manager (MSM), or storcli CLI. NVMe RAID Performance Metrics The use of NVMe (Non-Volatile Memory Express) technology is justified by the increased bandwidth provided by the standard PCIe interface. It leverages all the advantages of solid-state drives, since RAID arrays are increasingly built from SSDs. For example, the data transfer protocol operates similarly to high-performance processor architectures (parallel paths, low latency, etc.). NVMe supports up to 64,000 queues, each with a depth of 64,000 entries, whereas the outdated AHCI technology can only send 32 commands per queue. Previous-generation controllers’ drivers used long cycles with a 6-microsecond latency. NVMe uses short cycles with only 2.8 microseconds latency—a significant factor in performance improvement. The following metrics are commonly compared: IOPS (Input/Output Operations Per Second)—the number of input/output operations per second. Average and maximum latency—the host response time to operation requests. System throughput—the speed of sequential read/write. These metrics are “synthetic” because in real-world use, they rarely appear in pure form. However, they serve well for testing and comparing different controllers by running specialized programs. It is best to evaluate equipment built on similar technology since RAID 0 on SSDs is always faster than on HDDs, even without NVMe, due to hardware differences alone. Conclusion Choosing between software and hardware platforms usually boils down to some recommendations. For a RAID array made from two drives, the first option (software RAID) is sufficient. More complex systems should definitely be built on external controllers. For large arrays or mission-critical workloads, use dedicated hardware RAID or firmware-assisted RAID like Intel VROC for better performance and resilience. For new enterprise NVMe deployments, look into modern PCIe 4.0/5.0 hardware RAID controllers or direct CPU-attached solutions with VMD/VROC, avoiding older legacy cards unless required for compatibility.