Software Architecture Books Summary And Highlights -- Part 6 Reliability

 

Reliability

Highlights

Distributed Database eventual consistency pattern

1. Background sync process to sync different service’s databases.
   1. Cons: break bounded context among dbs. Because background process also has access to many dbs
   2. Suitable when there is no other communication among related services
2. orchestration
   1. Pros: Atomic business request
   2. Cons: Slower responsiveness
3. event based: Sync through events
   1. pros: Fast responsiveness
   2. Cons: Complex error handling

SAH Ch 9 Data Ownership and Distributed Transactions

Distributed Transactions

the various patterns used to implement distributed transactionality (such as compensating transactions) succumb to a wide variety of failure modes and boundary conditions, along with adding inherent complexity via undo operations. Distributed transactions present a host of difficulties and thus are best avoided if possible.

SAH Ch 12 Transactional Sagas

Transaction

distributed transactions are hard to get right and can actually inhibit scaling.

Systems that eventually converge through compensating retry logic can be harder to reason about, and may need other compensating behavior to fix up inconsistencies in data.

So first think hard about if your business operation could accept eventual consistency. If it really needs strong consistency, think hard if you really need to break the related services apart.

MSV Ch 5 Splitting the monolith

Synthetic Monitoring

Create a fake event input for the system to test production system. We used this synthetic transaction to ensure the system was behaving semantically, which is why this technique is often called semantic monitoring.

MSV Ch 8 Monitoring

Global ID tracking

Use a global id to track all related service logs. Populate the global id using a thin client lib so that it is easy to integrate into every service.

MSV Ch 8 Monitoring

Cascade failures: Each service instance should track and expose the health of its downstream dependencies, from the database to other collaborating services

MSV Ch 8 Monitoring

Standardized Monitoring

You should standardize your monitoring implementation across all your services.

• for each service
  • track response time, error rate, downstream api response time, standardize log collection, log location, monitoring operating system
• for the system
  • aggregation, tool capability , correlation ids, when to fire alert, what is needed in dashboard, if to use existing tool

MSV Ch 8 Monitoring

Security measure: CIA

• Confidentiality is the property that data or services are protected from unauthorized access.
• Integrity is the property that data or services are not subject to unauthorized manipulation.
• Availability is the property that the system will be available for legitimate use.

SAP Ch 11 Security

Signon approach

single signon (SSO) solution:

1. SAML (SOAP based)
2. OpenId connect (from Google) Rest based

A directory service could be something like the Lightweight Directory Access Protocol (LDAP) or Active Directory. These systems allow you to store information about principals, such as what roles they play in the organization.

use a gateway to centralize the behavior for redirecting the user and perform the handshake in only one place.

Gateway downside:

1. Downstream service still need to handle principals correctly
2. hard to provide production like auth environment for one service’s developer to test
3. developer may rely too much on gateway and neglect their own responsibility for security feature

MSV Ch 9 Security

Favor fine grained authorization with multiple roles. Control each role’s access in each service instead of in gateway

MSV Ch 9 Security

Service to Service Authentication and Authorization

1. Allow Everything Inside the Perimeter
   1. Cons: if an attacker penetrates your network, then he can do anything
2. HTTP(S) Basic Authentication: client send user name and password over HTTPS
   1. cons:
      1. Hard to manage SSL issuing process and revoking process
      2. HTTPS traffic cannot be cached by reverse proxies
3. Use SAML or OpenID Connect, but client talk to identity server directly
   1. cons: where do we store credentials
4. Use client certificate such as TLS to verify a client server is valid
   1. Difficult to debug TLS verification issue
5. HMAC Over HTTP
   1. hash-based messaging code (HMAC)
   2. client and server shares same private key
   3. request body is hashed by private key and the hash is sent along with the request body
      1. so that if middle man messes the request, the hash won’t match the body
   4. lower overhead than https
   5. cons:
      1. need to send private key to client in a secure way
      2. hard to invalidate private key
      3. this is a pattern, not a standard, and thus there are divergent ways of implementing it.
      4. It can only guarantee no one else manipulated the request. the body is still visible to others
6. API keys
   1. public api offers client user to use specials keys to authorize them and allow public api server to put limit on them
   2. can be implemented in multiple ways, e.g. public key, private key
   3. easy to use

MSV Ch 9 Security

Related Chapters

SAP Ch 10 Safety

SAP Ch 11 Security

SAH Ch 9 Data Ownership and Distributed Transactions

SAH Ch 12 Transactional Sagas

MSV Ch 5 Splitting the monolith

MSV Ch 8 Monitoring

MSV Ch 9 Security