├── .DS_Store ├── EDA.md ├── LICENSE ├── README.md ├── a-b-testing.md ├── acid.md ├── adapter-containers.md ├── ambassador-containers.md ├── api-gateway.md ├── api-management.md ├── api.md ├── authentication.md ├── batch-size.md ├── blue-green-deployment.md ├── bounded-context.md ├── canary-deployment.md ├── cap-theorem.md ├── causal-consistency.md ├── cicd.md ├── circuit-breaker.md ├── cloud-native.md ├── compensating-transactions.md ├── configmap.md ├── consistency-models.md ├── container.md ├── cqrs.md ├── cycle-time.md ├── dark-launch.md ├── data-virtualization.md ├── deployment.md ├── devops.md ├── discovery.md ├── domain-driven-design.md ├── domain.md ├── elasticity.md ├── event-consumer.md ├── event-driven-architecture.md ├── event-producer.md ├── event-sink.md ├── event-source.md ├── event-sourcing.md ├── eventing.md ├── eventual-consistency.md ├── faas.md ├── fault-injection.md ├── fault-tolerance.md ├── feature-toggles.md ├── federalization.md ├── functions.md ├── governance.md ├── grpc.md ├── haproxy.md ├── health-checking.md ├── hybrid-cloud.md ├── images ├── APIGateway.png └── containers.png ├── immutable-infrastructure.md ├── ingress.md ├── json-web-token.md ├── kafka.com ├── knative.md ├── kubernetes.md ├── lead-time.md ├── lets-encrypt.md ├── linearizability.md ├── log-aggregation.md ├── materialized-view.md ├── metrics.md ├── microservice.md ├── model.md ├── monitoring.md ├── monolith.md ├── node-proxy.md ├── orchestration.md ├── outlier.md ├── pipeline.md ├── pod.md ├── protobuf.md ├── rate-limiting.md ├── reactive-programming.md ├── rest.md ├── route.md ├── router.md ├── rpc.md ├── sagas.md ├── serverless.md ├── service-mesh.md ├── service-virtualization.md ├── sidecar-containers.md ├── strangler-pattern.md ├── strict-consistency.md ├── tekton.md ├── tracing.md ├── traffic-splitting.md ├── two-pizza-team.md ├── ubiquitous-language.md └── write-only-database.md /.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/.DS_Store -------------------------------------------------------------------------------- /EDA.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/EDA.md -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # cloud-native-compass 2 | Definitions of terms and links to relative materials for Cloud Native Software Development and Microservices 3 | 4 | Brought to you by the team at [Red Hat Developers](https://developers.redhat.com). 5 | 6 | This is the Cloud Native Compass, a jumping-off point into the world of cloud native and microservices development. 7 | 8 | Here you'll find over 75 terms defined and explained. In addition, you'll find links to helpful resources related to the subjects. Let this be your starting point on your journey to cutting-edge software development. 9 | 10 | Bonus: It's open source. Don't like something? Want to make an improvement or an addition? Simply fork this repo and submit a pull request. 11 | 12 | -------------------------------------------------------------------------------- /a-b-testing.md: -------------------------------------------------------------------------------- 1 | # A/B Testing 2 | 3 | A/B testing is an approach to testing a hypothesis by creating a control group and introducing variant scenarios, functionality, appearance, et. al., and measuring the reactions across the scenarios against an intended reaction. 4 | 5 | One application of A?B Testing is to test two application versions at the same time. By splitting the traffic 50/50 between two versions of an application or website, you are able to determine which version is more popular, faster, a better fit, etc. … whichever criteria you have determined are most important. 6 | 7 | For example, a website might experiment with a different layout. While unit testing, integration testing, and user acceptance testing may be successful, determining if the layout is more popular or results in more leads/orders/profits/etc. is done by A/B testing with the previous layout. In this scenario it is common to randomly split web traffic between the two layouts. 8 | 9 | In a microservices context, A/B testing directs traffic randomly between the two versions and logs, traces and monitoring are used to determine which is better. 10 | 11 | If you are using Red Hat OpenShift, one tactic for A/B Testing is to spin up an equal number of pods for the two versions of your application and then establish one route that uses a round robin load balancer to direct traffic to the pods. 12 | 13 | Using Istio to implement A/B Testing gives you more control over the traffic. This is the suggested method of A/B Testing against OpenShift applications. 14 | -------------------------------------------------------------------------------- /acid.md: -------------------------------------------------------------------------------- 1 | Atomicity, Consistency, Isolation, Durability 2 | -------------------------------------------------------------------------------- /adapter-containers.md: -------------------------------------------------------------------------------- 1 | # Adapter Containers 2 | 3 | An Adapter container is kind of reverse Ambassador and provides a unified interface to a pod from the outside world. -------------------------------------------------------------------------------- /ambassador-containers.md: -------------------------------------------------------------------------------- 1 | # Ambassador Containers 2 | 3 | An Ambassador container is used to create a virtual link between a service consumer and a service. This differs from an API gateway in that the `--link` option is used in the `docker run` command to link the containers. This exposes a lone interface to the world. 4 | 5 | For example, rather than have a website call a microservice directly, an ambassador container sits between the website and the microservice, and the website makes requests to the Ambassador container. In the event that the microservice must be moved, no changes need to be made to the website. This improves the portability of the service. 6 | 7 | As an illustration, consider: 8 | 9 | Website → Microservice 10 | Website → Ambassador Container → Microservice 11 | 12 | In the second case, moving the microservice does not require a restart of the website. 13 | 14 | 15 | In this sense, an Ambassador container provides a unified view to the world for your microservice. This is a specialization of the Sidecar pattern, where in this situation, the Ambassador does not enhance the behaviour of the main container. Instead, it is used with the only purpose of hiding complexity and providing a unified interface to services outside of the pod, in this example, the website. 16 | -------------------------------------------------------------------------------- /api-gateway.md: -------------------------------------------------------------------------------- 1 | # API Gateway 2 | 3 | A service design model — an implementation of the facade design pattern — where a client (e.g. a website) talks to one and only one service: The API Gateway. The API Gateway, in turn, handles all traffic to the other services and then back to the calling client. 4 | 5 | An example would be in the case where different clients need different responses from the same service. A website may require a particular snippet of HTML, whereas a mobile client may require a JSON document. By using an API Gateway, you are able to detect the client and direct the request — and handle the response — appropriately. 6 | 7 | ![diagram of the structure of an API gateway architecture](./images/APIGateway.png) 8 | 9 | An API Gateway is also the preferred method for efficiently handling client Authentication for your Cloud Native solution. 10 | 11 | As a software developer, the API Gateway model and implementation present the opportunity to put all Circuit Breaker logic in one place. -------------------------------------------------------------------------------- /api-management.md: -------------------------------------------------------------------------------- 1 | # API Management 2 | 3 | API management is the practice of taking an active ownership of your APIs. Management tools may include: rate limits, a dashboard, analytics, tools for monetization, authentication, onboarding, documentation and a developer portal. 4 | 5 | API Management is critical to maintaining control over an application. Preventing overuse, blocking DDoS attacks, monitoring traffic, billing, etc. are the responsibility of the service owner. API management enables a team to own their service and its performance. 6 | -------------------------------------------------------------------------------- /api.md: -------------------------------------------------------------------------------- 1 | # API 2 | 3 | Application Programming Interface. This is the "contract" that specifies what a service expects to receive and what it promises to return. This contract, or agreement, dictates the protocols, data, and methods to be used by any client. APIs can use different data formats and protocols; In the domain of Cloud Native computing, the most common pattern is the REST API Pattern. 4 | 5 | Most RESTful services communicate via TCP, using HTTP verbs to invoke methods and JSON documents to send and receive data. Support for XML is also another viable message format, though is much less commonly used for new interfaces. XML is not recommended for new projects as it adds unnecessary complexity and introduces a larger payload between services, i.e. it takes more text to describe an XML document versus a JSON document. 6 | 7 | For services that are exposed outside of a network, i.e. over the internet or a WAN, REST and TCP is the de facto standard for communication. 8 | 9 | For services that communicate within a network, i.e. behind the firewall, RPC is another means for API communications. RPC, specifically implemented using gRPC (which uses protobuffers under the hood), has the advantage over REST in that it is faster and more robust than REST over TCP. 10 | 11 | The speed advantage is due to reduced latency and the fact that serialization and deserialization needs are reduced, saving CPU cycles. 12 | 13 | Robustness is improved because gRPC allows a connection to be maintained between two machines while executing remote functions; gRPC also uses strongly-typed data formats with forward- and backward-compatible schema evolution. 14 | -------------------------------------------------------------------------------- /authentication.md: -------------------------------------------------------------------------------- 1 | # Authentication 2 | 3 | The process of verifying an identity to make sure it has the proper rights to perform actions. For microservices, OAuth2 is the preferred method of authentication. OAuth2 will generate a JSON Web Token (JWT) that is used to authenticate the user. 4 | 5 | By using an API Gateway, authentication can be performed at a single point. The generated token is then passed along to every microservice, which in turn uses the token to determine rights of the caller. This model centralizes the authentication while distributing the access rights. 6 | 7 | The downside of using a API Gateway to generate a JWT occurs when user rights are changed before a JWT expires, meaning the rights will not be effective until later. 8 | -------------------------------------------------------------------------------- /batch-size.md: -------------------------------------------------------------------------------- 1 | # Batch Size 2 | 3 | In the DevOps world, batch size is the amount of changes accumulated between each one of your software releases and/or deployments into production. It’s directly connected to two other very import metrics: lead time, and cycle time. 4 | 5 | Some practitioners consider batch size to be the most relevant metric in any DevOps strategy: it’s easily measured no matter how mature (or immature) is your organization, and it has a direct correlation with risk mitigation. 6 | 7 | First, let’s discuss the correlation with risk mitigation. Updating software into production is risky: usually software releases bring new bugs, and bugs might impact your business results. But not updating software is also risky: existing bugs or security issues won’t get fixed without a new software release, and not providing capabilities to your software fast enough to keep it up to the business requirements pace is also very dangerous for your long term wealthy. 8 | 9 | Changes in a software deployment pipeline encompasses three different scopes: code, environment, and data. Bugs into production environments are almost always associated with changes in one of these scopes. That’s the reason why reducing batch size is one of the primary goals of any DevOps strategy: the larger the batch size, the larger the risks associated to having bugs into production. 10 | -------------------------------------------------------------------------------- /blue-green-deployment.md: -------------------------------------------------------------------------------- 1 | # Blue/Green Deployment 2 | 3 | A deployment pattern to enable zero-downtime deployments by running two application versions simultaneously. Because Kubernetes handles routing to and discovery of pods, this can be done quickly using patching. 4 | 5 | The Blue/Green Deployment model uses two application versions that are running at the same time. Assuming the Blue version is the current version of the application, the next version, or Green version, is started side-by-side with the Blue version. After the Green version is ready -- that is, once both of the versions are running simultaneously in separate pods -- the route is switched from Blue to Green. At this moment, the newer version of the software is in being accessed by any requests to the service. 6 | 7 | This switching method -- done by patching the software-defined route -- yields zero downtime while allowing an almost-immediate switch back to the Blue version if necessary (by patching the route again). While both versions are running, switching between them can be done rapidly by a route patch. When it has been determined which version is superior -- hopefully the Green version -- the inferior version can be terminated. 8 | -------------------------------------------------------------------------------- /bounded-context.md: -------------------------------------------------------------------------------- 1 | # Bounded Context 2 | 3 | Everything has meaning only as it relates to the domain in question. -------------------------------------------------------------------------------- /canary-deployment.md: -------------------------------------------------------------------------------- 1 | # Canary Deployment 2 | 3 | A deployment pattern where a new version is eased into production by making it available to a given to an increasingly-larger subset of users, until it either reaches 100 percent of the audience or is deemed not ready and is abandoned (and the audience percentage is set to zero). 4 | 5 | By using intelligent routing, such as that provided by istio [istio.io], it is possible to direct web requests to a service based on user-defined criteria, such as geographical location, user id, etc. With that functionality it becomes possible to split traffic to an existing version and a new, Canary version. 6 | 7 | The term “Canary” in this context refers to the old idea of carrying a canary in a cage into a coal mine, using it as a snapshot of the mine’s conditions. If, for example, the canary died, it meant a buildup of dangerous gases such as carbon monoxide. This signaled to the miners that conditions were life-threatening and it was time to exit the mine. 8 | 9 | In software, a Canary Deployment allows you to monitor the success of a new version -- performance, correctness, robustness, etc -- with a small audience. Based on success or failure of the application, the user base is then either slowly expanded until 100 percent of the users are using the new version, or scaled back to zero and the application terminated. 10 | -------------------------------------------------------------------------------- /cap-theorem.md: -------------------------------------------------------------------------------- 1 | # CAP Theorem 2 | 3 | CAP is a theorem explaining a tension between availability and consistency in distributed systems. The theorem states: in distributed computing, only two of the three characteristics can be guaranteed: Consistency, Availability, and Partition tolerance. However, because one of the fallacies of distributed computing includes network unreliability, the choice of partition tolerance is a given -- or forced -- constraint. 4 | 5 | Partition tolerance is achieved when the system responds correctly despite failures. That is, proper routing, service discovery and orchestration assures that the system is working despite areas -- partitions -- of failure. 6 | 7 | Consistency is achieved when each read of data reflects the most recent write. That is, the data is up-to-date across the network. The consistency level the CAP theorem talks about is the linearizability. Note the term consistency differs from the consistency of ACID transactions. The consistency in CAP refers to handling of concurrent data access, if multiple concurrent writes are available to readers in correct order on all nodes. 8 | The concurrent data access is covered by “I” (isolation) in the ACID. 9 | 10 | Availability is achieved when a non-failing node will eventually return a response. The CAP does not define any time boundary when the response has to be returned. 11 | 12 | The definition of characteristics of availability and consistency are strong guarantees. If we relax one of them we can get a system which is partially consistent (see consistency models) but fully available. 13 | -------------------------------------------------------------------------------- /causal-consistency.md: -------------------------------------------------------------------------------- 1 | # Causal Consistency 2 | 3 | Causal consistency is interesting as it's currently considered to be the upper level of consistency which is achievable from a CAP point of view for a system that maintains availability and partition tolerance. Meaning the system could be causally consistent and still be available and partition tolerant. 4 | 5 | Causal consistency defines that causally related reads and writes are seen by every node in the same order (linearizability requires all operations seen in the order), 6 | concurrent writes could be seen in changed order on different nodes. The well known example, is posting to a social network, a post that you hate your boss and before that action you removed the boss from your friends. The causal order being kept means the order of actions can't be changed - the boss can't get informed you hate him. 7 | -------------------------------------------------------------------------------- /cicd.md: -------------------------------------------------------------------------------- 1 | # CI/CD 2 | 3 | Acronym for Continuous Integration/Continuous Delivery or Continuous Integration/Continuous Deployment. 4 | 5 | Continuous Integration (CI) is the practice of merging all developer software branches (or changes) into the master copy (or “trunk”) several times a day. The theory behind CI is that, at any time, a build successful build should be possible from the master trunk of the software. Part of the build process includes automated unit testing. To avoid partial features from being included, Feature Toggles can be used to ignore unfinished sections. 6 | 7 | Automating the process is done by using a build server, which runs after every software commit. This gives a constant update on the status of the software. 8 | 9 | Continuous Delivery extends CI by assuring that the successfully-built code is ready for rapid deployment. Continuous Delivery is not the practice of putting software into production; rather, it is making the software available for production use. The decision to deploy the software can be automatic (Continuous Deployment) or manual. 10 | 11 | Continuous Delivery is the goal to be reached in order to be successfully embracing DevOps. 12 | 13 | Continuous Deployment differs from Continuous Delivery. It is the practice of deploying software to production automatically after a successful build. For most, this is either impractical, too risky, or violates regulations. Manually deploying software is often the preferred method of deployment; Continuous Deployment is best for low-risk software or highly-performant development teams. 14 | -------------------------------------------------------------------------------- /circuit-breaker.md: -------------------------------------------------------------------------------- 1 | # Circuit Breaker 2 | 3 | An architectural pattern to prevent an error at a single service from cascading across the system. It does this by watching service health and "tripping" the circuit after a specified number of failures. 4 | A circuit breaker, whether implemented in code (e.g. Hystrix) or supplied by a sidecar container such as istio, has the purpose of removing a broken service from inventory until it is repaired or replaced. Working in cooperation with service routing, an open circuit can be avoided, with requests directed to correctly-functioning services instead. 5 | 6 | A circuit can be triggered to open by server errors (500 errors) and timeout errors. 7 | 8 | Once the circuit is closed, requests are once again routed to the service. 9 | 10 | Within the circuit breaker the parameters to trip the breaker (to open the route to the service and suspends its availability) are set programmatically. Settings such as how many consecutive errors, or a percentage of errors over a timespan, or a limit until a timeout is triggered, are all examples of circuit breaker pattern parameters. 11 | While the circuit breaker can be useful, full implementation of a successful circuit breaker pattern requires that the client responds to an open circuit in a graceful way, as well as log the event. 12 | -------------------------------------------------------------------------------- /cloud-native.md: -------------------------------------------------------------------------------- 1 | # Cloud Native 2 | 3 | Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. 4 | 5 | These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. 6 | 7 | The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone. 8 | 9 | * official reference: [Cloud Native Definition v1](https://github.com/cncf/toc/blob/master/DEFINITION.md) 10 | -------------------------------------------------------------------------------- /compensating-transactions.md: -------------------------------------------------------------------------------- 1 | # Compensating Transactions 2 | 3 | A compensating transaction is a one or more database operations that result in the reversal of a database transaction without affecting other database operations. The compensating transactions pattern is used in the Cloud Native Computing context, where transactions can span several microservices and should not use traditional database locking. Instead, a distributed application should implement an eventual consistency data model. 4 | 5 | During a long-running transaction, the affected data is inconsistent. It is not until the transaction is completed that the data is consistent and correct. If the transaction should fail before all of the steps are completed, it is required that there be a method by which the transaction can be completed at a later date or canceled. 6 | 7 | A transaction rollback is not a valid solution in this instance because the eventual consistency database model does not implement database locking. One of the challenges of database transactions in the distributed application model is that, while a long-running transaction is executing, it may affect data is multiple, dissimilar databases (e.g. a SQL database, a NoSQL data store, text files, etc.). Further, the transaction may have affected the state of another service. 8 | 9 | The compensating transaction, then, stores all the steps necessary to recreate any transaction. It can also be used to reverse an aborted transaction from any point. Finally, it must be idempotent so that multiple unsuccessful attempts to execute the compensating transaction itself -- either to completion or rollback -- will not result in corruption of data. 10 | -------------------------------------------------------------------------------- /configmap.md: -------------------------------------------------------------------------------- 1 | # ConfigMap 2 | 3 | A ConfigMap is used by Kubernetes to enable the decoupling of configuration artifacts from images. Leveraging a ConfigMap keeps a container portable across environments. 4 | 5 | The ConfigMap API object holds key-value pairs of configuration data. A ConfigMap can store fine-grained information like individual properties or coarse-grained information like entire configuration files or JSON blobs. 6 | 7 | A ConfigMap should not be used to store secrets such as API keys or passwords. In that case, use Kubernetes Secrets. 8 | -------------------------------------------------------------------------------- /consistency-models.md: -------------------------------------------------------------------------------- 1 | # Consistency Models 2 | 3 | Consistency Model is used to define and describe how data acts in a distributed system, i.e. a contract between a distributed data store and the processes. It defines how the client’s reads and writes depends on each other, if the data written by of one clients can be seen by reads of the other clients. 4 | 5 | Consistency models are listed in order of strength, from strongest to weakest. The strongest model yields the most consistent data. Better consistency normally means lower concurrency. 6 | 7 | Strict Consistency 8 | Linearizability 9 | Causal consistency 10 | Eventual consistency 11 | -------------------------------------------------------------------------------- /container.md: -------------------------------------------------------------------------------- 1 | # Container 2 | 3 | Linux containers are technologies that allow you to package and isolate applications with their entire runtime environment — all of the files necessary to run; operating system, data, binaries, dependencies, etc. This makes it easy to move the contained application between environments (development, test, production, etc.) while retaining full functionality. 4 | 5 | To put a finer point on it, imagine you’re developing an application. You do your work on a laptop and your environment has a specific configuration. Other developers may have slightly different configurations. The application you’re developing relies on that configuration and is dependent on specific files. Meanwhile, your business has test and production environments which are standardized with their own configurations and their own sets of supporting files. You want to emulate those environments as much as possible locally, but without all of the overhead of re-creating the server environments. So, how do you make your app work across these environments, pass quality assurance, and get your app deployed without massive headaches, rewriting, and break-fixing? The answer: Containers. The container that holds your application has the necessary configurations (and files) so that you can move it from development, to test, to production without all of the nasty side effects. Crisis averted–everyone’s happy. 6 | 7 | ## Isn’t this just virtualization? 8 | 9 | Yes and no. Here’s an easy way to think about the two: 10 | * Virtualization lets many operating systems run simultaneously on a single system. 11 | * Containers share the same operating system kernel and isolate the application processes from the rest of the system. 12 | 13 | ![/images/containers.png](/images/containers.png) 14 | 15 | What does this mean? For starters, having multiple operating systems running on a hypervisor, the software that makes virtualization work, isn’t as lightweight as using containers. When you have finite resources with finite capabilities, you need lightweight apps that can be densely deployed. Linux containers run from that single Linux kernel, sharing it across all of your containers, so your apps and services stay lightweight and run swiftly in parallel. 16 | 17 | Because containers are self-contained they can be started quickly, typically in under one second. This makes containers ideal for auto-scaling environments such as Kubernetes and OpenShift. 18 | -------------------------------------------------------------------------------- /cqrs.md: -------------------------------------------------------------------------------- 1 | # CQRS 2 | 3 | Command and Query Responsibility Segregation (CQRS) is a data storage design where the model used to write data is different from the model used to read data. 4 | 5 | In a traditional Create, Read, Update, Delete (CRUD) database model, all create, update and delete operations -- the commands -- are executed within the same, single data model as all read operations -- the queries. As expected, this has benefits and disadvantages associated with it. 6 | 7 | The benefits of a traditional CRUD model include the ease with which code can be constructed, the familiarity with this traditional model, and the single location of all database operations. 8 | 9 | The disadvantages include performance bottlenecks, the mixing of various domain logic into one database, and a data model that may not agree with the Bounded Context that utilizes it. 10 | 11 | By segregating commands and queries, some of the benefits to be gained include: a data model that matches the Bounded Context; the ability to more easily scale database operations; easier application of security restrictions. 12 | 13 | Generating the application code to support CQRS is not possible, given the fact that the queries do not necessarily map to the underlying data structures -- but are rather a derived structure as a result of Domain Driven Design. Also, because multiple data stores are typically used, data consistency issues present themselves: data may be updated in one location before other locations (see CAP Theorem). 14 | 15 | When data has been updated but not fully propagated, it may result in a read operation that does not contain the latest update. This is known as a “stale read”. 16 | 17 | A common use for CQRS is in support of Event Sourcing, where all database updates are written as a stream of events, and Materialized Views are used to read data. 18 | -------------------------------------------------------------------------------- /cycle-time.md: -------------------------------------------------------------------------------- 1 | # Cycle Time 2 | 3 | The amount of time that elapses between the moment a work item is accepted until it is realized in production. This cycle time is a good measurement of the maturity and agility of an organization, with the goal of reducing it as much as possible. 4 | 5 | The cycle time metric includes not only process automation, but also human-powered processes such as issue tickets, change reviews, documentation, etc. This increases understanding of the broader process and invite innovation in every aspect of the development cycle. 6 | -------------------------------------------------------------------------------- /dark-launch.md: -------------------------------------------------------------------------------- 1 | # Dark Launch 2 | 3 | Dark Launch is the practice of launching a new version of a microservice and splitting traffic between it and the existing version while using only the existing version in production. After splitting the ingress messages, both the existing version of the microservice and the Dark Launch version process the messages and yield results. The results of the existing version are returned as usual, while the Dark Launch version results are logged. These logged results are then analyzed to assure they are correct. -------------------------------------------------------------------------------- /data-virtualization.md: -------------------------------------------------------------------------------- 1 | # Data Virtualization 2 | 3 | A view of the data is presented that is not necessarily a one-to-one mapping to the underlying data source(s). Because, in a distributed system, data is stored across the network in (often) many different forms (RDBMS, NoSQL, files, etc), it is often necessary to create a view of the data that maps to the bounded context being served. This virtual view of the data allows the microservice to understand and work with the data in the ubiquitous language as determined by the bounded context. -------------------------------------------------------------------------------- /deployment.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/deployment.md -------------------------------------------------------------------------------- /devops.md: -------------------------------------------------------------------------------- 1 | # DevOps 2 | 3 | DevOps is defined in many organizations through their use of tools, methodologies and culture, typically resulting in a redesign of the teams that build and deliver applications and infrastructure. Fundamentally, DevOps represents a shift in attitude towards the value that custom software development can provide. DevOps empowers an organization by automating software development lifecycle events, from the creation of code through promoting it to production, without manual steps, delays or introducing human error. A key performance indicator for the value of DevOps to an organization is the reduction in mean time to value (MTTV) of the developers’ efforts. 4 | 5 | In a DevOps model, resources that were siloed by function in traditional software development shops, are realigned under an application or service with all necessary skill sets in a single team. Utilizing Continuous Integration and Continuous Deployment tooling with full coverage tests in a single build pipeline for all necessary targeted environments enables the cradle to grave development lifecycle, lowering the overall MTTV. Streamlining teams into DevOps models reduces the typical handoff and environment change management that traditional software organizations encounter. With a DevOps model, organizations benefit from operational efficiencies, improved communication, application scale without major redesign, and reduced security exposure. -------------------------------------------------------------------------------- /discovery.md: -------------------------------------------------------------------------------- 1 | # Discovery 2 | 3 | Discovery, or Service Discovery, is the method by which a service is located in order to be invoked. Each microservice will be registered with a service registry e.g. kubernetes, consul and the consumers can discover the service by its name. 4 | 5 | For example: Kubernetes has a inbuilt service registry, each kubernetes application that is deployed will be registered against its internal service registry using service name, the consumers or the other apps can lookup the service by its name which in turn return the endpoint URL 6 | -------------------------------------------------------------------------------- /domain-driven-design.md: -------------------------------------------------------------------------------- 1 | # Domain-Driven Design 2 | 3 | Domain Driven Design (DDD) is a system analysis methodology where the needs of the underlying business entity or function drives the outcome of the system construction. 4 | 5 | In DDD, the solution -- one or more microservices -- is built to address only the problems presented by the domain it models. Everything in the solution is within the context of the domain, and all terms are likewise related. This is addressed by the following four characteristics of DDD: 6 | 7 | Bounded Context 8 | Domain 9 | Model 10 | Ubiquitous Language -------------------------------------------------------------------------------- /domain.md: -------------------------------------------------------------------------------- 1 | # Domain 2 | 3 | The underlying concept, beliefs, systems and values addressed by the solution. 4 | -------------------------------------------------------------------------------- /elasticity.md: -------------------------------------------------------------------------------- 1 | # Elasticity 2 | 3 | The parts of a system can expand and contract as necessary based on load. In a Cloud Native environment, this is addressed by using containers and a container management tool such as Kubernetes. By using Kubernetes, you can set policies that determine when containers are started or shutdown in response demand. -------------------------------------------------------------------------------- /event-consumer.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/event-consumer.md -------------------------------------------------------------------------------- /event-driven-architecture.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/event-driven-architecture.md -------------------------------------------------------------------------------- /event-producer.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/event-producer.md -------------------------------------------------------------------------------- /event-sink.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/event-sink.md -------------------------------------------------------------------------------- /event-source.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/event-source.md -------------------------------------------------------------------------------- /event-sourcing.md: -------------------------------------------------------------------------------- 1 | # Event Sourcing 2 | 3 | All database transactions are writes to a database, a time series of events. In this model there are no read, update, or delete operations. The current value of any data entity -- for example, a customer -- is determined by aggregating all of the events associated with that entity. It would include an initial “Create Customer” event, followed by zero to many “Update Customer” events and zero or one “Delete Customer” event. This aggregation of events, known as a Materialized View, can be generated as events happen, as needed, or on a scheduled basis. 4 | 5 | Because data and events are linked, they should include a version stamp. This is necessary when processing events over time as data formats change. 6 | 7 | Event sourcing allows you to store an event in one place -- the Source of Truth for an entity -- and then propagate the event throughout your system as necessary. The events can also trigger multiple processes in your system while maintaining very loose coupling between processes. 8 | 9 | By writing only events to a data store, several advantages are gained. They include: 10 | Performance increases 11 | Elimination of database locks 12 | A data entity’s history is stored 13 | Data does not need to exist in only one place 14 | Events can be used to trigger loosely-coupled actions 15 | -------------------------------------------------------------------------------- /eventing.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/eventing.md -------------------------------------------------------------------------------- /eventual-consistency.md: -------------------------------------------------------------------------------- 1 | # Eventual Consistency 2 | 3 | A weaker level of consistency that states only that the update will be executed at each node eventually; there is no assurance of the order being kept. In our example of removing your boss from your network of friends and posting about your antipathy to him you are not sure what ordering will be processed in the system but you are sure they will be processed. The post may be sent to your friends before your boss is removed from your friend list. Both operations happen, eventually, but the order is not guaranteed. 4 | 5 | In a monolithic system with a central database, database reads are kept as current as possible by using database locks and two-phase commits. While robust, this is expensive and does not scale across a network of microservices. 6 | 7 | In a Cloud Native computing system, where data is distributed and replicated across the network, reading data from a replicated data store may result in stale data. The principle of Eventual Consistency is the fact that, eventually, the virtual view of the data will reflect reality. However, it also results in improved performance as database locks are not felt across the network and database reads are against local data stores. 8 | -------------------------------------------------------------------------------- /faas.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/faas.md -------------------------------------------------------------------------------- /fault-injection.md: -------------------------------------------------------------------------------- 1 | # Fault Injection 2 | 3 | The practice of intentionally introducing faults into a system in order to test it. In the realm of Cloud Native Computing, where microservices are autonomous and small, yet work in a large and often very complex system, testing by fault injection is a good way to test system-wide error handling. Logging and monitoring can also be tested, as faults should be logged and monitored and surfaced as an aid to debugging. -------------------------------------------------------------------------------- /fault-tolerance.md: -------------------------------------------------------------------------------- 1 | # Fault Tolerance 2 | 3 | The ability of a system to remain running despite failures. In Cloud Native computing, this is paramount to success. Network fragility and a reliance on systems beyond your control, i.e. third party services, require systems design to expect and respond to failures. 4 | 5 | Using technologies such as containers, Kubernetes and system-wide monitoring allow you to improve site reliability. Additional techniques and practices related to fault tolerance include fallbacks and circuit breakers. 6 | -------------------------------------------------------------------------------- /feature-toggles.md: -------------------------------------------------------------------------------- 1 | # Feature Toggles 2 | 3 | The ability to test multiple combinations of changes. Using feature toggles allows all developers to work on the trunk of a software project while keeping their code separate at runtime if they desire. By toggling features on and off, multiple combinations of code configurations and tests can be run against the same software. -------------------------------------------------------------------------------- /federalization.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/federalization.md -------------------------------------------------------------------------------- /functions.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/functions.md -------------------------------------------------------------------------------- /governance.md: -------------------------------------------------------------------------------- 1 | # Governance 2 | 3 | How a project or system is managed, regulated and/or directed. When adopting the Cloud Native computing paradigm, governance of software projects switches from a more process-centric management to a results-specific model. This is because, with multiple small, autonomous teams and projects, decisions about the development languages, methods, etc. are left up to the team. The only criteria for success are function and support; that is, does the software work correctly and it is well supported? -------------------------------------------------------------------------------- /grpc.md: -------------------------------------------------------------------------------- 1 | # gRPC 2 | 3 | gRPC (grpc.io) is a specific open source software project from Google that implements Remote Procedure Calls -- RPC -- in any environment. It includes libraries for C++, C#, Node.js, PHP, Ruby, Python, Go, and Java. 4 | 5 | gRPC includes support for load balancing, tracing, health checking and authentication. 6 | -------------------------------------------------------------------------------- /haproxy.md: -------------------------------------------------------------------------------- 1 | # HAProxy 2 | 3 | HAProxy is a software solution that offers high availability, load balancing, and proxy services in a Cloud Native computing environment. HAProxy is the de facto standard solution for these services for TCP and HTTP-based systems. -------------------------------------------------------------------------------- /health-checking.md: -------------------------------------------------------------------------------- 1 | # Health Checking 2 | 3 | An automated system of determining the uptime of a system. As a health checking systems performs its functions, it reports back to the centralized monitoring system. The items monitored by a health checking system may include: 4 | * Correct IP address, port and protocol? 5 | * The validity of service parameters 6 | * Does the service start? 7 | * Does the service respond properly? 8 | * Does the service respond within a configured time, i.e. timeout issues 9 | -------------------------------------------------------------------------------- /hybrid-cloud.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/hybrid-cloud.md -------------------------------------------------------------------------------- /images/APIGateway.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/images/APIGateway.png -------------------------------------------------------------------------------- /images/containers.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/images/containers.png -------------------------------------------------------------------------------- /immutable-infrastructure.md: -------------------------------------------------------------------------------- 1 | # Immutable Infrastructure 2 | 3 | You don't change your infrastructure; you replace it. Because infrastructure is now code instead of hardware it is described in scripts and documents. When a change is necessary, the concept of Immutable Infrastructure dictates that you do not change any running code. Instead, you create a new, updated version and push that into production. 4 | 5 | This avoids the all-too-common problem of an update skipping some parts of the system. It also provides a clearer path to rolling back if necessary. 6 | 7 | Note: Some argue that rolling back should never happen; you create an even newer version and roll forward, even if that new version includes the older code and settings. 8 | -------------------------------------------------------------------------------- /ingress.md: -------------------------------------------------------------------------------- 1 | # Ingress 2 | 3 | Ingress is collection of rules that determines or decides where to route the incoming requests to a designated cluster service. The main purpose of ingress is to give the access to a service via an externalized URL . IngressController is the main component that helps in resolving a request to cluster service; it can also add to itself other features like LoadBalancing, proxying to provide HA-like features. 4 | 5 | Examples include the Kubernetes Ingress Controller and Istio. 6 | -------------------------------------------------------------------------------- /json-web-token.md: -------------------------------------------------------------------------------- 1 | # JSON Web Token 2 | 3 | ## AKA JWT 4 | 5 | An authentication token that contains implicit meaning for the user, e.g. “logged in as administrator”. -------------------------------------------------------------------------------- /kafka.com: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/kafka.com -------------------------------------------------------------------------------- /knative.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/knative.md -------------------------------------------------------------------------------- /kubernetes.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/kubernetes.md -------------------------------------------------------------------------------- /lead-time.md: -------------------------------------------------------------------------------- 1 | # Lead Time 2 | 3 | The amount of time it takes to complete a delivery from when the request was made. In addition to cycle time, lead time includes all applicable process elements leading up to the start of work including manual tasks, such as order processing and requirements management but also subsequent elements like billing. Lead time is used to measure process efficiency from a customer perspective. -------------------------------------------------------------------------------- /lets-encrypt.md: -------------------------------------------------------------------------------- 1 | # Let's Encrypt 2 | 3 | Let’s Encrypt (letsencrypt.org) is a free, open source service that provides SSL/TLS certification. -------------------------------------------------------------------------------- /linearizability.md: -------------------------------------------------------------------------------- 1 | # Linearizability 2 | 3 | Any operation in the system is propagated to all the nodes and holds the order. If there is a reader checking the value, then it can contact any arbitrary node and it gets the same result from any node. -------------------------------------------------------------------------------- /log-aggregation.md: -------------------------------------------------------------------------------- 1 | # Log Aggregation 2 | 3 | Putting all your logs into one place so they can easily be scanned. Entries must be timestamped and uniquely identifiable, as well as linked to their origin. Logs must be stored outside of any single microservice, in a central location, for monitoring and inspection. -------------------------------------------------------------------------------- /materialized-view.md: -------------------------------------------------------------------------------- 1 | # Materialized View 2 | 3 | A database query that has been pre-executed and cached, increasing performance. Materialized Views are useful in a cloud native architecture where data must be read quickly and the eventual consistency data model is appropriate. -------------------------------------------------------------------------------- /metrics.md: -------------------------------------------------------------------------------- 1 | # Metrics 2 | 3 | The measurements of a system. For cloud native computing, sampling of requests and performance monitoring metrics are paramount success, both in terms of performance and uptime. Important metrics include: network latency, processor load, processing time, database performance, UI response time, and fault rates. In an ecommerce system, conversion rates to sales are an important metric when combined with A/B testing to fine tune the UI and increase sales. -------------------------------------------------------------------------------- /microservice.md: -------------------------------------------------------------------------------- 1 | # Microservice 2 | 3 | A microservice is a very small web service that represents part of the bounded context as part of a larger system. In a microservices architectural style, the many small services work in concert to provide the larger, overall solution. 4 | 5 | Microservices are autonomous, independent of other services. They also utilize their own data store(s). A microservice is constructed and supported by a small team (see 2-Pizza Team) which choose the programming language and libraries to use. 6 | 7 | Code reuse is not emphasized in the microservices architecture, as each team should stand on its own. 8 | 9 | Microservices should support the following concepts: 10 | * Centralized logging 11 | * Monitoring 12 | * Uses its own local database 13 | * Depends upon its own construction and support decisions 14 | -------------------------------------------------------------------------------- /model.md: -------------------------------------------------------------------------------- 1 | # Model 2 | 3 | The architecture as it relates to the Domain, i.e. how the domain shapes the solution. -------------------------------------------------------------------------------- /monitoring.md: -------------------------------------------------------------------------------- 1 | # Monitoring 2 | 3 | Automated system of watching your system for errors, performance issues, outages, or any other measurements you wish to observe. In a cloud native system, monitoring can be used to trigger automatic responses to events. 4 | 5 | Measurements monitored include CPU Usage, Disk Usage, Disk I/O, Memory, Bandwidth, and top CPU consumers. 6 | -------------------------------------------------------------------------------- /monolith.md: -------------------------------------------------------------------------------- 1 | # Monolith 2 | 3 | One system that includes all of the code and bits necessary to run; the typical system, running on a server or VM. -------------------------------------------------------------------------------- /node-proxy.md: -------------------------------------------------------------------------------- 1 | # Node Proxy 2 | 3 | Illusionary interface that represents a microservice to others, but is not the actual microsystem. -------------------------------------------------------------------------------- /orchestration.md: -------------------------------------------------------------------------------- 1 | # Orchestration 2 | 3 | The automated practice of getting all the pieces of a software system to work together. This includes assembling the correct pieces, constructing the system, and managing the results -- all through software. A fourth aspect of orchestration is to maintain a system in its desired state. 4 | 5 | Using orchestration, as system is defined in a declarative language, with an underlying automated process carrying out any instructions necessary to reach and maintain the state defined. 6 | 7 | The goals of orchestration are to have a Single Source of Truth for any system’s architecture and a zero-touch process to reaching, maintaining, and changing the system. 8 | -------------------------------------------------------------------------------- /outlier.md: -------------------------------------------------------------------------------- 1 | # Outlier 2 | 3 | Outlier is a method or process of identifying services that are not healthy like its other peer cluster members and making them Ejected (non-serviceable for a configurable amount of time) from the list of cluster members. The Key Performance Indicator (KPI) for identifying non-healthy members could be timeout, latency, successive failures, etc., 4 | 5 | We can apply Outlier detection in conjunction with Circuit Breaker - typically when one server is overwhelmed with requests, and is running out of resources to serve requests which could potentially result in service rejections, based on the number consecutive service rejections we can mark the particular service member to non-health and apply ejection. 6 | -------------------------------------------------------------------------------- /pipeline.md: -------------------------------------------------------------------------------- 1 | # Pipeline 2 | 3 | An environment of automated steps to move an application from development through testing and into staging and, eventually, into production. An automated pipeline allows for the implementation of a CI/CD system. The most widely-used CI/CD tool is Jenkins, an open source software product that allows you to build a pipeline that includes automated builds, automated testing, and either automated or manual delivery or deployment. 4 | -------------------------------------------------------------------------------- /pod.md: -------------------------------------------------------------------------------- 1 | # Pod 2 | 3 | In Kubernetes, a pod is a collection of one or more containers that share storage and/or networking and the specifications (e.g. environment variables) to run the containers. The containers in a pod have the same IP address and port number assigned to them; Kubernetes is responsible to handle this sharing. 4 | 5 | Pods are useful when thought of in the context of auto-scaling, where multiple instances of a service are created or destroyed rapidly and on demand, with the same URI applying at all times. 6 | -------------------------------------------------------------------------------- /protobuf.md: -------------------------------------------------------------------------------- 1 | # Protobuf 2 | 3 | Protobuf is a mechanism to serialze structured data to be communicated 4 | between two end-points. The structured data is defined in a .proto file 5 | per a data definition language published by Google. The protobuf 6 | compiler is then used to generate code, in a chosen language (C#, C++, 7 | Dart, Go, Python, Java are supported as of now), to read and 8 | write the structured data. 9 | A pretty simple analogy for Protobuf is XML - which is used to communicate with web services. 10 | 11 | In cloud native app developement world, Protobufs are used in conjunction 12 | with gRPC. 13 | -------------------------------------------------------------------------------- /rate-limiting.md: -------------------------------------------------------------------------------- 1 | # Rate Limiting 2 | 3 | Rate limiting is a method/process to control the amount of traffic that is sent to a particular service or cluster of services. Rate Limiting is very useful in very high load scenarios where we wish to limit the requests to a service or cluster of services at a given point of time. -------------------------------------------------------------------------------- /reactive-programming.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/reactive-programming.md -------------------------------------------------------------------------------- /rest.md: -------------------------------------------------------------------------------- 1 | # REST 2 | 3 | Acronym for REpresentational State Transfer. Interface between systems that allows state manipulation via HTTP verbs. The HTTP verbs are used for CRUD operations as follows: 4 | 5 | HTTP Verb | CRUD operation 6 | POST | Create 7 | GET | Read 8 | PUT | Update 9 | DELETE | Delete 10 | 11 | -------------------------------------------------------------------------------- /route.md: -------------------------------------------------------------------------------- 1 | # Route 2 | 3 | The path to a microservice. Because a microservice may be running several instances of itself, the route may have multiple paths. When this is the case, the multiple routes are tracked by the Load Balancer, which in then determines which specific route to use when a microservice is called. These routes may differ by port number, IP address or DNS entry, i.e. different URIs. When this happens, the load balance automates the routing, allowing the developer to use one URI that is resolved at runtime. -------------------------------------------------------------------------------- /router.md: -------------------------------------------------------------------------------- 1 | # Router 2 | 3 | Software that determines the path to a resource. In the context of cloud native computing, a router will determine the IP address and port number of a microservice. This frees the developer from writing code that finds a microservice; rather, an assigned URI is used. -------------------------------------------------------------------------------- /rpc.md: -------------------------------------------------------------------------------- 1 | # RPC 2 | 3 | Remote Procedure Call. A high-speed, direct system-to-system interface between two microservices. Implemented by gRPC. RPC differs from REST in four main aspects: 4 | 1. The connection remains open for the entirety of the process. 5 | 1. RPC allows unique method names, e.g. “SendConfirmationEmail” -- as opposed to the HTTP verbs (GET, POST, PUT, etc). 6 | 1. RPC allows for interface interrogation by machine instead of being limited to only a human-readable specification. 7 | 1. RPC is faster. 8 | 9 | The main disadvantage of RPC is that it requires a special library to implement and is not a standard HTTP request. 10 | -------------------------------------------------------------------------------- /sagas.md: -------------------------------------------------------------------------------- 1 | # Sagas 2 | 3 | An event-driven model that is the microservices alternative implementation of a Two-Phase Commit. A saga consists of a collection of requests and compensating transactions. Requests must be able to be aborted and must be idempotent. 4 | 5 | Sagas are comprised of a series of compensating transactions that are coordinated by events. They are the cloud native (near) equivalent of a distributed transaction. 6 | -------------------------------------------------------------------------------- /serverless.md: -------------------------------------------------------------------------------- 1 | # Serverless 2 | 3 | A development model that relies on code and ignores the underlying infrastructure. Serverless functions allow a developer to write code regardless of the operating system on which it will run. Serverless, which typically run as cloud-based functions, are commonly used to respond to events in a system, providing one result from one event. -------------------------------------------------------------------------------- /service-mesh.md: -------------------------------------------------------------------------------- 1 | # Service Mesh 2 | 3 | A Service Mesh is the term to describe the network of microservices and interactions between them. This is a typical phenomenon when a monolithic application is migrated to microservice-based architecture. -------------------------------------------------------------------------------- /service-virtualization.md: -------------------------------------------------------------------------------- 1 | # Service Virtualization 2 | 3 | Service virtualization is a technique used to emulate the behavior of dependencies of component-based applications. Although generally speaking, these dependencies are usually REST API-based services in a microservices architecture, the concept can also be applied to any other kinds of dependencies such as databases, ESB, Web Services, JMS, or any other system that communicates using messaging protocols. -------------------------------------------------------------------------------- /sidecar-containers.md: -------------------------------------------------------------------------------- 1 | # Sidecar Containers 2 | 3 | Containers that exist to assist your microservices. In Kubernetes, sidecars run within the same namespace, i.e. the same pod, and have the same lifecycle as the service it supports. 4 | 5 | Istio is an example of a sidecar container. By routing all traffic to and from a service through the istio sidecar, it is able to control ingress and egress routing, circuit breaker support, provide observability, and more. 6 | 7 | The goal of a sidecar container is such that support for these and other features of cloud native computing are contained outside of your source code, i.e. you don’t need to import libraries and write code to support, for example, a circuit breaker. 8 | -------------------------------------------------------------------------------- /strangler-pattern.md: -------------------------------------------------------------------------------- 1 | # Strangler Pattern 2 | 3 | A pattern of introducing microservices in support of a legacy, monolithic app, whereby the number of microservices eventually surrounds the monolith to the point that, in a diagram, the monolith is 'strangled' by the microservices. -------------------------------------------------------------------------------- /strict-consistency.md: -------------------------------------------------------------------------------- 1 | # Strict Consistency 2 | 3 | This consistency level is the “holy grail” of distributed systems. It brings ACID properties to the distributed world. It is defined as: when a client writes a value to specific key to the system, then any other read from arbitrary node will get the most up-to-date value for the key. And at the same time the operations over the properties could be grouped into blocks where those blocks defines a single non-separable unit of work where no operation from outside of the block can enter between. 4 | 5 | In a traditional relational database model, this is achieved by using row- and set-level locks. In a distributed environment, with multiple databases, this becomes too expensive to be practical. 6 | -------------------------------------------------------------------------------- /tekton.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/tekton.md -------------------------------------------------------------------------------- /tracing.md: -------------------------------------------------------------------------------- 1 | # Tracing 2 | 3 | Tracing -- rather Distributed tracing -- is the process of identifying the request flow from start to end, while along the way collecting some key metrics. This is very useful for distributed applications in identifying various bottlenecks. 4 | In particular, OpenTracing, being a CNCF (Cloud Native Computing Foundation) project is the place to go to for more resources. 5 | https://opentracing.io/ 6 | -------------------------------------------------------------------------------- /traffic-splitting.md: -------------------------------------------------------------------------------- 1 | # Traffic Splitting 2 | 3 | Used with a Dark Launch, traffic splitting is the practice of sampling and duplicating some traffic to a service -- the percentage or sampling rate is configurable -- and sending it to a second service for processing. The second service processes the request and returns the values to a third party -- a log file, for example -- where it can be evaluated to see if the results are as expected. -------------------------------------------------------------------------------- /two-pizza-team.md: -------------------------------------------------------------------------------- 1 | # Two pizza team 2 | 3 | The term "Two pizza team" comes from Amazon and describes a team size such that it is the number of people that can be fed by two pizzas. The reality is that the term is not only a reference to team size but, rather, underscores the concept of "Accountability". 4 | 5 | In the world of Cloud Native Computing, a small team is responsible for an application and its life, from inception to coding to support (some people make an exception for security, which may be handled by a central security team for the sake of consistency and completeness). In traditional (e.g. waterfall) SDLC schemes, teams are built around the division of responsibilities: Design, development, testing, database, operations, etc. 6 | 7 | In the microservices model, teams are built around a function or unit of work: Adding to inventory, retrieving a list of nearby stores, etc. This typically small team is free to design, develop, test and deploy the microservice as it sees fit. Language choice (Java, C#, Go, etc.) is not governed by an outside management force, but is determined by the team's skill set or a particular language's best fit for a function. 8 | 9 | The application design is determined by the team; any local database is their choice as well, as it is deployed with the solution. Likewise, testing remains their challenge, with a built-in incentive: The team also supports the application, so fewer defects means less time spent in support. On the other hand, a problem at 3AM on a Saturday is the team's responsibility and theirs alone. 10 | -------------------------------------------------------------------------------- /ubiquitous-language.md: -------------------------------------------------------------------------------- 1 | # Ubiquitous Language 2 | 3 | All terms are related to the domain and have a meaning that is understood by all parties involved within the domain. 4 | 5 | For example: The term “run” can have several meanings. It may be a verb, as when a person runs. It may also be a noun, but with many meanings. A run in a card game, a run in a stocking, a run in a manufacturing facility, a run in a baseball game, etc. The Context determines the meaning of this Ubiquitous Language, as determined by the Domain in which we are dealing. How a run is modeled in a system (the Model) is based on this knowledge. 6 | 7 | When these four factors are applied, we are then able to construct microservices to implement a solution. 8 | -------------------------------------------------------------------------------- /write-only-database.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/redhat-developer-demos/cloud-native-compass/0b93f71a5284c7acd0a1a49193c971208d99da79/write-only-database.md --------------------------------------------------------------------------------