What is ASP.NET Core?

ASP.NET Core is a free, open-source, and cross-platform framework developed by Microsoft for building modern, cloud-based, internet-connected applications. It is a complete redesign of the earlier ASP.NET framework, optimized to run on Windows, Linux, and macOS, enabling developers to build web applications, APIs, microservices, and real-time applications using .NET technologies.

ASP.NET Core is modular, lightweight, and highly performant, providing a unified programming model for building web UI and web APIs. It supports dependency injection, middleware pipeline configuration, and integrates seamlessly with modern client-side frameworks.

With its cloud-ready architecture and extensive tooling support (Visual Studio, VS Code), ASP.NET Core has become the preferred choice for enterprise-grade web development.

Major Use Cases of ASP.NET Core

1. Web Applications

ASP.NET Core is used to develop responsive, scalable web apps with Razor Pages or MVC (Model-View-Controller) architecture, supporting dynamic server-side rendering.

2. RESTful APIs

Creating REST APIs for mobile apps, single-page applications (SPA), or third-party integrations using lightweight JSON communication.

3. Microservices

Building loosely coupled, independently deployable microservices with built-in support for containerization (Docker) and cloud-native patterns.

4. Real-Time Applications

Using SignalR in ASP.NET Core for real-time features like chat, live notifications, or collaboration apps.

5. Cross-Platform Server Apps

Run ASP.NET Core on Windows, Linux, or macOS servers or containers, supporting hybrid and cloud environments.

6. IoT and Edge Computing

Lightweight runtime makes it suitable for backend services for IoT devices and edge computing scenarios.

7. Blazor WebAssembly

Develop client-side interactive web UIs with C# and Razor syntax running in browsers.

How ASP.NET Core Works Along with Architecture

ASP.NET Core architecture is modular and based on middleware components that handle HTTP requests in a pipeline.

Core Architectural Components:

• Hosting Layer

Manages app startup and lifetime, configuring web server and dependency injection container.

• Web Server

By default, uses Kestrel, a cross-platform, high-performance web server. Can be run standalone or behind IIS, Nginx, or Apache.

• Middleware Pipeline

A sequence of middleware components that process requests and responses, enabling functionalities such as routing, authentication, static files, error handling, and CORS.

• Routing

Matches incoming HTTP requests to endpoint handlers like controllers or Razor Pages.

• Dependency Injection (DI)

Built-in DI container enables injecting services and managing their lifetimes.

• MVC Framework

Supports separation of concerns with Controllers (handle requests), Models (data/business logic), and Views (UI rendering).

• Razor Pages

Simplifies page-focused scenarios with page-centric programming.

• Entity Framework Core

Object-relational mapper (ORM) for database interactions.

• Configuration and Logging

Supports hierarchical configuration sources (JSON, environment variables) and structured logging.

Request Processing Flow

1. HTTP request arrives at Kestrel server.
2. Request enters the middleware pipeline.
3. Middleware components inspect, modify, or short-circuit the request.
4. Routing middleware selects the matching endpoint.
5. Controller or page handler executes, returning a response.
6. Response passes back through middleware pipeline.
7. Response sent to client.

Basic Workflow of ASP.NET Core

1. Project Creation

Start a new ASP.NET Core project using Visual Studio, CLI, or VS Code.

2. Configure Services

Register services like MVC, database contexts, and authentication in Startup.ConfigureServices.

3. Setup Middleware

Configure HTTP request pipeline with middleware in Startup.Configure.

4. Create Controllers and Views

Implement application logic in controllers, build UI with Razor views or pages.

5. Configure Routing

Define URL patterns mapping to actions or pages.

6. Run and Debug

Build and run the app locally using Kestrel or IIS Express.

7. Test

Write unit and integration tests to validate functionality.

8. Deploy

Publish and deploy to cloud platforms (Azure, AWS), containers, or on-premises.

Step-by-Step Getting Started Guide for ASP.NET Core

Step 1: Install Prerequisites

• Install .NET SDK
• Install IDE like Visual Studio 2022, VS Code with C# extension

Step 2: Create a New Project

Using CLI:

dotnet new mvc -n MyAspNetCoreApp
cd MyAspNetCoreApp

Or use Visual Studio:
File → New → Project → ASP.NET Core Web App (Model-View-Controller)

Step 3: Explore Project Structure

• Program.cs – App entry point, builds host and starts server.
• Startup.cs – Configures services and middleware.
• Controllers/ – Contains controller classes.
• Views/ – Contains Razor view files.
• appsettings.json – Configuration settings.

Step 4: Configure Services and Middleware

Edit Startup.cs:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }

    app.UseStaticFiles();

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapDefaultControllerRoute();
    });
}

Step 5: Add a Controller

Create HomeController.cs:

public class HomeController : Controller
{
    public IActionResult Index()
    {
        return View();
    }
}

Step 6: Add a View

Create Views/Home/Index.cshtml:

<h1>Welcome to ASP.NET Core!</h1>

Step 7: Run the Application

Using CLI:

dotnet run

Visit http://localhost:5000 in your browser to see the app running.

Step 8: Add Entity Framework Core (Optional)

Install EF Core packages:

dotnet add package Microsoft.EntityFrameworkCore.SqlServer
dotnet add package Microsoft.EntityFrameworkCore.Tools

Configure DbContext and perform database migrations.

Step 9: Build, Test, and Deploy

Use Visual Studio or CLI tools to build, test, and deploy your app.

The ongoing COVID-19 pandemic and recent social strife has pushed the Kubernetes project to alter its quarterly update schedule through the end of the year, though it’s looking to get back in track (like the rest of the world) in 2021.

The Kubernetes 1.19 release should have dropped at some point around June 30. That would have maintained what had been a near metronome-like schedule of platform updates dating back to its initial 1.0 release in mid-2015. However, external events have altered that pattern.

“The 1.19 release has been quite different from a regular release due to COVID-19, George Floyd protests, the Black Lives Matter movement, and several other global events that we experienced as a release team,” explained Taylor Dolezal, lead on the Kubernetes 1.19 Release, in an email to SDxCentral. “Due to these events, we made the decision to adjust our timeline and allow [special interest groups], working groups, and contributors more time to get things done. The extra time also allowed for people to take time to focus on their lives outside of the Kubernetes project and to ensure their mental wellbeing was in a good place.”

The 1.19 update is currently scheduled to be released on Aug. 25. The update is expected to include a greater focus on sidecar integration, which has been an ongoing focus point for several of the past updates.

Dolezal, who is also a developer advocate at HashiCorp, said that the subsequent 1.20 release will be the last one scheduled for this year, “and the plan is to return to a three-month update cycle (baring no unforeseen circumstances),” he added.

The current delay could be a boon for enterprises that continue to struggle with Kubernetes’ infernal update schedule. A Platform9 survey of more than 1,300 attendees at last year’s KubeCon + CloudNativeCon event in San Diego found more than 44% cited “upgrades” as challenge in running Kubernetes.

Sponsored by Kontron

This new ebook explores edge computing as an efficient way to handle the massive data volumes generated by 5G technology. Learn about edge computing architecture and the benefits associated with having a more distributed network.

By clicking the link, I consent to share my contact information with the sponsor(s) of this content, who may reach out to you as part of their marketing campaigns, and register for SDxCentral email communications. See how we use your data: Privacy Policy.

Kubernetes Looks Within

As part of this reset, the project also launched a new working group focused on evaluating the language and naming choices within the project “with a specific initial focus on removing barriers to contribution and adoption by replacing harmful language with neutral terms whenever possible,” Dolezal explained. This move is similar to one being instituted by a number of vendors that are looking to remove “problematic language” from software terms.

The Kubernetes project is also requiring all of its chair and technology leads to complete a Linux Foundation unconscious bias course that Dolezal will help identify “possible language or practices that may proliferate such bias.”

Background: The Kubernetes Security and Compliance Gap

As Kubernetes adoption accelerated through 2019 and into 2020, many organizations moved workloads from experimental clusters to production environments. With that transition came a growing need to address not just operational security, but formal regulatory compliance—specifically frameworks like PCI DSS (Payment Card Industry Data Security Standard) and GDPR (General Data Protection Regulation).

The challenge is structural. Standards like PCI DSS were written before containers and orchestrators became mainstream. Concepts such as “server,” “network segment,” and “system component” do not map cleanly to Kubernetes primitives like pods, nodes, namespaces, and clusters. This ambiguity forces developers and auditors alike to interpret legacy compliance language in a cloud-native context—an error-prone, manual process that slows delivery and increases risk.

What Alcide Announced

In March 2020, Alcide—a Kubernetes-focused security vendor—announced that its Alcide Kubernetes Security Platform added automated compliance scanning for both PCI DSS and GDPR. The goal was to let DevOps and security teams run regulatory compliance checks continuously and alongside existing security controls, rather than treating compliance as a separate, periodic audit exercise.

According to Alcide, the platform could, for example, verify that firewall configurations protecting cardholder data environments were in place, or flag direct public internet access to system components that should be isolated—checks directly derived from PCI DSS requirements.

Why This Matters for DevOps Teams

Regulatory compliance has traditionally been the domain of dedicated security or audit teams. The shift toward DevSecOps means compliance checks are increasingly expected to be embedded into CI/CD pipelines and cluster lifecycle management. Manual audits against PCI DSS or GDPR requirements in a dynamic Kubernetes environment—where workloads scale up and down, namespaces are created frequently, and network policies change—are difficult to sustain without automation.

Alcide’s 2019 State of Kubernetes Adoption and Security survey (cited in the announcement) reported that 44% of respondents were running Kubernetes in production at the time, up from 20% in 2018. The company also previously found—through scanning real-world clusters—that a large proportion of Kubernetes deployments were not using built-in security features such as Kubernetes Secrets. These findings highlighted an automation gap that compliance tooling is designed to address.

PCI DSS and GDPR in a Kubernetes Context

Understanding what PCI DSS and GDPR compliance means for Kubernetes environments requires mapping traditional requirements to cloud-native equivalents:

PCI DSS Considerations for Kubernetes

• Network segmentation: PCI DSS requires isolating the cardholder data environment (CDE). In Kubernetes, this translates to enforcing NetworkPolicy rules between namespaces and restricting ingress/egress for pods that handle payment data.
• Firewall configuration: Equivalent controls include Kubernetes NetworkPolicies, cloud provider security groups, and service mesh policies (e.g., Istio authorization policies).
• System component identification: Auditors must decide whether a “system component” in PCI terms corresponds to a pod, a node, or a cluster. There is no single accepted answer, and this interpretation affects the scope of a PCI audit.
• Access control: Role-Based Access Control (RBAC) in Kubernetes maps partially to PCI’s requirements for restricting access to system components and cardholder data.
• Logging and monitoring: PCI DSS requires audit logs. Kubernetes audit logging, combined with a log aggregation solution, is the typical approach.

GDPR Considerations for Kubernetes

• Data minimization: Workloads processing EU personal data should request only the permissions and data access they require. Kubernetes RBAC and pod security controls support enforcement.
• Encryption in transit and at rest: GDPR expects appropriate technical measures. Kubernetes supports TLS between components; storage encryption depends on the underlying infrastructure and storage class configuration.
• Data residency: GDPR may impose geographic constraints on where personal data is processed. In Kubernetes, node affinity and topology constraints can be used to restrict pod scheduling to compliant regions.
• Secrets management: Storing credentials or personal data in environment variables rather than Kubernetes Secrets (or a dedicated secrets manager) is a common misconfiguration with compliance implications.

The Role of Automated Compliance Scanning

Automated compliance scanning tools—whether from vendors like Alcide or open-source projects such as kube-bench (which checks against CIS Kubernetes Benchmark controls)—work by codifying compliance requirements as machine-readable checks and running them against live cluster configurations or infrastructure-as-code manifests.

The advantages of this approach include:

• Continuous assurance: Checks run on a schedule or as part of a pipeline, rather than only at audit time.
• Drift detection: Configuration changes that introduce compliance violations are caught quickly rather than discovered months later.
• Developer-facing feedback: Surfacing compliance issues in developer tools (pull request checks, Slack alerts) allows remediation before changes reach production.
• Audit evidence: Automated scan reports provide documented evidence for auditors, reducing the manual effort required to demonstrate compliance.

Key Takeaways for DevOps and Security Engineers

Whether you are evaluating a commercial platform or assembling an open-source compliance toolchain, the core principles for Kubernetes PCI DSS and GDPR compliance remain consistent:

1. Define your compliance scope early. Determine which namespaces, nodes, and clusters are in scope for PCI or GDPR, and enforce hard boundaries using NetworkPolicies and RBAC.
2. Automate checks rather than relying on periodic manual reviews. Kubernetes environments change constantly; point-in-time audits miss configuration drift.
3. Map framework requirements to Kubernetes primitives explicitly. Document your interpretation of how PCI DSS “system components” or GDPR “technical measures” translate to your specific cluster architecture, and get agreement from your auditor.
4. Use Kubernetes-native security features. RBAC, NetworkPolicy, PodSecurity (or OPA/Gatekeeper policies), audit logging, and Secrets management are foundational. Compliance tooling is most effective on top of these controls, not as a substitute for them.
5. Involve security teams in platform design. Compliance requirements are easier to meet when the cluster architecture is designed with them in mind, rather than retrofitted after the fact.

About Alcide

Alcide was a Kubernetes security company focused on providing continuous security and compliance tooling for cloud-native deployments. The company was later acquired by Rapid7 in early 2021. As of the time of that acquisition, features from the Alcide platform were integrated into Rapid7’s broader cloud security offerings.

What Is Cloud-Native DevOps?

Cloud-native computing is more than a deployment model — it is a fundamental shift in how enterprise software is designed, built, and operated. At its core, cloud-native abstracts away the complexity of hybrid and multi-cloud environments, allowing workloads and applications to run without being tightly coupled to any single infrastructure layer.

When you combine that abstraction with DevOps culture and automation, you get cloud-native DevOps: an approach that extends cloud best practices across the entire software delivery lifecycle — from code commit to production deployment to business outcome measurement.

For most teams, Kubernetes is the entry point to cloud-native infrastructure. But the infrastructure is never the end goal. The goal is delivering better applications to customers and employees, faster and with less risk.

Three Common Starting Points for Cloud-Native Adoption

Because cloud-native is an all-encompassing paradigm, organisations rarely adopt it in a single step. In practice, three distinct starting points emerge:

• Cloud-first strategy: Defaulting to a cloud-based option over an on-premises one whenever the cloud alternative meets the business need. This is the most common entry point for greenfield workloads.
• Hybrid IT or multi-cloud architecture: Acknowledging from the outset that multiple environments — private data centres, multiple public clouds, edge — are a deliberate, long-term choice rather than a transitional state.
• DevOps transformation: Agile shops that prioritise automation and cultural change quickly discover that infrastructure complexity — inconsistent environments, fragmented data, governance bottlenecks — blocks their ability to ship software reliably. This forces them into cloud-native thinking from the application delivery side.

Regardless of starting point, organisations eventually face the same challenges: managing data across environments, automating deployment pipelines end-to-end, and proving that engineering effort translates to business value. A growing set of cloud-native tools address each of these gaps.

The Expanding Cloud-Native DevOps Toolbox

The following three tool categories — cloud-native data persistence, continuous delivery as a service, and value-stream measurement — represent important gaps that purpose-built cloud-native products are beginning to fill. The specific vendors cited below were highlighted in late 2019 analysis from Intellyx; the underlying architectural patterns they represent remain broadly relevant.

1. Cloud-Native Data Persistence

One of the most underappreciated challenges in cloud-native DevOps is data persistence. Stateless microservices are straightforward to containerise and orchestrate with Kubernetes. Stateful workloads — databases, file stores, data pipelines — are considerably harder.

Products designed for cloud-native data persistence attempt to solve this by presenting a single, unified namespace across all on-premises and cloud-based storage options. Above the abstraction layer, an application sees one large logical volume. Beneath it, the platform handles data tiering (hot, warm, and cold), multi-cloud data sharing, disaster recovery, automated failover, and automated fallback.

For DevOps teams building modern enterprise applications on multi-cluster Kubernetes, this kind of abstraction is essential. Without it, data locality and consistency become manual, error-prone concerns that slow down every release cycle.

2. Continuous Delivery as a Service

Continuous integration (CI) has become relatively mature. Most engineering teams have adopted Git-centric workflows and automated build pipelines. Continuous delivery (CD), however, remains the harder half of the CI/CD equation — and the more consequential one.

Common blockers to reliable CD include:

• Manual acceptance testing gates that are inconsistently applied
• Change advisory boards (CABs) that serialise approvals and add days or weeks of latency
• Compliance sign-offs that require human intervention at every deployment
• Lack of automated rollback when a deployment degrades production quality

SaaS-delivered CD platforms address these blockers by providing pipeline builders, workflow automation, deployment verification (comparing pre- and post-deployment metrics to detect regressions automatically), and automated rollback. Crucially, they encode governance into the pipeline itself — approval workflows, audit trails, and policy enforcement — so that governance accelerates delivery rather than blocking it.

This governance-as-code model is what makes cloud-native CD qualitatively different from simply scripting a deployment with a legacy CI tool. At scale, manual governance is the bottleneck. Automating it is the only viable path to frequent, reliable deployments across hybrid multi-cloud environments.

3. Value-Stream Measurement and Flow Metrics

Even teams that have mastered CI/CD often struggle to connect their engineering activity to business outcomes. This is where value-stream management (VSM) tooling becomes important.

VSM platforms model the end-to-end flow of work through a software delivery toolchain — from idea capture and planning, through development, testing, and deployment, to production. They surface flow metrics, a set of measurements that tie directly to business outcomes rather than engineering activity:

• Flow velocity: How many work items (features, defects, risk items, debt) are completed per unit of time?
• Flow distribution: What proportion of effort is going to features versus defects versus technical debt?
• Flow time: How long does it take for a work item to move from start to delivery?
• Flow efficiency: What percentage of flow time is active work versus waiting?
• Flow load: How much work is in progress at any given time?

These metrics make the business impact of cloud-native investments visible. Without them, it is difficult to determine whether a Kubernetes migration or a CI/CD pipeline overhaul is actually improving outcomes for customers — or just keeping engineers busy.

The causal chain runs in one direction: customers drive business outcomes, business outcomes drive application requirements, and application requirements drive infrastructure choices. Value-stream tooling makes that chain visible and measurable in real time.

Putting It All Together: A Cloud-Native DevOps Reference Architecture

A mature cloud-native DevOps practice combines these three layers into a coherent whole:

1. Infrastructure abstraction layer: Kubernetes orchestrates compute; cloud-native storage solutions abstract persistent data across environments. Development teams do not need to know which cloud or data centre is running their workload.
2. Automated delivery layer: A CI/CD pipeline automates build, test, and deployment. Governance tasks — approvals, compliance checks, audit logging — are encoded as pipeline stages, not manual handoffs.
3. Measurement layer: Flow metrics and value-stream models connect deployment frequency and lead time to business outcomes, providing the feedback loop that allows teams to improve continuously.

The overarching principle across all three layers is abstraction through automation. Cloud-native DevOps does not eliminate complexity — it hides complexity behind well-defined interfaces and automates the management of what lies beneath.

Key Takeaways for DevOps Practitioners

• Cloud-native is not just an infrastructure choice — it is an application delivery strategy that demands corresponding changes to your DevOps toolchain and culture.
• Data persistence is frequently the hardest cloud-native problem. Invest in abstraction layers that let applications treat multi-cloud storage as a single resource.
• If your CI pipeline is mature but your CD pipeline stalls at manual governance gates, automating those governance steps is your highest-leverage improvement.
• Without value-stream measurement, cloud-native investments are difficult to justify to the business. Flow metrics translate engineering activity into language that product and business stakeholders understand.
• Start where your organisation has the most pain — infrastructure, delivery, or measurement — and expand from there. There is no single correct entry point.

Disclosure

The original analysis this article draws on was produced by Intellyx. At the time of publication (November 2019), NetApp was an Intellyx customer and AppDynamics was a former Intellyx customer. No other organisations mentioned were Intellyx customers. Readers should weigh vendor relationships accordingly when evaluating specific product recommendations.