The three little pigs and public Cloud adoption: from portal-based deployment to Infrastructure as Code

September 8, 2026

The story of the three little pigs tells how three brothers build their homes using different materials. The first quickly puts up a house of straw; the second chooses sticks, which are somewhat stronger; and the third spends more time and effort building a brick house. When the wolf appears, he blows hard and knocks down the first two houses. The brick house, by contrast, withstands the attack and provides shelter from the threat.

This well-known fable offers a simple way to illustrate three approaches to adopting public Cloud services. Organisations can deploy resources directly through the hyperscaler's portal, introduce automation through APIs, or move towards an Infrastructure as Code model. All three approaches make it possible to build environments, but they do not offer the same level of consistency, agility and recoverability when those environments are put under pressure.

In public Cloud, how quickly an environment is built does not, by itself, determine how well it can withstand disruption, recover and evolve.

The house of straw: basic adoption through the portal

The first little pig represents the most immediate and basic adoption model: creating and configuring resources through the public Cloud provider's web portal. This approach makes it possible to get started quickly, supports learning and is useful for proofs of concept, lab environments or one-off requirements.

Within minutes, it is possible to deploy compute, storage, networking or database capacity without first developing automation processes. In this scenario, the value of public Cloud may remain limited if there is no governance, automation and cost control strategy, and some environments may even end up costing more than a properly sized on-premises solution.

However, as the number of resources, teams or environments grows, manual operations begin to show their limitations. Configurations may differ across development, testing and production; reproducing an environment exactly becomes more difficult; and some knowledge remains tied to the individuals who made each change. The absence of a version-controlled process also makes modifications harder to review, approve and trace.

■ Like the house of straw, this model may serve a specific purpose well, but it offers limited protection when it has to cope with scale, operational pressure or urgent recovery.

The house of sticks: portal use and API-driven automation

The second little pig represents a more advanced level of adoption. The organisation continues to use the portal for certain tasks, but introduces scripts, APIs and other forms of automation to perform recurring operations. Provisioning becomes faster and some procedures become repeatable. Manual intervention in routine tasks is also reduced, along with some of the errors associated with carrying them out manually. At this point, organisations begin to extract significantly more value from the Cloud provider.

The house of sticks is more robust, but it still has weak points. Automation may have been created at different times and according to different criteria, or may depend on knowledge that is not sufficiently documented. In addition, a collection of scripts that performs actions does not always provide a complete definition of the desired state of the infrastructure. This can lead to drift between the intended state and what is actually deployed.

■ This model represents a significant step forward and, for many organisations, a necessary stage. However, partial automation does not yet amount to a comprehensive system for designing, deploying, validating and recovering infrastructure consistently.

The brick house: Infrastructure as Code

The third little pig represents an adoption model based on Infrastructure as Code (IaC). In this model, infrastructure components are defined through declarative files or templates that can be stored in repositories, placed under version control and deployed through automated processes.

This approach makes it possible to know which configuration has been approved, review changes before applying them and reproduce environments more consistently. It also makes it easier to integrate with pipelines, security controls, corporate policies and validation mechanisms. If an environment needs to be rebuilt or deployed in another region, the organisation has a reusable definition rather than relying solely on a manual sequence that is difficult to reproduce.

■ The brick house requires more planning and greater upfront effort, but it allows organisations to capture the benefits of public Cloud much more fully. Standards need to be defined, repositories structured, reusable modules designed and responsibilities established.

Infrastructure as Code does not, however, guarantee a secure architecture on its own: a misconfiguration can also be automated and propagated very quickly. Resilience comes from combining code, architecture, governance, security and operational discipline.

The wolf: the threats that put the environment to the test

In an enterprise environment, the wolf does not represent a single threat. It might be an attacker who compromises credentials or encrypts information; a natural disaster affecting a location; human error that deletes or modifies a critical resource; a widespread outage; a faulty update; or an unexpected increase in demand. It can also take less obvious forms, such as an audit, a new regulatory requirement or the departure of someone who held critical knowledge.

When any of these situations occurs, the differences between the models become clear. Having backups is not enough: organisations need to know how the environment was built, reproduce its configuration, apply the necessary controls and restore the service within the defined recovery objectives. The greater the reliance on manual actions and undocumented knowledge, the greater the uncertainty during incident response.

True Cloud maturity becomes apparent when an organisation can respond to an incident using established processes, traceable configurations and reproducible environments.

Building resilient Cloud adoption with the wolf in mind

Moving from public Cloud consumption through portals alone towards Infrastructure as Code is not simply a matter of implementing a tool. It requires analysing business needs, designing the target architecture and establishing a common foundation for identity, connectivity, security, observability, governance and cost control. It also means integrating automation into the operational lifecycle and training the teams responsible for maintaining the environment.

Different Cloud adoption models are not necessarily mutually exclusive. They can coexist and address different needs. The key is to understand the role each model plays and the level of exposure the organisation is prepared to accept. The objective is not always to build the most sophisticated house, but to ensure that critical services remain standing when a cyberattack, disaster, human error or any other unexpected wolf appears.

Ease of access is one of the major advantages of public Cloud, but it can also create a false sense of robustness. Creating resources is easy; building a governed, secure, repeatable platform that is designed for recovery requires a broader approach. This is where a strong partner with Professional Services capabilities for Cloud adoption can help turn the ad hoc use of Cloud services into a robust and sustainable platform.

■ Cloud Professional Services provide the specialist expertise needed to support this evolution: from designing landing zones, defining reusable patterns and modules, and implementing pipelines, to embedding security and compliance by design and establishing continuity and recovery mechanisms.

______

Búsquedas recomendadas