Patterns – High Availability for Application Architecture Design

Things to keep in Mind

  • This list is a starting point for those who seek to learn about High Availability Architecture Design
  • It is a work in progress and it may get updated from time to time
  • In some places are it is very high level. There are design patterns that are not mentioned here that may fall within another pattern mentioned here. For example, “queues” could fall under the “PUBLISH/SUBSCRIBE” pattern.

1 – Concepts

  • Redundancy
  • Horizontal Auto-scalling
  • Infrastructure as Code
  • Caching
  • Sharding
  • Idempotent Operations
  • Eventual Consistency

2 – Application Implementation

  • Stateless Applications / Web Tier
  • Backend / FrontEnd
  • Publish / Subscribe
  • Micro Services
  • Content Delivery Networks (CDN)
  • Command and Query Responsibility Segregation (CQRS)
  • Event Sourcing
  • Sidecar
  • Strangler

3 – Application Failure Handling

  • Single Point of Failure (Anti-pattern)
  • Timeouts
  • Intermittent and transient errors
  • Circuit Breaking
  • Service degradation & fallbacks
  • Backoff Algorithms
  • Rejection

4 – Operations

  • System Monitoring
  • Immutable Infrastructure
  • Database Replication
  • Distributed Tracing
  • Multiple Data Centers

Effective Rule #19 – Do the right thing, and do it right

Tenets

  • Doing the right thing is being effective
  • Doing things with minimal energy is being efficient
  • Being effective is better than being efficient, as doing the right thing slowly is always better than doing the wrong thing quickly

Rules of Thumb

  • Have a great product or service, as a slightly better product is not good enough
  • Follow through with excellence

“Just that you do the right thing. The rest doesn’t matter.”

Marcus Aurelius

“Nothing is less productive than to make more efficient what should not be done at all.”

Peter Drucker

Effective Rule #8 – Deliberately Develop and Polish a Core Set of Mindsets

mindset – “a mental attitude or inclination”

Merriam-Webster Dictionary

Tenets on Mindset

  • Mindsets are part of the core of our human operating system
  • They give color to how we view the world
  • They influence heavily all of our unconscious daily habits
    • They influence the decisions we make unconsciously
  • Not all are created equal, for example,
    • some are empowering, and
    • others are debilitating
  • Mindsets can be changed, optimized
  • By deliberately developing and polishing our mindsets our habits will change for the better

Rule of Thumb

  • The more you become aware of your mindsets, the more deliberate influence you have over your thoughts, feelings and actions.

We take our mindsets and habits for granted. In fact, those who have never thought about having mindsets operate on mindsets given to them.

“Nobody is born a warrior in exactly the same way that no one is born an average man”

Carlos Castaneda

Effective Rule #10 – Work Your Butt Off

Rule of Thumbs

  • Work a lot, spend a little, invest the difference
  • Have a high pain threshold, don’t start counting the reps until it hurts
  • Invest your money on growth not comfort
  • There is no shortcut to success

“Don’t wish it was easier, wish you were better. Don’t wish for less problems, wish for more skills. Don’t wish for less challenge, wish for more wisdom.”

Jim Rohn

Tenets

  • If you want something you have to be relentless
  • 1 hour a day compounds
  • Most things are more rewarding when you break a sweat to get them (M.M.)
  • “You’re growing or dying” , therefore, focus on growth

“To get what you want, you have to deserve what you want. The world is not yet a crazy enough place to reward a whole bunch of undeserving people.”

Charlie Munger

Beware

  • When working hard, happiness will steadily decline for those that do not take care of themselves accordingly.

Effective Rule #11 – Treat Time with Utmost Respect

Be aware of the productive time you waste

Tenets

  • Time is our most important resource
  • You cannot make more time
  • Time is worth more than money or going to work
  • We tend to waste a lot of time of the day

Rules of Thumb

  • Calculate a dollar per hour value for each of your “productive” hours
  • Ask yourself, “was this last hour well spent”, “would I have payed someone for this hour”, if the answer is “no”, then we know we can do better

“Understand that your time has a limit set to it. Use it, then to advance your enlightenment; or it will be gone, and never in your power again.”

Marcus Aurelius

“The only difference between a rich person and poor person is how they use their time.”

Kiyosaki

“You act like mortals in all that you fear, and like immortals in all that you desire”

Seneca

Are you a solid web engineer? Ask yourself these questions.

This is a question we never asked ourselves because the answer to us is obvious.

In my career I have met 4 types of developers:

  • The Overconfident Hotshot
  • The Uninitiated Newbie
  • The Aimless Developer
  • The Solid Engineer (less often)

The easiest to work with by far is the Solid Engineer. The one that can own a task, works well with others, and everyone is confident the task will not only get done, but it will get done with the highest quality and best time frame possible.

Most of the developers I have work with fall into the Aimless Developer category (myself included at some points in my life). These developers may be good, and in many cases effective, but they generally go through their work with unintentional focus. They treat work as just a job.

I have found that the best way to enjoy any work is to approach it with the following mindset.

“There is always room for improvement”.

This is true for all aspects of life not just web development. When we see ourselves improving it puts us in the state of joy, adding meaning to our lives.

Therefore, when I am working on a project or managing other engineers, these are the questions that I ask myself and of others to assess if I am a Solid Engineer.

Understanding of Context

By context I am referring to: Project goals, Project Process, System Architecture/Frameworks. A Solid Engineer has a good grasp of these 3 within any project. Before a developer starts working, they should have a solid understanding of these 3 aspects in relation to their work.

  • How does my work directly affects the project?
  • Am I following the project process/development guidelines?
  • Do I know the mechanics of the architecture framework?
  • Am I skill enough to work with this technology?
  • Can I offer suggestions on how it can be improved?

Serviceable Code / Maintainability

Well written code offers value in production for years because it is easily maintainable. For this to happen it needs to be easy to understand so that a different future engineer is able to fix and support the code without having to rewrite it. Note: This last point is a hard thing to do, as it is a well known tendency for engineers to think that they can write code better than what was written already.

  • Is my code easy to understand?
    • Legibility over cleverness
    • If the code is easy to understand chances are the developer had a good understanding of what needed to be done.
  • Can it be easily maintained? Simplicity over complexity
  • Is it well documented? Yes, we should write code that self documents, but it helps when we add effective notes that makes it easier to read.

Motivation

Solid Engineers appear to be self powered.

  • What motivates me? Do I have intrinsic motivation?
  • Do I make time learn?

Ownership

A Solid Engineer assumes total responsibility of scope of work and understand that if it does not get done it is their fault.

  • Do I understand the definition of DONE for the task at hand?
  • Do I take full responsibility for the work that needs to be done?
  • Am I willing to accept faults?
  • Do I seek to understand the requirements when I think they are incomplete?
  • Do I expect others to test my code?
  • Am I happy with others looking at my code?
  • Have I asked for any feedback?

Teamwork

A mark of a Solid Engineer knows when to ask for help.

  • Do I seek help from others, or do I seek to be the hero?
  • Do I own too much code?
  • Do I think I can write code better than anyone in the team?
  • Am I setting proactive expectations with others, especially when things are not going well?

Effectiveness / Value

A Solid Engineer focuses on doing the right thing well, instead of doing the wrong thing efficiently.

  • Am I working on the right thing?
  • Do I know what is the 20% of the work that will bring 80% of the value?
  • Do I time-box my tasks in order to minimize time wasted?

Professional Maturity

A Solid Engineer reflects on each experience and seeks to grow in maturity.

  • Do I boasts my own code is always the best?
  • Do I think that I am irreplaceable?
  • Do I take feedback well?
  • Do I often write code that is too complex?
  • Do I say yes to everything that is asked of me without question?
  • Do I make giant commits?

Keep It Super Simple (KISS)

Gist

  • The simpler a task is the more likely the task will get done correctly
  • The more complex a task is the less likely it will get done correctly

Challenges

  • It sounds obvious, therefore, very often this rule is ignored
  • How do you know a task is simple as opposed to being complex? These questions usually help,
    • Skill – Can the task be done by an Advanced Beginner or does it require and Expert?
    • Duration – Will the task take a long time?
    • Domain – Does the task expand beyond multiple disciplines / dimensions of knowledge?
    • Management – How many people are required?

Note to Self

  • If you think this is too obvious and take this rule for granted, then you probably deal in too much complexity
  • There is always room to simplify

Setting Expectations
a tool for clear communication

The Gist

  • Setting expectations with others is one of the most effective tools of getting things done,
  • These do not need to be inflexible, as
  • They represent points of reference,
  • Help create an agreement between individuals, an
  • Bring balance to relationships.

These can be used in may types of agreements.

  • Timelines
  • Actions
  • Effort / Scope of Work

Why does this matter

Failing to set proper expectations, or any kind of expectations results in frictions with others. Therefore, in the workplace, they are essential.

In personal relationships, expectations are mostly implicit, and not every expectation needs to be made explicit, but some can definitely benefit from naming these out.

Setting effective expectations

Setting expectations is a habit, and setting effective expectations requires deliberate practice.

It is one of the hardest skills any leader or partner

It is probably one of the hardest skills to cultivate.

Being Effective vs Being Efficient

The Gist

  • Effectiveness and Efficiency are two different things
  • Efficiency is to accomplish a task with minimal use of energy
  • Effectively is to accomplish the right task

Why is this important

It is better to accomplish the right task slowly, than to accomplish the wrong task quickly.

‘Truly fast, repeatable actions must be smooth, but you cannot perform a smooth action fast if you cannot first perform a slow action smoothly.’

Peter Stecher