2018 in Technology: IT and Hardware Trends

What 2018 in IT looked like in plain words

2018 was remembered as the moment when IT stopped being “just about computers” and became about trust, risks and the pace of change. Even familiar things — office PCs, rack servers, mail and documents — began to depend much more on security, supply chain, government requirements and how quickly teams can update systems.

To be specific, in the rest of the text “technology” will mean a few understandable layers: business applications and data, employee endpoints (PCs, all‑in‑ones, peripherals), servers and data centers, network and storage, and cybersecurity and regulatory requirements. These layers are linked: a CPU vulnerability or a configuration error can hit both users and servers.

You can view 2018 from different angles. For business, the most important constraints are budget, deadlines, reliability and downtime. For government bodies—compliance, procurement rules and supply transparency. In education and healthcare, accessibility and straightforward support often come first: workstation or system outages quickly become interruptions in teaching or patient care.

Market inertia matters too. Large vendors operate in cycles: new hardware generations appear regularly, but fleet updates take years. In 2018 this was especially noticeable due to a combination of factors: attention to vulnerabilities and updates, regulatory and internal security pressure, infrastructure complexity (clouds, containers, hybrid setups), growing interest in AI and analytics, and expectations for round‑the‑clock support and resilience.

So a review of 2018 is useful not as a “list of novelties” but as guidance: which solutions became de‑facto standards, where new risks emerged, and why planning PC and server refreshes became more disciplined. For integrators and manufacturers this was clear: quality, certification, service and lifecycle control began to be discussed alongside raw specs.

Main trends of 2018

If you sum up 2018 in a few words: cloud, containers, AI, security and data. But what's more important than the terms is how they changed everyday decisions — from server choice to how teams roll out updates.

The first noticeable shift was hybrid models. Many companies stopped arguing “cloud or on‑prem” and began combining both. Sensitive data and critical systems stayed on‑prem, while tests, spare capacity and some services moved to the cloud. This forced a fresh look at networking, backups and unified access rules.

The second trend was manageability. As the number of services and devices grew and admin time shrank, standardization and automation gained value: identical images, clear configurations, centralized monitoring and fewer manual tweaks.

The third trend was that security became embedded rather than a separate purchase. After high‑profile incidents and tighter attention to personal data, it became normal to check not only the perimeter but also processes — who has access, how systems are updated, and how fast recovery is.

Another shift was demand for reliability and supply‑chain transparency. Organizations increasingly asked where and how equipment was produced, who is responsible for support and how predictable the service is.

Priorities often became hybrid architecture and unified access policies, containerization with more frequent releases, automated monitoring and updates, verifiable supply and clear service models.

A simple example: a bank keeps core systems on its own servers and moves analytics and test environments to the cloud. It needs not only new servers but a unified monitoring, backup and access control scheme. In that scenario the important thing is not the “most powerful” box but a supported platform and service model — what system integrators typically include.

Security and regulators: what changed

2018 is remembered for security no longer being just antivirus and firewall. Early in the year, CPU‑level vulnerabilities (Spectre and Meltdown) were widely discussed. This was an unwelcome signal: a problem might not be in software but deeper — in the silicon and the way instructions are executed.

In practice, this meant mass microcode and OS updates. In some scenarios, especially server workloads with heavy I/O, organizations experienced performance drops. A painful choice emerged: apply patches quickly and lose some throughput, or delay and expose data to risk. For many, 2018 became the year when update management had to be built “for real”: testing, maintenance windows, rollback, version tracking.

At the same time, pressure from regulators and clients increased. GDPR in Europe became a symbol of a new approach to personal data: collect less, explain where and why you store data, and be able to prove you protect it. Even companies outside the EU felt the effect if they worked with European partners or processed EU user data.

Typical business reactions in 2018 were practical: first an asset inventory (which PCs, servers, OS and firmware are actually on the network), then patch management with a test cluster and clear deadlines for critical updates. Networks were resegmented, backup policies revisited (frequency, offline copies, regular restore tests) and data ownership clarified: who owns what, where it’s stored and who has access.

A simple example: after CPU vulnerability news a company updates servers and sees a drop in accounting system performance. If a test rig and metrics exist, you can choose settings, update in stages and avoid disrupting the workday. Without them, updates can become as risky as the vulnerability.

PCs and endpoints: what changed in hardware

In 2018 desktop PCs and workstations noticeably “matured.” The main shift was simple: more compute power became available not only in expensive configurations but across mainstream endpoints. This pushed companies to revisit office PC standards, especially where many browser tabs run, heavy spreadsheets are used, CRM and video calls are common.

CPUs evolved in two directions: more cores and higher frequencies while keeping reasonable thermal envelopes. Intel and AMD actively refreshed their product lines. Practically, this was felt as price and availability fluctuations in some segments and more value‑for‑money configurations in others that previously seemed “almost professional.”

A landmark of 2018 was storage. SSDs were increasingly seen as the basic minimum for endpoints, and NVMe moved from “nice to have” to the norm for those working with large files, databases or virtual machines. The issue was not only speed but predictability when a disk is under load.

All‑in‑ones, thin chassis and touchscreens grew more common. For reception desks, classrooms and medical posts, all‑in‑ones were valued for tidiness, fewer cables and easier installation. In Kazakhstan this trend was supported by local manufacturers including GSE.kz, which developed domestic PC and touchscreen all‑in‑one lines — helping to standardize fleets and simplify support.

If in 2018 you chose a “typical” office PC, you looked at a few basics: enough cores for multitasking, presence of an SSD (and whether NVMe is needed), headroom in RAM for 2–3 years, noise and heat in dense deployments, and ease of maintenance and service.

Servers and data centers: 2018 updates

For data centers, 2018 marked a shift: more workloads were limited not by “do we have enough servers” but by how fast and predictably systems performed under load. Companies began to count not only purchase price but TCO: power, licenses, rack space and admin time.

Server CPUs: core race and pragmatic calculations

Competition in server processors intensified in 2018. Vendors added cores and offered more flexible price tiers. Practically, this led to recalculating configurations: is it better to have fewer but more powerful servers, or spread load across more nodes?

Applied questions became common: how many VMs can a host run without degradation, what costs more for you — per‑core licensing or downtime from insufficient capacity, and how fast can you scale with user growth?

Virtualization, consolidation and new storage requirements

Squeezing more VMs out of a single server became common. This drove consolidation but increased the cost of a mistake: one overloaded host could affect dozens of services. Demand for fast storage rose. NVMe and all‑flash arrays were increasingly considered not as luxury but as ways to reduce latency and provide stable IOPS for databases, VDI and analytics.

There was also stronger demand for faster in‑rack networking. 25G became a reasonable target for new deployments, and 100G appeared more often at aggregation layers. Interest in density and cooling grew: higher rack density requires careful attention to power, cabling and heat.

A typical scenario: an organization upgrades 2–3 old racks and wants to fit more services into fewer nodes. Turnkey solutions — where servers, network, storage and support are selected together — often won such projects.

AI and accelerators: what became mainstream

In 2018 AI stopped being only a lab topic and began to be treated as an applied task: document and face recognition, anomaly detection in payments, demand forecasting, automating support. Businesses wanted clear outcomes: less manual work, fewer mistakes, faster processing.

The spread of AI was largely enabled by accelerators, primarily GPUs. When selecting workstations and servers it became important to look not only at CPUs and memory but also at whether there is space and power for GPUs, how many PCIe lanes are available, cooling design and PSU reliability. For servers it was common that the same project might need different configurations — from “one GPU for a pilot” to multiple accelerators for training.

Money often went not to huge neural networks but to pilots and data. Companies bumped into labeling, cleaning, access rights and reproducibility. At the same time, practices later called MLOps began to take shape: how to store versions of data and models, how to test quality, how to deploy updates without surprises.

Typical 2018 expectations boiled down to a few conclusions. Quick wins appear where many repetitive tasks exist and a clear quality metric is available. If data is scarce or “dirty,” a GPU won’t help: the project stalls at preparation. Simple models are often sufficient, but embedding results into processes (who and how uses the output) is crucial. Finally, training and production are different problems: for production, stability, monitoring and support matter most.

A practical example: a bank pilots document scan recognition. The first weeks go to collection and labeling, then one GPU workstation is used for training and a standard server for inference to avoid overspending. In such projects not only hardware purchase matters but also infrastructure and support design.

Cloud, containers and DevOps: 2018 shifts

In 2018 many companies stopped seeing the cloud as “all or nothing.” Instead of arguing where infrastructure should live, they chose the best place for each task.

Containers became popular because they simplified moving apps between environments. The same service could run on a test server, then in production, and later be moved to another provider with minimal repackaging. Kubernetes increasingly became the common way to manage containers: scale, restart on failure, and roll out updates stepwise.

DevOps in 2018 became more practical. It was not an abstract “culture” but habits that deliver measurable benefits: deploying changes more often while reducing the risk of each release.

What became “normal” in DevOps

Common practices included automated builds and checks (CI/CD), “infrastructure as code” instead of manual setup, observability via metrics and logs, and small, frequent releases.

Hybrid cloud became a realistic compromise. Sensitive data, critical systems and workloads that need predictable latency stayed on‑prem. Services that are convenient to change, test or scale moved to the cloud.

An example: a large clinic keeps part of medical systems and patient databases in a local network, while appointment portals and notifications run in the cloud because they require frequent updates and must absorb traffic peaks. Such projects need reliable servers and clear support so the hybrid setup doesn’t turn into chaos.

Why the barrier to entry fell

By 2018 there were more ready‑made platforms and templates: standard Kubernetes clusters, typical CI/CD pipelines and basic security practices. That made it easier to start small without building a “perfect platform” for years.

How to use 2018 lessons when planning IT for 2019–2020

2018 showed a simple truth: winners are not those chasing trends but those who assess risks and update IT by plan. In 2019–2020 the best approach is clear steps that link security, performance and support into a single picture.

Start with a short but honest work plan. First gather an inventory: PCs, servers, network gear, licenses, OS versions and critical services (mail, accounting, healthcare, education, front‑office). Then pick 3–5 priorities for 12–18 months: patches and backups, removing performance bottlenecks, supply transparency and import substitution (if important), user convenience and 24/7 support for key systems. After that decide the hosting model: on‑prem, cloud or hybrid. Often hybrid is needed: critical data and services remain inside, while secondary loads are moved outside.

Next, outline a three‑year refresh cycle: endpoints in batches, servers by criticality, a separate plan for storage and backups. Immediately include operations: spare parts, response times, and recovery procedures.

After 2018 many organizations found that security updates can reduce performance and old platforms are harder to patch. So test updates in advance and have rollback plans.

A practical example: if an organization in Kazakhstan has a heterogeneous PC fleet and a couple of servers without clear maintenance history, it makes sense to start with standardizing models and a single support contract. In government and large companies this is often combined with requirements for local origin and supply transparency — these criteria are best formalized as part of a strategy, not as a one‑off purchase.

In the 2019–2020 budget, allocate funds for backups and restore tests, support and spare parts (disks, PSUs, memory), basic security hygiene training for staff and pilots (one new server node or a batch of PCs) to validate the approach before mass rollout.

Common mistakes that became visible in 2018

2018 clearly showed that problems rarely stem from “the wrong brand.” They usually grow from operational and planning habits.

The most visible mistake was around updates. Many postponed patches to avoid downtime, especially on servers and critical endpoints. As a result vulnerabilities accumulated and the window for safe updating narrowed. A working approach is different: short maintenance windows, testing on a pilot group and a clear rollback procedure.

The second common issue was buying servers “by CPU.” In 2018 many saw that CPU gains do not help if the bottleneck is storage, network or cooling. A server can be powerful on paper but slow under real load.

The third mistake concerned architecture: critical and non‑critical services often lived on the same network and under the same access rules. Without segmentation a single incident becomes a chain reaction. Zoning and least‑privilege access usually deliver more effect than adding another point security product.

The fourth mistake was moving “everything to the cloud” without calculations. Surprises appeared in storage bills, traffic costs and backup needs, and in data and regulatory requirements.

Fifth — starting an AI project without a foundation: no quality data, no owner of outcomes and no metrics of value. Companies often buy servers and accelerators but do not define which processes the model should improve and who will change workflows after deployment.

A short checklist: what to check after reviewing 2018

If you recognize 2018 scenarios in your environment, it’s most useful to quickly check basic things. This list helps find risks that typically surface after an incident or sudden outage.

• Security: is there an inventory of devices and software, is a patch management process in place, have backups been tested with restores, is MFA enabled for mail, VPN and admin access?
• Infrastructure: review CPU, RAM and disk usage charts for 30–90 days, note network bottlenecks (Wi‑Fi, office switches, links to branches), estimate data growth rates and remaining capacity.
• Endpoints: how many PCs are older than 4–5 years, is key software compatible with current OS, where are all‑in‑ones a logical choice (reception, classrooms, medical desks)?
• Support and operations: are SLAs and responsibilities clear, are spare critical parts available, are uniform configuration standards used, is there short user training for frequent issues?
• Documentation and planning: are data and access policies updated, are procurement and local origin requirements considered, is there a 12–24 month roadmap with budget and priorities?

If you answer “not sure” to two or three items, start with inventory and backups, then move to fleet and infrastructure updates. For organizations in Kazakhstan it’s useful to verify procurement and support requirements in advance so delivery and service are not surprising.

Simple example: refreshing a fleet of PCs and servers after 2018

Imagine an organization with 300 office PCs and 10 servers in a small server room. Over a year workload grew (more 1С/ERP usage, more files, more remote work), and after 2018 it became clear old practices no longer suffice: CPU‑level vulnerabilities, new data protection requirements and higher user expectations for speed.

Split the refresh into stages to avoid stopping work and spending the whole budget in one go.

• Stage 1 (0–2 months): inventory and risk assessment. Which PCs can’t handle the OS and office tasks, which servers are constrained by CPU/RAM/disks, what’s the state of backups and patches, which services are “critical.”
• Stage 2 (2–6 months): quick wins. Replace the most problematic PCs (e.g., 20–30% of the fleet), upgrade some older machines with SSDs and more RAM. On servers, beef up the storage subsystem for databases and VMs, add 10GbE where the network is the bottleneck.
• Stage 3 (6–12 months): core infrastructure. Gradually refresh remaining PCs, either replace servers with newer models or move some workloads to a hybrid setup: mail, archives, test environments.
• Stage 4 (after 12 months): standards and support. Lock in unified images, update schedules, encryption policy and access control.

A common budget split: 60–70% for endpoints (replacements and upgrades), 20–30% for servers and storage, and about 10% for security and backups. If supply transparency and local service matter, decide in advance which items to source from a local manufacturer or integrator (for example, locally produced PCs and servers in Kazakhstan) and which to treat as a service.

Compromises are straightforward: immediately fix security and critical bottlenecks (patches, backups, database disks), later improve comfort (monitors, peripherals), and move unregulated loads (development, analytical sandboxes, seasonal peaks) to the hybrid cloud.

Check metrics after three months and after a year, not impressions: share of devices with up‑to‑date patches and enabled encryption, number of incidents and mean time to recovery, CPU/RAM utilization and disk latency on servers at peak hours, backup success and recovery verification times, and number of “slow/frozen” support tickets per 100 users.

Next steps: turning findings into a concrete plan

The lesson of 2018 is simple: updates are easier as a series of small decisions than as one big rare project. To avoid getting lost in trends, summarize findings on a one‑page plan.

One‑page plan

A good format that you can show a manager and team consists of five blocks: 3–5 main risks (security, downtime, insufficient capacity, supply dependence), three priorities for 90 days, timelines and milestones (pilot, procurement, rollout), owners (process owner, InfoSec, IT, procurement) and success criteria (fewer incidents, faster performance, clear support).

That makes it easier to decide what to update first: endpoints, servers, network, backups or access policies.

Run a pilot, not a full replacement

A pilot reduces risk and helps understand real workload. Usually 10–20 endpoints or 1–2 server nodes are enough. For example, in accounting and sales you quickly see whether a fast SSD, more RAM or stable drivers and peripherals matter most.

For a pilot agree in advance on two things: who collects feedback and how you will roll back if needed.

Then prepare procurement requirements: localization and status of domestic manufacturers (if important for public procurement), required certificates, clear delivery times, warranty and support. Where internal resources are lacking, involve an integrator for design, deployment and support — especially for servers, virtualization and backups.

If typical scenarios fit you (office PCs, workstations, rack servers, delivery and service), consider locally produced lines and support from GSE.kz (gse.kz) as one option for pilots and later rollouts.