IT Services
Hardware Procurement
Sphere 10 specifies Dell PowerEdge, HPE ProLiant and Lenovo ThinkSystem servers, business workstations and NVIDIA GPU systems around the workload they must run. We translate .NET application concurrency, SQL database activity, dataset size and recovery requirements into CPU, ECC memory, PCIe, NVMe storage and network choices. Procurement includes the complete configuration, expansion and remote-management requirements, followed by a commissioning record tied to measured application demand.
We establish a representative workload before comparing machines. For a business application that means its actual transactions, reports and background jobs; for AI compute it includes model memory, data movement and the intended inference or training task. Our System Expert engineering provides concrete experience collecting Windows processor, memory, storage, GPU and hardware-health evidence. We carry that measurement discipline through vendor comparison, delivery inspection and commissioning, so the equipment decision remains traceable after the purchase.
Size the System From Measured Demand
We measure application response, CPU saturation, managed-memory pressure, storage latency and throughput before choosing a machine. Intel Xeon or AMD EPYC core count is considered with clock behaviour, memory channels and NUMA placement; SQL Server cache and GPU VRAM receive their own capacity model. A representative .NET transaction or model workload establishes the useful baseline, including the storage and network traffic produced during backups and concurrent work.
For .NET systems we relate runtime counters to application behaviour rather than treating high memory use as a hardware fault. We distinguish the operating-system baseline, application working set, database cache and file cache. The resulting capacity model identifies required resources, planned headroom and assumptions that need another measurement.
Check the Complete Compatibility Chain
The compatibility check follows the selected chassis through risers, PCIe lane allocation, NICs, storage controllers and drive backplanes. We verify that an NVMe drive form factor and protocol match its bay, that the intended GPU fits the supported slot, power and cooling configuration, and that DIMM population follows the vendor rules. Boot devices, redundant power, RAID or software-storage policy and replacement-part availability are specified with the host.
GPU procurement covers device memory, supported drivers, operating system and toolkit compatibility, power delivery and physical clearance. We check the actual model or computation against the proposed environment. For application servers, we verify operating-system support and the runtime or database requirements instead of assuming that any machine with enough cores is suitable.
Commission the Delivered Configuration
On delivery we reconcile serial numbers, CPU and DIMM inventory, drive firmware and network devices against the approved bill of materials. Dell iDRAC, HPE iLO or Lenovo XClarity provides the remote inventory and hardware-health baseline. We configure its management access, verify remote console and power controls where licensed, then exercise CPU, memory, storage and GPU demand while observing temperatures, errors and application results.
Acceptance includes repeatable results under realistic operating conditions, not a single synthetic benchmark. We record the test data, settings and measurement method, including limitations of device-specific sensors. The commissioning report distinguishes a configuration problem from an application constraint and identifies the corrective action for each failed check.
Leave an Equipment Record You Can Use
The handover contains the approved bill of materials, purchasing rationale, firmware and driver baseline, support references and commissioning evidence. We identify which components can be expanded independently and which changes require another capacity or compatibility review. This supports later procurement without relying on someone's memory of the original selection.
We also record operational prerequisites: rack space, power, network interfaces, installation access and backup destinations. Your team receives a maintenance and replacement checklist tied to the actual installation. Hardware changes can then be evaluated against the same workload baseline, keeping subsequent upgrades deliberate and comparable.
Technologies & Integration
Discuss Your Infrastructure Project Back to IT Services
Server Deployment
Sphere 10 deploys Windows Server and Linux as complete .NET application environments. We build IIS-hosted ASP.NET Core sites, Windows Services and Linux Kestrel services supervised by systemd, with Nginx at the public boundary where required. SQL Server or PostgreSQL data, uploaded files, service identities and TLS certificates receive explicit ownership. The commissioned host has a reproducible configuration, a versioned release location and acceptance checks under its intended service identity.
Our .NET product engineering connects the host configuration to the application's real behaviour. Local Notion runs across Windows, Linux and macOS; our broader deployment work includes Linux containers, persistent application state and authenticated browser access. We use that practical application knowledge to define installation, restart, logging and recovery procedures. Your team receives a commissioned environment with known ownership and a controlled update path, rather than an undocumented machine that happens to run the first executable.
Define the Host and Its Boundaries
We map ASP.NET Core endpoints, .NET Worker Services, SQL Server or PostgreSQL instances, scheduled tasks and outbound integrations before selecting the host. Windows deployments define Active Directory or local service identities, NTFS permissions and firewall rules; Linux deployments define Unix users, filesystem permissions and systemd units. DNS names, certificate renewal, database connection requirements and administrative access are recorded separately for development, staging and production.
Storage planning separates replaceable application packages from databases, uploaded files and generated business records. We agree capacity, backup scope and the locations that must survive a redeployment. Network design includes name resolution, time synchronisation and certificate renewal, because an accessible port alone does not establish a working application path.
Build a Controlled Application Host
For IIS, we install the matching .NET Hosting Bundle, configure the ASP.NET Core Module and application-pool identity, and separate deployment permissions from application write access. Standalone workers use Windows Service lifetime and recovery settings. On Linux, the systemd unit defines the service user, working directory, executable and restart behaviour. We configure Nginx-to-Kestrel forwarding and trusted proxy headers together so HTTPS redirects, authentication callbacks and client-address handling reflect the real boundary.
Build scripts and configuration records capture the supported runtime, package layout, environment settings and startup behaviour. Secrets are supplied through the agreed protected configuration mechanism. We restrict write access to the application locations that require it and ensure the release package does not silently contain machine-specific credentials or production data.
Prove Restart, Failure and Recovery
Commissioning exercises a cold boot, service restart, certificate path and representative database transaction under the configured service identity. We verify IIS or systemd restarts the intended package, that SQL Server or PostgreSQL permissions permit only the required operations, and that files remain writable after deployment. Nginx upstream failures, unavailable databases and expired credentials are tested as observable operating conditions, with a defined recovery action and retained business records.
We configure useful logs, health checks and operating-system diagnostics with enough context to distinguish host, application and dependency failures. Our System Expert work includes Windows services, processes, event logs, storage and network diagnostics; Linux deployments receive equivalent native operational checks. Recovery exercises follow the agreed state and backup boundaries.
Hand Over a Maintainable Server
Handover includes PowerShell build and verification commands, the IIS or systemd configuration, runtime inventory, firewall and permission map, and the active release location. Windows Admin Center and Event Viewer support Windows diagnosis; systemctl and journalctl identify Linux service state and logs. Your administrator can distinguish a stopped service, reverse-proxy error, missing runtime and failed database connection using the supplied checks, then follow the matching restart, rollback or restore procedure.
We define the update sequence for the operating system, runtime and application, including prerequisites and a recovery decision point. Monitoring, patching and incident response can continue under an agreed operating arrangement. Changes remain tied to a configuration record, keeping an emergency fix from becoming an invisible dependency in the next release.
Technologies & Integration
Discuss Your Infrastructure Project Back to IT Services
Virtualization
Sphere 10 builds and migrates virtual infrastructure on Microsoft Hyper-V, VMware vSphere and Proxmox VE with QEMU/KVM. We size the hosts, guest resources, virtual networking and storage around the applications sharing them, including ASP.NET Core services, SQL databases and background processing. Each delivered guest has an owned image, identity, capacity allocation and recovery path, with the application checked after migration or restoration.
Virtualisation changes where the operating system runs; it does not remove application ownership. We relate guest sizing to database activity, .NET process behaviour, scheduled work and peak concurrency. Our application and persistence engineering, including Sphere10 Framework , informs the backup, connection-lifetime and restart decisions. A development workstation running an isolated test machine receives a different design from a host carrying several operational systems. We establish those requirements before selecting Hyper-V or a Linux KVM/QEMU environment and document the actual supported configuration.
Allocate Capacity Where the Guests Compete
Resource design follows the hypervisor and the competing guests. We review Hyper-V memory settings and virtual processors, vSphere reservations, limits and CPU-ready evidence, or KVM vCPU topology and memory allocation. NUMA layout, host overhead and storage latency are assessed under simultaneous application and backup demand. The allocation records which workloads can grow, what resources are reserved and which measurements trigger another capacity decision.
We examine oversubscription against simultaneous demand, including backup and maintenance windows. CPU scheduling, memory pressure and shared-disk queues are measured together. The allocation record identifies limits, reservations and practical growth options so a new guest does not quietly consume the capacity on which an existing service depends.
Keep Guest Disks and Application Records Consistent
We select VHDX, VMDK or qcow2/raw storage with the hypervisor, datastore and backup method in view. Hyper-V production checkpoints and application-aware backup, vSphere guest quiescing, and QEMU guest-agent coordination are configured for the selected operating system. SQL Server and PostgreSQL receive engine-aware recovery procedures. A migration records the guest generation, disk chain, endpoint changes and the point at which the old instance stops accepting writes.
We coordinate database and file capture with the processes that write them. The design distinguishes a convenience checkpoint from a recoverable application backup, including credentials and configuration needed after restoration. Migration planning includes DNS, client endpoints and a decision point for returning to the previous guest.
Make Virtual Machines Rebuildable
Build automation uses Hyper-V PowerShell, vCenter templates and guest customisation, or Proxmox templates and cloud-init as appropriate. We configure virtual switches or Linux bridges, IEEE 802.1Q VLAN membership, guest tools and driver prerequisites with the image. Machine identity, network addressing and service credentials are supplied deliberately when cloning, so a template can create a usable replacement without duplicating another server's identity.
Templates capture the intended operating system, drivers, virtual devices and application prerequisites. We identify unique machine identities and secrets that must be supplied separately. Your team receives the guest build and host configuration together, allowing a failed guest to be replaced without guessing which manual changes mattered.
Demonstrate Recovery at the Application Boundary
Acceptance checks include host and guest restart, resource contention and restoration of a representative system. Where availability or migration is in scope, we test the agreed transition and measure its effect on the application. Handover includes inventory, configurations, baseline measurements and the sequence for maintaining the environment.
We distinguish a guest fault from a failed host, storage path or virtual switch before choosing the recovery action. The runbook orders infrastructure, database and application startup and checks each dependency under its service identity. This prevents a successful guest boot from concealing an unavailable database or a changed endpoint.
Technologies & Integration
Discuss Your Infrastructure Project Back to IT Services
Containers and Clusters
Sphere 10 packages .NET applications into Docker images and operates them through Docker Compose or Kubernetes according to the workload. We deliver ASP.NET Core services, Worker Services and supporting databases with explicit image versions, configuration, identities, networks and persistent storage. A Compose installation has a maintained host and release procedure; a Kubernetes installation includes its Deployment, Service, ingress, storage and operating responsibilities.
We begin with the service's actual processes and data. A web application, background worker and database have different startup, shutdown and storage needs; placing them in containers does not make them interchangeable. Our .NET Linux deployment work includes non-root processes, restricted filesystem writes and retained state outside replaceable packages. We turn those concerns into an explicit image build, runtime configuration and operational test sequence, with the smallest deployment model that supports the required availability and maintenance workload.
Choose the Host and Scheduling Model
We use Docker Compose for defined multi-container stacks whose host, networks and volumes can be operated together. Kubernetes introduces separate scheduling, Services, rollout control and persistent-volume ownership for workloads needing those capabilities. The decision includes node capacity, container architecture, Linux or Windows image compatibility, registry access and the team responsible for cluster upgrades. Availability requirements determine replica placement and recovery checks.
We record which failures the installation must tolerate and who will operate it. A bounded service stack can remain a straightforward host deployment. A cluster design includes scheduling, identity, ingress, storage and upgrade responsibilities; these are part of delivery, rather than assumed benefits of choosing an orchestration product.
Separate Images From Runtime Configuration
The Dockerfile or .NET container publish configuration separates build tooling from the runtime image and records the target architecture. Runtime settings arrive through the chosen environment, configuration or secret mechanism; application data uses explicit volumes or managed stores. Kubernetes security context and service-account permissions, or Compose user and filesystem settings, are checked against the .NET process's actual read and write requirements.
Entrypoint and shutdown settings are verified so stop requests reach the .NET process. Active requests and workers receive a bounded completion period, with unfinished durable jobs available to another instance. We check filesystem permissions under the configured container identity and prevent operational writes from depending on the image's replaceable layer.
Define a Release Your Team Can Reproduce
A release binds an immutable image digest to Compose configuration or versioned Kubernetes manifests and Helm values. We define readiness, liveness and startup probes separately, plus resource requests and limits, rollout settings and termination grace. Acceptance replaces an instance while processing a representative request or durable job, checks persisted state and confirms that a previous image can be selected with a compatible database generation.
Release records connect source generation, image identity, configuration and deployment manifests. We document promotion between environments and the migration compatibility required by each release. Operators can identify what is active, reproduce the configuration and decide whether rollback restores service or conflicts with a completed data change.
Replace Components Without Losing the Work
Acceptance includes a fresh deployment, service restart, dependency failure and replacement of an application image while retaining the required records. Cluster engagements test the agreed rollout and node-disruption scenarios. We verify the served application separately from container health.
A rolling release needs database changes that old and new application instances can both tolerate during transition. We stage compatible schema additions, data backfills and later removals deliberately. Request draining and readiness control when traffic reaches each generation; returning to an older image is assessed separately from reversing a data migration.
Technologies & Integration
Discuss Your Infrastructure Project Back to IT Services
Network Structuring and Segmentation
Sphere 10 designs segmented IPv4 and IPv6 networks around real application paths. We configure IEEE 802.1Q VLANs and routing on platforms such as Cisco Catalyst, with FortiGate or pfSense enforcing the permitted traffic between user, application, database and management zones. IEEE 802.1X access control and WireGuard site or administrative tunnels are integrated where the access model requires them. The delivered network includes its address plan, rule ownership and tested allowed and denied paths.
We trace application traffic before changing network rules. Browser access, database connections, directory services, time synchronisation and external APIs form different trust and availability relationships. Our .NET and ASP.NET Core work connects those routes to actual application behaviour, including proxy headers, certificate names and client addressing. Our System Expert engineering supplies concrete Windows adapter, endpoint and packet-capture experience. We use the appropriate platform tools to produce an understandable communication model and a controlled implementation sequence.
Map Source, Destination and Responsibility
We map DNS, DHCP, identity, application, database and management traffic before assigning VLANs. For switching, the configuration states access-port membership, allowed tagged VLANs, trunk endpoints and the treatment of untagged traffic. Routing and firewall ownership are explicit at each boundary. A login, upload or report supplies the source, destination, protocol and return path used to verify the diagram against the application.
Where documentation is incomplete, a representative login, report or import provides a bounded traffic-capture scenario. We correlate observed endpoints with name resolution, address translation and TLS termination. IPv4 and IPv6 paths are checked where enabled, because an allowed path in one address family must not bypass the intended boundary in another.
Design Access by Purpose
Access policy combines network placement with the identity controls the estate supports. An IEEE 802.1X design records the supplicant, switch or access-point authenticator, RADIUS service, certificate requirements and recovery access. WireGuard configuration records peer keys, permitted routes and firewall policy at both ends. Database ports, administrative services and public reverse proxies receive distinct rules, with direct bypass paths included in the acceptance checks.
Management access, public ingress, staff access and service-to-service communication receive separate rules and identities. We align network boundaries with application authorization rather than expecting a subnet to enforce every business permission. Reverse-proxy trust and forwarded client details are explicitly configured for the ASP.NET Core applications behind the boundary.
Turn the Diagram Into Reviewed Configuration
We implement reviewed VLAN, address-object, route, NAT and stateful-firewall changes in a controlled sequence. Cisco switch-port and trunk settings are checked alongside FortiGate or pfSense interface and policy configuration. We retain configuration backups and a management path throughout the change, then test representative flows and deliberate denials from the correct zones. IPv6, DNS and return routing are included in the recorded result.
The delivery package connects address plans, VLANs, routing and firewall rules to a source-to-destination access matrix. Each permitted path carries its purpose and owner. We document rollout order, configuration backups and the checks used to prove that a rule change preserved essential name resolution, monitoring and administration services.
Commission With a Retained Management Path
Changes are staged so the team retains a known management path while rules are applied. Acceptance checks both successful application workflows and attempts that should be denied. We record the tested source and destination context rather than reporting an unexplained pass.
Rule testing checks direction and connection state, not merely whether one port opens. A database can accept connections from its application zone while rejecting the same request from a user workstation. We test the intended proxy path and direct bypass attempts separately, then retain the rule and source context behind each result.
Technologies & Integration
Discuss Your Infrastructure Project Back to IT Services
Backup Solutions
Sphere 10 delivers backup and recovery for virtual machines, .NET applications, databases and business files using Veeam Backup & Replication, restic and database-native tooling as appropriate. We define the recovery point objective, recovery time objective, retention and access model for each service, then implement the capture, off-site storage, monitoring and restore procedure. SQL Server, PostgreSQL and SQLite receive recovery methods matched to their actual consistency and write behaviour.
A .NET application can keep important state in several places: database transactions, uploaded documents, local object stores and configuration outside the executable directory. We trace those locations and select a consistent capture method for each. Our Local Notion product provides concrete experience downloading Notion pages, databases, objects and attachments with local history. For any system, we distinguish the material we can export from the application or workspace behaviour that must be reconstructed and verified after a failure.
Define the Recovery Set and Its Ownership
The recovery set names the databases, file stores, service configuration, encryption keys and application generation needed to restore a business function. We agree RPO and RTO targets with the owner, measure the data volume and available transfer window, and select Veeam jobs, restic repositories or engine-native schedules accordingly. Repository administration and restore credentials are assigned independently from routine application access, with retention tied to the restore chain.
We record dependencies needed to interpret the captured data, including encryption keys, application versions, schema versions and external configuration. Recovery priorities distinguish services needed immediately from archives that can follow later. Retention and access rules account for an operator mistake as well as disk failure or a lost host.
Capture State at a Consistent Boundary
SQL Server recovery combines the selected full, differential and transaction-log backups with its recovery model. PostgreSQL uses an appropriate logical dump or base backup with WAL archiving for point-in-time requirements. SQLite uses its supported backup mechanism for an active database. Veeam application-aware processing or a coordinated application export handles the selected workload, and associated file generations are recorded with the database capture.
Capture generations receive a manifest linking the database set, associated files and required configuration. Completion is recorded only after the expected parts exist and can be read. For an incremental chain, the procedure tracks its base and dependencies so retention cannot discard a generation still needed to restore a newer one.
Make Backup Failures Operationally Visible
We monitor missed jobs, source omissions, repository capacity, chain dependencies and restore credentials. Veeam repository protections or a deliberately protected restic destination are configured with the storage service and administrator permissions in view. Integrity checking and sampled file recovery accompany the schedule; an independent restore exercise measures the full application recovery time and reconciles the resulting records against the agreed recovery point.
Monitoring distinguishes a completed backup from an empty result, inaccessible source or partial export. We retain job identity, source generation and useful error context without exposing secrets. Operators receive clear handling for missed schedules, unavailable destinations and expired access, with an accountable owner for restoring the backup process itself.
Restore Into an Independent Environment
Acceptance restores selected data into an isolated location and verifies content, permissions where relevant and application behaviour. We include a damaged or missing source scenario where it materially affects the design. Handover contains runbooks, alert handling and a schedule for repeating recovery exercises.
Restoration has a dependency order: obtain required keys, recreate the supported runtime, restore the database and files, then connect services and validate records. We verify that the recovery destination cannot accidentally send live notifications or duplicate scheduled work. The exercise identifies credentials or installation assets that existed only on the lost host.
Technologies & Integration
Discuss Your Infrastructure Project Back to IT Services
Auditing and Evaluation of Existing Systems
Sphere 10 audits existing .NET applications and their Windows, Linux, SQL Server, PostgreSQL and network dependencies using source inspection and operational evidence. We investigate slow transactions, unreliable releases, access weaknesses, recovery gaps and unsupported components. The review connects concrete runtime findings to a prioritised correction plan, using appropriate CIS configuration benchmarks and NIST Cybersecurity Framework outcomes when security and operating controls are in scope.
Our reviews combine .NET application engineering with host and operational analysis. Sphere10 Framework gives us direct experience maintaining application composition, persistence, serialization and user-interface infrastructure. Our System Expert work covers Windows process, memory, storage, network and configuration inventories. We bring those concerns together when investigating an inherited application, a slow production workload or an uncertain migration plan. The assessment distinguishes observed defects, credible risks and questions that need a targeted experiment, making the result useful for both technical and commercial decisions.
Set the Questions and Inspection Boundary
We agree which business operations, hosts, repositories, identities and datasets are included, together with the permitted evidence collection. A Windows Server or Linux configuration review uses the applicable CIS Benchmark and records the selected profile and justified exceptions. Identity and recovery questions are mapped to the organisation's NIST CSF outcomes. Application, infrastructure and control findings retain their own evidence and closure conditions.
For an inherited .NET application, we match the deployed assembly and runtime to its source revision and configuration before interpreting a reported defect. A representative slow operation is traced from screen input through generated queries and dependencies. This establishes whether the issue belongs to code, data shape, environment drift or an external system.
Connect Runtime Evidence to Source and Configuration
For .NET we use dotnet-counters, dotnet-trace and dumps to investigate allocation, garbage collection, CPU, blocked work and thread-pool behaviour. Sysinternals Process Explorer connects process identity and resources to Windows evidence; Wireshark supports a bounded network investigation. SQL Server Query Store or PostgreSQL EXPLAIN connects slow requests to query plans, waits and ORM loading. Source, configuration and measurements are correlated around the same reproduced operation.
We correlate process counters, traces, logs and database behaviour with code paths and configuration. Dependency versions, transaction boundaries, cancellation, background work and resource ownership are reviewed where they affect the question. Measurements include their collection conditions and limitations, avoiding conclusions drawn from a single busy counter or screenshot.
Prioritise Work by Consequence and Dependency
Recommendations name the failing operation, affected product/version, evidence and engineering correction. An EF Core or NHibernate finding can identify excess round trips, transaction lifetime or an unbounded result; an infrastructure finding can identify a firewall rule, unsupported runtime or missing recovery dependency. We rank consequences and prerequisites, then specify the exact workload, permissions or restored function that will demonstrate closure.
Findings identify the affected operation, evidence, consequence and recommended correction. We separate work that prevents a safe release from later maintainability improvements, and sequence changes according to their dependencies. Where inspection cannot establish an outcome, we propose a bounded experiment with a specific pass condition and useful deliverable.
Hand Over an Evidence Package Others Can Act On
We walk through the findings with the people responsible for the system and distinguish immediate faults from longer-term improvements. Acceptance is the agreed evidence package and decision support, not a promise that every possible defect has been discovered. Handover includes the collected non-secret configuration references, reproducible checks and proposed next steps.
Each recommended correction includes a closure condition. A query finding names the dataset and result to compare; a recovery finding names the restored workflow; a dependency finding identifies the affected release. The owner can retest the original evidence after a fix and distinguish a resolved problem from a symptom that merely stopped appearing.
Technologies & Integration
Discuss Your Infrastructure Project Back to IT Services
