The invisible architecture: how the cloud supports all new tech roles

A web application responds in milliseconds. An artificial intelligence agent queries business information and executes an action. A mobile application synchronizes data in real-time. A pipeline deploys a new version without interrupting the service.

For the user, these experiences occur within an application. Behind it exists a much broader infrastructure that determines whether they can operate securely, efficiently, and reliably when demand increases.

Compute, storage, networks, databases, load balancers, CDNs, identity systems, pipelines, observability, and artificial intelligence services are part of that architecture that remains practically invisible while functioning correctly.

In recent years, specialized profiles have emerged in AI agents, RAG, MLOps, Platform Engineering, APIs, Web Performance, and other disciplines. Although they work on different problems, a considerable part of their capability depends on the available infrastructure.

The cloud has ceased to be simply the place where an application is hosted. In modern architectures, it functions as an enabling layer upon which software, data, and artificial intelligence operate.

Cloud is the infrastructure that connects applications, data, and AI

A modern cloud architecture can be visualized through different layers.

At the top are the experiences used by the user: web applications, mobile, and enterprise systems.

Below are APIs, microservices, and AI services responsible for executing the logic. These components need databases, storage, pipelines, and models. In turn, all of them depend on compute, networking, identity, and other infrastructure resources.

The result can be represented as follows:

Experience: Web · Mobile · enterprise applications ↓ Services: APIs · microservices · AI agents ↓ Data and AI: Databases · pipelines · RAG · models · inference ↓ Platform: Containers · Kubernetes · serverless · CI/CD · observability ↓ Infrastructure: Compute · GPU · storage · networking · CDN · IAM

Not all companies need to use all these components. The importance of the model lies in understanding the dependencies.

A team can develop an excellent application and still be limited by the capacity of the underlying infrastructure.

Cloud Engineers work precisely on this layer, designing and operating resources capable of supporting the technical needs of the product.

The new tech profiles depend on a common infrastructure

An AI Agent Developer and an API Developer may work with completely different stacks, but both need infrastructure to run their systems.

The same applies to Data Engineers, MLOps Engineers, Backend Developers, or Web Performance specialists.

This relationship explains why infrastructure is becoming increasingly transversal.

Specialists build different capabilities on a shared foundation. When that foundation is properly designed, each team can focus better on its domain. When it presents limitations, problems end up propagating to the upper layers.

AI is increasing demands on infrastructure

Traditional enterprise applications already need compute, storage, databases, and networks. The incorporation of artificial intelligence adds new loads and usage patterns.

A RAG system, for example, may require pipelines that process documents, storage, a database prepared for retrieval, embedding services, generation models, and APIs that connect all those components.

An agent adds another dimension. It can interact with different tools, query data, execute operations, and maintain processes that need to be observed and controlled.

Artificial intelligence specialists can develop these capabilities, but bringing them to production also requires resolving how and where they run.

This becomes even more evident when an organization uses proprietary models or specialized infrastructure. GPUs, inference capacity, large data volume storage, and networking can become relevant variables of the system.

Data also needs an architecture capable of moving it

Artificial intelligence has increased attention on data, but the infrastructure needed to work with it existed long before the rise of generative models.

Information from applications, CRM, ERP, e-commerce, devices, or external providers may need to be moved, transformed, and stored before being available for analysis or applications.

Data Engineers build pipelines and platforms that enable these processes.

Cloud provides different components on which they can operate: object storage, databases, processing services, streaming systems, data warehouses, and computing capacity.

The architecture must determine where each type of information lives and how it moves between systems.

This decision affects performance, availability, security, and cost. Replicating large volumes of information unnecessarily or executing processing in incorrect locations can generate a considerable bill without improving the product.

An API also depends on what exists beneath

From the consumer's perspective, an API may simply seem like a URL that receives a request and returns a response.

The infrastructure needed to keep it available can be considerably more complex.

DNS directs the request. A CDN or a perimeter layer may participate before reaching the application. A load balancer distributes traffic. The service processes the request and possibly queries databases, caches, or other systems.

When traffic increases, some components need to scale.

If the application operates in different regions, decisions about geographic distribution, replication, and consistency also arise.

This chain demonstrates why the speed of an API does not solely depend on the endpoint code. Networking, compute, storage, and data architecture also play a role.

Infrastructure becomes visible when it starts to fail

While everything functions correctly, few users wonder where an application runs.

Infrastructure comes into the conversation when the experience begins to degrade.

An API gradually increases its latency. A database reaches its connection limit. A service stops responding when traffic increases. A whole region presents problems. A deployment introduces an incorrect configuration. An AI system starts consuming more resources than expected.

At that moment, what seemed like an invisible layer becomes a critical part of the product.

Some common symptoms include:

• performance degradation as the number of users increases;

• services whose availability depends on a single instance or region;

• difficult-to-reproduce manual deployments;

• lack of metrics to locate where a problem begins;

• cloud costs rising faster than product usage;

• resources configured manually without a consistent source of truth;

• AI systems whose compute demand is difficult to anticipate.

These problems rarely belong exclusively to one technology. They typically reveal an architecture that needs to evolve alongside the product.

Observability allows understanding systems that no longer fit on a single screen

A relatively small monolithic application may be easy to diagnose. When a request traverses multiple APIs, services, databases, and AI components, finding the source of a problem becomes much more difficult.

Observability provides mechanisms to reconstruct that behavior through metrics, logs, and traces.

Metrics allow observing trends such as latency, errors, CPU utilization, or memory consumption. Logs provide information about specific events. Tracing helps follow an operation as it traverses different services.

These signals gain greater value when correlated.

If a user reports that an operation takes five seconds, the team should be able to determine how much time corresponded to the frontend, how much to the API, how much to a query, and how much to any external service involved.

DevOps Engineers can help build these deployment, monitoring, and operation mechanisms so that teams have information before an incident depends solely on manually reviewing logs.

Cloud Engineer, DevOps Engineer, and Platform Engineer do not fulfill exactly the same function

These profiles may share technologies and responsibilities, especially in small organizations. However, they respond to different problems.

The Cloud Engineer primarily works on infrastructure: compute, networking, storage, IAM, managed services, and cloud architecture.

DevOps focuses on improving how software moves from development to production. Automation, CI/CD, Infrastructure as Code, observability, and collaboration between development and operations are part of that scope.

Platform Engineering appears when an organization needs to abstract part of that complexity for numerous teams. Instead of each developer configuring infrastructure directly, an internal platform can provide workflows, templates, and standardized services.

A small team can distribute these responsibilities among a few people. An organization with dozens of teams may need to separate them.

The relevant difference lies in the problem that needs to be solved, not in accumulating titles within the organizational chart.

The platform can turn complex infrastructure into a simple experience

A cloud architecture can offer hundreds of options. Giving direct access to all that complexity to each development team can produce inconsistent configurations and increase operational load.

Platform Engineering seeks to create a layer of abstraction.

A developer could deploy a new service using a template that already includes networking, observability, security policies, and pipeline. They do not need to design all those components from scratch each time.

This allows establishing standards without forcing every developer to become an infrastructure specialist.

IT infrastructure then acquires an additional function: providing a stable enough foundation for different teams to build upon.

Scalability means allocating capacity where it is truly needed

One of the benefits associated with the cloud is the ability to modify resources according to demand.

But scaling an application is not simply about adding servers.

The bottleneck may be in a database, a queue, an external API, or an inference service. Increasing compute elsewhere in the system may not yield any improvement.

The architecture needs to identify which components can scale horizontally, which maintain state, and what dependencies impose limits.

It must also decide how much capacity margin the product needs.

Oversizing infrastructure for traffic that may never arrive generates permanent costs. Maintaining capacity that is too tight can lead to degradation in the face of any unexpected increase.

The balance depends on the actual behavior of the application and the business requirements.

Cloud also turns architecture into an economic decision

Every technical resource has a cost.

Compute, storage, data transfer, managed databases, observability, GPUs, and specialized services can generate different consumption models.

A technically elegant architecture can be economically difficult to maintain if it uses resources inefficiently.

This explains the emergence of disciplines like FinOps, where engineering, finance, and business work together to understand and optimize cloud consumption.

The goal should not be to reduce costs indiscriminately.

A more expensive infrastructure may be perfectly justified if it provides availability, performance, or capacity necessary for the business. The problem arises when the team cannot explain what generates the expense or relate it to the value produced.

Cloud makes it possible to scale resources quickly. It also makes it possible to quickly scale a bad architectural decision.

More cloud does not automatically mean better architecture

Cloud platforms offer Kubernetes, serverless, multiple databases, messaging systems, gateways, advanced observability, and a vast amount of managed services.

Using them all does not make an application modern.

A company operating a relatively simple product can achieve excellent results with a small and predictable architecture.

Complexity should be incorporated only when there is a specific reason: more traffic, availability needs, team growth, regulatory requirements, intensive processing, geographic distribution, or new AI loads.

Software Architecture should help determine when to introduce those capabilities.

A Kubernetes cluster running three simple services can generate more operational work than it resolves. A multi-region architecture may be unnecessary if the business tolerates a brief interruption perfectly. A dedicated infrastructure for AI may not make sense if the current volume is efficiently resolved through managed services.

Technical sophistication only adds value when it meets a real requirement.

The cloud architecture must evolve with the product

A startup validating its first application and a platform used by millions of people need different levels of infrastructure.

Trying to build from day one the architecture that might be needed five years later can slow down the product and consume resources that should be dedicated to validating the business.

The opposite extreme also generates problems.

Indefinitely maintaining an architecture designed for a prototype can lead to incidents, technical debt, and difficulties in incorporating new capabilities.

The strategy is to recognize when the system is approaching its limits and evolve it before those limits become interruptions.

This requires metrics, knowledge of the architecture, and communication between those who build the product and those who operate the infrastructure.

The invisible infrastructure connects the teams that build technology

Tech profiles are increasing their specialization.

AI Engineers work with models and agents. Data Engineers build pipelines. Backend Developers develop services. Frontend and Mobile Developers create experiences. DevOps automates the delivery cycle. Platform Engineers build internal platforms.

Below all of them exists a shared infrastructure.

The cloud provides capacity to run software, store information, move data, connect systems, and scale resources. But its value depends on how that foundation is designed.

An infrastructure that is too limited can hinder even an excellent team. An excessively complex one can consume time and budget without providing a proportional advantage.

The right architecture lies between both extremes: the minimum infrastructure capable of meeting current requirements and reasonably accompanying the evolution of the product.

Users will probably never see that architecture. They do not need to.

They will see an application that responds, an agent that can access the correct information, an available API, or a service capable of supporting an increase in demand.

The new tech profiles build much of what the user can see. The cloud architecture largely determines how far everything that remains beneath can grow.