Episode 13: Architectural Patterns

by Imran Kasam & Steve Ledwith

This episode was published on 27 August 2020 and is approximately 54 minutes long. This episode made possible by Glow Your Soul and Anchor.fm.

Overview

This episode is all about architecture, patterns, and a discussion about a contrived example to help explain how we think about things. It’s a great introduction into microservices thinking and when it’s time to formalize your processes.

Listen on Apple Podcasts

Apple Podcasts

Listen on Anchor.fm

Listen on Spotify

Show Notes & Selected Links

Take some time to learn about Architectural patterns.

When do you need to implement standards, patterns, and formality?

  • How do you know you need it?
  • What does the organization look like?

Inflection Point

  • You’ve got the pieces out to your users and now you need to make improvements
  • Maybe you have to add more features faster, and with high quality
  • By paying attention, you’ll see signs that your primary needs have changed
  • This can be an exceptionally subtle change

Unofficial Requirements

  • Listen for things your users and stakeholders are talking about
  • Can you support the future features you’re hearing?
  • Do you have the architecture, infrastructure, and processes?
  • What do you need to do get there?

Is there a specific size?

  • If your company is making more than $1,000,000 a year, is that the time?
  • There’s no set answer … it really does depend

Understanding Your Needs

  • You need to know what you’re trying to accomplish
  • What are the road blocks to progress?
  • Do you have to push releases to avoid conflicts?
  • Do you have multiple teams fighting for time or the same code base?

Do I have to use Microservics?

  • It’s the new hotness!

Should I start with Microservices?

  • If you’re starting something brand new, maybe we want to figure out the process first
  • Once we have a solid process, let’s find where we need to break it down.
  • Spend the time at first, thinking about how the whole process needs to work
  • Avoid premature optimization!

Premature Optimization

How did we get to Microservices?

  • Service Oriented Architecture - SOA!
  • 15 years ago, this was the new hotness. It’s evolved into microservices, and improved thinking about how to interact, and what we need from each other.
“It is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts.”—Domain Driven Design

Domain Driven Design (DDD)

  • It’s a way of looking at the business processes you’re working with, and the code you’re building. The process is the most important part of the equation, and the code needs to support the business needs.
  • The domain, in a business sense, is what an organization does, and the marketplace, or environment it works in.
  • Combines business experts and software engineers together in one team, with the goal of producing software which exactly matches what the business would create if they could do so on their own.
Implementing Domain Driven Design

Onboarding Process Example - 7 Desks in a Room

  • Open the mail
  • Stamp the mail
  • Review application for completeness
  • Process application
  • Process payment
  • Send welcome packet
  • File the application in file cabinet

This is can be thought of as a set of microservices. Each “desk” is part of the process, and each one is dedicated to a specific process.

Event Driven Design

  • According to Wikipedia: Event Driven Design is a programming paradigm in which the flow of the program is determined by events such as user actions (mouse clicks, key presses), sensor outputs, or messages from other programs or threads.

Keep Tracking / Activity in Mind

  • You wouldn’t want to learn from a user or customer there’s a part of your system which isn’t working properly.
  • Think about how you’re going to monitor your services, regardless of the design patterns
Patterns, Principles, and Practices of Domain-Driven Design
“Microservices will make things better when done right. You have to think about the complexity of solution.”—Imran Kasam

N+1 redundancy is a form of resilience that ensures system availability in the event of component failure.

Episode Recap

  • Think about where you need to go. It can take a while to build the architecture you need.
  • Listen for signals from your stakeholders, business, and customers
  • Architecture can be completed in a lot of ways; find the right one
  • Have a plan!
  • Microservices are a great pattern, make sure you understand what each service needs to accomplish

Like, Subscribe, Reach Out.

If you enjoyed this episode, we would greatly appreciate a review on Apple Podcasts. It helps our visibility, and the more people listen, the more we resource we can dedicate to the show. Thank you!