kgb1001001 / cloudadoptionpatterns Goto Github PK

Add a pattern on container orchestration.

Not sure if this is applicable or not, but it seems more than a few client conversations have been centered around "how to set up their cloud account".

Clients have been asking about a "hub and spoke" pattern to their cloud account with centralize a subset of cloud services for visibility, security, and compliance while giving enough autonomy for the workloads to provision the services they need, within the "guardrails" of a centralized authority.

Pub/Fed and banking clients seem to be gravitating toward a "hub and spoke" design to their cloud account and organization structure. For example, in large orgs with distributed IT teams, a "cooking cutter" landing zone for workloads interacts with a centralized "management plane" account for aggregate logging, brokering public traffic, centralized audit & billing access.

Hi:
A few more typos to report.

1. Look For Hairline Cracks (https://kgb1001001.github.io/cloudadoptionpatterns/Cloud-Adoption/Look-For-Hairline-Cracks.html)
   a) first paragraph:
   in order to improve the maintainance of the application and to reduce the blast radius of new changes to the application
2. Identify Entities and Aggregates
   (https://kgb1001001.github.io/cloudadoptionpatterns/Cloud-Native-Architecture/Identify-Entities-And-Aggregates.html)
   a) 6th paragraph
   Typo: Entities also have attributes that might change, but the identifier for the person stays the same. 
   Correction: Entities also have attributes that might change, but the identifier for the entity stays the same. 
   b) second last paragraph: They often form the boundaries of transactionality.
3. Identify Domain Events (https://kgb1001001.github.io/cloudadoptionpatterns/Cloud-Native-Architecture/Identify-Domain-Events.html)
   a) 7th paragraph:
   These facts are now Events in that they show how one occurance will be followed in time by another and another and another.
4. Event Driven Architecture (https://kgb1001001.github.io/cloudadoptionpatterns/Event-Based-Architecture/Event-Driven-Architecture.html)
   last paragraph
   Typo: An Event-Driven Architecture extends loose coupling to event coupling in which because the targets are optional; the source announces the occurrence the same whether the announcement goes to no, one, or multiple targets. It enables each target to receive the notification and decide how to react, if at all, such as which service to invoke.
   Correction: An Event-Driven Architecture extends loose coupling to event coupling in which because the targets are optional; the source announces the occurrence the same way whether the announcement goes to no, one, or multiple targets. It enables each target to receive the notification and decide how to react, if at all, such as which service to invoke.
5. Service Mesh
   3rd paragraph: Even performance management becomes more challenging to implement, because instead of calls that are fixed in time, you have the vagaraties of network communication added into the mix.

I found following typos so far as I am reading.

1. Introduction page (https://kgb1001001.github.io/cloudadoptionpatterns/)
   a) Cloud Adoption
   typo: applciations toward a cloud-native approach
   b) Cloud Client Architecture
   typo: faciliatate cloud-native development.

2. Cloud Centric Design (https://kgb1001001.github.io/cloudadoptionpatterns/Cloud-Adoption/Cloud-Centric-Design.html)
   Towards last third of the page
   a) typo: Minimizing the use of state (it is impossible to entirely eliminate state, but you should ony keep the state that is absolutely required).
   b) typo: It would take advantage of Scaleable Stores that allow development teams to match the data stroage technology to the type of data that being stored and to the data storage and retrieval patterns that are most prevalent for that application

3. Implement Monolith First (https://kgb1001001.github.io/cloudadoptionpatterns/Cloud-Adoption/Implement-Monolith-First.html)
   8th paragraph
   typo: because the right way is simply not known at this stage: when the application is not successul, the right decision is to shut it down, not to rearchitect it into something more beautiful

4. Lift and Shift (https://kgb1001001.github.io/cloudadoptionpatterns/Cloud-Adoption/Lift-and-Shift.html)
   a) 5th paragraph
   typo: There are three basic steps that you need to ensure in order ot make a Lift and Shift possible.
   b) bullet point #2
   typo: In many cases, even if the applciation runs entirely in the cloud, all requests to the application must come up through a direct connection to a corporate internet
   c) bullet point #3
   requirements or dependinces on databases that are shared across many applications may require the latter
   d) second last paragraph
   typo: apply to traditional application resiliancy as well, although the implementation choices may differ on which technologies you choose to perform data replication

As I continue my reading, I will keep taking notes and share it as an open issue.

Regards:
--kh

Bobby - you should add an Author bio page on the root directory - see mine or Joe's or Cees' for an example.

For example on https://kgb1001001.github.io/cloudadoptionpatterns/Strangler-Patterns/ .

Seems like there's a problem with the use of <img> in finding the .pngs. Reverting Markdown ![blah](imagepath) works.

1. Adapter microservices(https://kgb1001001.github.io/cloudadoptionpatterns/Microservices/Adapter-Microservice.html)
   a)3rd paragraph: Or it may be that you want to take advantage of a cloud-based (SaaS) API from a clodu provider that provides some or most of the functionality that you would otherwise have to build.
2. Page Cache (https://kgb1001001.github.io/cloudadoptionpatterns/Microservices/Page-Cache.html)
   a) Broken page reference in first paragraph: You are building a web or mobile application using a Microservices Architecture**]**(Microservices-Architecture.md)
3. Event Based Architecture(https://kgb1001001.github.io/cloudadoptionpatterns/Event-Based-Architecture)
   a) Issue: The link and the page title do not match. Link states Event Based Architecture and the corresponding page title states Event Driven Architecture.
4. Event Sourcing (https://kgb1001001.github.io/cloudadoptionpatterns/Event-Based-Architecture/Event-Sourcing.html)
   a) Ist paragraph: When you are designing applications that use Events you often find that the approach of repseenting the state of your application
   b) 2nd paragraph: Waht’s more, it’s also hard to figure out the logic of how to “undo” things when conditions change.