1. Do the cloud impact our architecture?
1.1. Cost
1.2. Scale
1.3. Business Model
1.3.1. Services
1.4. DevOps
1.4.1. Infrastructure as code
1.4.2. CI -> CD
1.4.3. IaaS - PaaS - ?aaS
1.5. Security
1.6. Infinite
1.6.1. Data
1.6.1.1. Denormalization
1.6.2. Compute
1.7. Latency
2. Hi
2.1. Xenix
3. Simple architecture
4. Pattern
4.1. Federated Identity Pattern
4.1.1. Delegate authentication to an external identity provider. This pattern can simplify development, minimize the requirement for user administration, and improve the user experience of the application.
4.1.2. When to Use this Pattern
4.1.2.1. Single sign on in the enterprise
4.1.2.2. Federated identity with multiple partners
4.1.2.3. Federated identity in SaaS applications
4.1.2.4. NOT: All users of the application can be authenticated by one identity provider, and there is no requirement to authenticate using any other identity provider. This is typical in business applications that use only a corporate directory for authentication, and access to this directory is available in the application directly, by using a VPN, or (in a cloud-hosted scenario) through a virtual network connection between the on-premises directory and the application.
4.1.2.5. NOT: The application was originally built using a different authentication mechanism, perhaps with custom user stores, or does not have the capability to handle the negotiation standards used by claims-based technologies. Retrofitting claims-based authentication and access control into existing applications can be complex, and may not be cost effective.
4.1.3. Related Patterns and Guidance
4.2. Circut Breaker Pattern
4.2.1. Resiliency is the ability of a system to gracefully handle and recover from failures. The nature of cloud hosting, where applications are often multi-tenant, use shared platform services, compete for resources and bandwidth, communicate over the Internet, and run on commodity hardware means there is an increased likelihood that both transient and more permanent faults will arise. Detecting failures, and recovering quickly and efficiently, is necessary to maintain resiliency.
4.2.2. When to Use this Pattern
4.2.2.1. To prevent an application from attempting to invoke a remote service or access a shared resource if this operation is highly likely to fail.
4.2.2.2. NOT: For handling access to local private resources in an application, such as in-memory data structure. In this environment, using a circuit breaker would simply add overhead to your system.
4.2.2.3. NOT: As a substitute for handling exceptions in the business logic of your applications.
4.2.3. Related Patterns and Guidance
4.2.3.1. Retry Pattern
4.2.3.2. Health Endpoint Monitoring Pattern
4.3. Queue-based Load Leveling Pattern
4.3.1. Use a queue that acts as a buffer between a task and a service that it invokes in order to smooth intermittent heavy loads that may otherwise cause the service to fail or the task to time out. This pattern can help to minimize the impact of peaks in demand on availability and responsiveness for both the task and the service.
4.3.2. When to Use this Pattern
4.3.2.1. This pattern is ideally suited to any type of application that uses services that may be subject to overloading.
4.3.2.2. NOT: This pattern might not be suitable if the application expects a response from the service with minimal latency.
4.3.3. Related Patterns and Guidance
4.3.3.1. Asynchronous Messaging Primer
4.3.3.2. Competing Consumer Pattern
4.3.3.3. Throttling Pattern
4.4. Sharding Pattern
4.4.1. Divide a data store into a set of horizontal partitions or shards. This pattern can improve scalability when storing and accessing large volumes of data.
4.4.2. When to Use this Pattern
4.4.2.1. When a data store is likely to need to scale beyond the limits of the resources available to a single storage node.
4.4.2.2. To improve performance by reducing contention in a data store.
4.4.3. Related Patterns and Guidance
4.4.3.1. Data Consistency Primer
4.4.3.2. Data Partitioning Guidance
4.4.3.3. Index Table Pattern
4.4.3.4. Materialized View Pattern
4.5. Event Sourcing Pattern
4.5.1. Use an append-only store to record the full series of events that describe actions taken on data in a domain, rather than storing just the current state, so that the store can be used to materialize the domain objects. This pattern can simplify tasks in complex domains by avoiding the requirement to synchronize the data model and the business domain; improve performance, scalability, and responsiveness; provide consistency for transactional data; and maintain full audit trails and history that may enable compensating actions.
4.5.2. When to Use this Pattern
4.5.2.1. When you want to capture “intent,” “purpose,” or “reason” in the data. For example, changes to a customer entity may be captured as a series of specific event types such as Moved home, Closed account, or Deceased.
4.5.2.2. When it is vital to minimize or completely avoid the occurrence of conflicting updates to data.
4.5.2.3. When you want to record events that occur, and be able to replay them to restore the state of a system; use them to roll back changes to a system; or simply as a history and audit log. For example, when a task involves multiple steps you may need to execute actions to revert updates and then replay some steps to bring the data back into a consistent state.
4.5.2.4. When using events is a natural feature of the operation of the application, and requires little additional development or implementation effort.
4.5.2.5. When you need to decouple the process of inputting or updating data from the tasks required to apply these actions. This may be to improve UI performance, or to distribute events to other listeners such as other applications or services that must take some action when the events occur. An example would be integrating a payroll system with an expenses submission website so that events raised by the event store in response to data updates made in the expenses submission website are consumed by both the website and the payroll system.
4.5.2.6. When you want flexibility to be able to change the format of materialized models and entity data if requirements change, or—when used in conjunction with CQRS—you need to adapt a read model or the views that expose the data.
4.5.2.7. When used in conjunction with CQRS, and eventual consistency is acceptable while a read model is updated or, alternatively, the performance impact incurred in rehydrating entities and data from an event stream is acceptable.
4.5.2.8. NOT: Small or simple domains, systems that have little or no business logic, or non-domain systems that naturally work well with traditional CRUD data management mechanisms.
4.5.2.9. NOT: Systems where consistency and real-time updates to the views of the data are required.
4.5.2.10. NOT: Systems where audit trails, history, and capabilities to roll back and replay actions are not required.
4.5.2.11. NOT: Systems where there is only a very low occurrence of conflicting updates to the underlying data. For example, systems that predominantly add data rather than updating it.
4.5.3. Related Patterns and Guidance
4.5.3.1. Command and Query Responsibility Segregation (CQRS) Pattern
4.5.3.2. Materlialized View Pattern
4.5.3.3. Compensation Transaction Pattern
4.5.3.4. Data Consistency Primer
4.5.3.5. Data Partitioning Guidance