This text is a summary of my 14+ years of experience working with the cloud as a novelty or part of a transformation, especially among non-technical people. The examples described in the article below were found on the internet and in public sources. Suggested framework are also just an examples and they’re not universal cures. Sources linked in the article should be treated as just the beginning of exploring the particular topic.
Introduction: The Invisible Cloak
In the grand theater of digital transformation, infrastructure is often treated like a boring understudy-invisible, underappreciated, but the whole production falls apart as soon as it trips over a cable. No one applauds Wi-Fi, VPNs, or the aging Kafka cluster running on some forgotten Azure subscription. Until something breaks.
Until Slack freezes during an all-hands meeting, the Product Owner can’t access JIRA, and the CEO’s demo throws a 502 error. Then we remember: infrastructure is not a backdrop. It’s the backbone of an organization. And transforming with a broken backbone is more like yoga fail than corporate rebirth.
These ten chapters could be the autopsy report of every digital transformation that forgot to check its network’s pulse.
#1: The Cult of Visibility
Every company claims to be data-driven. Most are perception-driven. We fund dashboards, AI copilots, and real-time UX heatmaps, but we ignore what lies beneath.
Infrastructure is invisible by design-and that’s dangerous.
The board sees business units. We see teams. We see applications. We don’t see load balancers, orphaned IP addresses, tangled VPC peering configurations, or that archaic Jenkins job that’s the only thing deploying the finance module.
So we prioritize what we can see. Until what we can’t see breaks everything.
Example: A new user portal was created in one of institutions. The front end worked like a charm. The UX was beautiful. But no one invested in a stable API gateway and DNS redundancy. The result? Total collapse on the first day of application submission. “Unforeseen success,” as the press release put it.
Anti-pattern: Decision-making based on what you see on the slide.
Framework:
- Visibility
- Criticality
- Risk
- Decision: invest before it breaks.
#2: The Cloud is not Magic, it’s someone else’s computer
The phrase “moving to the cloud” often means lift-and-shift migration. In practice, this often means moving our monolith from a physical server to EC2 and praying for DevOps.
Example: A particular company moved its entire CRM to the public cloud. The architecture remained intact – except for increased latency and a 300% increase in costs. The teams didn’t know who managed the VPC, and backups were set up once – by accident.
Anti-pattern: The myth of the cloud as a panacea. “Just move everything to AWS and we’ll be a modern company.” Without a well-thought-out rearchitecture 🔎, the cloud becomes just a more expensive server.
Framework: Cloud transformation (Cloud Readiness Canvas 🔎):
- Are our applications cloud-native?
- Does the architecture assume multi-tenancy, automatic scaling, disaster recovery?
- Are costs monitored in real time?
- Do teams have the skills to manage infrastructure as code?
#3: The Underfunded Team of Culprits
Infrastructure teams often operate like an invisible army. When it works, no one notices. When it fails, they are to blame for everything. Release not working? Infrastructure. Application crashing? Infrastructure. Security? Their job too.
Example: A large retail chain failed to implement DevSecOps (or anything similar, to be honest), despite receiving alerts about vulnerabilities in its backend dependencies. The team didn’t have the time, people, or tools. When an attack occurred, management demanded heads. But the SIEM tools had been out of date for eight months.
Anti-pattern: Assuming that Ops doesn’t need a roadmap. Infrastructure is seen as “maintenance” rather than a strategic partner.
Framework: Infrastructure team investment model (Ops Maturity Matrix 🔎):
- Level 1: Firefighting – responding to failures without systematization.
- Level 2: Reactive project support – visibility only through incidents.
- Level 3: Strategic partner – own roadmap, KPIs, regular reviews with technology and business leaders.
- Level 4: … read about this concept - You will find many smarter texts on this subject than this one.
#4: Networks are political
Start planning a multi-regional architecture, and you will quickly discover that the biggest problem is not TCP/IP packets, but your organization’s policies.
Example: A company branch in X country wanted to deploy a service independently. The head office’s network policy blocked VPNs. Every change required a ticket to Y country and security approval from the head office. The project died due to a lack of… decision-making capacity.
Anti-pattern: The network as departmental property – not a shared service. Lack of trust and standardization lead to chaos and conflicts between regions or departments.
Framework: Network Trust Zones model 🔎:
- Risk-based segmentation (e.g., personal data vs. test data)
- Delegation of change approval to local teams with accountability
- Common security policy layer with overarching control (audit, logs, certifications)
The larger the organization, the network is less technical and more geopolitical.
#5: Death by Excel
When you keep your infrastructure inventory in an Excel spreadsheet, your organization enters “blind management” mode.
You don’t know what you have. You don’t know what’s breaking. And you have no way to respond proactively.
Example: In one corporation, asset data was stored in separate files: one for dev, one for sec, and one for backups. There was no common view. When the storage failed, no one knew where the snapshots were.
Anti-pattern: Manual inventory without auditing and synchronization. No central CMDB system 🔎, no automatic resource data update processes.
Framework: Infra Asset Framework (CAF – Configuration Asset Framework or you can call it as you want):
- Single source of truth (e.g., ServiceNow, CMDB)
- Synchronization frequency (real-time > batch > manual)
- Visibility and availability (for whom and with what level of permissions?)
- Change monitoring and compliance with policies (log auditing, backups, versioning)
Excel as a control tool dies with the first incident. Inventory automation is not a luxury – it is a necessity.
#6: Repair Architecture – Transformation through Disaster
Investments in infrastructure are most often the result of… disaster.
Nothing speeds up budget approval like a crisis. It is transformation through trauma.
Example: After a server room failure that shut down an institution for 36 hours, the entire organization switched to an active-active model. But only because no one wanted to answer to the Financial Supervision Authority for another outage.
Anti-pattern: Budget only after a fire. No risk modeling or system resilience design in advance. No environments for testing system behavior under pressure.
Framework: Proactive Resilience Model 🔎, for example:
- Level 1: No plan – ad hoc responses, no documentation, manual recovery
- Level 2: Reactive post mortem – post-failure analysis, no preventive measures
- Level 3: Failure modeling – chaos engineering, DR tests, automatic failovers, rollback procedures, runbooks
A resilient infrastructure is one that anticipates not only success but also spectacular failure. And it has a ready response to it.
#7: Observability ≠ monitoring
Monitoring will tell you that something is broken. Observability will help you understand why. It’s the difference between “the temperature is rising” and “here’s where the heat is escaping.”
Example: A logistics company was experiencing API delays. Monitoring only showed spike latency. But only full traces from OpenTelemetry 🔎 revealed the source: a library version conflict between two microservices.
Anti-pattern: Dashboards without context. Alerts from data silos that generate more noise than signal. No correlation between logs, metrics, and business events. Visibility ends at the frontend application layer.
Framework: Observability Triangle 🔎:
- Logs – events, errors, exceptions, audits
- Metrics – availability, response time, CPU/RAM usage
- Traces – request flow through components
Additional elements (I strongly recommend their implementation):
- Correlation with deployments (feature flags, canary releases)
- Integration with incident management (pager duty, runbooks)
Observability is not a tool. It is a practice of designing systems with understanding in mind.
#8: The Myth of Stateless Systems
Stateless systems are beautiful in theory. But reality adds exceptions: local caches, user sessions, complex routing, regional dependencies.
Example: An e-commerce application was rewritten as microservices. Unfortunately, all session data was stored in a single Redis 🔎 instance in country X. Customers in country Y reported timeouts. Ultimately, it was necessary to rebuild the sessions with geolocation and data synchronization in mind.
Anti-pattern: Stateless… except for data. A service that is declaratively stateless but in practice depends on a single data source or external cache becomes difficult to scale and only seemingly fault-tolerant.
Framework: Data availability design model (Data Gravity Grid) 🔎:
- Data location – where it is created and where it is needed
- Availability – what is the SLA and RTO/RPO
- Synchronization cost – how much does traffic, storage, and cold start cost
- Security – does the data have to remain in the region (compliance)
Stateless systems do not mean a lack of responsibility for data. They mean conscious management of its flow and availability.
#9: Terraforming Organizations
Infrastructure-as-code (IaC) 🔎 is more than automation. It is a record of intent, standardization 🔎, and the ability to revise engineering decisions.
The problem starts when IaC serves as digital duct tape.
Example: Team A used Terraform to create VPCs 🔎. Team B used it to manage resources in the same space. No one had permissions for everything, and pipelines were overwritten. After the third conflict, a manual rollback was necessary.
Anti-pattern: IaC without ownership and modularity policies. No standards, no audits, no code reviews – every change is a risk, every module is different. Chaos in the Terraform repository means chaos in the infrastructure.
Framework: IaC Lifecycle Framework 🔎:
- Repository – single source, accessible, divided into modules
- Modularity – small, repeatable components, no cross-dependencies
- Version control and audit – commit = decision, code reviews
- Testing and validation – terraform plan, terraform validate, policy-as-code (OPA)
- State management – remote backend, locking, rollback
If infrastructure is not subject to review, it cannot be managed – only reacted to when errors occur. IaC is an act of engineering culture, not just technical convenience.
#10: Platform instead of Team
Don’t build an infrastructure team. Build a platform. A product. With users (developers), SLAs (internal), a roadmap, and satisfaction metrics.
Example: A technology company implemented an Internal Developer Platform (IDP) 🔎. As a result, the time to deploy a new application was reduced from 18 days to 2 hours. The platform team acted as a product team – with a backlog, metrics, and customer satisfaction.
Yep, that was a positive example for a change.
Anti-pattern: The infrastructure team acts as 24/7 support. No roadmap, reactivity, support without partnership. Developers do not see value and treat the team as “blockers.”
Framework: Internal Developer Platform Canvas (I just made this up, but hear me out below):
- Users – developers, QA, security, analysts
- Value – speed of implementation, quality of environments, process automation
- Services – CI/CD, logging, monitoring, cost control, feature flags
- Interfaces – CLI, UI, chatOps, documentation
- KPIs – Developer Net Promoter Score, time from idea to production, environment failure rate
A platform team is not a fixed cost. It is an investment in the scalability of the organization. A platform is a tool for influence, not a cost center.
#11: Infrastructure for AI – between GPUs and responsibility
The rise of language, predictive, and generative models means entirely new requirements for infrastructure. It’s no longer just servers and load balancers – it’s GPU clusters, low-latency networks, model orchestration, and integration with MLOps.
Example: A company launched a churn prediction system. The ML model performed well in testing. But the inference infrastructure was not prepared for 40 million queries per day – the service crashed on the first deployment. The GPUs were too weak, there was no auto-scaling, and the fallback logic did not anticipate timeouts.
Anti-pattern: The model only works on the data scientist’s laptop. There is no production environment for inference, no plan for handling input data, and no model decision logging. AI as proof-of-concept without operationalization.
Framework: AI Infrastructure Canvas (I encourage every large company to create its own model, especially if it has a lot of legacy and non-standardized or scattered data on which it wants to build an AI solution.):
- Phase: training / inference / feedback loop
- Components: data storage / GPUs / model orchestration / MLOps pipelines
- Requirements:
- Latency (e.g., real-time <100 ms vs. batch overnight)
- Cost (cost per model decision, GPU usage optimization)
- Transparency (decision logging, auditability)
- Regulatory compliance (AI Act, data locality, explainability)
AI requires a separate infrastructure layer – as strategic as that for financial transactions. And much more difficult to predict in terms of costs and behavior.
Bonus Episode: AI Act, ESG, and compliance
AI Act
European legislation on artificial intelligence (AI Act) 🔎 imposes specific requirements on infrastructure:
- Traceability – the ability to trace input data and AI model decisions
- Environment segmentation – clear separation of dev, test, and production environments
- Auditability – inference logging, model versioning, full decision traces
- Data compliance – data location compliant with GDPR and industry requirements
The AI Act does not only require model compliance – it requires compliant infrastructure.
ESG and GreenOps
Infrastructure consumes energy. A lot of energy. And every organization that publishes an ESG report should consider:
- The carbon footprint of cloud consumption (CO₂ emissions per workload)
- The energy efficiency of processes (GreenOps)
- Equipment lifespan (circularity) and optimization opportunities
In Poland, this is even more important due to the current energy mix and the location of cloud operators’ data centers within the country.
Framework #1: Sustainable Infra Canvas (just canvas everything xd - I’m joking but the concept of being able to store all crucial information on the one page/canvas is really good if you really want the people to read)
- Optimization of cold vs. hot storage
- Separation of rarely used data
- Scheduling tasks for times of lower energy consumption
Framework #2: DevOps & Infrastructure Policies. Modern infrastructure must be designed for DevOps, i.e.:
- Automated CI/CD – no manual steps in deployments
- Observability + SLO – services must report their own health
- Security by Design – security policies built in from the start (Shift Left Security)
- Rollback & Progressive Delivery – systems must allow for safe rollback of changes
A well-designed DevOps infrastructure not only supports teams, but also “knows” when something is wrong – and can show it before the dashboard turns red.
Let’s land, shall we?
Infrastructure is not just a technical thing. It is a layer that determines:
- the pace of change,
- data security,
- real service availability,
- the scalability of AI solutions,
- costs – including hidden ones,
- compliance with regulatory requirements (AI Act, ESG, GDPR).
Digital transformation without a solid infrastructure is like trying to push a train on gravel – it can be done, but you won’t get very far.
Instead of building new applications, companies should start by strengthening the ground on which these applications will run.
Infrastructure is not an “operating cost.” It is a strategic pillar. It is not just an IT tool – it is internal policy, organizational trust, and the ability to anticipate crises. We cannot talk about modern AI, agility, or innovation if we have not invested in:
- fail-safe resilience,
- cost and energy control,
- automated regulatory compliance,
- a platform culture,
- observability of the entire ecosystem.
In large organizations, infrastructure can no longer be a forgotten foundation. It must be a topic for the board. An element of strategy. A tool for building advantage. Because the next crisis will not ask if we are ready.
It will simply happen.