Co-Founder Taliferro
Introduction
This architectural cheat sheet guides architects who are attempting to architect a system. A Technical Architecture is the layer of system software and extensions upon which an application are built. Architecture is broken down into development, execution, and operations.
This cheat sheet focuses on Execution Architecture primarily as it relates to the physical architecture, code management, and build processes.
Architecture will be a combination of Development processes and runtime support as defined by the company's System Management team. Architectural considerations are:
- Summary of the Application
- An overview of how specific architectural issues are handled
- Guidelines for selecting a specific technical approach where alternatives exist
Architecture Principle Context
- Time-based
- Granularity
- Don't break subscribers
- Horizontal data growth
- Decoupling
- State rebuild
- Temporal queries
- Data consistency
- Serve only data needed by client
- Data availability
- Materialized View Pattern
- Circuit Breaker Pattern
- API Gateway
Logical Architecture
A diagram should indicate the critical capabilities of an Application Architecture. These capabilities determine what applications are necessary to deliver on the business vision. This consists of a summary of the types and numbers of assets, data requirements, asset characteristics, and so on, for each Application.
A middleware layer describes the various mechanisms by which consumers access data.
The Data layer can be described separately as part of the Data Architecture or as part of the application architecture.
The discussion of the Data Architecture should include a description of the enterprise data access methods, direct and replicated local data access methods, and guidelines regarding data location.
An integration plan provides the data access method used.
Single Page Application Considerations
Typically, best practice development in the SPA world aligns with an aggregate approach instead of a series of rows. The consequence of querying a row/series in a SPA application has a negative effect because the query only needs a subset of data from some entities, such as a summary of services for several microservices without all of the service details. If the SPA must extract all of the data for the relevant entities to obtain the required information, it will negatively impact the user experience. A best practice for SPA applications is to generate, in advance, a view that materializes the data in a format suited to the required component.
The view should only contain the data required by a particular SPA component. Materialized views can include values from calculations or other data items. You can even optimize the materialized view for just a single query. If the source changes, the view can be updated to include the new information automatically via a cloud function/database trigger.
State and Session Context Management
Context management refers to storing and retrieving information entered by the user across a sequence of screen exchanges or page submissions. Specifically, provide facilities that enable an application programmer to :
- Store data to be displayed on the user's screen
- Retrieve user input
- Store temporary data that should persist across screens
Consider a context framework that gives developers access to context through a single interface. Examples of context components are:
- Client side state component. This component stores the temporary state in an HTML cookie on the client. The component is rebuilt at each request. The component is stateless and is suitable for applications with high scalability requirements. It is unsuitable if a large amount of temporary data is stored.
- Temporary data store state component. This component uses stores the temporary state data in the cloud.
- In-memory state component. A component stores the temporary state in the cloud's memory. The component must be stateful between user pages, and so it is stored in a session object. This component is unsuitable if the Application requires a high level of scalability since the cloud stores the user information, and subsequent client requests must be directed at the same Application.
Environments
A project's technical architecture can comprise multiple environments. These environments are usually integration, staging, and production. Staging is not an active environment but is designed to mirror the production environment and assume its activities for real-world testing.
The cloud provides redundancy and failover capabilities through a configuration setup. An architecture should empower developers to assemble new business applications that combine functionality from multiple systems. A well-architected system should meet the challenges of:
- Availability
- Data Management
- Management and Monitoring
- Performance and Scalability
- Resiliency
- Security
The Virtual Network
Establish a virtual network to handle middleware execution and resource retrieval. All the resources communicate outbound to the internet and inbound with cloud components.
Data Private Subnet
Within the virtual network, there can be a dedicated data subnet. The advantage to breaking the data and app environment up into a subnet is that the subnet allows the division of one network into logical subnetworks, separating data duties from middleware and web resource duties.
App Environment Subnet
An app environment subnet is responsible for all business logic, web service, and resource access.
Active Directory
If utilizing Active Directory, a component can serve as an identity management service and filter applications' access by enforcing security rules. In addition, the AD service can facilitate Single Sign On (SSO).
Network Security Groups (NSG)
NSGs filter network traffic to and from resources in a virtual network.
Data Factory
A Data Factory will issue custom commands to extract data from external sources.
Data Lake
A Data Lake can work in conjunction with a storage blob for data that is structured, imported through a batch process, and used for streaming analytics and machine learning.
Data Store
DSs can be used as a repository for big data analytics workflow, either unstructured, semi-structured, or structured data. Automatically replicates for unexpected hardware failures and has unlimited size and no limits to scale.
Backup Vault
Works as a cloud-to-cloud implementation where cloud-based VMs and data can be backed-up to the Backup Vault without disrupting services.
Virtual Machine
Virtual machines can act as gateways to extract data from external data stores.
Data Bricks
It can provide the service necessary to harness all the data collected and apply data science to the acquired data.
Storage Blob
If there is data extraction from many systems, the data can grow exponentially. The data is possibly unstructured, or the information is in a binary format. A blob stores the data and can be used for analysis by other services.
Machine Learning Workspaces
Data scientists use the machine learning workspace to conduct experiments on the data.
SQL database
Use an SQL database to create custom data tables, enforce referential integrity, and run necessary stored procedures to generate the data for UI needs.
WebApp
The only difference between the WepApp and an API App is that the WebApp does not contain a defined interface. The WepApp is usually the nodejs portion of a project.
API App
The middleware (with interfaces) contains the business logic that returns the data.
Security Management
The purpose of the Security Approach is to provide a consistent infrastructure for ensuring that only authorized users can access web services and that those users can only access the data pertinent to their function.
CI / CD considerations
- Define and agree on release and deployment with customers/stakeholders
- Ensure the release consists of related assets and compatible service components
- Ensure integrity of release and its components
- Ensure release is recorded accurately in the configuration management system
- Ensure release is tracked, installed, tested, verified, and uninstalled or backed out
- Manage change during release and deployment
- Address deviations, risks, and issues related to new features or changes
- Ensure a process for knowledge transfer optimizes and supports business activities
- Ensure skills and knowledge are transferred to operations and support staff
Testing Considerations
Code is stamped and frozen, and this code version is pushed to an integration environment where all code is tested as a single unit. Once bugs are fixed, each team pushes the revised code to the source control repository. The code is stamped with a minor version change and moved to the integration server.
If there are no bugs, the release manager reviews the results with the product owner, then pushes the code to a staging server.
A QA team performs quality acceptance testing on the code, testing for bugs, performance, and user story match. The QA team sends a bug report (if applicable) back to the development team for bug fixes. Each development team reviews the QA report and fixes bugs found in staging.
Tyrone Showers