practical use case of software architecture evolution

Abstract

The speaker presents multiple types of architectures:

  • layered architecture
    • cons
      • Without careful design, there’s a risk of tightly coupling layers to external dependencies.
      • In general, enforcing strict layering rules adds unnecessary complexity to the call chains. A relaxed layered architecture is preferable.
  • hexagonal architecture
    • When to use a hexagonal architecture?
      • In the case of application involving multiple external integration.
      • In the case of applications with complex business logic or domain models.
    • When NOT to use a hexagonal architecture?
      • For an application with a simple business domain (e.g. CRUD application) or even without a (real) defined domain, and minimal or no integrations, as it would bring unnecessary complexity.
      • Not ideal for prototyping. More suited for long-run architectures.
  • microservice architecture
    • Key benefits of microservice architecture:
      • Easier workload distribution across teams.
      • Faster and independent development.
      • Improved data segregation and governance.
      • Service adhering to DDD could create a highly decoupled architecture.
      • Enhanced scalability and availability of individual services.
    • Before adopting the microservice style, make sure the infrastructure is ready to support it.
      • Code, CI/CD, runtime env.
      • Distributed architectures impose other challenges such as monitoring, aggregated logging, tracing, etc…
    • When NOT to use microservice?
      • A few domains with limited capabilities might benefit more from a modular monolith.
      • Few users or requests may not justify the overload of multiple microservices.
      • Tight data coupling makes it challenging to segregate across distributed services.
      • High networking overhead can hinder efficient data movement.
      • Enhancing modularity within an existing monolith or optimizing its components might be preferable before transitioning to microservice.
  • event-driven architecture
    • Key benefits of event-driven architecture:
      • Enables asynchronous communication between components.
      • Message queues facilitate effective workload handling, improving system responsiveness during load fluctuations.
      • Loosely coupled relationships between producers and consumers services.
    • Cons:
      • Increased complexity, use EDA only in the critical parts of the system where it is really needed.
      • Understanding and extending the overall flow of events in larger systems and their relationships requires more time.
  • serverless architecture
    • Key benefits
      • FaaS is a cost optimization model (“pay as you go” model).
      • Managing the underlying infrastructure is entirely the responsibility of the cloud provider.
    • Cons:
      • Execution and memory limits (e.g. 15m and 10 240MB limit in AWS Lambda).
      • serverless decreases the compute cost but increases the networking communication costs.
      • The cold start-up time of FaaS may introduce slight execution delays compared to an already initialized long-running service.

Reviews

2024-08-13

Why did I want to read/watch this? There are lots of architecture types out there. Some more popular than others. It’s always a good idea to either refresh my memory about those architectures or learn new ones in order to know when and how to apply them in projects.

What did I get out of it? I have already some knowledge on all the architectures the speaker presented. But it’s good to refresh the knowledge in order to move them to my long-term memory.