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)
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?
