In summary, both .cer and .pfx/p12 files serve different purposes in a PKI system. A .cer file is only used to verify the identity of a server or other entity and contains public key data, while a .pfx/.p12 file includes both private key and one or more certificates, allowing for two-way authentication when establishing secure connections.

1. MUST
   This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.

2. MUST NOT This phrase, or the phrase “SHALL NOT”, mean that the definition is an absolute prohibition of the specification.

3. SHOULD
   This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

4. SHOULD NOT
   This phrase, or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

5. MAY
   This word, or the adjective “OPTIONAL”, mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

names = ['Alice', 'Bob', 'Dilbert']

When a new item is added to the list and committed to a source control like git, the file diff will highlight the entire line as a difference between the commits instead of just the newly added item(s).

names = ['Alice', 'Bob', 'Dilbert', 'Roger']

Way(s) to solve this:

1. Write each list item into its own lines

names = [
    'Alice', 
    'Bob', 
    'Dilbert', # ◀️ gets highlighted because of an additional comma 
    'Roger'    # ◀️ gets highlighted
    ]

Because the git diff is a line based tool, it now highlights the difference on Last 2 Items of the list (notice the , was added next to Dilbert)

1. Even to further alleviate this problem, always end the last item on a list with a comma(,)

names = [
    'Alice', 
    'Bob', 
    'Dilbert',
    'Roger', # ◀️ note an additional comma here
    ]

Orchestration is the coordination of multiple services through the use of a separate mediator service that controls and manages the workflow of the transaction (like a conductor in an orchestra).

Choreography, on the other hand, is the coordination of multiple services by which each service talks to one another without the use of a central mediator (like dancers in a dance).

As services become more fine-grained, both orchestration and choreography are necessary to tie the services together to complete the business transaction.

Additional Resources: https://cloud.google.com/blog/topics/developers-practitioners/service-orchestration-google-cloud

The concept of an “architecture sinkhole” refers to the practice of designing software or systems in such a way that they consume significant resources while providing limited benefits or value.

It can be described as a structure that does not perform its intended function well and instead creates a waste of time, money, or energy.

In software development, architecture sinkholes can occur when developers design systems with complex, over-engineered architectures that are difficult to maintain or modify. These architectures often require extensive resources, such as human expertise, time, and financial investment, but they may not provide any significant benefits to the organization or end-users.

Another type of architecture sinkhole is when a system fails to meet its intended requirements or goals, resulting in wasted effort, time, and money. This can happen for a variety of reasons, including poor design, faulty implementation, or inadequate resources.

Overall, an architecture sinkhole refers to any situation where a software or systems design fails to deliver the expected results or value, causing waste and inefficiency.

Example:

In an N-layered architecture, when a request passes from the User Interface (UI) layer directly to the Persistent Layer without incorporating any business rules in either the Business or Service Layers, the purpose of these layers during that request cycle is merely to create objects. This can result in unnecessary memory usage as objects are created but not utilized beyond their creation process.

UI-Layer ➡️ Business-Layer ➡️ Service-Layer ➡️ Database

What tradeoffs to consider:

Maintain an oversight of your N-layered architecture to ensure that no more than 20% of your endpoints have sinkholes. If this percentage exceeds, consider a strategic reconfiguration of your architecture.

1. Software Architecture is dynamic, is a tradeoff and is an iterative process.
2. Architecture cannot be done at the beginning of an initiative and cannot expect it to remain constant during the development process.
3. New changes keeps coming and architecture should incorporate those changes and keep evolving while considering tradeoffs.