#software architecture
13 posts

Patterns for resilient architecture: Embracing failure at scale

Build your application to be redundant, duplicating components to increase overall availability across multiple availability zones or even regions. To support this, ensure you have a stateless application and perhaps an elastic load balancer to distribute requests.
Read more

Patterns for resilient architecture: Embracing failure at scale

  • Build your application to be redundant, duplicating components to increase overall availability across multiple availability zones or even regions. To support this, ensure you have a stateless application and perhaps an elastic load balancer to distribute requests.
  • Enable auto-scaling not just for AWS services but application auto-scaling for any service built on AWS. Determine your auto-scaling technology by the speed you tolerate - preconfigure custom golden AMIs, avoid running or configuring at startup time, replace configuration scripts with Dockerfiles, or use container platforms like ECS or Lambda functions.
  • Use infrastructure as code for repeatability, knowledge sharing, and history preservation and have an immutable infrastructure with immutable components replaced for every deployment, with no updates on live systems and always starting with a new instance of every resource, with an immutable server pattern.
  • As a stateless service, treat all client requests independently of prior requests and sessions, storing no information in local memory. Share state with any resources within the auto-scaling group using in-memory object caching systems or distributed databases.

Full post here, 10 mins read

7 things you don’t know about agile architecture

Build in feedback loops in every development cycle. Don’t mistake fast initial development for sustainable agility.
Read more

7 things you don’t know about agile architecture

  • Design the project so that introducing changes is not expensive.
  • Don’t spend too much time designing. Start building, learn and progress. Build in feedback loops in every development cycle.
  • Don’t mistake fast initial development for sustainable agility. You want to arrive sooner at the right end product rather than simply going faster.
  • Work in smaller teams, as bigger ones are less flexible and need more communication making them less agile. Know that more people does not guarantee earlier completion.
  • Avoid using speculation on future requirements to add complexity to projects. However, past changes can be clues to future needs, so watch for change hotspots and high defect density.

Full post here, 6 mins read

How to sleep at night having a cloud service: common architecture do's

Have a way of deploying your entire infrastructure as you deploy code. Build a CI/CD pipeline. Configure a load balancer.
Read more

How to sleep at night having a cloud service: common architecture do's

  • Have a way of deploying your entire infrastructure as you deploy code.
  • Build a CI/CD pipeline.
  • Configure a load balancer.
  • Use unique identifiers that allow you to trace a request through its lifecycle, and allows someone to see the entire path of the request in the logs. This is highly useful when things go down.
  • Have a log collection and build searchability in it. This comes in handy when searching for one unexpected log.
  • Have monitoring agents to check if your service is up.
  • Automatic autoscaling based on load is great for being elastic under load.
  • Create a way to test out things with 1% of your users for an hour. It is a good way to deploy changes safely.

Full post here, 7 mins read

9 tips for a painless microservices migration

Document your URL route domains and ensure everyone follows the one convention. Be explicit about routes and methods. Avoid wildcard routes and wildcard verbs or HTTP methods.
Read more

9 tips for a painless microservices migration

  • Draw domain lines to define and document your business entities early on. Be mindful of how you cross the boundaries between these entities.
  • Document your URL route domains and ensure everyone follows the one convention.
  • Be explicit about routes and methods. Avoid wildcard routes and wildcard verbs or HTTP methods.
  • Assign URL endpoint ownership for clean formation of teams in the future.
  • Monitor URL usage by instrumenting the endpoints - at least graph the request rate, if not the error rate and performance of every HTTP endpoint you expose.
  • Kill dead code - delete it, not just comment on it. Have source code control for history, if needed.
  • Document the environment variables a service, class or module uses.

Full post here, 8 mins read

3 easy things to do to make your microservices more resilient

Test your system using chaos strategies. Have a plan to at least partially fulfill your service promise in case of a fault, whether it is a canned message or calling a different service as a backup.
Read more

3 easy things to do to make your microservices more resilient

  • Test your system using chaos strategies.
  • Have a plan to at least partially fulfill your service promise in case of a fault, whether it is a canned message or calling a different service as a backup.
  • Be conservative in what you send to a service and liberal in what you accept. Your unmarshalling logic should do just enough validation of responses and pull out just the data you need rather than executing a full validation.
  • When services fail, multiple iterations of the same message should not add inconsistencies to your users’ systems.
  • Use infrastructure that filters out duplicates. Or, track unique identifiers in the messages and discard those that are already processed successfully.

Full post here, 7 mins read