Gcore named a Leader in the GigaOm Radar for AI Infrastructure!Get the report
  1. Home
  2. Blog
  3. Exploring the Benefits of Cloud Development

Exploring the Benefits of Cloud Development

  • October 31, 2023
  • 9 min read
Exploring the Benefits of Cloud Development

Cloud development allows you to write, debug, and run code directly in the cloud infrastructure, rather than working in the local environment and subsequently uploading to the cloud. This streamlines the development process, allowing you to deploy and update applications faster. This article explains what cloud development is, what tools can help you with it, and how you can use cloud development to develop and update your application to meet your customers’ needs.

What Is Cloud Development?

Cloud development is the practice of creating and managing applications that run on remote servers, allowing users to access them over the internet.

Every application is made up of different types of services, such as backend services, frontend services, and monitoring services. Normally, without cloud development, creating a new service or updating an existing service means writing and running your code in the local environment first. After ensuring your service works as expected, you then push your code to the cloud environment, and run it there. Finally, you publish your service and integrate it with the app. This process is time-consuming, and requires sufficiently powerful computing resources to run the service on the local machine.

This is when cloud development proves its value. With cloud development, you write your code directly in the cloud infrastructure. After you have finished writing your code, publishing your service takes just one click.

Diagram comparing the difference in steps between traditional development vs. cloud development

Useful Cloud Development Tools

To apply cloud development to your projects, several tools are required to build and manage the code efficiently:

  • Code editor to help you write code more efficiently
  • Version control tool to manage the code changes
  • Compiler/interpreter to run your code
  • Publisher to allow public use of your application

Let’s learn about each of the tools in more detail.

Code Editor

A code editor is a software tool that supports code highlighting, easy navigation within the codebase, test execution, and debugging capabilities. When you’re working on applications that are hosted in a cloud environment, it’s essential for your code editor to support remote access because the code you’re working on is stored on a remote cloud server.

Remote access support enables you to establish an SSH connection between your local code editor and the remote server. You can then use your code editor to create, view, and modify code files as if they were local.

Popular code editors—like Visual Studio Code and JetBrains IDE—have features that support remote development. For example, with Visual Studio Code, you can install Microsoft’s “Remote – SSH” extension to enable remote code access via SSH. Once the extension is installed, you can connect to the remote server by entering its IP address, username, and password, and work on your cloud-based projects just as easily as you would local ones.

Below is an example of using Visual Studio Code to access code via a remote machine.

Example of using Visual Studio Code to access code via a remote machine

Version Control

In software development, it’s common for many people to be working on the same code base. Having a version control tool allows you to review who made the changes, and when, to certain lines of code so that you can trace any problems back to their source. Having a version control tool also allows you to revert your code to the version you want in the instance that new code introduces bugs.

There are several version control tools out there, such as Git, SVN, and Mercurial; Git is currently the most popular. Git is an open-source version control system that allows you to manage the changes in the code. It is distributed software, meaning that you create a local copy of the Git repository on your local machine, and then create new branches, add files, commit, and merge locally. When your code is ready to ship, you then push your code to the Git repository on the server.

Compiler/Interpreter

After tools that help you to write and track changes in the code, the next most important tool required to run code in the cloud is a compiler or interpreter. You need either a compiler or an interpreter to translate your code into machine code, depending on the programming languages or the runtime you are working on. They allow the computer to understand and execute your instructions. Generally speaking, the compiler or interpreter helps to build your code into executable files. Let’s look at each in turn to understand their differences.

Compiler

Before a service actually runs, a compiler translates the high-level code that you have written into low-level code. For example, a Java compiler compiles source code to the bytecode first, then the Java Virtual Machine will interpret and convert the bytecode to a machine-code executable file. As a result, compilers require time to analyze the source code. However, they also show obvious syntax errors, so you don’t need to spend a lot of time debugging your service when it’s running.

The programming languages that use compilers to translate code are Java, C#, and Go.

Interpreter

Unlike a compiler, an interpreter only translates written code into machine code when the service runs. As a result, the interpreter does not take time to compile the code. Instead, the code is executed right away. However, an application using an interpreter is often slower than one using a compiler because the interpreter executes the code line by line.

The programming languages that use interpreters are Python, Javascript, and Ruby.

Publisher

To allow other users to access your service, you need a publisher tool. This manages the following key aspects of your service:

  • Configuring the network
  • Creating the domain name
  • Managing the scalability

Network Configuration

To allow users to access your service, the network configuration is crucial. The method for making your service available online varies based on your technology stack. For instance, if you use the Next.js framework to build your web application, you can choose Vercel to deploy your application code.

You can also customize the behavior of your application with network configuration. Here’s an example of how to use the vercel.json file to redirect requests from one path to another:

Plaintext
{ "redirects": [ { "source": "/book", "destination": "/api/book", "statusCode": 301 } ]}

Domain Setting

Every service requires a URL for applications to interact with it. However, using direct IP addresses as URLs can be complex and unwieldy, so it’s advisable to assign a domain name to your service, like www.servicedomain.com. Various platforms, such as GoDaddy or SquareSpace, offer domain registration services for this purpose.

Scalability

To allow your service to handle more requests from your users, you need to define a scalability mechanism for your services. This way, your service will automatically scale according to the workload. Scalability also keeps costs in check; you pay for what you use, rather than wasting money by allocating resources based on peak usage.

Below is an example definition file for applying autoscaling to your service, using Kubernetes HorizontalPodAutoscaler.

Plaintext
apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: app spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: appdeploy minReplicas: 1 maxReplicas: 10 targetCPUUtilizationPercentage: 70

How to Run Code In the Cloud

Now that you are familiar with the tools you need for cloud development, let’s learn about how to run code in the cloud. There are two ways to run code in the cloud: using virtual machines or using containers. We explain the difference in depth in our dedicated article, but let’s review their relevance to cloud development here.

Virtual Machines

A virtual machine (VM) is like a computer that runs within a computer. It mimics a standalone system, with its own virtual hardware and software. Since a VM is separate from its host computer, you can pick the VM operating system that suits your needs without affecting your host’s system. Plus, its isolation offers an extra layer of security: if one VM is compromised, the others remain unaffected.

Architecture of a VM, which includes a guest OS

While VMs offer versatility in terms of OS choices for cloud development, scaling applications on VMs tends to be more challenging and costly compared to using containers. This is because each VM runs a full operating system, leading to higher resource consumption and longer boot-up times. Containers, on the other hand, share the host OS and isolate only the application environment, making them more lightweight and quicker to scale up or down.

Containers

A container is a software unit that contains a set of software packages and other dependencies. Since it uses the host operating system’s kernel and hardware, it doesn’t possess its own dedicated resources as a virtual machine does. As a result, it’s more lightweight and takes less time to start up. For instance, an e-commerce application can have thousands of containers for its backend and frontend services. This allows the application to easily scale out when needed by increasing the number of containers for its services.

Architecture of a container, which is more lightweight than VM architecture due to the lack of guest OS

Using containers for cloud code enables efficient resource optimization and ease of scaling due to their lightweight nature. However, you have limited flexibility in choosing the operating system, as most containers are Linux-based.

Cloud Development Guide

We’ve addressed cloud development tools and ways to run code in the cloud. In this section, we offer a step-by-step guide to using cloud development for your project.

Check Computing Resources

Before anything else, you’ll need the correct computing resources to power your service. This includes deciding between virtual machines and containers. If your service tends to have a fixed number of user requests everyday, or it needs a specific operating system like Mac or Windows in order to run, go with virtual machines. If you expect your service to experience a wide range in the number of user requests and you want it to be scalable to optimize operational costs, go with containers.

After choosing between virtual machines and containers, you need to allocate computing resources for use. The important resources that you need to consider are CPUs, RAM, disk volumes, and GPUs. The specifications for these resources can vary significantly depending on the service you’re developing. For instance, if you’re building a monitoring service with a one-year data retention plan, you’ll need to allocate disk volumes of approximately 100GB to store all generated logs and metrics. If you’re building a service to apply deep learning models to large datasets, you’ll require not only a powerful CPU and ample RAM, but also a GPU.

Install Software Packages and Dependencies

After preparing the computing resources, you’ll next install the necessary software and dependencies. The installation process varies depending on whether you’re using virtual machines or containers.

As a best practice, you should set up the mechanism to install the required dependencies automatically upon initialization of the virtual machine or container. This ensures that your service has all the necessary dependencies to operate immediately upon deployment. Additionally, it facilitates easy redeployment to a different virtual machine or container, if necessary. For example, if you want to install software packages and dependencies for an Ubuntu virtual machine to host a Node.js service, you can configure cloud-init scripts for the deployed virtual machine as below:

Plaintext
#cloud-config...apt: sources: docker.list: source: deb [signed-by=$KEY_FILE] https://deb.nodesource.com/node_18.x $RELEASE main keyid: 9FD3B784BC1C6FC31A8A0A1C1655A0AB68576280package_update: truepackage_upgrade: truepackages: - apt-transport-https - ca-certificates - gnupg-agent - software-properties-common - gnupg - nodejspower_state: mode: reboot timeout: 30 condition: True

To set up a web service on containers using Node.js, you’ll need to install Node along with the required dependencies. Below is a Dockerfile example for doing so:

Plaintext
# Pull the Node.js image version 18 as a base imageFROM node:18# Set the service directoryWORKDIR /usr/src/appCOPY package*.json ./# Install service dependenciesRUN npm install

Write Code

When you’ve installed the necessary software packages and dependencies, you can begin the fun part: writing the code. You can use code editors that support remote access to write the code for your service directly in the cloud. Built-in debugging tools in these editors can help you to identify any issues during this period.

Below is an example of using IntelliJ to debug a Go service for managing the playlists.

Using IntelliJ to debug a Go service

Test Your Service

After you finish writing your code, it’s crucial to test your service. As a best practice, start with unit tests to ensure that individual components work, followed by integration tests to see how your service interacts with existing application services, and finally E2E (end-to-end) tests to assess the overall user experience and system behavior.

Below is a test pyramid that gives a structured overview of each test type’s coverage. This will help you allocate your testing efforts efficiently across unit and integration tests for your service.

Test pyramid demonstrates the proportion that should be allocated to each test

Configure Network Settings

To make your service available to users, you need to configure its network settings. This might involve configuring the rules for inbound and outbound data, creating a domain name for your service, or setting a static IP address for your service.

Here is an example of using cloud-init configuration to set a static IP for a virtual machine that hosts your service:

Plaintext
#cloud-config...write_files: - content: | network: version: 2 renderer: networkd ethernets: enp3s0: addresses: - 192.170.1.25/24 - 2020:1::1/64 nameservers: addresses: - 8.8.8.8 - 8.8.4.4 path: /etc/netplan/00-add-static-ip.yaml permissions: 0644power_state: mode: reboot timeout: 30 condition: True

Add Autoscaling Mechanism

With everything in place, it’s time to add an autoscaling mechanism. This adjusts resources based on demand, which will save costs during quiet times and boost performance during busy periods.

Assuming that you use Kubernetes to manage the containers of your service, the following is an example of using Gcore Managed Kubernetes to set the autoscaling mechanism for your Kubernetes cluster:

Configuring a Gcore Managed Kubernetes cluster to enable cluster autoscaling

Set Up Security Enhancement

Finally, ensure your service is secure. Enhancements can range from setting up robust authentication measures to using tools like API gateways to safeguard your service. You can even set up a mechanism to protect your service from malicious activities such as DDoS attacks.

Below is an example of how to apply security protection to your service by creating a resource for your service URL using Gcore Web Security:

Create a web security resource for the service domain to protect it from attacks

Gcore Cloud Development

Accelerating feature delivery through cloud development can offer a competitive edge. However, the initial setup of tools and environments can be daunting—and mistakes in this phase can undermine the benefits.

Here at Gcore, we recognize these obstacles and offer Gcore Function as a Service (FaaS) as a solution. Gcore FaaS eliminates the complexities of setup, allowing you to dive straight into coding without worrying about configuring code editors, compilers, debuggers, or deployment tools. Ideally suited for straightforward services that require seamless integration with existing applications, Gcore FaaS excels in the following use cases:

  • Real-time stream processing
  • Third-party service integration
  • Monitoring and analytics services

Conclusion

Cloud development allows you to deliver your service to users immediately after you’ve finished the coding and testing phases. You can resolve production issues and implement features faster to better satisfy your customers. However, setting up cloud infrastructure can be time intensive and ideally needs a team of experienced system administrators for building and maintenance.

With Gcore FaaS, you don’t have to take on that challenge yourself. You can focus on writing code, and we’ll handle the rest—from configuring pods and networking to implementing autoscaling. Plus, you are billed only for time your customers actually use your app, ensuring cost effective operation.

Want to try out Gcore FaaS to see how it works? Get started for free.

Related articles

How we engineered a single pipeline for LL-HLS and LL-DASH

Viewers in sports, gaming, and interactive events expect real-time, low-latency streaming experiences. To deliver this, the industry has rallied around two powerful protocols: Low-Latency HLS (LL-HLS) and Low-Latency DASH (LL-DASH).While they share a goal, their methods are fundamentally different. LL-HLS delivers video in a sequence of tiny, discrete files. LL-DASH delivers it as a continuous, chunked download of a larger file. This isn't just a minor difference in syntax; it implies completely different behaviors for the packager, the CDN, and the player.This duality presents a major architectural challenge: How do you build a single, efficient, and cost-effective pipeline that can serve both protocols simultaneously from one source?At Gcore, we took on this unification problem. The result is a robust, single-source pipeline that delivers streams with a glass-to-glass latency of approximately 2.0 seconds for LL-DASH and 3.0 seconds for LL-HLS. This is the story of how we designed it.Understanding the dualityTo build a unified system, we first had to deeply understand the differences in how each protocol operates at the delivery level.LL-DASH: the continuous feedMPEG-DASH has always been flexible, using a single manifest file to define media segments by their timing. Low-Latency DASH builds on this by using Chunked CMAF segments.Imagine a file that is still being written to on the server. Instead of waiting for the whole file to be finished, the player can request it, and the server can send it piece by piece using Chunked Transfer Encoding. The player receives a continuous stream of bytes and can start playback as soon as it has enough data.Single, long-lived files: A segment might be 2–6 seconds long, but it’s delivered as it’s being generated.Timing-based requests: The player knows when a segment should be available and requests it. The server uses chunked transfer to send what it has so far.Player-driven latency: The manifest contains a targetLatency attribute, giving the player a strong hint about how close to the live edge it should play.LL-HLS: the rapid-fire deliveryLL-HLS takes a different approach. It extends the traditional playlist-based HLS by breaking segments into even smaller chunks called Parts.Think of it like getting breaking news updates. The server pre-announces upcoming Parts in the manifest before they are fully available. The player then requests a Part, but the server holds that request open until the Part is ready to be delivered at full speed. This is called a Blocking Playlist Reload.Many tiny files (Parts): A 2-second segment might be broken into four 0.5-second Parts, each requested individually.Manifest-driven updates: The server constantly updates the manifest with new Parts, and uses special tags like #EXT-X-PART-INF and #EXT-X-SERVER-CONTROL to manage delivery.Server-enforced timing: The server controls when the player receives data by holding onto requests, which helps synchronize all viewers.A simplified diagram visually comparing the LL-HLS delivery of many small parts versus the LL-DASH chunked transfer of a single, larger segment over the same time period.These two philosophies demand different things from a CDN. LL-DASH requires the CDN to intelligently cache and serve partially complete files. LL-HLS requires the CDN to handle a massive volume of short, bursty requests and hold connections open for manifest updates. A traditional CDN is optimized for neither.Forging a unified strategyWith two different delivery models, where do you start? You find the one thing they both depend on: the keyframe.Playback can only start from a keyframe (or I-frame). Therefore, the placement of keyframes, which defines the Group of Pictures (GOP), is the foundational layer that both protocols must respect. By enforcing a consistent keyframe interval on the source stream, we could create a predictable media timeline. This timeline can then be described in two different “languages” in the manifests for LL-HLS and LL-DASH.A single timeline with consistent GOPs being packaged for both protocols.This realization led us to a baseline configuration, but each parameter involved a critical engineering trade-off:GOP: 1 second. We chose a frequent, 1-second GOP. The primary benefit is extremely fast stream acquisition; a player never has to wait more than a second for a keyframe to begin playback. The trade-off is a higher bitrate. A 1-second GOP can increase bitrate by 10–15% compared to a more standard 2-second GOP because you're storing more full-frame data. For real-time, interactive use cases, we prioritized startup speed over bitrate savings.Segment Size: 2 seconds. A 2-second segment duration provides a sweet spot. For LL-DASH and modern HLS players, it's short enough to keep manifest sizes manageable. For older, standard HLS clients, it prevents them from falling too far behind the live edge, keeping latency reduced even on legacy players.Part Size: 0.5 seconds. For LL-HLS, this means we deliver four updates per segment. This frequency is aggressive enough to achieve sub-3-second latency while being coarse enough to avoid overwhelming networks with excessive request overhead, which can happen with part durations in the 100–200ms range.Cascading challenges through the pipeline1. Ingest: predictability is paramountTo produce a clean, synchronized output, you need a clean, predictable input. We found that the encoder settings of the source stream are critical. An unstable source with a variable bitrate or erratic keyframe placement will wreck any attempt at low-latency delivery.For our users, we recommend settings that prioritize speed and predictability over compression efficiency:Rate control: Constant Bitrate (CBR)Keyframe interval: A fixed interval (e.g., every 30 frames for 30 FPS, to match our 1s GOP).Encoder tune: zerolatencyAdvanced options: Disable B-frames (bframes=0) and scene-cut detection (scenecut=0) to ensure keyframes are placed exactly where you command them to be.Here is an example ffmpeg command in Bash that encapsulates these principles:ffmpeg -re -i "source.mp4" -c:a aac -c:v libx264 \ -profile:v baseline -tune zerolatency -preset veryfast \ -x264opts "bframes=0:scenecut=0:keyint=30" \ -f flv "rtmp://your-ingest-url"2. Transcoding and packagingOur transcoding and Just-In-Time Packaging (JITP) layer is where the unification truly happens. This component does more than just convert codecs; it has to operate on a stream that is fundamentally incomplete.The primary challenge is that the packager must generate manifests and parts from media files that are still being written by the transcoder. This requires a tightly-coupled architecture where the packager can safely read from the transcoder's buffer.To handle the unpredictable nature of live sources, especially user-generated content via WebRTC, we use a hybrid workflow:GPU Workers (Nvidia/Intel): These handle the heavy lifting of decoding and encoding. Offloading to GPU hardware is crucial for minimizing processing latency and preserving advanced color formats like HDR+.Software Workers and Filters: These provide flexibility. When a live stream from a mobile device suddenly changes resolution or its framerate drops due to a poor connection, a rigid hardware pipeline would crash. Our software layer can handle these context changes gracefully, for instance, by scaling the erratic source and overlaying it on a stable, black-background canvas, meaning the output stream never stops.This makes our JITP a universal packager, creating three synchronized content types from a single, resilient source:LL-DASH (CMAF)LL-HLS (CMAF)Standard HLS (MPEG-TS) for backward compatibility3. CDN delivery: solving two problems at onceThis was the most intensive part of the engineering effort. Our CDN had to be taught how to excel at two completely different, high-performance tasks simultaneously.For LL-DASH, we developed a custom caching module we call chunked-proxy. When the first request for a new .m4s segment arrives, our edge server requests it from the origin. As bytes flow in from the origin, the chunked-proxy immediately forwards them to the client. When a second client requests the same file, our edge server serves all the bytes it has already cached and then appends the new bytes to both clients' streams simultaneously. It’s a multi-client cache for in-flight data.For LL-HLS, the challenges were different:Handling Blocked Requests: Our edge servers needed to be optimized to hold thousands of manifest requests open for hundreds of milliseconds without consuming excessive resources.Intelligent Caching: We needed to correctly handle cache statuses (MISS, EXPIRED) for manifests to ensure only one request goes to the origin per update, preventing a "thundering herd" problem.High Request Volume: LL-HLS generates a storm of requests for tiny part-files. Our infrastructure was scaled and optimized to serve these small files with minimal overhead.The payoff: ultimate flexibility for developersThis engineering effort wasn't just an academic exercise. It provides tangible benefits to developers building with our platform. The primary benefit is simplicity through unification, but the most powerful benefit is the ability to optimize for every platform.Consider the complex landscape of Apple devices. With our unified pipeline, you can create a player logic that does this:On iOS 17.1+: Use LL-DASH with the new Managed Media Source (MMS) API for ~2.0 second latency.On iOS 14.0 - 17.0: Use native LL-HLS for ~3.0 second latency.On older iOS versions: Automatically fall back to standard HLS with a reduced latency of ~9 seconds.This lets you provide the best possible experience on every device, all from a single backend and a single live source, without any extra configuration.Don't fly blind: observability in a low-latency worldA complex system is useless without visibility, and traditional metrics can be misleading for low-latency streaming. Simply looking at response_time from a CDN log is not enough.We had to rethink what to measure. For example:For an LL-HLS manifest, a high response_time (e.g., 500ms) is expected behavior, as it reflects the server correctly holding the request while waiting for the next part. A low response_time could actually indicate a problem. We monitor “Manifest Hold Time” to ensure this blocking mechanism is working as intended.For LL-DASH, a player requesting a chunk that isn't ready yet might receive a 404 Not Found error. While occasional 404s are normal, a spike can indicate origin-to-edge latency issues. This metric, combined with monitoring player liveCatchup behavior, gives a true picture of stream health.Gcore: one pipeline to serve them allThe paths of LL-HLS and LL-DASH may be different, but their destination is the same: real-time interaction with a global audience. By starting with a common foundation—the keyframe—and custom-engineering every component of our pipeline to handle this duality, we successfully solved the unification problem.The result is a single, robust system that gives developers the power of both protocols without the complexity of running two separate infrastructures. It’s how we deliver ±2.0s latency with LL-DASH and ±3.0s with LL-HLS, and it’s the foundation upon which we’ll build to push the boundaries of real-time streaming even further.

Gcore successfully stops 6 Tbps DDoS attack

Gcore recently detected and mitigated one of the most powerful distributed denial-of-service (DDoS) attacks of the year, peaking at 6 Tbps and 5.3 billion packets per second (Bpps).This surge, linked to the AISURU botnet, reflects a growing trend of large-scale attacks. It reminds us how crucial effective protection has become for companies that depend on high availability and low latency. 6 Tbps 5.3 BppsThe attack in numbersPeak traffic: 6 TbpsPacket rate: 5.3 BppsMain protocol: UDP, typical of volumetric floods designed to overwhelm bandwidthGeographic concentration: 51% of sources originated in Brazil and 23.7% in the US, together accounting for nearly 75% of all trafficGeographic sources This regional concentration shows how today’s botnets are expanding across areas with high device connectivity and weaker security measures, creating an ideal environment for mass exploitation.How to strengthen your defensesThe 6 Tbps attack is not an isolated incident. It marks an escalation in DDoS activity across industries where performance and availability are critical to customer satisfaction and company revenue. To protect your business from large-scale DDoS attacks, consider the following key strategies:Adopt an adaptive DDoS protection that detects and mitigates attacks automatically.Leverage edge infrastructure to absorb malicious traffic closer to its source.Prepare for high traffic volumes by upgrading your infrastructure or partnering with a reliable DDoS protection provider that has the global capacity and resources to keep your services online during large-scale attacks.Keeping your business safe with GcoreTo stay ahead of these evolving threats, companies need solutions that deliver real-time detection, intelligent mitigation, and global reach. Gcore’s DDoS Protection was built to do precisely that, leveraging AI-driven traffic analysis and worldwide network capacity to block attacks before they impact your users.As attacks grow larger and more complex, staying resilient means being prepared. With the right protection in place, your customers will never know an attack happened in the first place.Learn more about 2025 cyberattack trends

Gcore CDN updates: Dedicated IP and BYOIP now available

We’re pleased to announce two new premium features for Gcore CDN: Dedicated IP and Bring Your Own IP (BYOIP). These capabilities give customers more control over their CDN configuration, helping you meet strict security, compliance, and branding requirements.Many organizations, especially in finance and other regulated sectors, require full control over their network identity. With these new features, Gcore enables customers to use unique, dedicated IP addresses to meet compliance or security standards; retain ownership and visibility over IP reputation and routing, and deliver content globally while maintaining trusted, verifiable IP associations.Read on for more information about the benefits of both updates.Dedicated IP: exclusive addresses for your CDN resourcesThe Dedicated IP feature enables customers to assign a private IP address to their CDN configuration, rather than using shared ones. This is ideal for:Businesses that are subject to strict security or legal frameworks.Customers who want isolated IP resources to ensure consistent access and reputation.Teams using WAAP or other advanced security solutions where dedicated IPs simplify policy management.BYOIP: bring your own IP range to Gcore CDNWith Bring Your Own IP (BYOIP), customers can use their own public IP address range while leveraging the performance and global reach of Gcore CDN. This option is especially useful for:Resellers who prefer to keep Gcore infrastructure invisible to end clients.Enterprises maintaining brand consistency and control over IP reputation.How to get startedBoth features are currently available as paid add-ons and are configured manually by the Gcore team. To request activation or learn more, please contact Gcore Support or your account manager.We’re working on making these features easier to manage and automate in future releases. As always, we welcome your feedback on both the feature functionality and the request process—your insights help us improve the Gcore CDN experience for everyone.Get in touch for more information

Introducing AI Cloud Stack: turning GPU clusters into revenue-generating AI clouds

Enterprises and cloud providers face major roadblocks when trying to deploy GPU infrastructure at scale: long time-to-market, operational inefficiencies, and difficulty bringing new capacity to market profitably. Establishing AI environments with hyperscaler-grade functionality typically requires years of engineering effort, multiple partner integrations, and complex operational tooling.Not anymore.With Gcore AI Cloud Stack, organizations can transform bare Nvidia GPU clusters into a fully cloud-enabled environment—complete with orchestration, observability, billing, and go-to-market support—all in a fraction of the time it would take to build from scratch, maximizing GPU utilization.This proven solution marks the latest addition to the Gcore AI product suite, enabling enterprises and cloud providers to accelerate AI cloud deployment through better GPU utilization, monetization, reduced complexity, and hyperscaler-grade functionality in their own AI environments. Gcore AI Cloud Stack is already powering leading technology providers, including VAST and Nokia.Why we built AI Cloud StackBuying and efficiently operating GPUs at a large scale requires significant investment, time, and expertise. Most organizations need to hit the ground running, bypassing years of in-house R&D. Without a robust reference architecture, infrastructure and network preparation, 24/7 monitoring, dynamic resource allocation, orchestration abstraction, and clear paths to utilization or commercialization, enterprises can spend years before seeing ROI.“Gcore brings together the key pieces—compute, networking, and storage—into a usable stack. That integration helps service providers stand up AI clouds faster and onboard clients sooner, accelerating time to revenue. Combined with the advanced multi-tenant capabilities of VAST’s AI Operating System, it delivers a reliable, scalable, and futureproof AI infrastructure. Gcore offers operators a valuable option to move quickly without building everything themselves.”— Dan Chester, CSP Director EMEA, VAST DataAt Gcore, we understand that organizations across industries will continue to invest heavily in GPUs to power the next wave of AI innovation—meaning these challenges aren’t going away. AI Cloud Stack solves today’s challenges and anticipates tomorrow’s. It ensures that GPU infrastructure at the core of AI innovation delivers maximum value to enterprises.How AI Cloud Stack worksThis comprehensive solution is structured across three stages.1. Provision and launchGcore handles the complexities of initial deployment, from physical infrastructure setup to orchestration, enabling enterprises to go live quickly with a reliable GPU cloud.2. Operations and managementThe solution includes monitoring, orchestration, ticket management, and ongoing support to keep environments stable, secure, and efficient. This includes automated GPU failure handling and optimized resource management.3. Go-to-market supportUnlike other solutions, AI Cloud Stack goes beyond infrastructure. Building on Gcore’s experience as a trusted NVIDIA Cloud Provider (NCP), it helps customers sell their capacity, including through established reseller channels. This integrated GTM support ensures capacity doesn’t sit idle, losing value and potential.What sets Gcore apartUnlike many providers entering this market, Gcore has operated as a global cloud provider for over a decade and has been an early player in the global AI landscape. Gcore knows what it takes to build, scale, and sell cloud and AI services—because it has done it for customers and partners worldwide. Gcore AI Cloud Stack has already been deployed on thousands of NVIDIA Hopper GPUs across Europe to build a commercial-grade AI cloud with full orchestration, abstraction, and monetization layers. That real-world experience allows Gcore to deliver the infrastructure, operational playbook, and sales enablement customers need to succeed.“We’re pleased to collaborate with Gcore, a strong European ISV, to advance a networking reference architecture for AI clouds. Combining Nokia’s open, programmable, and reliable networking with Gcore’s cloud software accelerates deployable blueprints that customers can adopt across data centers and the edge.”— Mark Vanderhaegen, Head of Business Development, Data Center Networks, NokiaKey features of AI Cloud StackCloudification of GPU clusters: Transform raw infrastructure into cloud-like consumption: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), GPU as a Service (GPUaaS), or Model as a Service (MaaS).Gcore AI suite integration: Enable serverless inference and training capabilities through Gcore’s enterprise AI suite.Hyperscaler functionality: Built-in billing, observability, orchestration, and professional services deliver the tools CSPs and enterprises need to operate—similar to what they’re used to getting on public cloud.White-label options: Deliver capacity under your own brand while relying on Gcore’s proven global cloud backbone.NVIDIA AI Enterprise-ready: Integrate pretrained models, chatbots, and NVIDIA AI blueprints to accelerate time-to-market.The future of AI cloudsWith Gcore AI Cloud Stack, enterprises no longer need to spend years building the operational, technical, and commercial capabilities required to utilize and monetize GPU infrastructure. Instead, they can launch in a few months with a hyperscaler-grade solution designed for today’s AI demands.Whether you’re a cloud service provider, an enterprise investing in AI infrastructure, or a partner looking to accelerate GPU monetization, AI Cloud Stack gives you the speed, scalability, and GTM support you need.Ready to turn your GPU clusters into a fully monetized, production-grade AI cloud? Talk with our AI experts to learn how you can go from bare metal to model-as-a-service in months, not years.Get a customized consultation

Gcore Radar Q1–Q2 2025: three insights into evolving attack trends

Cyberattacks are becoming more frequent, larger in scale, and more sophisticated in execution. For businesses across industries, this means protecting digital resources is more important than ever. Staying ahead of attackers requires not only robust defense solutions but also a clear understanding of how attack patterns are changing.The latest edition of the Gcore Radar report, covering the first half of 2025, highlights important shifts in attack volumes, industry targets, and attacker strategies. Together, these findings show how the DDoS landscape is evolving, and why adaptive defense has never been more important.Here are three key insights from the report, which you can download in full here.#1. DDoS attack volumes continue to riseIn Q1–Q2 2025, the total number of DDoS attacks grew by 21% compared to H2 2024 and 41% year-on-year.The largest single attack peaked at 2.2 Tbps, surpassing the previous record of 2 Tbps in late 2024.The growth is driven by several factors, including the increasing availability of DDoS-for-hire services, the rise of insecure IoT devices feeding into botnets, and heightened geopolitical and economic tensions worldwide. Together, these factors make attacks not only more common but also harder to mitigate.#2. Technology overtakes gaming as the top targetThe distribution of attacks by industry has shifted significantly. Technology now represents 30% of all attacks, overtaking gaming, which dropped from 34% in H2 2024 to 19% in H1 2025. Financial services remain a prime target, accounting for 21% of attacks.This trend reflects attackers’ growing focus on industries with broader downstream impact. Hosting providers, SaaS platforms, and payment systems are attractive targets because a single disruption can affect entire ecosystems of dependent businesses.#3. Attacks are getting smarter and more complexAttackers are increasingly blending high-volume assaults with application-layer exploits aimed at web apps and APIs. These multi-layered tactics target customer-facing systems such as inventory platforms, payment flows, and authentication processes.At the same time, attack durations are shifting. While maximum duration has shortened from five hours to three, mid-range attacks lasting 10–30 minutes have nearly quadrupled. This suggests attackers are testing new strategies designed to bypass automated defenses and maximize disruption.How Gcore helps businesses stay protectedAs attack methods evolve, businesses need equally advanced protection. Gcore DDoS Protection offers over 200 Tbps filtering capacity across 210+ points of presence worldwide, neutralizing threats in real time. Integrated Web Application and API Protection (WAAP) extends defense beyond network perimeters, protecting against sophisticated application-layer and business-logic attacks. To explore the report’s full findings, download the complete Gcore Radar report here.Download Gcore Radar Q1-Q2 2025

Edge AI is your next competitive advantage: highlights from Seva Vayner’s webinar

Edge AI isn’t just a technical milestone. It’s a strategic lever for businesses aiming to gain a competitive advantage with AI.As AI deployments grow more complex and more global, central cloud infrastructure is hitting real-world limits: compliance barriers, latency bottlenecks, and runaway operational costs. The question for businesses isn’t whether they’ll adopt edge AI, but how soon.In a recent webinar with Mobile World Live, Seva Vayner, Gcore’s Product Director of Edge Cloud and AI, made the business case for edge inference as a competitive differentiator. He outlined what it takes to stay ahead in a world where speed, locality, and control define AI success.Scroll on to watch Seva explain why your infrastructure choices now shape your market position later.Location is everything: edge over cloudAI is no longer something globally operating businesses can afford to run from a central location. Regional regulations and growing user expectations mean models must be served as close to the user as possible. This reduces latency, but perhaps more importantly is essential for compliance with local laws.Edge AI also keeps costs down by avoiding costly international traffic routes. When your users are global but your infrastructure isn’t, every request becomes an expensive, high-latency journey across the internet.Edge inference solves three problems at once in an increasingly regionally fragmented AI landscape:Keeps compute near users for low latencyCuts down on international transit for reduced costsHelps companies stay compliant with local lawsPrivate edge: control over convenienceMany businesses started their AI journey by experimenting with public APIs like OpenAI’s. But as companies and their AI use cases mature, that’s not good enough anymore. They need full control over data residency, model access, and deployment architecture, especially in regulated industries or high-sensitivity environments.That’s where private edge deployments come in. Instead of relying on public endpoints and shared infrastructure, organizations can fully isolate their AI environments, keeping data secure and models proprietary.This approach is ideal for healthcare, finance, government, and any sector where data sovereignty and operational security are critical.Optimizing edge AI: precision over powerDeploying AI at the edge requires right-sizing your infrastructure for the models and tasks at hand. That’s both technically smarter and far more cost-effective than throwing maximum power and size at every use case.Making smart trade-offs allows businesses to scale edge AI sustainably by using the right hardware for each use case.AI at the edge helps businesses deliver the experience without the excess. With the control that the edge brings, hardware costs can be cut by using exactly what each device or location requires, reducing financial waste.Final takeawayAs Seva put it, AI infrastructure decisions are no longer just financial; they’re part of serious business strategy. From regulatory compliance to operational cost to long-term scalability, edge inference is already a necessity for businesses that plan to serve AI at scale and get ahead in the market.Gcore offers a full suite of public and private edge deployment options across six continents, integrated with local telco infrastructure and optimized for real-time performance. Learn more about Everywhere Inference, our edge AI solution, or get in touch to see how we can help tailor a deployment model to your needs.Ready to get started? Deploy a model in just three clicks with Gcore Everywhere Inference.Discover Everywhere Inference

Subscribe to our newsletter

Get the latest industry trends, exclusive insights, and Gcore updates delivered straight to your inbox.