A quick summary of software architecture courses, it includes books recommended in the courses. Software architecture is important since it is across any software project. The sooner you know the concepts the better you will understand some decisions made in the project you are or will work on.

Introduction

• You must start by understanding the problem you are solving.
• Ensure you are delivering value (enable team).
• Work directly with development teams (they work on the project from a different perspective).
• Work on outages and issues.

Context

• Software Architect’s elevator
  • Being able to communicate with technical and non-technical people.
• Change can be unsettling, but it’s also a sign of growth.
• Fitness functions: Functions to test your architectural characteristics.

Architecture Styles

• Monoliths
  • Simple, small applications, MVP.
• Layered Architecture
  • Most common.
• Hexagonal Architecture
• Service Oriented Architecture
  • Rare to share functionality across applications.
• Microservices
  • Team superheros.
  • Best for small and independent services.
• Macroservices
• Event Driven Architecture
  • Shout out event, listen to the response.

Fallacies of Distributed Computing (4/8)

• The network is reliable
• Latency is zero
• Bandwidth is infinite
• The network is secure

Microservices

• what are you hoping to achieve?
• have you considered alternatives?
• how will you define success?

Service Oriented Architecture vs Microservices

• Microservices have smaller parts to be deployed than SOA

Microservices benefits

• Teams working independently
• Reduce time to market
• Increase robustness
• Embrace new technology

Event Driven Architecture

• Header/Metadata
• Body/Payload
• Types of messages chanel
  • Queue
  • Event Bus (published/subscribe)

Thinking Serverless First

• Why am I doing this, when a cloud provider could do it for me?
• Provide value to the customer and let the rest to the cloud provider

Conway’s Law

• Organizations tend to create systems that mirror their own team and communication structures.
• Align your architecture to your organization or align your organization to your intended architecture – Reverse Conway Manuever.

Ocams Razor – Keept It Simple Stupid

• The simplest explanation is often the best one.

Postel’s Law

• Be liberal in what you receive and conservative in what you send.

Design Patterns

• Provide a proven solution to a common problem.
• Think patterns first, not specific services or implementations.
  • Allows people to understand your architectural intentions.
• It is a bad idea to start domain model first, API second.
  • Exposes domain model to the outside world.

API design first

• Allows independent work.
• Requires communication between teams.
• Point to point integration
  • Message driven communication between two systems
    • Stream
      • allows to process data in real time
    • Batch processing
      • process run on a schedule

Scaling Systems

• Load balancing
  • Round Robin
    • Requests distributed evenly across instances.
  • Least Connection
    • Distributes requests to the server with less connections.
  • Hashing Algorithm
    • Distributes based on the incoming request.
      • IP hash
• Scaling
  • Horizontal
    • Adds more instances of compute.
  • Vertical
    • Increases resources of a single piece of compute.

Caching

• Store data in a temporary location where it can be read quickly.
• Faster responses per requests means more requests can be processed.
• Useful
  • Read Heavy Workloads
  • Tolerate Stale Data
• Types
  • Read Through Cache
  • Write Ahead
• Cache Hit: Record is found in the cache.
• Cache Miss: Cache is checked and data isn’t there.
• Ideal is to have more cache hits than misses.

Integration Styles

• File Transfer
• Shared Database
  • Monoliths typically do this as default.
  • It’s hard to determine a shared schema that suits all parties.
• Remote Procedure Call
  • REST, etc.
  • Often seen with service oriented architecture.
• Message Based Communication
  • Lower coupling & higher cohesion.
  • All integration is asynchronous.
  • Asynchronous communication can make it difficult to determine cause and effect.
  • Use publish subscribe to communicate between business domains or teams.
    • Message Bus, for example.
  • Point to point: A → B (stream or queue).
  • Publisher/subscriber A → many.

Architect for failure

• It’s not the boxes you need to worry about on an architecture diagram, it’s the lines.
• Retry (exponentially).
• Circuit breaker.
• Carefully consider your integration points.

Documentation

• Good documentation will save you from future headaches
• Architecture Decision Records
  • Keeps track of all the reasons behind every architectural decision
  • https://github.com/joelparkerhenderson/architecture-decision-record
  • ADR’s should be inmmutable
  • Context provide reference points
  • Context mapping shows the communication patterns between teams
• Importance of interoperability
  • Embrace standards and protocols that are common and open
  • Design user friendly API’s well-documented and versioned
  • Consider data formats
  • Regular test systems interactions, schemas and integrations
• Fitness Function: provides an objective integrity assessment of some architectural characteristic
• Human-Central Architecture: human focus
  • Stakeholders
    • Users the system is for
    • Business Stakeholders
    • Developers
    • Wider human population

Recommended books

• The Software Architect Elevator, George Hohpe.
• Building Microservices, Sam Newman.
• Monolith to Microservices, Sam Newman.
• Team Topologies, Mattew Skelton.
• Enterprise Integration Patterns, John Capri.
• Designing Data-Intensive Applications, Martin Kleppmann.
• Building Evolutionary Architectures, Neal Ford.

Referenced courses

• https://dometrain.com/course/getting-started-solution-architecture