diff --git a/.github/settings.yml b/.github/settings.yml index 299c096ab3..c995009307 100644 --- a/.github/settings.yml +++ b/.github/settings.yml @@ -125,6 +125,9 @@ collaborators: # l10n bn approvers - username: Arindam200 permission: push + + - username: asem-hamid + permission: push - username: Imtiaz1234 permission: push @@ -168,9 +171,6 @@ collaborators: - username: huats permission: push - - username: fydrah - permission: push - - username: Krast76 permission: push @@ -180,6 +180,9 @@ collaborators: - username: guillaumebernard84 permission: push + - username: seb-835 + permission: push + # l10n ur approvers - username: Saim-Safdar permission: push @@ -220,7 +223,7 @@ collaborators: - username: aliok permission: push - - username: halil-bugol + - username: symys permission: push - username: rwxdash @@ -390,6 +393,7 @@ branches: # bn approvers users: - Arindam200 + - asem-hamid - Imtiaz1234 - mitul3737 - sajibAdhi @@ -448,10 +452,10 @@ branches: # fr approvers users: - huats - - fydrah - Krast76 - sestegra - guillaumebernard84 + - seb-835 teams: [] enforce_admins: null required_linear_history: null @@ -524,7 +528,7 @@ branches: # tr approvers users: - aliok - - halil-bugol + - symys - rwxdash - eminalemdar teams: [] diff --git a/.github/workflows/check-links.yml b/.github/workflows/check-links.yml new file mode 100644 index 0000000000..4a116080d1 --- /dev/null +++ b/.github/workflows/check-links.yml @@ -0,0 +1,18 @@ +name: Links + +on: + pull_request: + +jobs: + build-and-check-links: + name: CHECK LINKS + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + - uses: actions/setup-node@v4 + with: + node-version-file: .nvmrc + cache: npm + cache-dependency-path: package.json + - run: npm install --omit=optional + - run: npm run check:links diff --git a/.github/workflows/es-spellcheck.yml b/.github/workflows/es-spellcheck.yml index 230e7fd5ae..2243a24e10 100644 --- a/.github/workflows/es-spellcheck.yml +++ b/.github/workflows/es-spellcheck.yml @@ -29,6 +29,6 @@ jobs: set -o errexit diff content/es/.wordlist.txt <(LC_ALL= sort -f content/es/.wordlist.txt) - name: GitHub Spellcheck Action - uses: rojopolis/spellcheck-github-actions@0.36.0 + uses: rojopolis/spellcheck-github-actions@0.42.0 with: config_path: content/es/.spellcheck.yml diff --git a/.github/workflows/post-outdated-content-report.yaml b/.github/workflows/post-outdated-content-report.yaml index fb9980f5fd..c45ece5079 100644 --- a/.github/workflows/post-outdated-content-report.yaml +++ b/.github/workflows/post-outdated-content-report.yaml @@ -50,7 +50,7 @@ jobs: # - name: Download output # uses: actions/download-artifact@v3 - name: Download output - uses: dawidd6/action-download-artifact@v3 + uses: dawidd6/action-download-artifact@v6 with: github_token: ${{secrets.GITHUB_TOKEN}} workflow: check-outdated-content.yaml diff --git a/.github/workflows/spellcheck.yml b/.github/workflows/spellcheck.yml index 9b43ed3f89..3691d61469 100644 --- a/.github/workflows/spellcheck.yml +++ b/.github/workflows/spellcheck.yml @@ -25,4 +25,4 @@ jobs: - uses: actions/checkout@v4 - name: GitHub Spellcheck Action - uses: rojopolis/spellcheck-github-actions@0.36.0 + uses: rojopolis/spellcheck-github-actions@0.42.0 diff --git a/.gitignore b/.gitignore index 360dcc9d3b..665996ea17 100644 --- a/.gitignore +++ b/.gitignore @@ -1,10 +1,12 @@ -public/ -resources/ -node_modules/ -.hugo_build.lock .DS_Store +.hugo_build.lock +/public +/resources +node_modules/ +package-lock.json pagefind +tmp/ # Local Netlify folder .netlify diff --git a/.htmltest.yml b/.htmltest.yml new file mode 100644 index 0000000000..005d265767 --- /dev/null +++ b/.htmltest.yml @@ -0,0 +1,8 @@ +# cSpell:ignore pagefind regexs +DirectoryPath: public +# IgnoreDirectoryMissingTrailingSlash: true # FIXME +IgnoreInternalEmptyHash: true # FIXME +IgnoreDirs: + - ^(bn|de|hi|it|ko|pt.*?|ru|tr|ur|zh.*?)/ +IgnoreURLs: # list of regexs of paths or URLs to be ignored + - ^/pagefind diff --git a/.nvmrc b/.nvmrc new file mode 100644 index 0000000000..b009dfb9d9 --- /dev/null +++ b/.nvmrc @@ -0,0 +1 @@ +lts/* diff --git a/CODEOWNERS b/CODEOWNERS index c76477236b..576c5de98a 100644 --- a/CODEOWNERS +++ b/CODEOWNERS @@ -23,8 +23,8 @@ /i18n/ar.toml @TarekMSayed @same7ammar @AShabana @arezk84 # Approvers for Bengali contents -/content/bn/ @Arindam200 @Imtiaz1234 @mitul3737 @sajibAdhi -/i18n/bn.toml @Arindam200 @Imtiaz1234 @mitul3737 @sajibAdhi +/content/bn/ @Arindam200 @asem-hamid @Imtiaz1234 @mitul3737 @sajibAdhi +/i18n/bn.toml @Arindam200 @asem-hamid @Imtiaz1234 @mitul3737 @sajibAdhi # Approvers for German contents /content/de/ @iamNoah1 @DaveVentura @CathPag @bcubk @@ -35,8 +35,8 @@ /i18n/es.toml @raelga @ramrodo @electrocucaracha @krol3 @92nqb # Approvers for French contents -/content/fr/ @huats @fydrah @Krast76 @sestegra @guillaumebernard84 -/i18n/fr.toml @huats @fydrah @Krast76 @sestegra @guillaumebernard84 +/content/fr/ @huats @Krast76 @sestegra @guillaumebernard84 @seb-835 +/i18n/fr.toml @huats @Krast76 @sestegra @guillaumebernard84 @seb-835 # Approvers for Hindi contents /content/hi/ @Garima-Negi @jayesh-srivastava @abhay-raj19 @aj11anuj @kumarankit999 @bishal7679 @@ -63,8 +63,8 @@ /i18n/ru.toml @shurup @kirkonru @tym83 # Approvers for Turkish contents -/content/tr/ @aliok @halil-bugol @rwxdash @eminalemdar -/i18n/tr.toml @aliok @halil-bugol @rwxdash @eminalemdar +/content/tr/ @aliok @symys @rwxdash @eminalemdar +/i18n/tr.toml @aliok @symys @rwxdash @eminalemdar # Approvers for Urdu contents /content/ur/ @Saim-Safdar @waleed318 diff --git a/Makefile b/Makefile index f4cb3e0240..85ae00b701 100644 --- a/Makefile +++ b/Makefile @@ -1,5 +1,27 @@ +HTMLTEST_DIR=tmp +HTMLTEST?=htmltest # Specify as make arg if different +HTMLTEST_ARGS?=--skip-external + +# Use $(HTMLTEST) in PATH, if available; otherwise, we'll get a copy +ifeq (, $(shell which $(HTMLTEST))) +override HTMLTEST=$(HTMLTEST_DIR)/bin/htmltest +ifeq (, $(shell which $(HTMLTEST))) +GET_LINK_CHECKER_IF_NEEDED=get-link-checker +endif +endif + +check-links: $(GET_LINK_CHECKER_IF_NEEDED) + $(HTMLTEST) $(HTMLTEST_ARGS) + +clean: + rm -rf $(HTMLTEST_DIR) public/* resources + +get-link-checker: + rm -Rf $(HTMLTEST_DIR)/bin + curl https://htmltest.wjdp.uk | bash -s -- -b $(HTMLTEST_DIR)/bin + serve: - hugo server \ + npx hugo server \ --disableFastRender \ --buildDrafts \ --buildFuture \ @@ -13,16 +35,15 @@ serve: --gc production-build: - git submodule update --init --recursive - hugo \ - --minify + npm run get:submodule + npx hugo --minify npx -y pagefind --site public preview-build: git submodule update --init --recursive - hugo \ + npx hugo \ --baseURL $(DEPLOY_PRIME_URL) \ --buildDrafts \ --buildFuture \ --minify - npx -y pagefind --site public \ No newline at end of file + npx -y pagefind --site public diff --git a/README.md b/README.md index 9be4799b17..c5fbfd84bc 100644 --- a/README.md +++ b/README.md @@ -13,19 +13,19 @@ If you'd like to help with the glossary we'd love to have your contributions! Pl ## Acknowledgements The Cloud Native Glossary was initiated by the CNCF Marketing Committee -(Business Value Subcommittee) and includes contributions from -[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), -[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/), -[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk), -[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), -[Katelin Ramer](https://www.linkedin.com/in/katelinramer/), -[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca), -and many more contributors. +(Business Value Subcommittee) and includes contributions from +[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), +[Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/), +[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk), +[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), +[Katelin Ramer](https://www.linkedin.com/in/katelinramer/), +[Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca), +and many more contributors. For a complete contributor list, please refer to [this GitHub page](https://github.com/cncf/glossary/graphs/contributors). -The Glossary is maintained by +The Glossary is maintained by [Seokho Son](https://www.linkedin.com/in/seokho-son/), -[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/), +[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/), [Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/), [Nate W.](https://www.linkedin.com/in/nate-double-u/), and [Jorge Castro](https://www.linkedin.com/in/jorge-castro2112/). @@ -43,10 +43,8 @@ All code contributions are under the Apache 2.0 license. Documentation is distri To improve the Cloud Native Glossary site itself, install a local copy with these instructions. Note you must have [npm](https://www.npmjs.com/) and [Hugo](https://gohugo.io/) installed. -``` +```sh git clone https://github.com/cncf/glossary.git -cd glossary -git submodule update --init --recursive npm install ``` diff --git a/content/en/cloud-native-apps.md b/content/en/cloud-native-apps.md index 513bb17102..d57bcdcc9d 100644 --- a/content/en/cloud-native-apps.md +++ b/content/en/cloud-native-apps.md @@ -14,7 +14,7 @@ Cloud native applications today include apps that run in a cloud provider’s da ## Problem it addresses Traditionally, on-premise environments provided compute resources in a fairly bespoke way. -Each datacenter had services that [tightly coupled](/tightly-coupled-architectures/) applications to specific environments, +Each datacenter had services that [tightly coupled](/tightly-coupled-architecture/) applications to specific environments, often relying heavily on manual provisioning for infrastructure, like [virtual machines](/virtual-machine/) and services. This, in turn, constrained developers and their applications to that specific datacenter. Applications that weren't designed for the cloud couldn't take advantage of a cloud environment’s resiliency and scaling capabilities. diff --git a/content/en/container-orchestration.md b/content/en/container-orchestration.md index 5cc57322ff..124d2dce82 100644 --- a/content/en/container-orchestration.md +++ b/content/en/container-orchestration.md @@ -4,19 +4,19 @@ status: Completed category: Concept --- -[Container](/container/) orchestration refers to managing and automating the lifecycle of [containerized](/containerization/) applications in dynamic environments. -It's executed through a container orchestrator (in most cases, [Kubernetes](/kubernetes)), which enables deployments, (auto)scaling, auto-healing, and monitoring. +[Container](/container/) orchestration refers to managing and automating the lifecycle of [containerized](/containerization/) applications in dynamic environments. +It's executed through a container orchestrator (in most cases, [Kubernetes](/kubernetes/)), which enables deployments, (auto)scaling, auto-healing, and monitoring. Orchestration is a metaphor: -The orchestration tool conducts containers like a music conductor, ensuring every container (or musician) does what it should. +The orchestration tool conducts containers like a music conductor, ensuring every container (or musician) does what it should. -## Problem it addresses +## Problem it addresses -Managing [microservices](/microservices), security, and network communication at scale — and [distributed systems](/distributed-systems) in general — is hard, if not impossible, to manage manually. -Container orchestration allows users to automate all these management tasks. +Managing [microservices](/microservices-architecture/), security, and network communication at scale — and [distributed systems](/distributed-systems/) in general — is hard, if not impossible, to manage manually. +Container orchestration allows users to automate all these management tasks. ## How it helps -Container orchestration tools allow users to determine a system's state. +Container orchestration tools allow users to determine a system's state. First, they declare how it should look like (e.g., x containers, y pods, etc.). -The orchestration tool will then automatically monitor the infrastructure and correct it if its state deviates from the declared one (e.g., spin up a new container if one crashes). +The orchestration tool will then automatically monitor the infrastructure and correct it if its state deviates from the declared one (e.g., spin up a new container if one crashes). This automation simplifies many of the engineering teams' otherwise highly manual and complex operational tasks, including provisioning, deployment, scaling (up and down), networking, load balancing, and other activities. diff --git a/content/en/containerization.md b/content/en/containerization.md index 8f51c9aedc..c4514feba4 100644 --- a/content/en/containerization.md +++ b/content/en/containerization.md @@ -5,10 +5,7 @@ category: Technology tags: ["application", "", ""] --- -Containerization is the process of bundling an application and its dependencies into a container image. -The container build process requires adherence to the [Open Container Initiative](https://opencontainers.org) (OCI) standard. -As long as the output is a container image that adheres to this standard, which containerization tool is used doesn't matter. - +Containerization is the process of packaging of application code including libraries and dependencies required to run the code into a single lightweight executable—called [container image](/container-image/). ## Problem it addresses Before [containers](/container/) became prevalent, organizations relied on [virtual machines](/virtual-machine/) (VMs) to diff --git a/content/en/devops.md b/content/en/devops.md index 271e0147fb..d1169cefd4 100644 --- a/content/en/devops.md +++ b/content/en/devops.md @@ -11,7 +11,7 @@ DevOps calls for groups of engineers that work on small components (versus an en ## Problem it addresses -Traditionally, in complex organizations with [tightly-coupled](/tightly-coupled-architectures/) [monolithic apps](/monolithic-apps/), +Traditionally, in complex organizations with [tightly-coupled](/tightly-coupled-architecture/) [monolithic apps](/monolithic-apps/), work was generally fragmented between multiple groups. This led to numerous handoffs and long lead times. Each time a component or update was ready, it was placed in a queue for the next team. diff --git a/content/en/function-as-a-service.md b/content/en/function-as-a-service.md index 61550110b8..7aabd9190d 100644 --- a/content/en/function-as-a-service.md +++ b/content/en/function-as-a-service.md @@ -5,14 +5,14 @@ category: Technology tags: ["infrastructure", "", ""] --- -Function as a Service (FaaS) is a cloud computing model that provides a platform for executing event-triggered functions, allowing for automatic scaling without manual intervention. +Function as a Service (FaaS) is a [cloud computing](/cloud-computing/) model that provides a platform for executing event-triggered functions, allowing for automatic scaling without manual intervention. At its essence, FaaS enables the deployment of individual functions that are activated by specific events, operate on a short-term basis, and then shut down, ensuring resources are not wasted. -This model supports an [autoscaling](/auto-scaling/) feature, enabling a function instance to be initiated per request and terminated post-execution, emphasizing its stateless nature. -Consequently, FaaS platforms can implement a true pay-as-you-go billing approach, eliminating costs when functions are dormant, distinguishing it from other models like [Platform as a Service (PaaS)](/platform-as-a-service/), which require continuous resource availability. +This model supports an [autoscaling](/auto-scaling/) feature, enabling a function instance to be initiated per request and terminated post-execution, emphasizing its [stateless](/stateless-apps/) nature. +Consequently, FaaS platforms can implement a true pay-as-you-go billing approach, eliminating costs when functions are dormant, distinguishing it from other models like Platform as a Service (PaaS), which require continuous resource availability. ## Problem it addresses -Traditionally, businesses have relied on maintaining on-premises data centers, necessitating substantial investment in hardware, software, and personnel. +Traditionally, businesses have relied on maintaining on-premises [data centers](/data-center/), necessitating substantial investment in hardware, software, and personnel. This setup demands resources to be scaled to peak demand, resulting in underutilized assets during downtime. Moreover, rapid business growth can overwhelm IT capabilities, leading to operational inefficiencies. In contrast, [Infrastructure-as-a-Service (IaaS)](/infrastructure-as-a-service/) models, while offering cloud-based solutions, still place the onus of scaling resources on the user, requiring payment for continuous server availability irrespective of actual usage. @@ -23,6 +23,6 @@ FaaS gives developers an [abstraction](/abstraction/) for running web applicatio For example, an action such as uploading a file could trigger custom code that transcodes the file into various formats. The FaaS infrastructure automatically adjusts resources to match demand, freeing developers from the complexities of coding for [scalability](/scalability/). Charges apply solely for the duration of computation, ensuring no costs accrue when functions are inactive. - + For more information, refer to the [Serverless](/serverless/) glossary entry. -Although "serverless" and "FaaS" are often used as interchangeable terms, they embody distinct concepts. \ No newline at end of file +Although "serverless" and "FaaS" are often used as interchangeable terms, they embody distinct concepts. diff --git a/content/en/horizontal-scaling.md b/content/en/horizontal-scaling.md index 99b1f71641..40f1abd766 100644 --- a/content/en/horizontal-scaling.md +++ b/content/en/horizontal-scaling.md @@ -7,10 +7,11 @@ tags: ["infrastructure", "", ""] Horizontal scaling is a technique where a system's capacity is increased by adding more [nodes](/nodes/) versus adding more compute resources to individual nodes (the latter being known as [vertical scaling](/vertical-scaling/)). -Let's say, we have a system of 4GB RAM and want to increase its capacity to 16GB RAM, -scaling it horizontally means doing so by adding 4 x 4GB RAM rather than switching to a 16GB RAM system. +Let's say, we have a system of 4GB RAM and want to increase its capacity to 16GB RAM. +Scaling it horizontally means doing so by adding 3 nodes x 4GB RAM rather than switching to +a 16GB RAM system. -This approach enhances the performance of an application by adding new instances, or [nodes](/nodes/), +This approach enhances the performance of an application by adding new instances, or nodes, to better distribute the workload. In simple words, it aims to decrease the server's load rather than expanding capacity of the individual server. diff --git a/content/en/loosely-coupled-architecture.md b/content/en/loosely-coupled-architecture.md index 87cada947b..0bccb3a1d9 100644 --- a/content/en/loosely-coupled-architecture.md +++ b/content/en/loosely-coupled-architecture.md @@ -5,15 +5,15 @@ category: Property tags: ["fundamental", "architecture", "property"] --- -Loosely coupled architecture is an architectural style -where the individual components of an application are built independently from one another -(the opposite paradigm of [tightly coupled architectures](/tightly-coupled-architectures/)). -Each component, sometimes referred to as a [microservice](/microservices-architecture/), is built to perform a specific function -in a way that can be used by any number of other services. -This pattern is generally slower to implement than tightly coupled architecture +Loosely coupled architecture is an architectural style +where the individual components of an application are built independently from one another +(the opposite paradigm of [tightly coupled architectures](/tightly-coupled-architecture/)). +Each component, sometimes referred to as a [microservice](/microservices-architecture/), is built to perform a specific function +in a way that can be used by any number of other services. +This pattern is generally slower to implement than tightly coupled architecture but has a number of benefits, particularly as applications scale. -Loosely coupled applications allow teams to develop features, deploy, and scale independently, -which allows organizations to iterate quickly on individual components. -Application development is faster and teams can be structured around their competency, -focusing on their specific application. +Loosely coupled applications allow teams to develop features, deploy, and scale independently, +which allows organizations to iterate quickly on individual components. +Application development is faster and teams can be structured around their competency, +focusing on their specific application. diff --git a/content/en/microservices-architecture.md b/content/en/microservices-architecture.md index 9badc03ad0..81c11b5117 100644 --- a/content/en/microservices-architecture.md +++ b/content/en/microservices-architecture.md @@ -5,31 +5,31 @@ tags: ["architecture", "fundamental", ""] --- A microservices architecture is an architectural approach that breaks applications into individual independent (micro)[services](/service/), with each service focused on a specific functionality. -These services work together closely, appearing to the end user as a single entity. -Take Netflix as an example. -Its interface allows you to access, search, and preview videos. +These services work together closely, appearing to the end user as a single entity. +Take Netflix as an example. +Its interface allows you to access, search, and preview videos. These capabilities are likely powered by smaller services that each handle one functionality, e.g., authentication, search, and running previews in your browser. This architectural approach allows developers to push out new features or update functionality much faster than if they were all tightly coupled, such as in a [monolithic application](/monolithic-apps/) (more to that below). ## Problem it addresses -Applications are made up of different parts, each responsible for a specific capability. -Demand for a particular functionality will not necessarily increase or decrease with demand for other app parts. -Going back to our Netflix example. -Let's say that after a big marketing campaign, Netflix experiences a big spike in signups, but streaming has remained more or less stable in the early hours of the day. -The surge in signups demands more signup capacity. -Traditionally (monolithic approach), the entire app would have to be [scaled](/scalability/) to accommodate the increase — a very inefficient use of resources. +Applications are made up of different parts, each responsible for a specific capability. +Demand for a particular functionality will not necessarily increase or decrease with demand for other app parts. +Going back to our Netflix example. +Let's say that after a big marketing campaign, Netflix experiences a big spike in signups, but streaming has remained more or less stable in the early hours of the day. +The surge in signups demands more signup capacity. +Traditionally (monolithic approach), the entire app would have to be [scaled](/scalability/) to accommodate the increase — a very inefficient use of resources. -Monolithic architectures also make it easy for developers to succumb to design pitfalls. -Because all the code is in one place, it is easier to make that code [tightly coupled](/tightly-coupled-architectures/) and harder to enforce the principle of separation of concerns. -Monoliths also often require developers to understand the entire codebase before deploying any changes. -Microservices architecture is a response to these challenges. +Monolithic architectures also make it easy for developers to succumb to design pitfalls. +Because all the code is in one place, it is easier to make that code [tightly coupled](/tightly-coupled-architecture/) and harder to enforce the principle of separation of concerns. +Monoliths also often require developers to understand the entire codebase before deploying any changes. +Microservices architecture is a response to these challenges. ## How it helps -Separating functionality into different microservices makes them easier to deploy, update, and scale independently. -It also allows different teams to work simultaneously on a small part of a bigger application without inadvertently negatively impacting the rest of the app. -While a microservices architecture solves many problems, it also creates operational overhead — the things you need to deploy and keep track of increase by order of magnitude. +Separating functionality into different microservices makes them easier to deploy, update, and scale independently. +It also allows different teams to work simultaneously on a small part of a bigger application without inadvertently negatively impacting the rest of the app. +While a microservices architecture solves many problems, it also creates operational overhead — the things you need to deploy and keep track of increase by order of magnitude. Many [cloud-native technologies](/cloud-native-tech/) aim to make microservices easier to deploy and manage. diff --git a/content/en/security-chaos-engineering.md b/content/en/security-chaos-engineering.md index 0affd08570..3d6dcc9b9b 100644 --- a/content/en/security-chaos-engineering.md +++ b/content/en/security-chaos-engineering.md @@ -29,5 +29,5 @@ Engineering teams will progressively improve the understanding for security conc within complex infrastructure, platforms, and distributed systems. SCE improves the cyber resiliency of the entire product, uncovers hidden security issues, exposes the classical blind spots, and prepares teams for critical edge cases. -This approach helps SREs, [DevOps](/devops/) and [DevSecOps](/devsecops/) engineers +This approach helps [SREs](/site-reliability-engineering/), [DevOps](/devops/) and [DevSecOps](/devsecops/) engineers create confidence in the system, increase cyber resiliency and improve observability. diff --git a/content/en/serverless.md b/content/en/serverless.md index 17a824a49c..987d3451c6 100644 --- a/content/en/serverless.md +++ b/content/en/serverless.md @@ -9,12 +9,12 @@ tags: ["architecture", "", ""] Serverless Computing [abstracts](/abstraction/) servers away from the user. Operational management falls to the service provider, including handling physical machines and VM provisioning. Service providers can be public cloud entities or internal IT departments serving their development teams. -These providers offer user interfaces such as SDKs, CLIs, or OCI-compliant runtimes, focusing on code and deployment tasks. +These providers offer user interfaces such as SDKs, CLIs, or OCI-compliant [runtimes](/runtime/), focusing on code and deployment tasks. Charges are based on a pay-per-use model. [Scaling](/scalability/) and resource provisioning for computing, storage, or networking are automatically adjusted based on application demand without user intervention. A serverless platform provider consolidates resources to serve multiple users on a single physical machine, ensuring isolation through virtualization, especially with [VMs](/virtual-machine/). -Serverless is a comprehensive term encompassing services with these attributes, extending from [Platform-as-a-Service (PaaS)](/platform-as-a-service/) to [Software-as-a-Service (SaaS)](/software-as-a-service/). +Serverless is a comprehensive term encompassing services with these attributes, extending from Platform-as-a-Service (PaaS) to Software-as-a-Service (SaaS). ## Problem it addresses diff --git a/content/en/stateful-apps.md b/content/en/stateful-apps.md index a59499c64e..4412df8f9e 100644 --- a/content/en/stateful-apps.md +++ b/content/en/stateful-apps.md @@ -5,12 +5,12 @@ category: Property tags: ["fundamental", "application", "property"] --- -When we speak of stateful (and [stateless](/stateless-apps/)) apps, -state refers to any data the app needs to store to function as designed. -Any kind of online shop that remembers your cart is a stateful app for example. +When we speak of stateful (and [stateless](/stateless-apps/)) apps, +state refers to any data the app needs to store to function as designed. +Any kind of online shop that remembers your cart is a stateful app for example. -Today, most applications we use are at least partly stateful. In cloud native environments though, -stateful apps are a challenge. This is because [cloud native apps](/cloud-native-apps) are very dynamic. +Today, most applications we use are at least partly stateful. In cloud native environments though, +stateful apps are a challenge. This is because [cloud native apps](/cloud-native-apps/) are very dynamic. They can be scaled up and down, restarted, and moved around but still need to be able to access their state. Therefore, stateful apps needs some kind of storage that is accessible from anywhere, like databases. diff --git a/content/en/stateless-apps.md b/content/en/stateless-apps.md index 6cf8647441..c9f18cbc8b 100644 --- a/content/en/stateless-apps.md +++ b/content/en/stateless-apps.md @@ -5,11 +5,10 @@ tags: ["fundamental", "application", "property"] --- -Stateless applications process requests as if each request were the first it's ever been sent. -The app doesn't "remember" previous interactions or user session data. -Data from previous interactions is referred to as state, and since that data isn't stored anywhere, these apps are state*less*. +Stateless applications handle each request independently without remembering any previous interactions or user data. +Data from previous interactions is referred to as state since that data isn’t stored anywhere, these apps are state*less*. Here's an example: When you use a search engine, and that search is interrupted (e.g., the window is closed), those search results are lost. You'll need to start all over. -On the other hand, applications that process requests while considering previous interactions are called [stateful applications](/stateful-apps/). \ No newline at end of file +On the other hand, applications that process requests while considering previous interactions are called [stateful applications](/stateful-apps/). diff --git a/content/en/webassembly.md b/content/en/webassembly.md new file mode 100644 index 0000000000..da15a5f2ad --- /dev/null +++ b/content/en/webassembly.md @@ -0,0 +1,23 @@ +--- +title: WebAssembly +status: Completed +category: Concept +tags: ["Application", "", ""] +--- + +WebAssembly (often abbreviated as Wasm) is a binary instruction format designed as a portable target for compiling high-level languages like C, C++, Rust, and others. It enables deployment on the web for client-side and server-side applications. +It is a low-level bytecode format that can be executed in a virtual machine, typically integrated into web browsers. While initially developed for the web, Web Assembly is a Universal Runtime and sees applications in non-web environments such as IoT and edge devices. + +## Problem it addresses + +For many years, the LAMP (Linux Apache MySQL PHP) stack was the template for web-based applications. Later, Javascript became the king of front-end application development and node. js based applications became the norm. As the technology around the web evolved, it heavily favored interpreted languages, which are typically less performant than compiled languages, even with technological advancements. +While JavaScript has improved over the years, it still faces performance limitations when executing computationally intensive tasks. +Interpreted languages that are compiled at runtime often see performance and functionality issues as the code is executed across different environments. Conversely, compiled binaries typically run the same as long as they've compiled correctly. However, historically, a compiled binary has been less suited for the web environment. + +## How it helps + +WebAssembly provides a low-level binary format that can be executed at near-native speeds, enabling web applications to perform complex computations efficiently. +It allows developers to build web applications by leveraging their existing skills in languages like C, C++, Rust, and others. +This opens up new possibilities and allows developers to reuse existing codebases and libraries. +Also, WebAssembly modules can run consistently across different browsers, operating systems, and devices, reducing the need for platform-specific code. +Overall, WebAssembly addresses performance limitations, language restrictions, code portability, security concerns, code size, and loading time issues, providing a more robust and flexible environment for web application development. diff --git a/content/es/.wordlist.txt b/content/es/.wordlist.txt index 0eb3a8724c..6470a3a8b9 100644 --- a/content/es/.wordlist.txt +++ b/content/es/.wordlist.txt @@ -1,4 +1,5 @@ -add +accionables +Add Agreement Amazon an @@ -22,6 +23,7 @@ bare based becoming Benavides +Berkeley blob blue branch @@ -32,6 +34,7 @@ BVS BY CaaS calendar +call Canary CAPEX Carol @@ -49,6 +52,7 @@ CI cifrada CLA Client +CLIs Cloud clúster clústeres @@ -95,6 +99,7 @@ directly Docs draft Dropbox +eBPF edit ej empoderen @@ -113,6 +118,7 @@ externalizar FaaS faltantes Feedback +Filter Finance Firewall first @@ -161,6 +167,7 @@ Jones Kafka Katelin Kubernetes +Landscape Language laptop Layer @@ -188,6 +195,7 @@ Microsoft Mike mitigarse monitorea +monitoreados monitorean monitorear monitoreará @@ -215,8 +223,11 @@ on-premises Open PaaS PaC +packet Paganini platform +Pod +pods Política portable pr @@ -249,6 +260,7 @@ SaaS Salesforce SCE scripts +SDK search Secure security @@ -264,7 +276,7 @@ sobreescriba Sockets Spanish spell -SRE +sre SSL stack Started @@ -276,6 +288,7 @@ submitting subrúbricas Subversion supercomputadoras +system tags TCP technology diff --git a/content/es/application-programming-interface.md b/content/es/application-programming-interface.md index d00bc44bcc..c9360b09b4 100644 --- a/content/es/application-programming-interface.md +++ b/content/es/application-programming-interface.md @@ -21,4 +21,4 @@ Sin un marco compartido, la [escalabilidad](/es/scalability/) y la integración Las APIs permiten a los programas o aplicaciones interactuar y compartir información en una manera definida y entendible. Estas están construidas en bloques para aplicaciones modernas y proveen a los desarrolladores una manera de integrar aplicaciones. -Siempre que escuche acerca de [microservicios](/es/microservices/) trabajando en conjunto, se puede inferir que están interactuando a través de una API. +Siempre que escuche acerca de [microservicios](/es/microservices-architecture/) trabajando en conjunto, se puede inferir que están interactuando a través de una API. diff --git a/content/es/auto-scaling.md b/content/es/auto-scaling.md index 7196b39343..248a663847 100644 --- a/content/es/auto-scaling.md +++ b/content/es/auto-scaling.md @@ -5,7 +5,7 @@ category: Propiedad tags: ["infraestructura", "", ""] --- -El autoescalado es la habilidad de un sistema para [escalar](/es/scalability) automáticamente, en términos de recursos computacionales. +El autoescalado es la habilidad de un sistema para [escalar](/es/scalability/) automáticamente, en términos de recursos computacionales. Con un sistema de autoescalado, los recursos son agregados automáticamente cuando se necesitan y pueden escalar para cumplir con la demanda fluctuante de los usuarios. El proceso de autoescalado varía y es configurable para escalar basado en diferentes métricas, como son la memoria o el uso de CPU. Los servicios gestionados en la nube son los que están asociados típicamente con esta funcionalidad de autoescalado @@ -15,7 +15,7 @@ Anteriormente, la infraestructura y las aplicaciones eran diseñadas para consid Esta arquitectura implicaba que había más recursos que eran desaprovechados o con cambios rígidos frente a la demanda de los usuarios. La rigidez en este caso, incrementa el coste y puede suponer una pérdida de negocios debido a problemas de capacidad. -Aprovechando la nube, la [virtualización](/es/virtualization) y la [contenerización](/es/containerization/) de aplicaciones y sus dependencias, +Aprovechando la nube, la [virtualización](/es/virtualization/) y la [contenerización](/es/containerization/) de aplicaciones y sus dependencias, las organizaciones pueden construir aplicaciones que escalan de manera acorde a la demanda de los usuarios. Se pueden monitorear la demanda de las aplicaciones y de manera automática escalar las mismas, proporcionando una experiencia al usuario final óptima. Tomemos el ejemplo del aumento de la audiencia de Netflix todos los viernes por la noche. diff --git a/content/es/chaos-engineering.md b/content/es/chaos-engineering.md index fb1d5953ff..1d23e344f9 100644 --- a/content/es/chaos-engineering.md +++ b/content/es/chaos-engineering.md @@ -15,7 +15,7 @@ técnicas para el incremento de la resiliencia del producto y de la [confiabilid La capacidad del sistema para tolerar fallos al mismo tiempo que aseguran una calidad de servicio adecuado suele ser un típico requerimiento de desarrollo de software. Existen muchos aspectos involucrados al momento de la indisponibilidad de una aplicación, -como la infraestructura, la plataforma o otras partes del ecosistema de las aplicaciones basadas en ([microservicios](/es/microservices/)). +como la infraestructura, la plataforma o otras partes del ecosistema de las aplicaciones basadas en ([microservicios](/es/microservices-architecture/)). La alta frecuencia de despliegues de funcionalidades hacia el ambiente productivo puede aumentar la posibilidad de un incidente crítico o estar fuera de línea, generando consecuencias considerables para el negocio. diff --git a/content/es/cloud-native-apps.md b/content/es/cloud-native-apps.md index de59c39583..a8d639b691 100644 --- a/content/es/cloud-native-apps.md +++ b/content/es/cloud-native-apps.md @@ -5,7 +5,7 @@ category: Concepto tags: ["aplicación", "fundamento", ""] --- -Las aplicaciones nativas para la nube están diseñadas específicamente para aprovechar las innovaciones en [computación en la nube](/es/cloud_computing/). +Las aplicaciones nativas para la nube están diseñadas específicamente para aprovechar las innovaciones en [computación en la nube](/es/cloud-computing/). Estas aplicaciones se integran fácilmente con sus respectivas arquitecturas en la nube, aprovechando los recursos de la nube y las capacidades de [escalado](/es/scalability/). También se refiere a las aplicaciones que aprovechan las innovaciones en infraestructura impulsadas por la computación en la nube. diff --git a/content/es/cloud-native-tech.md b/content/es/cloud-native-tech.md index 82ab678600..e5bb07e97e 100644 --- a/content/es/cloud-native-tech.md +++ b/content/es/cloud-native-tech.md @@ -9,7 +9,7 @@ Las tecnologías nativas para la nube, también denominadas como stack nativo pa son las tecnologías que se utilizan para crear [aplicaciones nativas para la nube](/es/cloud-native-apps/). Estas tecnologías permiten a las organizaciones crear y ejecutar aplicaciones escalables en entornos modernos y dinámicos como nubes públicas, privadas e híbridas, -mientras aprovechan al máximo los beneficios de la [computación en la nube](/es/cloud_computing/). +mientras aprovechan al máximo los beneficios de la [computación en la nube](/es/cloud-computing/). Están diseñadas desde cero para explotar las capacidades de la computación en la nube y los contenedores, las mallas de servicio, los microservicios, y la infraestructura inmutable ejemplifican este enfoque. diff --git a/content/es/cluster.md b/content/es/cluster.md index a161812388..afd4b5157c 100644 --- a/content/es/cluster.md +++ b/content/es/cluster.md @@ -15,7 +15,7 @@ El conjunto de todos estos servicios [contenedorizados](/es/containerization/), Un software que es ejecutado en un solo ordenador es un único punto de fallo — Si este ordenador falla, o alguien por accidente desconecta el cable de alimentación, algún sistema crítico para el negocio puede quedar fuera de funcionamiento. -Es por esto que el software moderno se construye generalmente como [aplicaciones distribuidas](/es/distributed-apps), agrupadas en clústeres. +Es por esto que el software moderno se construye generalmente como [aplicaciones distribuidas](/es/distributed-apps/), agrupadas en clústeres. ## ¿Cómo ayuda? diff --git a/content/es/container-image.md b/content/es/container-image.md index 4cbade92a9..c52e720f55 100644 --- a/content/es/container-image.md +++ b/content/es/container-image.md @@ -8,7 +8,7 @@ tags: ["", "", ""] Una imagen es un fichero estático e inmutable que contiene las dependencias para la creación de un [contenedor](/es/container/). Estas dependencias pueden incluir un archivo binario ejecutable, librerías del sistema, herramientas del sistema, variables de entorno y otras configuraciones de plataforma necesarias. -Las imágenes son el resultado de la [contenerización](/es/containerization) de una aplicación y típicamente están guardadas en los registros de contenedor, +Las imágenes son el resultado de la [contenerización](/es/containerization/) de una aplicación y típicamente están guardadas en los registros de contenedor, donde pueden ser descargados para ser ejecutados como procesos aislados usando un Container Runtime Interface (CRI). El framework de una imagen debe de seguir el esquema estándar definido por el Open Container Initiative (OCI). diff --git a/content/es/container-orchestration.md b/content/es/container-orchestration.md index 70dbd33b2b..c34e736f9a 100644 --- a/content/es/container-orchestration.md +++ b/content/es/container-orchestration.md @@ -5,13 +5,13 @@ category: Concepto --- La orquestación de [contenedores](/es/container/) se refiere al manejo y automatización del ciclo de vida de una aplicación contenedorizada en ambientes dinámicos. -Es ejecutada a través de un orquestador de contenedores (por lo general, [Kubernetes](/es/kubernetes)), el cual ofrece despliegues, autoescalado, auto reparación y monitoreo. +Es ejecutada a través de un orquestador de contenedores (por lo general, [Kubernetes](/es/kubernetes/)), el cual ofrece despliegues, autoescalado, auto reparación y monitoreo. La orquestación es metafórica: Al igual que un director de orquesta, la herramienta de orquestación dirige a los contenedores asegurándose que cada contenedor (como un músico) haga lo que debe hacer. ## Problema que aborda -El manejo de [microservicios](/es/microservices), la seguridad, y la comunicación de red a escala - y los [sistemas distribuidos](/es/distributed-systems) en general - es muy difícil, casi imposible de hacerse manualmente. +El manejo de [microservicios](/es/microservices-architecture/), la seguridad, y la comunicación de red a escala - y los [sistemas distribuidos](/es/distributed-systems/) en general - es muy difícil, casi imposible de hacerse manualmente. La orquestación de contenedores permite a los usuarios automatizar todas estas tareas operacionales. ## ¿Cómo ayuda? diff --git a/content/es/distributed-apps.md b/content/es/distributed-apps.md index 69c43a547d..747e82a3c6 100644 --- a/content/es/distributed-apps.md +++ b/content/es/distributed-apps.md @@ -6,7 +6,7 @@ tags: ["arquitectura", "", ""] --- Una aplicación distribuida es una aplicación en la que la funcionalidad se divide en múltiples partes independientes más pequeñas. -Las aplicaciones distribuidas suelen estar formadas por componentes individuales llamados [microservicios](/es/microservices/) +Las aplicaciones distribuidas suelen estar formadas por componentes individuales llamados [microservicios](/es/microservices-architecture/) que se ocupan de diferentes responsabilidades dentro de una aplicación más extensa. En un entorno nativo para la nube, los componentes individuales suelen ejecutarse como [contenedores](/es/container/) en un [clúster](/es/cluster/). diff --git a/content/es/ebpf.md b/content/es/ebpf.md new file mode 100644 index 0000000000..ced1fdca64 --- /dev/null +++ b/content/es/ebpf.md @@ -0,0 +1,40 @@ +--- +title: eBPF +status: Completed +category: Tecnología +tags: ["arquitectura", "redes", "seguridad"] +--- + +eBPF, o "extended Berkeley Packet Filter", es una tecnología que permite a pequeños programas o scripts aislados ejecutarse en el espacio del kernel de un sistema Linux sin necesidad de cambiar el código fuente ni cargar módulos al kernel Linux. + +Un sistema Linux tiene dos espacios: el de kernel y el de usuario. +El kernel representa el sistema operativo y es la única parte +con acceso ilimitado al hardware. + +Las aplicaciones quedan en el espacio de usuario y, cuando necesitan permisos más elevados, +envían una solicitud al kernel. +Para aplicaciones que requieren más flexibilidad, como el acceso directo al hardware, +el kernel puede ser extendido mediante lo que se conoce como el enfoque de "módulos +del kernel Linux". Este enfoque amplía la funcionalidad predeterminada del kernel, +permitiendo a las aplicaciones un acceso más profundo a los componentes básicos. +Sin embargo, este enfoque también introduce riesgos de seguridad, lo que hace que eBPF sea una alternativa atractiva. + +## Problema que soluciona +Típicamente, las aplicaciones se ejecutan en el espacio de usuario y, si la aplicación requiere algunos privilegios del kernel (por ejemplo, para acceder a algún hardware), +lo solicita al kernel a través de una llamada al sistema conocida como "system call". +En la mayoría de los casos, este enfoque funciona bien. Sin embargo, hay casos en los que los desarrolladores requieren más flexibilidad para acceder al sistema a nivel bajo. +La observabilidad, la seguridad y las redes son buenos ejemplos. +Para lograrlo, podemos utilizar módulos del kernel Linux, ampliando la base del kernel sin modificar el código principal del kernel. +Si bien hay beneficios en el uso de módulos del kernel Linux, también introduce riesgos de seguridad. +Como operan dentro del espacio del kernel, los módulos del kernel Linux pueden hacer que el kernel falle y, cuando el kernel falla, también lo hace toda la máquina. +Además, los módulos del kernel tienen privilegios elevados y acceso directo a los recursos del sistema. Y si no están adecuadamente aseguradas, los atacantes pueden explotarlas. + +## ¿Cómo ayuda? +eBPF proporciona un entorno más controlado y contenido para ejecutar programas definidos por el usuario que los módulos del kernel Linux. +Se ejecuta en un entorno aislado dentro del kernel, proporcionando aislamiento y mitigando riesgos. +Si se explota una vulnerabilidad o defecto en un programa eBPF, su impacto generalmente se limita al entorno aislado. +Además, antes de que un programa eBPF pueda comenzar a ejecutarse en el kernel, debe pasar por algunas verificaciones. +El componente verificador verifica el programa eBPF en busca de posibles violaciones de seguridad, +como el acceso a memoria fuera de límites, ciclos infinitos y funciones del kernel no autorizadas. +De esta manera, asegura que el programa no entre en un ciclos infinitos y provoque un fallo del kernel. +Estos controles de seguridad hacen que eBPF sea una opción más segura para ejecutar aplicaciones en el kernel Linux que los módulos del kernel Linux. \ No newline at end of file diff --git a/content/es/firewall.md b/content/es/firewall.md index 206fe9036b..8b7a8f361e 100644 --- a/content/es/firewall.md +++ b/content/es/firewall.md @@ -13,7 +13,7 @@ Los Firewall pueden ser hardware, software o una combinación de ambos. Por defecto, una red permite a cualquier entidad ingresar y egresar en tanto y en cuanto se respeten las reglas de enrutamiento. Por este motivo, es un desafío asegurar una red. -Por ejemplo, en una aplicación bancaria basada en [microservicios](/es/microservices/), los componentes se comunican entre sí +Por ejemplo, en una aplicación bancaria basada en [microservicios](/es/microservices-architecture/), los componentes se comunican entre sí transmitiendo información financiera sensible a través de la red que comparten. Un actor malicioso podría infiltrarse en esta red, interceptar la comunicación y hacer daño si no hubiera un Firewall. diff --git a/content/es/horizontal-scaling.md b/content/es/horizontal-scaling.md index 568c13177c..89be7949fc 100644 --- a/content/es/horizontal-scaling.md +++ b/content/es/horizontal-scaling.md @@ -5,12 +5,12 @@ category: Concepto tags: ["infraestructura", "", ""] --- -Escalado horizontal es una técnica donde la capacidad del sistema es incrementada agregando más [nodos](/es/nodes) +Escalado horizontal es una técnica donde la capacidad del sistema es incrementada agregando más [nodos](/es/nodes/) en vez de agregar más recursos computacionales a nodos individuales (conocido como [escalado vertical](/es/vertical-scaling/)). Como ejemplo, digamos que tenemos un sistema con 4 GB de memoria y queremos incrementar su capacidad a 16 GB, escalar horizontalmente significa agregar 4 x 4 GB en vez de cambiar a un sistema de 16 GB. -Este método mejora el funcionamiento de una aplicación agregando nuevas instancias o [nodos](/es/nodes), +Este método mejora el funcionamiento de una aplicación agregando nuevas instancias o [nodos](/es/nodes/), para distribuir de mejor manera la carga de trabajo. En concreto, apunta a disminuir la carga del servidor en vez de expandir la capacidad de cada uno individualmente. diff --git a/content/es/infrastructure-as-a-service.md b/content/es/infrastructure-as-a-service.md index dd2aaf0c8c..6c22ae455f 100644 --- a/content/es/infrastructure-as-a-service.md +++ b/content/es/infrastructure-as-a-service.md @@ -5,8 +5,8 @@ category: Tecnología tags: ["infraestructura", "", ""] --- -Infraestructura como Servicio, o IaaS, es un modelo de servicio de [computación en la nube](/es/cloud_computing/) que -ofrece recursos de cómputo, almacenamiento y red mediante servidores [físicos](/es/bare_metal_machine/) o [virtualizados](/es/virtualization/) +Infraestructura como Servicio, o IaaS, es un modelo de servicio de [computación en la nube](/es/cloud-computing/) que +ofrece recursos de cómputo, almacenamiento y red mediante servidores [físicos](/es/bare-metal-machine/) o [virtualizados](/es/virtualization/) suministrados bajo demanda en un modelo de pago por uso. Los proveedores de la nube poseen y operan el hardware y el software, a disposición de los consumidores en despliegues de nube pública, privada o híbrida. diff --git a/content/es/load-balancer.md b/content/es/load-balancer.md index 7010968d76..1bd5745603 100644 --- a/content/es/load-balancer.md +++ b/content/es/load-balancer.md @@ -6,7 +6,7 @@ tags: ["infraestructura", "redes", ""] --- Un balanceador de carga es una herramienta que distribuye eficientemente las solicitudes entrantes entre varias instancias de una aplicación. -Tome una arquitectura de [microservicio](/es/microservices/) como ejemplo, donde cada servicio se puede [escalar horizontalmente](/es/horizontal-scaling/). +Tome una arquitectura de [microservicio](/es/microservices-architecture/) como ejemplo, donde cada servicio se puede [escalar horizontalmente](/es/horizontal-scaling/). Un balanceador de carga se encuentra frente a un microservicio escalado y garantiza que ninguna instancia reciba la mayor parte de las solicitudes. Los balanceadores de carga pueden estar basados en software o hardware. diff --git a/content/es/loosely-coupled-architecture.md b/content/es/loosely-coupled-architecture.md index 428680ccd7..0f23e17e8d 100644 --- a/content/es/loosely-coupled-architecture.md +++ b/content/es/loosely-coupled-architecture.md @@ -8,7 +8,7 @@ tags: ["fundamento", "arquitectura", "propiedad"] La arquitectura débilmente acoplada es un tipo de arquitectura en donde los componentes individuales de una aplicación se construyen de manera independiente unos de los otros (es el paradigma opuesto a la [arquitectura fuertemente acoplada](/es/tightly-coupled-architectures/)). -Cada componente, a veces denominado [microservicio](/es/microservices/), +Cada componente, a veces denominado [microservicio](/es/microservices-architecture/), está diseñado para realizar una función específica de manera que pueda ser utilizado por cualquier número de servicios. Este patrón es generalmente más lento de implementar que la arquitectura estrechamente acoplada, pero tiene una serie de beneficios, particularmente a medida que las aplicaciones escalan. diff --git a/content/es/monolithic-apps.md b/content/es/monolithic-apps.md index da126644a7..9d5e543b2f 100644 --- a/content/es/monolithic-apps.md +++ b/content/es/monolithic-apps.md @@ -13,7 +13,7 @@ la probabilidad de conflictos y la necesidad de comunicación interpersonal entr ## Problema que aborda -La división de una aplicación en [microservicios](/es/microservices/) aumenta su sobrecarga operativa +La división de una aplicación en [microservicios](/es/microservices-architecture/) aumenta su sobrecarga operativa ya que hay más cosas que probar, desplegar y mantener en funcionamiento. Al principio del ciclo de vida de un producto, puede ser ventajoso reducir la complejidad y construir una aplicación monolítica hasta que se determine que el producto tiene éxito. diff --git a/content/es/mutual-transport-layer-security.md b/content/es/mutual-transport-layer-security.md index 026b266b13..0ddee33c39 100644 --- a/content/es/mutual-transport-layer-security.md +++ b/content/es/mutual-transport-layer-security.md @@ -5,7 +5,7 @@ category: Concepto tags: ["seguridad", "redes", ""] --- -La seguridad mutua de capa de transporte (mTLS en Inglés) es una técnica utilizada para autenticar y codificar mensajes enviados entre dos [servicios](/es/service). +La seguridad mutua de capa de transporte (mTLS en Inglés) es una técnica utilizada para autenticar y codificar mensajes enviados entre dos [servicios](/es/service/). mTLS es el protocolo de [Seguridad de capa de transporte](/es/transport-layer-security/) (TLS) estándar pero, en vez de validar la identidad de solo una conexión, se validan ambos lados. diff --git a/content/es/observability.md b/content/es/observability.md index 534d4dba8d..bf98b136f9 100644 --- a/content/es/observability.md +++ b/content/es/observability.md @@ -5,18 +5,12 @@ category: Concepto tags: ["propiedad", "", ""] --- -La observabilidad es la capacidad de generar y descubrir continuamente información procesable basada en señales del sistema bajo observación. -En otras palabras, la observabilidad permite a los usuarios comprender el estado de un sistema a partir de su salida externa y así tomar medidas (correctivas). +La observabilidad es una propiedad del sistema que define el grado en que el sistema puede generar conocimientos accionables. +Permite a los usuarios comprender el estado de un sistema a partir de estas salidas externas y tomar medidas (correctivas). -## Problema que aborda +Los sistemas informáticos se miden observando señales de bajo nivel como el tiempo de CPU, la memoria, el espacio en disco y señales de nivel superior y empresariales, incluidos los tiempos de respuesta de la API, errores, transacciones por segundo, etc. +Estos sistemas observables son **observados** (o monitoreados) a través de herramientas especializadas, llamadas herramientas de observabilidad. Una lista de estas herramientas se puede ver en la [Sección de observabilidad de Cloud Native Landscape](https://landscape.cncf.io/?group=projects-and-products&view-mode=card#observability-and-analysis--observability). -Los sistemas informáticos se miden mediante la observación de señales de bajo nivel, como el tiempo de CPU, la memoria, el espacio en disco y las señales comerciales y de nivel superior, incluidos los tiempos de respuesta de API, errores, transacciones por segundo, etc. +Los sistemas observables proporcionan datos significativos y accionables a sus operadores, lo que les permite lograr resultados favorables (respuesta más rápida a incidentes, aumento de la productividad del desarrollador) y menos trabajo manual y tiempo de inactividad. -La observabilidad de un sistema tiene un impacto significativo en su costo operativo. -Los sistemas observables brindan datos significativos y procesables a sus operadores, lo que les permite lograr resultados favorables (respuesta más rápida a incidentes, mayor productividad del desarrollador) y menos trabajo y tiempo de inactividad. - -## ¿Cómo ayuda? - -Es esencial entender que más información no necesariamente significa que en un sistema sea más observable. -De hecho, a veces, la cantidad de información generada por un sistema puede dificultar la identificación de señales de salud valiosas debido al ruido generado por la aplicación. -La observabilidad requiere los datos correctos en el momento correcto para que el consumidor correcto (humano o pieza de software) tome las decisiones correctas. +Por consiguiente, cuán observable sea un sistema esto afectará significativamente sus costos operativos y de desarrollo. \ No newline at end of file diff --git a/content/es/platform-as-a-service.md b/content/es/platform-as-a-service.md index 95f5083713..e64bd1f6a7 100644 --- a/content/es/platform-as-a-service.md +++ b/content/es/platform-as-a-service.md @@ -10,7 +10,7 @@ Heroku, Cloud Foundry y App Engine son ejemplos de ofertas de PaaS. ## Problema que aborda -Para aprovechar los patrones de las aplicaciones nativas para la nube como son los [microservicios](/es/microservices/) o las [aplicaciones distribuidas](/es/distributed-apps/), +Para aprovechar los patrones de las aplicaciones nativas para la nube como son los [microservicios](/es/microservices-architecture/) o las [aplicaciones distribuidas](/es/distributed-apps/), los equipos de operaciones y los desarrolladores necesitan ser capaces de descargar un tiempo significativo de trabajo en operaciones y mantenimiento. Estos incluyen tareas como el aprovisionamiento de infraestructura, el manejo del [descubrimiento de servicios](/es/service-discovery/) y balanceo de cargas, y [escalamiento](/es/scalability/) de aplicaciones. diff --git a/content/es/pod.md b/content/es/pod.md new file mode 100644 index 0000000000..a362a8e6c9 --- /dev/null +++ b/content/es/pod.md @@ -0,0 +1,31 @@ +--- +title: Pod +status: Completed +category: Concepto +tags: ["infraestructura", "fundamento", ""] +--- + +Dentro de un entorno de [Kubernetes](/es/kubernetes/), un Pod actúa como la unidad más básica desplegable. +Representa un bloque de construcción esencial para desplegar y administrar aplicaciones contenedorizadas. +Cada Pod contiene una única instancia de la aplicación y puede albergar uno o más [contenedores](/es/container/). +Kubernetes administra los Pods como parte de un despliegue más grande y puede escalar los Pods [vertical](/es/vertical-scaling/) u [horizontalmente](/es/horizontal-scaling/) según sea necesario. + +## Problema que aborda + +Mientras los contenedores generalmente actúan como unidades independientes que ejecutan y controlan una carga de trabajo en particular, +hay casos en los que los contenedores necesitan interactuar y ser controlados de manera estrechamente acoplada. + +Si cada uno de estos contenedores estrechamente relacionados se administrara individualmente, se generarían tareas de gestión redundantes. +Por ejemplo, el operador tendría que determinar repetidamente la ubicación de los contenedores relacionados para asegurarse que permanezcan juntos. +Y aunque los ciclos de vida de estos contenedores relacionados necesitan estar sincronizados, solo se pueden administrar individualmente. + + +## ¿Cómo ayuda? + +Los Pods agrupan contenedores estrechamente vinculados en una única unidad, lo que simplifica significativamente las operaciones de contenedores. +Por ejemplo, los contenedores auxiliares a menudo se suelen utilizar junto con el contenedor principal para agregar funcionalidades adicionales o configurar aspectos globales. +Ejemplos de esto incluyen contenedores que inyectan y aplican configuraciones básicas al contenedor principal, +_sidecar_ (contenedores auxiliares) que manejan el enrutamiento del tráfico de red para el contenedor principal (ver [malla de servicios](/es/service-mesh/)) +o contenedores que recolectan registros en conjunto con cada contenedor. + +La asignación de memoria y CPU se puede definir a nivel de Pod, permitiendo a los contenedores internos a compartir recursos de forma flexible, o bien se puede definir por contenedor individualmente. diff --git a/content/es/serverless.md b/content/es/serverless.md index 610cda1653..0981102d63 100644 --- a/content/es/serverless.md +++ b/content/es/serverless.md @@ -5,28 +5,28 @@ Category: Tecnología tags: ["arquitectura", "", ""] --- -Sin servidor (Serverless) es un modelo de desarrollo nativo en la nube que ayuda a los desarrolladores a -crear y ejecutar aplicaciones sin tener que mantener servidores. -Hay servidores en el modelo sin servidor, pero han sido [abstraídos](/es/abstraction/) del proceso de desarrollo. -Un proveedor de nube se encarga del aprovisionamiento, mantenimiento y [escalamiento](/es/scalability/) de la infraestructura de servidores. -Luego los desarrolladores pueden empacar su código en [contenedores](/es/containers/) para el despliegue. -Una vez desplegado el código, las aplicaciones sin servidor satisfacen la demanda y escalan automáticamente según sea necesario. -La modalidad sin servidor en proveedores de nube públicas usualmente es una medida bajo demanda a través de un modelo de ejecución basado en eventos. -Como resultado, cuando una función sin servidor está inutilizada, no representa costo alguno. + +La computación sin servidor [abstrae](/es/abstraction/) los servidores del usuario. +La gestión operativa recae en el proveedor de servicios, incluido el manejo de máquinas físicas y el aprovisionamiento de Máquinas Virtuales. +Los proveedores de servicios pueden ser entidades de nube pública o departamentos de TI internos que prestan servicios a sus equipos de desarrollo. +Estos proveedores ofrecen interfaces de usuario como SDK, CLIs o tiempos de ejecución compatibles con OCI, centrándose en el código y las tareas de implementación. +Los cargos se basan en un modelo de pago por uso. +El [escalado](/es/scalability/) y el aprovisionamiento de recursos para cómputo, almacenamiento o redes, se ajustan automáticamente en función de la demanda de la aplicación sin intervención del usuario. +Un proveedor de plataforma sin servidor consolida recursos para atender a múltiples usuarios en una única máquina física, garantizando el aislamiento mediante la virtualización, especialmente con [Máquinas Virtuales](/es/virtual-machine/). + +Sin servidor (Serverless) es un término integral que abarca servicios con estos atributos y se extiende desde [Plataforma como Servicio (PaaS)](/es/platform-as-a-service/) hasta [Software como Servicio (SaaS)]( /es/software-as-a-service/). ## Problema que aborda -En un modelo de [Infraestructura como Servicio](/es/infrastructure-as-a-service/), -los usuarios compran unidades de cómputo o capacidad de forma anticipada, es decir, se paga a un proveedor de nube pública por componentes de servidores de ejecución continua para las aplicaciones. -Es responsabilidad del usuario luego aumentar la capacidad de cómputo durante periodos de alta demanda y -reducirla cuando ya no sea necesaria. -La infraestructura en la nube necesaria para ejecutar una aplicación está activa incluso cuando la aplicación no está en uso. +En los modelos tradicionales de [Infraestructura como Servicio (IaaS)](/es/infrastructure-as-a-service/), [computación en la nube](/es/cloud-computing/), los usuarios se comprometen a una capacidad predefinida, lo que genera cargos por disponibilidad del servidor independientemente del uso real. +La responsabilidad de ajustar la capacidad del servidor para satisfacer las demandas fluctuantes recae en el usuario, manteniendo la infraestructura activa incluso durante los períodos de inactividad. ## ¿Cómo ayuda? -En contraste, con la arquitectura sin servidor las aplicaciones son ejecutadas solo cuando es necesario. -Cuando un evento llama a una aplicación a ejecutarse, el proveedor de nube pública garantiza dinámicamente una serie de recursos para que se ejecute dicho código. -Además del beneficio de costo y eficiencia, -el modelo sin servidor libera a los desarrolladores de las tareas rutinarias asociadas al escalado y aprovisionamiento de servidores. -Con el modelo sin servidor, las tareas rutinarias como mantenimiento de los sistemas operativos y sistemas de archivos, parches de seguridad, -balanceo de carga, manejo de capacidad, escalado, auditoría y monitoreo pasan a estar en manos del proveedor de servicios de nube. \ No newline at end of file +La arquitectura sin servidor introduce un enfoque más eficiente, activando servicios únicamente según demanda. +Este modelo garantiza la asignación dinámica de recursos por parte de un proveedor de nube, eliminando costos por servicios no utilizados. +Más allá de la eficiencia financiera y operativa, la tecnología sin servidor alivia a los desarrolladores de la carga de escalar aplicaciones y administrar la infraestructura de servidores. +Tareas como el mantenimiento del sistema operativo, las actualizaciones de seguridad, el equilibrio de carga, la capacidad de planificación y el monitoreo se delegan al proveedor de la nube, lo que agiliza el proceso de desarrollo. + +Consulta la entrada del glosario [Función como Servicio (FaaS)](/es/function-as-a-service/) para obtener más información. +Aunque "sin servidor" y "FaaS" se utilizan a menudo como términos intercambiables, incorporan conceptos distintos. diff --git a/content/es/virtualization.md b/content/es/virtualization.md index b0c80cbfa3..c20005e496 100644 --- a/content/es/virtualization.md +++ b/content/es/virtualization.md @@ -10,7 +10,7 @@ refiere al proceso de tomar una computadora física, algunas veces llamada servi y permitirle ejecutar múltiples sistemas operativos aislados. Estos sistemas operativos aislados y sus recursos computacionales dedicados (CPU, memoria y red) son referidos como máquinas virtuales. -Cuando hablamos de una [máquina virtual](/es/virtual-machine), estamos hablando de una computadora definida por software. +Cuando hablamos de una [máquina virtual](/es/virtual-machine/), estamos hablando de una computadora definida por software. Algo que luce y actúa como una computadora real pero comparte hardware con otras máquinas virtuales. La [computación en la nube](/es/cloud-computing/) está principalmente basada en la tecnología de virtualización. Como ejemplo, se puede rentar una computadora a AWS - una computadora que es en realidad una máquina virtual. diff --git a/content/fr/_TEMPLATE.md b/content/fr/_TEMPLATE.md index abc74f8160..07f2b0708e 100644 --- a/content/fr/_TEMPLATE.md +++ b/content/fr/_TEMPLATE.md @@ -11,7 +11,7 @@ Un bref descriptif de la technologie ou du concept. Quelques lignes à propos du problème qu'il adresse. -## Quel en est l'utilité +## Quelle en est l'utilité Quelques lignes sur comment le problème est résolu. diff --git a/content/fr/agile-software-development.md b/content/fr/agile-software-development.md index 7192a7bfeb..a64d74b79c 100644 --- a/content/fr/agile-software-development.md +++ b/content/fr/agile-software-development.md @@ -15,7 +15,7 @@ Définir, communiquer et comprendre les exigences pour toutes les parties prenan Pourtant, les clients veulent que leurs projets logiciels soient livrés à temps, respectant la qualité, l'étendue des travaux et le budget attendus. De par sa nature cyclique, le développement Agile de logiciels permet une adaptation continue des exigences et une adaptation plus rapide au-delà de tous les autres facteurs par opposition aux stratégies en cascade. -## Quel en est l'utilité +## Quelle en est l'utilité Le développement Agile de logiciels contient toutes les phases des stratégies traditionnelles (en cascade), comme l'ingénierie des exigences, la planification, la mise en œuvre, la revue, les tests et la livraison. La plus grande différence est que toute la durée d'un projet logiciel est découpée en itérations, qui contiennent chacune de ces phases. diff --git a/content/fr/api-gateway.md b/content/fr/api-gateway.md index 11ce4e4cfa..3ed3bc538f 100644 --- a/content/fr/api-gateway.md +++ b/content/fr/api-gateway.md @@ -14,7 +14,7 @@ Une passerelle d'API fonctionne comme une interface commune pour les consommateu Si vous mettez des APIs à la disposition de consommateurs externes, vous voudrez un point d'entrée unique pour gérer et contrôler tous les accès. De plus, si vous devez appliquer une fonctionnalité sur ces interactions, une passerelle d'API vous permettra de l'appliquer uniformément à tout le trafic sans nécessiter de modifications du code de l'application. -## Quel en est l'utilité +## Quelle en est l'utilité En fournissant un seul point d'accès pour diverses APIs d'applications, les passerelles d'API facilitent, pour les organisations, la mise en place de logiques métiers ou de sécurité transversales dans un emplacement centralisé. Elles permettent également aux consommateurs d'applications de se rendre à une adresse unique pour tous leurs besoins. diff --git a/content/fr/application-programming-interface.md b/content/fr/application-programming-interface.md index 2e6b7731dd..2f2926e2bb 100644 --- a/content/fr/application-programming-interface.md +++ b/content/fr/application-programming-interface.md @@ -17,7 +17,7 @@ Les applications doivent adopter une approche modulaire de leur fonctionnement s Sans API, il manque un cadre pour l'interaction entre les applications. Sans un cadre partagé, il est difficile pour les applications de [passer à l'échelle](/fr/scalability/) et de s'intégrer. -## Quel en est l'utilité +## Quelle en est l'utilité Les APIs permettent aux programmes informatiques ou aux applications d'interagir et de partager des informations de manière définie et compréhensible. Elles sont les éléments constitutifs des applications modernes et elles offrent aux développeurs un moyen d'intégrer les applications entre elles. diff --git a/content/fr/bare-metal-machine.md b/content/fr/bare-metal-machine.md index 0c67d93a57..977abfac1e 100644 --- a/content/fr/bare-metal-machine.md +++ b/content/fr/bare-metal-machine.md @@ -16,7 +16,7 @@ sans [virtualisation](/fr/virtualization/), est ce que l'on appelle une machine Associer un système d'exploitation à un ordinateur physique est le modèle original de l'informatique. Toutes les ressources de l'ordinateur physique sont disponibles directement pour le système d'exploitation et sans couche de virtualisation présente, aucune latence n'est induite par la traduction des instructions du système d'exploitation vers le matériel. -## Quel en est l'utilité +## Quelle en est l'utilité En dédiant toutes les ressources de calcul d'un ordinateur à un seul système d'exploitation, vous fournissez théoriquement les meilleures performances possibles au système d'exploitation. diff --git a/content/fr/blue-green-deployment.md b/content/fr/blue-green-deployment.md index 718bd4dfb7..be400e23c3 100644 --- a/content/fr/blue-green-deployment.md +++ b/content/fr/blue-green-deployment.md @@ -21,7 +21,7 @@ Par exemple, le déploiement bleu/vert serait approprié pour une boutique en li Dans ce cas, les deux doivent être modifiés en même temps. Si cela était fait sur le système de production, les clients remarqueraient une interruption de service. -## Quel en est l'utilité +## Quelle en est l'utilité Le déploiement bleu/vert est une stratégie appropriée pour les logiciels non Cloud Natives qui doivent être mis à jour avec un temps d'arrêt minimal. Cependant, son utilisation est normalement un "signe" que le logiciel hérité doit être redéveloppé afin que les composants puissent être mis à jour individuellement. diff --git a/content/fr/canary-deployment.md b/content/fr/canary-deployment.md index 1e22de82ab..20e2c00d47 100644 --- a/content/fr/canary-deployment.md +++ b/content/fr/canary-deployment.md @@ -1,5 +1,5 @@ --- -title: Deploiement canari +title: Déploiement canari status: Completed category: concept tags: ["méthodologie", "application", ""] @@ -23,7 +23,7 @@ De même, si quelque chose ne va pas avec le code mis à jour, le trafic en dire Peu importe la rigueur de la stratégie de test, il y aura toujours des bugs qui seront découverts en production. Le fait de basculer 100% du trafic d'une version d'application vers une autre peut intensifier l'impact des défaillances sur les utilisateurs. -## Quel en est l'utilité +## Quelle en est l'utilité Les déploiements canaris permettent aux organisations de voir comment se comporte le nouveau logiciel dans des scénarios réels avant de transférer un trafic significatif vers la nouvelle version. diff --git a/content/fr/chaos-engineering.md b/content/fr/chaos-engineering.md new file mode 100644 index 0000000000..a7fad2ce4d --- /dev/null +++ b/content/fr/chaos-engineering.md @@ -0,0 +1,31 @@ +--- +title: Ingénierie du Chaos (Chaos Engineering) +status: Completed +category: concept +tags: ["méthodologie", "", ""] +--- + +L'ingénierie du chaos (Chaos Engineering ou CE en anglais) est la discipline qui consiste à éprouver un [système distribué](/fr/distributed-systems/) en production +afin de renforcer la confiance dans la capacité du système à résister à des conditions turbulentes et inattendues. + +## Problème auquel il répond + +Les pratiques [SRE](/fr/site-reliability-engineering/) et [DevOps](/fr/devops/) se concentrent sur +les techniques visant à accroître la résilience et la [fiabilité](/fr/reliability/) des produits. +La capacité d'un système à tolérer les défaillances tout en assurant une qualité de service adéquate est +généralement une exigence du développement logiciel. +Plusieurs aspects sont susceptibles d'entraîner des pannes d'une application, +comme l'infrastructure, la plateforme ou d'autres parties d'une application ([microservice](/fr/microservices-architecture/)). +Le déploiement très fréquent de nouvelles fonctionnalités dans l'environnement de production +peut entraîner une forte probabilité d'indisponibilité et d'incident critique +— avec des conséquences considérables pour l'entreprise. + +## Quelle en est l'utilité + +L'ingénierie du chaos est une technique permettant de répondre aux exigences de résilience. +Elle est utilisée pour assurer la résilience contre les défaillances de l'infrastructure, de la plateforme et de l'application. +Les ingénieurs du chaos utilisent des tests de chaos afin d'injecter de manière proactive des défaillances aléatoires +pour vérifier qu'une application, une infrastructure ou une plateforme peut s'auto-réparer et que la défaillance n'a pas d'impact perceptible pour les utilisateurs. +Les expériences de chaos visent à découvrir les angles morts +(par exemple sur les techniques de supervision ou de mise à l'échelle automatique) et d'améliorer la communication entre les équipes lors d'incidents critiques. +Cette approche permet d'accroître la résilience et la confiance de l'équipe dans des systèmes complexes, en particulier de production. diff --git a/content/fr/client-server-architecture.md b/content/fr/client-server-architecture.md new file mode 100644 index 0000000000..a44c56dfdf --- /dev/null +++ b/content/fr/client-server-architecture.md @@ -0,0 +1,31 @@ +--- +title: Architecture Client-Serveur +status: Completed +category: technology +tags: ["architecture", "fondamental", ""] +--- +Dans une architecture client-serveur, la logique (ou le code) qui constitue une application est séparée en deux composants minimum : +- un client qui demande que le travail soit effectué (par exemple, l'application web Gmail exécutée dans votre navigateur web) +- un ou plusieurs serveurs qui satisfont cette demande (par exemple, le service "Envoyer un courrier électronique" exécuté sur les ordinateurs de Google dans le Cloud). + +Dans cet exemple, les courriels sortants que vous écrivez sont envoyés par le client (application web exécutée dans votre navigateur web) à un serveur (les ordinateurs de Gmail, qui transfèrent vos courriels sortants à leurs destinataires). + +Cette approche diffère de celle des applications autonomes (telles que les applications de bureau) qui effectuent tout le travail en un seul endroit. +Par exemple, un programme de traitement de texte comme Microsoft Word peut être installé et exécuté entièrement sur votre ordinateur. + +## Problème auquel cela répond + +Une architecture client-serveur résout un problème majeur posé par les applications autonomes : les mises à jour régulières. +Dans une application autonome, pour chaque mise à jour, les utilisateurs devraient télécharger et installer la dernière version. +Imaginez que vous deviez télécharger tout le catalogue de produits d'Amazon sur votre propre ordinateur avant de pouvoir le parcourir ! + +## Quelle en est l’utilité + +En mettant en œuvre la logique de l'application dans un serveur ou un service distant, +les opérateurs peuvent mettre l'application à jour sans avoir à modifier la logique côté client. +Cela signifie que les mises à jour peuvent être effectuées beaucoup plus fréquemment. +Le stockage des données sur le serveur permet à de nombreux clients de voir et de partager les mêmes données. +Considérez la différence entre l'utilisation d'un traitement de texte en ligne et celle d'un traitement de texte traditionnel hors ligne. +Dans le premier cas, vos fichiers existent sur le serveur et +peuvent être partagés avec d'autres utilisateurs qui les téléchargent simplement à partir du serveur. +Dans l'ancien monde, les fichiers devaient être copiés sur des supports amovibles (disquettes !) et partagés avec des individus. diff --git a/content/fr/cloud-computing.md b/content/fr/cloud-computing.md index 45f23d04bf..dc700ead00 100644 --- a/content/fr/cloud-computing.md +++ b/content/fr/cloud-computing.md @@ -17,7 +17,7 @@ Elles pouvaient soit acquérir, financer et concevoir de (nouvelles) installatio soit étendre et entretenir celles qui existaient déjà. Le cloud computing résout ce dilemme en permettant aux organisations d'externaliser une partie de leurs besoins informatiques. -## Quel en est l'utilité +## Quelle en est l'utilité Les fournisseurs de cloud permettent aux organisations de louer des ressources informatiques à la demande et de payer à l'utilisation, offrant deux avantages majeurs. Premièrement, les organisations peuvent se concentrer sur leur produit ou service sans avoir à attendre, diff --git a/content/fr/cloud-native-apps.md b/content/fr/cloud-native-apps.md index b131b15c5a..b06f4e9993 100644 --- a/content/fr/cloud-native-apps.md +++ b/content/fr/cloud-native-apps.md @@ -13,11 +13,11 @@ Aujourd'hui, les applications Cloud Natives incluent les applications qui foncti ## Problème auquel il répond Traditionnellement, les environnements hébergés dans des centres de données classiques fournissent des serveurs sur mesure. -Chaque centre de données dispose de services qui [associent étroitement ](/fr/tightly-coupled-architectures/) les applications à des environnements spécifiques, qui se basent souvent sur des infrastructures déployées à la main, par exemple des [machines virtuelles](/fr/virtual-machine/) et des services. Cela contraint les développeurs et leurs applications à un déploiement dans ce centre de données spécifique. +Chaque centre de données dispose de services qui [associent étroitement ](/fr/tightly-coupled-architecture/) les applications à des environnements spécifiques, qui se basent souvent sur des infrastructures déployées à la main, par exemple des [machines virtuelles](/fr/virtual-machine/) et des services. Cela contraint les développeurs et leurs applications à un déploiement dans ce centre de données spécifique. Les applications qui n'ont pas été conçues pour tirer avantage des environnements Cloud ne pourront pas bénéficier de ses avantages tels que la résilience et la mise à l'échelle. Par exemple, les applications nécessitant une intervention manuelle pour démarrer correctement ne pourront pas se mettre à l'échelle automatiquement ou automatiquement redémarrées en cas d'erreur. -## Quel en est l'utilité +## Quelle en est l'utilité Bien qu'il n'y ait pas de solution miracle pour qu'une application soit définie comme Cloud Native, les applications Cloud Natives présentent des points en commun. diff --git a/content/fr/cloud-native-security.md b/content/fr/cloud-native-security.md index 18240d1d04..4c6eacdf6b 100644 --- a/content/fr/cloud-native-security.md +++ b/content/fr/cloud-native-security.md @@ -16,7 +16,7 @@ Les modèles de sécurité traditionnels ont été conçus avec des hypothèses Les applications Cloud Natives changent fréquemment, utilisent beaucoup d'outils et de bibliothèques open source, elles tournent dans des infrastructures souvent contrôlées par un revendeur et elles sont sujettes à des changements d'infrastructures rapides. Les revues de code, les longs cycles d'assurance qualité, l'analyse des vulnérabilités des hôtes, et les révisions de sécurité de dernière minute ne se mettent pas à l'échelle avec les applications Cloud Natives. -## Quel en est l'utilité +## Quelle en est l'utilité La sécurité Cloud Native introduit une nouvelle façon de travailler qui protègent les applications en migrant depuis les modèles de sécurité traditionnels vers un modèle ou la sécurité est impliquée dans chaque étape du cycle de livraison. diff --git a/content/fr/cloud-native-tech.md b/content/fr/cloud-native-tech.md index df493c2baa..df8f20ff90 100644 --- a/content/fr/cloud-native-tech.md +++ b/content/fr/cloud-native-tech.md @@ -22,7 +22,7 @@ Les inconvénients des modèles d'exploitation informatiques traditionnels. Les défis incluent les difficultés à créer des applications évolutives, tolérantes aux pannes et qui sont capable de se réparer toute seule. Il adresse également l'utilisation inefficace de ressources entre autres. -## Quel en est l'utilité +## Quelle en est l'utilité Bien que chaque technologie réponde à un problème très spécifique, en tant que groupe, les technologies Cloud Natives permettent de créer des systèmes faiblement couplés qui sont résilients, gérables et observables.. diff --git a/content/fr/cluster.md b/content/fr/cluster.md index bcff692c6d..78901aeec4 100644 --- a/content/fr/cluster.md +++ b/content/fr/cluster.md @@ -17,7 +17,7 @@ Un logiciel qui s'exécute sur un seul ordinateur représente un point de défai alors un système critique pourrait être mis hors-ligne. C'est pourquoi généralement les logiciels modernes sont souvent construits sous forme d'[applications distribuées](/fr/distributed-apps/), regroupées ensemble comme un cluster. -## Quel en est l'utilité +## Quelle en est l'utilité Les applications réparties en cluster s'exécutent sur plusieurs machines, éliminant le point de défaillance unique. Cependant, fabriquer des systèmes distribués est vraiment difficile. diff --git a/content/fr/container-orchestration.md b/content/fr/container-orchestration.md index 578c6c8407..b13cc4b2f2 100644 --- a/content/fr/container-orchestration.md +++ b/content/fr/container-orchestration.md @@ -4,14 +4,14 @@ status: Completed category: Concept --- -L'orchestration de [Conteneurs](/fr/container/) fait référence à la gestion et à l'automatisation du cycle de vie d'applications conteneurisées au sein d'environnements dynamiques. -Réalisée à l'aide d'un orchestrateur de conteneurs (la plupart du temps, [Kubernetes](/fr/kubernetes)), elle permet les déploiements, le passage à l'échelle (automatique), (l'auto-)remédiation et le monitoring. +L'orchestration de [Conteneurs](/fr/container/) fait référence à la gestion et à l'automatisation du cycle de vie d'applications [conteneurisées](/fr/containerization/) au sein d'environnements dynamiques. +Réalisée à l'aide d'un orchestrateur de conteneurs (la plupart du temps, [Kubernetes](/fr/kubernetes/)), elle permet les déploiements, le passage à l'échelle (automatique), (l'auto-)remédiation et le monitoring. L'orchestration est une métaphore: L'outil d'orchestration dirige les conteneurs tel un chef d'orchestre, s'assurant que chaque conteneur (ou musicien) fait ce qu'il doit faire. ## Problème auquel il répond -Gérer manuellement des [microservices](/fr/microservices-architecture), la sécurité, et la communication réseaux à grande échelle — et des [systèmes distribués](/fr/distributed-systems) en général — est compliqué, pour ne pas dire impossible. +Gérer manuellement des [microservices](/fr/microservices-architecture/), la sécurité, et la communication réseaux à grande échelle — et des [systèmes distribués](/fr/distributed-systems/) en général — est compliqué, pour ne pas dire impossible. L'orchestration de conteneurs permet aux utilisateurs d'automatiser toutes ces tâches de gestion. ## Quelle en est l'utilité diff --git a/content/fr/container.md b/content/fr/container.md index 12ec423d4e..b2d53fe1b5 100644 --- a/content/fr/container.md +++ b/content/fr/container.md @@ -17,7 +17,7 @@ Chaque machine nécessitait son propre système d'exploitation, qui utilisait du tout cela pour faire fonctionner une simple application. De plus, la maintenance, la mise à jour et le lancement d'un système d'exploitation sont des sources de travail en plus. -## Quel en est l'utilité +## Quelle en est l'utilité Les conteneurs partagent le même système d'exploitation et ses ressources machine, et se partagent donc la charge additionnelle des ressources dues au système d'exploitation, ce qui permet un usage efficace de la machine physique. diff --git a/content/fr/containerization.md b/content/fr/containerization.md index 5ba774f81f..51378dc184 100644 --- a/content/fr/containerization.md +++ b/content/fr/containerization.md @@ -16,7 +16,7 @@ Les VMs sont sensiblement plus grosses que les conteneurs et nécessitent un hyp À cause du stockage, des sauvegardes et du transfert de ces gros modèles de VM, la création des modèles de VM est également longue. De plus, les VMs peuvent souffrir d'une dérive de configuration ce qui enfreint le principe de l'[immuabilité](/fr/immutable-infrastructure/). -## Quel en est l'utilité +## Quelle en est l'utilité Les images de conteneurs sont légères (par opposition aux VM traditionnelles) et le processus de conteneurisation nécessite un fichier qui liste les dépendances. diff --git a/content/fr/continuous-delivery.md b/content/fr/continuous-delivery.md index bbfa65d1e9..99273d33fb 100644 --- a/content/fr/continuous-delivery.md +++ b/content/fr/continuous-delivery.md @@ -21,7 +21,7 @@ Cependant, le faire manuellement se traduit par des coûts élevés pour chaque Historiquement, pour éviter ces coûts, les organisations publiaient moins fréquemment, déployant plus de changements à la fois et augmentant le risque que quelque chose se passe mal. -## Quel en est l'utilité +## Quelle en est l'utilité Les stratégies CD créent un parcours entièrement automatisé vers la production qui teste et déploie le logiciel en utilisant diverses stratégies diff --git a/content/fr/continuous-integration.md b/content/fr/continuous-integration.md index 92d31c3593..1aa13c44a6 100644 --- a/content/fr/continuous-integration.md +++ b/content/fr/continuous-integration.md @@ -18,7 +18,7 @@ ces développeurs peuvent apporter des modifications contradictoires et, par ina De plus, avec plusieurs développeurs travaillant sur le même projet, toutes les tâches quotidiennes telles que tester ou mesurer la qualité du code devraient être répétées par chaque développeur, ce qui ferait perdre du temps. -## Quel en est l'utilité +## Quelle en est l'utilité Le logiciel de CI vérifie automatiquement que les modifications de code sont fusionées proprement chaque fois qu'un développeur soumet une modification. L'utilisation du serveur CI pour exécuter des contrôles de qualité du code, des tests et même des déploiements est une pratique quasi universelle. diff --git a/content/fr/data-center.md b/content/fr/data-center.md index bedbdad889..37c845a1ed 100644 --- a/content/fr/data-center.md +++ b/content/fr/data-center.md @@ -19,7 +19,7 @@ Avant les centres de données, l'échelle de l'application était limitée par l Mais si vous pensez à des applications à grande échelle comme Gmail ou Netflix (l'application côté serveur, pas l'interface utilisateur que vous avez sur votre téléphone ou votre ordinateur), celles-ci ont besoin d'une capacité de calcul supérieure à celle qu'un seul ordinateur peut fournir. C'est là qu'interviennent les centres de données. -## Quel en est l'utilité +## Quelle en est l'utilité En connectant plusieurs serveurs, les utilisateurs peuvent créer un [système distribué](/fr/distributed-systems/) qui fonctionne comme un "superordinateur". En regroupant la puissance de plusieurs machines, il est désormais possible d'exécuter des applications beaucoup plus importantes ou traiter des tâches de calcul beaucoup plus complexes. diff --git a/content/fr/devops.md b/content/fr/devops.md index 14a743c41d..62ae0c75ee 100644 --- a/content/fr/devops.md +++ b/content/fr/devops.md @@ -12,7 +12,7 @@ Le DevOps fait appel à un groupe d'ingénieurs travaillant sur des petits compo ## Problème auquel il répond -Traditionnellement, dans les organisations complexes possédant des [applications monolithiques](/fr/monolithic-apps/) [fortement couplées](/fr/tightly-coupled-architectures/), +Traditionnellement, dans les organisations complexes possédant des [applications monolithiques](/fr/monolithic-apps/) [fortement couplées](/fr/tightly-coupled-architecture/), le travail était généralement fragmenté entre plusieurs équipes. Ce fonctionnement menait à de nombreuses passations entre les équipes et allongeait les délais de livraison. À chaque nouveau composant ou nouvelle mise à jour, le résultat était mis en file d'attente pour la prochaine équipe. @@ -24,7 +24,7 @@ Le rôle de chacun était ainsi de fournir le travail à l'équipe suivante, et Une fois le code livré en production, ce dernier passé entre les mains de tellement de différents développeurs, ayant attendu dans tellement de files d'attente, il en devenait alors compliqué de tracer l'origine d'un problème en cas de dysfonctionnement du code. Le DevOps vient chambouler cette approche. -## Quel en est l'utilité +## Quelle en est l'utilité Avoir une seule équipe en charge du cycle de vie d'une application permet de minimiser les passations, réduisant ainsi les risques lors des déploiements en production, améliorant diff --git a/content/fr/devsecops.md b/content/fr/devsecops.md index d4c4f16955..f91bff2f75 100644 --- a/content/fr/devsecops.md +++ b/content/fr/devsecops.md @@ -19,7 +19,7 @@ toutes les parties prenantes de l’organisation peuvent exacerber les problème Un processus qui publie rapidement de nouveaux logiciels sans tenir compte des besoins de sécurité peut dégrader la posture de sécurité d’une organisation. -## Quel en est l'utilité +## Quelle en est l'utilité DevSecOps se concentre sur la suppression des silos d'équipe et promeut la création de flux de travail sécurisés et automatisés. Lors de la sélection d'applications de sécurité, les organisations doivent tirer parti diff --git a/content/fr/distributed-apps.md b/content/fr/distributed-apps.md index 043f5a0198..f49208a4fd 100644 --- a/content/fr/distributed-apps.md +++ b/content/fr/distributed-apps.md @@ -18,7 +18,7 @@ Une application monolithique peut être plus difficile à mettre à l'échelle c Les applications monolithiques peuvent également devenir un frein à la vitesse de développement à mesure qu'elles grossissent, car davantage de développeurs doivent travailler sur une base de code partagée qui n'a pas toujours des limites bien définies. -## Quel en est l'utilité +## Quelle en est l'utilité En divisant une application en différents éléments et en les exécutant à différents endroits, le système global peut tolérer davantage de pannes. Cela permet également à une application de tirer parti des fonctionnalités de mise à l'échelle non disponibles pour une application ayant une instance unique, diff --git a/content/fr/distributed-systems.md b/content/fr/distributed-systems.md index a758d5a8a9..a95e7f8fb6 100644 --- a/content/fr/distributed-systems.md +++ b/content/fr/distributed-systems.md @@ -19,7 +19,7 @@ Sans calcul distribué, beaucoup d'applications sur lesquelles nous nous appuyon Traditionnellement, les systèmes [passent à l'échelle](/fr/scalability/) verticalement, ce qui correspond à l'ajout de processeur ou de mémoire à une seule machine. Le passage à l'échelle vertical est chronophage, nécessite un temps d'arrêt, et atteint rapidement ses limites. -## Quel en est l'utilité +## Quelle en est l'utilité Les systèmes distribués permettent un [passage à l'échelle horizontal](/fr/horizontal-scaling/) (par exemple en ajoutant des nœuds au système lorsque nécessaire). Ceci peut être automatisé, permettant ainsi au système de gérer une croissance soudaine de charge de travail (workload) ou de consommation de ressources. diff --git a/content/fr/ebpf.md b/content/fr/ebpf.md new file mode 100644 index 0000000000..54218912fb --- /dev/null +++ b/content/fr/ebpf.md @@ -0,0 +1,37 @@ +--- +title: eBPF +status: Completed +category: ["architecture", "réseau", "sécurité"] +--- + +eBPF, ou "extended Berkeley Packet Filter", est une technologie qui permet à de petits programmes ou scripts de s'exécuter au sein d'un environnement contrôlé dans l'espace du noyau (kernel en anglais) d'un système Linux, sans avoir à modifier le code source du noyau ou à charger des modules dans le noyau Linux. + +Un système Linux comporte deux espaces : l'espace du noyau et l'espace utilisateur. +Le noyau représente le cœur du système d'exploitation et est la seule partie ayant un accès illimité au matériel. + +Les applications résidant dans l'espace utilisateur envoient une requête au noyau lorsqu'elles ont besoin de privilèges plus importants. +Pour les applications qui nécessitent plus de flexibilité, comme un accès direct au matériel, le noyau peut être étendu grâce à ce que l'on appelle des "modules" pour le noyau. +Cette approche permet d'étendre les fonctionnalités par défaut du noyau, +ainsi les applications peuvent accéder plus directement aux composants sous-jacents. +Cependant, cette approche introduit également des risques de sécurité, ce qui fait d'eBPF une alternative intéressante. + +## Problème auquel il répond + +Généralement, les applications s'exécutent dans l'espace utilisateur, et si l'application a besoin de certains privilèges du noyau (par exemple, pour accéder à du matériel), elle les demande au noyau par l'intermédiaire d'un "appel système". +Dans la plupart des cas, cette approche fonctionne parfaitement. Cependant, dans certains cas, les développeurs ont besoin d'une plus grande flexibilité pour un accès système de bas niveau. +Les fonctionnalités d'observabilité, de sécurité et de réseau sont de bons exemples. +Pour ce faire, nous pouvons utiliser des modules du noyau Linux, qui étendent les fonctionnalités du noyau sans en modifier le code source. +Si l'utilisation des modules du noyau Linux présente des avantages, elle introduit également des risques de sécurité. +Parce qu'ils opèrent dans l'espace du noyau, les modules du noyau Linux peuvent faire planter le noyau, ce qui fait tomber toute la machine. +En outre, les modules du noyau disposent de privilèges élevés et d'un accès direct aux ressources du système. S'ils ne sont pas correctement sécurisés, des attaquants peuvent les exploiter. + +## Quelle en est l'utilité + +L'eBPF fournit un environnement plus contrôlé et plus restreint pour l'exécution de programmes définis par l'utilisateur par rapport aux modules du noyau Linux. +Il s'exécute dans un environnement "bac à sable" au sein du noyau, ce qui permet une isolation et une atténuation des risques. +Si une vulnérabilité ou une faille est exploitée dans un programme eBPF, son impact est généralement limité à l'environnement "bac à sable". +En outre, avant qu'un programme eBPF puisse commencer à s'exécuter dans le noyau, il doit subir certaines vérifications. +Le composant vérificateur s'assure que le programme eBPF ne présente pas de violations potentielles de la sécurité, +telles que des accès hors limites à la mémoire, des boucles infinies et des fonctions non autorisées du noyau. +Il s'assure ainsi que le programme n'entrera pas dans une boucle infinie et ne provoquera pas un plantage du noyau. +Ces contrôles de sécurité font d'eBPF une option plus sûre que les modules du noyau Linux pour l'exécution d'applications dans le noyau Linux. diff --git a/content/fr/edge-computing.md b/content/fr/edge-computing.md new file mode 100644 index 0000000000..7712554474 --- /dev/null +++ b/content/fr/edge-computing.md @@ -0,0 +1,27 @@ +--- +title: Informatique en Périphérie (Edge Computing) +status: Completed +category: Technology +--- + +L'Edge Computing (informatique en périphérie) est une [architecture distribuée](/fr/distributed-systems/) qui déplace une partie de la capacité de stockage et de calcul du [centre de données](/fr/data-center/) principal vers la source de données. +Les données collectées sont traitées localement (par exemple, dans une usine, dans un magasin ou à travers toute une ville) plutôt que d'être envoyées à un centre de données centralisé pour traitement et analyse. +Ces unités ou dispositifs de traitement locaux représentent la périphérie du système, tandis que le centre de données en est le centre. +L'information calculée par ces unités périphériques est ensuite renvoyée au centre de données principal pour un traitement ultérieur. +Parmi les exemples de Edge Computing, nous avons les bracelets connectés, ou les ordinateurs qui analysent le flux de circulation. + +## Problème auquel il répond + +Au cours de la dernière décennie, nous avons constaté une augmentation du nombre de dispositifs de périphérie de réseau (par exemple, téléphones mobiles, montres intelligentes ou capteurs). +Dans certains cas, le traitement des données en temps réel n'est pas seulement un plus, mais vital. +Pensez aux voitures autonomes. +Maintenant, imaginez que les données des capteurs de la voiture doivent être transférées à un centre de données pour traitement avant d'être renvoyées au véhicule afin qu'il puisse réagir de manière appropriée. +La latence inhérente au réseau pourrait être fatale. +Bien que cela soit un exemple extrême, la plupart des utilisateurs ne voudraient pas utiliser un appareil intelligent incapable de fournir un retour d'information instantané. + +## Quelle en est l'utilité + +Comme décrit ci-dessus, pour que les dispositifs de périphérie de réseau soient utiles, ils doivent effectuer au moins une partie du traitement et de l'analyse localement pour fournir un retour d'information quasi instantanée aux utilisateurs. +Cela est réalisé en déplaçant certaines ressources de stockage et de traitement du centre de données vers l'endroit où les données sont générées : le dispositif de périphérie de réseau. +Les données traitées et non traitées sont ensuite envoyées au centre de données pour un traitement et un stockage ultérieurs. +En bref, l'efficacité et la vitesse sont les principaux moteurs de l'Edge Computing. \ No newline at end of file diff --git a/content/fr/event-driven-architecture.md b/content/fr/event-driven-architecture.md new file mode 100644 index 0000000000..297e7c4b54 --- /dev/null +++ b/content/fr/event-driven-architecture.md @@ -0,0 +1,24 @@ +--- +title: Architecture Orientée Événements (Event-Driven Architecture) +status: Completed +category: concept +tags: ["architecture", "", ""] +--- + +L'architecture orientée événements (Event-Driven Architecture) est une architecture logicielle qui favorise la création, le traitement et la consommation d'événements. +Un événement est un changement d'état d'une application. +Par exemple, héler un véhicule au travers d'une application de covoiturage représente un événement. +Cette architecture crée la structure dans laquelle les événements peuvent être correctement acheminés depuis leur source (l'application demandant un trajet) vers les destinataires souhaités (les applications des conducteurs disponibles à proximité). + +## Problème auquel il répond + +À mesure que davantage de données sont mises à jour en temps réel, il devient de plus en plus complexe de trouver des moyens fiables pour garantir que les événements sont capturés et acheminés vers le [service](/fr/service/) approprié qui doit traiter ces demandes. +Les méthodes traditionnelles de gestion des événements n'offrent souvent aucune garantie que les messages sont correctement acheminés ou qu'ils ont effectivement été envoyés ou reçus. +Lors de la mise à l'échelle des applications, il devient plus difficile d'orchestrer les événements. + +## Quelle en est l'utilité + +Les architectures orientées événements établissent un hub central pour tous les événements (par exemple, Kafka). +Vous définissez ensuite les producteurs d'événements (la source) et les consommateurs (le récepteur), et le hub central des événements garantit le flux des événements. +Cette architecture garantit que les services restent découplés et que les événements sont correctement acheminés du producteur au consommateur. +Le producteur prendra l'événement entrant, généralement via le protocole HTTP, puis acheminera les informations de l'événement. diff --git a/content/fr/event-streaming.md b/content/fr/event-streaming.md new file mode 100644 index 0000000000..613af3ef89 --- /dev/null +++ b/content/fr/event-streaming.md @@ -0,0 +1,29 @@ +--- +title: Diffusion d'événements en continu (Event Streaming) +status: Completed +category: concept +tags: ["méthodologie", "réseau", ""] +--- + +La diffusion d'événements en continu (Event Streaming) est une approche où un logiciel envoie des données d'événements d'une application à une autre pour communiquer en continu ce qu'elles font. +Imaginez un service diffusant tout ce qu'il fait à tous les autres services. +Chaque activité effectuée par un service est appelée un événement, d'où le terme de diffusion d'événements en continu. +Par exemple, le NASDAQ reçoit des mises à jour sur les prix des actions et des matières premières chaque seconde. +Si vous aviez une application surveillant un ensemble spécifique d'actions, vous voudriez recevoir ces informations en quasi-temps réel. +Yahoo! Finance fournit une [API](/fr/application-programming-interface/) qui récupère les données du NASDAQ et envoie (ou diffuse en continu) les informations (ou événements) de leur application à toute application qui s'y abonne. +Les données envoyées ainsi que les changements de ces données (prix des actions) sont les événements, tandis que le processus de les livrer à une application est la diffusion d'événements. + +## Problème auquel il répond + +Traditionnellement, Yahoo! Finance mettrait en œuvre des requêtes TCP individuelles. +Cela serait très inefficace car cela nécessiterait qu'une connexion soit créée pour chaque événement. +À mesure que les données deviennent de plus en plus temps réel, mettre à l'échelle une telle solution devient inefficace. +Ouvrir une seule connexion et permettre aux événements de circuler est idéal pour la collecte en temps réel. +La quantité de données générées augmente de manière exponentielle et, par conséquent, les changements de données sont extrêmement fréquents. Les développeurs et les utilisateurs doivent être en mesure de voir ces données en quasi-temps réel. + +## Quelle en est l'utilité + +La diffusion d'événements en continu permet de communiquer les changements de données de la source au destinataire. +Au lieu d'attendre que les services demandent des informations, le service de diffusion propage en continu tous ses événements (ou activités). +Il ne se préoccupe pas de ce qui arrive aux informations. +Il fait simplement ce qu'il doit faire et les diffuse, restant ainsi complètement indépendant de tout autre service. \ No newline at end of file diff --git a/content/fr/function-as-a-service.md b/content/fr/function-as-a-service.md new file mode 100644 index 0000000000..497db5e1ae --- /dev/null +++ b/content/fr/function-as-a-service.md @@ -0,0 +1,32 @@ +--- +title: Fonction en tant que Service (FaaS) +status: Completed +category: Technology +tags: ["infrastructure", "", ""] +--- + +Une Fonction en tant que Service, ou Function as a Service (FaaS) en anglais, est un type de [service](/fr/service/) de [cloud computing](/fr/cloud-computing/) [serverless](/fr/serverless/) +qui permet d'exécuter du code en réponse à des événements sans maintenir l'infrastructure complexe +généralement associée à la création et au lancement d'applications en [microservices](/fr/microservices-architecture/). +Avec le FaaS, les utilisateurs ne gèrent que les fonctions et les données, tandis que le fournisseur de services cloud gère l'application. +Cela permet aux développeurs d'obtenir les fonctions dont ils ont besoin sans avoir à payer pour des services lorsque le code n'est pas en cours d'exécution. + +## Problème auquel il répond + +Dans un scénario traditionnel sur site, une entreprise gère et entretient son propre centre de données. +Elle doit investir dans des serveurs, des systèmes de stockage, des logiciels et d'autres technologies, +et éventuellement engager du personnel ou des sous-traitants pour acheter, gérer et mettre à jour l'ensemble du matériel et des licences. +Le centre de données doit être construit pour répondre aux pointes de consommation, même lorsque la charge de travail diminue par la suite et que les ressources deviennent inutilisées. +Inversement, si l'entreprise se développe rapidement, le service informatique peut avoir du mal à suivre. +Dans le cadre d'un modèle standard de [cloud computing](/fr/cloud-computing/) en [infrastructure en tant que service (IaaS)](/fr/infrastructure-as-a-service/), les utilisateurs achètent à l'avance des unités de capacité, +ce qui signifie que vous payez un fournisseur de cloud public pour des serveurs toujours actifs afin d'exécuter vos applications. +Il incombe à l'utilisateur d'augmenter la capacité des serveurs en cas de forte demande et de la réduire lorsque cette capacité n'est plus nécessaire. +L'infrastructure cloud nécessaire au fonctionnement d'une application reste active même lorsque l'application n'est pas utilisée. + +## Quelle en est l'utilité + +Le FaaS offre aux développeurs une [abstraction](/fr/abstraction/) permettant d'exécuter des applications web en réponse à des événements sans avoir à gérer de serveurs. +Par exemple, le téléchargement d'un fichier peut déclencher un code personnalisé qui transcode le fichier dans différents formats. +L'infrastructure FaaS dimensionnera automatiquement le code en cas d'utilisation intensive, +et le développeur n'a pas besoin de consacrer du temps ou des ressources à l'élaboration du code pour la [capacité de mise à l'échelle](/fr/scalability/). +La facturation est basée uniquement sur le temps de calcul, ce qui signifie que les organisations n'ont pas à payer lorsque les fonctions ne sont pas utilisées. diff --git a/content/fr/horizontal-scaling.md b/content/fr/horizontal-scaling.md index e75c85eaf0..11053ad735 100644 --- a/content/fr/horizontal-scaling.md +++ b/content/fr/horizontal-scaling.md @@ -16,7 +16,7 @@ En termes simples, elle vise à réduire la charge du serveur plutôt qu'à éte Lorsque la demande d'une application dépasse la capacité actuelle de l'instance de cette application, nous devons trouver un moyen de [mettre à l'échelle](/fr/scalability/) le système (ajouter de la capacité au système). Nous pouvons soit ajouter plus de nœuds au système (mise à l'échelle horizontale) soit ajouter plus de ressources informatiques aux nœuds existants (mise à l'échelle verticale). -## Quel en est l'utilité +## Quelle en est l'utilité La mise à l'échelle horizontale permet aux applications de s'étendre jusqu'aux limites fournies par le cluster sous-jacent. En ajoutant davantage d'instances au système, l'application peut traiter un plus grand nombre de requêtes. diff --git a/content/fr/infrastructure-as-a-service.md b/content/fr/infrastructure-as-a-service.md index 865b4a1f85..c12275155f 100644 --- a/content/fr/infrastructure-as-a-service.md +++ b/content/fr/infrastructure-as-a-service.md @@ -16,7 +16,7 @@ Lorsque la demande est plus faible, ces ressources informatiques sont inutilisé Et si la charge de travail dépasse la demande prévue, il y a une pénurie de ressources informatiques pour traiter la charge de travail. Ce manque de capacité de mise à l'échelle entraîne une augmentation des coûts et une utilisation inefficace des ressources. -## Quel en est l'utilité +## Quelle en est l'utilité Avec l'IaaS, les entreprises peuvent éviter d'acheter et de maintenir la capacité de calcul et le centre de données pour leurs applications. Une infrastructure à la demande leur permet de louer des ressources informatiques en fonction de leurs besoins et de différer d'importantes dépenses d'investissement, tout en leur donnant la possibilité d'augmenter ou de réduire leur capacité. diff --git a/content/fr/infrastructure-as-code.md b/content/fr/infrastructure-as-code.md index fa1af9948e..558b17b0db 100644 --- a/content/fr/infrastructure-as-code.md +++ b/content/fr/infrastructure-as-code.md @@ -16,6 +16,6 @@ Il est également nécessaire de pouvoir [mettre à l'échelle](/fr/scalability/ Le provisionnement manuel ne pouvant pas répondre aux besoins de réactivité et de passage à l'échelle des [applications Cloud Natives](/fr/cloud-native-apps/). Les changements manuels sur l'infrastructure ne sont pas reproductibles, affichent rapidement des problèmes de mise à l'échelle, et amènent des erreurs de configuration. -## Quel en est l'utilité +## Quelle en est l'utilité En représentant les ressources des centres de données comme les serveurs, les équilibreurs de charge, et les sous-réseaux en tant que code, celà permet aux équipes en charge de l'infrastructure d'avoir une seule source de vérité pour toutes les configurations mais aussi de gérer leurs centres de données dans un pipeline [CI](/continuous-integration/)/[CD](/continuous-delivery/), qui implémente la gestion de version et des stratégies de déploiement. diff --git a/content/fr/ingress.md b/content/fr/ingress.md new file mode 100644 index 0000000000..4806b93c15 --- /dev/null +++ b/content/fr/ingress.md @@ -0,0 +1,30 @@ +--- +title: Ingress +status: Completed +category: technologie +tags: ["fondamental"] +--- + +Un Ingress, que nous pourrions traduire par "point d'entrée", est un ensemble de règles qui participe à gérer le trafic Internet depuis l'extérieur vers un conteneur ou un groupe de conteneurs s'exécutant dans un cluster. +Il se compose de deux éléments : la ressource Ingress et le contrôleur d'Ingress. +La ressource Ingress est un fichier de configuration qui coexiste avec les autres fichiers manifestes et permet aux administrateurs de configurer le routage du trafic externe. +Le contrôleur d'Ingress est le service qui, en utilisant des technologies web, assure le routage du trafic conformément à la configuration définie dans la ressource Ingress. + +## Problème auquel il répond + +Les applications web Cloud Native sont composées de plusieurs services, et souvent, ces [services](/fr/service/) doivent être accessibles depuis Internet pour que les utilisateurs puissent les joindre depuis leur navigateur. +Pour rendre ces services accessibles aux utilisateurs tout en utilisant [Kubernetes](/fr/kubernetes/) pour exécuter cette application, nous devons exposer chaque service applicatif au monde extérieur. +La manière la plus directe serait d'utiliser un service d'équilibrage de charge Kubernetes (Load Balancer). +La création d'un tel service ajoute un nouveau composant dans l'infrastructure sous-jacente. +Cela introduit non seulement de nouveaux coûts et une surcharge de gestion, mais chaque équilibreur de charge nouvellement créé a sa propre adresse IP externe. +Cela conduit à une mauvaise expérience utilisateur, car en tant qu'utilisateur, nous ne voulons pas naviguer sur différentes URL pour accéder à une application. + +## Quelle en est l'utilité + +Une ressource Ingress vous permet de configurer la façon dont le trafic est réparti et routé vers les services d'une application. +Le contrôleur d'Ingress expose un seul point d'entrée accessible via une URL (www.example-url.com) et effectue le routage et la répartition en fonction de différents chemins d'URL (www.example-url.com/chemin). +Un contrôleur d'Ingress est un composant qui s'exécute dans le cluster et interprète les règles définies dans la ressource Ingress. +Il appartient aux opérateurs de cluster où s'exécute l'application web de choisir un contrôleur d'Ingress spécifique parmi un ensemble de technologies possibles comme Nginx, Traefik, HAProxy, etc. +Ainsi, si une application est composée de plusieurs services, l'utilisateur peut y accéder à l'aide d'une seule URL. +Cela élimine le besoin de mettre en œuvre de nombreux équilibreurs de charge distincts au niveau de l'infrastructure et facilite la configuration des règles de pare-feu et de répartition de charge pour chaque service. +En centralisant le routage du trafic et les configurations, le contrôleur d'Ingress offre une mise à l'échelle rationalisée, optimise l'utilisation des ressources, réduit les coûts et améliore la gestion globale des applications s'exécutant dans un cluster. \ No newline at end of file diff --git a/content/fr/kubernetes.md b/content/fr/kubernetes.md index ea3347776e..20e2ccc61b 100644 --- a/content/fr/kubernetes.md +++ b/content/fr/kubernetes.md @@ -18,7 +18,7 @@ Kubernetes est extensible via ses [API](/fr/application-programming-interface/), L'automatisation de l'infrastructure et la gestion de configuration déclarative sont des concepts importants depuis longtemps, mais ils sont devenus omniprésents depuis que le [cloud computing](/fr/cloud-computing/) a gagné en popularité. À mesure que la demande de ressources de calcul augmente et que les organisations ont besoin de plus de capacités avec moins d'ingénieurs, les nouvelles technologies et les méthodes de travail doivent répondre à cette demande. -## Quel en est l'utilité +## Quelle en est l'utilité Comme pour les outils traditionnels d'[infrastructure en tant que code](/fr/infrastructure-as-code/), Kubernetes aide à l'automatisation, mais a l'avantage de fonctionner avec des conteneurs. Les conteneurs sont plus résistants aux écarts de configuration que les [machines virtuelles](/fr/virtual-machine/) ou physiques. diff --git a/content/fr/loosely-coupled-architecture.md b/content/fr/loosely-coupled-architecture.md index eb352d9095..f2385582e6 100644 --- a/content/fr/loosely-coupled-architecture.md +++ b/content/fr/loosely-coupled-architecture.md @@ -7,7 +7,7 @@ tags: ["fondamental", "architecture", "propriété"] L'architecture faiblement couplée est un type d'architecture où les différents composants d'une application sont construits indépendamment les uns des autres (c'est le paradigme opposé -des [architectures fortement couplées](/fr/tightly-coupled-architectures/)). +des [architectures fortement couplées](/fr/tightly-coupled-architecture/)). Chaque composant, parfois identifié comme un [microservice](/fr/microservices-architecture/), est construit pour effectuer une tâche spécifique d'une manière qui lui permet d'être utilisé par d'autres services. Cette approche est souvent plus longue à mettre en œuvre que l'architecture fortement couplée mais, elle a plusieurs avantages en particulier lorsque l'application change d'échelle. diff --git a/content/fr/microservices-architecture.md b/content/fr/microservices-architecture.md index fcaa075500..5433089163 100644 --- a/content/fr/microservices-architecture.md +++ b/content/fr/microservices-architecture.md @@ -22,11 +22,11 @@ L'augmentation du nombre d'inscriptions exige une plus grande capacité de la pa Traditionnellement (approche monolithique), l'ensemble de l'application devrait être [mise à l'échelle](/fr/scalability/) pour s'adapter à la demande - une utilisation très inefficace des ressources. Les architectures monolithiques font parfois tomber les développeurs dans des pièges de conception. -Étant donné que tout le code se retrouve au même endroit, il est plus facile de rendre ce code [étroitement couplé](/fr/tightly-coupled-architectures/) et plus difficile d'appliquer le principe de séparation des responsabilités. +Étant donné que tout le code se retrouve au même endroit, il est plus facile de rendre ce code [étroitement couplé](/fr/tightly-coupled-architecture/) et plus difficile d'appliquer le principe de séparation des responsabilités. Les monolithes exigent également souvent que les développeurs comprennent l'ensemble du code avant d'y faire des modifications. L'architecture en microservices est une réponse à ces défis. -## Quel en est l'utilité +## Quelle en est l'utilité La séparation des fonctionnalités en différents microservices facilite leur déploiement, leur mise à jour et leur mise à l'échelle de manière indépendante. Cela permet également à différentes équipes de travailler simultanément sur une petite partie d'une application plus grande sans avoir d'impact involontairement négatif sur le reste de l'application. diff --git a/content/fr/multitenancy.md b/content/fr/multitenancy.md new file mode 100644 index 0000000000..07fbc34749 --- /dev/null +++ b/content/fr/multitenancy.md @@ -0,0 +1,37 @@ +--- +title: Mutualisation (Multitenancy) +status: Completed +category: Property +tags: ["architecture", "propriété", ""] +--- + +La mutualisation (multitenancy en anglais) fait référence à une installation unique de logiciel utilisé par plusieurs locataires (tenant). +Un locataire est un utilisateur, une application ou un groupe d'utilisateurs/applications qui utilisent le logiciel pour travailler sur ses propres jeux de données. +Ces locataires ne partagent pas de données (sauf si c'est explicitement demandé par le propriétaire) et peuvent même ne pas se connaître. + +Un locataire peut être petit comme un utilisateur indépendant avec un unique identifiant de connexion +— pensez à un logiciel de productivité personnelle — ou aussi grand qu'une entreprise complète avec +des centaines d'identifiants de connexion, chacun avec ses propres droits mais interdépendants de multiples +manières. Les exemples de mutualisation incluent : Google Mail, Google Docs, Microsoft Office 365, Salesforce CRM, +Dropbox, parmi tant d'autres qui sont complètement ou partiellement mutualisés. + +## Problème auquel il répond + +Sans mutualisation, chaque locataire aurait besoin d'une installation logicielle qui lui est dédiée. +Cela augmente l'utilisation de ressources et l'effort de maintenance, et au final le coût du logiciel. + +## Quelle en est l'utilité + +Le logiciel mutualisé fournit à chaque locataire un environnement isolé (données de travail, configurations, liste d'identifiants, etc.), +servant simultanément plusieurs locataires. Du point de vue du locataire, chacun à son installation logicielle dédiée, +bien qu'en réalité, ils en partagent tous une seule. Tout cela est possible en exécutant le logiciel sur un serveur et en autorisant +les colocataires à se connecter à celui-ci par une interface utilisateur et/ou par une [API](/fr/application-programming-interface/) (faisant référence à une +[architecture client-serveur](/fr/client-server-architecture/)). +Avec les logiciels mutualisés, les colocataires partagent les mêmes ressources d'une même installation sans affecter les autres ou seulement +d'une manière prédéfinie et contrôlée. Les ressources économisées du côté du fournisseur du logiciel peuvent être répercutées aux locataires, réduisant +de manière significative le coût du logiciel pour les utilisateurs (encore une fois, pensez aux emails ou aux éditeurs de documents en ligne). + +## Termes liés + +La mutualisation n'est pas un synonyme de SaaS, +bien qu'il soit commun pour les SaaS d'être mutualisés et même de proposer la mutualisation comme un bénéfice majeur. diff --git a/content/fr/mutual-transport-layer-security.md b/content/fr/mutual-transport-layer-security.md index be59aab7a0..1931c829bc 100644 --- a/content/fr/mutual-transport-layer-security.md +++ b/content/fr/mutual-transport-layer-security.md @@ -15,7 +15,7 @@ Les [microservices](/fr/microservices-architecture/) communiquent sur un réseau tout comme sur votre réseau wifi, les communications qui transitent par ce réseau peuvent être piratées. Le mTLS garantit qu'aucune partie non autorisée ne peut écouter ou usurper des requêtes légitimes. -## Quel en est l'utilité +## Quelle en est l'utilité mTLS garantit que le trafic est sécurisé et digne de confiance dans les deux sens entre un client et un serveur, Il fournit une couche de sécurité supplémentaire aux utilisateurs qui se connectent à un réseau ou à des applications. diff --git a/content/fr/nodes.md b/content/fr/nodes.md index 4ea039776e..b836cf4344 100644 --- a/content/fr/nodes.md +++ b/content/fr/nodes.md @@ -18,7 +18,7 @@ En particulier, une défaillance du système sous-jacent va perturber l'applicat Pour résoudre ce problème, les développeurs ont commencé à créer des [applications distribuées](/fr/distributed-apps/) où chaque processus s'exécute sur son propre nœud. Ainsi, les nœuds exécutent des applications ou des processus dans le cadre d'un groupe formant un [cluster](/fr/cluster/), c'est-à-dire un groupe de nœuds qui travaillent ensemble pour atteindre un objectif commun. -## Quel en est l'utilité +## Quelle en est l'utilité Un nœud vous fournit une unité de calcul distincte (mémoire, processeur, réseau) que vous pouvez attribuer à un cluster. Dans une plate-forme ou une application [Cloud Native](/fr/cloud-native-tech/), un nœud représente une unité unique qui peut effectuer un travail. diff --git a/content/fr/pod.md b/content/fr/pod.md index 128c01deef..082477d803 100644 --- a/content/fr/pod.md +++ b/content/fr/pod.md @@ -18,7 +18,7 @@ Si chacun de ces conteneurs étroitement liés était géré individuellement, i Par exemple, l'opérateur devrait continuellement déterminer l'emplacement des conteneurs liés pour s'assurer qu'ils restent ensemble. Et bien que les cycles de vie de ces conteneurs liés doivent être synchronisés, ils ne peuvent être gérés qu'individuellement. -## Quel en est l'utilité +## Quelle en est l'utilité Les pods regroupent des conteneurs étroitement liés en une seule unité, ce qui simplifie considérablement la gestion des conteneurs. Par exemple, des conteneurs auxiliaires sont souvent utilisés parallèlement au conteneur principal pour ajouter des fonctionnalités supplémentaires ou pour mettre en place des configurations globales. diff --git a/content/fr/policy-as-code.md b/content/fr/policy-as-code.md index 50dda7bbb7..cbb71ea2fa 100644 --- a/content/fr/policy-as-code.md +++ b/content/fr/policy-as-code.md @@ -16,7 +16,7 @@ ou de stocker des données en dehors d'une région géographique spécifique. Il est très laborieux et sujet aux erreurs pour les développeurs et les relecteurs de vérifier manuellement les applications et les infrastructures par rapport aux politiques documentées. Les processus manuels ne peuvent pas répondre aux exigences de réactivité et de mise à l'échelle des applications Cloud Natives. -## Quel en est l'utilité +## Quelle en est l'utilité La description des politiques sous forme de code permet la répétabilité et réduit les erreurs (contrairement à ce qui se fait manuellement). Un autre avantage de la politique en tant que code est que le code peut être géré par un système de contrôle de version comme Git. diff --git a/content/fr/role-based-access-control.md b/content/fr/role-based-access-control.md index 3e78f21962..037e04ed20 100644 --- a/content/fr/role-based-access-control.md +++ b/content/fr/role-based-access-control.md @@ -15,7 +15,7 @@ Le RBAC répond au défi de contrôler les ressources auxquelles les membres de Les administrateurs doivent veiller à ce que chaque utilisateur dispose des autorisations adéquates pour accéder aux ressources nécessaires. Cette tâche peut devenir fastidieuse et sujette aux erreurs en l'absence d'un mécanisme structuré de gestion des accès. -## Quel en est l'utilité +## Quelle en est l'utilité Le RBAC offre aux équipes informatiques la possibilité de gérer aisément les autorisations de tous les utilisateurs d'un groupe simultanément, ou d'apporter rapidement des ajustements au niveau d'accès d'un utilisateur individuel en lui attribuant ou en supprimant un rôle. Cette approche garantit la sécurité des données sensibles et veille à ce que les employés n'aient accès qu'aux informations nécessaires à l'exécution de leurs tâches professionnelles. diff --git a/content/fr/runtime.md b/content/fr/runtime.md new file mode 100644 index 0000000000..e27d8c55cc --- /dev/null +++ b/content/fr/runtime.md @@ -0,0 +1,36 @@ +--- +title: Environnement d'exécution (Runtime) +status: Completed +category: concept +tags: ["application", "", ""] +--- + +En général, un environnement d'exécution (ou runtime en anglais) exécute un logiciel. +C'est une [abstraction](/fr/abstraction/) du système d'exploitation sous-jacent qui traduit les commandes du programme en actions pour le système d'exploitation. + +Dans le contexte des [applications Cloud Natives](/fr/cloud-native-apps/), l'environnement d'exécution fait généralement référence à l'environnement d'exécution de conteneurs (ou container runtime en anglais). +Un environnement d'exécution de conteneurs implémente la spécification [Open Container Initiative](https://opencontainers.org/) pour garantir un fonctionnement cohérent des conteneurs quelle que soit la technologie d'orchestration utilisée. + +## Problème auquel il répond + +Sans l'abstraction d'un environnement d'exécution, l'application devrait prendre en considérations toutes les spécificités de chaque système d'exploitation, augmentant la complexité de l'exécution de l'application. + +## Quelle en est l'utilité + +L'environnement d'exécution de conteneurs est un composant nécessaire des orchestrateurs de conteneurs tels que Kubernetes. +Il gère le cycle de vie des conteneurs, et fait principalement trois choses. +Premièrement, il définit comment les images de conteneurs utilisées doivent être spécifiées et comment l'environnement d'exécution peut les récupérer. +Deuxièmement, il gère la manière dont ces images sont décompressées, superposées, montées et exécutées. +En outre, l'environnement d'exécution gère les ressources matérielles en prenant soin de toutes les actions au niveau du système d'exploitation. +Cela inclut l'allocation et l'isolation des ressources. +Avec le temps, différents produits d'environnement d'exécution de conteneurs ont évolué, conduisant à la spécification OCI, +qui est devenue la norme pour les environnements d'exécution de conteneurs. + +L'introduction de cette norme permet aux utilisateurs finaux de combiner n'importe quel environnement d'exécution conforme à la spécification OCI avec n'importe quel orchestrateur de conteneurs conforme à la spécification OCI (comme Kubernetes). + +## Termes liés + +- [Cloud Native](/fr/cloud-native-apps/) +- [Conteneurisation](/fr/containerization/) +- [Orchestration de Conteneurs](/fr/container-orchestration/) +- [Architecture en Microservices](/fr/microservices-architecture/) diff --git a/content/fr/security-chaos-engineering.md b/content/fr/security-chaos-engineering.md new file mode 100644 index 0000000000..1451e03892 --- /dev/null +++ b/content/fr/security-chaos-engineering.md @@ -0,0 +1,33 @@ +--- +title: Sécurité par l'ingénierie du chaos +status: Completed +category: concept +tags: ["sécurité", "méthodologie", ""] +--- + +La sécurité par l'ingénierie du chaos, ou SCE (Security Chaos Engineering en anglais), est une discipline basée sur l'[ingénierie du chaos](/fr/chaos-engineering/). +La SCE réalise des tests de sécurité proactifs sur un système distribué +pour accroître la confiance dans la capacité du système à faire face à des conditions instables et malveillantes. +Les ingénieurs en sécurité du chaos utilisent, en boucle, des méthodes scientifiques pour y parvenir, +comme la définition de l'état d'équilibre (steady-state), d'hypothèses, l'amélioration continue, l'apprentissage et la mise en œuvre de mesures d'atténuation. + +## Problème auquel cela répond + +La principale priorité des ingénieurs en fiabilité des sites et des ingénieurs en cybersécurité est +de rétablir le service le plus rapidement possible dans le but d'avoir un temps d'indisponibilité nul et de minimiser l'impact client. +Les ingénieurs en fiabilité des sites et en cybersécurité gèrent à la fois les incidents avant et après la défaillance. +La plupart des problèmes de sécurité sont difficiles à découvrir et à corriger rapidement, ce qui affecte les fonctionnalités de l'application ou du système. +De plus, les incidents de sécurité sont généralement difficiles à détecter pendant la phase de développement. + +## Quelle en est l’utilité + +La sécurité par l'ingénierie du chaos est construite autour des pratiques d'[observabilité](/fr/observability/) et de cyber-résilience. +Elle vise à découvrir les "inconnues inconnues" et à renforcer la confiance dans le système, +augmentant ainsi la cyber-résilience et améliorant l'observabilité. + +Les équipes d'ingénierie amélioreront progressivement la compréhension des problèmes de sécurité +au sein d'infrastructures complexes, de plates-formes et de systèmes distribués. +La SCE améliore la cyber-résilience de l'ensemble du produit, révèle des problèmes de sécurité cachés, +expose les angles morts classiques et prépare les équipes aux cas critiques. +Cette approche aide les ingénieurs [SREs](/fr/site-reliability-engineering/), [DevOps](/fr/devops/) et [DevSecOps](/fr/devsecops/) +à créer de la confiance dans le système, à augmenter la cyber-résilience et à améliorer l'observabilité. \ No newline at end of file diff --git a/content/fr/serverless.md b/content/fr/serverless.md new file mode 100644 index 0000000000..08ba75b78b --- /dev/null +++ b/content/fr/serverless.md @@ -0,0 +1,31 @@ +--- +Title: Serverless +Status: Completed +Category: Technology +tags: ["architecture", "", ""] +--- + +Le serverless, que l'on pourrait traduire littéralement par "sans serveur", est un modèle de développement Cloud Native qui permet aux développeurs de construire et d'exécuter des applications sans avoir à gérer de serveurs. +Bien que les serveurs existent toujours dans le paradigme serverless, ils sont [abstraits](/fr/abstraction/) du processus de développement de l'application. +Un fournisseur de cloud s'occupe du travail routinier de mise à disposition, de maintenance et de [mise à l'échèle](/fr/scalability/) de l'infrastructure. +Les développeurs peuvent facilement empaqueter leur code dans des [conteneurs](/fr/container/) pour le déployer. +Une fois déployées, les applications serverless répondent à la demande et se mettent à l'échelle automatiquement. +Les offres serverless des fournisseurs de cloud public sont généralement jaugés à l'utilisation au travers d'un modèle d'exécution basé sur des événements. +Par conséquent, lorsqu'une fonction serverless est inutilisée, il n'y a pas de coûts associés. + +## Problème auquel il répond + +Dans le cadre d'un modèle standard d'[infrastructure en tant que service (IaaS)](/fr/infrastructure-as-a-service/) [cloud computing](/fr/cloud-computing/), les utilisateurs achètent à l'avance des unités de capacité, +ce qui signifie que vous payez un fournisseur de cloud public pour des serveurs toujours actifs afin d'exécuter vos applications. +Il incombe à l'utilisateur d'augmenter la capacité des serveurs en cas de forte demande et de la réduire lorsque cette capacité n'est plus nécessaire. +L'infrastructure cloud nécessaire au fonctionnement d'une application reste active même lorsque l'application n'est pas utilisée. + +## Quelle en est l'utilité + +Contrairement aux approches traditionnelles, l'architecture serverless ne lance les applications que lorsqu'elles sont nécessaires. +Lorsqu'un événement déclenche l'exécution du code de l'application, le fournisseur de cloud public alloue dynamiquement des ressources à ce code. +L'utilisateur cesse de payer lorsque le code a fini de s'exécuter. +Outre les avantages en termes de coûts et d'efficacité, +le serverless libère les développeurs des tâches routinières et pénibles associées à la mise à l'échelle des applications et à la mise à disposition des serveurs. +Avec le serverless, les tâches de routine telles que la gestion du système d'exploitation et du système de fichiers, les correctifs de sécurité, +l'équilibrage de charge, la gestion de la capacité, la mise à l'échelle, la journalisation et la supervision sont toutes transférées à un fournisseur de services cloud. diff --git a/content/fr/service-discovery.md b/content/fr/service-discovery.md new file mode 100644 index 0000000000..d99d41580f --- /dev/null +++ b/content/fr/service-discovery.md @@ -0,0 +1,22 @@ +--- +title: Découverte de services (Service Discovery) +status: Completed +category: Concept +tags: ["réseau", "", ""] +--- + +La découverte de services est le processus permettant de découvrir les différentes instances qui composent un service. +Un outil de découverte de service garde une trace des différents nœuds ou points de terminaison qui constituent un service. + +## Problème auquel il répond + +Les architectures cloud natives sont dynamiques et fluides, ce qui signifie qu'elles changent constamment. +Une application [conteneurisée](/fr/containerization/) finira probablement par démarrer et s'arrêter plusieurs fois au cours de sa durée de vie. +À chaque fois que cela se produit, elle aura une nouvelle adresse et +toute application qui souhaite la trouver aura besoin d'un outil qui lui fournira les nouvelles informations de localisation. + +## Quelle en est l'utilité + +Le mécanisme de découverte de services garde une trace des applications au sein du réseau afin qu'elles puissent se trouver mutuellement en cas de besoin. +Il fournit une méthode simple pour trouver et potentiellement identifier les services individuels. +Les moteurs de découverte de services sont des outils semblables à des bases de données qui stockent les informations sur les services existants et comment les localiser. \ No newline at end of file diff --git a/content/fr/service-mesh.md b/content/fr/service-mesh.md index dff5acde48..53918a6a93 100644 --- a/content/fr/service-mesh.md +++ b/content/fr/service-mesh.md @@ -22,7 +22,7 @@ réglementaires, fournir des métriques pour les équipes opérationnelles et pr pour aider à diagnostiquer les problèmes. Si cela devait être géré au niveau de chaque application, chacune de ces fonctionnalités pourrait conduire à créer des frictions entre les équipes et ralentir le développement de nouvelles fonctionnalités. -## Quel en est l'utilité +## Quelle en est l'utilité Le maillage de services (services mesh) ajoute de la fiabilité, de l'observabilité et de la sécurité pour tous les services du cluster sans avoir à changer le code des services. diff --git a/content/fr/service-proxy.md b/content/fr/service-proxy.md new file mode 100644 index 0000000000..db17554921 --- /dev/null +++ b/content/fr/service-proxy.md @@ -0,0 +1,28 @@ +--- +title: Proxy de service +status: Completed +category: technology +tags: ["réseau", "", ""] +--- + +Un proxy de service intercepte le trafic vers ou depuis un [service](/fr/service/) donné, +lui applique une certaine logique, puis transmet ce trafic à un autre service. +Il agit essentiellement comme un "intermédiaire" qui collecte des informations sur le trafic réseau et/ou lui applique des règles. + +## Problème auquel il répond + +Pour suivre la communication de service à service (c'est-à-dire le trafic réseau) et +potentiellement la transformer ou la rediriger, nous devons collecter des données. +Traditionnellement, le code permettant la collecte de données et la gestion du trafic réseau étaient intégrés à chaque application. + +## Quelle en est l'utilité + +Un proxy de service nous permet "d’externaliser" cette fonctionnalité. +Il n'est plus nécessaire qu'elle réside à l'intérieur des applications. +Au lieu de cela, elle est désormais intégrée à la couche plate-forme (où vos applications s’exécutent). + +Agissant comme des gardiens entre les services, les proxys donnent un aperçu du type de communication en cours. +En fonction de leur observations, ils déterminent où envoyer une demande particulière ou même la refusent complètement. + +Les proxys collectent des données critiques, gèrent le routage (en répartissant le trafic uniformément entre les services ou en le déroutant en cas de panne de certains services), +chiffrent les connexions et mettent en cache le contenu (réduisant la consommation de ressources). diff --git a/content/fr/shift-left.md b/content/fr/shift-left.md new file mode 100644 index 0000000000..444159db72 --- /dev/null +++ b/content/fr/shift-left.md @@ -0,0 +1,39 @@ +--- +title: Décalage vers la gauche (Shift Left) +status: Completed +category: Concept +tags: ["méthodologie", "", ""] +--- + +Le terme "gauche" dans "décalage vers la gauche" fait référence aux premières étapes dans le cycle de vie du développement logiciel, +en envisageant ce cycle comme une ligne où les étapes sont exécutées de gauche à droite. +Le décalage vers la gauche est la pratique consistant à mettre en œuvre des tests, la sécurité ou d'autres pratiques de développement +tôt dans le cycle de vie du développement logiciel plutôt que vers la fin. + +Bien qu'à l'origine utilisé pour désigner le processus de test anticipé, +le décalage vers la gauche peut désormais également s'appliquer à d'autres aspects du développement logiciel et du [DevOps](/fr/devops/), tels que la sécurité et le déploiement. + +## Problème auquel il répond + +Les problèmes de sécurité, les bugs et les défauts logiciels peuvent être plus difficiles et coûteux à résoudre +s'ils sont découverts tard dans le cycle de développement ou après le déploiement, +en particulier si le logiciel a déjà été déployé en production. + +## Quelle en est l'utilité + +En adoptant une mentalité décalage vers la gauche pour le développement logiciel, +les équipes peuvent mettre en œuvre des tests et la sécurité tout au long du cycle de développement. +Et comme la responsabilité des tests et de la sécurité est partagée dans toute l'équipe de développement +— des ingénieurs logiciels à l'assurance qualité en passant par les opérations — +chacun joue un rôle dans la garantie de la stabilité et de la sécurité d'une application. + +De plus, le décalage vers la gauche permet une amélioration continue et +suit une approche de développement [agile](/fr/agile-software-development/) plutôt que linéaire (waterfall). + +Les équipes peuvent apporter de petites améliorations itératives et identifier les problèmes plus tôt. +Cette approche permet aux ingénieurs d'adopter des pratiques de sécurité et de développement sécurisé +dès la phase de conception et d'architecture. +Tester tout au long du cycle de développement réduit le temps nécessaire pour les tests avant la publication d'un logiciel. + +De nombreux outils logiciels et solutions SaaS aident à déplacer ces pratiques vers la gauche. +Cependant, le décalage vers la gauche peut également être mis en œuvre grâce à des processus améliorés et des changements culturels au sein d'une équipe. \ No newline at end of file diff --git a/content/fr/site-reliability-engineering.md b/content/fr/site-reliability-engineering.md new file mode 100644 index 0000000000..1a3cab30e4 --- /dev/null +++ b/content/fr/site-reliability-engineering.md @@ -0,0 +1,26 @@ +--- +title: Ingénierie de la fiabilité des sites (SRE) +status: Completed +category: concept +tags: ["méthodologie", "", ""] +--- + +L'ingénierie de la fiabilité des sites (ou SRE pour Site Reliability Engineering en anglais) est une discipline qui combine l'exploitation informatique et le développement logiciel. +Ce dernier est utilisé spécifiquement pour résoudre des problèmes d'infrastructure et d'exploitation informatique. +En d'autres termes, au lieu de créer des fonctionnalités pour une application, les ingénieurs en fiabilité des sites construisent des systèmes pour faire fonctionner les applications. +Il existe des similitudes avec le [DevOps](/fr/devops/), mais tandis que le DevOps se concentre sur la mise en production du code, le SRE s'assure que le code exécuté en production fonctionne correctement. + +## Problème auquel il répond + +Garantir le fonctionnement [fiable](/fr/reliability/) des applications requiert de nombreuses capacités, +de la surveillance des performances à la gestion des alertes, du débogage au dépannage. +Sans ces capacités, les opérateurs de systèmes ne peuvent que réagir aux problèmes au lieu de travailler de manière proactive pour les éviter +— Les indisponibilités ne sont plus qu'une question de temps. + +## Quelle en est l'utilité + +Une approche SRE minimise le coût, le temps et les efforts du processus de développement logiciel +en améliorant continuellement le système sous-jacent. +Le système mesure et surveille en permanence les composants de l'infrastructure et de l'application. +Lorsque quelque chose ne va pas, le système indique aux ingénieurs en fiabilité des sites quand, où et comment le réparer. +Cette approche permet de créer des systèmes logiciels avec une grande [capacité de mise à l'échelle](/fr/scalability/) et fiables en automatisant les tâches opérationnelles. diff --git a/content/fr/stateful-apps.md b/content/fr/stateful-apps.md new file mode 100644 index 0000000000..ce99b979e9 --- /dev/null +++ b/content/fr/stateful-apps.md @@ -0,0 +1,16 @@ +--- +title: Applications avec état (Stateful Apps) +status: Completed +category: Property +tags: ["fondamental", "application", "propriété"] +--- + +Lorsque nous parlons d'applications avec état (et [sans état](/fr/stateless-apps/)), +l'état fait référence à toutes les données que l'application doit stocker pour fonctionner comme prévu. +Par exemple, tout type de boutique en ligne qui se souvient de votre panier est une application avec état. + +Aujourd'hui, la plupart des applications que nous utilisons sont au moins partiellement avec état. Cependant, dans les environnements cloud natifs, +les applications avec état posent des difficultés. En effet, les [applications cloud natives](/fr/cloud-native-apps/) sont très dynamiques. +Elles peuvent être mises à l'échelle, redémarrées et déplacées, mais elles doivent toujours pouvoir accéder à leur état. + +Par conséquent, les applications avec état ont besoin d'une forme de stockage accessible de n'importe où, comme des bases de données. diff --git a/content/fr/stateless-apps.md b/content/fr/stateless-apps.md new file mode 100644 index 0000000000..55a938c4bd --- /dev/null +++ b/content/fr/stateless-apps.md @@ -0,0 +1,15 @@ +--- +title: Applications sans état (Stateless Apps) +status: Completed +category: Property +tags: ["fondamental", "application", "propriété"] +--- + +Les applications sans état (Stateless Apps en anglais) traitent les requêtes comme si chaque requête était la toute première envoyée. +L'application ne "se souvient" ni des interactions précédentes ni des données de session utilisateur. +Les données provenant des interactions précédentes sont appelées état, et comme ces données ne sont stockées nulle part, ces applications sont sans état (stateless). +Voici un exemple : +Lorsque vous utilisez un moteur de recherche et que cette recherche est interrompue (par exemple, la fenêtre est fermée), les résultats de recherche sont perdus. +Vous devrez tout recommencer. + +En revanche, les applications qui traitent les requêtes en tenant compte des interactions précédentes sont appelées [applications avec état](/fr/stateful-apps/) (stateful). \ No newline at end of file diff --git a/content/fr/style-guide/_index.md b/content/fr/style-guide/_index.md index 5b914765d6..06f9fa572a 100644 --- a/content/fr/style-guide/_index.md +++ b/content/fr/style-guide/_index.md @@ -48,7 +48,7 @@ Un bref descriptif de la technologie ou du concept. Quelques lignes à propos du problème qu'il adresse. -## Quel en est l'utilité +## Quelle en est l'utilité Quelques lignes sur comment le problème est résolu. ``` @@ -107,7 +107,7 @@ Les définitions pour les catégories **technology** et **concept** contiennent - **Ce que c'est** : fournis une explication claire et concise de ce dont nous parlons. - **Problème qu'il adresse** : se concentre sur le problème, pas la solution (cela vient dans la section suivante). Pour faire simple, éviter de mentionner le terme qui est défini. Le problème nous aide à nous concentrer sur *ce qui* nous a mené à avoir besoin de ce terme. -- **Quel en est l'utilité**: maintenant, revenir sur le terme en lui-même. Comment est-ce qu'il adresse le problème décrit précédemment ? +- **Quelle en est l'utilité**: maintenant, revenir sur le terme en lui-même. Comment est-ce qu'il adresse le problème décrit précédemment ? Noter que les propriétés ne nécessitent pas de section séparée. Un définition suffira. diff --git a/content/fr/tightly-coupled-architectures.md b/content/fr/tightly-coupled-architecture.md similarity index 96% rename from content/fr/tightly-coupled-architectures.md rename to content/fr/tightly-coupled-architecture.md index 4705edbabb..39d4c3bd1a 100644 --- a/content/fr/tightly-coupled-architectures.md +++ b/content/fr/tightly-coupled-architecture.md @@ -1,5 +1,5 @@ --- -title: Architectures Fortement Couplées +title: Architecture Fortement Couplée status: Completed category: Property tags: ["fondamental", "architecture", "propriété"] diff --git a/content/fr/transport-layer-security.md b/content/fr/transport-layer-security.md index 379b85bc94..cf9a69f5a9 100644 --- a/content/fr/transport-layer-security.md +++ b/content/fr/transport-layer-security.md @@ -17,7 +17,7 @@ La prise en charge de TLS par les applications serveurs et clientes garantit que les données transmises entre elles sont chiffrées et ne peuvent pas être consultées par des tiers. -## Quel en est l'utilité +## Quelle en est l'utilité TLS utilise une combinaison de techniques de chiffrement qui assurent la sécurité lors de la transmission de données sur un réseau. TLS permet une connexion chiffrée entre une application cliente et un serveur, par exemple un navigateur web et un site bancaire. diff --git a/content/fr/vertical-scaling.md b/content/fr/vertical-scaling.md index 81b6b6753c..346ff72514 100644 --- a/content/fr/vertical-scaling.md +++ b/content/fr/vertical-scaling.md @@ -14,7 +14,7 @@ Lorsque la demande d'une application dépasse la capacité actuelle de l'instanc Nous pouvons soit ajouter plus de ressources informatiques aux nœuds existants (mise à l'échelle verticale), soit ajouter plus de nœuds au système ([mise à l'échelle horizontale](/fr/horizontal-scaling/)). La [capacité de mise à l'échelle](/fr/scalability/) contribue à la compétitivité, à l'efficacité, à la réputation et à la qualité. -## Quel en est l'utilité +## Quelle en est l'utilité La mise à l'échelle verticale vous permet de redimensionner votre serveur sans modifier le code de l'application. Cela contraste avec la mise à l'échelle horizontale, où l'application doit être réplicable pour être mise à l'échelle, ce qui peut nécessiter des mises à jour du code. diff --git a/content/fr/zero-trust-architecture.md b/content/fr/zero-trust-architecture.md index ecd9cce0e7..205afa2c71 100644 --- a/content/fr/zero-trust-architecture.md +++ b/content/fr/zero-trust-architecture.md @@ -23,7 +23,7 @@ L'attaquant se trouve alors à l'intérieur du périmètre "de confiance" du ré Dans une architecture zéro confiance, la confiance est éliminée, réduisant ainsi la surface d'attaque, car un attaquant est contraint de se soumettre à une vérification avant de pouvoir progresser dans le système. -## Quel en est l'utilité +## Quelle en est l'utilité L'adoption d'une architecture zéro confiance présente le principal avantage d'augmenter la sécurité tout en réduisant la surface d'attaque. En éliminant la notion de confiance de votre système d'entreprise, diff --git a/content/hi/devops.md b/content/hi/devops.md index 506935e403..776a5c28c6 100644 --- a/content/hi/devops.md +++ b/content/hi/devops.md @@ -10,7 +10,7 @@ DevOps एक कार्यप्रणाली है जिसमें ट ## समस्या -परंपरागत रूप से, [टाइटली-कपल्ड](/tightly-coupled-architectures/) [मोनोलिथिक ऐप्स](/monolithic-apps/) का प्रयोग वाले जटिल संगठनों में, काम आम तौर पर कई समूहों के बीच खंडित होता था। इसमें एप्लीकेशन कई टीमों के बीच जाता था और काफी लम्बा समय लगता था। हर बार जब कोई घटक या अपडेट तैयार होता था, तो उसे अगली टीम के लिए एक कतार में रखा जाता था। क्योंकि प्रत्येक व्यक्ति केवल परियोजना के एक छोटे से हिस्से पर काम करता था, इस दृष्टिकोण के कारण स्वामित्व की कमी होती थी। उनका लक्ष्य काम को अगले समूह तक पहुंचाना था, न कि ग्राहक को सही कार्यक्षमता प्रदान करना - प्राथमिकताओं का एक स्पष्ट गलत संरेखण। +परंपरागत रूप से, [टाइटली-कपल्ड](/tightly-coupled-architecture/) [मोनोलिथिक ऐप्स](/monolithic-apps/) का प्रयोग वाले जटिल संगठनों में, काम आम तौर पर कई समूहों के बीच खंडित होता था। इसमें एप्लीकेशन कई टीमों के बीच जाता था और काफी लम्बा समय लगता था। हर बार जब कोई घटक या अपडेट तैयार होता था, तो उसे अगली टीम के लिए एक कतार में रखा जाता था। क्योंकि प्रत्येक व्यक्ति केवल परियोजना के एक छोटे से हिस्से पर काम करता था, इस दृष्टिकोण के कारण स्वामित्व की कमी होती थी। उनका लक्ष्य काम को अगले समूह तक पहुंचाना था, न कि ग्राहक को सही कार्यक्षमता प्रदान करना - प्राथमिकताओं का एक स्पष्ट गलत संरेखण। जब तक कोड अंततः उत्पादन में आया, तब तक यह इतने सारे डेवलपर्स के माध्यम से चला गया, इतनी कतारों में प्रतीक्षा कर रहा था कि यदि कोड काम नहीं करता है तो समस्या की उत्पत्ति का पता लगाना मुश्किल था। DevOps ने इस दृष्टिकोण को पलट कर रख दिया। diff --git a/content/ja/agile-software-development.md b/content/ja/agile-software-development.md index 98adba0bf2..56d48da7a4 100644 --- a/content/ja/agile-software-development.md +++ b/content/ja/agile-software-development.md @@ -6,8 +6,7 @@ tags: ["方法論", "", ""] --- アジャイルソフトウェア開発は、繰り返しの開発サイクルと自己組織化チームを重視する一連の実践です。 -プロジェクトの最後にのみ価値が生み出されるウォーターフォール型のプロジェクトとは対照的に、 -アジャイルソフトウェア開発は、継続的かつ段階的な価値の提供とプロセス自体の進化的な改善に焦点を当てています。 +プロジェクトの最後にのみ価値が生み出されるウォーターフォール型のプロジェクトとは対照的に、アジャイルソフトウェア開発は、継続的かつ段階的な価値の提供とプロセス自体の進化的な改善に焦点を当てています。 ## 解決すべき問題はなんですか diff --git a/content/ja/api-gateway.md b/content/ja/api-gateway.md index 8efe5d6abd..f13ab4dcc1 100644 --- a/content/ja/api-gateway.md +++ b/content/ja/api-gateway.md @@ -5,25 +5,18 @@ category: テクノロジー tags: ["ネットワーキング", "", ""] --- -[API](/ja/application-programming-interface/)ゲートウェイは、いくつかのアプリケーションAPIを集約し、 -それらを一か所で利用可能にするツールです。 -これにより認証や認可、 -またはアプリケーション間のリクエスト数を制限するなどの重要な機能を中央管理された場所に集約することができます。 +[API](/ja/application-programming-interface/)ゲートウェイは、いくつかのアプリケーションAPIを集約し、それらを一か所で利用可能にするツールです。 +これにより認証や認可、またはアプリケーション間のリクエスト数を制限するなどの重要な機能を中央管理された場所に集約することができます。 APIゲートウェイは、(しばしば外部の)APIの利用者に対する共通のインターフェースとして機能します。 ## 解決すべき問題はなんですか -外部の利用者にAPIを提供する場合、 -すべてのアクセスを管理・制御するための一つのエントリーポイントが必要になります。 -さらに、それらのやり取りに機能を適用する必要がある場合、 -APIゲートウェイを使用するとアプリのコードを変更することなく、すべてのトラフィックに対して一様にそれを適用することができます。 +外部の利用者にAPIを提供する場合、すべてのアクセスを管理・制御するための一つのエントリーポイントが必要になります。 +さらに、それらのやり取りに機能を適用する必要がある場合、APIゲートウェイを使用するとアプリのコードを変更することなく、すべてのトラフィックに対して一様にそれを適用することができます。 ## どのように役に立つのでしょうか -アプリケーション内のさまざまなAPIに対して単一のアクセスポイントを提供するAPIゲートウェイは、 -組織の横断的なビジネスロジックやセキュリティロジックを一箇所に集中して適用するのを容易にします。 +アプリケーション内のさまざまなAPIに対して単一のアクセスポイントを提供するAPIゲートウェイは、組織の横断的なビジネスロジックやセキュリティロジックを一箇所に集中して適用するのを容易にします。 また、アプリケーションの利用者がすべてのニーズに対して単一のアドレスを通じてアクセスできるようにもします。 -APIゲートウェイは、システム内のすべてのウェブサービスへのリクエストに対して単一のアクセスポイントを提供することで、 -セキュリティや[可観測性](/ja/observability/)などの運用上の懸念を簡素化することができます。 -すべてのリクエストがAPIゲートウェイを通過するため、 -メトリクス収集、レート制限、認証などの機能を追加するための単一の場所となります。 +APIゲートウェイは、システム内のすべてのウェブサービスへのリクエストに対して単一のアクセスポイントを提供することで、セキュリティや[オブザーバビリティ](/ja/observability/)などの運用上の懸念を簡素化することができます。 +すべてのリクエストがAPIゲートウェイを通過するため、メトリクス収集、レート制限、認証などの機能を追加するための単一の場所となります。 diff --git a/content/ja/auto-scaling.md b/content/ja/auto-scaling.md index d3371ffe38..c8b8ffa080 100644 --- a/content/ja/auto-scaling.md +++ b/content/ja/auto-scaling.md @@ -2,7 +2,7 @@ title: オートスケーリング status: Completed category: プロパティ -tags: ["インフラストラクチャー", "", ""] +tags: ["インフラストラクチャ", "", ""] --- オートスケーリングとは、システムが自動的に[スケール](/ja/scalability/)する能力のことで、通常はコンピューティングリソースにおいて行われます。 @@ -11,7 +11,7 @@ tags: ["インフラストラクチャー", "", ""] マネージドクラウドサービスには通常、オートスケーリング機能が関連しています。 これは、ほとんどのオンプレミス環境へのデプロイよりも多くのオプションと実装が利用可能であるためです。 -以前はインフラストラクチャーとアプリケーションが、システムのピーク使用量を考慮して設計されていました。 +以前はインフラストラクチャとアプリケーションが、システムのピーク使用量を考慮して設計されていました。 このアーキテクチャにより、多くのリソースが未使用であり、消費者需要の変化に対して非弾力的でした。 非弾力性は、ビジネスへの高コストと、過剰な需要によって発生する障害の営業損失を意味します。 diff --git a/content/ja/bare-metal-machine.md b/content/ja/bare-metal-machine.md index bfe14ff754..acd3eb5049 100644 --- a/content/ja/bare-metal-machine.md +++ b/content/ja/bare-metal-machine.md @@ -2,17 +2,24 @@ title: ベアメタルマシン status: Completed category: テクノロジー -tags: ["インフラストラクチャー", "", ""] +tags: ["インフラストラクチャ", "", ""] --- -ベアメタルとは物理コンピューターを意味し、具体的にはサーバーのことでありオペレーティングシステムが1つしかないものです。最近のコンピューティングでは、サーバーの多くが[仮想マシン](/ja/virtual-machine/)であるため、この区別は重要です。物理サーバーは、一般的に強力なハードウェアを内蔵したかなり大型のコンピューターです。[仮想化](/ja/virtualization/)せずに、物理ハードウェア上にオペレーティングシステムをインストールし直接アプリケーションを実行することを"ベアメタル"上で実行すると呼ばれます。 +ベアメタルとは物理コンピューターを意味し、具体的にはサーバーのことでありオペレーティングシステムが1つしかないものです。 +最近のコンピューティングでは、サーバーの多くが[仮想マシン](/ja/virtual-machine/)であるため、この区別は重要です。 +物理サーバーは、一般的に強力なハードウェアを内蔵したかなり大型のコンピューターです。 +[仮想化](/ja/virtualization/)せずに、物理ハードウェア上にオペレーティングシステムをインストールし直接アプリケーションを実行することを"ベアメタル"上で実行すると呼ばれます。 ## 解決すべき問題はなんですか -1つのオペレーティングシステムと1台の物理コンピューターの組み合わせはコンピューティングの原型です。物理コンピューターのすべてのリソースがオペレーティングシステムで直接利用可能であり、仮想化レイヤーが存在しないため、オペレーティングシステムの命令をハードウェアに変換する際に人工的な遅延が発生しません。 +1つのオペレーティングシステムと1台の物理コンピューターの組み合わせはコンピューティングの原型です。 +物理コンピューターのすべてのリソースがオペレーティングシステムで直接利用可能であり、仮想化レイヤーが存在しないため、オペレーティングシステムの命令をハードウェアに変換する際に人工的な遅延が発生しません。 ## どのように役に立つのでしょうか -コンピューターのすべての計算リソースを単一のオペレーティングシステムに割り当てることで、オペレーティングシステムに最高のパフォーマンスを提供できる可能性があります。ハードウェアリソースに極めて高速にアクセスしなければならないワークロードを実行する必要がある場合、ベアメタルが適切なソリューションかもしれません。 +コンピューターのすべての計算リソースを単一のオペレーティングシステムに割り当てることで、オペレーティングシステムに最高のパフォーマンスを提供できる可能性があります。 +ハードウェアリソースに極めて高速にアクセスしなければならないワークロードを実行する必要がある場合、ベアメタルが適切なソリューションかもしれません。 -[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)のコンテキストでは、私たちは一般的にパフォーマンスを、[水平スケーリング](/ja/horizontal-scaling/)（リソースプールにマシンを追加する）で処理できる多数の並行イベントへの[スケーリング](/ja/scalability/)という観点から考えます。しかし、ワークロードによっては[垂直スケーリング](/ja/vertical-scaling/)（既存の物理マシンにさらにパワーを追加する）が必要な場合や、極めて高速な物理ハードウェアのレスポンスが必要になる場合はベアメタルが適しています。また、ベアメタルにおいては、タスクを達成するために、物理ハードウェアや場合によってはハードウェアドライバをチューニングすることもできます。 +[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)のコンテキストでは、私たちは一般的にパフォーマンスを、[水平スケーリング](/ja/horizontal-scaling/)（リソースプールにマシンを追加する）で処理できる多数の並行イベントへの[スケーリング](/ja/scalability/)という観点から考えます。 +しかし、ワークロードによっては[垂直スケーリング](/ja/vertical-scaling/)（既存の物理マシンにさらにパワーを追加する）が必要な場合や、極めて高速な物理ハードウェアのレスポンスが必要になる場合はベアメタルが適しています。 +また、ベアメタルにおいては、タスクを達成するために、物理ハードウェアや場合によってはハードウェアドライバをチューニングすることもできます。 diff --git a/content/ja/blue-green-deployment.md b/content/ja/blue-green-deployment.md index 6762a06c18..1f2a3b3142 100644 --- a/content/ja/blue-green-deployment.md +++ b/content/ja/blue-green-deployment.md @@ -5,7 +5,7 @@ category: コンセプト tags: ["方法論", "アプリケーション", ""] --- -ブルーグリーンデプロイメントは、最小限のダウンタイムで稼働中のコンピュータシステムを更新する戦略です。 +ブルーグリーンデプロイメントは、最小限のダウンタイムで稼働中のコンピューターシステムを更新する戦略です。 オペレーターは、"ブルー"と"グリーン"と呼ばれる2つの環境を維持します。 一方は本番トラフィックを処理し(現在すべてのユーザーが使用しているバージョン)、もう一方が更新されます。 アクティブではない(グリーン)環境のテストが終了すると、本番トラフィックは(しばしばロードバランサーを使用して)切り替えられます。 diff --git a/content/ja/chaos-engineering.md b/content/ja/chaos-engineering.md index 5b7cca2143..011d974a4b 100644 --- a/content/ja/chaos-engineering.md +++ b/content/ja/chaos-engineering.md @@ -12,13 +12,13 @@ tags: ["方法論", "", ""] [SRE](/ja/site-reliability-engineering/)や[DevOps](/ja/devops/)の実践は、プロダクトの回復力と[信頼性](/ja/reliability/)を高める技術に焦点を当てています。 システムが障害を許容しつつ適切なサービス品質を保証する能力は、通常のソフトウェア開発の要件です。 -インフラストラクチャー、プラットフォーム、あるいは([マイクロサービス](/ja/microservices-architecture)ベースの)アプリケーションの他の動作部分のように、アプリケーションの停止につながる可能性のある複数の側面が関与しています。 +インフラストラクチャ、プラットフォーム、あるいは([マイクロサービス](/ja/microservices-architecture/)ベースの)アプリケーションの他の動作部分のように、アプリケーションの停止につながる可能性のある複数の側面が関与しています。 本番環境に新機能を高頻度でデプロイすることは、高い確率でダウンタイムと重大なインシデントをもたらし、ビジネスに重大な影響を及ぼす可能性があります。 ## どのように役に立つのでしょうか カオスエンジニアリングは、回復力の要件を満たすための技術です。 -インフラストラクチャー、プラットフォーム、そしてアプリケーションの障害に対する回復力を達成するために使用されます。 -カオスエンジニアは、アプリケーション、インフラストラクチャー、あるいはプラットフォームが自己修復でき障害が顧客に目立った影響を与えないことを検証するために、プロアクティブにランダムな障害を注入するカオス実験を行います。 +インフラストラクチャ、プラットフォーム、そしてアプリケーションの障害に対する回復力を達成するために使用されます。 +カオスエンジニアは、アプリケーション、インフラストラクチャ、あるいはプラットフォームが自己修復でき障害が顧客に目立った影響を与えないことを検証するために、プロアクティブにランダムな障害を注入するカオス実験を行います。 カオス実験の目的は、盲点(例えば、モニタリングや自動スケーリング技術)を発見し、重大なインシデントの最中にチーム間のコミュニケーションを改善することです。 このアプローチは、特に本番環境において、複雑なシステムにおける回復力とチームの自信を高めるのに役立ちます。 diff --git a/content/ja/client-server-architecture.md b/content/ja/client-server-architecture.md index bab2dc42f7..673af6b4df 100644 --- a/content/ja/client-server-architecture.md +++ b/content/ja/client-server-architecture.md @@ -16,12 +16,11 @@ tags: ["アーキテクチャ", "基礎", ""] クライアントサーバーアーキテクチャは、自己完結型のアプリケーションが抱える、定期的な更新という大きな課題を解決します。 自己完結型アプリでは、更新のたびにユーザーは最新バージョンをダウンロードしてインストールする必要があります。 -Amazonの商品カタログ全体を、ブラウジングする前に自分のコンピュータにダウンロードすることを想像してみてください！ +Amazonの商品カタログ全体を、ブラウジングする前に自分のコンピューターにダウンロードすることを想像してみてください！ ## どのように役に立つのでしょうか -リモートサーバーやサービスでアプリケーションロジックを実装することにより、 -オペレーターはクライアント側のロジックを変更することなく、それを更新できます。 +リモートサーバーやサービスでアプリケーションロジックを実装することにより、オペレーターはクライアント側のロジックを変更することなく、それを更新できます。 これによって更新をより頻繁に行うことができます。 データをサーバー上に保存することで、多くのクライアントが同じデータを見て共有することができます。 オンラインのワードプロセッサーを使用することと、従来のオフラインのワードプロセッサーを使用することの違いを考えてみてください。 diff --git a/content/ja/cloud-computing.md b/content/ja/cloud-computing.md index 1681b4dc0a..fc3fee0cd2 100644 --- a/content/ja/cloud-computing.md +++ b/content/ja/cloud-computing.md @@ -2,15 +2,21 @@ title: クラウドコンピューティング status: Completed category: コンセプト -tags: ["インフラストラクチャー", "基礎", ""] +tags: ["インフラストラクチャ", "基礎", ""] --- -クラウドコンピューティングは、CPU、ネットワーク、ディスクなどの計算資源をインターネット上でオンデマンドで提供し、ユーザーは物理的に離れた場所にある計算能力にアクセスし、使用することができるようにします。一般に、クラウド基盤が組織専用のものか、オープンな公共サービスのために共有されているかによって、プライベートクラウドとパブリッククラウドに区別されます。 +クラウドコンピューティングは、CPU、ネットワーク、ディスクなどの計算資源をインターネット上でオンデマンドで提供し、ユーザーは物理的に離れた場所にある計算能力にアクセスし、使用することができるようにします。 +一般に、クラウド基盤が組織専用のものか、オープンな公共サービスのために共有されているかによって、プライベートクラウドとパブリッククラウドに区別されます。 ## 解決すべき問題はなんですか -組織は従来、コンピューティングパワーを拡大しようとする際、主に2つの課題に直面していました。物理的なサーバーとネットワークをホストするための（新しい）設備を取得、サポート、設計するか、既存の設備を拡張、維持するかです。クラウドコンピューティングは、企業がコンピューティングニーズの一部をアウトソースできるようにすることで、この課題を解決しています。 +組織は従来、コンピューティングパワーを拡大しようとする際、主に2つの課題に直面していました。 +物理的なサーバーとネットワークをホストするための（新しい）設備を取得、サポート、設計するか、既存の設備を拡張、維持するかです。 +クラウドコンピューティングは、企業がコンピューティングニーズの一部をアウトソースできるようにすることで、この課題を解決しています。 ## どのように役に立つのでしょうか -クラウドプロバイダーは、企業がオンデマンドでコンピューティングリソースを借り、使用量に応じて料金を支払うことを可能にし、2つの重要な利点をもたらします。第一に、企業は新しい物理的なインフラストラクチャーを待つことなく、計画し、リソースを費やすことなく、製品やサービスに集中することができます。そして2つ目は、必要に応じてオンデマンドで[拡張](/ja/scalability/)できることです。クラウドコンピューティングでは、必要な分だけインフラを導入することができます。 +クラウドプロバイダーは、企業がオンデマンドでコンピューティングリソースを借り、使用量に応じて料金を支払うことを可能にし、2つの重要な利点をもたらします。 +第一に、企業は新しい物理的なインフラストラクチャを待つことなく、計画し、リソースを費やすことなく、製品やサービスに集中することができます。 +そして2つ目は、必要に応じてオンデマンドで[拡張](/ja/scalability/)できることです。 +クラウドコンピューティングでは、必要な分だけインフラを導入することができます。 diff --git a/content/ja/cloud-native-apps.md b/content/ja/cloud-native-apps.md index 8aff40a688..828f4faecc 100644 --- a/content/ja/cloud-native-apps.md +++ b/content/ja/cloud-native-apps.md @@ -5,12 +5,22 @@ category: コンセプト tags: ["アプリケーション", "基礎", ""] --- -クラウドネイティブアプリケーションは、[クラウドコンピューティング](/ja/cloud-computing/)の技術革新を活用するため特別に設計されています。これらのアプリケーションは、それぞれのクラウドアーキテクチャと容易に統合でき、クラウドのリソースと[スケーリング](/ja/scalability/)機能を活用できます。また、クラウドコンピューティングによるインフラストラクチャーの技術革新を活用するアプリケーションのことも指します。今日のクラウドネイティブアプリケーションには、クラウドプロバイダーのデータセンターで実行されるアプリケーションと、オンプレミスのクラウドネイティブプラットフォームで実行されるアプリケーションがあります。 +クラウドネイティブアプリケーションは、[クラウドコンピューティング](/ja/cloud-computing/)の技術革新を活用するため特別に設計されています。 +これらのアプリケーションは、それぞれのクラウドアーキテクチャと容易に統合でき、クラウドのリソースと[スケーリング](/ja/scalability/)機能を活用できます。 +また、クラウドコンピューティングによるインフラストラクチャの技術革新を活用するアプリケーションのことも指します。 +今日のクラウドネイティブアプリケーションには、クラウドプロバイダーのデータセンターで実行されるアプリケーションと、オンプレミスのクラウドネイティブプラットフォームで実行されるアプリケーションがあります。 ## 解決すべき問題はなんですか -従来、オンプレミス環境では、コンピューティングリソースをかなり特化した方法で提供していました。各データセンターは、アプリケーションを特定の環境に[密結合](/ja/tightly-coupled-architectures/)するサービスを持っており、多くの場合、[仮想マシン](/ja/virtual-machine/)やサービスのようなインフラストラクチャーの提供は手作業に大きく依存していました。その結果、開発者とそのアプリケーションは、特定のデータセンターに制約されることになりました。クラウド用に設計されていないアプリケーションは、クラウド環境の耐障害性やスケーリング機能を活用することができません。例えば、正しく起動するために手作業が必要なアプリケーションは、自動的にスケーリングすることができず、障害発生時に自動的に再起動することもできません。 +従来、オンプレミス環境では、コンピューティングリソースをかなり特化した方法で提供していました。 +各データセンターは、アプリケーションを特定の環境に[密結合](/ja/tightly-coupled-architecture/)するサービスを持っており、多くの場合、[仮想マシン](/ja/virtual-machine/)やサービスのようなインフラストラクチャの提供は手作業に大きく依存していました。 +その結果、開発者とそのアプリケーションは、特定のデータセンターに制約されることになりました。 +クラウド用に設計されていないアプリケーションは、クラウド環境の耐障害性やスケーリング機能を活用することができません。 +例えば、正しく起動するために手作業が必要なアプリケーションは、自動的にスケーリングすることができず、障害発生時に自動的に再起動することもできません。 ## どのように役に立つのでしょうか -クラウドネイティブアプリケーションへの万能な道はありませんが、いくつかの共通点はあります。クラウドネイティブアプリケーションは弾力性があり、管理しやすく、それに付随する一連のクラウドサービスによって支援されます。さまざまなクラウドサービスによって、高度な[可観測性](/ja/observability/)が有効になり、ユーザーは問題が深刻化する前に発見して対処することができます。堅牢な自動化と組み合わせることで、エンジニアは最小限の労力で、インパクトの大きい変更を頻繁にかつ予想通りに行うことができます。 +クラウドネイティブアプリケーションへの万能な道はありませんが、いくつかの共通点はあります。 +クラウドネイティブアプリケーションは弾力性があり、管理しやすく、それに付随する一連のクラウドサービスによって支援されます。 +さまざまなクラウドサービスによって、高度な[オブザーバビリティ](/ja/observability/)が有効になり、ユーザーは問題が深刻化する前に発見して対処することができます。 +堅牢な自動化と組み合わせることで、エンジニアは最小限の労力で、インパクトの大きい変更を頻繁にかつ予想通りに行うことができます。 diff --git a/content/ja/cloud-native-security.md b/content/ja/cloud-native-security.md index ab3eaa3a02..5b29362444 100644 --- a/content/ja/cloud-native-security.md +++ b/content/ja/cloud-native-security.md @@ -5,15 +5,23 @@ category: コンセプト tags: ["セキュリティ", "", ""] --- -クラウドネイティブセキュリティは、セキュリティを[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)に組み込むアプローチです。開発から本番に至るまで、アプリケーションのライフサイクル全体にセキュリティが組み込まれていることを保証します。クラウドネイティブセキュリティは、従来のセキュリティモデルと同じ基準を保証しつつ、クラウドネイティブ環境の特性、すなわち迅速なコード変更や非常に短命な[^1]インフラストラクチャーに適応することを目指します。クラウドネイティブセキュリティは、[DevSecOps](/ja/devsecops/)と呼ばれるプラクティスと非常に関係があります。 +クラウドネイティブセキュリティは、セキュリティを[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)に組み込むアプローチです。 +開発から本番に至るまで、アプリケーションのライフサイクル全体にセキュリティが組み込まれていることを保証します。 +クラウドネイティブセキュリティは、従来のセキュリティモデルと同じ基準を保証しつつ、クラウドネイティブ環境の特性、すなわち迅速なコード変更や非常に短命な[^1]インフラストラクチャに適応することを目指します。 +クラウドネイティブセキュリティは、[DevSecOps](/ja/devsecops/)と呼ばれるプラクティスと非常に関係があります。 [^1]: 訳注：必要に応じてリソースを動的に拡張したり縮小したりするといった性質を持つ ## 解決すべき問題はなんですか -従来のセキュリティモデルは、もはや有効でない多くの前提のもとに構築されていました。クラウドネイティブアプリケーションは頻繁に変わり、多数のオープンソースツールやライブラリを使用し、多くの場合ベンダーが管理するインフラストラクチャーで実行され、急速なインフラストラクチャーの変更に影響を受けることがあります。コードレビューや長い品質保証サイクル、ホストベースの脆弱性スキャン、直前のセキュリティレビューは、クラウドネイティブアプリケーションに対応することはできません。 +従来のセキュリティモデルは、もはや有効でない多くの前提のもとに構築されていました。 +クラウドネイティブアプリケーションは頻繁に変わり、多数のオープンソースツールやライブラリを使用し、多くの場合ベンダーが管理するインフラストラクチャで実行され、急速なインフラストラクチャの変更に影響を受けることがあります。 +コードレビューや長い品質保証サイクル、ホストベースの脆弱性スキャン、直前のセキュリティレビューは、クラウドネイティブアプリケーションに対応することはできません。 ## どのように役に立つのでしょうか -クラウドネイティブセキュリティは、従来のセキュリティモデルから、リリースサイクルのすべての段階でセキュリティが関与するモデルへと移行することにより、アプリケーションを保護する新しい方法を導入します。手作業による監査と監視は、大部分が自動スキャンに取って代わられます。迅速なコードリリースパイプラインは、コンパイル前にコードの脆弱性をスキャンするツールと統合されます。オープンソースライブラリは、信頼できるソースから取得され脆弱性がないか監視されています。 -クラウドネイティブセキュリティモデルは、緩やかな変化ではなく、脆弱性のあるコンポーネントを頻繁に更新したり、インフラストラクチャーを定期的に交換したりすることを受け入れます。 +クラウドネイティブセキュリティは、従来のセキュリティモデルから、リリースサイクルのすべての段階でセキュリティが関与するモデルへと移行することにより、アプリケーションを保護する新しい方法を導入します。 +手作業による監査と監視は、大部分が自動スキャンに取って代わられます。 +迅速なコードリリースパイプラインは、コンパイル前にコードの脆弱性をスキャンするツールと統合されます。 +オープンソースライブラリは、信頼できるソースから取得され脆弱性がないか監視されています。 +クラウドネイティブセキュリティモデルは、緩やかな変化ではなく、脆弱性のあるコンポーネントを頻繁に更新したり、インフラストラクチャを定期的に交換したりすることを受け入れます。 diff --git a/content/ja/cloud-native-tech.md b/content/ja/cloud-native-tech.md index 51117e1d53..7218bb5064 100644 --- a/content/ja/cloud-native-tech.md +++ b/content/ja/cloud-native-tech.md @@ -5,14 +5,19 @@ category: コンセプト tags: ["基礎", "", ""] --- -クラウドネイティブテクノロジーは、クラウドネイティブスタックとも呼ばれ、[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)を構築するために使用される技術です。これらの技術により、組織がスケーラブルなアプリケーションを、パブリックやプライベート、ハイブリッドクラウドのようなモダンでダイナミックな環境で、[クラウドコンピューティング](/ja/cloud-computing/)の利点を最大限に活用しながら、構築や実行することができます。コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャーなど、クラウドコンピューティングの機能を活用するために1から設計されたアプローチです。 +クラウドネイティブテクノロジーは、クラウドネイティブスタックとも呼ばれ、[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)を構築するために使用される技術です。 +これらの技術により、組織がスケーラブルなアプリケーションを、パブリックやプライベート、ハイブリッドクラウドのようなモダンでダイナミックな環境で、[クラウドコンピューティング](/ja/cloud-computing/)の利点を最大限に活用しながら、構築や実行することができます。 +コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャなど、クラウドコンピューティングの機能を活用するために1から設計されたアプローチです。 ## 解決すべき問題はなんですか クラウドネイティブスタックには多くの異なる技術カテゴリーがあり、様々な課題に対応しています。 [CNCFクラウドネイティブランドスケープ](https://landscape.cncf.io/)を見ると、いかに多くの異なる領域に触れているかわかると思います。 -しかし高いレベルでは、主に従来のIT運用モデルのマイナス面に取り組んでいます。含まれる課題としては、拡張性がありフォールトトレラントな自己修復型アプリケーションの実現が困難であること、リソースの活用が非効率であることなどが挙げられます。 +しかし高いレベルでは、主に従来のIT運用モデルのマイナス面に取り組んでいます。 +含まれる課題としては、拡張性がありフォールトトレラントな自己修復型アプリケーションの実現が困難であること、リソースの活用が非効率であることなどが挙げられます。 ## どのように役に立つのでしょうか -それぞれの技術は特定の問題に対応していますが、全体として、クラウドネイティブテクノロジーは弾力性があり管理可能で観測可能な疎結合のシステムを実現します。堅牢な自動化と組み合わせることで、エンジニアは最小限の労力で影響力の大きい変更を頻繁にかつ予測通りに行うことができます。クラウドネイティブシステムの望ましい特性は、クラウドネイティブスタックで実現することが容易になりました。 +それぞれの技術は特定の問題に対応していますが、全体として、クラウドネイティブテクノロジーは弾力性があり管理可能で観測可能な疎結合のシステムを実現します。 +堅牢な自動化と組み合わせることで、エンジニアは最小限の労力で影響力の大きい変更を頻繁にかつ予測通りに行うことができます。 +クラウドネイティブシステムの望ましい特性は、クラウドネイティブスタックで実現することが容易になりました。 diff --git a/content/ja/cluster.md b/content/ja/cluster.md index c29169cc34..4d3e73051f 100644 --- a/content/ja/cluster.md +++ b/content/ja/cluster.md @@ -2,7 +2,7 @@ title: クラスター status: Completed category: コンセプト -tags: ["インフラストラクチャー", "基礎", ""] +tags: ["インフラストラクチャ", "基礎", ""] --- クラスターは、共通の目的に向けて連携して働くコンピューターやアプリケーションのグループです。 diff --git a/content/ja/container-orchestration.md b/content/ja/container-orchestration.md index 1f57583916..635bb40629 100644 --- a/content/ja/container-orchestration.md +++ b/content/ja/container-orchestration.md @@ -4,15 +4,14 @@ status: Completed category: コンセプト --- -[コンテナ](/ja/container/)オーケストレーションとは、流動的な環境において、[コンテナ化](/ja/containerization)されたアプリケーションのライフサイクルを管理し自動化することを指します。 -これはコンテナオーケストレータ(ほとんどの場合は[Kubernetes](/ja/kubernetes))を通じて実行され、デプロイメント、(自動)スケーリング、自動ヒーリング、モニタリングが可能になります。 +[コンテナ](/ja/container/)オーケストレーションとは、流動的な環境において、[コンテナ化](/ja/containerization/)されたアプリケーションのライフサイクルを管理し自動化することを指します。 +これはコンテナオーケストレータ(ほとんどの場合は[Kubernetes](/ja/kubernetes/))を通じて実行され、デプロイメント、(自動)スケーリング、自動ヒーリング、モニタリングが可能になります。 オーケストレーションという言葉は比喩です。 オーケストレーションツールは、音楽指揮者のようにコンテナを指揮し、すべてのコンテナ(または音楽家)が適切に機能するようにします。 ## 解決すべき問題は何ですか -スケールに応じて[マイクロサービス](/ja/microservices-architecture)、セキュリティ、ネットワーク通信や一般的な[分散システム](/ja/distributed-systems)を管理することは、 -手動で行うには難しく、場合によっては不可能です。 +スケールに応じて[マイクロサービス](/ja/microservices-architecture/)、セキュリティ、ネットワーク通信や一般的な[分散システム](/ja/distributed-systems/)を管理することは、手動で行うには難しく、場合によっては不可能です。 コンテナオーケストレーションにより、これらすべての管理タスクを自動化することができます。 ## どのように役に立つのでしょうか diff --git a/content/ja/container.md b/content/ja/container.md index 3944bd392e..23dbe0a35e 100644 --- a/content/ja/container.md +++ b/content/ja/container.md @@ -7,8 +7,7 @@ tags: ["アプリケーション", "基礎", ""] コンテナは、コンピューターのオペレーティングシステムがリソースと機能面での制限を管理する、実行中のプロセスです。 コンテナプロセスで利用可能なファイルは、コンテナイメージとしてパッケージ化されています。 -コンテナは一つのマシン上で同時に実行されますが、 -通常オペレーティングシステムは別々のコンテナプロセスが互いに干渉するのを防ぎます。 +コンテナは一つのマシン上で同時に実行されますが、通常オペレーティングシステムは別々のコンテナプロセスが互いに干渉するのを防ぎます。 ## 解決すべき問題は何ですか @@ -19,8 +18,7 @@ tags: ["アプリケーション", "基礎", ""] ## どのように役に立つのでしょうか -コンテナはオペレーティングシステムとそのマシンリソースを共有し、 -オペレーティングシステムのリソースオーバーヘッドを分散させ、物理マシンを効率的に使用します。 +コンテナはオペレーティングシステムとそのマシンリソースを共有し、オペレーティングシステムのリソースオーバーヘッドを分散させ、物理マシンを効率的に使用します。 これは通常コンテナが互いに干渉することが制限されているため、実現できます。 これにより、同じ物理マシン上で多くのアプリケーションを実行することができます。 diff --git a/content/ja/containerization.md b/content/ja/containerization.md index 0433f35742..f0cb04366a 100644 --- a/content/ja/containerization.md +++ b/content/ja/containerization.md @@ -11,8 +11,7 @@ tags: ["アプリケーション", "", ""] ## 解決すべき問題は何ですか -[コンテナ](/ja/container)が普及する前は、組織は仮想マシン(VM)に依存して、 -単一の[ベアメタルマシン](/ja/bare-metal-machine/)上で複数のアプリケーションをオーケストレーションしていました。 +[コンテナ](/ja/container/)が普及する前は、組織は仮想マシン(VM)に依存して、単一の[ベアメタルマシン](/ja/bare-metal-machine/)上で複数のアプリケーションをオーケストレーションしていました。 VMはコンテナよりも非常に大きく、実行にはハイパーバイザーが必要です。 これらの大きなVMテンプレートのストレージ、バックアップ、転送により、VMテンプレートの作成もより遅くなります。 さらに、VMは[不変性](/ja/immutable-infrastructure/)の原則に反する構成ドリフトに悩まされることがあります。 @@ -22,8 +21,6 @@ VMはコンテナよりも非常に大きく、実行にはハイパーバイザ コンテナイメージは(従来のVMとは異なり)軽量です。 またコンテナ化のプロセスには依存関係のリストが記載されたファイルが必要です。 このファイルはバージョン管理が可能で、ビルドプロセスを自動化できます。 -これにより組織は他の優先事項に集中でき、 -自動化されたプロセスがビルドを担当します。 +これにより組織は他の優先事項に集中でき、自動化されたプロセスがビルドを担当します。 コンテナイメージは、その厳密な内容と設定に関連付けられた一意の識別子によって保存されます。 -コンテナがスケジュールされ再スケジュールされると、 -常に初期状態にリセットされるため、構成ドリフトが解消されます。 +コンテナがスケジュールされ再スケジュールされると、常に初期状態にリセットされるため、構成ドリフトが解消されます。 diff --git a/content/ja/continuous-delivery.md b/content/ja/continuous-delivery.md index f2599c8df6..00739d034b 100644 --- a/content/ja/continuous-delivery.md +++ b/content/ja/continuous-delivery.md @@ -5,26 +5,20 @@ category: コンセプト tags: ["方法論", "アプリケーション", ""] --- -継続的デリバリー(しばしばCDと略される)は、 -コードの変更が自動的に受け入れ環境にデプロイされる -(または継続的デプロイメントの場合、本番環境にデプロイされる)一連の実践を指します。 -CDは、ソフトウェアがデプロイメント前に適切にテストされていることを保証する手順を重要視し、 -必要と判断された場合に変更をロールバックする方法を提供します。 -[継続的インテグレーション(CI)](/ja/continuous-integration/)は継続的デリバリーに向けた最初のステップです -(つまり、テストやデプロイがされる前に、変更がうまく統合されなければなりません。) +継続的デリバリー(しばしばCDと略される)は、コードの変更が自動的に受け入れ環境にデプロイされる(または継続的デプロイメントの場合、本番環境にデプロイされる)一連の実践を指します。 +CDは、ソフトウェアがデプロイメント前に適切にテストされていることを保証する手順を重要視し、必要と判断された場合に変更をロールバックする方法を提供します。 +[継続的インテグレーション(CI)](/ja/continuous-integration/)は継続的デリバリーに向けた最初のステップです(つまり、テストやデプロイがされる前に、変更がうまく統合されなければなりません。) ## 解決すべき問題は何ですか 大規模な環境では、[信頼性](/ja/reliability/)の高いアップデートのデプロイが問題となります。 理想的には、エンドユーザーにより良い価値を提供するために、頻繁にデプロイを行いたいところです。 しかし、それを手動で行うと変更ごとに高いトランザクションコストが発生します。 -歴史的に、これらのコストを避けるために、組織は頻繁にリリースを行わず、 -一度に多くの変更をデプロイしてきましたが、これにより何かが間違ってしまうリスクが高まります。 +歴史的に、これらのコストを避けるために、組織は頻繁にリリースを行わず、一度に多くの変更をデプロイしてきましたが、これにより何かが間違ってしまうリスクが高まります。 ## どのように役に立つのでしょうか -CD戦略は、完全に自動化された本番環境へのパスを作成し、 -[カナリア](/ja/canary-deployment/)や[ブルーグリーン](/ja/blue-green-deployment/)リリースなどの様々なデプロイメント戦略を使用してソフトウェアをテストしデプロイします。 +CD戦略は、完全に自動化された本番環境へのパスを作成し、[カナリア](/ja/canary-deployment/)や[ブルーグリーン](/ja/blue-green-deployment/)リリースなどの様々なデプロイメント戦略を使用してソフトウェアをテストしデプロイします。 これにより、開発者は頻繁にコードをデプロイすることができ、新しいリビジョンがテストされていることを安心して受け入れることができます。 ## 関連する用語はありますか diff --git a/content/ja/continuous-deployment.md b/content/ja/continuous-deployment.md index 59847ba78a..4f80dc48ea 100644 --- a/content/ja/continuous-deployment.md +++ b/content/ja/continuous-deployment.md @@ -5,24 +5,19 @@ category: コンセプト tags: ["アプリケーション", "方法論", ""] --- -継続的デプロイメント(しばしばCDと略される)は、 -完成したソフトウェアを直接本番環境にデプロイするという点で[継続的デリバリー](/ja/continuous-delivery/)より一歩進んでいます。 +継続的デプロイメント(しばしばCDと略される)は、完成したソフトウェアを直接本番環境にデプロイするという点で[継続的デリバリー](/ja/continuous-delivery/)より一歩進んでいます。 継続的デプロイメント(CD)は[継続的インテグレーション](/ja/continuous-integration/)(CI)と密接に関連しており、しばしばCI/CDと呼ばれます。 -CIプロセスは特定のアプリケーションへの変更が有効であるかどうかをテストし、 -CDプロセスはコードの変更を自動的に組織のテスト環境や本番環境にデプロイします。 +CIプロセスは特定のアプリケーションへの変更が有効であるかどうかをテストし、CDプロセスはコードの変更を自動的に組織のテスト環境や本番環境にデプロイします。 ## 解決すべき問題はなんですか 新しいソフトウェアバージョンのリリースは、労力がかかりエラーが発生しやすいプロセスです。 -また本番環境でのインシデントを避け、エンジニアが通常の業務時間外に対応する時間を減らすため、 -組織が頻繁に行わないことも多いです -伝統的なソフトウェアデプロイメントモデルでは、 -ソフトウェアのリリースプロセスが組織の安定性と機能の速度の両方に関するニーズを満たせず、組織を悪循環に陥らせます。 +また本番環境でのインシデントを避け、エンジニアが通常の業務時間外に対応する時間を減らすため、組織が頻繁に行わないことも多いです。 +伝統的なソフトウェアデプロイメントモデルでは、ソフトウェアのリリースプロセスが組織の安定性と機能の速度の両方に関するニーズを満たせず、組織を悪循環に陥らせます。 ## どのように役に立つのでしょうか -リリースサイクルを自動化し、組織が頻繁に本番環境へのリリースを強制することにより、 -CDは運用チームに対して、CIが開発チームにもたらした効果を実現します。 +リリースサイクルを自動化し、組織が頻繁に本番環境へのリリースを強制することにより、CDは運用チームに対して、CIが開発チームにもたらした効果を実現します。 具体的には、運用チームが本番へのデプロイメントの際に煩雑でエラーが発生しやすい部分を自動化するように促し、全体的なリスクを減少させます。 また組織が本番環境の変更を受け入れ、適応する能力を向上させ、より高い安定性につながります。 diff --git a/content/ja/continuous-integration.md b/content/ja/continuous-integration.md index c4c048d74a..82e0bdf563 100644 --- a/content/ja/continuous-integration.md +++ b/content/ja/continuous-integration.md @@ -7,16 +7,13 @@ tags: ["アプリケーション", "方法論", ""] 継続的インテグレーション(CI)とは、コードの変更を可能な限り定期的に統合することを指します。 CIは[継続的デリバリー](/ja/continuous-delivery/)(CD)の前提条件です。 -伝統的に、CIのプロセスはバージョンコントロールシステム(GitやMercurial、あるいはSubversion)にコードの変更がコミットされることで開始し、 -CDシステムで利用できるようになったテスト済みの成果物で終了します。 +伝統的に、CIのプロセスはバージョンコントロールシステム(GitやMercurial、あるいはSubversion)にコードの変更がコミットされることで開始し、CDシステムで利用できるようになったテスト済みの成果物で終了します。 ## 解決すべき問題はなんですか ソフトウェアシステムはしばしば大規模で複雑であり、多くの開発者が維持や更新をしています。 -システムの異なる部分で並行して作業を行う開発者たちは、 -意図せずに互いの作業を壊すような矛盾した変更を加えることがあります。 -さらに、同じプロジェクトに複数の開発者が取り組む場合、 -テストやコード品質の計測といった日常的なタスクは、各開発者によって繰り返される必要があり、時間の無駄になります。 +システムの異なる部分で並行して作業を行う開発者たちは、意図せずに互いの作業を壊すような矛盾した変更を加えることがあります。 +さらに、同じプロジェクトに複数の開発者が取り組む場合、テストやコード品質の計測といった日常的なタスクは、各開発者によって繰り返される必要があり、時間の無駄になります。 ## どのように役に立つのでしょうか diff --git a/content/ja/data-center.md b/content/ja/data-center.md new file mode 100644 index 0000000000..70c83ad330 --- /dev/null +++ b/content/ja/data-center.md @@ -0,0 +1,25 @@ +--- +title: データセンター +status: Completed +category: テクノロジー +tags: ["インフラストラクチャ", "基礎", ""] +--- + +データセンターはコンピューター(その多くはサーバー)を収容するために設計された特別な建物または施設です。 +これらのデータセンターが[クラウドコンピューティング](/ja/cloud-computing/)に重点を置いている場合、高速なインターネット回線に接続される傾向があります。 +データセンターが入っている建物には、停電時に電力を供給する発電機や、発熱するコンピューターを冷却する強力な空調機など、停電が発生した場合でもサービスを維持できる設備が備えられています。 + +## 解決すべき問題は何ですか + +1990年代後半にデータセンターが普及するまでは、主に特定の業務プロセスを実行するための専用のコンピューターであり、または個人が作業を行うためにコンピューターが使用されていました。 +ただし、コンピューターのリソース(ハードディスク、メモリ、CPU)は限られているため、その上で実行されるアプリケーションには厳しい制約があり、実行できるアプリケーションの種類が制限されます。 +データセンターが普及する前は、アプリケーションの規模が実行されているコンピューターの容量によって制限されていました。 +しかし、GmailやNetflixのような大規模なアプリケーション(携帯電話やコンピューターのユーザーインターフェースではなくサーバーサイドアプリ)について考えてみると、1 台のコンピューターが提供できる能力よりも多くのコンピューティング能力が必要になります。 +そこでデータセンターが登場します。 + +## どのように役に立つのでしょうか + +ユーザーはさまざまなサーバーに接続することで、「スーパーコンピューター」のように機能する[分散システム](/ja/distributed-systems/)を構築できます。 +複数のマシンの能力を統合しているため、より大規模なサーバーサイドアプリや業務プロセスを実行したり、より強力な計算タスクを処理したりできるようになりました。 +私たちが日常的に使用するほとんどのアプリケーションがデータセンターで実行されています。 +[パブリッククラウド](/ja/cloud-computing/)はクライアントにコンピューターリソースを貸し出すデータセンターです。ここ数年、企業所有のデータセンターからパブリッククラウドへ移行している事例が多数あります。 diff --git a/content/ja/devops.md b/content/ja/devops.md index e497556f50..fb9c6d9ccc 100644 --- a/content/ja/devops.md +++ b/content/ja/devops.md @@ -11,21 +11,16 @@ DevOpsは、(全体の機能ではなく)小さなコンポーネントに取り ## 解決すべき問題はなんですか -従来、[密結合な](/ja/tightly-coupled-architectures/)[モノリシックアプリ](/ja/monolithic-apps/)を持つ複雑な組織では、 -通常、作業は複数のグループ間で断片化されていました。 +従来、[密結合な](/ja/tightly-coupled-architecture/)[モノリシックアプリ](/ja/monolithic-apps/)を持つ複雑な組織では、通常、作業は複数のグループ間で断片化されていました。 これにより多くの引き渡しと長いリードタイムが発生しました。 コンポーネントやアップデートが準備できるたびに、それは次のチームのキューに置かれました。 個々の担当者はプロジェクトの一部分のみを扱うため、このアプローチは所有権の欠如につながりました。 彼らの目標は、作業を次のグループに渡すことであり、顧客に適切な機能を提供することではありませんでした。 これは明らかな優先順位のずれです。 -コードが最終的に本番環境に入る頃には、多くの開発者を経由し、多くのキューで待機していたため、 -コードが動作しない場合の問題の原因を追跡するのが難しくなりました。 +コードが最終的に本番環境に入る頃には、多くの開発者を経由し、多くのキューで待機していたため、コードが動作しない場合の問題の原因を追跡するのが難しくなりました。 DevOpsはこのアプローチを根本から覆します。 ## どのように役に立つのでしょうか -アプリケーションの全ライフサイクルを一つのチームが担当することで、 -引き渡しを最小限に抑え、本番環境へデプロイする際のリスクを減少させ、 -チームが本番環境でのコードのパフォーマンスにも責任を持つことでコード品質が向上し、 -より多くの自律性と所有権により従業員の満足度も高まります。 +アプリケーションの全ライフサイクルを一つのチームが担当することで、引き渡しを最小限に抑え、本番環境へデプロイする際のリスクを減少させ、チームが本番環境でのコードのパフォーマンスにも責任を持つことでコード品質が向上し、より多くの自律性と所有権により従業員の満足度も高まります。 diff --git a/content/ja/devsecops.md b/content/ja/devsecops.md new file mode 100644 index 0000000000..9e7b259e54 --- /dev/null +++ b/content/ja/devsecops.md @@ -0,0 +1,23 @@ +--- +title: DevSecOps +status: Completed +category: コンセプト +tags: ["方法論", "セキュリティ", ""] +--- + +DevSecOpsという用語は、開発、運用、およびセキュリティの責任の文化的統合を指します。 +これは、開発と運用のワークフローを最小限に乱すことなく、セキュリティの優先順位を含むように[DevOps](/ja/devops/)アプローチを拡張します。 +DevOpsと同様に、DevSecOpsは採用された技術によって推進される文化的変革であり、独自の適用方法があります。 + +## 解決すべき問題はなんですか + +DevOpsの実践には、[継続的インテグレーション](/ja/continuous-integration/)、[継続的デリバリー](/ja/continuous-delivery/)、および[継続的デプロイメント](/ja/continuous-deployment/)が含まれ、アプリケーションの開発とリリースサイクルを加速します。 +残念ながら、自動化されたリリースプロセスが組織のすべてのステークホルダーを適切に表現できない場合には、既存の問題を悪化させる可能性があります。 +セキュリティのニーズを考慮せずに構築された新しいソフトウェアを迅速にリリースするプロセスは、組織のセキュリティ態勢を低下させる可能性があります。 + +## どのように役に立つのでしょうか + +DevSecOpsは、チームのサイロを壊し、安全な自動化されたワークフローの作成を促進することに焦点を当てています。 +セキュリティアプリケーションを選択する際、組織は開発者を支援する自動化されたCI/CDワークフローとポリシーの施行を活用する必要があります。 +障害物になることではなく、セキュリティポリシーを施行しつつ、ユーザーにプロジェクトを前進させる方法に関する正確な情報を提供することが目標です。 +適切に実装された場合、組織はより良いチームコミュニケーションを得て、セキュリティ事故と関連コストを減らすことができます。 diff --git a/content/ja/distributed-apps.md b/content/ja/distributed-apps.md index 5fab30e604..5205b2199b 100644 --- a/content/ja/distributed-apps.md +++ b/content/ja/distributed-apps.md @@ -11,8 +11,8 @@ tags: ["アーキテクチャ", "", ""] ## 解決すべき問題はなんですか -単一のコンピュータ上で動作している単一のアプリケーションは単一障害点となります。 -もしそのコンピュータが故障した場合、そのアプリケーションは利用できなくなります。 +単一のコンピューター上で動作している単一のアプリケーションは単一障害点となります。 +もしそのコンピューターが故障した場合、そのアプリケーションは利用できなくなります。 分散アプリケーションは、しばしば[モノリシックアプリケーション](/ja/monolithic-apps/)と比較されます。 モノリシックアプリケーションは、様々なコンポーネントが独立してスケールできないために、スケールが難しい場合があります。 さらに、それらは成長するにつれて開発者の速度の妨げになることもあります。 diff --git a/content/ja/distributed-systems.md b/content/ja/distributed-systems.md new file mode 100644 index 0000000000..77fc176b62 --- /dev/null +++ b/content/ja/distributed-systems.md @@ -0,0 +1,30 @@ +--- +title: 分散システム +status: Completed +category: コンセプト +tags: ["アーキテクチャ", "", ""] +--- + +分散システムは、ネットワーク上で接続された自立型のコンピューティング要素の集合であり、ユーザーから見ると1つの統一されたシステムとして見えます。 +一般的には[ノード](/ja/nodes/)と言われるこれらの要素は、ハードウェアデバイス(例: コンピューターや携帯電話)やソフトウェアのプロセスです。 +ノードは共通の目標を達成するためにプログラムされており、連携するためにネットワーク上でメッセージを交換します。 + +## 解決すべき問題はなんですか + +現代の多くのアプリケーションは、運用するのにスーパーコンピューターが必要になるほど大規模です。 +GmailやNetflixを考えてみて下さい。 +単一のコンピューターでは、アプリケーション全体を提供するのに十分な性能がありません。 +複数のコンピューターを接続することで、計算能力はほとんど無制限になります。 +分散コンピューティングなしでは、今日、我々が頼りにしている多くのアプリケーションは実現できないでしょう。 + +従来、システムは垂直に[スケール](/ja/scalability/)するものでした。 +これは、個々のマシンにCPUやメモリを追加するときのことを指します。 +垂直スケーリングには時間がかかり、ダウンタイムを必要とし、また、すぐに限界に達します。 + +## どのように役に立つのでしょうか + +分散システムは[水平スケーリング](/ja/horizontal-scaling/)(例えば、必要に応じてシステムにノードを追加すること)を可能にします。 +これは自動化できるため、システムは急激なワークロードやリソース消費の増加に対応できるようになります。 + +分散システムでないシステムは、1台のマシンが故障するとシステム全体が故障するというリスクにさらされます。 +分散システムは、いくつかのマシンがダウンしたとしても、システム全体としては同じ結果を返し続けるように設計することができます。 diff --git a/content/ja/ebpf.md b/content/ja/ebpf.md index 15ee85a515..402b3fef11 100644 --- a/content/ja/ebpf.md +++ b/content/ja/ebpf.md @@ -16,9 +16,10 @@ Linuxシステムには2種類の空間があります。カーネル空間と しかしこのアプローチはセキュリティリスクももたらすため、eBPFが魅力的な代替となります。 ## 解決すべき問題はなんですか + 一般的に、アプリケーションはユーザー空間で動作し、アプリケーションがカーネルから(例えばハードウェアへのアクセスなどの)権限を要求するときは、いわゆる「システムコール」を介して要求します。 多くの場合、このアプローチはうまく働きますが、低水準なシステムに対するより柔軟なアクセスを開発者が必要とする場合があります。 -可観測性、セキュリティやネットワーク機能はこういった場合の良い例です。 +オブザーバビリティ、セキュリティやネットワーク機能はこういった場合の良い例です。 この実現のため、Linuxカーネルモジュールを使ってカーネルのソースコードを修正することなくカーネルの基礎を拡張することができます。 Linuxカーネルモジュールの使用には利点もありますが、セキュリティリスクももたらします。 Linuxカーネルモジュールはカーネル空間の内部で動作するため、カーネルをクラッシュさせる可能性があり、カーネルがクラッシュするということは機器全体もクラッシュすることになります。 @@ -26,6 +27,7 @@ Linuxカーネルモジュールはカーネル空間の内部で動作するた もし適切に保護されていない場合、攻撃者は攻撃のためカーネルモジュールを悪用できてしまいます。 ## どのように役に立つのでしょうか + eBPFはユーザー定義プログラムの実行環境として、Linuxカーネルモジュールよりも制御、制限された環境を提供します。 eBPFプログラムはカーネル内のサンドボックス化された環境で動作することで、隔離を提供しリスクを低減します。 もしeBPFプログラム中の脆弱性や欠陥が悪用されたとしても、一般的にその影響はサンドボックス化された環境に抑えられます。 diff --git a/content/ja/event-driven-architecture.md b/content/ja/event-driven-architecture.md new file mode 100644 index 0000000000..b09a86f164 --- /dev/null +++ b/content/ja/event-driven-architecture.md @@ -0,0 +1,24 @@ +--- +title: イベント駆動アーキテクチャ +status: Completed +category: コンセプト +tags: ["アーキテクチャ", "", ""] +--- + +イベント駆動アーキテクチャは、イベントの作成、処理、および消費を促進するソフトウェアアーキテクチャです。 +イベントとは、アプリケーションの状態に対する任意の変更を指します。 +例えば、ライドシェアリングアプリで乗車を依頼することは、イベントを代表しています。 +このアーキテクチャは、イベントがそのソース(乗車を要求するアプリ)から望ましいレシーバー(近くの利用可能なドライバーのアプリ)へ適切にルーティングされる構造を作り出します。 + +## 解決すべき問題はなんですか + +より多くのデータがリアルタイムになるにつれて、イベントがキャプチャされ、イベントリクエストを処理する必要がある適切な[サービス](/ja/service/)へ正確にルーティングされる信頼性の高い方法を見つけることがますます困難になります。 +イベントを処理する従来の方法は、メッセージが適切にルーティングされたか、あるいは実際に送信または受信されたかを保証する方法がないことがしばしばあります。 +アプリケーションがスケールするにつれて、イベントをオーケストレーションすることがより困難になります。 + +## どのように役に立つのでしょうか + +イベント駆動アーキテクチャは、すべてのイベントのためのセントラルハブ(例えばKafka)を確立します。 +次に、イベントプロデューサー(ソース)とコンシューマー(レシーバー)を定義し、セントラルハブがイベントの流れを保証します。 +このアーキテクチャは、サービス同士が疎結合のまま、イベントがプロデューサーからコンシューマーに適切にルーティングされることを保証します。 +プロデューサーは、通常はHTTPプロトコルによって受信イベントを取り、イベント情報をルーティングします。 diff --git a/content/ja/event-streaming.md b/content/ja/event-streaming.md new file mode 100644 index 0000000000..32fb7334ee --- /dev/null +++ b/content/ja/event-streaming.md @@ -0,0 +1,30 @@ +--- +title: イベントストリーミング +status: Completed +category: コンセプト +tags: ["方法論", "ネットワーキング", ""] +--- + +イベントストリーミングは、ソフトウェアが一つのアプリケーションから別のアプリケーションにイベントデータを送信し、何をしているかを継続的に通信するアプローチです。 +あるサービスが行うすべてのことを他のすべてのサービスにブロードキャストする様子を想像してください。 +サービスによって行われる各活動はイベントと呼ばれ、これがイベントストリーミングの由来です。 +たとえば、NASDAQは毎秒、株価と商品価格の更新を受け取ります。 +特定の株式セットを監視するアプリケーションを動かすとしたら、その情報をほぼリアルタイムで受け取りたいでしょう。 +Yahoo! Financeは、NASDAQから引っ張ってきたデータを引用し、その情報(またはイベント)を購読するアプリケーションに送信(またはストリーム)する[API](/ja/application-programming-interface/)を提供しています。 +送信されるデータおよびそのデータ(株価)の変化がイベントであり、それらをアプリケーションに配信するプロセスがイベントストリーミングです。 + +## 解決すべき問題はなんですか + +従来、Yahoo! Financeは単一のTCPリクエストを使用していました。 +これは、イベントごとに接続を確立する必要があるため、非常に非効率的です。 +データがよりリアルタイム性を帯びるにつれて、そのような解決策をスケーリングすることは非効率的になります。 +接続を一度開いてイベントが流れるようにすることは、リアルタイム収集として理想的です。 +生成されるデータの量は指数関数的に増加しており、それに伴いデータの状態は絶えず変動しています。 +開発者とユーザーは、そのデータをほぼリアルタイムで見ることができる必要があります。 + +## どのように役に立つのでしょうか + +イベントストリーミングにより、データの変更をソースから受信者に通信できます。 +情報を要求するためにサービスが待つ代わりに、サービスはそのすべてのイベント(または活動)を継続的にストリームします。 +情報がどうなるかについては関心を持ちません。 +必要なことを行い、それをブロードキャストするだけで、他のどのサービスとも完全に独立しています。 diff --git a/content/ja/function-as-a-service.md b/content/ja/function-as-a-service.md index 57f2b664b7..5d0445e655 100644 --- a/content/ja/function-as-a-service.md +++ b/content/ja/function-as-a-service.md @@ -2,14 +2,11 @@ title: Function as a Service (FaaS) status: Completed category: テクノロジー -tags: ["インフラストラクチャー", "", ""] +tags: ["インフラストラクチャ", "", ""] --- -Function as a Service (FaaS)は、 -[サーバーレス](/ja/serverless/)、[クラウドコンピューティング](/ja/cloud-computing/)、[サービス](/ja/service/)の一種であり、 -イベントによってコードを実行することを可能にします。 -これは通常、[マイクロサービス](/ja/microservices-architecture/)アプリケーションの構築や立ち上げに関連する、 -複雑なインフラストラクチャーのメンテナンスを必要としません。 +Function as a Service (FaaS)は、[サーバーレス](/ja/serverless/)、[クラウドコンピューティング](/ja/cloud-computing/)、[サービス](/ja/service/)の一種であり、イベントによってコードを実行することを可能にします。 +これは通常、[マイクロサービス](/ja/microservices-architecture/)アプリケーションの構築や立ち上げに関連する、複雑なインフラストラクチャのメンテナンスを必要としません。 FaaSを使用すると、ユーザーは関数とデータのみを管理し、クラウドプロバイダーがアプリケーションを管理します。 これにより、開発者はコードが実行されていないときにサービスの費用を支払うことなく、必要な機能を得ることができます。 @@ -19,8 +16,7 @@ FaaSを使用すると、ユーザーは関数とデータのみを管理し、 企業はサーバー、ストレージ、ソフトウェア、その他の技術に投資し、ITスタッフや請負業者を雇ってすべての機器やライセンスの購入、管理、更新を行う必要があります。 データセンターは、作業負荷が減少しリソースがアイドリング状態の時期があるにも関わらず、ピーク需要に対応できるように建設されなければなりません。 逆にビジネスが急速に成長する場合、IT部門は追いつくのに苦労するかもしれません。 -標準的な[Infrastructure-as-a-Service (IaaS)](/ja/infrastructure-as-a-service/)クラウドコンピューティングモデルでは、 -ユーザーは事前に容量ユニットを購入します。 +標準的な[Infrastructure-as-a-Service (IaaS)](/ja/infrastructure-as-a-service/)クラウドコンピューティングモデルでは、ユーザーは事前に容量ユニットを購入します。 つまりアプリを実行するために、サーバーコンポーネントを常時起動させ、それに対する支払いをパブリッククラウドプロバイダーに行います。 需要が高まる時にサーバー容量を増やし、その容量が不要になった時に減らすのはユーザーの責任です。 アプリが使用されていないときでも、そのアプリを実行するためのクラウドインフラは稼働しています。 @@ -29,6 +25,5 @@ FaaSを使用すると、ユーザーは関数とデータのみを管理し、 FaaSはサーバーを管理することなく、イベントに応じてウェブアプリケーションを実行するための[抽象化](/ja/abstraction/)を開発者に提供します。 例えば、ファイルのアップロードがそのファイルを様々な形式にトランスコードするカスタムコードのトリガーとなるかもしれません。 -FaaSのインフラストラクチャーは、頻繁に使用するコードを自動的にスケールアップし、 -開発者は[スケーラビリティ](/ja/scalability/)のためのコード構築に時間やリソースを費やす必要がありません。 +FaaSのインフラストラクチャは、頻繁に使用するコードを自動的にスケールアップし、開発者は[スケーラビリティ](/ja/scalability/)のためのコード構築に時間やリソースを費やす必要がありません。 課金は計算時間のみに基づいているため、機能が使用されていない時には企業は支払いをする必要がありません。 diff --git a/content/ja/horizontal-scaling.md b/content/ja/horizontal-scaling.md index 5ae37a225a..8c028c0aba 100644 --- a/content/ja/horizontal-scaling.md +++ b/content/ja/horizontal-scaling.md @@ -2,20 +2,20 @@ title: 水平スケーリング status: Completed category: コンセプト -tags: ["インフラストラクチャー", "", ""] +tags: ["インフラストラクチャ", "", ""] --- -水平スケーリングは、より多くのノードを追加することでシステムの処理能力を向上させる手法です。個別の[ノード](/ja/nodes/)により多くの計算リソースを追加する手法とは異なります(後者は[垂直スケーリング](/ja/vertical-scaling/)として知られています)。 +水平スケーリングは、より多くのノードを追加することでシステムの処理能力を向上させる手法です。 +個別の[ノード](/ja/nodes/)により多くの計算リソースを追加する手法とは異なります(後者は[垂直スケーリング](/ja/vertical-scaling/)として知られています)。 たとえば、RAM容量4GBのシステムを持っていて、そのRAMを16GBに増やしたい場合、水平スケーリングはRAM 16GBのシステムに切り替えるのではなく、RAM 4GBのマシン4台で対応します。 -このアプローチは、新しいインスタンスまたは[ノード](/ja/nodes)を追加することで、負荷をより効果的に分散し、アプリケーションのパフォーマンスを向上させます。 +このアプローチは、新しいインスタンスまたは[ノード](/ja/nodes/)を追加することで、負荷をより効果的に分散し、アプリケーションのパフォーマンスを向上させます。 簡単に言えば、個別のサーバーの処理能力を強化することではなく、個別のサーバーの負荷を減らすことを目指しています。 ## 解決すべき問題はなんですか アプリケーションに対する需要がそのアプリケーションインスタンスの現在の処理能力を超えた場合、システムに処理能力を[スケール](/ja/scalability/)する(処理能力を向上させる)方法が必要になります。 - システムにノードを追加する(水平スケーリング)か、既存のノードにより多くの計算リソースを追加する(垂直スケーリング)かのいずれかが可能です。 ## どのように役に立つのでしょうか diff --git a/content/ja/idempotence.md b/content/ja/idempotence.md index 5702efafc9..6c93011170 100644 --- a/content/ja/idempotence.md +++ b/content/ja/idempotence.md @@ -5,5 +5,5 @@ category: プロパティ tags: ["プロパティ", "", ""] --- -数学やコンピュータサイエンスにおいて、冪等性とは、何度実行しても常に同じ結果になる操作を指します。 +数学やコンピューターサイエンスにおいて、冪等性とは、何度実行しても常に同じ結果になる操作を指します。 パラメーターが同じであれば、冪等な操作を複数回実行しても、追加の効果はありません。 diff --git a/content/ja/immutable-infrastructure.md b/content/ja/immutable-infrastructure.md index c6347009b2..95d329c03b 100644 --- a/content/ja/immutable-infrastructure.md +++ b/content/ja/immutable-infrastructure.md @@ -1,18 +1,18 @@ --- -title: イミュータブルインフラストラクチャー +title: イミュータブルインフラストラクチャ status: Completed category: プロパティ -tags: ["インフラストラクチャー", "プロパティ", ""] +tags: ["インフラストラクチャ", "プロパティ", ""] --- -イミュータブルインフラストラクチャーとは、一度デプロイされると変更することができないコンピューターインフラストラクチャー([仮想マシン](/ja/virtual-machine/)や[コンテナ](/ja/container/)、ネットワーク機器)を指します。 +イミュータブルインフラストラクチャとは、一度デプロイされると変更することができないコンピューターインフラストラクチャ([仮想マシン](/ja/virtual-machine/)や[コンテナ](/ja/container/)、ネットワーク機器)を指します。 これは許可されていない変更を自動的に上書きするプロセスや、最初から変更を許可しないシステムによって強制されます。 -コンテナはイミュータブルインフラストラクチャーの良い例です。 +コンテナはイミュータブルインフラストラクチャの良い例です。 なぜならコンテナに永続的な変更を加えるには、新しいバージョンのコンテナを作成するか、イメージから既存のコンテナを再度作成するしかないからです。 -許可されていない変更の防止や特定により、イミュータブルインフラストラクチャーはセキュリティリスクの特定と軽減を容易にします。 +許可されていない変更の防止や特定により、イミュータブルインフラストラクチャはセキュリティリスクの特定と軽減を容易にします。 このようなシステムの運用ははるかに簡単になります。 なぜなら、管理者がそれについての前提を立てやすくなるためです。 結局のところ、誰も間違いを犯していないことや、伝え忘れた変更を行っていないことが分かっています。 -イミュータブルインフラストラクチャーは[Infrastructure as Code](/ja/infrastructure-as-code/)と密接に関連しており、インフラストラクチャーを作成するために必要なすべての自動化がバージョン管理(たとえばGit)されています。 +イミュータブルインフラストラクチャは[Infrastructure as Code](/ja/infrastructure-as-code/)と密接に関連しており、インフラストラクチャを作成するために必要なすべての自動化がバージョン管理(たとえばGit)されています。 この不変性とバージョン管理の組み合わせにより、システムへのすべての許可された変更に対して、耐久性のある監査ログが存在します。 diff --git a/content/ja/infrastructure-as-a-service.md b/content/ja/infrastructure-as-a-service.md new file mode 100644 index 0000000000..390aaf3c33 --- /dev/null +++ b/content/ja/infrastructure-as-a-service.md @@ -0,0 +1,25 @@ +--- +title: Infrastructure as a Service (IaaS) +status: Completed +category: テクノロジー +tags: ["インフラストラクチャ", "", ""] +--- + +Infrastructure as a service (IaaS)は、[クラウドコンピューティング](/ja/cloud-computing/)のサービスモデルの一つであり、[物理的](/ja/bare-metal-machine/)または[仮想化](/ja/virtualization/)されたコンピューティングリソース、ストレージ、ネットワークリソースをオンデマンドで提供し、従量課金モデルに基づいて利用できます。 +クラウドプロバイダーはハードウェアとソフトウェアを所有、運用し、これらをパブリック、プライベート、またはハイブリッドクラウドの形態で消費者に提供します。 + +## 解決すべき問題はなんですか + +従来のオンプレミス環境では、組織はコンピューティングリソースの有効活用にしばしば苦労していました。 +データセンターは、1%の時間しか必要とされない、潜在的なピーク需要に対応するために構築されなければなりません。 +需要が低い時期には、これらのコンピューティングリソースはアイドル状態になります。 +また、予想を超えるワークロードが発生した場合、処理するためのコンピューティングリソースが不足します。 +このようなスケーラビリティの欠如は、コストの増加とリソースの非効率的な使用につながります。 + +## どのように役に立つのでしょうか + +IaaSを利用することで、組織はアプリケーション用のコンピューティングリソースやデータセンターのスペースを購入し、維持する必要がなくなります。 +オンデマンドインフラを使用することで、必要に応じてコンピューティングリソースをレンタルし、[CAPEX](https://ja.wikipedia.org/wiki/資本的支出)と呼ばれる大規模な資本支出を延期しながら、スケールアップあるいはスケールダウンする柔軟性を得ることができます。 + +IaaSは、新しいアプリケーションを実験したり試したりする際の初期コストを削減し、インフラストラクチャを迅速に展開する施設を提供します。 +クラウドプロバイダーは、開発者が実験し革新するために役立つ、開発あるいはテスト環境にとって優れた選択肢です。 diff --git a/content/ja/infrastructure-as-code.md b/content/ja/infrastructure-as-code.md index 20cf537402..29e9df4f2d 100644 --- a/content/ja/infrastructure-as-code.md +++ b/content/ja/infrastructure-as-code.md @@ -2,18 +2,18 @@ title: Infrastructure as Code (IaC) status: Completed category: コンセプト -tags: ["インフラストラクチャー", "方法論", ""] +tags: ["インフラストラクチャ", "方法論", ""] --- -Infrastructure as Codeは、インフラストラクチャーの定義を一つあるいは複数のファイルで保存する実践を指します。 +Infrastructure as Codeは、インフラストラクチャの定義を一つあるいは複数のファイルで保存する実践を指します。 これは、通常はシェルスクリプトや他の設定ツールを用いたInfrastructure as a Serviceを手動でプロビジョニングする従来のモデルに代わるものです。 ## 解決すべき問題はなんですか -クラウドネイティブな方法でアプリケーションを構築するには、インフラストラクチャーを使い捨てできるようにし、かつ再現可能にする必要があります。 +クラウドネイティブな方法でアプリケーションを構築するには、インフラストラクチャを使い捨てできるようにし、かつ再現可能にする必要があります。 また自動化された繰り返し可能な方法で、人の手が介入することなくオンデマンドに[スケール](/ja/scalability/)する必要があります。 手動でのプロビジョニングは、[クラウドネイティブアプリケーション](/ja/cloud-native-apps/)の応答性とスケーラビリティを満たすことができません。 -手動でのインフラストラクチャーの変更は再現不可能で、すぐにスケールの限界に達し、設定ミスのエラーを引き起こします。 +手動でのインフラストラクチャの変更は再現不可能で、すぐにスケールの限界に達し、設定ミスのエラーを引き起こします。 ## どのように役に立つのでしょうか diff --git a/content/ja/ingress.md b/content/ja/ingress.md index 76bcf38280..f2e5e2582b 100644 --- a/content/ja/ingress.md +++ b/content/ja/ingress.md @@ -7,19 +7,15 @@ tags: ["基礎"] Ingressは、クラスター内で動作するコンテナあるいはコンテナ群への外部からのインターネットトラフィックを管理するためのルールセットです。 これにはIngressリソースとIngressコントローラーという二つの要素があります。 -Ingressリソースは、他のマニフェストファイルと共に存在する設定ファイルで、 -管理者が外部からのトラフィックのルーティングを設定することを可能にします。 +Ingressリソースは、他のマニフェストファイルと共に存在する設定ファイルで、管理者が外部からのトラフィックのルーティングを設定することを可能にします。 Ingressコントローラーは、実際にIngressリソースの設定に従ってトラフィックをルーティングするウェブサーバー技術です。 ## 解決すべき問題は何ですか -クラウドネイティブのウェブアプリケーションは複数のサービスで構成されており、しばしば、 -それらの[サービス](/ja/service/)は、ブラウザを使用してユーザーがインターネット経由でアクセスする必要があります。 -これらのサービスをユーザーがアクセスできるようにしながら、 -このアプリケーションを実行するために[Kubernetes](/ja/kubernetes/)を使用する場合、 -各アプリケーションサービスを全世界に向けて公開する必要があります。 +クラウドネイティブのウェブアプリケーションは複数のサービスで構成されており、しばしば、それらの[サービス](/ja/service/)は、ブラウザを使用してユーザーがインターネット経由でアクセスする必要があります。 +これらのサービスをユーザーがアクセスできるようにしながら、このアプリケーションを実行するために[Kubernetes](/ja/kubernetes/)を使用する場合、各アプリケーションサービスを全世界に向けて公開する必要があります。 最も簡単な方法は、KubernetesのLoad Balancer Serviceを使用することです。 -しかし、このようなサービスを作成すると、基盤となるインフラストラクチャー上に新たなコンポーネントが生まれます。 +しかし、このようなサービスを作成すると、基盤となるインフラストラクチャ上に新たなコンポーネントが生まれます。 これは新しいコストと管理のオーバーヘッドを導入するだけでなく、新しく作成された各ロードバランサーには独自の外部IPアドレスがあります。 これは悪いユーザーエクスペリエンスにつながります。 なぜならユーザーは、アプリケーションにアクセスするために異なるURLをブラウズしたくないからです。 @@ -27,13 +23,9 @@ Ingressコントローラーは、実際にIngressリソースの設定に従っ ## どのように役に立つのでしょうか Ingressリソースを使用すると、アプリケーションのサービスへのトラフィックのバランスとルーティング方法を設定できます。 -Ingressコントローラーは、URLを通じて単一のエントリポイント(例: www.example-url.com)を公開し、 -異なるURLパス(例: www.example-url.com/path)に基づいて実際のルーティングとバランシングを行います。 +Ingressコントローラーは、URLを通じて単一のエントリポイント(例: www.example-url.com)を公開し、異なるURLパス(例: www.example-url.com/path)に基づいて実際のルーティングとバランシングを行います。 Ingressコントローラーは、クラスター内で動作するコンポーネントであり、Ingressリソースで定義されたルールを解釈します。 -ウェブアプリが動作するクラスターの運用者が、 -Nginx、Traefik、HAProxyなどの使用可能な技術セットから特定のIngressコントローラーを選択することができます。 +ウェブアプリが動作するクラスターの運用者が、Nginx、Traefik、HAProxyなどの使用可能な技術セットから特定のIngressコントローラーを選択することができます。 それにより、アプリケーションが複数のサービスで構成されている場合、ユーザーは単一のURLを使用してアクセスできます。 -これは、インフラストラクチャーレベルで数多くの個別のロードバランサーが不要になり、 -各サービスのファイアウォールとロードバランサーのルールの設定が容易になります。 -トラフィックのルーティングと設定の取り扱いを一元化することで、Ingressはスケーラビリティの効率化を提供し、 -リソース利用を最適化し、コストを削減し、クラスター内で実行されるアプリケーションの全体的な管理のしやすさを向上させます。 +これは、インフラストラクチャレベルで数多くの個別のロードバランサーが不要になり、各サービスのファイアウォールとロードバランサーのルールの設定が容易になります。 +トラフィックのルーティングと設定の取り扱いを一元化することで、Ingressはスケーラビリティの効率化を提供し、リソース利用を最適化し、コストを削減し、クラスター内で実行されるアプリケーションの全体的な管理のしやすさを向上させます。 diff --git a/content/ja/kubernetes.md b/content/ja/kubernetes.md index 429f523c31..5d86d43844 100644 --- a/content/ja/kubernetes.md +++ b/content/ja/kubernetes.md @@ -2,20 +2,20 @@ title: Kubernetes status: Completed category: テクノロジー -tags: ["インフラストラクチャー", "基礎", ""] +tags: ["インフラストラクチャ", "基礎", ""] --- Kubernetesは、しばしばK8sと略される、オープンソースのコンテナオーケストレーターです。 -Kubernetesは、モダンなインフラストラクチャー上でコンテナ化されたアプリケーションのライフサイクルを自動化し、[分散システム](/ja/distributed-systems/)全体でアプリケーションを管理するデータセンターのオペレーティングシステムとして機能します。 +Kubernetesは、モダンなインフラストラクチャ上でコンテナ化されたアプリケーションのライフサイクルを自動化し、[分散システム](/ja/distributed-systems/)全体でアプリケーションを管理するデータセンターのオペレーティングシステムとして機能します。 -Kubernetesは、[クラスター](/ja/cluster/)内の[ノード](/ja/nodes/)にまたがって[コンテナ](/ja/container/)をスケジュールし、ロードバランサーや永続ストレージなど、いくつかのインフラストラクチャーリソースを束ねてコンテナ化されたアプリケーションを実行します。 +Kubernetesは、[クラスター](/ja/cluster/)内の[ノード](/ja/nodes/)にまたがって[コンテナ](/ja/container/)をスケジュールし、ロードバランサーや永続ストレージなど、いくつかのインフラストラクチャリソースを束ねてコンテナ化されたアプリケーションを実行します。 Kubernetesは自動化と拡張性を実現し、ユーザーが宣言的に（以下参照）かつ再現可能な方法でアプリケーションをデプロイできるようにします。 Kubernetesは[API](/ja/application-programming-interface/)を介して拡張可能であり、経験豊富なKubernetesの専門家が自分たちのニーズに応じて拡張することができます。 ## 解決すべき問題はなんですか -インフラストラクチャーの自動化と宣言的な設定の管理は長い間重要な概念でしたが、[クラウドコンピューティング](/ja/cloud-computing/)が人気になるにつれて、その重要性がさらに増していきました。 +インフラストラクチャの自動化と宣言的な設定の管理は長い間重要な概念でしたが、[クラウドコンピューティング](/ja/cloud-computing/)が人気になるにつれて、その重要性がさらに増していきました。 計算機リソースへの需要が増加し、組織がより少ないエンジニアでより多くの運用機能を提供する必要が生じる中、その需要に応えるためには新しい技術や作業方法が求められています。 ## どのように役に立つのでしょうか @@ -23,11 +23,13 @@ Kubernetesは[API](/ja/application-programming-interface/)を介して拡張可 従来の[Infrastracture as Code](/ja/infrastructure-as-code/)ツールと同様にKubernetesは自動化を支援しますが、コンテナを用いて動作するという利点があります。 コンテナは[仮想マシン](/ja/virtual-machine/)や物理マシンよりも設定のずれに対する耐性があります。 -さらにKubernetesは宣言的に動作します。つまり、オペレータがマシンに何かを行う方法を指示するのではなく、インフラストラクチャーがどのようにあるべきかを記述します。これは通常、マニフェストファイル（例えばYAML）として記述されます。 +さらにKubernetesは宣言的に動作します。 +つまり、オペレータがマシンに何かを行う方法を指示するのではなく、インフラストラクチャがどのようにあるべきかを記述します。 +これは通常、マニフェストファイル（例えばYAML）として記述されます。 その後、Kubernetesが実行方法の詳細を管理します。 これにより、KubernetesはInfrastracture as Codeと非常に互換性が高くなっています。 またKubernetesは[セルフヒーリング](/ja/self-healing/)を行います。 セルフヒーリングによって、クラスターの実際の状態は、常にオペレータの望む状態と一致します。 Kubernetesがマニフェストファイルで記述された内容と異なる点を検出した場合、Kubernetesコントローラーがそれを修正します。 -Kubernetesが使用するインフラストラクチャーは絶えず変化しているかもしれませんが、Kubernetesは常に自動的に変化に適応し、望ましい状態と一致するように保証します。 +Kubernetesが使用するインフラストラクチャは絶えず変化しているかもしれませんが、Kubernetesは常に自動的に変化に適応し、望ましい状態と一致するように保証します。 diff --git a/content/ja/loosely-coupled-architecture.md b/content/ja/loosely-coupled-architecture.md index 8712a34dd1..800e0c6c6d 100644 --- a/content/ja/loosely-coupled-architecture.md +++ b/content/ja/loosely-coupled-architecture.md @@ -5,9 +5,8 @@ category: プロパティ tags: ["基礎", "アーキテクチャ", "プロパティ"] --- -疎結合アーキテクチャは、アプリケーションの構成要素それぞれが互いに独立して構築されるようなアーキテクチャです -(その逆は[密結合アーキテクチャ](/ja/tightly-coupled-architectures/)と呼ばれます)。 -[マイクロサービス](/ja/microservice/)とよく呼ばれる個々の構成要素は、その他多くのサービスから利用できるような方法で、特定の機能を果たすよう構築されます。 +疎結合アーキテクチャは、アプリケーションの構成要素それぞれが互いに独立して構築されるようなアーキテクチャです(その逆は[密結合アーキテクチャ](/ja/tightly-coupled-architecture/)と呼ばれます)。 +[マイクロサービス](/ja/microservices-architecture/)とよく呼ばれる個々の構成要素は、その他多くのサービスから利用できるような方法で、特定の機能を果たすよう構築されます。 疎結合アーキテクチャは密結合アーキテクチャより一般的に実装が遅くなりますが、特にアプリケーションがスケールする際に多くの利点があります。 アプリケーションが疎結合だと、チームは独立して機能開発、デプロイ、スケールすることが可能です。 diff --git a/content/ja/microservices-architecture.md b/content/ja/microservices-architecture.md index df6aee24fd..5d36331ab9 100644 --- a/content/ja/microservices-architecture.md +++ b/content/ja/microservices-architecture.md @@ -1,21 +1,34 @@ --- title: マイクロサービスアーキテクチャ status: Completed -tags: ["インフラストラクチャー", "基礎", ""] +tags: ["インフラストラクチャ", "基礎", ""] --- -マイクロサービスアーキテクチャは、アプリケーションを個々の独立した（マイクロ）[サービス](/ja/service/)に分割するアーキテクチャ手法で、各サービスは特定の機能に焦点を当てています。これらのサービスは密接に連携して動作し、エンドユーザーには単一のエンティティとして見えます。例として、Netflix を考えてみます。そのインターフェイスは、ビデオへのアクセス、検索、プレビューが可能です。これらの機能は、ブラウザでの認証、検索、プレビューの実行など、それぞれ一つの機能を扱う小さなサービスによって実現されている可能性が高いです。 +マイクロサービスアーキテクチャは、アプリケーションを個々の独立した（マイクロ）[サービス](/ja/service/)に分割するアーキテクチャ手法で、各サービスは特定の機能に焦点を当てています。 +これらのサービスは密接に連携して動作し、エンドユーザーには単一のエンティティとして見えます。 +例として、Netflix を考えてみます。そのインターフェイスは、ビデオへのアクセス、検索、プレビューが可能です。 +これらの機能は、ブラウザでの認証、検索、プレビューの実行など、それぞれ一つの機能を扱う小さなサービスによって実現されている可能性が高いです。 このアーキテクチャ手法により、[モノリシックアプリケーション](/ja/monolithic-apps/)（以下に詳細あり）のようにすべてが密接に結合している場合よりも、開発者は新機能を迅速に導入したり機能を更新したりすることができます。 ## 解決すべき問題はなんですか -アプリケーションは、さまざまなパーツで構成され、それぞれが特定の能力を担当します。特定の機能に対する需要は、アプリケーションの他のパーツに対する需要と連動して必ず増減するわけではありません。Netflix の例に戻りましょう。例えば、大規模なマーケティングキャンペーンの後で、Netflix の契約者数が急増したが、その日の早い時間帯におけるストリーミングは概ね安定しているとします。 -契約者数の急増は、平常時より多くのキャパシティを要求します。伝統的な手法（モノリシックアプローチ）の場合では、増加に対応するためにアプリ全体を[スケールアップ](/ja/scalability/)する必要がありました。これは非常に非効率的なリソースの使い方です。 +アプリケーションは、さまざまなパーツで構成され、それぞれが特定の能力を担当します。 +特定の機能に対する需要は、アプリケーションの他のパーツに対する需要と連動して必ず増減するわけではありません。 +Netflix の例に戻りましょう。 +例えば、大規模なマーケティングキャンペーンの後で、Netflix の契約者数が急増したが、その日の早い時間帯におけるストリーミングは概ね安定しているとします。 +契約者数の急増は、平常時より多くのキャパシティを要求します。 +伝統的な手法（モノリシックアプローチ）の場合では、増加に対応するためにアプリ全体を[スケールアップ](/ja/scalability/)する必要がありました。 +これは非常に非効率的なリソースの使い方です。 -また、モノリシックアーキテクチャは、開発者が設計の落とし穴に陥りやすくするものです。すべてのコードが一か所にあるため、そのコードが[密結合](/ja/tightly-coupled-architectures/)になりやすく、関心の分離の原則を適用することが難しくなります。さらに、多くの場合、モノリスはデプロイする前にコードベース全体を理解する必要性を生じさせます。マイクロサービスアーキテクチャは、こうした課題への対応策です。 +また、モノリシックアーキテクチャは、開発者が設計の落とし穴に陥りやすくするものです。 +すべてのコードが一か所にあるため、そのコードが[密結合](/ja/tightly-coupled-architecture/)になりやすく、関心の分離の原則を適用することが難しくなります。 +さらに、多くの場合、モノリスはデプロイする前にコードベース全体を理解する必要性を生じさせます。 +マイクロサービスアーキテクチャは、こうした課題への対応策です。 ## どのように役に立つのでしょうか -機能を異なるマイクロサービスに分離することにより、それらを独立してデプロイ、アップデート、スケールすることが容易になります。また、意図せずアプリケーションの他のパーツに悪影響を与えることなく、大きなアプリケーションの一部に対して複数のチームが同時に作業することを可能にします。 -マイクロサービスアーキテクチャは多くの問題を解決しますが、デプロイして追跡する必要があるものが桁違いに増えるため、運用上のオーバーヘッドも発生させます。多くの[クラウドネイティブテクノロジー](/ja/cloud-native-tech/)は、マイクロサービスのデプロイと管理を容易にすることを目指しています。 +機能を異なるマイクロサービスに分離することにより、それらを独立してデプロイ、アップデート、スケールすることが容易になります。 +また、意図せずアプリケーションの他のパーツに悪影響を与えることなく、大きなアプリケーションの一部に対して複数のチームが同時に作業することを可能にします。 +マイクロサービスアーキテクチャは多くの問題を解決しますが、デプロイして追跡する必要があるものが桁違いに増えるため、運用上のオーバーヘッドも発生させます。 +多くの[クラウドネイティブテクノロジー](/ja/cloud-native-tech/)は、マイクロサービスのデプロイと管理を容易にすることを目指しています。 diff --git a/content/ja/monolithic-apps.md b/content/ja/monolithic-apps.md index b670a7287c..eed64ed8a0 100644 --- a/content/ja/monolithic-apps.md +++ b/content/ja/monolithic-apps.md @@ -6,7 +6,7 @@ tags: ["アーキテクチャ", "基礎"] --- モノリシックアプリケーションは単独で配置できるプログラムにすべての機能を格納しており、アプリケーションを開発する時に最も簡単かつ手軽な出発点とされています。 -しかし、アプリケーションが複雑になると、モノリスのメンテナンスが難しくなることがあります。 +しかし、アプリケーションが複雑になると、モノリスのメンテナンスが難しくなることがあります。 また、同じコードベースで作業する開発者が増えるため、変更が競合したり、開発者の間で直接コミュニケーションを取る必要性が高まります。 ## 解決すべき問題はなんですか @@ -19,4 +19,4 @@ tags: ["アーキテクチャ", "基礎"] 適切に設計されたモノリスはアプリケーションを起動して実行する最も簡単な方法であるため、簡潔さを維持できます。 モノリシックアプリーケーションがビジネス的に価値があると証明されれば、アプリケーションを分割し、マイクロサービス化させる事も可能です。 価値が証明される前に技術的努力を費やし、マイクロサービス基盤でアプリケーションを開発することは早計である可能性があります。 -アプリケーションが価値を生まなければ、その努力も無駄になるためです。 \ No newline at end of file +アプリケーションが価値を生まなければ、その努力も無駄になるためです。 diff --git a/content/ja/multitenancy.md b/content/ja/multitenancy.md new file mode 100644 index 0000000000..f65ced6090 --- /dev/null +++ b/content/ja/multitenancy.md @@ -0,0 +1,34 @@ +--- +title: マルチテナンシー +status: Completed +category: プロパティ +tags: ["アーキテクチャ", "プロパティ", ""] +--- + +マルチテナンシーとは、複数のテナントにサービスを提供する単一のソフトウェアインストールを指します。 +テナントとは、自身のデータセットでソフトウェアを利用するユーザー、アプリケーション、あるいはそれらのグループのことです。 +これらのテナントは(所有者による明示的な指示がある場合を除いて)データを共有せず、互いの存在を意識することもありません。 + +テナントは、1人の独立したユーザーで1つのログインIDを持つほど小さくなり得ます。 +例えば、個人の生産性を高めるソフトウェアを考えてみてください。 +あるいは、何千ものログインIDを持つ企業全体ほど大きくもなり得ます。 +これらは、それぞれが独自の権限を持ちつつも多方面で相互に関連しています。 +マルチテナントソフトウェアの例には、Google Mail、Google Docs、Microsoft Office 365、Salesforce CRM、Dropboxなどがあり、完全または部分的にマルチテナントソフトウェアとして分類されます。 + +## 解決すべき問題はなんですか + +マルチテナンシーがなければ、各テナントに専用のソフトウェアインストールが必要になります。 +これはリソース利用とメンテナンスの労力を増加させ、最終的にはソフトウェアコストを増加させます。 + +## どのように役に立つのでしょうか + +マルチテナントソフトウェアは、各テナントに分離された環境(作業データ、設定、認証情報リストなど)を提供し、同時に複数のテナントにサービスを提供します。 +テナントの観点から見れば、各々が専用のソフトウェアインストールを持っているように見えますが、実際にはすべてが1つを共有しています。 +これはソフトウェアをサーバー上で実行し、テナントがインターフェイスおよび/あるいは[API](/ja/application-programming-interface/)を通じてネットワーク経由で接続できるようにすることで実現されます([クライアントサーバーアーキテクチャ](/ja/client-server-architecture/)も参照)。 +マルチテナントソフトウェアを使用すると、テナントはお互いに影響を与えることなく定義された制御された方法でのみ、1つのインストールのリソースを共有することができます。 +ソフトウェア提供者側の結果としてのリソース節約は、テナントに渡されユーザーにとってのソフトウェアコストを大幅に削減することができます(改めてウェブベースのEメールやドキュメントエディターを考えてみてください)。 + +## 関連する用語はありますか + +マルチテナンシーはSaaSと同義ではありません。 +しかし、SaaSがマルチテナントであることは非常に一般的であり、その主要な利点の1つとしてマルチテナンシーを特徴づけることがあります。 diff --git a/content/ja/nodes.md b/content/ja/nodes.md index 14bf72b188..0db4e3e783 100644 --- a/content/ja/nodes.md +++ b/content/ja/nodes.md @@ -2,7 +2,7 @@ title: ノード status: Completed category: コンセプト -tags: ["インフラストラクチャー", "基礎", ""] +tags: ["インフラストラクチャ", "基礎", ""] --- ノードとは、他のコンピューター、つまり他のノードと協力して共通のタスクを達成するコンピューターのことです。 diff --git a/content/ja/observability.md b/content/ja/observability.md index 45691feaaf..284191f6ad 100644 --- a/content/ja/observability.md +++ b/content/ja/observability.md @@ -1,16 +1,18 @@ --- -title: 可観測性 +title: オブザーバビリティ(可観測性) status: Completed category: コンセプト tags: ["プロパティ", "", ""] --- -可観測性とは、システムが実用的な洞察をどの程度出力できるかを決める性質のことを指します。 -可観測性により、ユーザーはシステム外部への出力を元にそのシステムの状態を理解し、(是正)措置を取ることが可能になります。 +オブザーバビリティとは、システムが実用的な洞察をどの程度出力できるかを決める性質のことを指します。 +オブザーバビリティにより、ユーザーはシステム外部への出力を元にそのシステムの状態を理解し、(是正)措置を取ることが可能になります。 コンピューターシステムは、CPU時間・メモリ・ディスク容量といった低水準のシグナルや、APIの応答時間・エラー数・秒間トランザクション数などを含む高水準でビジネスに直結するシグナルを観測することで評価されます。 -可観測なシステムは、いわゆる可観測性ツールと言われる専門のツールで**観測**(もしくは監視)されます。可観測性ツールの一覧は[クラウドネイティブ ランドスケープの可観測性セクション](https://landscape.cncf.io/card-mode?category=observability-and-analysis&grouping=category)で見られます。 +可観測なシステムは、いわゆるオブザーバビリティツールと言われる専門のツールで**観測**(もしくは監視)されます。 +オブザーバビリティツールの一覧は[クラウドネイティブ ランドスケープのオブザーバビリティセクション](https://landscape.cncf.io/?group=projects-and-products&view-mode=card#observability-and-analysis--observability)で見られます。 -可観測なシステムは、有意義かつ実用的なデータを運用者に提供し、運用者が(インシデントへのより素早い対応や開発者の生産性向上といった)好ましい結果を出すことを可能にします。システムのダウンタイムとともに、手間のかかる手作業での仕事も少なくなります。 +可観測なシステムは、有意義かつ実用的なデータを運用者に提供し、運用者が(インシデントへのより素早い対応や開発者の生産性向上といった)好ましい結果を出すことを可能にします。 +システムのダウンタイムとともに、手間のかかる手作業での仕事も少なくなります。 結果として、システムの運用コストと開発コストは、そのシステムがどれだけ可観測なのかに大きく影響を受けるでしょう。 diff --git a/content/ja/pod.md b/content/ja/pod.md index 28102d6e15..cd59eb2447 100644 --- a/content/ja/pod.md +++ b/content/ja/pod.md @@ -2,7 +2,7 @@ title: Pod status: Completed category: コンセプト -tags: ["インフラストラクチャー", "基礎", ""] +tags: ["インフラストラクチャ", "基礎", ""] --- [Kubernetes](/ja/kubernetes/)環境の中では、Podは最も基本的なデプロイ可能ユニットとして機能します。 @@ -12,8 +12,7 @@ Kubernetesは、より大規模なDeploymentの一部としてPodを管理し、 ## 解決すべき問題はなんですか -コンテナは一般的に、特定のワークロードを実行し制御する独立した単位として機能しますが、 -コンテナが密接に相互作用し、適切に連携して制御される必要がある場合もあります。 +コンテナは一般的に、特定のワークロードを実行し制御する独立した単位として機能しますが、コンテナが密接に相互作用し、適切に連携して制御される必要がある場合もあります。 これらの密接に関連するコンテナがそれぞれ個別に管理される場合、冗長な管理作業が発生します。 たとえば、オペレーターは関連するコンテナの配置を繰り返し判断し、それらが一緒に保たれるようにしなければなりません。 @@ -21,11 +20,9 @@ Kubernetesは、より大規模なDeploymentの一部としてPodを管理し、 ## どのように役に立つのでしょうか -Podは密接に関連するコンテナを単一のユニットにまとめることで、 -コンテナ操作を大幅に簡素化します。 +Podは密接に関連するコンテナを単一のユニットにまとめることで、コンテナ操作を大幅に簡素化します。 たとえば、補助的なコンテナは、追加機能を提供したり、グローバルな設定を行うために主コンテナと一緒に使用されることがよくあります。 -これには、基本設定を主コンテナに注入して適用するコンテナ、 -_sidecar_(コンテナ)であり、主コンテナのためのネットワークトラフィックルーティングを処理する([サービスメッシュ](/ja/service-mesh/)を参照)、 -あるいは各コンテナと連動してログを収集するコンテナなどが含まれます。 +これには、基本設定を主コンテナに注入して適用するコンテナ、 _sidecar_ (コンテナ)であり、主コンテナのためのネットワークトラフィックルーティングを処理する([サービスメッシュ](/ja/service-mesh/)を参照)、あるいは各コンテナと連動してログを収集するコンテナなどが含まれます。 -メモリとCPUの割り当ては、Podレベルで定義することも、コンテナごとに定義することもできます。Podレベルで定義すると、内部のコンテナがリソースを柔軟に共有できます。 +メモリとCPUの割り当ては、Podレベルで定義することも、コンテナごとに定義することもできます。 +Podレベルで定義すると、内部のコンテナがリソースを柔軟に共有できます。 diff --git a/content/ja/policy-as-code.md b/content/ja/policy-as-code.md new file mode 100644 index 0000000000..9a5155db20 --- /dev/null +++ b/content/ja/policy-as-code.md @@ -0,0 +1,23 @@ +--- +title: Policy as Code (PaC) +status: Completed +category: コンセプト +tags: ["方法論", "", ""] +--- + +Policy as Codeは、ポリシー定義を機械的に読み取り可能かつ処理可能な形式で、１つ以上のファイルに保存する方法です。 +これは、別々の文書に人間が読める形式でポリシーが文書化されていた従来の方式を置き換えます。 + +## 解決すべき問題はなんですか + +アプリケーションやインフラストラクチャの構築には、しばしば組織が定義した多数のポリシーにより制約が課されます。 +たとえば、シークレット情報をソースコードへの埋め込むことを禁止するセキュリティポリシーや、スーパーユーザー権限でコンテナの実行を禁止するポリシー、あるいは特定の地理的位置以外にデータを保存することを禁止するポリシーなどがあります。 +開発者やレビュアーにとって、アプリケーションやインフラストラクチャが文書化されたポリシーに従っているかを手動で確認することは非常に労力がかかり、エラーも発生しやすいです。 +手動のプロセスでは、クラウドネイティブアプリケーションの応答性やスケールの要件を満たせません。 + +## どのように役に立つのでしょうか + +コードを通じてポリシーを記述することは、再現性を持たせることができ、手動で行う場合と比べてエラーが減少します。 +Policy as Codeの他の利点は、コードがGitのようなバージョン管理システムで管理できることです。 +Gitは変更履歴を作成し、これはなにかが期待通りに機能しない際にとりわけ役に立ちます。 +これにより、誰が変更を行ったのかを確認し、以前のバージョンに戻すことが可能になります。 diff --git a/content/ja/portability.md b/content/ja/portability.md index 60d8f0eb62..4136bd9895 100644 --- a/content/ja/portability.md +++ b/content/ja/portability.md @@ -1,11 +1,11 @@ --- -title: 可搬性 +title: ポータビリティ(可搬性) status: Completed category: プロパティ tags: ["基礎", "プロパティ", ""] --- -ソフトウェアの特性である可搬性は、再利用性の一つの形態です。 +ソフトウェアの特性であるポータビリティは、再利用性の一つの形態です。 クラウドプロバイダー、オペレーティングシステムやベンダーなどの特定の運用環境へのロックインを避けるのに役立ちます。 伝統的に、ソフトウェアは特定の環境(例えばAWSやLinux)向けに構築されがちです。 diff --git a/content/ja/reliability.md b/content/ja/reliability.md index fb2febb94a..9c415eeee8 100644 --- a/content/ja/reliability.md +++ b/content/ja/reliability.md @@ -6,6 +6,6 @@ tags: ["基礎", "プロパティ", ""] --- クラウドネイティブの観点から見ると、信頼性とはシステムが障害にどれだけうまく対応するかを指します。 -インフラストラクチャーが変化し、個々のコンポーネントが故障しても動作し続ける[分散システム](/ja/distributed-systems/)があれば、それは信頼性があります。 +インフラストラクチャが変化し、個々のコンポーネントが故障しても動作し続ける[分散システム](/ja/distributed-systems/)があれば、それは信頼性があります。 一方で、容易に故障し、運用者が手動で介入して動作を維持する必要がある場合、それは信頼性がないです。 [クラウドネイティブアプリケーション](/ja/cloud-native-apps/)の目標は、本質的に信頼性の高いシステムを構築することです。 diff --git a/content/ja/role-based-access-control.md b/content/ja/role-based-access-control.md index 914c94f30e..4c5131b023 100644 --- a/content/ja/role-based-access-control.md +++ b/content/ja/role-based-access-control.md @@ -6,17 +6,13 @@ tags: ["セキュリティ", "", ""] --- ロールベースアクセス制御(RBAC)は、チームあるいはより大きな組織内での個々のロールに基づいてシステムやネットワーク、リソースへのアクセスを管理するセキュリティ方法です。 -RBACは、管理者に特定の職務を持つすべてのユーザーに必要なアクセスレベルを割り当て、 -事前に定義された一連の権限を持つ役割をそれらのユーザーに割り当てる権限を与えます。 +RBACは、管理者に特定の職務を持つすべてのユーザーに必要なアクセスレベルを割り当て、事前に定義された一連の権限を持つ役割をそれらのユーザーに割り当てる権限を与えます。 組織はRBACを利用して、従業員ごとの役割と責任に合わせた、さまざまなレベルのアクセスを提供します。 ## 解決すべき問題はなんですか -RBACは、特にアプリケーションとチームメンバーの数が増えるにつれて、 -チームメンバーやアプリケーションがアクセスできるリソース、 -および彼らが実行できる操作を制御するという課題に対処します。 -管理者は、各ユーザーがアクセスする必要があるリソースに対して正しい権限を持っていることを確認する必要がありますが、 -これは構造化されたアクセス制御メカニズムがなければ煩雑で間違いが生じやすい作業になります。 +RBACは、特にアプリケーションとチームメンバーの数が増えるにつれて、チームメンバーやアプリケーションがアクセスできるリソース、および彼らが実行できる操作を制御するという課題に対処します。 +管理者は、各ユーザーがアクセスする必要があるリソースに対して正しい権限を持っていることを確認する必要がありますが、これは構造化されたアクセス制御メカニズムがなければ煩雑で間違いが生じやすい作業になります。 ## どのように役に立つのでしょうか diff --git a/content/ja/scalability.md b/content/ja/scalability.md index 655d120645..af919c5aaf 100644 --- a/content/ja/scalability.md +++ b/content/ja/scalability.md @@ -9,10 +9,13 @@ tags: ["基礎","プロパティ" , ""] この特性により、システムが行うべき任意の処理に対して、その処理能力を増強することが可能となります。 -例として、[Kubernetes](/ja/kubernetes/)[クラスタ](/ja/cluster/)は、[コンテナ化](/ja/containerization/)されたアプリの数を増減することでスケールしますが、そのスケーラビリティはいくつかの要素に依存します。[ノード](/ja/nodes/)の数、各ノードが処理できる[コンテナ](/ja/container/)の数、コントロールプレーンがサポート可能なレコードとオペレーションの規模と関係しています。 +例として、[Kubernetes](/ja/kubernetes/)[クラスタ](/ja/cluster/)は、[コンテナ化](/ja/containerization/)されたアプリの数を増減することでスケールしますが、そのスケーラビリティはいくつかの要素に依存します。 +[ノード](/ja/nodes/)の数、各ノードが処理できる[コンテナ](/ja/container/)の数、コントロールプレーンがサポート可能なレコードとオペレーションの規模と関係しています。 スケーラブルなシステムは、キャパシティの追加を容易に行えます。 -私たちはスケーリングアプローチを2種類に分類します。[水平スケーリング](/ja/horizontal-scaling/)では、増加した負荷を処理するためにより多くのノードを追加します。一方で、[垂直スケーリング](/ja/vertical-scaling/)では、個々のノードがより多くのトランザクションを実行するために性能向上します（例えば、個別のマシンにより多くのメモリやCPUを追加すること）。 +私たちはスケーリングアプローチを2種類に分類します。 +[水平スケーリング](/ja/horizontal-scaling/)では、増加した負荷を処理するためにより多くのノードを追加します。 +一方で、[垂直スケーリング](/ja/vertical-scaling/)では、個々のノードがより多くのトランザクションを実行するために性能向上します（例えば、個別のマシンにより多くのメモリやCPUを追加すること）。 スケーラブルなシステムは、容易に変更することができ、ユーザーのニーズに応えることができます。 diff --git a/content/ja/security-chaos-engineering.md b/content/ja/security-chaos-engineering.md new file mode 100644 index 0000000000..06b2f4edbc --- /dev/null +++ b/content/ja/security-chaos-engineering.md @@ -0,0 +1,26 @@ +--- +title: セキュリティカオスエンジニアリング +status: Completed +category: コンセプト +tags: ["セキュリティ", "方法論", ""] +--- + +セキュリティカオスエンジニアリング(SCE)は、[カオスエンジニアリング](/ja/chaos-engineering/)に基づく規律です。 +SCEは、分散システムに対して積極的なセキュリティ実験を行い、乱雑や悪意のある条件に耐えるシステムの能力に信頼を築くために行われます。 +セキュリティカオスエンジニアは、定常状態、仮説、継続的検証、学習した教訓、および緩和の実施を含む科学的方法のループを使用してこれを達成します。 + +## 解決すべき問題はなんですか + +[サイト信頼性エンジニア](/ja/site-reliability-engineering/)(SRE)とサイバーセキュリティエンジニアの主な優先事項は、できるだけ早くサービスを復旧させ、ゼロダウンタイムを目指してビジネスへの影響を最小限に抑えることです。 +SREおよびサイバーセキュリティエンジニアは、障害発生前および障害発生後のインシデント状況の両方に対処します。 +ほとんどのセキュリティ問題は、迅速に発見および修正が難しく、アプリケーションやシステムの機能に影響を与えます。 +さらに、セキュリティインシデントは、開発フェーズ中に発見するのが通常難しいものです。 + +## どのように役に立つのでしょうか + +セキュリティカオスエンジニアリングは、[オブザーバビリティ](/ja/observability/)とサイバーレジリエンスの実践を中心に構築されています。 +これは「未知の未知」を明らかにし、システムに自信を持ち、サイバーレジリエンスを向上させ、オブザーバビリティを改善することを目指しています。 + +エンジニアリングチームは、複雑なインフラストラクチャ、プラットフォーム、および分散システム内のセキュリティ問題に関する理解を徐々に向上させます。 +SCEは、製品全体のサイバーレジリエンスを改善し、隠されたセキュリティ問題を明らかにし、典型的な盲点を露呈し、チームを重要なエッジケースに備えさせます。 +このアプローチは、SRE、[DevOps](/ja/devops/)、および[DevSecOps](/ja/devsecops/)エンジニアが、システムに自信を持ち、サイバーレジリエンスを向上させ、オブザーバビリティを改善するのに役立ちます。 diff --git a/content/ja/self-healing.md b/content/ja/self-healing.md index 0fce4281f6..33caf6a44e 100644 --- a/content/ja/self-healing.md +++ b/content/ja/self-healing.md @@ -2,7 +2,7 @@ title: 自己修復 status: Completed category: プロパティ -tags: ["インフラストラクチャー", "プロパティ"] +tags: ["インフラストラクチャ", "プロパティ"] --- 自己修復システムは、人の手の介入なしに特定のタイプの障害から回復することができます。 diff --git a/content/ja/serverless.md b/content/ja/serverless.md new file mode 100644 index 0000000000..8f708a7309 --- /dev/null +++ b/content/ja/serverless.md @@ -0,0 +1,30 @@ +--- +Title: サーバーレス +Status: Completed +Category: テクノロジー +tags: ["アーキテクチャ", "", ""] +--- + +サーバーレスは、開発者がサーバーの管理を気にすることなくアプリケーションの構築と実行を可能にするクラウドネイティブの開発モデルです。 +サーバーレスパラダイム内にサーバーは存在しますが、アプリケーション開発プロセスから[抽象化](/ja/abstraction/)されています。 +クラウドプロバイダーがサーバーインフラのプロビジョニング、維持、および[スケーリング](/ja/scalability/)の日常的な作業を処理します。 +開発者は、デプロイのためにコードを[コンテナ](/ja/container/)に便利にパッケージできます。 +一度デプロイされると、サーバーレスアプリは需要に応じて自動的にスケールアップおよびダウンします。 +パブリッククラウドプロバイダーからのサーバーレスの提供は通常、イベント駆動型の実行モデルによってオンデマンドで課金されます。 +その結果、サーバーレス機能がアイドル状態にあるとき、関連するコストは発生しません。 + +## 解決すべき問題はなんですか + +標準的な[Infrastructure as a Service (IaaS)](/ja/infrastructure-as-a-service/)の[クラウドコンピューティング](/ja/cloud-computing/)モデルでは、 +ユーザーはキャパシティの単位を事前に購入します。 +つまり、アプリを実行するために常時稼働するサーバーコンポーネントの料金をパブリッククラウドプロバイダーに支払うことになります。 +高需要時にサーバーのキャパシティをスケールアップしたり、キャパシティが必要なくなったときにスケールダウンしたりするのは、ユーザーの責任です。 +アプリケーションが使用されていないときであっても、アプリケーションを運用するために必要なクラウドインフラストラクチャーはアクティブなままです。 + +## どのように役に立つのでしょうか + +従来のアプローチとは対照的に、サーバーレスアーキテクチャは必要なときにのみアプリケーションを起動します。 +イベントがアプリコードの実行をトリガーすると、パブリッククラウドプロバイダーは、そのコードのためのリソースを動的に割り当てます。 +コードの実行が終了すると、ユーザーは支払いを停止します。 +コストと効率の利点に加えて、サーバーレスは開発者をアプリのスケーリングとサーバーのプロビジョニングに関連する日常的で単調なタスクから解放します。 +サーバーレスを使用すると、オペレーティングシステムとファイルシステムの管理、セキュリティパッチ、ロードバランシング、キャパシティ管理、スケーリング、ログ、監視などの日常的なタスクは、すべてクラウドサービスプロバイダーに委ねられます。 diff --git a/content/ja/service-discovery.md b/content/ja/service-discovery.md new file mode 100644 index 0000000000..9ba47c96e5 --- /dev/null +++ b/content/ja/service-discovery.md @@ -0,0 +1,21 @@ +--- +title: サービスディスカバリー +status: Completed +category: コンセプト +tags: ["ネットワーキング", "", ""] +--- + +サービスディスカバリーはサービスを構成する個々のインスタンスを見つけるプロセスです。 +サービスディスカバリーツールは、サービスを構成するさまざまなノードやエンドポイントを追跡します。 + +## 解決すべき問題はなんですか + +クラウドネイティブアーキテクチャは、動的かつ流動的で常に変化しています。 +[コンテナ化](/ja/containerization/)されたアプリケーションは、その寿命の中で複数回起動と停止をする可能性があります。 +起動や停止が起きるたびに新しいアドレスを持つことになり、それを見つけたい任意のアプリケーションは、新しい位置情報を提供するツールを必要とします。 + +## どのように役に立つのでしょうか + +サービスディスカバリーは、ネットワーク内のアプリケーションを追跡し、必要な時にお互いを見つけられるようにします。 +そして、個々のサービスを識別し見つけるための共通の場所を提供します。 +サービスディスカバリーエンジンはデータベースのようなツールで、どのようなサービスが存在し、それらをどのように配置するかについての情報を保存します。 diff --git a/content/ja/service-mesh.md b/content/ja/service-mesh.md index cd8c26398a..3bfb41fd4a 100644 --- a/content/ja/service-mesh.md +++ b/content/ja/service-mesh.md @@ -8,12 +8,11 @@ tags: ["ネットワーキング", "", ""] [マイクロサービス](/ja/microservices-architecture/)の世界では、アプリケーションは複数の小さな[サービス](/ja/service/)に分割され、それらがネットワークを介して通信します。 あなたのWi-Fiネットワークのように、コンピューターネットワークは本質的には信頼性が低く、ハッキングされやすく、しばしば遅いものです。 サービスメッシュは、サービス間のトラフィック(すなわち通信)を管理することによって、この新しい課題に対処します。 -サービスメッシュは、すべてのサービスにわたって[信頼性](/ja/reliability/)、[可観測性](/ja/observability/)、およびセキュリティ機能を均一に追加します。 +サービスメッシュは、すべてのサービスにわたって[信頼性](/ja/reliability/)、[オブザーバビリティ](/ja/observability/)、およびセキュリティ機能を均一に追加します。 ## 解決すべき問題はなんですか -マイクロサービスアーキテクチャに移行したことで、エンジニアは数百、 -場合によっては数千ものサービスを扱うようになり、それらすべてが相互に通信を必要としています。 +マイクロサービスアーキテクチャに移行したことで、エンジニアは数百、場合によっては数千ものサービスを扱うようになり、それらすべてが相互に通信を必要としています。 つまり、ネットワーク上で大量のトラフィックが行き交っています。 その上、個々のアプリケーションは、必須の要件をサポートするために通信を暗号化する必要があるかもしれません。 あるいは運用チームに共通のメトリクスを提供する必要があるかもしれませんし、問題の診断に役立つ、トラフィックに関する詳細な洞察を提供する必要があるかもしれません。 @@ -21,6 +20,5 @@ tags: ["ネットワーキング", "", ""] ## どのように役に立つのでしょうか -サービスメッシュは、コードの変更を必要とせずに、クラスタ全体のすべてのサービスに対して、 -信頼性、可観測性、およびセキュリティ機能を均一に追加します。 +サービスメッシュは、コードの変更を必要とせずに、クラスタ全体のすべてのサービスに対して、信頼性、オブザーバビリティ、およびセキュリティ機能を均一に追加します。 サービスメッシュが登場する前は、その機能をすべての個々のサービスに組み込む必要があり、バグや技術的負債の潜在的な原因となっていました。 diff --git a/content/ja/shift-left.md b/content/ja/shift-left.md new file mode 100644 index 0000000000..99dc2a3695 --- /dev/null +++ b/content/ja/shift-left.md @@ -0,0 +1,29 @@ +--- +title: シフトレフト +status: Completed +category: コンセプト +tags: ["方法論", "", ""] +--- + +シフトレフトの「レフト」はソフトウェア開発ライフサイクルのより初期のステージを指します。 +ライフサイクルをステージが左から右へと実行される線と考えます。 +シフトレフトは、テストやセキュリティなどの開発プラクティスをソフトウェア開発ライフサイクルの終盤ではなく、早い段階で実施することです。 + +もともとはテストプロセスを早い段階で行うことを指していましたが、現在ではセキュリティやデプロイなど、ソフトウェア開発や[DevOps](/ja/devops/)の他の側面にも適用されることがあります。 + +## 解決すべき問題はなんですか + +セキュリティ問題や、バグ、ソフトウェアの欠陥は開発サイクルの後期やデプロイ後に発見された場合、とりわけソフトウェアが既に本番環境へデプロイされていた場合、修正はより難しく高コストになる可能性があります。 + +## どのように役に立つのでしょうか + +ソフトウェア開発におけるシフトレフトの考え方を適用することで、チームは開発ライフサイクル全体を通してテストやセキュリティを実装することができます。 +テストとセキュリティに対する責任はソフトウェアエンジニアから品質保証、運用まで開発チーム全体にわたって共有さるものであるため、誰もがアプリケーションの安定性とセキュリティを担保する役割を果たします。 + +加えて、シフトレフトは継続的な改善を可能とし、ウォーターフォール開発よりも[アジャイル](/ja/agile-software-development/)開発により実践されます。 +チームは小さな改善を繰り返し行い、より早い段階で問題を特定することができます。 +このアプローチにより、エンジニアは設計とアーキテクチャフェーズにおいて、セキュリティと安全な開発プラクティスを適用することが可能になります。 +開発サイクル全体を通してテストを行うことは、ソフトウェアのリリース前に必要となるテスト時間を短縮します。 + +多数のソフトウェアツールやSaaSソリューションは、これらのプラクティスを左にシフトすることを支援します。 +ただし、シフトレフトはチーム内のプロセスの改善や文化の改革を通しても実践することができます。 diff --git a/content/ja/site-reliability-engineering.md b/content/ja/site-reliability-engineering.md index 897d6f8edb..4ef5b48248 100644 --- a/content/ja/site-reliability-engineering.md +++ b/content/ja/site-reliability-engineering.md @@ -1,27 +1,24 @@ --- -title: Site Reliability Engineering +title: サイト信頼性エンジニアリング(SRE) status: Completed category: コンセプト tags: ["方法論", "", ""] --- -SRE(Site Reliability Engineering)は、オペレーションとソフトウェアエンジニアリングを組み合わせた分野です。 -後者では、特にインフラストラクチャーとオペレーションの問題に応用されます。 -つまり製品機能を構築する代わりに、SREエンジニアは、アプリケーションを実行するためのシステムを構築します。 -[DevOps](/ja/devops/)との類似点がありますが、DevOpsがコードを本番環境に導入することに焦点を当てているのに対し、 -SREは本番環境で実行中のコードが適切に機能することを保証します。 +サイト信頼性エンジニアリング(SRE: Site Reliability Engineering)は、オペレーションとソフトウェアエンジニアリングを組み合わせた分野です。 +後者では、特にインフラストラクチャとオペレーションの問題に応用されます。 +つまり製品機能を構築する代わりに、サイト信頼性エンジニアは、アプリケーションを実行するためのシステムを構築します。 +[DevOps](/ja/devops/)との類似点がありますが、DevOpsがコードを本番環境に導入することに焦点を当てているのに対し、SREは本番環境で実行中のコードが適切に機能することを保証します。 ## 解決すべき問題はなんですか -アプリケーションを[高い信頼性](/ja/reliability/)で実行するためには、 -パフォーマンスモニタリング、アラート、デバッグ、トラブルシューティングなど、複数の機能が必要です。 +アプリケーションを[高い信頼性](/ja/reliability/)で実行するためには、パフォーマンスモニタリング、アラート、デバッグ、トラブルシューティングなど、複数の機能が必要です。 これらがなければ、システムオペレーターは問題に対応するだけで、積極的にそれらを回避しようとすることはできません。 — ダウンタイムは時間の問題となるだけです。 ## どのように役に立つのでしょうか SREのアプローチは、基盤となるシステムを継続的に改善することで、ソフトウェア開発プロセスのコスト、時間、労力を最小限に抑えます。 -システムは、インフラストラクチャーとアプリケーションコンポーネントを継続的に測定し監視します。 -何か問題が発生した場合、システムはSREエンジニアにいつ、どこで、どのように修正するかを指摘します。 -このアプローチを用いて運用タスクを自動化することで、 -高度に[スケーラブル](/ja/scalability/)で信頼性の高いソフトウェアシステムを作成するのに役立ちます。 +システムは、インフラストラクチャとアプリケーションコンポーネントを継続的に測定し監視します。 +何か問題が発生した場合、システムはサイト信頼性エンジニアにいつ、どこで、どのように修正するかを指摘します。 +このアプローチを用いて運用タスクを自動化することで、高度に[スケーラブル](/ja/scalability/)で信頼性の高いソフトウェアシステムを作成するのに役立ちます。 diff --git a/content/ja/stateful-apps.md b/content/ja/stateful-apps.md index 7368e4db24..85654945fc 100644 --- a/content/ja/stateful-apps.md +++ b/content/ja/stateful-apps.md @@ -10,7 +10,7 @@ tags: ["基礎", "アプリケーション", "プロパティ"] 今日、私たちが使用するほとんどのアプリケーションは少なくとも部分的にステートフルです。 しかし、クラウドネイティブ環境では、ステートフルアプリは難しいです。 -これは、[クラウドネイティブアプリ](/ja/cloud-native-apps)が非常に動的だからです。 +これは、[クラウドネイティブアプリ](/ja/cloud-native-apps/)が非常に動的だからです。 これらはスケーリング、再起動、別の場所への移動が可能ですが、それでもそのステートにアクセスできる必要があります。 そのため、ステートフルアプリには、データベースのようにどこからでもアクセス可能な何らかのストレージが必要です。 diff --git a/content/ja/tightly-coupled-architectures.md b/content/ja/tightly-coupled-architecture.md similarity index 74% rename from content/ja/tightly-coupled-architectures.md rename to content/ja/tightly-coupled-architecture.md index 69e15388c3..a25b35e2d3 100644 --- a/content/ja/tightly-coupled-architectures.md +++ b/content/ja/tightly-coupled-architecture.md @@ -12,7 +12,5 @@ tags: ["基礎", "アーキテクチャ", "プロパティ"] また、しばしば構成要素を協調してロールアウトする必要が生じるため、開発者の生産性に対する足かせとなる可能性があります。 密結合なアプリケーションアーキテクチャはかなり古典的なアプリケーション構築方法です。 -[マイクロサービス](/ja/microservices/)開発のベストプラクティス全てには必ずしも整合しませんが、 -密結合アーキテクチャは特定の場合に有用です。 -密結合アーキテクチャでの開発は、実装がより簡潔で早くなる傾向があり、 -[モノリシックアプリケーション](/ja/monolithic-apps/)とよく似て初期開発サイクルを加速させる可能性があります。 +[マイクロサービス](/ja/microservices-architecture/)開発のベストプラクティス全てには必ずしも整合しませんが、密結合アーキテクチャは特定の場合に有用です。 +密結合アーキテクチャでの開発は、実装がより簡潔で早くなる傾向があり、[モノリシックアプリケーション](/ja/monolithic-apps/)とよく似て初期開発サイクルを加速させる可能性があります。 diff --git a/content/ja/vertical-scaling.md b/content/ja/vertical-scaling.md index cdaa5b0ddd..ef02d070cc 100644 --- a/content/ja/vertical-scaling.md +++ b/content/ja/vertical-scaling.md @@ -2,22 +2,27 @@ title: 垂直スケーリング status: Completed category: コンセプト -tags: ["インフラストラクチャー", "", ""] +tags: ["インフラストラクチャ", "", ""] --- 垂直スケーリング(「スケールアップおよびスケールダウン」とも呼ばれる)は、個別の[ノード](/ja/nodes/)にCPUとメモリを追加することでシステムの処理能力を強化する方法です。 -例えば、4GB RAMのコンピュータを持っていて、その容量を16GB RAMに増やしたい場合、垂直スケーリングすることは、16GB RAMシステムに切り替えることを意味します。(別のスケーリングアプローチについては、[水平スケーリング](/ja/horizontal-scaling/)を参照してください。) +例えば、4GB RAMのコンピューターを持っていて、その容量を16GB RAMに増やしたい場合、垂直スケーリングすることは、16GB RAMシステムに切り替えることを意味します。 +(別のスケーリングアプローチについては、[水平スケーリング](/ja/horizontal-scaling/)を参照してください。) ## 解決すべき問題はなんですか -アプリケーションへの需要が現在のアプリケーションインスタンスの処理能力を超えると、システムに処理能力を強化する方法が必要です。既存のノードにさらなる計算リソースを追加する(垂直スケーリング)か、システムにより多くのノードを追加する(水平スケーリング)ことができます。[スケーラビリティ](/ja/scalability/)は、競争力、効率、評判、品質に貢献します。 +アプリケーションへの需要が現在のアプリケーションインスタンスの処理能力を超えると、システムに処理能力を強化する方法が必要です。 +既存のノードにさらなる計算リソースを追加する(垂直スケーリング)か、システムにより多くのノードを追加する(水平スケーリング)ことができます。 +[スケーラビリティ](/ja/scalability/)は、競争力、効率、評判、品質に貢献します。 ## どのように役に立つのでしょうか 垂直スケーリングは、アプリケーションのコードを変更せずにサーバーの処理能力を変更することができます。 -一方で、水平スケーリングの場合、アプリケーションがスケールするために複製可能でなければなりません。コードの変更が必要になる可能性もあります。 +一方で、水平スケーリングの場合、アプリケーションがスケールするために複製可能でなければなりません。 +コードの変更が必要になる可能性もあります。 垂直スケーリングは、計算リソースを追加することで既存のアプリケーションの処理能力を強化し、アプリケーションがより多くのリクエストを処理し、より多くの作業を同時に行うことを可能にします。 ## 関連する用語はありますか + * [水平スケーリング](/ja/horizontal-scaling/) -* [オートスケーリング](/ja/auto-scaling/) \ No newline at end of file +* [オートスケーリング](/ja/auto-scaling/) diff --git a/content/ja/virtual-machine.md b/content/ja/virtual-machine.md index 134c8cd9f9..776ac92c76 100644 --- a/content/ja/virtual-machine.md +++ b/content/ja/virtual-machine.md @@ -2,17 +2,23 @@ title: 仮想マシン status: Completed category: テクノロジー -tags: ["基礎", "インフラストラクチャー", ""] +tags: ["基礎", "インフラストラクチャ", ""] --- -仮想マシン（VM）とは、特定のハードウェアに縛られないコンピューターとそのオペレーティングシステムのことです。VMは、1台の物理コンピューターを複数の仮想コンピューターに分割する[仮想化](/ja/virtualization/)に依存しています。この分割は、組織やインフラプロバイダーに、下層のハードウェアに影響を与えることなく、VMを簡単に作成、破棄することを可能にします。 +仮想マシン（VM）とは、特定のハードウェアに縛られないコンピューターとそのオペレーティングシステムのことです。 +VMは、1台の物理コンピューターを複数の仮想コンピューターに分割する[仮想化](/ja/virtualization/)に依存しています。 +この分割は、組織やインフラプロバイダーに、下層のハードウェアに影響を与えることなく、VMを簡単に作成、破棄することを可能にします。 ## 解決すべき問題はなんですか -仮想マシンは仮想化を利用しています。[ベアメタル](/ja/bare-metal-machine/)マシンは単一のオペレーティングシステムに縛られているので、マシンのリソースをどれだけ使えるかはある程度制限されます。また、オペレーティングシステムも単一の物理マシンに縛られているので、その可用性はハードウェアに直結します。物理マシンがメンテナンスやハードウェア故障によりオフラインになると、オペレーティングシステムもオフラインになります。 +仮想マシンは仮想化を利用しています。[ベアメタル](/ja/bare-metal-machine/)マシンは単一のオペレーティングシステムに縛られているので、マシンのリソースをどれだけ使えるかはある程度制限されます。また、オペレーティングシステムも単一の物理マシンに縛られているので、その可用性はハードウェアに直結します。 +物理マシンがメンテナンスやハードウェア故障によりオフラインになると、オペレーティングシステムもオフラインになります。 ## どのように役に立つのでしょうか オペレーティングシステムと物理マシンとの直接的な関係を取り除くことで、プロビジョニングの時間やハードウェア利用率、弾力性といったベアメタルマシンが抱えるいくつかの問題を解決することができます。 -新しいハードウェアの購入やインストール、あるいはそれをサポートするための設定が必要ないため、新しいコンピューターのプロビジョニングの時間が劇的に短縮されます。VMは、1台の物理マシン上に複数の仮想マシンを配置することで、既存の物理ハードウェアリソースをより有効に活用できます。特定の物理マシンに縛られないため、VMは物理マシンよりも耐障害性に優れています。物理マシンがオフラインになる必要がある場合、その上で稼働しているVMを、ほとんどない、あるいは全く停止時間なしで別のマシンに移動させることができます。 +新しいハードウェアの購入やインストール、あるいはそれをサポートするための設定が必要ないため、新しいコンピューターのプロビジョニングの時間が劇的に短縮されます。 +VMは、1台の物理マシン上に複数の仮想マシンを配置することで、既存の物理ハードウェアリソースをより有効に活用できます。 +特定の物理マシンに縛られないため、VMは物理マシンよりも耐障害性に優れています。 +物理マシンがオフラインになる必要がある場合、その上で稼働しているVMを、ほとんどない、あるいは全く停止時間なしで別のマシンに移動させることができます。 diff --git a/content/ja/virtualization.md b/content/ja/virtualization.md index e4a6af4c1a..782838fa04 100644 --- a/content/ja/virtualization.md +++ b/content/ja/virtualization.md @@ -2,7 +2,7 @@ title: 仮想化 status: completed category: テクノロジー -tags: ["基礎", "インフラストラクチャー", "方法論"] +tags: ["基礎", "インフラストラクチャ", "方法論"] --- クラウドネイティブコンピューティングにおける仮想化とは、 @@ -13,12 +13,10 @@ tags: ["基礎", "インフラストラクチャー", "方法論"] [クラウドコンピューティング](/ja/cloud-computing/)は主に仮想化技術の恩恵を受け提供されています。 例えば、AWSで作成し使用できる「コンピューター」は実際のところはVMです。 - ## 解決すべき問題はなんですか 仮想化によって、我々は多くの課題に対処することができます。 -例えば、仮想化によって同じ物理的なハードウェア上により多くのアプリケーションを互いに隔離しつつ動かすことができるので、 -セキュリティを保ったまま物理マシンの使用率を改善することができます。 +例えば、仮想化によって同じ物理的なハードウェア上により多くのアプリケーションを互いに隔離しつつ動かすことができるので、セキュリティを保ったまま物理マシンの使用率を改善することができます。 ## どのように役に立つのでしょうか diff --git a/content/ja/zero-trust-architecture.md b/content/ja/zero-trust-architecture.md index 03eaebbda5..f8cc5db2d7 100644 --- a/content/ja/zero-trust-architecture.md +++ b/content/ja/zero-trust-architecture.md @@ -6,19 +6,15 @@ tags: ["セキュリティ", "", ""] --- ゼロトラストアーキテクチャは、ITシステムの設計と実装において信頼を完全に取り除くアプローチを推奨します。 -その核心の原則は「決して信頼せず、常に検証する」であり、 -デバイスやシステムは、システムの他のコンポーネントと通信する際に常に事前に自分自身を検証します。 +その核心の原則は「決して信頼せず、常に検証する」であり、デバイスやシステムは、システムの他のコンポーネントと通信する際に常に事前に自分自身を検証します。 今日の多くのネットワークは、企業ネットワークの信頼された境界内にあるため、システムやデバイスは互いに自由に通信することができます。 -ゼロトラストアーキテクチャは、ネットワークの境界内にあっても、 -システム内のコンポーネントは通信する前に検証しなければならないという正反対のアプローチを取ります。 +ゼロトラストアーキテクチャは、ネットワークの境界内にあっても、システム内のコンポーネントは通信する前に検証しなければならないという正反対のアプローチを取ります。 ## 解決すべき問題はなんですか -伝統的な信頼ベースのアプローチでは、企業ネットワークの境界内に存在するシステムやデバイスに対して、 -信頼があるため問題がないという前提があります。 +伝統的な信頼ベースのアプローチでは、企業ネットワークの境界内に存在するシステムやデバイスに対して、信頼があるため問題がないという前提があります。 しかし、ゼロトラストアーキテクチャは、その信頼が脆弱性になると認識しています。 -攻撃者が信頼されたデバイスへのアクセスを獲得した場合、 -そのデバイスに与えられている信頼のレベルとアクセスに依存してシステムは攻撃に対して脆弱になります。 +攻撃者が信頼されたデバイスへのアクセスを獲得した場合、そのデバイスに与えられている信頼のレベルとアクセスに依存してシステムは攻撃に対して脆弱になります。 なぜなら、攻撃者は信頼されたネットワークの境界内におり、システム内を横断的に移動することができるからです。 ゼロトラストアーキテクチャでは、信頼が取り除かれるため攻撃者はシステム内をさらに横断する前に検証を強いられ、結果としてアタックサーフェスが縮小します。 diff --git a/content/pt-br/application-programming-interface.md b/content/pt-br/application-programming-interface.md index 23c368521a..9ab8df28da 100644 --- a/content/pt-br/application-programming-interface.md +++ b/content/pt-br/application-programming-interface.md @@ -13,4 +13,4 @@ Uma API (interface de programação de aplicações - do inglês: applications p ## Como isso ajuda -APIs permitem que programas de computador ou aplicações interajam e compartilhem informações de uma maneira definida e compreensível. Elas são os blocos de construção para as aplicações modernas e fornecem aos desenvolvedores uma maneira de integrar aplicações. Sempre que você ouvir sobre [microsserviços](/microservices/) você pode inferir que eles interagem uns com os outros por meio de uma API. +APIs permitem que programas de computador ou aplicações interajam e compartilhem informações de uma maneira definida e compreensível. Elas são os blocos de construção para as aplicações modernas e fornecem aos desenvolvedores uma maneira de integrar aplicações. Sempre que você ouvir sobre [microsserviços](/pt-br/microservices-architecture/) você pode inferir que eles interagem uns com os outros por meio de uma API. diff --git a/content/pt-br/chaos-engineering.md b/content/pt-br/chaos-engineering.md new file mode 100644 index 0000000000..270e86030d --- /dev/null +++ b/content/pt-br/chaos-engineering.md @@ -0,0 +1,16 @@ +--- +title: Engenharia do Caos +status: Completed +category: conceito +tags: ["metodologia"] +--- + +A Engenharia do Caos, ou CE, é a disciplina de experimentar em um [sistema distribuído](/pt-br/distributed-systems/) em produção para construir confiança na capacidade do sistema de resistir a condições turbulentas e inesperadas. + +## Problema relacionado + +As práticas de [SRE](/pt-br/site-reliability-engineering/) e [DevOps](/pt-br/devops/)focam em técnicas para aumentar a resiliência e [confiabilidade](/pt-br/reliability/) do produto. A capacidade de um sistema de tolerar falhas enquanto garante qualidade de serviço adequada é tipicamente um requisito de desenvolvimento de software. Existem vários aspectos envolvidos que podem levar a falhas de um aplicativo, como infraestrutura, plataforma ou outras partes móveis de um aplicativo baseado em [microserviços](/pt-br/microservices-architecture/). A implantação frequente de novos recursos no ambiente de produção pode aumentar a probabilidade de tempo de inatividade e um incidente crítico — com consequências consideráveis para o negócio. + +## Como ajuda + +A engenharia do caos é uma técnica para atender aos requisitos de resiliência. É usada para alcançar resiliência contra falhas de infraestrutura, plataforma e aplicativo. Engenheiros de caos usam experimentos de caos para injetar proativamente falhas aleatórias e verificar se um aplicativo, infraestrutura ou plataforma pode se recuperar automaticamente e se a falha não pode afetar perceptivelmente os clientes. Os experimentos de caos visam descobrir pontos cegos (por exemplo, técnicas de monitoramento ou de escalonamento automático) e melhorar a comunicação entre equipes durante incidentes críticos. Essa abordagem ajuda a aumentar a resiliência e a confiança da equipe em sistemas complexos, especialmente em produção. diff --git a/content/pt-br/cloud-native-apps.md b/content/pt-br/cloud-native-apps.md index c1c2223e7d..902b393834 100644 --- a/content/pt-br/cloud-native-apps.md +++ b/content/pt-br/cloud-native-apps.md @@ -1,5 +1,5 @@ --- -title: Aplicações Nativas em Nuvem +title: Aplicações Nativas em Nuvem status: Completed category: conceito tags: ["aplicação", "fundamento", ""] @@ -9,7 +9,7 @@ As aplicações nativas em nuvem são projetadas especificamente para aproveitar ## Problema relacionado -Tradicionalmente, os ambientes locais forneciam recursos de computação de maneira bastante personalizada. Cada datacenter tinha seus serviços [fortemente acoplados](/tightly-coupled-architectures/) aos aplicativos e a ambientes específicos, muitas vezes contando com o provisionamento manual para infraestrutura, como serviços e [máquinas virtuais](/pt-br/virtual-machine/). Isso, por sua vez, restringiu os desenvolvedores e seus aplicativos a esse datacenter específico. Aplicativos que não foram projetados para a nuvem não poderiam aproveitar os recursos de resiliência e dimensionamento de um ambiente em nuvem. Por exemplo, os aplicativos que exigem intervenção manual para iniciar corretamente não podem escalar automaticamente, nem podem ser reiniciados automaticamente em caso de falha. +Tradicionalmente, os ambientes locais forneciam recursos de computação de maneira bastante personalizada. Cada datacenter tinha seus serviços [fortemente acoplados](/pt-br/tightly-coupled-architecture/) aos aplicativos e a ambientes específicos, muitas vezes contando com o provisionamento manual para infraestrutura, como serviços e [máquinas virtuais](/pt-br/virtual-machine/). Isso, por sua vez, restringiu os desenvolvedores e seus aplicativos a esse datacenter específico. Aplicativos que não foram projetados para a nuvem não poderiam aproveitar os recursos de resiliência e dimensionamento de um ambiente em nuvem. Por exemplo, os aplicativos que exigem intervenção manual para iniciar corretamente não podem escalar automaticamente, nem podem ser reiniciados automaticamente em caso de falha. ## Como isso ajuda diff --git a/content/pt-br/devops.md b/content/pt-br/devops.md index cb00ae1fab..a37c0f7ff3 100644 --- a/content/pt-br/devops.md +++ b/content/pt-br/devops.md @@ -10,7 +10,7 @@ Esta metodologia vai além da implementação de um conjunto de tecnologias, req ## Problema relacionado -Tradicionalmente, em organizações complexas com [aplicações monolíticas](/monolithic-apps/) de [alto acoplamento](/tightly-coupled-architectures/), o trabalho era geralmente fragmentado entre vários grupos, levando a um alto número de transferências de responsabilidade e longo prazo nas entregas. Cada vez que um componente ou atualização estava pronto, era disponibilizado em uma fila para o próximo time. Como cada pessoa trabalhava em apenas uma pequena parte do projeto, esta abordagem levava a uma falha de responsabilidade no processo como um todo. O objetivo dos times era transferir o trabalho para o próximo time, e não entregar a funcionalidade correta ao cliente - uma clara falta de alinhamento nas prioridades. +Tradicionalmente, em organizações complexas com [aplicações monolíticas](/pt-br/monolithic-apps/) de [alto acoplamento](/pt-br/tightly-coupled-architecture/), o trabalho era geralmente fragmentado entre vários grupos, levando a um alto número de transferências de responsabilidade e longo prazo nas entregas. Cada vez que um componente ou atualização estava pronto, era disponibilizado em uma fila para o próximo time. Como cada pessoa trabalhava em apenas uma pequena parte do projeto, esta abordagem levava a uma falha de responsabilidade no processo como um todo. O objetivo dos times era transferir o trabalho para o próximo time, e não entregar a funcionalidade correta ao cliente - uma clara falta de alinhamento nas prioridades. No momento em que o código finalmente entrava em produção, depois de passar por diversos desenvolvedores e esperando em várias filas, tornava-se difícil rastrear a origem do problema se o código não funcionava. DevOps vira essa abordagem de cabeça para baixo. diff --git a/content/pt-br/distributed-apps.md b/content/pt-br/distributed-apps.md index c109881c7b..46ac94f0ad 100644 --- a/content/pt-br/distributed-apps.md +++ b/content/pt-br/distributed-apps.md @@ -5,20 +5,20 @@ category: conceito tags: ["arquitetura", "", ""] --- -Uma aplicação distribuída é uma aplicação em que a funcionalidade é dividida em várias partes menores independentes. -As aplicações distribuídas geralmente são compostas de [microsserviços](/microservices/) individuais -que lidam com diferentes preocupações dentro da aplicação mais ampla. +Uma aplicação distribuída é uma aplicação em que a funcionalidade é dividida em várias partes menores independentes. +As aplicações distribuídas geralmente são compostas de [microsserviços](/pt-br/microservices-architecture/) individuais +que lidam com diferentes preocupações dentro da aplicação mais ampla. Em um ambiente nativo da nuvem, os componentes individuais normalmente são executados como [contêineres](/pt-br/container/) em um [cluster](/pt-br/cluster/). -## Problema relacionado +## Problema relacionado -A execução de uma aplicação em um único computador representa um único ponto de falha — se esse computador falhar, a aplicação ficará indisponível. -As aplicações distribuídas são frequentemente contrárias as aplicações [monolíticas](/monolithic-apps/). -Uma aplicação monolítica pode ser mais difícil de escalar, pois os vários componentes não podem ser redimensionados de forma independente. +A execução de uma aplicação em um único computador representa um único ponto de falha — se esse computador falhar, a aplicação ficará indisponível. +As aplicações distribuídas são frequentemente contrárias as aplicações [monolíticas](/pt-br/monolithic-apps/). +Uma aplicação monolítica pode ser mais difícil de escalar, pois os vários componentes não podem ser redimensionados de forma independente. Eles também podem reduzir a velocidade do desenvolvimento à medida que crescem, porque mais desenvolvedores precisam trabalhar em uma base de código compartilhada, que não tem necessariamente limites bem definidos. ## Como isso ajuda -Ao dividir uma aplicação em diferentes partes e executá-las em muitos lugares, o sistema geral pode tolerar mais falhas. -Isso também permite que uma aplicação aproveite os recursos de dimensionamento não disponíveis para uma única instância, ou seja, a capacidade de [escalar horizontalmente](/horizontal-scaling/). +Ao dividir uma aplicação em diferentes partes e executá-las em muitos lugares, o sistema geral pode tolerar mais falhas. +Isso também permite que uma aplicação aproveite os recursos de dimensionamento não disponíveis para uma única instância, ou seja, a capacidade de [escalar horizontalmente](/horizontal-scaling/). Isso, no entanto, tem um custo: maior complexidade e sobrecarga operacional — agora você está executando muitos componentes em vez de uma aplicação. diff --git a/content/pt-br/distributed-systems.md b/content/pt-br/distributed-systems.md index a35af56fd7..0922fef25a 100644 --- a/content/pt-br/distributed-systems.md +++ b/content/pt-br/distributed-systems.md @@ -7,11 +7,11 @@ tags: ["arquitetura", "", ""] Um sistema distribuído é uma coleção de elementos de computação autônomos conectados por uma rede que aparece para os usuários como um único sistema coerente. Geralmente referidos como [nós](/pt-br/nodes/), esses componentes podem ser dispositivos de hardware (por exemplo, computadores, telefones móveis) ou processos de software. Os nós são programados para alcançar um objetivo comum e, para colaborar, eles trocam mensagens pela rede. -## Problema relacionado +## Problema relacionado Hoje, inúmeras aplicações modernas são tão grandes que precisariam de supercomputadores para operar. Pense no Gmail ou Netflix. Nenhum computador único é suficientemente poderoso para hospedar toda a aplicação. Ao conectar vários computadores, o poder computacional se torna praticamente ilimitado. Sem a computação distribuída, muitas das aplicações das quais dependemos hoje não seriam possíveis. -Tradicionalmente, os sistemas seriam [escalados](/pt-br/scalability) verticalmente. Isso significa adicionar mais CPU ou memória a uma máquina individual. A [escalabilidade vertical](/pt-br/vertical-scaling/) é demorada, requer tempo de inatividade e atinge seu limite rapidamente. +Tradicionalmente, os sistemas seriam [escalados](/pt-br/scalability/) verticalmente. Isso significa adicionar mais CPU ou memória a uma máquina individual. A [escalabilidade vertical](/pt-br/vertical-scaling/) é demorada, requer tempo de inatividade e atinge seu limite rapidamente. ## Como ajuda diff --git a/content/pt-br/edge-computing.md b/content/pt-br/edge-computing.md new file mode 100644 index 0000000000..adb9b8b806 --- /dev/null +++ b/content/pt-br/edge-computing.md @@ -0,0 +1,19 @@ +--- +title: Edge Computing +status: Completed +category: Tecnologia +--- + +A computação de borda é um modelo de [sistema distribuído](/pt-br/distributed-systems/) que transfere parte da capacidade de armazenamento e processamento do [*data center*](/pt-br/data-center/) principal para as fontes de dados. +Os dados coletados são processados localmente (por exemplo, em uma fábrica, em uma loja ou em toda uma cidade) em vez de serem enviados para um *data center* centralizado para processamento e análise. +Essas unidades ou dispositivos de processamento locais representam a borda do sistema, enquanto o *data center* é o seu centro. +A saída processada na borda é então enviada de volta para o *data center* principal para processamento adicional. +Exemplos de computação de borda incluem dispositivos vestíveis ou computadores que analisam o fluxo de tráfego. + +## Problema relacionado + +Na última década, vimos um aumento significativo nos dispositivos de borda (por exemplo, telefones celulares, relógios inteligentes ou sensores). Em alguns casos, o processamento de dados em tempo real não é apenas um recurso agradável de se ter, mas vital. Pense nos carros autônomos. Agora imagine se os dados dos sensores do carro tivessem que ser transferidos para um *data center* para processamento antes de serem enviados de volta para o veículo para que ele possa reagir adequadamente. A latência de rede inerente poderia ser fatal. Embora este seja um exemplo extremo, a maioria dos usuários não gostaria de usar um dispositivo inteligente que não pode fornecer feedback instantâneo. + +## Como ajuda + +Como descrito acima, para que os dispositivos de borda sejam úteis, eles devem fazer pelo menos parte do processamento e análise localmente para fornecer feedback quase em tempo real aos usuários. Isso é alcançado transferindo alguns recursos de armazenamento e processamento do *data center* para onde os dados são gerados: o dispositivo de borda. Os dados processados e não processados são posteriormente enviados para o *data center* para processamento e armazenamento adicionais. Em resumo, eficiência e velocidade são os principais impulsionadores da computação de borda. diff --git a/content/pt-br/function-as-a-service.md b/content/pt-br/function-as-a-service.md index b2d45c1a18..ee4db6ccc5 100644 --- a/content/pt-br/function-as-a-service.md +++ b/content/pt-br/function-as-a-service.md @@ -5,7 +5,7 @@ category: Tecnologia tags: ["infraestrutura", "", ""] --- -Função como um Serviço, (FaaS - Function as a Service ), é um tipo de [serviço](/pt-br/service/) de [computação em nuvem](/pt-br/cloud-computing/) [sem servidor](/pt-br/serverless/) que permite a execução de código em resposta a eventos sem manter a complexa infraestrutura normalmente associado à criação e lançamento de aplicações de [microsserviços](/microservices/). +Função como um Serviço, (FaaS - Function as a Service ), é um tipo de [serviço](/pt-br/service/) de [computação em nuvem](/pt-br/cloud-computing/) [sem servidor](/pt-br/serverless/) que permite a execução de código em resposta a eventos sem manter a complexa infraestrutura normalmente associado à criação e lançamento de aplicações de [microsserviços](/pt-br/microservices-architecture/). Com FaaS, os usuários gerenciam apenas funções e dados enquanto o provedor de nuvem gerencia a aplicação. Isso permite que os desenvolvedores obtenham as funções necessárias sem pagar pelos serviços quando o código não está em execução. diff --git a/content/pt-br/microservices.md b/content/pt-br/microservices-architecture.md similarity index 80% rename from content/pt-br/microservices.md rename to content/pt-br/microservices-architecture.md index d7f69152f2..09a529b862 100644 --- a/content/pt-br/microservices.md +++ b/content/pt-br/microservices-architecture.md @@ -5,26 +5,26 @@ category: conceito tags: ["arquitetura", "", ""] --- -Os microsserviços têm uma abordagem moderna para o desenvolvimento de aplicações que aproveita as tecnologias nativas da nuvem. -Embora as aplicações modernas, como a Netflix, pareçam ser uma única aplicação, elas são na verdade uma coleção de serviços menores - todos trabalhando em colaboração. -Por exemplo, uma única página que permite acessar, pesquisar e visualizar vídeos provavelmente é alimentada por serviços menores que lidam com um aspecto (por exemplo, pesquisa, autenticação e execução de visualizações no seu navegador). -Em resumo, os microsserviços referem-se a um padrão de arquitetura de aplicações geralmente contrária as [aplicações monolíticas](/monolithic-apps/). +Os microsserviços têm uma abordagem moderna para o desenvolvimento de aplicações que aproveita as tecnologias nativas da nuvem. +Embora as aplicações modernas, como a Netflix, pareçam ser uma única aplicação, elas são na verdade uma coleção de serviços menores - todos trabalhando em colaboração. +Por exemplo, uma única página que permite acessar, pesquisar e visualizar vídeos provavelmente é alimentada por serviços menores que lidam com um aspecto (por exemplo, pesquisa, autenticação e execução de visualizações no seu navegador). +Em resumo, os microsserviços referem-se a um padrão de arquitetura de aplicações geralmente contrária as [aplicações monolíticas](/pt-br/monolithic-apps/). ## Problema relacionado -Os microsserviços são uma resposta aos desafios colocados por aplicações monolíticas. -Geralmente, diferentes partes de uma aplicação precisarão ser dimensionadas separadamente. -Por exemplo, uma loja online terá mais visualizações de produtos do que a finalização da compra. -Isso significa que você precisará de mais cópias da funcionalidade de visualização do produto em execução do que a conclusão da compra. -Em uma aplicação monolítica, essa lógica não pode ser implantada individualmente. -Se você não conseguir dimensionar a funcionalidade do produto individualmente, terá que duplicar toda a aplicação com todos os outros componentes que não precisa - um uso ineficiente de recursos. -As aplicações monolíticas também tornam mais fácil para os desenvolvedores sucumbirem às armadilhas do projeto. -Como todo o código está em um só lugar, é mais fácil tornar esse [código bem acoplado](/pt-br/tightly-coupled-architectures/) e mais difícil de impor o princípio da separação de responsabilidades. +Os microsserviços são uma resposta aos desafios colocados por aplicações monolíticas. +Geralmente, diferentes partes de uma aplicação precisarão ser dimensionadas separadamente. +Por exemplo, uma loja online terá mais visualizações de produtos do que a finalização da compra. +Isso significa que você precisará de mais cópias da funcionalidade de visualização do produto em execução do que a conclusão da compra. +Em uma aplicação monolítica, essa lógica não pode ser implantada individualmente. +Se você não conseguir dimensionar a funcionalidade do produto individualmente, terá que duplicar toda a aplicação com todos os outros componentes que não precisa - um uso ineficiente de recursos. +As aplicações monolíticas também tornam mais fácil para os desenvolvedores sucumbirem às armadilhas do projeto. +Como todo o código está em um só lugar, é mais fácil tornar esse [código bem acoplado](/pt-br/tightly-coupled-architecture/) e mais difícil de impor o princípio da separação de responsabilidades. Os monólitos geralmente exigem que os desenvolvedores entendam toda a base de código antes que possam ser produtivos. ## Como isso ajuda -Separar a funcionalidade em diferentes microsserviços facilita a implantação, atualização e escala de forma independente. -Ao permitir que diferentes equipes se concentrem em sua própria e pequena parte de uma aplicação maior, você também torna mais fácil para elas trabalharem em suas aplicações sem afetar negativamente o resto da organização. -Embora os microsserviços resolvam muitos problemas, eles também criam sobrecarga operacional — as coisas que você precisa para implantar e acompanhar têm um aumento na ordem de grandeza ou mais. +Separar a funcionalidade em diferentes microsserviços facilita a implantação, atualização e escala de forma independente. +Ao permitir que diferentes equipes se concentrem em sua própria e pequena parte de uma aplicação maior, você também torna mais fácil para elas trabalharem em suas aplicações sem afetar negativamente o resto da organização. +Embora os microsserviços resolvam muitos problemas, eles também criam sobrecarga operacional — as coisas que você precisa para implantar e acompanhar têm um aumento na ordem de grandeza ou mais. Muitas [tecnologias nativas da nuvem](/pt-br/cloud-native-tech/) visam tornar os microsserviços mais fáceis de implantar e gerenciar. diff --git a/content/pt-br/monolithic-apps.md b/content/pt-br/monolithic-apps.md index 141d80d60d..6a93f65a0f 100644 --- a/content/pt-br/monolithic-apps.md +++ b/content/pt-br/monolithic-apps.md @@ -5,19 +5,19 @@ category: conceito tags: ["arquitetura", "", ""] --- -Uma aplicação monolítica contém todas as funcionalidades em um único programa. -Este é muitas vezes o lugar mais simples e fácil para começar ao fazer uma aplicação. -No entanto, uma vez que a aplicação cresce em complexidade, os monólitos podem se tornar difíceis de manter. +Uma aplicação monolítica contém todas as funcionalidades em um único programa. +Este é muitas vezes o lugar mais simples e fácil para começar ao fazer uma aplicação. +No entanto, uma vez que a aplicação cresce em complexidade, os monólitos podem se tornar difíceis de manter. Com mais desenvolvedores trabalhando na mesma base de código, a probabilidade de mudanças conflitantes e a necessidade de comunicação interpessoal entre desenvolvedores aumenta. ## Problema relacionado -A conversão de uma aplicação em [microsserviços](/microservices/) aumenta sua sobrecarga operacional — existe mais coisas para testar, implantar e executar. +A conversão de uma aplicação em [microsserviços](/pt-br/microservices-architecture/) aumenta sua sobrecarga operacional — existe mais coisas para testar, implantar e executar. No início do ciclo de vida de um produto, pode ser vantajoso adiar essa complexidade e construir uma aplicação monolítica até que o produto seja determinado como bem-sucedido. ## Como isso ajuda -Um monólito bem projetado pode manter os princípios *lean*, sendo a maneira mais simples de colocar uma aplicação em funcionamento. -Quando o valor comercial da aplicação monolítica prova ser bem-sucedido, ela pode ser decomposta em microsserviços. -Desenvolver uma aplicação com base em microsserviços antes que ela tenha se mostrado valiosa pode ser um gasto prematuro de esforço de engenharia. +Um monólito bem projetado pode manter os princípios *lean*, sendo a maneira mais simples de colocar uma aplicação em funcionamento. +Quando o valor comercial da aplicação monolítica prova ser bem-sucedido, ela pode ser decomposta em microsserviços. +Desenvolver uma aplicação com base em microsserviços antes que ela tenha se mostrado valiosa pode ser um gasto prematuro de esforço de engenharia. Se a aplicação não produzir valor, esse esforço se torna desperdiçado. diff --git a/content/pt-br/platform-as-a-service.md b/content/pt-br/platform-as-a-service.md index e834ad317f..41ea94a7b2 100644 --- a/content/pt-br/platform-as-a-service.md +++ b/content/pt-br/platform-as-a-service.md @@ -9,7 +9,7 @@ Plataforma como serviço, ou PaaS, é uma plataforma externa para equipes de des ## Problema relacionado -Para aproveitar os padrões nativos da nuvem, como [microsserviços](/microservices/) ou [aplicações distribuídas](/distributed-apps/), as equipes de operações e os desenvolvedores precisam ser capazes de descarregar uma grande quantidade de operações e trabalho de manutenção. Isso inclui tarefas como provisionamento de infraestrutura, manipulação de [descoberta de serviço](/service-discovery/), balanceamento de carga e [escalabilidade](/pt-br/scalability/) de aplicações. +Para aproveitar os padrões nativos da nuvem, como [microsserviços](/pt-br/microservices-architecture/) ou [aplicações distribuídas](/distributed-apps/), as equipes de operações e os desenvolvedores precisam ser capazes de descarregar uma grande quantidade de operações e trabalho de manutenção. Isso inclui tarefas como provisionamento de infraestrutura, manipulação de [descoberta de serviço](/service-discovery/), balanceamento de carga e [escalabilidade](/pt-br/scalability/) de aplicações. ## Como isso ajuda diff --git a/content/pt-br/service.md b/content/pt-br/service.md index 3e727142ee..fa0a6dbde5 100644 --- a/content/pt-br/service.md +++ b/content/pt-br/service.md @@ -5,4 +5,4 @@ category: conceito tags: ["aplicação", "fundamento", ""] --- -Observe que, em Tecnologia da Informação, o termo serviço tem vários significados. Vamos nos concentrar na mais tradicional: serviço como no microsserviço. Como ou mesmo se os serviços diferem dos microsserviços é sutil, e pessoas diferentes podem ter opiniões diferentes. Para uma definição de alto nível, vamos tratá-los da mesma forma. Consulte a definição [microsserviço](/microservices/). +Observe que, em Tecnologia da Informação, o termo serviço tem vários significados. Vamos nos concentrar na mais tradicional: serviço como no microsserviço. Como ou mesmo se os serviços diferem dos microsserviços é sutil, e pessoas diferentes podem ter opiniões diferentes. Para uma definição de alto nível, vamos tratá-los da mesma forma. Consulte a definição [microsserviço](/pt-br/microservices-architecture/). diff --git a/content/pt-br/stateless-apps.md b/content/pt-br/stateless-apps.md index d8470edcfb..fa24c704b6 100644 --- a/content/pt-br/stateless-apps.md +++ b/content/pt-br/stateless-apps.md @@ -9,7 +9,7 @@ Um aplicação stateless não salva nenhum dado de sessão do cliente no servido ## Problema relacionado -Aplicações stateless resolvem o problema da resiliência, porque diferente dos pods em um [cluster](/pt-br/cluster/) podem funcionar de forma independente, com várias requisições chegando a elas ao mesmo tempo. Se houver um problema, você pode reiniciar facilmente a aplicação e ela retornará ao seu estado inicial com pouco ou nenhum tempo de inatividade. Como tal, os benefícios das aplicações stateless incluem a resiliência, a elasticidade e a alta disponibilidade. No entanto, a maioria das aplicações que usamos hoje é pelo menos parcialmente [stateful](/pt-br/stateful_apps/), pois armazenam coisas como preferências e configurações para melhorar a experiência do usuário. +Aplicações stateless resolvem o problema da resiliência, porque diferente dos pods em um [cluster](/pt-br/cluster/) podem funcionar de forma independente, com várias requisições chegando a elas ao mesmo tempo. Se houver um problema, você pode reiniciar facilmente a aplicação e ela retornará ao seu estado inicial com pouco ou nenhum tempo de inatividade. Como tal, os benefícios das aplicações stateless incluem a resiliência, a elasticidade e a alta disponibilidade. No entanto, a maioria das aplicações que usamos hoje é pelo menos parcialmente [stateful](/pt-br/stateful-apps/), pois armazenam coisas como preferências e configurações para melhorar a experiência do usuário. ## Como isso ajuda diff --git a/content/pt-br/tightly-coupled-architectures.md b/content/pt-br/tightly-coupled-architecture.md similarity index 75% rename from content/pt-br/tightly-coupled-architectures.md rename to content/pt-br/tightly-coupled-architecture.md index 476b105c0c..73b425ec5d 100644 --- a/content/pt-br/tightly-coupled-architectures.md +++ b/content/pt-br/tightly-coupled-architecture.md @@ -7,5 +7,4 @@ tags: ["fundamento", "arquitetura", "propriedade"] Arquitetura acoplada é um estilo de arquitetura em que vários componentes da aplicação são interdependentes (o paradigma oposto de [arquiteturas desacopladas](/loosely-coupled-architecture/)). Isso significa que uma mudança em um componente provavelmente afetará outros componentes. Geralmente é mais fácil de implementar do que estilos de arquitetura desacopladas, mas pode deixar um sistema mais vulnerável a falhas em cascata. Esse estilo de arquitetura também tende a exigir implementações coordenadas de componentes, o que pode se tornar um obstáculo à produtividade do desenvolvedor. -Arquiteturas acopladas de aplicativos são uma maneira bastante tradicional de criar aplicações. Embora não sejam necessariamente consistentes com todas as melhores práticas de desenvolvimento de [microsserviços](/microservices/), elas podem ser úteis em circunstâncias específicas. Elas tendem a ser mais rápidas e simples de implementar e, assim como [aplicações monolíticas](/monolithic-apps/), elas podem acelerar o ciclo de desenvolvimento inicial. - +Arquiteturas acopladas de aplicativos são uma maneira bastante tradicional de criar aplicações. Embora não sejam necessariamente consistentes com todas as melhores práticas de desenvolvimento de [microsserviços](/pt-br/microservices-architecture/), elas podem ser úteis em circunstâncias específicas. Elas tendem a ser mais rápidas e simples de implementar e, assim como [aplicações monolíticas](/pt-br/monolithic-apps/), elas podem acelerar o ciclo de desenvolvimento inicial. diff --git a/layouts/_default/search.html b/layouts/_default/search.html index 2772fa47ff..9c850d56f7 100644 --- a/layouts/_default/search.html +++ b/layouts/_default/search.html @@ -55,7 +55,7 @@

{{ .Title }}

var newUrl = baseUrl + "?" + urlParams.toString(); // Update the browser history (optional) - window.history.pushState({}, null, newUrl); + history.replaceState(null, '', newUrl); } diff --git a/layouts/partials/head.html b/layouts/partials/head.html index ae4f0b2673..851dbe3e63 100644 --- a/layouts/partials/head.html +++ b/layouts/partials/head.html @@ -30,6 +30,7 @@ {{- template "_internal/twitter_cards.html" . -}} + {{ partialCached "head-css.html" . "asdf" }}