Infrastructure Concepts: Difference between revisions
Line 10: | Line 10: | ||
In a cloud environment, infrastructure, as viewed by the user, is no longer represented by hardware, but by virtual constructs like servers, [[Amazon_VPC_Concepts#Subnet|subnets]] and block devices. The hardware still exists, but infrastructure elements accessible to users "float" across it, can be manipulated by the [[#Infrastructure_Platform|infrastructure platform]] APIs and can be created, duplicated, changed and destroyed at will. They are referred to as [[#Infrastructure_Resource|infrastructure resources]]. Infrastructure resources can be instantiated, changed and destroyed by [[Infrastructure as Code#Subjects|infrastructure as code]] to provide the infrastructure foundation for [[#Application_Runtime|application runtimes]] and [[#Applications|applications]]. | In a cloud environment, infrastructure, as viewed by the user, is no longer represented by hardware, but by virtual constructs like servers, [[Amazon_VPC_Concepts#Subnet|subnets]] and block devices. The hardware still exists, but infrastructure elements accessible to users "float" across it, can be manipulated by the [[#Infrastructure_Platform|infrastructure platform]] APIs and can be created, duplicated, changed and destroyed at will. They are referred to as [[#Infrastructure_Resource|infrastructure resources]]. Infrastructure resources can be instantiated, changed and destroyed by [[Infrastructure as Code#Subjects|infrastructure as code]] to provide the infrastructure foundation for [[#Application_Runtime|application runtimes]] and [[#Applications|applications]]. | ||
=Application= | =Application= | ||
'''Applications''' and '''services''' provide domain-specific capabilities to organizations and users. Everything in the underlying layers ([[#Application_Runtime|application runtime]], [[#Infrastructure_Platform|infrastructure platform]]) exists to enable this layer. | '''Applications''' and '''services''' provide domain-specific capabilities to organizations and users. Everything in the underlying layers ([[#Application_Runtime|application runtime]], [[#Infrastructure_Platform|infrastructure platform]]) exists to enable this layer. Just a few examples out of a very large set are: salesforce.com, Intuit Quickbooks, batch services based on Spark, aimed at data scientists, etc. Applications can be directly offered to users as part of a cloud service delivery model, under the generic name of '''Software-as-a-Service''' (SaaS). The users do not need to manage anything, but they also do not control anything, including the design of the application. This works well, unless the customer needs functionality that is not available in the application. | ||
=Application Runtime= | =Application Runtime= |
Revision as of 20:34, 30 December 2021
External
- http://www.infrastructures.org
- Infrastructure as Code: Dynamic Systems for the Cloud Age by Kief Morris
Internal
Overview
In a cloud environment, infrastructure, as viewed by the user, is no longer represented by hardware, but by virtual constructs like servers, subnets and block devices. The hardware still exists, but infrastructure elements accessible to users "float" across it, can be manipulated by the infrastructure platform APIs and can be created, duplicated, changed and destroyed at will. They are referred to as infrastructure resources. Infrastructure resources can be instantiated, changed and destroyed by infrastructure as code to provide the infrastructure foundation for application runtimes and applications.
Application
Applications and services provide domain-specific capabilities to organizations and users. Everything in the underlying layers (application runtime, infrastructure platform) exists to enable this layer. Just a few examples out of a very large set are: salesforce.com, Intuit Quickbooks, batch services based on Spark, aimed at data scientists, etc. Applications can be directly offered to users as part of a cloud service delivery model, under the generic name of Software-as-a-Service (SaaS). The users do not need to manage anything, but they also do not control anything, including the design of the application. This works well, unless the customer needs functionality that is not available in the application.
Application Runtime
The application runtime layer provides services and capabilities to the application layer. An application runtime is laid upon the infrastructure platform layer and it is assembled from infrastructure resources. The application runtime instance may include container clusters, serverless execution environments, application servers and databases. This layer is also referred to as Platform as a Service (PaaS).
Infrastructure Platform
Infrastructure Resources
A cloud infrastructure platform abstracts infrastructure resources (compute, network, storage) from physical hardware. Infrastructure resources are assembled to provide application runtime instances.
Infrastructure Services
Infrastructure Stack
- Stack integration point.
Environment
Cloud
NIST definition: https://www.nist.gov/programs-projects/nist-cloud-computing-program-nccp
Containers
Cluster
Cluster as code.
Container Cluster
Server
Serverless Execution Environment
Configuration Drift
Configuration drift is variation that happens over time across systems that were once identical. Manually making changes in configuration (performance optimizations, permissions, fixes), even if the base was laid down by automation, causes configuration drift. Selectively using automation on some of the initially identical systems, but not on others, also causes configuration drift. This is how snowflake systems come into existence. Also see Minimize Variation. Once manually-introduced configuration drift occurs, the trust in automation goes down, because people are not sure how an automation will modify a manually-changed system. Interestingly, manual configuration creeps in because the automation is not run frequently and consistently, leading to a vicious circle. To avoid this spiral, make everything reproducible automatically and consistently run automation. Operational automation combined with good monitoring exposes configuration drift.
Governance
Lightweight Architectural Governance
Lightweight architectural governance aims to balance autonomy and centralized control. More in EDGE: Value-Driven Digital Transformation by Jim Robert Highsmith, Linda Luu, David Robinson and the The Goldilocks zone of lightweight architectural governance Jonny LeRoy talk.
Organizatorium
- Integration points