Before moving to code-first frameworks, many developers have lived the same frustration: you write a feature that needs a database or a queue, then your pull request stalls until the platform team can manually provision it. I’ve felt that pain both as a backend engineer and as a mentor in the Refonte Learning Cloud Development program. This 3-month, part-time course covers “Building and Deploying Applications” and “Infrastructure as Code” to prepare developers for exactly this crossroads. In it, we see that “infrastructure from code” tools (like Encore, SST, Winglang) let you embed resource declarations (databases, pub/sub topics, storage, cron jobs, etc.) right in your application code instead of separate Terraform files. The result: developers no longer need to wait on tickets or handoffs to spin up common resources. This article explains exactly what “infrastructure from code” means, compares the leading frameworks, and shows why this shift matters (and when it doesn’t).
Refonte Learning’s own Cloud Development Program page highlights hands-on use of AWS/Azure/GCP and Terraform, and includes topics like deploying cloud apps and IaC. That foundation is essential. But it doesn’t yet prescribe which pattern you choose: separate IaC files or code-embedded infrastructure. Let’s examine the new “from code” pattern in detail. We’ll also touch on how AI coding agents (Encore’s Leap, etc.) are starting to use these frameworks to deploy real infrastructure.
The Handoff That Blocks Every Feature
Stalled development: In the old model, every new database, queue, or bucket required an infrastructure pull request (for example, Terraform) and often manual review. Teams report features sitting idle for days while platform engineers merge IaC changes.
Slow feedback loop: This “DevOps handoff” meant developers had no control over the deployment timeline. A small schema change could take a week to appear in a test environment, slowing down validation and integration.
Context switching: Developers waste time tracking the status of tickets or chasing down ops teams, pulling them away from coding. It also requires jumping out of your code context to write YAML or HCL, which breaks flow.
Shifting work: In contrast, the new frameworks let developers declare and iterate on infrastructure alongside application code, removing that bottleneck. (For example, our Pulumi vs. Terraform: A Migration Guide covers the traditional separate-IaC approach, which is what we’re moving beyond here.)
What "Infrastructure From Code" Actually Means
“Infrastructure from code” (sometimes called Infrastructure-from-Code, IfC) is a newer approach where cloud resources are specified directly in your application code or a single config file, rather than in separate Terraform/CloudFormation repositories. In practical terms:
Code-embedded resources: Developers use the same programming language they’re writing their app in (e.g. Go, TypeScript, or a new language) to declare what infrastructure they need. For example, Encore’s documentation says you can “declare the resources your app needs, from databases and pub/sub caches to API gateways and cron jobs, directly in your code”. In SST, “your entire app is defined in code, in a single sst.config.ts file. This includes databases, buckets, queues… or any one of 150+ providers”.
Automated provisioning: When you run the app or push changes, the framework automatically provisions or updates the cloud resources. Encore’s workflow is literally “infrastructure from development to production”; it replaces Terraform PRs and DevOps handoffs with an automated pipeline. In Encore, running encore run spins up a local Postgres, Pub/Sub emulator, etc., so you can test with real services. In production, the platform provisions them in your AWS/GCP account. SST’s new “Ion” engine compiles the TypeScript and uses Pulumi/Terraform under the hood to deploy resources across AWS, Cloudflare, etc.
Preview environments: A key feature in these frameworks is one-click preview or branch environments. For each git branch or PR, the platform automatically creates an isolated environment with copies of your services. For example, Encore’s docs outline a three-step development workflow: (1) Local development with real infra on your machine; (2) “per-PR preview” environments in the cloud (optionally with a branched database snapshot); (3) Production on merge. This means each change can be validated end-to-end immediately, without manual setup.
Why it’s different: Unlike traditional IaC, you’re not writing YAML or HCL templates. Instead, the application code itself generates the infra. This closes the gap between app logic and the resources it needs, making rapid iteration possible. (See our Pulumi vs. Terraform: A Migration Guide for more on the old IaC approach.) Even Gartner and analysts now recognize IfC as a distinct category.
How This Differs From Traditional IaC
Scope of work: Traditional IaC tools (Terraform, CloudFormation, Pulumi in standalone mode) treat infrastructure and app code separately. You often have separate repos or files of resources that an infrastructure team maintains. With code-first frameworks, the same team writing the application code is also declaring its infra.
Language and process: With Terraform you write HCL and apply on CLI; with Encore/SST/Winglang you write in Go/TS/Wing and run a dev command. The dev productivity loop is tighter.
Collaboration model: Infrastructure changes become part of the app’s pull requests and code reviews rather than a separate pipeline. This can break down silos but also requires new guardrails (policy-as-code, etc.) to replace the old ops approvals.
Dependency handling: In IaC you typically plan/apply and maybe preview, but testing changes requires separate environments. Code-first frameworks build preview environments by default, including data (e.g. Encore uses Neon DB branching).
Encore: Declaring Infrastructure Inside Go or TypeScript
Encore is an open-source framework (Go and TypeScript SDKs) designed to put backend infrastructure right in app code. Key points:
Language-first SDK: Encore provides libraries for Go or TS. In your service code you simply reference resources like databases, Pub/Sub topics, storage buckets, APIs, etc., as variables or annotations. For example, you might write db := encore.Postgres("db") to declare a database. When you run or deploy, Encore notices these declarations and provisions real cloud resources (Postgres on AWS/GCP, Pub/Sub, etc.).
Local dev with real services: Encore’s dev command (encore run) spins up the entire system on your machine with real services, including a local Postgres instance, pub/sub emulation, etc. This means you test your code against real integrations, not mocks. In Encore’s words, engineers can “build production systems without waiting on infrastructure”.
Preview environments: Encore automatically creates full-stack preview environments for each git branch or PR. These are ephemeral deployments in the cloud that mirror your services. Optionally, Encore can even branch your production database (using Neon DB’s instant branching) so each preview has realistic data. Preview databases even “scale to zero” when idle, saving costs.
Deploying to your cloud: By default, Encore deploys into your own AWS or GCP account (not a hosted PaaS). The platform auto-generates the necessary Terraform (IAM roles, resource configs, etc.) but keeps control in your cloud. As Encore’s co-founder explains, the team’s goal was that “devs can define infrastructure directly in Go or TypeScript, and the platform turns that into real cloud resources deployed to their own AWS or GCP accounts”. This means no extra training or abstract “stack”: it’s real-world infrastructure from day one.
Developer experience: Encore offers things like live code updates, built-in tracing, and API docs. (It also claims “2-3x faster development speed” and “90% shorter time to market,” but note these are marketing claims on its site, not independent benchmarks.)
SST: One Config File for the Whole Stack
SST (Serverless Stack Toolkit) is a TypeScript framework for full-stack apps that also embraces a code-first infra model. In SST:
Single config file: You define your entire app in sst.config.ts. This TypeScript file can declare everything: frontends, backends, databases, queues, buckets, cron jobs, and more. The documentation says “What makes SST different is that your entire app is defined in code, in a single sst.config.ts file”. For example, you can add a new sst.aws.Nextjs("MyWeb", { domain: "..." }) line for a Next.js site, or new sst.aws.Postgres("MyDatabase", { vpc }) for a managed database.
150+ built-in constructs: SST’s config API includes high-level classes for common resources: containers, functions, Postgres, buckets, cron schedules, etc. It supports over 150 providers, not just AWS. The community provides constructs for Cloudflare D1, Firebase, and many more, all usable in that one config.
SST Ion engine: Under the hood, SST v3 uses the new Ion deployment engine (launched May 2026). Ion replaces SST v2’s CDK+CloudFormation with a Pulumi+Terraform backend. In practice, this means an sst deploy command now drives Pulumi operations, allowing multi-cloud support (AWS, Cloudflare, Vercel, Stripe, and other services). SST Ion is open-source (MIT) and is now the default for new projects, giving better deploy speed and multi-cloud flexibility.
Deployment and preview: Like Encore, SST projects can be deployed either via sst deploy to your AWS account, or through SST’s Console (a hosted service) that can manage previews. SST’s pipeline can push frontends to Vercel/Cloudflare and backend infra to AWS in one go.
Example features: In sst.config.ts, you might see:
Front-end: e.g. new sst.aws.Nextjs("Web", { path: "frontend" }) to deploy a Next.js app.
Backend: e.g. new sst.aws.Service("MyService", { cluster, loadBalancer: { ports: [...] } }) or new sst.aws.Function("MyFunction", { handler: "src/handler" }).
Database: new sst.aws.Postgres("MyDatabase", { vpc }) for a managed Postgres instance.
Storage/Cron: new sst.aws.Bucket("MyBucket") for S3, and new sst.aws.Cron("MyCron", { schedule: "rate(5 minutes)", function: myFunc }) for periodic jobs.
All these live side-by-side in code.
What sst.config.ts Actually Defines
The sst.config.ts can include:
Front-end apps: Next.js, Remix, Astro, Svelte, Solid, etc. (each has a construct in SST).
Backend compute: Containers (ECS/EKS) via Service, or Lambda functions via Function constructs.
Databases: Managed Postgres or Redis instances that are automatically wired into your VPC if needed.
Storage and queues: S3 buckets, DynamoDB, or pub/sub topics, via Bucket, Queue, etc. constructs (shown in SST docs).
Scheduled jobs: Cron tasks as first-class resources (e.g. a Cron construct that ties a schedule to a function).
Each declaration in code maps to the necessary underlying cloud resources (via Ion/Pulumi). In effect, SST lets you move most service-level infra into code: everything from your API gateways to database servers can be declared inline.
Winglang and the Smaller Players
Other frameworks in this space include new languages and niche tools:
Winglang (Wing): A new cloud-oriented language (open source, ~5.4k stars on GitHub as of mid-2026). Winglang is designed from scratch to merge infra and app logic. In Wing, you write code like let queue = new cloud.Queue(); let bucket = new cloud.Bucket(); and the compiler generates a cloud-ready deployment. Wing provides a local simulator for full-stack testing, and when compiled it emits Terraform files and code bundles for AWS/Azure/etc.. For example, a Wing app pre-defines resources (queue, bucket, counter) which at compile-time generate a Terraform config and at runtime handle the message logic, all with built-in scaling and security for AWS Lambda/S3/SQS behind the scenes. It’s cloud-agnostic by design. Winglang is a younger ecosystem but an interesting entrant in “infra from code.”
Nitric: An open-source cloud framework (multi-language) focusing on ease-of-use. Nitric lets you write code that implicitly includes APIs, WebSockets, Pub/Sub, etc. It’s a language SDK approach and is mentioned as a platform-independent tool in industry surveys. Adoption and activity are smaller.
Klotho: Another open-source tool (initially from IBM and others) that uses code annotations to auto-generate cloud infrastructure. For instance, you add custom // @klotho:: comments in your code and Klotho compiles them to Terraform/Pulumi. It’s often cited alongside IfC tools like Encore and Nitric. Like Nitric, it’s more niche.
These “also-rans” are worth knowing, but the main market momentum in 2026 is behind Encore and SST (and to a lesser degree Winglang) due to their active development and backing.
Preview Environments as a Built-In Feature
A big perk of code-first frameworks is automated previews. Instead of manually wiring up a staging environment, branches or pull requests spin up their own sandbox:
One-click previews: In Encore and SST, pushing a new branch to Git (or opening a PR) triggers a fresh deployment of your whole app. That means a new set of running services, databases, and frontends, all isolated from prod. (Encore calls these Preview Environments, and SST’s Console has a similar feature.)
Integrated data: For truly end-to-end testing, these previews include real or realistic data. Encore’s system uses Neon’s branching feature: it instantly clones your database state for the preview, so the app has real data to work with. This lets you test migrations or data fixes in a safe copy of your database (the Neon branch “scales to zero” when idle for cost savings).
Consistent infrastructure: Because infra is declared in code, each preview is fully production-grade. For example, a preview deployed via Encore Cloud uses the same resource definitions (security settings, VPCs, etc.) as prod, so you catch issues early.
Rapid iteration: This model dramatically shortens feedback loops. If a bug appears in a preview, you can fix code (including infra config) and see results in a redeploy that takes minutes, all as part of your normal development workflow.
In short, preview environments become an automatic part of every feature branch, powered by the same code-based declarations that govern production. This means changes introduced by AI or humans can be validated in a realistic full-stack context before merging.
Where AI Coding Agents Fit Into This Pattern
AI-driven development tools (like GitHub Copilot, Amazon CodeWhisperer, or custom “dev agents” on platforms) benefit from and align with the “infra from code” model. Specifically:
Agents producing full-stack code: Tools like Encore’s new Leap agent (released May 2025) actually generate entire applications, including the backend code, APIs, and database schemas. Crucially, they also generate the infrastructure definitions using the same framework. For example, Leap builds an app using Encore.ts (Encore’s TS SDK) and produces code that declares all needed resources (microservices, databases, pub/sub, storage).
Deployable output: Because Leap (and similar tools) builds on Encore’s model, the generated output isn’t locked in a toy environment. Encore emphasizes that “Leap builds apps, Encore Cloud deploys them,” meaning the AI-generated app can be deployed to your AWS/GCP infrastructure with no rewriting. The output includes a Git diff of new code (and Encore’s declarative infra code), which the platform then provisions.
Not a sandbox: Unlike consumer AI site builders, these coding agents target real production workflows from the start. Encore and others designed Leap so its output goes through the same preview and deploy pipeline as hand-written code. In other words, an AI agent can check in a pull request that contains new Encore/SST code, and the code-first framework will automatically provision the infrastructure for that change.
Workflow integration: Agents can leverage the built-in developer tools. For example, Leap includes a two-way GitHub sync and preview environment, so code generated by the agent still goes through code review and testing as usual. The infrastructure generation is embedded in the agent’s output, not a separate script.
In summary, “infrastructure from code” frameworks become the execution model for AI agents that build cloud apps. Instead of an agent outputting a Terraform snippet, it outputs high-level Encore or SST code that the framework fully interprets into resources. This ensures AI-driven development remains grounded in real infra.
How Leap Deploys Real Infrastructure, Not a Sandbox
Encore’s Leap is a good example of this synergy. Encore describes Leap as “built for developers and designed for real production workflows”. Key points:
Encore.ts + Agent: Leap uses Encore.ts to scaffold apps. As Encore’s blog notes, apps built by Leap use Encore.ts (which has “a declarative infrastructure layer… which Leap uses to set up microservices, databases, pub/sub, storage buckets, and more”).
Encore Cloud: When you accept Leap’s output, deploying it uses Encore Cloud into your own AWS/GCP account. Encore explicitly contrasts this with BaaS platforms: “Applications generated by Leap aren’t confined to a proprietary PaaS… they’re built to deploy through Encore Cloud into real cloud infrastructure”.
No rewrite needed: The path from agent to prod is seamless. You iterate on the code in a branch (with Encore’s preview tools), and then when ready you select the infrastructure components and deploy. Encore promises “no structural rewrite required to graduate from demo to production” – the agent’s code is already in the right format.
Agent’s mindset: In practice, this means Leap (or another coding agent) generates the Encore code as if a human had written it. The same unit tests, migrations, and deployment commands apply. That’s why Encore positioned Leap as something for developers (with schema design, docs, testing) rather than a locked-down no-code builder.
The bottom line: infrastructure-from-code frameworks like Encore provide the lingua franca between AI agents and the actual cloud. They ensure AI-generated changes can be validated and deployed on real infrastructure, not just a sandbox.
What This Means for Platform Teams
For centralized platform/DevOps teams, code-first frameworks shift responsibilities and workflows:
Less blocking: The day-to-day ticketing of provisioning requests can drop. Developers become empowered to request resources by code, so platform teams move from “create this bucket for me” to “we help set guardrails and automation.”
New focus: Platform engineering may focus more on building common libraries, policies, and CI/CD pipelines for these frameworks. For example, maintaining the Encore Cloud backend, or shared SST components, rather than hand-editing Terraform templates for each team.
Policy as Code: To retain control, teams must codify security/policy checks in the framework. This might mean adding CDK or Terratest rules, or using tools that scan the generated infra. Essentially, the platform’s guardrails must be written into the code review and CI process, since the infra is now in the app repo.
Gradual rollout: In practice, many organizations start by letting teams opt into the new frameworks for new services, while keeping core infra (network, etc.) under old processes. Platform teams will often integrate the code-first tools with existing pipelines (e.g. running sst deploy or encore deploy inside GitHub Actions) rather than drop all IaC tools at once.
Overall, platform engineers transition from manually managing resources to supporting and auditing a more developer-driven model. They still own identity, cross-account roles, shared networking, and the underlying cloud environment, but they can treat these as platforms that developers write into, rather than per-request tickets.
When Infrastructure From Code Isn't the Right Choice
This pattern is powerful, but it has limits. Scenarios where you might stick with traditional IaC or a hybrid approach include:
Low-level or niche resources: If your application needs highly specialized infra not supported by these frameworks (e.g. certain telecom services, ML infrastructure, proprietary databases), you may still use Terraform/CloudFormation for those parts.
Existing IaC-heavy stack: For a large legacy system already in Terraform, fully ripping it out may be too costly. Many teams adopt code-first only for new microservices while maintaining core infra separately.
Strict compliance/audit needs: In some industries, every infrastructure change must pass stringent audits. Having all infra changes in code helps auditability, but you may need careful segregation or additional tools. If manual review of every cloud artifact is required, the speed gains may be offset by extra verification steps.
Team readiness: If the dev team isn’t comfortable with Go/TypeScript or new tools, a sudden switch could cause confusion. Training may be needed. In those cases, it may be prudent to learn the new framework on a proof-of-concept project first.
In short, if a project already has a heavy investment in IaC pipelines, or demands resources beyond the framework’s coverage, it’s fine to use a mix: keep stable components in Terraform and new services in code. The point is choosing the right tool for the job, not dogmatically replacing everything at once.
Migrating an Existing App to This Pattern
If you have an existing application with Terraform or Pulumi configs, a pragmatic migration is usually incremental:
Choose a low-risk service: Start by writing a new service (microservice, function, or feature) using the code-first framework. Let it coexist with the old stack. For example, create a new Encore or SST service and deploy it alongside the legacy app.
Use both models side-by-side: You can even have Terraform manage the network/VPC and have the code-first framework import or reference existing resources. Encore, for instance, can integrate external resources via providers if needed. This lets you gradually shift responsibilities.
Test and migrate data: When moving a database or queue from Terraform into code, deploy the new version in parallel (possibly pointed at a copy of the data) before cutting over. Tools like Neon DB branching (mentioned earlier) or database migration services help here.
Clean up after: Once a service is proven on the code-first model, you can decommission the Terraform-managed counterpart. Update IAM policies or VPC routes only when safe.
What to Keep in Terraform vs. What to Move
As a rule of thumb, keep stable, cluster-level or shared infrastructure in Terraform, and move service-specific resources into code. For example:
Terraform (Keep) | Infrastructure-from-Code (Move) |
Networking and core infra (VPCs, subnets, firewalls) | Databases and caches declared per service |
Cross-service IAM roles and policies | Service-specific roles (the framework usually creates least-privilege roles automatically) |
Kubernetes/ECS cluster provisioning (if used) | Individual microservices or Lambda functions |
Legacy monolith or non-managed services | New APIs, containers, queues, cron jobs, bucket definitions |
Anything not (yet) supported by the new framework | Everything the framework does support (CDK constructs like Postgres, Bucket, Queue, Cron, etc.) |
Encore’s documentation explicitly suggests this hybrid approach: use Terraform or your cloud console “as normal” for parts of the stack, and let Encore manage the resources you move into code. You don’t have to rewrite everything; you can incrementally migrate services while leaving core infrastructure under Terraform.
Common Mistakes Teams Make Adopting These Frameworks
Blindly trusting marketing claims: Vendors often tout huge productivity gains. For instance, Encore’s website claims “2-3x faster development” and “90% shorter time to market”. These are marketing figures and not independently validated. Treat such claims skeptically. Measure your own cycle times before and after adoption.
Ignoring security and configuration issues: Remember that embedding infra in code still requires best practices. Don’t forget to manage secrets properly or write IAM least-privilege policies. Just because the framework can create a DB, you still need to secure it. Always review the generated IAM roles and network settings.
Over-migrating: Trying to shove every single resource into code at once can backfire. It’s often wiser to start small. If you attempt a big-bang migration of a huge Terraform codebase, you may encounter unexpected drift or edge cases.
Neglecting testing: Just like code, infra definitions should be tested. Don’t skip integration tests or schema validation. The point of preview environments is to catch issues early, so use them.
Treating the frameworks as PaaS lock-in: While Encore/SST claim to deploy in your own cloud, there is some learning curve and reliance on the framework’s CLI/SDK. Don’t lose your ability to inspect or export the underlying Terraform/Pulumi if needed.
Treating Vendor Speed Claims as Verified Benchmarks
A specific pitfall is believing promotional metrics. Encore’s marketing claims (e.g. “2-3x faster development speed, 90% shorter time to market”) should be read with caution. These numbers are based on their own internal measurements and assume a certain kind of workflow and team. In practice, your mileage may vary. It’s good to treat them as goals, not guarantees, and to log your own performance improvements once you start using the framework.
How This Fits Alongside Database Branching for AI Agents
It’s worth noting that this infrastructure-from-code approach complements other modern practices like database branching. (If you’re curious about the recent Databricks acquisition of Neon and how it enables AI agents to provision databases, see our related article “Databricks’ Neon Acquisition and Serverless Postgres”.) In brief, the same preview environments we discussed use Neon branches to give each code change a realistic database state. In combination with frameworks like Encore and SST, this means AI-generated or developer-written changes can be validated against production-like data and infrastructure before going live. The overall workflow becomes: code changes (human or AI) → a preview environment with a cloned database → tests pass → merge and deploy real infrastructure. The result is a tight feedback loop powered by both database branching and code-embedded infra.
Cloud Developer Skills and Salaries in 2026
Looking at the job market and required skills, becoming a cloud developer in 2026 means a mix of traditional and new proficiencies:
Programming and cloud fundamentals: You still need strong coding skills (e.g. Go, TypeScript, Python) and an understanding of AWS/GCP/Azure services. Knowledge of containers, Kubernetes, and continuous delivery are essential.
Infrastructure knowledge: Beyond coding, you must grasp cloud networking, security best practices, and often have to write or review infrastructure code (whether Terraform or the new frameworks). Skills in DevOps practices (CI/CD, monitoring) are key.
Emerging tools: Familiarity with code-first infra frameworks (like Encore, SST, or even AWS CDK) is becoming a plus. So is understanding of AI-assisted development, for example, knowing how to integrate Copilot/Leap outputs and run CI on them. Our WebAssembly on the Server article covers some related skills (server-side Wasm, event-driven design, etc.) that are also relevant to modern cloud dev roles.
Soft skills: The ability to collaborate with platform teams and manage cross-functional workflows is increasingly important. You need to explain infrastructure changes in code reviews and work in small, cross-disciplinary teams.
In terms of compensation, cloud development is well paid. The Refonte Learning program cites a career outcome of “$80.0K+ starting” salary and 120K+ job openings for cloud developer roles. (That figure comes from the program’s marketing materials.) Independent industry data paints a similar picture: a Glassdoor analysis (April 2025) shows a median total pay around $127K/year for U.S. cloud developers, while ZipRecruiter (Aug 2026) reports an average around $128K with a median near $130K. In other words, entry salaries in the $80K range are realistic for juniors, and experienced developers often see six-figure compensation. The demand (tens of thousands of openings) remains strong.
In summary, as you sharpen your skills for 2026, focus on coding proficiency and on understanding cloud architecture patterns (including both traditional IaC and these new code-centric frameworks). The job market rewards those who can bridge both worlds.
Building This Skill Set: The Refonte Learning Cloud Development Program
If you’re looking to formalize your skills, consider Refonte Learning’s Cloud Development Program. It’s a 3-month training and virtual internship (12–15 hours/week) that covers all the fundamentals: introduction to cloud computing, service models, building and deploying applications, DevOps/CI/CD, containerization, security, and a capstone project. The program specifically teaches tools like AWS, Azure, Google Cloud, Docker, Kubernetes, and Terraform, giving you a broad foundation. Importantly, it also includes “Infrastructure as Code” in its competencies, which will help you understand when to use code-first frameworks versus traditional IaC (even if it doesn’t teach Encore or SST by name).
Through hands-on projects and mentorship (the instructor, Charlotte Smith, has 10+ years in cloud engineering), you’ll prepare for roles like Cloud Developer, DevOps Engineer, or Cloud Architect. Many graduates report career starts in the $80K+ range and high job placement rates (as noted on the program page). All in all, if you want a structured path to learning cloud and infrastructure principles (beyond just the buzzword frameworks), this program could be a good step.
Code-first infrastructure frameworks can dramatically accelerate feature delivery by eliminating the “ticket wait” for new resources. By learning to integrate tools like Encore, SST, or Winglang into your workflow alongside solid IaC and DevOps practices, and you’ll be at the cutting edge of cloud engineering. The Refonte Learning Cloud Development Program is designed to help you get there, equipping you with the versatile skills that employers seek.