Component Architecture
The 'component architecture' defines a vocabulary, rules, properties that is used by the component architecture to reason about the model. Components are highly scalable, isolated entities in the model that have a focus on a specific task. Components are composed from a primitive called a 'resource' and components can be integrated by means of these resources. The model also defines 'core' components and 'dynamic' components where 'core' components manage 'dynamic' components.
Components are entities that have a focus on a specific task and are therefore highly specialised. Components do one thing very well, and don't do other things that have nothing to do with the specific task that it does.
For example, a component can have a focus to manage data in context of a domain like 'people'. Its core task is to do CRUD operations on that task and is therefor specialised to do so.
In order to function, a component needs resources. Example resources are 'compute' and 'storage' and can be of any type.
A component is composed of resources. This means that a component is a definition of resources like for example, a group of 'compute', a group of 'storage' of any type.
Components are composed of resources. The component model defines that resources are not exposed to other resources and that by default resources are not available to other components. The resources of a component can optionally be exposed to other components in order to be used by other components.
Components are task oriented, isolated components that by default have no notion of each other. The design states that 'core' components know of 'dynamic' components but not the other way around. This way component can stay highly specialised components with a focus on a specific task that can operate in isolation.
Components can be integrated, and the way to do this is by means of resources. Resources can be of any type that support data transportation for example, an API resource that supports synchronous data transportation.
Components integrate by means of shared resources. Components can make use of resources that are exposed by other components. Components that have a focus on managing data, can expose those resources in order to provide an integration path between components. For example, a component can expose a Kinesis resource that the component manages. Other components can use the Kinesis resource in order to publish or consume from it.
The model defines 'core' and 'dynamic' component where 'core' components manage 'dynamic' components. Core components create and manage the life cycle of 'dynamic' components.
A generic component consists of compute, storage, api and security resources and the model can be extended to use any resources that the component needs to function.
A component consists of 'core' resources compute, storage, api and security.
A Component is a collection of resources. Components can expose resources. Components can also use/consume external resources like a 'kinesis' resource that is exposed by another component.
Multiple components can use/consume exposed resources like eg. a 'kinesis' resource that has been exposed by another component.
In order to function, a component needs an event driven runtime environment, based on resource oriented composable primitives.
sbt-sam, defines event driven, resource oriented components. These components define three APIs:
- Control - (synchronous) - API Gateway
- Notification - (pub/sub) - SNS
- Data Movement - data transport - Kinesis
sbt-sam components define components that are focused on a task, are composed of resources and use core resources: compute, storage, api and security.
An example sbt-sam component is eg. the 'schema repository. The schema repository has a single focus, 'managing schema definitions', it is made of lambda, dynamodb, api-gateway, policy and cognito resources. Such a component is viable within 1..3 days.
To map from a 'component' to an 'sbt-sam' component, the following technical choices have been made:
- Compute: Lambda function implemented by means of a Lambda event handler, tagged by annotation
- Storage: Definition of a storage resource in typesafe config preferred DynamoDB,
- API: API gateway composed of http handlers optionally secured by cognito by means of user pools
- Security: Resource security by means of roles and policies, and API security by means of Cognito
- Imports: Resource imports by means of CloudFormation Arn resource exports either on typesafe config resource or annotated event handler,
- Exports: Exports by means of typesafe config by means of attribute of a resource using CloudFormation output.
- Supported non-core resources: S3, Kinesis, SNS, Schedule, by means of typesafe config or annotated event handler.
The component model translates to the reference 'schema repo' component as follows:
- Compute: Http Handler Lambda annotated with API resource,
- Storage: DynamoDB single table with key/value and JSON payload
- API: Http Handler per path per method
- Security: AWS Managed resource policies and Cognito userpool with 'SRP' and authorized users and clientId
- Imports: None
- Exports: None
