# Unfurl Cloud Standard Library Overview The [Unfurl Cloud Standard library](https://unfurl.cloud/onecommons/std) is a TOSCA library that provides building blocks and abstractions for deploying applications and services. It allows you to create high-level blueprints that can work in a variety of environments and can easily be combined with other blueprints. If you are familiar with TOSCA or Unfurl, using the Unfurl Cloud Standard library should be straightforward -- it is just a collection of type that you can use when you declare your templates or your own types. If you're not familiar with TOSCA, then take a look at our [application blueprint project template](https://unfurl.cloud/onecommons/project-templates/application-blueprint) for a step-by-step guide for building an application blueprint using this library. The type definitions Unfurl Cloud Standard library provides can be grouped into 3 categories: * Core abstractions Types that provides a minimal set of abstract representations, and relationships, and services. Deriving classes in your blueprint from these types makes it easy for your blueprints to be interoperable with other blueprints. * Common resources and services This includes types that define abstract types for common resources like compute instances and disk volumes and common services such as DNS, popular databases, and mail servers. * Self-hosted and cloud provider implementations These are concrete implementations of the above abstract types including container-based implementations for self-hosting and ones that provision cloud-provider managed services. They are fairly minimal and designed to be easily customized. ## Core concepts TOSCA [node templates](https://docs.unfurl.run/glossary.html#node-template) instantiate instances when they are deployed. A resource refers the external object that TOSCA [instance](https://docs.unfurl.run/glossary.html#instance) is modeling. Resources can be concrete or abstract. A concrete resource corresponds to "real" resource in the external world, whether a virtual resource on a cloud provider or actual physical hardware. An abstract resource does not -- its existence depends other resources. TOSCA defines a "hostedOn" relationship between resources existential -- a resource "lives" on its host resource. Abstract resources will ultimately be hosted on concrete resources, though often through intermediate resources. A **Service** is a resource with one or more endpoints, such as an URL or network port. Services are a key abstraction in Unfurl Cloud Standard library. A blueprint the relies on Services to define the functionality it provides can be deployed on wide variety of architectures. A service may be implemented as a concrete resource (e.g. for example a database service provisioned directly from a cloud provider, like AWS RDS) but it usually an abstract resource. An abstract Service needs a **ServiceHost** that hosts the service. It translates the abstract service's specification so that it can be deployed on an underlying resource, e.g. generating and deploying configuration files. A resource (such as a compute resource) can have an **execution environment** that can alter the state of that resource and other resources in the model. **Artifacts** are representations of data from container images to configuration files. An executable environment can "execute" artifacts which may alter the state and capabilities of the environment. A **cloud provider** is a service that can instantiate concrete resources. An **App** is a user-facing application composed of one or more services. It is typically at the root of a deployment. ## Configuration architecture If you look at the type definitions, you may notice many of the properties and attributes have defaults set to computed values with expressions containing `.configured_on` and `.hosted_on` [keys](https://docs.unfurl.run/expressions.html#special-keys). We use these as part of our design goal of keeping the types loosely-coupled to improve reuse and composability. In TOSCA, there are [properties](https://docs.unfurl.run/glossary.html#properties), which specify configuration values and are immutable, and [attributes](https://docs.unfurl.run/glossary.html#attributes), which are values that reflect the actual state of deployed resource. In a topology where higher-level, more abstract resource types depend on lower-level, more concrete resource types the resulting dependency graph will tend to organize into two inheritance hierarchies. Properties will flow top-down: higher-level components set properties on the lower-level components; while attributes will flow bottoms-up: the attributes of lower-level components will determine the attributes of higher-level components. For example, consider a property like the domain name for an application. That would be set at the high level application resource and its various dependent components such as a DNS service or the application configuration files would rely on that property. But consider the ip address of a compute instance that isn't known until that resource is provisioned -- if there was a service hosted on that compute instance, the service would inherit that ip address. You can express these relationships by declaring declaring requirements with the [unfurl.relationships.Configures](#unfurl.relationships.Configures) and [tosca.relationships.HostedOn](#tosca.relationships.HostedOn) relationships. Unfurl's expression syntax provides two [keys](https://docs.unfurl.run/expressions.html#special-keys), `.configured_on` and `.hosted_on`, for searching along these two axes (Python DSL equivalents functions are [find_configured_by()](https://docs.unfurl.run/api.html#tosca.ToscaType.find_configured_by) and [find_hosted_on()](https://docs.unfurl.run/api.html#tosca.ToscaType.find_hosted_on).) So, following the DNS example above, a type definition that creates an "A" DNS record might set the record's name to `.configured_by::subdomain` and its value to `.hosted_on::public_address`. ## Type Hierarchy These two relationships are used with the core types discussed to above to form the basic patterns that application blueprints using this library follow: [Apps](#std.generic_types.App) configure [Services](#std.generic_types.Service). [Services](#std.generic_types.Service) are hosted on [ServiceHosts](#std.generic_types.ServiceHost). [ServiceHosts](#std.generic_types.ServiceHost) are hosted on [Compute](#std.generic_types.Compute) resources. The [ContainerService](#std.generic_types.ContainerService) subtype of [Service](#std.generic_types.Service) is used for creating services from OCI (Docker) images. It is hosted on a [ContainerHost](#std.generic_types.ContainerHost) of which there are several variants -- in particular, ones such as [HTTPSProxyContainerHost](#std.generic_types.HTTPSProxyContainerHost) which expose a container service via HTTPS proxy that obtaining HTTPS certificates and configures DNS for the service. The library also defines a hierarchy of abstract and concrete subtypes for resources such as compute instances and volumes for a variety of platforms and cloud providers, including Kubernetes, Amazon Web Services, Google Cloud, Microsoft Azure and Digital Ocean. Finally the library provides types for common services such as DNS, mail servers, and databases. For example, there's an abstract PostgresDB service that an application blueprint would use. Deployments of that blueprint would use one of the provided concrete subtypes, such as self-hosted containerized instance or a cloud provider managed service such as Google SQL Storage and Amazon RDS.