From 5309af66b8db9b7c82cb1ce75c84ad70c716872e Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Tue, 31 May 2022 16:39:32 +0900 Subject: [PATCH 1/4] [all] MD022: Insert empty lines before and after the header lines Signed-off-by: Jihoon Seo --- content/bn/_TEMPLATE.md | 3 +++ content/bn/_index.md | 1 - content/bn/abstraction.md | 2 -- content/bn/agile_software_development.md | 3 +++ content/bn/application_programming_interface.md | 3 +++ content/bn/cloud_computing.md | 3 +++ content/bn/cloud_native_tech.md | 6 ------ content/bn/cluster.md | 7 ------- content/bn/container.md | 1 - content/bn/contribute/_index.md | 16 +++++++++------- content/bn/contributor-ladder/_index.md | 3 +-- content/bn/devops.md | 3 +++ content/bn/software_as_a_service.md | 2 -- content/bn/style-guide/_index.md | 5 ----- content/de/_TEMPLATE.md | 3 +++ content/en/_TEMPLATE.md | 3 --- content/en/_index.md | 2 +- content/en/abstraction.md | 2 -- content/en/agile_software_development.md | 3 +++ content/en/api_gateway.md | 6 +++--- content/en/application_programming_interface.md | 4 +++- content/en/auto_scaling.md | 1 + content/en/bare_metal_machine.md | 1 - content/en/blue_green_deployment.md | 4 +++- content/en/canary_deployment.md | 5 +++-- content/en/chaos_engineering.md | 3 +++ content/en/cloud_computing.md | 5 +++-- content/en/cloud_native_apps.md | 5 +++-- content/en/cluster.md | 2 -- content/en/container.md | 3 +++ content/en/containers_as_a_service.md | 3 +++ content/en/continuous_delivery.md | 6 ++++-- content/en/continuous_deployment.md | 1 + content/en/continuous_integration.md | 4 ++++ content/en/contribute/_index.md | 3 +-- content/en/debugging.md | 3 +++ content/en/devops.md | 4 +++- content/en/devsecops.md | 5 +++-- content/en/distributed_apps.md | 1 - content/en/distributed_systems.md | 5 +++-- content/en/firewall.md | 3 +++ content/en/function_as_a_service.md | 3 +++ content/en/horizontal_scaling.md | 1 + content/en/immutable_infrastructure.md | 2 -- content/en/infrastructure_as_code.md | 4 +++- content/en/kubernetes.md | 5 +++-- content/en/load_balancer.md | 5 ++++- content/en/loosely_coupled_architecture.md | 1 - .../en/mTLS (Mutual Transport Layer Security).md | 3 +++ content/en/managed_services.md | 3 +++ content/en/microservices.md | 5 +++-- content/en/monolithic_apps.md | 3 +++ content/en/nodes.md | 2 -- content/en/observability.md | 1 - content/en/platform_as_a_service.md | 4 +++- content/en/policy_as_code.md | 3 +++ content/en/reliability.md | 1 - content/en/scalability.md | 2 -- content/en/security_chaos_engineering.md | 3 +++ content/en/serverless.md | 3 +++ content/en/service.md | 1 - content/en/service_discovery.md | 3 +++ content/en/service_mesh.md | 3 +++ content/en/service_proxy.md | 4 +++- content/en/shift_left.md | 3 +++ content/en/site_reliability_engineering.md | 3 +++ content/en/vertical_scaling.md | 1 + content/en/virtualization.md | 3 +++ content/en/zero_trust_architecture.md | 3 +++ content/es/.gitkeep | 0 content/es/contribute/_index.md | 2 +- content/hi/_TEMPLATE.md | 3 +++ content/hi/agile_software_development.md | 3 +++ content/hi/auto_scaling.md | 2 -- content/hi/canary_deployment.md | 1 + content/hi/container.md | 3 +++ content/hi/continuous_delivery.md | 5 +++-- content/hi/continuous_integration.md | 2 +- content/hi/contribute/_index.md | 13 ++++++++----- content/hi/contributor-ladder/_index.md | 2 +- content/hi/devops.md | 3 +++ content/hi/style-guide/_index.md | 1 - content/it/.gitkeep | 0 content/it/_index.md | 4 +--- content/it/agile_software_development.md | 4 +++- content/it/cluster.md | 2 +- content/it/contribute/_index.md | 13 ++++++++----- content/it/devops.md | 5 ++++- content/it/infrastructure_as_code.md | 3 +++ content/it/managed_services.md | 3 +++ content/it/microservices.md | 5 ++++- content/it/platform_as_a_service.md | 3 +++ content/it/site_reliability_engineering.md | 3 +++ content/it/style-guide/_index.md | 4 +--- content/it/virtual_machine.md | 3 +++ content/ko/_index.md | 3 +-- content/ko/cloud_computing.md | 5 +++-- content/ko/container.md | 3 +++ content/ko/contribute/_index.md | 10 +++++++++- content/ko/contributor-ladder/_index.md | 2 +- content/ko/microservices.md | 3 +++ content/ko/monolithic_apps.md | 3 +++ content/ko/style-guide/_index.md | 1 - content/ko/virtual_machine.md | 3 +++ content/pt-br/.gitkeep | 0 content/pt-br/_index.md | 6 ++++-- content/pt-br/abstraction.md | 1 + content/pt-br/agile_software_development.md | 3 +++ content/pt-br/auto_scaling.md | 1 - content/pt-br/canary_deployment.md | 5 ++++- content/pt-br/client_server_architecture.md | 2 +- content/pt-br/cloud_native_apps.md | 5 ++++- content/pt-br/cluster.md | 5 +++-- content/pt-br/container.md | 3 +++ content/pt-br/containerization.md | 3 +++ content/pt-br/continuous_delivery.md | 3 +++ content/pt-br/continuous_integration.md | 3 +++ content/pt-br/contribute/_index.md | 13 ++++++++----- content/pt-br/contributor-ladder/_index.md | 1 - content/pt-br/devops.md | 3 +++ content/pt-br/style-guide/_index.md | 3 ++- content/zh-cn/_index.md | 1 - content/zh-cn/container-image.md | 1 - content/zh-cn/container.md | 1 - content/zh-cn/continuous_delivery.md | 1 - content/zh-cn/contribute/_index.md | 11 ++++++++++- content/zh-cn/devops.md | 3 +++ content/zh-cn/load_balancer.md | 3 +++ content/zh-cn/reliability.md | 1 - content/zh-cn/serverless.md | 3 +++ content/zh-cn/style-guide/_index.md | 2 +- content/zh-cn/zero_trust_architecture.md | 2 +- 132 files changed, 301 insertions(+), 139 deletions(-) delete mode 100644 content/es/.gitkeep delete mode 100644 content/it/.gitkeep delete mode 100644 content/pt-br/.gitkeep diff --git a/content/bn/_TEMPLATE.md b/content/bn/_TEMPLATE.md index 6f5179ca9f..534be65b3a 100644 --- a/content/bn/_TEMPLATE.md +++ b/content/bn/_TEMPLATE.md @@ -5,10 +5,13 @@ category: ধারণা --- ## এটা কি + এটি ধারণার একটি দ্রুত সারাংশ । ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে + এটি যে সমস্যার সমাধান করছে তার কয়েকটি লাইন। ## এটা কিভাবে সাহায্য করে + জিনিসটি কীভাবে সমস্যার সমাধান করে তার কয়েকটি লাইন। diff --git a/content/bn/_index.md b/content/bn/_index.md index 5528518089..19c1ba1196 100644 --- a/content/bn/_index.md +++ b/content/bn/_index.md @@ -24,4 +24,3 @@ title: "ক্লাউড নেটিভ শব্দকোষ" ## লাইসেন্স সমস্ত কোড অবদান Apache 2.0 লাইসেন্সের অধীনে। ডকুমেন্টেশন CC BY 4.0 এর অধীনে বিতরণ করা হয়। - diff --git a/content/bn/abstraction.md b/content/bn/abstraction.md index 31414c42c0..dd39686354 100644 --- a/content/bn/abstraction.md +++ b/content/bn/abstraction.md @@ -7,5 +7,3 @@ category: বৈশিষ্ট্য কম্পিউটিং এর প্রেক্ষাপটে, অ্যাবস্ট্রাকশন অথবা বিমূর্ততা হল এক ধরনের উপস্থাপনা যেখানে সাধারণ ব্যবহারকারী এবং [সেবা](https://glossary.cncf.io/service/) ভোগকারীদের (কম্পিউটার প্রোগ্রাম অথবা মানুষ) কাছ থেকে সিস্টেমের জটিল এবং অপ্রয়োজনীয় বিষয়গুলি লুকিয়ে রাখা হয়, এভাবে সিস্টেমকে খুব সিম্পল ভাবে উপস্থাপন করা হয় ফলে সিস্টেমকে বুঝতেও সুবিধা হয়। একটি ভালো উদাহরণ হল আপনার ল্যাপটপের অপারেটিং সিস্টেম (OS)। এটি আপনার কম্পিউটার কিভাবে কাজ করে তার সমস্ত বিবরণ বিমূর্ত করে। আপনার সিপিইউ মেমোরি অথবা প্রোগ্রামগুলোকে কিভাবে পরিচালনা করতে হয় সে সম্পর্কে কিছু জানার দরকার নেই, আপনি শুধু আপনার অপারেটিং সিস্টেম চালান এবং আপনার OS নিজেই এই জটিল বিষয়গুলো পরিচালনা করে। OS কিভাবে কাজগুলো হ্যান্ডেল করে করে তা আপনার জানার দরকার নেই এবং সমস্ত বিবরণ এই OS "পর্দা" বা বিমূর্ততার পিছনে লুকানো রয়েছে। সিস্টেমে সাধারণত একাধিক অ্যাবস্ট্রাকশন স্তর থাকে। এটি সিস্টেম ডেভেলপমেন্ট কে অনেক সহজ করে তোলে। প্রোগ্রামিং এর সময় ডেভলপাররা নির্দিষ্ট অ্যাবস্ট্রাকশন স্তরের সাথে সামঞ্জস্য রেখে সব কিছু তৈরি করে এবং অন্যান্য অন্তর্নিহিত সুনির্দিষ্ট বিষয়গুলো নিয়ে তাদের আর চিন্তা করতে হয় না যা খুবই জটিল হতে পারত। কোন কিছু যদি কোনো নির্দিষ্ট অ্যাবস্ট্রাকশন স্তরের সাথে কাজ করে তবে তা সিস্টেমের সাথে কাজ করবে — নিচের স্তরগুলো তে যাই থাকুক না কেন। - - diff --git a/content/bn/agile_software_development.md b/content/bn/agile_software_development.md index 1e30148837..c410523b0c 100644 --- a/content/bn/agile_software_development.md +++ b/content/bn/agile_software_development.md @@ -5,10 +5,13 @@ category: ধারণা --- ## এটা কি + এটি একটি অনুশীলনের সেট যা পুনরাবৃত্তিমূলক বিকাশ চক্র এবং স্ব-সংগঠিত দলের উপর জোর স্থাপন করে। জলপ্রপাতের মতো প্রজেক্টগুলির বিপরীতে যেখানে একটি প্রজেক্টের সুবিধা কেবল প্রজেক্টের শেষেই পাওয়া যায়, অ্যাজাইল সফটওয়্যার ডেভলপমেন্ট দৃষ্টিপাত করে কিভাবে একটি ক্রমাগত, ক্রমবর্ধমান মূল্য সরবরাহ করতে পারা যায় এবং দৃষ্টিপাত করে যেন প্রক্রিয়াটি নিজের বিবর্তনীয় উন্নতির উপর দৃষ্টি নিবদ্ধ করে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে + একটি সফটওয়্যার প্রজেক্টে স্টেকহোল্ডারদের সকল চাহিদাকে সংজ্ঞায়িত করা, যোগাযোগ করা এবং বোঝা খুবই কঠিন প্রায় অসম্ভবই বলা চলে। তবুও, গ্রাহকরা প্রত্যাশা করেন যেন তাদের সফটওয়্যার প্রজেক্টগুলি সময়মতো, ভাল মানের, বাজেটে এবং সুযোগে বিতরণ করা হোক। এর চক্রাকার প্রকৃতির কারণে অ্যাজাইল সফটওয়্যার ডেভলপমেন্ট (Agile software development) জলপ্রপাতের মতো কৌশলগুলির বিপরীতে প্রয়োজনীয়তার অবিচ্ছিন্ন অভিযোজন এবং অন্যান্য সমস্ত পরিস্থিতির সমস্যার সমাধানকে দ্রুত অভিযোজন করতে সক্ষম করে। ## এটা কিভাবে সাহায্য করে + অ্যাজাইল সফটওয়্যার ডেভলপমেন্টে প্রথাগত (জলপ্রপাতের মতো) কৌশলগুলির সমস্ত ধাপ রয়েছে, যেমন প্রয়োজনীয় প্রকৌশল, পরিকল্পনা, বাস্তবায়ন, পর্যালোচনা, পরীক্ষা এবং বিতরণ। সবচেয়ে বড় পার্থক্য হল যে একটি সফটওয়্যার প্রজেক্টের পুরো সময়কালটি পুনরাবৃত্তিতে বিভক্ত করা হয়, যার প্রতিটিতে পূর্বের সমস্ত পর্যায় থাকে। প্রতিটি পুনরাবৃত্তির পরে, তৈরি করা মান গ্রাহকের সাথে পর্যালোচনা করা যেতে পারে এবং প্রয়োজনীয়তাগুলি শেষ লক্ষ্যের দিকে সামঞ্জস্য করা যেতে পারে। এরই সাথে ডেভলপমেন্ট দল পূর্বের ঘটনার উপর দৃষ্টি দিয়ে নির্ধারণ করে যে প্রক্রিয়াকে উন্নত করার জন্য কি সকল ধাপ গ্রহণ করতে হবে। diff --git a/content/bn/application_programming_interface.md b/content/bn/application_programming_interface.md index 21b65593f4..88343bb682 100644 --- a/content/bn/application_programming_interface.md +++ b/content/bn/application_programming_interface.md @@ -5,10 +5,13 @@ category: প্রযুক্তি --- ## এটা কি + একটি API হল কম্পিউটার প্রোগ্রামগুলির একে অপরের সাথে যোগাযোগ করার একটি উপায়। মানুষ যেমন একটি ওয়েব পৃষ্ঠার মাধ্যমে একটি ওয়েবসাইটের সাথে যোগাযোগ করে, তেমনি একটি API কম্পিউটার প্রোগ্রামগুলিকে একে অপরের সাথে যোগাযোগ করতে দেয়। মানুষের মিথস্ক্রিয়া থেকে ভিন্ন, API-গুলির সীমাবদ্ধতা রয়েছে তাদের থেকে কী জিজ্ঞাসা করা যায় এবং কী করা যায় না। ইন্টারঅ্যাকশনের সীমাবদ্ধতা প্রোগ্রামগুলির মধ্যে স্থিতিশীল এবং কার্যকরী যোগাযোগ তৈরি করতে সহায়তা করে। ## এটি যেই সমস্যাটি দৃষ্টিপাত করে + অ্যাপ্লিকেশনগুলি আরও জটিল হয়ে উঠলে, ছোট কোড পরিবর্তনগুলি অন্যান্য কার্যকারিতার উপর কঠোর প্রভাব ফেলতে পারে। অ্যাপ্লিকেশনগুলিকে তাদের কার্যকারিতার জন্য একটি মডুলার পদ্ধতি অবলম্বন করতে হবে যদি তারা একই সাথে বৃদ্ধি এবং স্থিতিশীলতা বজায় রাখতে পারে। API ছাড়া, অ্যাপ্লিকেশনগুলির মধ্যে মিথস্ক্রিয়া করার জন্য একটি কাঠামোর অভাব রয়েছে। একটি শেয়ার্ড ফ্রেমওয়ার্ক ছাড়া, অ্যাপ্লিকেশনগুলির জন্য [স্কেল(scale)](/scalability/) এবং একীভূত করা চ্যালেঞ্জিং। ## এটা কিভাবে সাহায্য করে + APIগুলি কম্পিউটার প্রোগ্রাম বা অ্যাপ্লিকেশনগুলিকে একটি সংজ্ঞায়িত এবং বোধগম্য পদ্ধতিতে তথ্য আদান-প্রদান এবং আদান-প্রদান করার অনুমতি দেয়। তারা আধুনিক অ্যাপ্লিকেশনের জন্য বিল্ডিং ব্লক এবং তারা ডেভেলপারদের অ্যাপ্লিকেশন একত্রিত করার একটি উপায় প্রদান করে থাকে। যখনই আপনি [মাইক্রসার্ভিস(microservices)](/microservices/) একসাথে কাজ করার কথা শুনেন, আপনি অনুমান করতে পারেন যে তারা একটি API এর মাধ্যমে ইন্টারঅ্যাক্ট করে। diff --git a/content/bn/cloud_computing.md b/content/bn/cloud_computing.md index d9583ae6c9..362105c418 100644 --- a/content/bn/cloud_computing.md +++ b/content/bn/cloud_computing.md @@ -5,10 +5,13 @@ category: ধারণা --- ## এটা কি + ক্লাউড কম্পিউটিং হল এমন একটি মডেল যা ইন্টারনেটের মাধ্যমে চাহিদা অনুযায়ী CPU, নেটওয়ার্ক এবং ডিস্ক ক্ষমতার মতো গণনা বিষয়ক কাজ(compute) করার সংস্থান সরবরাহ করে। ক্লাউড কম্পিউটিং এর মাধ্যমে ব্যবহারকারীরা নিজেদের শারীরিক অবস্থান থেকে ক্লাউডে থেকে প্রবেশ করতে পারে এবং প্রয়োজন অনুযায়ী ব্যবহার করতে পারে। ক্লাউড সুবিধা প্রদানকারী সংস্থাসমূহ যেমন AWS, GCP, Azure, DigitalOcean এবং অন্যান্য সকলেই তৃতীয় পক্ষ অর্থাৎ ব্যবহারকারীদের একাধিক ভৌগলিক অবস্থান থেকে ভাড়ার মাধ্যমে কম্পিউটিং বিষয়ক কাজ করার সুবিধা প্রদান করে। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে + যেকোনো সংস্থা প্রথাগতভাবে তাদের কম্পিউটিং কার্যকারিতা চাহিদা বৃদ্ধির সাথে তাল মিলিয়ে নিজেদের সম্প্রসারণের সময় প্রধানত দুই ধরনের সমস্যার সম্মুখীন হয়।এমতাবস্থায় তারা হয় তাদের মূল সার্ভারকে আয়ত্ত, সমর্থন, ডিজাইন এবং অর্থ প্রদান করে নিজেরা হোস্ট করার সুবিধা ভোগ করে অথবা এ সকল সুবিধা সম্প্রসারণ এবং পর্যবেক্ষণ করে থাকে। ক্লাউড কম্পিউটিং তাদের ব্যবহারকারী সংস্থাগুলিকে তাদের কম্পিউটিং চাহিদার কিছু অংশ অন্য সংস্থাকে আউটসোর্স করতে দেয়। ## এটা কিভাবে সাহায্য করে + ক্লাউড সুবিধা প্রদানকারী সংস্থাসমূহ তাদের ব্যবহারকারী সংস্থাগুলিকে অর্থের বিনিময়ে চাহিদা অনুযায়ী কম্পিউট রিসোর্স ভাড়া করার এবং ব্যবহার করার ক্ষমতা প্রদান করে। এটি দুটি প্রধান উদ্ভাবনের অনুমতি দেয়: সংস্থাগুলি ভৌত অবকাঠামোতে অর্থ বা সংস্থান ব্যয় না করে এবং সময় অপচয় না করে নতুন কিছু চেষ্টা করতে পারে এবং তারা প্রয়োজন এবং চাহিদা অনুযায়ী [স্কেল(scale)](/scalability/) করতে পারে। ক্লাউড সুবিধা প্রদানকারী সংস্থাসমূহ তাদের ব্যবহারকারী সংস্থাগুলিকে প্রয়োজন অনুযায়ী বা সর্বনিম্ন প্রয়োজন মোতাবেক পরিকাঠামো ব্যবহার করতে দেয়। diff --git a/content/bn/cloud_native_tech.md b/content/bn/cloud_native_tech.md index 6f16f2e910..eb5cc311ed 100644 --- a/content/bn/cloud_native_tech.md +++ b/content/bn/cloud_native_tech.md @@ -15,9 +15,3 @@ category: ধারণা ## এটা কিভাবে সাহায্য করে যদিও প্রতিটি প্রযুক্তি একটি খুব নির্দিষ্ট সমস্যার সমাধান করে, একটি গোষ্ঠী হিসাবে, ক্লাউড নেটিভ প্রযুক্তিগুলি স্থিতিস্থাপক, পরিচালনাযোগ্য এবং পর্যবেক্ষণযোগ্য শিথিলভাবে সংযুক্ত সিস্টেমগুলিকে সক্ষম করে। দৃঢ় অটোমেশনের সাথে মিলিত, তারা প্রকৌশলীদেরকে ন্যূনতম পরিশ্রমের সাথে ঘন ঘন এবং অনুমানযোগ্যভাবে উচ্চ-প্রভাব পরিবর্তন করতে দেয়। ক্লাউড নেটিভ সিস্টেমের পছন্দসই বৈশিষ্ট্য ক্লাউড নেটিভ স্ট্যাকের সাথে অর্জন করা সহজ। - - - - - - diff --git a/content/bn/cluster.md b/content/bn/cluster.md index 8db1fdc597..4b2847c117 100644 --- a/content/bn/cluster.md +++ b/content/bn/cluster.md @@ -8,17 +8,10 @@ category: ধারণা একটি ক্লাস্টার হল কম্পিউটার বা অ্যাপ্লিকেশনগুলির একটি গ্রুপ যা একটি সাধারণ লক্ষ্যে একসাথে কাজ করে। ক্লাউড নেটিভ কম্পিউটিং প্রসঙ্গে, শব্দটি প্রায়শই কুবারনেটে প্রয়োগ করা হয়। একটি Kubernetes ক্লাস্টার হল পরিষেবাগুলির একটি সেট (বা কাজের চাপ) যা তাদের নিজস্ব পাত্রে চলে, সাধারণত বিভিন্ন মেশিনে। এই সমস্ত [কন্টেইনারাইজড(Containerized)](/containerization/) পরিষেবাগুলির সংগ্রহ, একটি নেটওয়ার্কের মাধ্যমে সংযুক্ত, একটি ক্লাস্টার প্রতিনিধিত্ব করে। - - ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে একটি একক কম্পিউটারে চলা সফ্টওয়্যার ব্যর্থতার একটি একক পয়েন্ট উপস্থাপন করে — যদি সেই কম্পিউটারটি ক্র্যাশ হয়ে যায়, বা কেউ দুর্ঘটনাক্রমে পাওয়ার কেবলটি আনপ্লাগ করে, তবে কিছু ব্যবসা-সংক্রান্ত সমস্যা সিস্টেম অফলাইনে নেওয়া হতে পারে। এই কারণেই আধুনিক সফ্টওয়্যারগুলি সাধারণত [ডিস্ট্রিবিউটেড অ্যাপ্লিকেশন(Distributed application)](/distributed_apps/) হিসাবে তৈরি করা হয়, ক্লাস্টার হিসাবে একসাথে গ্রুপ করা হয়। - ## এটা কিভাবে সাহায্য করে ক্লাস্টারড, বিতরণ করা অ্যাপ্লিকেশনগুলি একাধিক মেশিন জুড়ে চলে, একটি একক বিন্দু ব্যর্থতা দূর করে। কিন্তু বিতরণ সিস্টেম নির্মাণ সত্যিই কঠিন. প্রকৃতপক্ষে, এটি তার নিজের অধিকারে একটি কম্পিউটার বিজ্ঞান শৃঙ্খলা। বিশ্বব্যাপী সিস্টেমের প্রয়োজনীয়তা এবং বছরের পর বছর ট্রায়াল এবং ত্রুটি একটি নতুন ধরণের প্রযুক্তিগত স্ট্যাকের বিকাশের দিকে পরিচালিত করে: [ক্লাউড নেটিভ টেকনোলজি(Cloud Native Technology)](/bn/cloud_native_tech/)। এই নতুন প্রযুক্তিগুলি হল বিল্ডিং ব্লক যা বিতরণ করা সিস্টেমগুলির পরিচালনা এবং নির্মাণকে সহজ করে তোলে। - - - - diff --git a/content/bn/container.md b/content/bn/container.md index f95c8561f7..507d21301a 100644 --- a/content/bn/container.md +++ b/content/bn/container.md @@ -16,5 +16,4 @@ category: প্রযুক্তি কনটেইনারগুলি একই অপারেটিং সিস্টেম এবং এর মেশিন সংস্থানগুলি ভাগ করে, অপারেটিং সিস্টেমের সংস্থান ওভারহেড ছড়িয়ে দেয় এবং শারীরিক মেশিনের দক্ষ ব্যবহার তৈরি করে। এই ক্ষমতা শুধুমাত্র সম্ভব কারণ কন্টেইনারগুলি সাধারণত একে অপরের সাথে যোগাযোগ করতে সক্ষম হতে সীমিত। এটি একই শারীরিক মেশিনে আরও অনেক অ্যাপ্লিকেশন চালানোর অনুমতি দেয়। - তবে সীমাবদ্ধতা আছে। যেহেতু কন্টেইনারগুলি একই অপারেটিং সিস্টেম শেয়ার করে, তাই প্রক্রিয়াগুলি বিকল্পগুলির তুলনায় কম নিরাপদ বলে বিবেচিত হতে পারে৷ ধারকদেরও ভাগ করা সম্পদের সীমা প্রয়োজন। সম্পদের নিশ্চয়তা দিতে, প্রশাসকদের অবশ্যই মেমরি এবং সিপিইউ ব্যবহার সীমাবদ্ধ এবং সীমিত করতে হবে যাতে অন্যান্য অ্যাপ্লিকেশনগুলি খারাপভাবে কাজ না করে। diff --git a/content/bn/contribute/_index.md b/content/bn/contribute/_index.md index d99f7177dc..b51f5aa1a9 100644 --- a/content/bn/contribute/_index.md +++ b/content/bn/contribute/_index.md @@ -33,17 +33,18 @@ menu: ![একটি সমস্যা(issue) দাবি করা](/images/how-to/claiming-an-issue.png) - এছাড়াও, অনুগ্রহ করে CNCF Slack-এর [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) চ্যানেলে যোগ দিন এবং রক্ষণাবেক্ষণকারীদের জানান যে আপনি একটি নতুন শব্দের জন্য একটি সমস্যা উত্থাপন করেছেন (আদর্শভাবে) , ট্যাগ করুন _@Catherine Paganini_, _@jmo_, _@Seokho Son_, _@Jihoon Seo_, এবং/অথবা _@iamnoah_ যাতে তারা এটি মিস না করে)। মনে রাখবেন যে আপনি একবারে শুধুমাত্র একটি মেয়াদ দাবি করতে পারেন। আপনি যদি একাধিক শর্তে কাজ করতে চান, অনুগ্রহ করে পরেরটি দাবি করার আগে একটি শেষ করুন। -একবার তারা এটি আপনাকে বরাদ্দ করলে, আপনি এটিতে কাজ শুরু করতে পারেন। পরবর্তী ধাপগুলির জন্য, অনুগ্রহ করে [একটি নতুন শব্দ জমা দেওয়া (একটি পিআর তৈরি করা)] (#submitting-a-new-term) বিভাগটি পড়ুন। +একবার তারা এটি আপনাকে বরাদ্দ করলে, আপনি এটিতে কাজ শুরু করতে পারেন। পরবর্তী ধাপগুলির জন্য, অনুগ্রহ করে [একটি নতুন শব্দ জমা দেওয়া (একটি পিআর তৈরি করা)](#submitting-a-new-term) বিভাগটি পড়ুন। ## নতুন শর্তাবলী প্রস্তাব করুন {#propose-new-terms} + আপনি অন্যদের জন্য একটি নতুন শব্দ প্রস্তাব করতে পারেন বা নিজে একটি নতুন সংজ্ঞা তৈরি করতে পারেন৷ যেভাবেই হোক, আপনি একটি সমস্যা তৈরি করে শুরু করবেন। -যারা এখনও GitHub এর সাথে পরিচিত নন তাদের জন্য নীচে একটি ধাপে ধাপে নির্দেশিকা। **আপনি যদি একজন GitHub Pro** হন, তাহলে অনুগ্রহ করে *করুন* যাতে আপনি আমাদের ইস্যু টেমপ্লেট, উপযুক্ত নামকরণ প্রথা ব্যবহার করেন, স্ল্যাকের উপর একটি পিআর দাবি করেন (অন্যথায় আমরা এটি মিস করতে পারি), এবং কোথায় পাবেন তা নিশ্চিত করতে দ্রুত দেখুন ফাইল টেমপ্লেট। এবং অনুগ্রহ করে শুরু করার আগে [স্টাইল গাইড](/bn/style-guide/) পড়া নিশ্চিত করুন — ধন্যবাদ! +যারা এখনও GitHub এর সাথে পরিচিত নন তাদের জন্য নীচে একটি ধাপে ধাপে নির্দেশিকা। **আপনি যদি একজন GitHub Pro** হন, তাহলে অনুগ্রহ করে _করুন_ যাতে আপনি আমাদের ইস্যু টেমপ্লেট, উপযুক্ত নামকরণ প্রথা ব্যবহার করেন, স্ল্যাকের উপর একটি পিআর দাবি করেন (অন্যথায় আমরা এটি মিস করতে পারি), এবং কোথায় পাবেন তা নিশ্চিত করতে দ্রুত দেখুন ফাইল টেমপ্লেট। এবং অনুগ্রহ করে শুরু করার আগে [স্টাইল গাইড](/bn/style-guide/) পড়া নিশ্চিত করুন — ধন্যবাদ! ### একটি সমস্যা তৈরি করা {#creating-an-issue} + [Glossary GitHub repo](https://github.com/cncf/glossary/issues) সমস্যাগুলিতে যান এবং "নতুন সমস্যা" এ ক্লিক করুন। ![সমস্যা(issues)](/images/how-to/howto-01.png) @@ -54,8 +55,8 @@ menu: আপনি যে শব্দটি প্রস্তাব করছেন তা যোগ করুন, নীচের দুটি প্রশ্নের উত্তর দিন এবং "নতুন সমস্যা জমা দিন" টিপুন। আপনি যদি শুধু একটি নতুন শব্দ প্রস্তাব করেন, আপনি সম্পন্ন! এটিতে কাজ করতে, পরবর্তী পদক্ষেপগুলি অনুসরণ করুন৷ - ### আপনার সমস্যা এর পরবর্তী ধাপ {#triaging-your-issue} + এর পরে, রক্ষণাবেক্ষণকারীরা সমস্যাটি সমাধান করবে। এর অর্থ হল শব্দটি শব্দকোষের অংশ হওয়া উচিত কিনা তা তারা মূল্যায়ন করবে (দ্রষ্টব্য, প্রতিটি পদকে সংযুক্ত করা হবে না। শর্তাবলী প্রতিষ্ঠিত হওয়া উচিত এবং ব্যাপকভাবে ব্যবহৃত ক্লাউড নেটিভ টার্মস)। অনুগ্রহ করে রক্ষণাবেক্ষণকারীদের জানান যে আপনি স্ল্যাকে একটি মেয়াদ জমা দিয়েছেন কারণ তারা অন্যথায় এটি মিস করতে পারে। আদর্শভাবে, ট্যাগ করুন _@Catherine Paganini_, _@jmo_, _@Seokho Son_, _@Jihoon Seo_ অথবা _@iamnoah_। যদি শব্দটি অনুমোদিত হয় এবং আপনি এটিতে কাজ করতে চান তবে তারা এটি আপনাকে বরাদ্দ করবে। @@ -103,9 +104,11 @@ URL-এ শব্দের নাম যোগ করুন (কোনও ক্ ![prs](/images/how-to/howto-13.png) ## একটি বিদ্যমান টার্ম আপডেট করুন {#update-an-existing-term} + একটি বিদ্যমান শব্দ আপডেট করতে, আপনি হয় একটি সমস্যার মাধ্যমে একটি পরিবর্তনের পরামর্শ দিতে পারেন বা এগিয়ে যান এবং একটি পুল অনুরোধ (PR) জমা দিয়ে সরাসরি শব্দটি আপডেট করতে পারেন৷ ### একটি সমস্যার মাধ্যমে একটি পরিবর্তনের অনুরোধ করুন {#request-a-change-via-an-issue} + আপনি যদি একটি শব্দের সাথে একটি সমস্যা ফ্ল্যাগ করতে চান কিন্তু কীভাবে এটি নিজেই ঠিক করতে চান না জানেন, তাহলে "সমস্যা প্রতিবেদন করুন" এ ক্লিক করুন৷ ![রিপোর্ট সমস্যা](/images/how-to/howto-14.png) @@ -115,6 +118,7 @@ URL-এ শব্দের নাম যোগ করুন (কোনও ক্ ![সমস্যার জমা দিন](/images/how-to/howto-15.png) ### একটি টার্ম সরাসরি আপডেট করুন {#update-a-term-directly} + একটি শব্দ সরাসরি পরিবর্তন করতে, "এই পৃষ্ঠাটি সম্পাদনা করুন" এ যান। ![এই পৃষ্ঠাটি সম্পাদনা করুন](/images/how-to/howto-16.png) @@ -122,7 +126,5 @@ URL-এ শব্দের নাম যোগ করুন (কোনও ক্ এটি শব্দের GitHub পৃষ্ঠা খুলবে। আপনার পরিবর্তন করুন এবং একটি পিআর জমা দিন। বিশদ বিবরণের জন্য অনুগ্রহ করে উপরে "একটি নতুন শব্দ জমা দেওয়া" দেখুন (মার্কডাউন সম্পর্কে কথা বলা বিভাগে যান)। ## শব্দকোষ অনুবাদ করতে সাহায্য করুন {#help-translate-the-glossary} -আপনার মাতৃভাষায় শব্দকোষটি অনুবাদ করতে সাহায্য করতে, অনুগ্রহ করে CNCF Slack-এ #glossary-localizations চ্যানেলে যোগ দিন এবং আমাদের জানান। আপনি হয় একটি বিদ্যমান দলে যোগ দিতে পারেন বা একটি নতুন দল তৈরি করতে পারেন (এটি কী নেয় তা দেখতে, চেক আউট করুন বা [স্থানীয়করণ গাইড](https://github.com/cncf/glossary/blob/main/LOCALIZATION.md))। এছাড়াও আমাদের মাসিক শব্দকোষ ওয়ার্কিং গ্রুপ মিটিং যোগদান করুন. আপনি [CNCF ক্যালেন্ডার](https://www.cncf.io/calendar/) এ মিটিংয়ের বিশদ বিবরণ পেতে পারেন। আমরা সেখানে আপনার সাথে দেখা করার জন্য উন্মুখ! - - +আপনার মাতৃভাষায় শব্দকোষটি অনুবাদ করতে সাহায্য করতে, অনুগ্রহ করে CNCF Slack-এ #glossary-localizations চ্যানেলে যোগ দিন এবং আমাদের জানান। আপনি হয় একটি বিদ্যমান দলে যোগ দিতে পারেন বা একটি নতুন দল তৈরি করতে পারেন (এটি কী নেয় তা দেখতে, চেক আউট করুন বা [স্থানীয়করণ গাইড](https://github.com/cncf/glossary/blob/main/LOCALIZATION.md))। এছাড়াও আমাদের মাসিক শব্দকোষ ওয়ার্কিং গ্রুপ মিটিং যোগদান করুন. আপনি [CNCF ক্যালেন্ডার](https://www.cncf.io/calendar/) এ মিটিংয়ের বিশদ বিবরণ পেতে পারেন। আমরা সেখানে আপনার সাথে দেখা করার জন্য উন্মুখ! diff --git a/content/bn/contributor-ladder/_index.md b/content/bn/contributor-ladder/_index.md index fe63be2d2c..b714aa1c7e 100644 --- a/content/bn/contributor-ladder/_index.md +++ b/content/bn/contributor-ladder/_index.md @@ -8,7 +8,6 @@ menu: স্বাগতম এখানে! 👋 CNCF ক্লাউড নেটিভ শব্দকোষ প্রকল্পে অবদান রাখার জন্য আপনার আগ্রহের জন্য ধন্যবাদ। আপনি নতুন শর্তাবলীতে অবদান রাখুন, শব্দকোষকে আপনার স্থানীয় ভাষায় স্থানীয়করণে সহায়তা করুন বা অন্যদের শুরু করতে সাহায্য করতে চান, এই সম্প্রদায়ের সক্রিয় সদস্য হওয়ার অনেক উপায় রয়েছে। এই ডক প্রকল্পের মধ্যে বিভিন্ন অবদানকারীর ভূমিকা এবং তাদের সাথে আসা দায়িত্ব ও সুযোগ-সুবিধার রূপরেখা দেয়। - ## 1. অবদানকারী (Contributors) শব্দকোষ সবার জন্য। প্রকল্পে অবদান রাখার মাধ্যমে যে কেউ একটি শব্দকোষ অবদানকারী হতে পারে। সমস্ত অবদানকারীরা [CNCF কোড অফ কন্ডাক্ট](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) অনুসরণ করবে বলে আশা করা হচ্ছে। @@ -43,7 +42,6 @@ menu: 2) কঠিন লেখার দক্ষতা সহ অনুমোদনকারী, 3) অনুমোদনকারী যারা উভয় ক্ষেত্রেই দক্ষ। - **প্রযুক্তিগত অনুমোদনকারী**: শক্তিশালী প্রযুক্তিগত পটভূমির ব্যক্তিরা ইংরেজি লেখার দক্ষতা ছাড়াই অনুমোদনকারী হতে পারেন। যাইহোক, যদি তারা প্রযুক্তিগত যোগ্যতার ভিত্তিতে একটি PR অনুমোদন করে, তবে তাদের অবশ্যই নিশ্চিত করতে হবে যে এটি একজন (সম্পাদক) অনুমোদনকারী দ্বারা পর্যালোচনা করা হয়েছে। **সম্পাদক**: সম্পাদকরা শর্তাবলী প্রুফরিড করে এবং নিশ্চিত করে যে সেগুলি শৈলী গাইড অনুসারে সহজ ভাষায় ব্যাখ্যা করা হয়েছে। যদি একটি শব্দ ব্যাপকভাবে সম্পাদিত হয়, তাহলে অর্থ পরিবর্তন করা হয়নি তা নিশ্চিত করতে সম্পাদককে অবশ্যই একটি প্রযুক্তিগত অনুমোদনকারীকে এটি পুনরায় পর্যালোচনা করার জন্য অনুরোধ করতে হবে। @@ -86,6 +84,7 @@ menu: ### একজন কমিউনিটি ম্যানেজার হন যে কেউ একজন শব্দকোষ সম্প্রদায় ব্যবস্থাপক হতে পারেন। কমিউনিটি ম্যানেজারদের অবশ্যই অবদান এবং স্থানীয়করণ প্রক্রিয়া সম্পর্কে একটি দৃঢ় ধারণা থাকতে হবে এবং অন্যদের মিথস্ক্রিয়া এবং সাহায্য করতে উপভোগ করতে হবে। কমিউনিটি ম্যানেজার হওয়ার জন্য, বিদ্যমান রক্ষণাবেক্ষণকারীদের আগ্রহ প্রকাশ করে শুরু করুন। অনবোর্ডিং/ট্রায়াল পিরিয়ডের পরে, রক্ষণাবেক্ষণকারীরা সিদ্ধান্ত নেবেন যে পারফরম্যান্সের উপর ভিত্তি করে কমিউনিটি ম্যানেজারের মর্যাদা দেওয়া হবে কিনা। + ## অনৈচ্ছিক অপসারণ দায়িত্ব এবং প্রয়োজনীয়তা পূরণ না হলে অবদানকারীর অনৈচ্ছিক অপসারণ ঘটে। এর মধ্যে বারবার নিষ্ক্রিয়তার নিদর্শন, নিষ্ক্রিয়তার বর্ধিত সময়কাল এবং/অথবা আচরণবিধি লঙ্ঘন অন্তর্ভুক্ত থাকতে পারে। এই প্রক্রিয়াটি গুরুত্বপূর্ণ কারণ এটি সম্প্রদায় এবং এর বিতরণযোগ্য জিনিসগুলিকে রক্ষা করে এবং নতুন অবদানকারীদের জন্য পদক্ষেপ নেওয়ার সুযোগও খুলে দেয়। diff --git a/content/bn/devops.md b/content/bn/devops.md index 05a1c23343..700b9d9119 100644 --- a/content/bn/devops.md +++ b/content/bn/devops.md @@ -5,12 +5,15 @@ category: ধারণা --- ## এটা কি + ডেভওপস হল একটি পদ্ধতি যেখানে দলগুলি অ্যাপ্লিকেশন ডেভেলপমেন্ট থেকে প্রোডাকশন অপারেশন পর্যন্ত সম্পূর্ণ প্রক্রিয়ার পরিচালনা করে থাকে। এটি সাধারণ প্রযুক্তি থেকে উচ্চ পর্যায় রয়েছে এবং সাধারণ ধরন থেকে আলাদা হয়। ডেভওপস প্রকৌশলীদের দলদের জন্য আহ্বান করে যারা ছোট উপাদানগুলিতে কাজ করে (একটি সম্পূর্ণ বৈশিষ্ট্যের বিপরীতে), হ্যান্ডঅফগুলি হ্রাস করে – যা সাধারণ ভুলের কারন। ## এটি যেই সমস্যাটি নির্দেশ করে + ঐতিহ্যগতভাবে, জটিল সংস্থা [শক্তভাবে মিলিত](/tightly_coupled_architectures/) ও [মনোলিথিক অ্যাপস](/monolithic_apps/) এর কাজ সাধারণত একাধিক দলের মধ্যে খণ্ডিত ছিল । এটি অসংখ্য হ্যান্ডঅফ এবং দীর্ঘ পরবর্তী সময় নেয়। প্রতিবার যখনই একটি উপাদান বা আপডেট প্রস্তুত ছিল, এটি পরবর্তী দলের জন্য একটি সারিতে স্থাপন করা হয়েছিল। যেহেতু ব্যক্তিরা কেবলমাত্র প্রকল্পের একটি ছোট অংশে কাজ করেছিল, এই পদ্ধতির ফলে মালিকানার অভাব দেখা দেয়। তাদের লক্ষ্য ছিল পরবর্তী দলের কাছে কাজটি পৌঁছে দেওয়া, গ্রাহকের কাছে সঠিক কার্যকারিতা সরবরাহ না করা যাকে অগ্রাধিকারগুলির একটি স্পষ্ট বিভ্রান্তি হিসেবে বলা যায়। কোডটি শেষ পর্যন্ত আসার সময় পর্যন্ত, এটি এত বেশি ডেভেলপারের মধ্য দিয়ে গিয়েছিল, এত সারিতে অপেক্ষা করেছিল যে কোডটি কাজ না করলে সমস্যার উৎস খুঁজে বের করা কঠিন ছিল। ডেভওপস এই পদ্ধতিকে উল্টো করে দেয়। ## এটা কিভাবে সাহায্য করে + একটি অ্যাপ্লিকেশনের সমগ্র জীবনচক্রের মালিক একটি দল থাকার ফলে হ্যান্ডঅফগুলি ন্যূনতম হয়, উৎপাদনে মোতায়েন করার সময় ঝুঁকি হ্রাস পায়, কোডের গুণমান আরও ভাল হয় কারণ দলগুলি আরও স্বায়ত্তশাসন এবং মালিকানার কারণে কোড কীভাবে উত্পাদন করে এবং কর্মীদের সন্তুষ্টি বৃদ্ধি করে তার জন্যও দায়ী৷ diff --git a/content/bn/software_as_a_service.md b/content/bn/software_as_a_service.md index 66ca463066..c9c3ffd83a 100644 --- a/content/bn/software_as_a_service.md +++ b/content/bn/software_as_a_service.md @@ -12,8 +12,6 @@ Category: প্রযুক্তি প্রথাগতভাবে, ব্যবসায়িক সফ্টওয়্যারগুলো পৃথক কম্পিউটারে ইনস্টল করা হয়, যার রক্ষণাবেক্ষণ এবং আপডেট করার জন্য একজন প্রশাসকের প্রয়োজন হয়। উদাহরণ স্বরূপ: একটি প্রতিষ্ঠান গ্রাহক চাহিদা ব্যবস্থাপনা (CRM) এর জন্য স্ব-শরীর(on-premise) সফ্টওয়্যার ব্যবহার করতে পারে। এই সফ্টওয়্যারটি অভ্যন্তরীণ আইটি বিভাগ নিয়োগ করে ক্রয়, ইনস্টল, সুরক্ষা, রক্ষণাবেক্ষণ এবং নিয়মিত আপগ্রেড করা প্রয়োজন, যা আইটি টিমের উপর একটি বোঝাস্বরূপ ৷ লাইসেন্স, ইন্সটলেশন এবং সম্ভাব্য অতিরিক্ত হার্ডওয়্যারের সাথে যুক্ত আপ ফ্রন্ট খরচ নিষিদ্ধ হতে পারে। চাহিদার প্রতি সাড়া দেওয়াও কঠিন হতে পারে এবং [স্কেল](/scalability/) বৃদ্ধি বা পরিবর্তনের প্রতিক্রিয়ায় দ্রুত প্রয়োজন অনুযায়ী উপরে ও নিচে যাতায়াত সম্ভব না হতে পারে। - ## এটা কিভাবে সাহায্য করে সফ্টওয়্যার এজ এ সার্ভিস (SaaS) অ্যাপ্লিকেশনগুলি ব্যবহারকরী অভ্যন্তরীণ আইটি সংস্থা থেকে কোনও বিশেষ প্রচেষ্টার প্রয়োজন ছাড়াই কাজ করে৷ এগুলি বিক্রেতা দ্বারা ইনস্টল, রক্ষণাবেক্ষণ, আপগ্রেড এবং সুরক্ষিত। স্কেল, প্রাপ্যতা, এবং ক্ষমতার সমস্যাগুলি পরিষেবা প্রদানকারী দ্বারা পরিচালিত হয় এবং, একটি পে-অ্যাজ-ইউ-গো মডেলের সাথে, এন্টারপ্রাইজ অ্যাপ্লিকেশনগুলির উদ্দেশ্যসাধন করার ফলে সংস্থাগুলির জন্য একটি সাশ্রয়ী উপায় হতে পারে৷ - diff --git a/content/bn/style-guide/_index.md b/content/bn/style-guide/_index.md index e318531cda..089d0c06ba 100644 --- a/content/bn/style-guide/_index.md +++ b/content/bn/style-guide/_index.md @@ -27,7 +27,6 @@ menu: ## সংজ্ঞা টেমপ্লেট - প্রতিটি শব্দকোষ একটি মার্কডাউন ফাইলে সংরক্ষণ করা হয় এবং এই টেমপ্লেটটি অনুসরণ করে: ```md @@ -95,7 +94,6 @@ category: ধারণা --- ``` - ### সংজ্ঞা #### তিনটি উপশিরোনাম @@ -118,8 +116,6 @@ category: ধারণা **উদাহরণ**: [পরিষেবা মেশ সংজ্ঞা](/service_mesh/) এর “এটি কী” বিভাগটি একবার দেখুন। এটি মাইক্রোসার্ভিস, পরিষেবা, নির্ভরযোগ্যতা এবং পর্যবেক্ষণযোগ্যতার সংজ্ঞাগুলির সাথে লিঙ্ক করে। উপরন্তু, এটি একটি মাইক্রোসার্ভিসেস পরিবেশে নেটওয়ার্ক চ্যালেঞ্জের তুলনা করে একটি বাস্তব-বিশ্বের উদাহরণ ব্যবহার করে (এমন কিছু যা অ-প্রযুক্তিগত লোকেরা সম্পর্কিত হতে পারে না) ওয়াইফাই সমস্যার (যা কেউ ল্যাপটপ ব্যবহার করে বুঝতে পারে)সাথে । যেখানে সম্ভব, সেই সংযোগটি তৈরি করার চেষ্টা করুন। - - #### একটি Google বা Word ডক দিয়ে শুরু করুন আমরা একটি Google বা Word ডক দিয়ে শুরু করার পরামর্শ দিই, এটিকে কয়েক দিনের জন্য বসতে দিন এবং আবার দেখার জন্য। এটি আপনাকে বাক্যাংশ বা অভিব্যক্তিগুলি ধরতে দেয় যা একটি সহজ এবং আরও অ্যাক্সেসযোগ্য উপায়ে শব্দ করা যেতে পারে। এছাড়াও, PR জমা দেওয়ার আগে একটি বানান পরীক্ষা চালানো নিশ্চিত করুন। @@ -128,7 +124,6 @@ category: ধারণা শুরু করার আগে, অনুগ্রহ করে কিছু প্রকাশিত শব্দকোষের পদ পড়ুন যাতে বিশদ এবং অসুবিধার মাত্রা এবং উদাহরণগুলি বোঝা যায়। - ## পর্যালোচনা প্রক্রিয়া: কি আশা করা যায় দয়া করে মনে রাখবেন যে আমরা বর্তমানে শুধুমাত্র তিনজন রক্ষণাবেক্ষণকারী তাদের অবসর সময়ে এটি করে। মাঝে মাঝে, আমরা দ্রুত শর্তাবলী পর্যালোচনা করতে সক্ষম হব; অন্যান্য অনুষ্ঠানে, এটি কিছুটা সময় নিতে পারে — আমরা আপনার ধৈর্যের প্রশংসা করি। আপনার যদি কোনো প্রশ্ন থাকে, তাহলে অনুগ্রহ করে #glossary Slack চ্যানেলে আমাদের সাথে যোগাযোগ করুন (কোথায় এবং কীভাবে এটি খুঁজে পাবেন, অনুগ্রহ করে আমাদের [কীভাবে অবদান রাখবেন](/bn/contribute/) ডকটি দেখুন । diff --git a/content/de/_TEMPLATE.md b/content/de/_TEMPLATE.md index 9855f5c76b..b3f9ba9a22 100644 --- a/content/de/_TEMPLATE.md +++ b/content/de/_TEMPLATE.md @@ -5,10 +5,13 @@ category: Konzept --- ## Was es ist + Eine kurze Zusammenfassung. ## Welches Problem es löst + Kurze Erklärung darüber, welches Problem es löst. ## Wie es das Problem löst + Erläuterung darüber, wie es das Problem löst. diff --git a/content/en/_TEMPLATE.md b/content/en/_TEMPLATE.md index 8bd46cdc16..334627ffde 100644 --- a/content/en/_TEMPLATE.md +++ b/content/en/_TEMPLATE.md @@ -8,17 +8,14 @@ category: concept Quick summary of the concept and what it is. - ## Problem it addresses Define the problem it addresses. Ideally, don't even mention the term you are defining. - ## How it helps Describe how the term addresses the problem described above. - ## Related terms Add related Glossary terms (if applicable) diff --git a/content/en/_index.md b/content/en/_index.md index e67b09547d..02f42cece3 100755 --- a/content/en/_index.md +++ b/content/en/_index.md @@ -1,4 +1,3 @@ - --- title: "Cloud Native Glossary" --- @@ -10,6 +9,7 @@ The Cloud Native Glossary is a project led by the CNCF Business Value Subcommitt

A woman and two men presenting technical info on a stage

## Contributing + Everybody is invited to suggest changes, additions, and improvements to the Cloud Native Glossary. We employ a community-driven process governed by the CNCF to develop and improve upon this shared lexicon. This Glossary provides a vendor-neutral platform to organize a shared vocabulary around cloud native technologies. Contributions are welcome from all participants who abide by the project's purpose and charter. Anyone who wishes to make a contribution may submit a GitHub issue or create a pull request. Please ensure you follow the [Style Guide](/style-guide/), read the [How To Contribute](/contribute/) doc, and join the #glossary channel on the CNCF Slack. There is also a #glossary-localizations channel for those who want to help translate the glossary into their native language. diff --git a/content/en/abstraction.md b/content/en/abstraction.md index 2a45fe5782..7d5248ef52 100644 --- a/content/en/abstraction.md +++ b/content/en/abstraction.md @@ -7,5 +7,3 @@ category: Property In the context of computing, an abstraction is a representation that hides specifics from a consumer of [services](/service/) (a consumer being a computer program or human), making a system more generic and thus easily understood. A good example is your laptop's operating system (OS). It abstracts away all the details of how your computer works. You don't need to know anything about CPU, memory, and how programs are handled, you just operate the OS and the OS deals with the details. All these details are hidden behind the OS "curtain" or abstraction. Systems typically have multiple abstraction layers. This significantly simplifies development. When programming, developers build components compatible with a particular abstraction layer and don't have to worry about all underlying specifics that can be very heterogeneous. If it works with the abstraction layer, it works with the system — no matter what's under the hood. - - diff --git a/content/en/agile_software_development.md b/content/en/agile_software_development.md index 11c87e7587..d28374cabe 100644 --- a/content/en/agile_software_development.md +++ b/content/en/agile_software_development.md @@ -5,10 +5,13 @@ category: concept --- ## What it is + A set of practices that emphasize iterative development cycles and self-organizing teams. In contrast to waterfall-like projects where value is generated only at the very end of a project, agile software development focuses on a continuous, incremental delivery of value and evolutionary improvement of the process itself. ## Problem it addresses + Defining, communicating and understanding requirements for all stakeholders in a software project is very difficult, if not impossible. Yet, customers want their software projects to be delivered on time, in good quality, on budget and on scope. With its cyclical nature, agile software development enables continuous adaptation of requirements and faster adaptation to all other circumstances as opposed to waterfall-like strategies. ## How it helps + Agile software development contains all the phases of traditional (waterfall-like) strategies, like requirements engineering, planning, implementation, review, testing and delivery. The biggest difference is that the whole time span of a software project is sliced into iterations, which each contain all those phases. After each iteration, the created value can be reviewed with the customer and requirements can be adjusted towards the end goal. Additionally the development team retrospects on which actions items to take in order to improve the process itself. diff --git a/content/en/api_gateway.md b/content/en/api_gateway.md index 07c2dddf72..73ec058171 100644 --- a/content/en/api_gateway.md +++ b/content/en/api_gateway.md @@ -5,13 +5,13 @@ category: technology --- ## What it is + An [API](/application_programming_interface/) gateway is a tool that aggregates unique application APIs, making them all available in one place. It allows organizations to move key functions, such as authentication and authorization or limiting the number of requests between applications, to a centrally managed location. An API gateway functions as a common interface to (often external) API consumers. ## Problem it addresses + If you’re making APIs available to external consumers, you'll want one entry point to manage and control all access. Additionally, if you need to apply functionality on those interactions, an API gateway allows you to uniformly apply it to all traffic without requiring any app code changes. ## How it helps -Providing one single access point for various APIs in an application, API gateways make it easier for organizations to apply cross-cutting business or security logic in a central location. They also allow application consumers to go to a single address for all their needs. An API gateway can simplify operational concerns like security and [observability](/observability/) by providing a single access point for requests to all web services in a system. As all requests flow through the API gateway, it presents a single place to add functionality like metrics-gathering, rate-limiting, and authorization. - - +Providing one single access point for various APIs in an application, API gateways make it easier for organizations to apply cross-cutting business or security logic in a central location. They also allow application consumers to go to a single address for all their needs. An API gateway can simplify operational concerns like security and [observability](/observability/) by providing a single access point for requests to all web services in a system. As all requests flow through the API gateway, it presents a single place to add functionality like metrics-gathering, rate-limiting, and authorization. diff --git a/content/en/application_programming_interface.md b/content/en/application_programming_interface.md index 471a9cef6c..ce3b3ca22d 100644 --- a/content/en/application_programming_interface.md +++ b/content/en/application_programming_interface.md @@ -5,11 +5,13 @@ category: technology --- ## What it is + An API is a way for computer programs to interact with each other. Just as humans interact with a website via a web page, an API allows computer programs to interact with each other. Unlike human interactions, APIs have limitations on what can and cannot be asked of them. The limitation on interaction helps to create stable and functional communication between programs. ## Problem it addresses + As applications become more complex, small code changes can have drastic effects on other functionality. Applications need to take a modular approach to their functionality if they can grow and maintain stability simultaneously. Without APIs, there is a lack of a framework for the interaction between applications. Without a shared framework, it is challenging for applications to [scale](/scalability/) and integrate. ## How it helps -APIs allow computer programs or applications to interact and share information in a defined and understandable manner. They are the building blocks for modern applications and they provide developers with a way to integrate applications together. Whenever you hear about [microservices](/microservices/) working together, you can infer that they interact via an API. +APIs allow computer programs or applications to interact and share information in a defined and understandable manner. They are the building blocks for modern applications and they provide developers with a way to integrate applications together. Whenever you hear about [microservices](/microservices/) working together, you can infer that they interact via an API. diff --git a/content/en/auto_scaling.md b/content/en/auto_scaling.md index 4e34d338d6..1fa3640fa0 100644 --- a/content/en/auto_scaling.md +++ b/content/en/auto_scaling.md @@ -11,5 +11,6 @@ Previously, infrastructure and applications were architected to consider peak sy By leveraging the cloud, [virtualizing](/virtualization/), and [containerizing](/containerization/) applications and their dependencies, organizations can build applications that scale according to user demands. They can monitor application demand and automatically scale them, providing an optimal user experience. Take the increase in viewership Netflix experiences every Friday evening. Autoscaling out means dynamically adding more resources: for example, increasing the number of servers allowing for more video streaming and scaling back once consumption has normalized. ## Related terms + * [Horizontal Scaling](/horizontal_scaling/) * [Vertical Scaling](/vertical_scaling/) diff --git a/content/en/bare_metal_machine.md b/content/en/bare_metal_machine.md index 15719a84ac..efe8e93e29 100644 --- a/content/en/bare_metal_machine.md +++ b/content/en/bare_metal_machine.md @@ -17,4 +17,3 @@ Pairing one operating system with one physical computer is the original pattern By dedicating all compute resources of a computer to a single operating system, you potentially provide the best possible performance to the operating system. If you need to run a workload that must have extremely fast access to hardware resources, bare metal may be the right solution. In the context of [cloud native apps](/cloud_native_apps/), we generally think of performance in terms of [scaling](/scalability/) to a large number of concurrent events, which can be handled by [horizontal scaling](/horizontal_scaling/) (adding more machines to your resource pool). But some workloads may require [vertical scaling](/vertical_scaling/) (adding more power to an existing physical machine) and/or an extremely fast physical hardware response in which case bare metal is better suited. Bare metal also allows you to tune the physical hardware and possibly even hardware drivers to help accomplish your task. - diff --git a/content/en/blue_green_deployment.md b/content/en/blue_green_deployment.md index 85f8cdb26e..bbad2a0882 100644 --- a/content/en/blue_green_deployment.md +++ b/content/en/blue_green_deployment.md @@ -5,11 +5,13 @@ category: concept --- ## What it is + Blue-green deployment is a strategy for updating running computer systems with minimal downtime. The operator maintains two environments, dubbed “blue” and “green”. One serves production traffic (the version all users are currently using), whilst the other is updated. Once testing has concluded on the non-active (green) environment, production traffic is switched over (often via the use of a load balancer). Note that blue-green deployment usually means switching the entire environments, comprising many services, all at once. Confusingly, sometimes the term is used with regard to individual services within a system. To avoid this ambiguity, the term “zero-downtime deployment” is preferred when referring to individual components. ## Problem it addresses + Blue-green deployments allow minimal downtime when updating software that must be changed in "lockstep" owing to a lack of backwards compatibility. For example, blue-green deployment would be appropriate for an online store consisting of a website and a database that needs to be updated, but the new version of the database doesn’t work with the old version of the website, and vice versa. In this instance, both need to be changed at the same time. If this was done on the production system, customers would notice downtime. ## How it helps -Blue-green deployment is an appropriate strategy for non-cloud native software that needs to be updated with minimal downtime. However, its use is normally a "smell" that legacy software needs to be re-engineered so that components can be updated individually. +Blue-green deployment is an appropriate strategy for non-cloud native software that needs to be updated with minimal downtime. However, its use is normally a "smell" that legacy software needs to be re-engineered so that components can be updated individually. diff --git a/content/en/canary_deployment.md b/content/en/canary_deployment.md index 938d5ec22c..dd23fa1539 100644 --- a/content/en/canary_deployment.md +++ b/content/en/canary_deployment.md @@ -5,14 +5,15 @@ category: concept --- ## What it is + Canary deployments is a deployment strategy that starts with two environments: one with live traffic and the other containing the updated code without live traffic. The traffic is gradually moved from the original version of the application to the updated version. It can start by moving 1% of live traffic, then 10%, 25%, and so on, until all traffic is running through the updated version. Organizations can test the new version of the software in production, get feedback, diagnose errors, and quickly rollback to the stable version if necessary. The term “canary” refers to the "canary in a coal mine" practice where canary birds were taken into coal mines to keep miners safe. If odorless harmful gases were present, the bird would die, and the miners knew they had to evacuate quickly. Similarly, if something goes wrong with the updated code, live traffic is "evacuated" back to the original version. ## Problem it addresses + No matter how thorough the testing strategy, there are always some bugs discovered in production. Shifting 100% of traffic from one version of an app to another can lead to more impactful failures. ## How it helps -Canary deployments allow organizations to see how new software behaves in real-world scenarios before moving significant traffic to the new version. This strategy enables organizations to minimize downtime and quickly rollback in case of issues with the new deployment. It also allows more in-depth production application testing without a significant impact on the overall user experience. - +Canary deployments allow organizations to see how new software behaves in real-world scenarios before moving significant traffic to the new version. This strategy enables organizations to minimize downtime and quickly rollback in case of issues with the new deployment. It also allows more in-depth production application testing without a significant impact on the overall user experience. diff --git a/content/en/chaos_engineering.md b/content/en/chaos_engineering.md index 21198382e5..15bc952ba0 100644 --- a/content/en/chaos_engineering.md +++ b/content/en/chaos_engineering.md @@ -5,10 +5,13 @@ category: concept --- ## What it is + Chaos Engineering or CE is the discipline of experimenting on a [distributed system](/distributed_systems/) in production to build confidence in the system's capability to withstand turbulent and unexpected conditions. ## Problem it addresses + [SRE](/site_reliability_engineering/) and [DevOps](/devops/) practices focus on techniques to increase product resiliency and [reliability](/reliability/). A system's ability to tolerate failures while ensuring adequate service quality is typically a software development requirement. There are several aspects involved that could lead to outages of an application, like infrastructure, platform or other moving parts of a ([microservice](/microservices/)-based) application. High-frequency deployment of new features to the production environment can result in a high probability of downtime and a critical incident — with considerable consequences to the business. ## How it helps + Chaos engineering is a technique to meet resilience requirements. It is used to achieve resilience against infrastructure, platform, and application failures. Chaos engineers use chaos experiments to proactively inject random failures to verify that an application, infrastructure, or platform can self-heal and the failure cannot noticeably impact customers. Chaos experiments aim to discover blind spots (e.g. monitoring or autoscaling techniques) and to improve the communications between teams during critical incidents. This approach helps increase resiliency and the team's confidence in complex systems, particularly production. diff --git a/content/en/cloud_computing.md b/content/en/cloud_computing.md index b76832528a..0c5424a05b 100644 --- a/content/en/cloud_computing.md +++ b/content/en/cloud_computing.md @@ -5,12 +5,13 @@ category: concept --- ## What it is + Cloud computing is a model that offers compute resources like CPU, network, and disk capabilities on-demand over the internet. Cloud computing gives users the ability to access and use computing power in a remote physical location. Cloud providers like AWS, GCP, Azure, DigitalOcean, and others all offer third parties the ability to rent access to compute resources in multiple geographic locations. ## Problem it addresses + Organizations traditionally faced two main problems when attempting to expand their use of computing power. They either acquire, support, design, and pay for facilities to host their physical servers and network or expand and maintain those facilities. Cloud computing allows organizations to outsource some portion of their computing needs to another organization. ## How it helps -Cloud providers offer organizations the ability to rent compute resources on-demand and pay for usage. This allows for two major innovations: organizations can try things without wasting time planning and spending money or resources on new physical infrastructure and they can [scale](/scalability/) as needed and on-demand. Cloud computing allows organizations to adopt as much or as little infrastructure as they need. - +Cloud providers offer organizations the ability to rent compute resources on-demand and pay for usage. This allows for two major innovations: organizations can try things without wasting time planning and spending money or resources on new physical infrastructure and they can [scale](/scalability/) as needed and on-demand. Cloud computing allows organizations to adopt as much or as little infrastructure as they need. diff --git a/content/en/cloud_native_apps.md b/content/en/cloud_native_apps.md index 39a4e86ac9..2bd13e8e55 100644 --- a/content/en/cloud_native_apps.md +++ b/content/en/cloud_native_apps.md @@ -5,12 +5,13 @@ category: concept --- ## What it is + Cloud native applications are specifically designed to take advantage of innovations in [cloud computing](/cloud_computing/). These applications integrate easily with their respective cloud architectures, taking advantage of the cloud’s resources and [scaling](/scalability/) capabilities. It also refers to applications that take advantage of innovations in infrastructure driven by cloud computing. Cloud native applications today include apps that run in a cloud provider’s datacenter and on cloud native platforms on-premise. ## 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, 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. For example, apps that require manual intervention to start correctly cannot scale automatically, nor can they be automatically restarted in the event of a failure. ## How it helps -While there is no “one size fits all” path to cloud native applications, they do have some commonalities. Cloud native apps are resilient, manageable, and aided by the suite of cloud services that accompany them. The various cloud services enable a high degree of [observability](/observability/), enabling users to detect and address issues before they escalate. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. - +While there is no “one size fits all” path to cloud native applications, they do have some commonalities. Cloud native apps are resilient, manageable, and aided by the suite of cloud services that accompany them. The various cloud services enable a high degree of [observability](/observability/), enabling users to detect and address issues before they escalate. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. diff --git a/content/en/cluster.md b/content/en/cluster.md index c596486502..ebb05dfd15 100644 --- a/content/en/cluster.md +++ b/content/en/cluster.md @@ -15,5 +15,3 @@ Software that runs on a single computer presents a single point of failure — i ## How it helps Clustered, distributed applications run across multiple machines, eliminating a single point of failure. But building distributed systems is really hard. In fact, it's a computer science discipline in its own right. The need for global systems and years of trial and error led to the development of a new kind of tech stack: [cloud native technologies](/cloud_native_tech/). These new technologies are the building blocks that make the operation and creation of distributed systems easier. - - diff --git a/content/en/container.md b/content/en/container.md index 62870a89cc..9ce4a298c3 100644 --- a/content/en/container.md +++ b/content/en/container.md @@ -5,12 +5,15 @@ category: technology --- ## What it is + A container is a running process with resource and capability constraints managed by a computer’s operating system. The files available to the container process are packaged as a container image. Containers run adjacent to each other on the same machine, but typically the operating system prevents the separate container processes from interacting with each other. ## Problem it addresses + Before containers were available, separate machines were necessary to run applications. Each machine would require its own operating system, which takes CPU, memory, and disk space, all for an individual application to function. Additionally, the maintenance, upgrade, and startup of an operating system is another significant source of toil. ## How it helps + Containers share the same operating system and its machine resources, spreading the operating system’s resource overhead and creating efficient use of the physical machine. This capability is only possible because containers are typically limited from being able to interact with each other. This allows many more applications to be run on the same physical machine. There are limitations, however. Since containers share the same operating system, processes can be considered less secure than alternatives. Containers also require limits on the shared resources. To guarantee resources, administrators must constrain and limit memory and CPU usage so that other applications do not perform poorly. diff --git a/content/en/containers_as_a_service.md b/content/en/containers_as_a_service.md index 6892f954f2..b644e6c7c3 100644 --- a/content/en/containers_as_a_service.md +++ b/content/en/containers_as_a_service.md @@ -5,12 +5,15 @@ category: Technology --- ## What it is + Containers-as-a-Service (CaaS) is a cloud service that helps manage and deploy apps using [container](/container/)-based [abstraction](/abstraction/). This service can be deployed on-premises or in the cloud. CaaS providers offer a framework or orchestration platform that automates key IT functions on which containers are deployed and managed. It helps developers build secure and [scalable](/scalability/) containerized apps. Because users only buy the resources they need (scheduling capabilities, load balancing, etc.), they save money and increase efficiency. Containers create consistent environments to rapidly develop and deliver [cloud-native applications](/cloud_native_apps/) that can run anywhere. ## Problem it addresses + Without CaaS, software development teams need to deploy, manage, and monitor the underlying infrastructure that containers run on. ## How it helps + When deploying containerized applications to a CaaS platform, users gain visibility into system performance through log aggregation and monitoring tools. CaaS also includes built-in functionality for [auto scaling](/auto_scaling/) and orchestration management. It enables teams to build high visibility and high availability [distributed systems](/distributed_systems/). In addition, by allowing rapid deployments, CaaS increases team development velocity. While containers ensure a consistent deployment target, CaaS lowers engineering operating costs by reducing needed [DevOps](/devops/) resources needed to manage a deployment. diff --git a/content/en/continuous_delivery.md b/content/en/continuous_delivery.md index 0d83b572ea..04166b8e18 100644 --- a/content/en/continuous_delivery.md +++ b/content/en/continuous_delivery.md @@ -5,16 +5,18 @@ category: concept --- ## What it is + Continuous delivery, often abbreviated as CD, is a set of practices in which code changes are automatically deployed into an acceptance environment (or, in the case of continuous deployment, into production). CD crucially includes procedures to ensure that software is adequately tested before deployment and provides a way to rollback changes if deemed necessary. Continuous integration (CI) is the first step towards continuous delivery (i.e., changes have to merge cleanly before being tested and deployed). ## Problem it addresses + Deploying [reliable](/reliability/) updates becomes a problem at scale. Ideally, we'd deploy more frequently to deliver better value to end-users. However, doing it manually translates into high transaction costs for every change. Historically, to avoid these costs, organizations have released less frequently, deploying more changes at once and increasing the risk that something goes wrong. ## How it helps + CD strategies create a fully automated path to production that tests and deploys the software using various deployment strategies such as [canary](/canary_deployment/) or [blue-green](/blue_green_deployment/) releases. This allows developers to deploy code frequently, giving them peace of mind that the new revision has been tested. Typically, trunk-based development is used in CD strategies as opposed to feature branching or pull requests. ## Related terms + * [Continuous Integration](/continuous_integration/) * [Continuous Deployment](/continuous_deployment/) - - diff --git a/content/en/continuous_deployment.md b/content/en/continuous_deployment.md index 6022b657a0..5c392c8580 100644 --- a/content/en/continuous_deployment.md +++ b/content/en/continuous_deployment.md @@ -17,5 +17,6 @@ Releasing new software versions can be a labor-intensive and error-prone process By automating the release cycle and forcing organizations to release to production more frequently, CD does what CI did for development teams for operations teams. Specifically, it forces operations teams to automate the painful and error-prone portions of production deployments, reducing overall risk. It also makes organizations better at accepting and adapting to production changes, which leads to higher stability. ## Related terms + * [Continuous Integration](/continuous_integration/) * [Continuous Delivery](/continuous_delivery/) diff --git a/content/en/continuous_integration.md b/content/en/continuous_integration.md index 50014d86b1..aafcba2513 100644 --- a/content/en/continuous_integration.md +++ b/content/en/continuous_integration.md @@ -5,14 +5,18 @@ category: concept --- ## What it is + Continuous integration, often abbreviated as CI, is the practice of integrating code changes as regularly as possible. CI is a prerequisite for [continuous delivery](/continuous_delivery/) (CD). Traditionally, the CI process begins when code changes are committed to a source control system (Git, Mercurial, or Subversion) and ends with a tested artifact ready to be consumed by a CD system. ## Problem it addresses + Software systems are often large and complex, with numerous developers maintaining and updating them. Working in parallel on different parts of the system, these developers may make conflicting changes and inadvertently break each other’s work. Additionally, with multiple developers working on the same project, any everyday tasks such as testing and calculating code quality would need to be repeated by each developer, wasting time. ## How it helps + CI software automatically checks that code changes merge cleanly whenever a developer commits a change. It's a near-ubiquitous practice to use the CI server to run code quality checks, tests, and even deployments. As such, it becomes a concrete implementation of quality control within teams. CI allows software teams to turn every code commit into either a concrete failure or a viable release candidate. ## Related terms + * [Continuous Delivery](/continuous_delivery/) * [Continuous Deployment](/continuous_deployment/) diff --git a/content/en/contribute/_index.md b/content/en/contribute/_index.md index 10fb12cca7..8c82aeb446 100644 --- a/content/en/contribute/_index.md +++ b/content/en/contribute/_index.md @@ -58,7 +58,7 @@ Please note that terms must meet the [CNCF's cloud native definition](https://gi The only exceptions are foundational terms needed to understand cloud native concepts. Below is a step-by-step guide for those not yet familiar with GitHub. -**If you are a GitHub Pro**, please *do* have a quick look to make sure you use our issue templates, +**If you are a GitHub Pro**, please _do_ have a quick look to make sure you use our issue templates, appropriate naming conventions, claim a PR on Slack (otherwise we may miss it), and where to find the file template. And please make sure to read the [Style Guide](/style-guide/) before getting started — thank you! @@ -75,7 +75,6 @@ You'll see a variety of templates. To propose a new term in English, select "Req Add the word you're suggesting, answer the two questions below, check the checkboxes, and hit "Submit new issue". If you're just proposing a new term, you're done! To work on it, follow the next steps. - ### Triaging your issue {#triaging-your-issue} Next, the maintainers will triage the issue. diff --git a/content/en/debugging.md b/content/en/debugging.md index 0c2e1b45e1..896a3a32c3 100644 --- a/content/en/debugging.md +++ b/content/en/debugging.md @@ -5,10 +5,13 @@ category: concept --- ## What it is + Debugging is the process or activity of finding and resolving bugs (or errors) from computer programs, software, or systems to get the desired result. A bug is a defect or a problem leading to incorrect or unexpected results. ## Problem it addresses + Software development is a complex activity that makes it nearly impossible to write code without introducing bugs. Those bugs lead to code that will likely not function as desired (undefined behavior) when executed. Depending on how critical an application is, bugs can have a significant negative impact — financially or even on human lives. Usually, application code has to go through different stages or environments where it gets tested. The more critical an application is, the more accurate the testing has to be. ## How it helps + When bugs appear, engineers have to debug (e.g., finding and fixing) the app to decrease undesired behavior for production systems. Debugging is no easy task as engineers have to track down the source of the undesired behavior. It requires knowledge about the code itself and the execution context at runtime. This is where different debugging techniques and tools come in handy. Analysis of logs, traces, and metrics, for instance, are used for debugging directly in production. Developers can use interactive debugging to step through the code at runtime while analyzing the related execution context. Once they have identified the source of the failure, they correct the code and create a bug fix or patch. diff --git a/content/en/devops.md b/content/en/devops.md index f34a0c4ac9..4cb5ab01eb 100644 --- a/content/en/devops.md +++ b/content/en/devops.md @@ -5,13 +5,15 @@ category: concept --- ## What it is + DevOps is a methodology in which teams own the entire process from application development to production operations, hence DevOps. It goes beyond implementing a set of technologies and requires a complete shift in culture and processes. DevOps calls for groups of engineers that work on small components (versus an entire feature), decreasing handoffs – a common source of errors. ## Problem it addresses + Traditionally, in complex organizations with [tightly-coupled](/tightly_coupled_architectures/) [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. Because individuals only worked on one small piece of the project, this approach led to a lack of ownership. Their goal was to get the work to the next group, not deliver the right functionality to the customer — a clear misalignment of priorities. By the time code finally got into production, it went through so many developers, waiting in so many queues that it was difficult to trace the origin of the problem if the code didn’t work. DevOps turns this approach upside down. ## How it helps -Having one team own the entire lifecycle of an application results in minimized handoffs, reduce risk when deploying into production, better code quality as teams are also responsible for how code performs in production and increased employee satisfaction due to more autonomy and ownership. +Having one team own the entire lifecycle of an application results in minimized handoffs, reduce risk when deploying into production, better code quality as teams are also responsible for how code performs in production and increased employee satisfaction due to more autonomy and ownership. diff --git a/content/en/devsecops.md b/content/en/devsecops.md index db4474a65a..630b7e129c 100644 --- a/content/en/devsecops.md +++ b/content/en/devsecops.md @@ -5,12 +5,13 @@ category: concept --- ## What it is + The term DevSecOps refers to a cultural merger of the development, operational, and security responsibilities. It extends the [DevOps](/devops/) approach to include security priorities with minimal to no disruption in the developer and operational workflow. Like DevOps, DevSecOps is a cultural shift, pushed by the technologies adopted, with unique adoption methods. ## Problem it addresses + DevOps practices include [continuous integration](/continuous_integration/) and [continuous deployment](/continuous_delivery/) and accelerate application development and release cycles. Unfortunately, automated release processes that fail to represent all organizational stakeholders adequately can exacerbate existing issues. A process that rapidly releases new software without considering security needs can degrade an organizations’ security posture. ## How it helps -DevSecOps focuses on breaking down team silos and promotes the creation of secure, automated workflows. When selecting security applications, organizations must take advantage of automated CI/CD workflows and policy enforcement that empower the developer. The goal is not to be a blocker but to enforce security policies while giving users accurate information on how to move their project forward. When properly implemented, an organization will gain better team communication and reduce security mishaps and associated costs. - +DevSecOps focuses on breaking down team silos and promotes the creation of secure, automated workflows. When selecting security applications, organizations must take advantage of automated CI/CD workflows and policy enforcement that empower the developer. The goal is not to be a blocker but to enforce security policies while giving users accurate information on how to move their project forward. When properly implemented, an organization will gain better team communication and reduce security mishaps and associated costs. diff --git a/content/en/distributed_apps.md b/content/en/distributed_apps.md index 35654739b3..4844a6af5f 100644 --- a/content/en/distributed_apps.md +++ b/content/en/distributed_apps.md @@ -15,4 +15,3 @@ An application running on one single computer represents a single point of failu ## How it helps When splitting an application into different pieces and running them in many places, the overall system can tolerate more failures. It also allows an application to take advantage of scaling features not available to a single application instance, namely the ability to [scale horizontally](/horizontal_scaling/). This does, however, come at a cost: increased complexity and operational overhead — you’re now running lots of application components instead of one app. - diff --git a/content/en/distributed_systems.md b/content/en/distributed_systems.md index c332fee87f..8d89a03e64 100644 --- a/content/en/distributed_systems.md +++ b/content/en/distributed_systems.md @@ -5,16 +5,17 @@ category: concept --- ## What it is + A distributed system is a collection of autonomous computing elements connected over a network that appears to users as a single coherent system. Generally referred to as [nodes](/nodes/), these components can be hardware devices (e.g. computers, mobile phones) or software processes. Nodes are programmed to achieve a common goal and, to collaborate, they exchange messages over the network. ## Problem it addresses + Numerous modern applications today are so big they'd need supercomputers to operate. Think Gmail or Netflix. No single computer is powerful enough to host the entire application. By connecting multiple computers, compute power becomes nearly limitless. Without distributed computing, many applications we rely on today wouldn't be possible. Traditionally, systems would [scale](/scalability/) vertically. That's when you add more CPU or memory to an individual machine. Vertical scaling is time-consuming, requires downtime, and reaches its limit quickly. ## How it helps + Distributed systems allow for [horizontal scaling](/horizontal_scaling/) (e.g. adding more nodes to the system whenever needed). This can be automated allowing a system to handle a sudden increase in workload or resource consumption. A non-distributed system exposes itself to risks of failure because if one machine fails, the entire system fails. A distributed system can be designed in such a way that, even if some machines go down, the overall system can still keep working to produce the same result. - - diff --git a/content/en/firewall.md b/content/en/firewall.md index f096bf80eb..27b599d962 100644 --- a/content/en/firewall.md +++ b/content/en/firewall.md @@ -5,10 +5,13 @@ category: Technology --- ## What it is + A firewall is a system that filters network traffic on the basis of specified rules. Firewalls can be hardware, software, or a combination of the two. ## Problem it addresses + By default, a network will allow anyone to enter and depart as long as they follow the network's routing rules. Because of this default behavior, securing a network is challenging. For example, in a microservices-based banking app, the services communicate with one another by transmitting highly sensitive financial data through their network. A malicious actor may infiltrate the network, intercept communication, and do damage if there was no firewall in place. ## How it helps + A firewall examines network traffic using pre-defined rules. All traffic is filtered, and any traffic coming from untrustworthy or suspect sources is blocked — only traffic configured to be accepted gets in. Firewalls establish a barrier between secured and controlled internal trusted networks. diff --git a/content/en/function_as_a_service.md b/content/en/function_as_a_service.md index 002e012a3a..aee30534e5 100644 --- a/content/en/function_as_a_service.md +++ b/content/en/function_as_a_service.md @@ -5,10 +5,13 @@ category: Technology --- ## What it is + Function as a Service (FaaS) is a type of [serverless](/serverless/) [cloud computing](/cloud_computing/) [service](/service/) that allows executing code in response to events without maintaining the complex infrastructure typically associated with building and launching [microservices](/microservices/) applications. With FaaS, users manage only functions and data while the cloud provider manages the application. This allows developers to get the functions they need without paying for services when code isn’t running. Some popular FaaS examples include: [Amazon's AWS Lambda](https://aws.amazon.com/lambda/), [Google Cloud Functions](https://cloud.google.com/functions/) and [Microsoft Azure Functions](https://azure.microsoft.com/en-us/services/functions/). ## Problem it addresses + In a traditional on-premises scenario, a business manages and maintains its own data center. The business must invest in servers, storage, software, and other technologies and potentially hire an IT staff or contractors to purchase, manage, and upgrade all the equipment and licenses. The data center has to be built to meet peak demand, even when workloads decline and those resources stand idle. Conversely, if the business grows quickly, the IT department might struggle to keep up. Under a standard [Infrastructure-as-a-Service (IaaS)](/infrastructure_as_a_service/) cloud computing model, users pre-purchase capacity units, meaning you pay a public cloud provider for always-on server components to run your apps. It’s the user’s responsibility to scale up server capacity during times of high demand and scale down when that capacity is no longer needed. The cloud infrastructure necessary to run an app is active even when the app isn’t being used. ## How it helps + FaaS gives developers an [abstraction](/abstraction/) for running web applications in response to events without managing servers. For example, uploading a file could trigger custom code that transcodes the file into various formats. FaaS infrastructure will auto-scale the code for heavy use, and the developer does not have to spend any time or resources building the code for [scalability](//scalability/). Billing is based on computation time alone, which means businesses do not have to pay when the functions are not in use. diff --git a/content/en/horizontal_scaling.md b/content/en/horizontal_scaling.md index 228d6742b3..461a390799 100644 --- a/content/en/horizontal_scaling.md +++ b/content/en/horizontal_scaling.md @@ -19,5 +19,6 @@ As demand for an application grows beyond the current capacity of that applicati Horizontal scaling allows applications to scale to whatever limits the underlying cluster provides. By adding more instances to the system, the app can process a greater number of requests. If a single node can handle 1,000 requests per second, each additional node should increase the total number of requests by around 1,000 requests per second. This allows the application to do more work concurrently without needing to increase the capacity of any node in particular. ## Related terms + * [Vertical Scaling](/vertical_scaling/) * [Auto Scaling](/auto_scaling/) diff --git a/content/en/immutable_infrastructure.md b/content/en/immutable_infrastructure.md index f00a12b459..14ba9285a8 100644 --- a/content/en/immutable_infrastructure.md +++ b/content/en/immutable_infrastructure.md @@ -7,5 +7,3 @@ category: property Immutable Infrastructure refers to computer infrastructure ([virtual machines](/virtual_machine/), [containers](/container/), network appliances) that cannot be changed once deployed. This can be enforced by an automated process that overwrites unauthorized changes or through a system that won't allow changes in the first place. Containers are a good example of immutable infrastructure because persistent changes to containers can only be made by creating a new version of the container or recreating the existing container from its image. By preventing or identifying unauthorized changes, immutable infrastructures make it easier to identify and mitigate security risks. Operating such a system becomes a lot more straightforward because administrators can make assumptions about it. After all, they know no one made mistakes or changes they forgot to communicate. Immutable infrastructure goes hand-in-hand with [infrastructure as code](/infrastructure_as_code/) where all automation needed to create infrastructure is stored in version control (e.g. Git). This combination of immutability and version control means that there is a durable audit log of every authorized change to a system. - - diff --git a/content/en/infrastructure_as_code.md b/content/en/infrastructure_as_code.md index 042379694c..86b156b24e 100644 --- a/content/en/infrastructure_as_code.md +++ b/content/en/infrastructure_as_code.md @@ -5,11 +5,13 @@ category: concept --- ## What it is + Infrastructure as code is the practice of storing the definition of infrastructure as one or more files. This replaces the traditional model where infrastructure as a service is provisioned manually, usually through shell scripts or other configuration tools. ## Problem it addresses + Building applications in a cloud native way requires infrastructure to be disposable and reproducible. It also needs to [scale](/scalability/) on-demand in an automated and repeatable way, potentially without human intervention. Manual provisioning cannot meet the responsiveness and scale requirements of [cloud native applications](/cloud_native_apps/). Manual infrastructure changes are not reproducible, quickly run into scale limits, and introduces misconfiguration errors. ## How it helps -By representing the data center resources such as servers, load balancers, and subnets as code, it allows infrastructure teams to have a single source of truth for all configurations and also allows them to manage their data center in a [CI](/continuous_integration/)/[CD](/continuous_delivery/) pipeline, implementing version control and deployment strategies. +By representing the data center resources such as servers, load balancers, and subnets as code, it allows infrastructure teams to have a single source of truth for all configurations and also allows them to manage their data center in a [CI](/continuous_integration/)/[CD](/continuous_delivery/) pipeline, implementing version control and deployment strategies. diff --git a/content/en/kubernetes.md b/content/en/kubernetes.md index 1d5c103ad3..602e378c06 100644 --- a/content/en/kubernetes.md +++ b/content/en/kubernetes.md @@ -5,6 +5,7 @@ category: technology --- ## What it is + Kubernetes, often abbreviated as K8s, is an open source container orchestrator that automates the life-cycle of [containerized](/container/) applications on modern infrastructures. It's like a data center operating system that manages applications running across a [distributed system](/distributed_systems/) (just like the OS on your laptop that manages your apps). Kubernetes schedules containers across [nodes](/nodes/) in a [cluster](/cluster/). It bundles several infrastructure constructs, sometimes referred to as “primitives,” like an instance of an app, load balancers, persistent storage, and others together in a way that they can be composed into applications. @@ -12,12 +13,12 @@ Kubernetes schedules containers across [nodes](/nodes/) in a [cluster](/cluster/ Kubernetes enables automation and extensibility, allowing users to deploy applications declaratively in a reproducible way. Software products and projects in the Kubernetes ecosystem take advantage of that automation and extensibility to extend the Kubernetes [API](/application_programming_interface/). This enables them to leverage Kubernetes’ automation and make their tools more accessible to experienced Kubernetes practitioners. ## Problem it addresses + Infrastructure automation and declarative configuration management have been important concepts for a long time and have only become more pressing as [cloud computing](/cloud_computing/) has gained popularity. As demand for compute resources increases and organizations feel pressured to provide more operational capabilities with fewer engineers, new technologies and working methods are required to meet that demand. Additionally, the rise of cloud computing was paired with [containerization](/containerization/) and organizations that were busy automating more traditional infrastructure needed a mechanism to automate the configuration and deployment of their containers. ## How it helps + Kubernetes helps with automation in a manner similar to traditional infrastructure as code tools but has the advantage of working with containers that are more resistant to configuration drift than virtual or physical machines. Kubernetes works declaratively, which means that instead of operators providing the instructions about how to do something they instead describe, usually as manifest files (e.g. YAML), what they want to be done; Kubernetes will take care of the "how" on its own. This results in Kubernetes being extremely compatible with infrastructure as code. Kubernetes also self-heals. This means that it ensures the cluster’s actual state always matches the operator’s desired state. If Kubernetes detects a deviation, a Kubernetes controller kicks in and fixes it. So while the infrastructure it uses may be continually changing Kubernetes itself is continually, and automatically adapting to changes and ensuring that it matches with the desired state. - - diff --git a/content/en/load_balancer.md b/content/en/load_balancer.md index 4fdd779ebf..4b2ad39106 100644 --- a/content/en/load_balancer.md +++ b/content/en/load_balancer.md @@ -5,10 +5,13 @@ category: concept --- ## What it is + A load balancer is a method to distribute incoming network traffic across a group of servers in the back-end. The solution can be software or hardware based. ## Problem it addresses + This helps solve the issue related to high availability and distributed systems. When working on an application or service that needs to scale to hundreds of thousands of users, one will often need to distribute that application on multiple servers. The load balancer is the "traffic cop" that routes traffic. ## How it helps -A load balancer will act as front-end for network traffic and clients. It often has various methods to check which server(s) is up and has the lowest load to handle the request. \ No newline at end of file + +A load balancer will act as front-end for network traffic and clients. It often has various methods to check which server(s) is up and has the lowest load to handle the request. diff --git a/content/en/loosely_coupled_architecture.md b/content/en/loosely_coupled_architecture.md index db4c56780d..740f366ea6 100644 --- a/content/en/loosely_coupled_architecture.md +++ b/content/en/loosely_coupled_architecture.md @@ -7,4 +7,3 @@ category: 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/), 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. - diff --git a/content/en/mTLS (Mutual Transport Layer Security).md b/content/en/mTLS (Mutual Transport Layer Security).md index e223a9562b..5db1a9d550 100644 --- a/content/en/mTLS (Mutual Transport Layer Security).md +++ b/content/en/mTLS (Mutual Transport Layer Security).md @@ -5,10 +5,13 @@ category: Concept --- ## What it is + Mutual TLS (mTLS) is a technique used to authenticate and encrypt messages sent between two [services](/service/). Mutual TLS is the standard [Transport Layer Security](/tlstransport-layer-security/) (TLS) protocol but, instead of validating the identity of just one connection, both sides are validated. ## Problem it addresses + [Microservices](/microservices/) communicate over a network and, just like your wifi network, communication in transit over that network can be hacked. mTLS ensures that no unauthorized party can listen in on or impersonate legitimate requests. ## How it helps + mTLS ensures that traffic is secure and trusted in both directions between a client and server, providing an additional layer of security for users who log in to a network or applications. It also verifies connections with client devices that do not follow a login process, such as Internet of Things (IoT) devices. Attacks like on-path attacks, spoofing attacks, credential stuffing, brute force attacks, etc. can be prevented by mTLS. diff --git a/content/en/managed_services.md b/content/en/managed_services.md index 33ee1bb9f2..db4ae83cc6 100644 --- a/content/en/managed_services.md +++ b/content/en/managed_services.md @@ -5,10 +5,13 @@ category: Technology --- ## What it is + A managed service is a software offering where operations and management are taken care of by a third party. Examples include database as a service offerings like Amazon’s RDS or an external monitoring service like Datadog. ## Problem it addresses + Managing software is complex, especially considering all the different technologies that make up a modern stack. Managing each aspect of it and/or having in-house experts able to do so may be too expensive or not worth your engineers' time. Your team is likely better off building new capabilities than taking care of the operational tasks that can be easily outsourced. ## How it helps + Managed services are ready to use from day one with very little operational overhead. They allow organizations to effectively outsource tasks that fall outside of their core competency with well defined, and usually [API](/application_programming_interface/) driven, boundaries. diff --git a/content/en/microservices.md b/content/en/microservices.md index c73935e189..e30953f7c0 100644 --- a/content/en/microservices.md +++ b/content/en/microservices.md @@ -5,14 +5,15 @@ category: concept --- ## What it is + Microservices are a modern approach to application development that takes advantage of cloud native technologies. While modern applications, like Netflix, appear to be a single app, they are actually a collection of smaller services – all closely working together. For instance, a single page that allows you to access, search, and preview videos is likely powered by smaller services that each handle one aspect of it (e.g. search, authentication, and running previews in your browser). In short, microservices refer to an application architecture pattern usually contrasted with [monolithic applications](/monolithic_apps/). ## Problem it addresses + Microservices are a response to challenges posed by monolithic applications. Generally, different parts of an application will need to be [scaled](/scalability/) separately. An online store, for example, is going to have more product views than checkouts. That means you'll need more copies of the product view functionality running than the checkout. In a monolithic application, those bits of logic can't be deployed separately. If you can't scale the product functionality individually, you'll have to duplicate the entire app with all other components you don't need – an inefficient use of resources. Monolithic applications 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 often require developers to understand the entire codebase before they can be productive. ## How it helps + Separating functionality into different microservices makes them easier to deploy, update, and scale independently. By allowing different teams to focus on their own small part of a bigger application you also make it easier for them to work on their apps without negatively impacting the rest of the organization. While microservices solve many problems, they also create operational overhead—the things you need to deploy and keep track of increase by order of magnitude or more. Many [cloud-native technologies](/cloud_native_tech/) aim to make microservices easier to deploy and manage. - - diff --git a/content/en/monolithic_apps.md b/content/en/monolithic_apps.md index bc17d28d1a..4200b085a7 100644 --- a/content/en/monolithic_apps.md +++ b/content/en/monolithic_apps.md @@ -5,10 +5,13 @@ category: concept --- ## What it is + A monolithic application contains all functionality in a single deployable program. This is often the simplest and easiest place to start when making an application. However, once the application grows in complexity, monoliths can become hard to maintain. With more developers working on the same codebase, the likelihood of conflicting changes and the need for interpersonal communication between developers increases. ## Problem it Addresses + Devolving an application into [microservices](/microservices/) increases its operational overhead — there are more things to test, deploy, and keep running. Early in a product’s lifecycle, it may be advantageous to defer this complexity and build a monolithic application until the product is determined successful. ## How it Helps + A well-designed monolith can uphold lean principles by being the simplest way to get an application up and running. When the business value of the monolithic application proves successful, it can be decomposed into microservices. Crafting a microservices-based app before it has proven valuable may be premature spending of engineering effort. If the application yields no value, that effort becomes wasted. diff --git a/content/en/nodes.md b/content/en/nodes.md index e6ae6bc034..2e6f7abfe0 100644 --- a/content/en/nodes.md +++ b/content/en/nodes.md @@ -8,7 +8,6 @@ category: Concept A node is a computer that works in concert with other computers, or nodes, to accomplish a common task. Take your laptop, modem, and printer, for example. They are all connected over your wifi network communicating and collaborating, each representing one node. In [cloud computing](/cloud_computing/), a node can be a physical computer, a virtual computer, referred to as a VM, or even a [container](/container/). - ## Problem it addresses While an application could (and many do) run on one single machine, there are some risks involved with that. Namely that the failure of the underlying system will disrupt the application. To address this, developers started creating [distributed applications](/distributed_apps/) where each process runs on its own node. Thus, nodes run apps or processes as part of a group forming a [cluster](/cluster/), or group, of nodes that works together to achieve a common goal. @@ -16,4 +15,3 @@ While an application could (and many do) run on one single machine, there are so ## How it helps A node gives you a distinct unit of compute (memory, CPU, network) that you can assign to a cluster. In a cloud native platform or app a node represents a single unit that can perform work. Ideally, individual nodes are undifferentiated in that any one node of a particular type is indistinguishable from any other node of the same type. - diff --git a/content/en/observability.md b/content/en/observability.md index 8f54128fca..978049518c 100644 --- a/content/en/observability.md +++ b/content/en/observability.md @@ -7,4 +7,3 @@ category: property Observability is a characteristic of an application that refers to how well a system's state or status can be understood from its external outputs. Computer systems are measured by observing CPU time, memory, disk space, latency, errors, etc. The more observable a system is, the easier it is to understand how it’s doing by looking at it. The observability of a system has a significant impact on its operating cost. Observable systems yield meaningful, actionable data to their operators, allowing them to achieve favorable outcomes and less downtime. Note that more information does not necessarily translate into a more observable system. In fact, sometimes the amount of information generated by a system can make it harder to identify valuable health signals from the noise generated by the application. Observability requires the right data to make the right decisions. - diff --git a/content/en/platform_as_a_service.md b/content/en/platform_as_a_service.md index 07373b4cf1..f9450f2278 100644 --- a/content/en/platform_as_a_service.md +++ b/content/en/platform_as_a_service.md @@ -5,11 +5,13 @@ category: Technology --- ## What it is + A Platform as a Service, or PaaS, is an external platform for application development teams to deploy and run their apps. Heroku, Cloud Foundry, App Engine are examples of PaaS offerings. ## Problem it addresses + To take advantage of cloud native patterns like [microservices](/microservices/) or [distributed applications](/distributed_apps/), operations teams and developers need to be able to offload a significant amount of operations and maintenance work. These include tasks like provisioning infrastructure, handling [service discovery](/service_discovery/) and load balancing, and [scaling](/scalability/) applications. ## How it helps -A PaaS provides common infrastructure tools to application developers in a fully automated fashion. It allows developers to understand and worry less about infrastructure and devote more time and effort to writing application code. It also provides some monitoring and [observability](/observability/) to help application teams ensure their apps are healthy. +A PaaS provides common infrastructure tools to application developers in a fully automated fashion. It allows developers to understand and worry less about infrastructure and devote more time and effort to writing application code. It also provides some monitoring and [observability](/observability/) to help application teams ensure their apps are healthy. diff --git a/content/en/policy_as_code.md b/content/en/policy_as_code.md index c7fc1a96e4..0fa1327f4e 100644 --- a/content/en/policy_as_code.md +++ b/content/en/policy_as_code.md @@ -5,10 +5,13 @@ category: concept --- ## What it is + Policy as Code is the practice of storing the definition of policies as one or more files in machine readable and processable form. This replaces the traditional model where policies are documented in human-readable form, in separate documents. ## Problem it addresses + Building applications and infrastructures is often constrained by a lot of policies, that are defined by an organization, e.g. security policies that forbid to store secrets in source code, to run a container with superuser permissions, or to store some data outside a specific geo region. It is very labor-intensive and error-prone for developers and reviewers to manually check applications and infrastructure against documented policies. Manual checking against policies cannot meet the responsiveness and scale requirements of cloud native applications. ## How it helps + By using Policy as Code it is possible to automate the checking of system properties and actions. Best practices of software development can be applied to Policy as Code authoring, e.g. by using Git and associated workflows. diff --git a/content/en/reliability.md b/content/en/reliability.md index da3275fe20..92a744a98a 100644 --- a/content/en/reliability.md +++ b/content/en/reliability.md @@ -5,4 +5,3 @@ category: property --- From a cloud native perspective, reliability refers to how well a system responds to failures. If we have a [distributed system](/distributed_systems/) that keeps working as infrastructure changes and individual components fail, it is reliable. On the other hand, if it fails easily and operators need to intervene manually to keep it running, it is unreliable. The goal of [cloud native applications](/cloud_native_apps/) is to build inherently reliable systems. - diff --git a/content/en/scalability.md b/content/en/scalability.md index bafbba23f9..8b5d36cf49 100644 --- a/content/en/scalability.md +++ b/content/en/scalability.md @@ -7,5 +7,3 @@ category: property Scalability refers to how well a system can grow. That is increasing the ability to do whatever the system is supposed to do. For example, a [Kubernetes](/kubernetes/) [cluster](/cluster/) scales by increasing or reducing the number of [containerized](/containerization/) apps, but that scalability depends on several factors. How many [nodes](/nodes/) does it have, how many [containers](/container/) can each node handle, and how many records and operations can the control plane support? A scalable system makes it easy to add more capacity. We differentiate between two scaling approaches. On the one hand, there is [horizontal scaling](/horizontal_scaling/) which adds more nodes to handle increased load. In contrast, in [vertical scaling](/vertical_scaling/) individual nodes are made more powerful to perform more transactions (e.g. by adding more memory or CPU to an individual machine). A scalable system is able to change easily and meet user needs. - - diff --git a/content/en/security_chaos_engineering.md b/content/en/security_chaos_engineering.md index 60d6e49c3a..c40876be96 100644 --- a/content/en/security_chaos_engineering.md +++ b/content/en/security_chaos_engineering.md @@ -5,12 +5,15 @@ category: concept --- ## What it is + Security Chaos Engineering or SCE is a discipline based on [Chaos Engineering](/chaos_engineering/). SCE performs proactive security experimentation on a distributed system to build confidence in the system's capability to withstand turbulent and malicious conditions. Security chaos engineers use scientific method loops to achieve this, including steady-state, hypothesis, continuous verification, lesson learned, and mitigation implementation. ## Problem it addresses + The main priority for [site reliability engineers](/site_reliability_engineering/) (SREs) and cyber security engineers is to restore service as fast as possible with the goal of achieving zero downtime and minimizing business impact. SREs and cyber security engineers deal both with pre-failure and post-failure incidents situations. Most security issues are challenging to discover and patch quickly, impacting application or system functionality. Additionally, security incidents are usually tricky to uncover during the development phase. ## How it helps + Security Chaos Engineering is built around [observability](/observability/) and cyber resiliency practices. It aims to uncover the "unknown unknowns" and build confidence in the system, increasing cyber resiliency and improving observability. Engineering teams will progressively improve the understanding for security concerns 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 create confidence in the system, increase cyber resiliency and improve observability. diff --git a/content/en/serverless.md b/content/en/serverless.md index f9e6876bff..d844262d55 100644 --- a/content/en/serverless.md +++ b/content/en/serverless.md @@ -5,10 +5,13 @@ Category: Technology --- ## What it is + Serverless is a cloud native development model that allows developers to build and run applications without having to manage servers. There are still servers in serverless, but they are [abstracted](/abstraction/) away from app development. A cloud provider handles the routine work of provisioning, maintaining, and [scaling](/scalability/) the server infrastructure. Developers can simply package their code in [containers](/container/) for deployment. Once deployed, serverless apps respond to demand and automatically scale up and down as needed. Serverless offerings from public cloud providers are usually metered on-demand through an event-driven execution model. As a result, when a serverless function is sitting idle, it doesn’t cost anything. ## Problem it addresses + Under a standard [Infrastructure-as-a-Service (IaaS)](/infrastructure_as_a_service/) [cloud computing](/cloud_computing/) model, users pre-purchase units of capacity, meaning you pay a public cloud provider for always-on server components to run your apps. It’s the user’s responsibility to scale up server capacity during times of high demand and to scale down when that capacity is no longer needed. The cloud infrastructure necessary to run an app is active even when the app isn’t being used. ## How it helps + With serverless architecture, by contrast, apps are launched only as needed. When an event triggers app code to run, the public cloud provider dynamically allocates resources for that code. The user stops paying when the code finishes executing. In addition to the cost and efficiency benefits, serverless frees developers from routine and menial tasks associated with app scaling and server provisioning. With serverless, routine tasks such as managing the operating system and file system, security patches, load balancing, capacity management, scaling, logging, and monitoring are all offloaded to a cloud services provider. diff --git a/content/en/service.md b/content/en/service.md index f9fd126006..fc3ef5a40c 100644 --- a/content/en/service.md +++ b/content/en/service.md @@ -5,4 +5,3 @@ category: concept --- Please note that in IT, service has multiple meanings. In this definition, we'll focus on the more traditional one: service as in microservice. How or even if services differ from microservices is nuanced and different people may have different opinions. For a high-level definition, we'll treat them as the same. Please refer to the [microservices](/microservices/) definition. - diff --git a/content/en/service_discovery.md b/content/en/service_discovery.md index a13dbb3d81..3e95d13e51 100644 --- a/content/en/service_discovery.md +++ b/content/en/service_discovery.md @@ -5,10 +5,13 @@ category: concept --- ## What it is + Service discovery is the process of finding individual instances that make up a service. A service discovery tool keeps track of the various nodes or endpoints that make up a service. ## Problem it addresses + Cloud native architectures are dynamic and fluid, meaning they are constantly changing. A [containerized](/containerization/) app will likely end up starting and stopping multiple times in its lifetime. Each time that happens, it will have a new address and any app that wants to find it needs a tool to provide the new location information. ## How it helps + Service discovery keeps track of apps within the network so they can find one another when needed. It provides a common place to find and potentially identify individual services. Service discovery engines are database-like tools that store info about what services exist and how to locate them. diff --git a/content/en/service_mesh.md b/content/en/service_mesh.md index 9503c3b6b6..75f0b7715a 100644 --- a/content/en/service_mesh.md +++ b/content/en/service_mesh.md @@ -5,10 +5,13 @@ category: technology --- ## What it is + In a [microservices](/microservices/) world, apps are broken down into multiple smaller [services](/service/) that communicate over a network. Just like your wifi network, computer networks are intrinsically unreliable, hackable, and often slow. Service meshes address this new set of challenges by managing traffic (i.e., communication) between services and adding [reliability](/reliability/), [observability](/observability/), and security features uniformly across all services. ## Problem it addresses + Having moved to a microservices architecture, engineers are now dealing with hundreds, possibly even thousands of individual services, all needing to communicate. That means a lot of traffic is going back and forth over the network. On top of that, individual applications may need to encrypt communications to support regulatory requirements, provide common metrics to operations teams, or provide detailed insight into traffic to help diagnose issues. If built into the individual applications, each one of these features will cause friction between teams and slow down development of new features. ## How it helps + Service meshes add reliability, observability, and security features uniformly across all services across a cluster without requiring code changes. Before service meshes, that functionality had to be encoded into every single service, becoming a potential source of bugs and technical debt. diff --git a/content/en/service_proxy.md b/content/en/service_proxy.md index 206b06b846..959498fbb1 100644 --- a/content/en/service_proxy.md +++ b/content/en/service_proxy.md @@ -5,15 +5,17 @@ category: technology --- ## What it is + A service proxy intercepts traffic to or from a given [service](/service/), applies some logic to it, then forwards that traffic to another service. It essentially acts as a “go-between” that collects information about network traffic and/or applies rules to it. ## Problem it addresses + To keep track of service to service communication (aka network traffic) and potentially transform or redirect it, we need to collect data. Traditionally, the code enabling data collection and network traffic management was embedded within each application. ## How it helps + A service proxy allows us to “externalize” this functionality. No longer does it need to live within the apps. Instead, it’s now embedded into the platform layer (where your apps run). Acting as gatekeepers between services, proxies provide insight into what type of communication is happening. Based on their insight, they determine where to send a particular request or even deny it entirely. Proxies gather critical data, manage routing (spreading traffic evenly among services or rerouting if some services break down), encrypt connections, and cache content (reducing resource consumption). - diff --git a/content/en/shift_left.md b/content/en/shift_left.md index 740736e00a..8cde7f21a6 100644 --- a/content/en/shift_left.md +++ b/content/en/shift_left.md @@ -5,14 +5,17 @@ category: Concept --- ## What it is + Left in Shift Left refers to earlier stages in a software development lifecycle, thinking of the lifecycle as a line where stages are executed from left to right. Shift Left is the practice of implementing tests, security, or other development practices early in the software development lifecycle rather than towards the end. Although originally used to refer to the process of testing early, Shift Left can now also be applied to other aspects of software development and [DevOps](/devops/), such as security and deployment. ## Problem it addresses + Security issues, bugs, and software defects can be more difficult and expensive to fix if they are discovered late in the development cycle or after deployment, particularly if the software has already been deployed into production. ## How it helps + By adopting a Shift Left mindset for software development, teams can implement testing and security throughout the development lifecycle. And because responsibility for testing and security is shared across the development team — from software engineers to quality assurance to operations — everyone plays a part in ensuring the stability and security of an application. In addition, shifting left enables continuous improvement and follows an [agile](/agile_software_development/) rather than waterfall approach to development. Teams can make small iterative improvements and identify problems earlier on. This approach allows engineers to adopt security and secure development practices as early as the design and architecture phase. Testing throughout the development cycle, decreases the time required for testing before a software release. diff --git a/content/en/site_reliability_engineering.md b/content/en/site_reliability_engineering.md index 55bff9ba46..229e61059f 100644 --- a/content/en/site_reliability_engineering.md +++ b/content/en/site_reliability_engineering.md @@ -5,10 +5,13 @@ category: concept --- ## What it is + Site Reliability Engineering or SRE is a discipline that combines operations and software engineering. The latter is applied to infrastructure and operations problems, specifically. Meaning, instead of building product features, Site Reliability Engineers build systems to run applications. There are similarities with DevOps, but while DevOps focuses on getting code to production, SRE ensures that code running in production works properly. ## Problem it addresses + Ensuring applications run reliably requires multiple capabilities, from performance monitoring, alerting, debugging to troubleshooting. Without these, system operators can only react to problems vs. proactively working towards avoiding them — downtime only becomes a matter of time. ## How it helps + An SRE approach minimizes the cost, time, and effort of the software development process by continuously improving the underlying system. The system continuously measures and monitors the infrastructure and application components. When something goes wrong, the system points Site Reliability Engineers to when, where, and how to fix it. This approach helps create highly scalable and reliable software systems by automating operational tasks. diff --git a/content/en/vertical_scaling.md b/content/en/vertical_scaling.md index 752d0dbaf3..5ffbb6fdb4 100644 --- a/content/en/vertical_scaling.md +++ b/content/en/vertical_scaling.md @@ -17,5 +17,6 @@ As demand for an application grows beyond the current capacity of that applicati Vertical scaling allows you to resize your server without changing the application code. That contrasts to horizontal scaling, where the app must be replicable to scale, potentially requiring code updates. Vertical scaling increases the capacity of an existing application by adding compute resources, allowing the app to process more requests and do more work concurrently. ## Related terms + * [Horizontal Scaling](/horizontal_scaling/) * [Auto Scaling](/auto_scaling/) diff --git a/content/en/virtualization.md b/content/en/virtualization.md index eaf2ec3256..23f2ec5f48 100644 --- a/content/en/virtualization.md +++ b/content/en/virtualization.md @@ -5,10 +5,13 @@ category: technology --- ## What it is + Virtualization, in the context of cloud native computing, refers to the process of taking a physical computer, sometimes called a server, and allowing it to run multiple isolated operating systems. Those isolated operating systems and their dedicated compute resources (CPU, memory, and network) are referred to as virtual machines or VMs. When we talk about a virtual machine, we’re talking about a software-defined computer. Something that looks and acts like a real computer but is sharing hardware with other virtual machines. As an example, you can lease a "computer" from AWS – that computer is actually a VM. ## Problem it addresses + Virtualization addresses a number of problems, including the improvement of physical hardware usage by allowing more apps to run on the same physical machine whilst still being isolated from each other for security. ## How it helps + Apps running on virtual machines have no awareness that they are sharing a physical computer. Virtualization also allows the users of the datacenter to spin up a new "computer" (aka a VM) in minutes without worrying about the physical constraints of adding a new computer to a datacenter. VMs also enable users to speed up the time to get a new virtual computer. diff --git a/content/en/zero_trust_architecture.md b/content/en/zero_trust_architecture.md index 2a1caeba89..f59d16a305 100644 --- a/content/en/zero_trust_architecture.md +++ b/content/en/zero_trust_architecture.md @@ -5,10 +5,13 @@ category: Concept --- ## What it is + Zero trust architecture prescribes to an approach to the design and implementation of IT systems where trust is completely removed. The core principle being "never trust, always verify", devices or systems themselves, whilst communicating to other components of a system, always verify themselves before doing so. In many networks today, within the corporate network, systems and devices inside may freely communicate with each other as they are within the trusted boundary of the corporate network perimeter. Zero trust architecture takes the opposite approach where although inside the network perimeter, components within the system first have to pass verification before any communication is made. ## Problem it addresses + With the traditional trust based approach where systems and devices that exist within a corporate network perimeter, the assumption is that because there is trust, there is no problem. Zero trust architecture however, recognises that trust is a vulnerability. In the event where an attacker has gained access to a trusted device, depending on the level of trust and access that has been given to that device, the system is now vulnerable to attack as the attacker is within the "trusted" network perimeter and is able to move laterally throughout the system. In a zero trust architecture, trust is removed, therefore reducing the attack surface as an attacker is now forced to verify before going any further throughout the system. ## How it helps + Adopting a zero trust architecture brings the principal benefit of increased security with a reduction in the attack surface. Removing trust from your corporate system now increases the number and strength of security gates that an attacker has to go through to gain access to other areas of the system. diff --git a/content/es/.gitkeep b/content/es/.gitkeep deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/content/es/contribute/_index.md b/content/es/contribute/_index.md index d0beec0397..daeac925b8 100644 --- a/content/es/contribute/_index.md +++ b/content/es/contribute/_index.md @@ -41,7 +41,7 @@ Una vez que te lo asignen, puedes empezar a trabajar en él. Para conocer los pr Puede proponer un nuevo término para que otros trabajen en él o crear una nueva definición usted mismo. De cualquier forma, comenzará creando un issue (tenga en cuenta que necesitará una cuenta de GitHub para hacerlo). -A continuación se muestra una guía paso a paso para aquellos que aún no están familiarizados con GitHub. **Si eres un profesional de GitHub**, *da* un vistazo rápido para asegurarte de que usas nuestras plantillas de issues, las convenciones de nomenclatura, solicita un PR en Slack (de lo contrario, podemos perderlo) y dónde encontrar la plantilla del archivo. Y asegúrese de leer la [Guía de estilo](/es/style-guide/) antes de comenzar. ¡Gracias! +A continuación se muestra una guía paso a paso para aquellos que aún no están familiarizados con GitHub. **Si eres un profesional de GitHub**, _da_ un vistazo rápido para asegurarte de que usas nuestras plantillas de issues, las convenciones de nomenclatura, solicita un PR en Slack (de lo contrario, podemos perderlo) y dónde encontrar la plantilla del archivo. Y asegúrese de leer la [Guía de estilo](/es/style-guide/) antes de comenzar. ¡Gracias! ### Creando un issue {#creating-an-issue} diff --git a/content/hi/_TEMPLATE.md b/content/hi/_TEMPLATE.md index b5896178c5..9fc457ed90 100644 --- a/content/hi/_TEMPLATE.md +++ b/content/hi/_TEMPLATE.md @@ -6,10 +6,13 @@ exclude_search: true --- ## यह क्या है + अवधारणा का एक त्वरित सारांश। ## समस्या + समस्या को संबोधित करते हुए कुछ पंक्तियाँ। ## समाधान + वह चीज़ कैसे समस्या का समाधान करती है, इसका वर्णन। diff --git a/content/hi/agile_software_development.md b/content/hi/agile_software_development.md index 8fc52fd3e1..b965df5e05 100644 --- a/content/hi/agile_software_development.md +++ b/content/hi/agile_software_development.md @@ -6,10 +6,13 @@ exclude_search: true --- ## यह क्या है + प्रथाओं का एक सेट जो पुनरावृत्त विकास चक्रों और स्वयं-संगठित टीमों पर जोर देता है। जलप्रपात जैसी परियोजनाओं के विपरीत जहां मूल्य केवल एक परियोजना के अंत में उत्पन्न होता है, एजाइल सॉफ्टवेयर विकास मूल्य की निरंतर, वृद्धिशील वितरण और प्रक्रिया के विकासवादी सुधार पर केंद्रित है। ## समस्या + एक सॉफ्टवेयर प्रोजेक्ट में सभी हितधारकों के लिए आवश्यकताओं को परिभाषित करना, संप्रेषित करना और समझना बहुत कठिन है। फिर भी, ग्राहक चाहते हैं कि उनके सॉफ्टवेयर प्रोजेक्ट समय पर, अच्छी गुणवत्ता में, बजट पर और दायरे में वितरित किए जाएं। अपनी चक्रीय प्रकृति के साथ, एजाइल सॉफ्टवेयर विकास आवश्यकताओं के निरंतर अनुकूलन और अन्य सभी परिस्थितियों के लिए तेजी से अनुकूलन को सक्षम बनाता है, जो जलप्रपात जैसी रणनीतियों के विपरीत है। ## समाधान + एजाइल सॉफ्टवेयर विकास में पारंपरिक रणनीतियों के सभी चरण, जैसे आवश्यकताएं इंजीनियरिंग, योजना, कार्यान्वयन, समीक्षा, परीक्षण और वितरण शामिल हैं। सबसे बड़ा अंतर यह है कि एक सॉफ्टवेयर प्रोजेक्ट के पूरे समय को पुनरावृत्तियों में काट दिया जाता है, जिनमें से प्रत्येक में वे सभी चरण होते हैं। प्रत्येक पुनरावृत्ति के बाद, ग्राहक के साथ बनाए गए मूल्य की समीक्षा की जा सकती है और आवश्यकताओं को अंतिम लक्ष्य की ओर समायोजित किया जा सकता है। इसके अतिरिक्त विकास दल(development team)पूर्व-निरीक्षण करता है कि प्रक्रिया को बेहतर बनाने के लिए किन कार्यों को करना है। diff --git a/content/hi/auto_scaling.md b/content/hi/auto_scaling.md index 74542b9ee2..8124e4a17e 100644 --- a/content/hi/auto_scaling.md +++ b/content/hi/auto_scaling.md @@ -10,5 +10,3 @@ exclude_search: true पहले, आधारिक संरचना और एप्लीकेशन्स को सिस्टम के चरम उपयोग के विचार से तैयार किया गया था। इस वास्तुकला का मतलब था अधिक संसाधनों का कम उपयोग और बदल्ते उपभोक्ता मांग को सम्पूर्ण करने में अयोग्यता। जिसका मतलब व्यवसाय की उच्च लागत और अधिक मांग के कारण आउटेज से व्यवसाय खो जाना था। क्लाउड, एप्लीकेशन को [वर्चुअल बनाकर](/virtualization/), [कन्टेनरीकृत कर](/hi/containerization/) और उनकी निर्भरता का लाभ उठाकर, संगठन उपयोगकर्ता की मांगों के अनुसार बड़े पैमाने पर एप्लीकेशन बना सकते हैं। वे एप्लीकेशन की मांग की निगरानी कर सकते हैं और इष्टतम उपयोगकर्ता अनुभव प्रदान करते हुए स्वचालित रूप से उन्हें स्केल कर सकते हैं। हर शुक्रवार शाम को Netflix के दर्शकों की संख्या में वृद्धि को लें। ऑटोस्केलिंग का अर्थ है गतिशील रूप से अधिक संसाधन जोड़ना: उदाहरण के लिए, अधिक वीडियो स्ट्रीमिंग वाले सर्वरों की संख्या में वृद्धि और खपत सामान्य होने के बाद वापस स्केलिंग। - - diff --git a/content/hi/canary_deployment.md b/content/hi/canary_deployment.md index 56b80e6cee..1098ebd6eb 100644 --- a/content/hi/canary_deployment.md +++ b/content/hi/canary_deployment.md @@ -6,6 +6,7 @@ exclude_search: true --- ## यह क्या है + कैनरी डिप्लॉयमेंट (Canary deployment), एक डिप्लॉयमेंट रणनीति है जिसकी शुरुआत दो एनवायरनमेंट से होती है: एक लाइव ट्रैफिक के साथ और दूसरा जिसमे अपडेटेड कोड हो बिना लाइव ट्रैफिक के। ट्रैफिक को धीरे-धीरे एप्लीकेशन के मूल संस्करण से अपडेटेड संस्करण में लाया जाता है। यह 1% लाइव ट्रैफ़िक, फिर 10%, 25%, इत्यादि को स्थानांतरित करके शुरू कर सकता है, जब तक कि सभी ट्रैफ़िक अपडेट किए गए संस्करण के माध्यम से नहीं चल रहे हों। संगठन उत्पादन में सॉफ़्टवेयर के नए संस्करण का परीक्षण कर सकते हैं, प्रतिक्रिया प्राप्त कर सकते हैं, त्रुटियों का निदान कर सकते हैं, और यदि आवश्यक हो तो स्थिर संस्करण में त्वरित रूप से रोलबैक कर सकते हैं। "कैनरी" शब्द "कोयला खदान में कैनरी" प्रथा को संदर्भित करता है जहां खनिकों को सुरक्षित रखने के लिए कैनरी पक्षियों को कोयला खदानों में ले जाया जाता था। यदि गंधहीन हानिकारक गैसें मौजूद होतीं, तो पक्षी मर जाता, और खनिक जानते थे कि उन्हें जल्दी से निकलना होगा। इसी तरह, अगर अपडेट किए गए कोड में कुछ गलत हो जाता है, तो लाइव ट्रैफ़िक को मूल संस्करण में वापस कर दिया जाता है। diff --git a/content/hi/container.md b/content/hi/container.md index 5188f2adb3..7b430b755c 100644 --- a/content/hi/container.md +++ b/content/hi/container.md @@ -6,12 +6,15 @@ exclude_search: true --- ### यह क्या है + कंटेनर एक प्रक्रिया है जिसके संसाधन और क्षमता, कंप्यूटर के ऑपरेटिंग सिस्टम द्वारा प्रबंधित होती है। कंटेनर प्रक्रिया के लिए उपलब्ध फ़ाइलें एक कंटेनर इमेज के रूप में पैक की जाती हैं। कंटेनर एक ही मशीन पर एक दूसरे से सटे चलते हैं, लेकिन आमतौर पर ऑपरेटिंग सिस्टम भिन्न कंटेनर प्रक्रियाओं को एक दूसरे के साथ इंटरैक्ट करने से रोकता है। ### समस्या + कंटेनर उपलब्ध होने से पहले, अप्लीकेशनों को चलाने के लिए अलग मशीनें आवश्यक थीं। प्रत्येक मशीन को अपने स्वयं के ऑपरेटिंग सिस्टम की आवश्यकता होगी, जो एक व्यक्तिगत एप्लीकेशन को कार्य करने के लिए CPU, मेमोरी और डिस्क स्पेस लेता है। इसके अतिरिक्त, ऑपरेटिंग सिस्टम का रखरखाव, उन्नयन और स्टार्टअप एक कठिन कार्य है। ### समाधान + कंटेनर एक ही ऑपरेटिंग सिस्टम और उसके मशीन संसाधनों को साझा करते हैं, ऑपरेटिंग सिस्टम के संसाधन को फैलाते हैं और भौतिक मशीन का कुशल उपयोग करते हैं। यह क्षमता केवल इसलिए संभव है क्योंकि कंटेनर आमतौर पर एक दूसरे के साथ बातचीत करने में सक्षम होने से सीमित होते हैं। यह एक ही भौतिक मशीन पर कई और अप्पलीकेशन चलाने की अनुमति देता है। हालाँकि, कुछ सीमाएँ हैं। चूँकि कंटेनर एक ही ऑपरेटिंग सिस्टम साझा करते हैं, इसलिए प्रक्रियाओं को विकल्पों की तुलना में कम सुरक्षित माना जा सकता है। कंटेनरों को भी साझा संसाधनों पर सीमा की आवश्यकता होती है। संसाधनों की गारंटी के लिए, एडमिनिस्ट्रेटर्स (प्रशासकों) को मेमोरी और CPU के उपयोग को सीमित करना चाहिए ताकि अन्य एप्लिकेशन खराब प्रदर्शन न करें। diff --git a/content/hi/continuous_delivery.md b/content/hi/continuous_delivery.md index cb0f0ea5e8..b150214182 100644 --- a/content/hi/continuous_delivery.md +++ b/content/hi/continuous_delivery.md @@ -6,12 +6,13 @@ exclude_search: true --- ## यह क्या है + निरंतर डिलीवरी, जिसे अक्सर CD के रूप में संक्षिप्त किया जाता है, प्रथाओं का एक समूह है जिसमें कोड परिवर्तन स्वचालित रूप से एक स्वीकृति वातावरण में (या, निरंतर डिप्लॉयमेंट के मामले में, उत्पादन में) डेप्लॉय किए जाते हैं। CD में महत्वपूर्ण रूप से यह सुनिश्चित करने के लिए प्रक्रियाएं शामिल हैं कि डिप्लॉयमेंट से पहले सॉफ़्टवेयर का पर्याप्त रूप से परीक्षण किया गया है और यदि आवश्यक समझा जाता है तो यह रोलबैक परिवर्तनों का एक तरीका प्रदान करता है। निरंतर डिलीवरी की दिशा में पहला कदम निरंतर इंटीग्रेशन (CI) है (अर्थात, परिवर्तनों को परीक्षण और डेप्लॉय करने से पहले, उन्हें साफ-सुथरे रूप से मर्ज करना)। ## समस्या + [विश्वसनीय](/reliability/) अपडेट को बड़े पैमाने पर डेप्लॉय करना एक समस्या बन जाता है। आदर्श रूप से, हम अंतिम-उपयोगकर्ताओं को बेहतर मूल्य प्रदान करने के लिए अधिक बार डेप्लॉय करते हैं। हालाँकि, इसे मैन्युअल रूप से करने से प्रत्येक परिवर्तन के लिए, अधिक खर्च होता हैं। ऐतिहासिक रूप से, इन खर्चो से बचने के लिए, संगठनों ने कम बार रिलीज़ करते है, एक बार में अधिक परिवर्तन डेप्लॉय करने पर कुछ गलत होने का जोखिम बढ़ जाता है। ## समाधान -CD रणनीतियाँ उत्पादन के लिए एक पूरी तरह से स्वचालित पथ बनाती हैं जो विभिन्न डिप्लॉयमेंट रणनीतियों जैसे: [कैनरी](/hi/canary_deployment/) या [ब्लू-ग्रीन](/blue_green_deployment/) रिलीज़ का उपयोग करके सॉफ़्टवेयर का परीक्षण और उसको डिप्लॉय करती है। यह डेवलपर्स को बार-बार कोड डिप्लॉय करने की अनुमति देता है, जिससे उन्हें मानसिक शांति मिलती है कि नए संशोधन का परीक्षण किया गया है। आम तौर पर, फीचर ब्रांचिंग या पुल रिक्वेस्ट (PR) के विपरीत, CD रणनीतियों में ट्रंक-आधारित विकास का उपयोग किया जाता है। - +CD रणनीतियाँ उत्पादन के लिए एक पूरी तरह से स्वचालित पथ बनाती हैं जो विभिन्न डिप्लॉयमेंट रणनीतियों जैसे: [कैनरी](/hi/canary_deployment/) या [ब्लू-ग्रीन](/blue_green_deployment/) रिलीज़ का उपयोग करके सॉफ़्टवेयर का परीक्षण और उसको डिप्लॉय करती है। यह डेवलपर्स को बार-बार कोड डिप्लॉय करने की अनुमति देता है, जिससे उन्हें मानसिक शांति मिलती है कि नए संशोधन का परीक्षण किया गया है। आम तौर पर, फीचर ब्रांचिंग या पुल रिक्वेस्ट (PR) के विपरीत, CD रणनीतियों में ट्रंक-आधारित विकास का उपयोग किया जाता है। diff --git a/content/hi/continuous_integration.md b/content/hi/continuous_integration.md index 0b143f1974..36ed13ca8d 100644 --- a/content/hi/continuous_integration.md +++ b/content/hi/continuous_integration.md @@ -15,4 +15,4 @@ exclude_search: true ## समाधान -जब कभी भी कोई डेवलपर परिवर्तन कमिट करता है, CI सॉफ्टवेयर स्वचालित रूप से जाँच करता है की कोड अच्छे से मर्ज हो जाए। यह लगभग एक सर्वव्यापी अभ्यास है की हम CI सर्वर का उपयोग कोड की गुणवत्ता की जाँच, परिक्षण और यहां तक ​​कि डेप्लोय्मेंट्स के लिए भी करते है। इसी चलते यह टीमों के भीतर कोड परिक्षण के लिए एक ठोस कार्यान्वयन बन जाता है। CI सॉफ्टवेयर टीमों को अनुमति देता है की वह किसी भी कोड कमिट को या तो ठोस असफलता या फिर एक व्यवहार्य रिलीज में बदल सकते हैं। +जब कभी भी कोई डेवलपर परिवर्तन कमिट करता है, CI सॉफ्टवेयर स्वचालित रूप से जाँच करता है की कोड अच्छे से मर्ज हो जाए। यह लगभग एक सर्वव्यापी अभ्यास है की हम CI सर्वर का उपयोग कोड की गुणवत्ता की जाँच, परिक्षण और यहां तक कि डेप्लोय्मेंट्स के लिए भी करते है। इसी चलते यह टीमों के भीतर कोड परिक्षण के लिए एक ठोस कार्यान्वयन बन जाता है। CI सॉफ्टवेयर टीमों को अनुमति देता है की वह किसी भी कोड कमिट को या तो ठोस असफलता या फिर एक व्यवहार्य रिलीज में बदल सकते हैं। diff --git a/content/hi/contribute/_index.md b/content/hi/contribute/_index.md index 7aae367433..8072d80530 100644 --- a/content/hi/contribute/_index.md +++ b/content/hi/contribute/_index.md @@ -15,15 +15,18 @@ menu: 2) मौजूदा शब्द अपडेट करें 3) शब्दकोष का अनुवाद करने में सहायता करें -## शब्दावली समुदाय में शामिल हों! +## शब्दावली समुदाय में शामिल हों + यदि आप नियमित रूप से योगदान देना चाहते हैं, तो हमारी मासिक शब्दावली कार्य समूह की बैठकों में शामिल होने पर विचार करें। आप CNCF कैलेंडर में मीटिंग विवरण प्राप्त कर सकते हैं। आप [CNCF कैलेंडर](https://www.cncf.io/calendar/) पर हमारे #glossary मेन्टेनेरों और साथी योगदानकर्ताओं से भी जुड़ सकते हैं — हमें आपसे मिलकर खुशी होगी! ## नए शब्द प्रस्तावित करें + आप दूसरों के द्वारा परिभाषित होने को नये शब्द प्रस्तावित कर सकते हैं या स्वयं एक नई परिभाषा लिख सकते हैं। किसी भी तरह से, आप एक समस्या बनाकर शुरू करेंगे (ध्यान दें कि ऐसा करने के लिए आपको एक GitHub खाते की आवश्यकता होगी)। नीचे उन लोगों के लिए चरण-दर-चरण मार्गदर्शिका दी गई है जो GitHub से परिचित नहीं हैं। **यदि आप गिटहब में निपुण हैं**, तो कृपया सुनिश्चित *करें* कि आप हमारे इशू टेम्प्लेट, उपयुक्त नामकरण परंपराओं का उपयोग करते हैं, Slack पर एक PR पर दावा करते हैं (अन्यथा हमसे चूक हो सकती है), और फ़ाइल टेम्पलेट कहां खोजें। कृपया शुरू करने से पहले [शैली मार्गदर्शिका](/hi/style-guide/) पढ़ना सुनिश्चित करें — धन्यवाद! ### इशू बनाना + [शब्दावली गिटहब रेपो](https://github.com/cncf/glossary/issues) issue पर जाएं और "new issue" पर क्लिक करें। ![इशू](/images/how-to/howto-01.png) @@ -85,9 +88,11 @@ URL में शब्द (कोई कैपिटलाइज़ेशन(ca ![prs](/images/how-to/howto-13.png) ## मौजूदा शब्द अपडेट करें + किसी मौजूदा शब्द को अपडेट करने के लिए, आप या तो किसी इशू के माध्यम से बदलाव का सुझाव दे सकते हैं या पुल अनुरोध (PR) सबमिट करके सीधे शब्द को अपडेट कर सकते हैं। ### इशू के ज़रिए बदलाव का अनुरोध करें + यदि आप कसी शब्द में किसी त्रुटि की सुचना देना चाहते हैं, लेकिन यह नहीं जानते कि इसे स्वयं कैसे ठीक करना है या नहीं करना चाहते हैं, तो "report issue" पर क्लिक करें। ![report issue](/images/how-to/howto-14.png) @@ -97,6 +102,7 @@ URL में शब्द (कोई कैपिटलाइज़ेशन(ca ![submit issue](/images/how-to/howto-15.png) ### शब्द को सीधे अपडेट करें + किसी शब्द को सीधे बदलने के लिए, "edit this page" पर जाएं। ![edit this page](/images/how-to/howto-16.png) @@ -104,8 +110,5 @@ URL में शब्द (कोई कैपिटलाइज़ेशन(ca इससे शब्द का GitHub पेज खुल जाएगा. अपने परिवर्तन करें और एक PR जमा करें। विस्तृत विवरण के लिए कृपया ऊपर "नया शब्द जमा करना" देखें (मार्कडाउन के बारे में बात करने वाले अनुभाग पर जाएं)। ## शब्दावली के अनुवाद में सहायता करें -शब्दावली का अपनी मूल भाषा में अनुवाद करने में सहायता के लिए, कृपया CNCF Slack पर #glossary-localizations चैनल से जुड़ें और हमें बताएं। आप किसी मौजूदा टीम में शामिल हो सकते हैं या एक नई टीम बना सकते हैं (विस्तृत विवरण के लिए [स्थानीयकरण मार्गदर्शिका](https://github.com/cncf/glossary/blob/main/LOCALIZATION.md) देखें)। कृपया हमारी मासिक शब्दावली कार्य समूह की बैठकों में भी शामिल हों। आप [CNCF कैलेंडर](https://www.cncf.io/calendar/) में मीटिंग विवरण पा सकते हैं। हम आपसे वहां मिलने के लिए उत्सुक हैं! - - - +शब्दावली का अपनी मूल भाषा में अनुवाद करने में सहायता के लिए, कृपया CNCF Slack पर #glossary-localizations चैनल से जुड़ें और हमें बताएं। आप किसी मौजूदा टीम में शामिल हो सकते हैं या एक नई टीम बना सकते हैं (विस्तृत विवरण के लिए [स्थानीयकरण मार्गदर्शिका](https://github.com/cncf/glossary/blob/main/LOCALIZATION.md) देखें)। कृपया हमारी मासिक शब्दावली कार्य समूह की बैठकों में भी शामिल हों। आप [CNCF कैलेंडर](https://www.cncf.io/calendar/) में मीटिंग विवरण पा सकते हैं। हम आपसे वहां मिलने के लिए उत्सुक हैं! diff --git a/content/hi/contributor-ladder/_index.md b/content/hi/contributor-ladder/_index.md index 7fe30e31dd..0a7aabee2e 100644 --- a/content/hi/contributor-ladder/_index.md +++ b/content/hi/contributor-ladder/_index.md @@ -96,4 +96,4 @@ menu: ## पुरानी भूमिका में वापस आना -यदि और जब कोई पिछली योगदानकर्ता भूमिका में वापस जाने के लिए उपलब्ध होता है, तो परियोजना नेतृत्व इसकी व्यवस्था और इस पर विचार कर सकता है। \ No newline at end of file +यदि और जब कोई पिछली योगदानकर्ता भूमिका में वापस जाने के लिए उपलब्ध होता है, तो परियोजना नेतृत्व इसकी व्यवस्था और इस पर विचार कर सकता है। diff --git a/content/hi/devops.md b/content/hi/devops.md index 562e9b3ec4..a253a1280c 100644 --- a/content/hi/devops.md +++ b/content/hi/devops.md @@ -6,12 +6,15 @@ exclude_search: true --- ## यह क्या है + DevOps एक कार्यप्रणाली है जिसमें टीम अनुप्रयोग विकास से लेकर उत्पादन संचालन तक की पूरी प्रक्रिया का स्वामी है। यह प्रौद्योगिकियों के एक सेट को लागू करने से परे है और इसके लिए संस्कृति और प्रक्रियाओं में पूर्ण बदलाव की आवश्यकता है। DevOps इंजीनियरों के उन समूहों को कहते हैं जो छोटे घटकों (बनाम एक संपूर्ण सुविधा) पर काम करके जटिलता को कम करते हैं। ## समस्या + परंपरागत रूप से, [टाइटली-कपल्ड](/tightly_coupled_architectures/) [मोनोलिथिक ऐप्स](/monolith_apps/) का प्रयोग वाले जटिल संगठनों में, काम आम तौर पर कई समूहों के बीच खंडित होता था। इसमें एप्लीकेशन कई टीमों के बीच जाता था और काफी लम्बा समय लगता था। हर बार जब कोई घटक या अपडेट तैयार होता था, तो उसे अगली टीम के लिए एक कतार में रखा जाता था। क्योंकि प्रत्येक व्यक्ति केवल परियोजना के एक छोटे से हिस्से पर काम करता था, इस दृष्टिकोण के कारण स्वामित्व की कमी होती थी। उनका लक्ष्य काम को अगले समूह तक पहुंचाना था, न कि ग्राहक को सही कार्यक्षमता प्रदान करना - प्राथमिकताओं का एक स्पष्ट गलत संरेखण। जब तक कोड अंततः उत्पादन में आया, तब तक यह इतने सारे डेवलपर्स के माध्यम से चला गया, इतनी कतारों में प्रतीक्षा कर रहा था कि यदि कोड काम नहीं करता है तो समस्या की उत्पत्ति का पता लगाना मुश्किल था। DevOps ने इस दृष्टिकोण को पलट कर रख दिया। ## समाधान + एक टीम के पास एक आवेदन के पूरे जीवनचक्र का स्वामित्व कम से कम हैंडऑफ़ में होता है, उत्पादन में तैनात करते समय जोखिम को कम करता है, बेहतर कोड गुणवत्ता के रूप में टीम भी जिम्मेदार होती है कि कोड उत्पादन में कैसा प्रदर्शन करता है और अधिक स्वायत्तता और स्वामित्व के कारण कर्मचारियों की संतुष्टि में वृद्धि होती है। diff --git a/content/hi/style-guide/_index.md b/content/hi/style-guide/_index.md index 48c01f87c1..1515fe2433 100644 --- a/content/hi/style-guide/_index.md +++ b/content/hi/style-guide/_index.md @@ -123,7 +123,6 @@ category: अवधारणा आरंभ करने से पहले, कृपया विस्तार और कठिनाई के स्तर को समझने के लिए और जब उदाहरण उपयुक्त हों, कुछ प्रकाशित शब्दावली शब्दों को पढ़ें। - ## समीक्षा प्रक्रिया: क्या उम्मीद करें कृपया ध्यान दें कि वर्तमान में हम केवल चार अनुरक्षक हैं जो अपने खाली समय में यह कर रहे हैं। कभी-कभी, हम शब्दों की शीघ्रता से समीक्षा कर सकेंगे; अन्य अवसरों पर, इसमें कुछ समय लग सकता है — हम आपके धैर्य की सराहना करते हैं। यदि आपके कोई प्रश्न हैं, तो कृपया #glossary Slack चैनल में हमसे संपर्क करें (इसे कहां और कैसे खोजा जाए, इसके लिए कृपया हमारा [योगदान कैसे करें](/hi/contribute/) दस्तावेज़ देखें)। diff --git a/content/it/.gitkeep b/content/it/.gitkeep deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/content/it/_index.md b/content/it/_index.md index 8121f871dd..48ebd8807b 100644 --- a/content/it/_index.md +++ b/content/it/_index.md @@ -1,4 +1,3 @@ - --- title: "Glossario Cloud Native" --- @@ -15,7 +14,6 @@ L'invito a suggerire modifiche, aggiunte e migliorie al Glossario Cloud Native Chiunque voglia contribuire può aprire una issue o una pull request su GitHub. Leggi la sezione [Come Contribuire](/it/contribute/) per maggiori informazioni e assicurati di seguire le indicazioni della [Guida di Stile](/it/style-guide/). - ## Riconoscimenti Il progetto del Glossario Cloud Native è un'iniziativa del Marketing Committee della CNCF (nello specifico del Business Value Subcommittee) e include contributi da [Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), [Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/), @@ -25,4 +23,4 @@ La localizzazione del progetto in italiano è a cura di [Giulia Di Pietro](https ## Licenza -Tutti i contributi sono sotto licenza Apache 2.0. La documentazione è distribuita sotto i termini di licenza Creative Commons CC BY 4.0. \ No newline at end of file +Tutti i contributi sono sotto licenza Apache 2.0. La documentazione è distribuita sotto i termini di licenza Creative Commons CC BY 4.0. diff --git a/content/it/agile_software_development.md b/content/it/agile_software_development.md index c3e1626fa9..64c8a0506a 100644 --- a/content/it/agile_software_development.md +++ b/content/it/agile_software_development.md @@ -5,11 +5,13 @@ category: Concetto --- ## Cos'è + Un insieme di pratiche che enfatizzano i cicli di sviluppo iterativi e i team auto-organizzati. In contrasto con i progetti waterfall (a cascata) in cui il valore è generato solo alla fine del progetto, lo sviluppo agile del software si concentra su una consegna continua e incrementale del valore e sul miglioramento evolutivo del processo stesso. ## Quali problematiche affronta + Definire, comunicare e comprendere i requisiti per tutti gli stakeholder (interessati) in un progetto di sviluppo software è molto difficile, se non impossibile. Tuttavia, i clienti vogliono che i loro progetti di sviluppo software siano consegnati in tempo, in buona qualità, entro i limiti del budget e dello scopo. Con la sua natura ciclica, lo sviluppo agile del software consente l'evoluzione continua dei requisiti e un adattamento più veloce in base a tutte le altre circostanze rispetto alle strategie waterfall. ## In che modo aiuta + Lo sviluppo agile del software contiene tutte le fasi tradizionali delle strategie waterfall, come requisiti di ingegneria, pianificazione, implementazione, revisione, test e consegna. La differenza sostanziale è che l'intero arco di tempo di un progetto software è suddiviso in iterazioni, ciascuna delle quali contiene tutte queste fasi. Dopo ogni iterazione, il valore creato può essere rivisto con il cliente e i requisiti possono essere adattati verso l'obiettivo finale. Inoltre il team di sviluppo riflette su quali azioni intraprendere per migliorare il processo stesso. - \ No newline at end of file diff --git a/content/it/cluster.md b/content/it/cluster.md index 11475db4a7..902fbdb7ee 100644 --- a/content/it/cluster.md +++ b/content/it/cluster.md @@ -14,4 +14,4 @@ Il software che è in esecuzione su un singolo computer presenta un singolo punt ## In che modo aiuta -Le applicazioni distribuite o clusterizzate vengono eseguite su più macchine, eliminando un singolo punto di vulnerabilità. Tuttavia, costruire sistemi distribuiti è davvero difficile e costituisce, infatti, una disciplina informatica a sé stante. La necessità di sistemi globali e anni di prove ed errori hanno portato allo sviluppo di un nuovo tipo di stack tecnologico: le [tecnologie cloud native](/it/cloud_native_tech/). Queste nuove tecnologie sono i pilastri che rendono più facile il mantenimento, il funzionamento e la creazione di sistemi distribuiti. \ No newline at end of file +Le applicazioni distribuite o clusterizzate vengono eseguite su più macchine, eliminando un singolo punto di vulnerabilità. Tuttavia, costruire sistemi distribuiti è davvero difficile e costituisce, infatti, una disciplina informatica a sé stante. La necessità di sistemi globali e anni di prove ed errori hanno portato allo sviluppo di un nuovo tipo di stack tecnologico: le [tecnologie cloud native](/it/cloud_native_tech/). Queste nuove tecnologie sono i pilastri che rendono più facile il mantenimento, il funzionamento e la creazione di sistemi distribuiti. diff --git a/content/it/contribute/_index.md b/content/it/contribute/_index.md index 3784621bd6..5a7daf64e6 100644 --- a/content/it/contribute/_index.md +++ b/content/it/contribute/_index.md @@ -14,15 +14,18 @@ Ci sono tre modi in cui puoi contribuire: 2) Migliorare quelle esistenti 3) Aiutare nella traduzione del glossario -## Entra nella Glossary community! +## Entra nella Glossary community + Valuta di entrare anche tu nei nostri meeting mensili del _Glossary Working Group_, se hai intenzione di contribuire regolarmente. Puoi trovare i dettagli del meeting nel [calendario della CNCF](https://www.cncf.io/calendar/). Puoi anche connetterti con i gestori e i contributors nel nostro canale #glossary-localizations della [CNCF Slack](https://cloud-native.slack.com/) — ti aspettiamo! ## Proporre nuove voci + Puoi sia proporre nuove voci su cui altri possono lavorare, o crearne tu stesso anche la definizione. In entrambi i casi dovrai iniziare aprendo una _issue_ (avrai bisogno di un account di Github per farlo). Di seguito trovi una guida che ti spiegherà passo dopo passo come fare, se non hai ancora dimestichezza con Github. Se invece **sei un GitHub Pro**, assicurati di scorrere la lista degli issue prima e usare il template corretto, una naming convention appropriata e segnalare la tua PR su Slack (altrimenti potremmo non notarla). Infine, assicurati di leggere la [Guida di Stile](/it/style-guide/) prima di iniziare — grazie! ### Creare una issue + Apri le issues nel [repo del Glossario su GitHub](https://github.com/cncf/glossary/issues) and clicca su "new issue". ![issues](/images/how-to/howto-01.png) @@ -85,9 +88,11 @@ Ora dovesti vedere la tua PR tra le "Pull requests". ![prs](/images/how-to/howto-13.png) ## Modifica un termine esistente + Per modificare un termine esistente, puoi decidere di proporre una modifica tramite una _issue_ o modificare direttamente il termine e creare una pull request (PR). ### Richiedere una modifica tramite una _issue_ + Se vuoi riportare un problema con un termine ma non puoi/vuoi risolverlo da solo, clicca su "report issue" ![report issue](/images/how-to/howto-14.png) @@ -97,6 +102,7 @@ Aprirai così una _issue_. Riporta nella descrizione che tipo di modifica bisogn ![submit issue](/images/how-to/howto-15.png) ### Aggiornare un termine direttamente + Per aggiornare direttamente il termine, vai su "edit this page." ![edit this page](/images/how-to/howto-16.png) @@ -104,8 +110,5 @@ Per aggiornare direttamente il termine, vai su "edit this page." ti si aprirà la pagina di Github relativa al termine. Fai le tue modifiche e apri una PR. Fai riferimento al paragrafo [Proporre un nuovo termine](#proporre-un-nuovo-termine-creare-una-pr) per una descrizione dettagliata di come modificare un file markdown. ## Aiutaci a tradurre il Glossario -Per aiutare a tradurre il Glossario nella tua lingua madre, entra nel canale #glossary-localizations della [CNCF Slack](https://cloud-native.slack.com/) e faccelo sapere. Puoi entrare a far parte di un team già esistente o crearne uno nuovo. Puoi anche partecipare al nostro meeting del Glossary Working Group. Trovi tutte le informazioni per il meeting nel [calendario della CNCF](https://www.cncf.io/calendar/). Ti aspettiamo! - - - +Per aiutare a tradurre il Glossario nella tua lingua madre, entra nel canale #glossary-localizations della [CNCF Slack](https://cloud-native.slack.com/) e faccelo sapere. Puoi entrare a far parte di un team già esistente o crearne uno nuovo. Puoi anche partecipare al nostro meeting del Glossary Working Group. Trovi tutte le informazioni per il meeting nel [calendario della CNCF](https://www.cncf.io/calendar/). Ti aspettiamo! diff --git a/content/it/devops.md b/content/it/devops.md index 1f551d1d9c..25ce5c70b1 100644 --- a/content/it/devops.md +++ b/content/it/devops.md @@ -5,12 +5,15 @@ category: Concetto --- ## Cos'è + DevOps è una metodologia in cui i team sono responsabili dell'intero processo: dallo sviluppo delle applicazioni fino alle attività di installazione, configurazione e manutenzione in produzione, da cui DevOps. Il concetto va oltre l'implementazione di una serie di tecnologie e richiede un cambiamento completo nella cultura e nei processi. DevOps richiede gruppi di ingegneri che lavorano su piccoli componenti (invece di un'intera feature), diminuendo i passaggi di mano - una fonte comune di errori. ## Quali problematiche affronta + Tradizionalmente, nelle organizzazioni complesse con [applicazioni monolitiche](/monolithic_apps/) dai [componenti strettamente accoppiati](/tightly_coupled_architectures/), il lavoro era generalmente frammentato tra più team. Questo portava a numerosi passaggi di mano e a lunghi tempi di consegna. Ogni volta che un componente o un aggiornamento era pronto, veniva messo in coda per il team successivo. Poiché gli individui lavoravano solo su una piccola parte del progetto, questo approccio portava ad una mancanza di ownership (titolarità) sull'intero progetto. Il loro obiettivo era quello di passare il lavoro al gruppo successivo e non di consegnare la giusta funzionalità al cliente - un evidente e chiaro disallineamento delle priorità. Quando il codice arrivava finalmente in produzione, passava da così tanti sviluppatori, stando in attesa in così tante code, che diventava difficile rintracciare l'origine del problema se il codice non funzionava. DevOps inverte questo approccio. ## In che modo aiuta -Avere un team che sia responsabile dell'intero ciclo di vita di un'applicazione, porta a minimizzare i passaggi di mano, a ridurre i rischi di installazione in produzione, a migliorare la qualità del codice (perché i team sono anche responsabili di come il codice "si comporta" in produzione) e ad aumentare la soddisfazione dei dipendenti grazie alla maggiore autonomia e ownership. \ No newline at end of file + +Avere un team che sia responsabile dell'intero ciclo di vita di un'applicazione, porta a minimizzare i passaggi di mano, a ridurre i rischi di installazione in produzione, a migliorare la qualità del codice (perché i team sono anche responsabili di come il codice "si comporta" in produzione) e ad aumentare la soddisfazione dei dipendenti grazie alla maggiore autonomia e ownership. diff --git a/content/it/infrastructure_as_code.md b/content/it/infrastructure_as_code.md index f4c5d5f5fc..7e1ac00f05 100644 --- a/content/it/infrastructure_as_code.md +++ b/content/it/infrastructure_as_code.md @@ -5,10 +5,13 @@ category: Concetto --- ## Che cos'è + Con _infrastructure as code_ (IaC - Infrastruttura come Codice) si intende il processo di gestione e provisioning dell’infrastruttura attraverso file di definizione leggibili da una macchina: tratta la configurazione dell’infrastruttura alla stregua di software di programmazione. Questo sostituisce il modello tradizionale in cui l'infrastruttura come servizio viene creata manualmente, in genere tramite script di shell o altri strumenti di configurazione. ## Quali problematiche risolve + La creazione di applicazioni native sul cloud richiede che l'infrastruttura sia a perdere e riproducibile. Deve essere inoltre scalabile su richiesta in modo automatizzato e ripetibile, potenzialmente senza intervento umano. Il provisioning manuale, infatti, non può soddisfare i requisiti di reattività e scalabilità delle applicazioni cloud native. Le modifiche manuali all'infrastruttura non sono riproducibili, si scontrano presto con i limiti in termini di scalabilità e introducono il rischio di errori di configurazione. ## In cosa aiuta + Rappresentando le risorse del data center come server, sistemi di bilanciamento del carico e sottoreti come codice, i team operations possono disporre di un'unica fonte di verità per tutte le configurazioni e possono gestire il proprio data center in una pipeline [CI](/continuous_integration/)/[CD](/continuous_delivery/), implementando sistemi di controllo di versione e strategie di deployment. diff --git a/content/it/managed_services.md b/content/it/managed_services.md index 47ff5c60d2..b3dfd26d46 100644 --- a/content/it/managed_services.md +++ b/content/it/managed_services.md @@ -5,10 +5,13 @@ category: Tecnologia --- ## Cos'è + Con _managed service_ si intende un'offerta di servizio da parte di un fornitore che comprende un software assieme alla sua gestione ordinaria e manutenzione. Ne sono esempi i servizi di [Database as a Service](/database_as_a_service/) come RDS di Amazon, o i servizi esterni di monitoring come Datadog. ## Quali problematiche affronta + La gestione di un software è un'attività complessa, specialmente considerando le diverse tecnologie che compongono uno stack moderno. Gestirne tutti gli aspetti e avere in azienda le risorse con un livello adeguato di conoscenza delle tecnologie coinvolte può essere dispendioso e non valere il tempo speso dagli specialisti. Il tuo team può così concentrarsi sulla creazione di nuove funzionalità dei propri sistemi, piuttosto che occuparsi di attività di gestione che possono essere facilmente delegate a parti terze. ## In che modo aiuta + I managed services sono soluzioni pronte da usare subito, che richiedono sforzi limitati dal punto di vista operativo. Consentono alle organizzazioni di esternalizzare le attività che non fanno parte del proprio core business, e connettersi ad esse tramite ben definite interfacce, solitamente seguendo i principi di sviluppo delle [API](/application_programming_interface/). diff --git a/content/it/microservices.md b/content/it/microservices.md index ee6ee11912..3aec99a08c 100644 --- a/content/it/microservices.md +++ b/content/it/microservices.md @@ -5,10 +5,13 @@ category: Concetto --- ## Che cos’è + I microservizi sono un approccio moderno allo sviluppo di applicazioni che sfrutta le tecnologie native del cloud. Sebbene le applicazioni moderne, come Netflix, sembrino essere un'unica app, in realtà sono una raccolta di servizi più piccoli, tutti in stretta collaborazione. Ad esempio, una singola pagina che ti consente di accedere, cercare e visualizzare in anteprima i video è probabilmente alimentata da servizi più piccoli che ne gestiscono ciascuno un aspetto (ad esempio ricerca, autenticazione ed esecuzione di anteprime nel browser). In breve, i microservizi si riferiscono a un modello di architettura dell'applicazione solitamente in contrasto con le [applicazioni monolitiche](/monolithic_apps/). ## Quale problema affronta -I microservizi sono una risposta alle sfide poste dalle applicazioni monolitiche. In genere, le diverse parti di un'applicazione dovranno essere [scalabili](/scalability/) separatamente. Per esempio, un negozio online avrà più visualizzazioni di prodotti che pagamenti. Ciò significa che avrai bisogno di più copie della funzionalità di visualizzazione del prodotto in esecuzione rispetto al pagamento. In un'applicazione monolitica, quei bit di logica non possono essere creati separatamente. Se non riesci a ridimensionare la funzionalità del prodotto individualmente, dovrai duplicare l'intera app con tutti gli altri componenti che non ti servono - un uso inefficiente delle risorse. Le applicazioni monolitiche causano agli sviluppatori di soccombere facilmente alle insidie ​​della progettazione. Poiché tutto il codice è in un unico posto, è più facile rendere quel codice [strettamente accoppiato](/tightly_coupled_architectures/) ed è più difficile applicare il principio della separazione dei contesti. I monoliti spesso richiedono agli sviluppatori di comprendere l'intera base di codice prima di poter essere produttivi. + +I microservizi sono una risposta alle sfide poste dalle applicazioni monolitiche. In genere, le diverse parti di un'applicazione dovranno essere [scalabili](/scalability/) separatamente. Per esempio, un negozio online avrà più visualizzazioni di prodotti che pagamenti. Ciò significa che avrai bisogno di più copie della funzionalità di visualizzazione del prodotto in esecuzione rispetto al pagamento. In un'applicazione monolitica, quei bit di logica non possono essere creati separatamente. Se non riesci a ridimensionare la funzionalità del prodotto individualmente, dovrai duplicare l'intera app con tutti gli altri componenti che non ti servono - un uso inefficiente delle risorse. Le applicazioni monolitiche causano agli sviluppatori di soccombere facilmente alle insidie della progettazione. Poiché tutto il codice è in un unico posto, è più facile rendere quel codice [strettamente accoppiato](/tightly_coupled_architectures/) ed è più difficile applicare il principio della separazione dei contesti. I monoliti spesso richiedono agli sviluppatori di comprendere l'intera base di codice prima di poter essere produttivi. ## In che modo aiuta + La separazione delle funzionalità in diversi microservizi ne semplifica la distribuzione, l'aggiornamento e la scalabilità in modo indipendente. Consentendo a diversi team di concentrarsi sulla propria piccola parte di un'applicazione più grande, rende loro più facile per loro lavorare sulle proprie app senza avere un impatto negativo sul resto dell'organizzazione. Sebbene i microservizi risolvano molti problemi, creano anche un sovraccarico operativo, le cose che ti servono per distribuire e tenere traccia del suo aumento per ordine di grandezza, ed altro. Molte [tecnologie cloud native](/it/cloud_native_tech/) mirano a semplificare la distribuzione e la gestione dei microservizi. diff --git a/content/it/platform_as_a_service.md b/content/it/platform_as_a_service.md index d2104bf059..dffcfcaa62 100644 --- a/content/it/platform_as_a_service.md +++ b/content/it/platform_as_a_service.md @@ -5,10 +5,13 @@ category: Tecnologia --- ## Cos'è + Una Platform as a Service, o PaaS, è una piattaforma esterna ai team di sviluppo per distribuire ed eseguire le proprie applicazioni. Heroku, Cloud Foundry, App Engine sono esempi di offerte PaaS. ## Quali problematiche affronta + Per sfruttare i modelli nativi del cloud come i [microservizi](/microservices/) o le [applicazioni distribuite](/distributed_apps/), i team delle operation e gli sviluppatori devono essere in grado di esternalizzare una quantità significativa di operazioni e lavori di manutenzione. Questi includono attività come il provisioning dell'infrastruttura, la gestione dell'[individuazione dei servizi](/service_discovery/), il bilanciamento del carico e la [scalabilità](/scalability/) delle applicazioni. ## In che modo aiuta + Un servizio PaaS fornisce strumenti di infrastruttura agli sviluppatori di applicazioni in modo completamente automatizzato. Consente loro di comprendere e preoccuparsi meno dell'infrastruttura stessa e di dedicare più tempo e sforzi alla scrittura del codice dell'applicazione. Fornisce inoltre una base di monitoraggio e [osservabilità](/observability/) per aiutare i team ad assicurarsi che le proprie applicazioni siano funzionanti. diff --git a/content/it/site_reliability_engineering.md b/content/it/site_reliability_engineering.md index dc1f0149a1..8c77d57477 100644 --- a/content/it/site_reliability_engineering.md +++ b/content/it/site_reliability_engineering.md @@ -5,10 +5,13 @@ category: Concetto --- ## Che cos’è + Site Reliability Engineering o SRE è una disciplina che combina operations e ingegneria del software. Quest'ultima viene applicata specificamente a problemi infrastrutturali e operativi. In altre parole, invece di creare funzionalità di prodotto, i SRE realizzano i sistemi su cui le applicazioni sono in esecuzione. Esistono somiglianze con DevOps, ma mentre DevOps si concentra sul portare il codice in produzione, SRE garantisce che il codice in produzione funzioni correttamente. ## Quale problema affronta + Per garantire che le applicazioni funzionino in modo affidabile, sono necessarie molteplici funzionalità, dal monitoraggio delle prestazioni, agli allarmi, al debug di errori e problemi. Senza questi elementi, gli sviluppatori possono solo reagire ai problemi anziché lavorare in modo proattivo per evitarli: il verificarsi di interruzioni di servizio sarà solo questione di tempo. ## In che modo aiuta + Un approccio SRE riduce al minimo i costi, i tempi e gli sforzi del processo di sviluppo del software migliorando in modo continuo l’infrastruttura. Il sistema misura e monitora continuamente l'infrastruttura e i componenti dell'applicazione. Quando qualcosa va storto, il sistema indica ai SRE quando, dove e come risolvere il problema. Questo approccio aiuta a creare sistemi software altamente scalabili e affidabili, automatizzando le attività operative. diff --git a/content/it/style-guide/_index.md b/content/it/style-guide/_index.md index 67e98835c8..f428b9a27d 100644 --- a/content/it/style-guide/_index.md +++ b/content/it/style-guide/_index.md @@ -24,7 +24,6 @@ Il Glossario Cloud Native rispetta la [Guida di Stile](https://github.com/cncf/f Consigliamo di dare un'occhiata a questi [set di regole grammaticali](https://grammatica-italiana.dossier.net/grammatica-italiana-17.htm) e alle [40 regole di scrittura di Umberto Eco per scrivere bene in italiano](https://bologna.unicusano.it/universita/scrivere-correttamente-in-italiano/). Possono essere di aiuto. - ## Destinatari Il Glossario è scritto sia per un pubblico di destinazione tecnico sia per un pubblico di destinazione NON-tecnico. Per questa ragione assicurati che le definizioni siano espresse in termini semplici e che non diano per scontata una conoscenza tecnica pregressa. Lo spieghiamo meglio nel paragrafo [*Definizioni*](#template-definizioni). @@ -108,7 +107,7 @@ Le definizioni categorizzate come **technology** e **concept** prevedono tre par La label **properties** non richiede un paragrafo a sé. La definizione è più che sufficiente. -#### Semplice è meglio! +#### Semplice è meglio Il Glossario ha come ultimo obiettivo **spiegare concetti complessi in parole semplici** — qualcosa di sorprendentemente difficile che richiederà quasi per certo svariate revisioni. Il consiglio è di tenere sempre ben presente il pubblico di destinazione, mentre si descrive un termine. Bisognerebbe evitare l'uso di espressioni eccessivamente tecniche e buzzword di varia natura. Lo evidenziamo perché ti troverai quasi per certo a farlo anche tu involontariamente e dovrai rivedere i tuoi contenuti. @@ -126,7 +125,6 @@ Per avere la certezza di non aprire una PR sovrapponendoti a qualcun altro o vic Ultimo suggerimento di carattere redazionale, prima di buttarti nella scrittura: prova a leggere qualche termine già pubblicato nel Glossario in modo da intuire il livello di dettaglio richiesto e le relative difficoltà, nonché l'utilizzo di esempi, come già citato sopra. - ## Il processo di revisione: cosa aspettarsi Innanzitutto vorremmo far presente che i maintainers di questo progetto sono solo tre e che se ne occupano nel loro tempo libero, per cui a volte saranno più rapidi, altre volte avranno bisogno di più tempo per rispondere e revisionare: abbi pazienza. Per qualunque domanda, però, mettiti in contatto con loro o con i gruppi di lavoro sul canale #glossary dello Slack CNCF (per approfondimenti ti rimandiamo alla sezione [Come contribuire](/it/contribute/)). diff --git a/content/it/virtual_machine.md b/content/it/virtual_machine.md index 2c20592c5b..7e3f3459ed 100644 --- a/content/it/virtual_machine.md +++ b/content/it/virtual_machine.md @@ -5,11 +5,14 @@ category: Tecnologia --- ## Che cos’è + Una macchina virtuale (VM) è un computer e il suo sistema operativo che non è legato a un particolare componente hardware. Le macchine virtuali si basano sulla [virtualizzazione](/virtualization/) per suddividere un singolo computer fisico in più computer virtuali. Questa separazione consente alle organizzazioni e ai fornitori di infrastrutture di creare e distruggere VM senza influire sull'hardware sottostante. ## Quale problema affronta + Le macchine virtuali sfruttano la virtualizzazione. Quando una macchina [bare metal](/bare_metal_machine/) è vincolata a un singolo sistema operativo (OS), il modo in cui le risorse della macchina possono essere utilizzate è alquanto limitato. Inoltre, quando un sistema operativo è legato a una singola macchina fisica, la sua disponibilità è direttamente legata a quell'hardware. Se la macchina fisica è offline a causa di manutenzione o guasti hardware, lo è anche il sistema operativo. ## In che modo aiuta + Rimuovendo la relazione diretta tra un sistema operativo e una singola macchina fisica, si risolvono diversi problemi delle macchine bare metal: tempo di provisioning (approvvigionamento), utilizzo dell'hardware e resilienza. I tempi di provisioning per un nuovo computer vengono notevolmente migliorati, senza l'acquisto, l'installazione o la configurazione di nuovo hardware per supportarlo. Le macchine virtuali consentono di utilizzare meglio le risorse hardware fisiche esistenti, creando più macchine virtuali su una singola macchina fisica. Non vincolate a una macchina fisica particolare, le macchine virtuali sono anche più resilienti delle macchine fisiche. Quando una macchina fisica deve essere spenta, le macchine virtuali in esecuzione su di essa possono essere spostate su un'altra macchina con tempi di inattività minimi o nulli. diff --git a/content/ko/_index.md b/content/ko/_index.md index 5056370cf7..c4931b2bdc 100644 --- a/content/ko/_index.md +++ b/content/ko/_index.md @@ -1,4 +1,3 @@ - --- title: "클라우드 네이티브 용어집" --- @@ -10,6 +9,7 @@ title: "클라우드 네이티브 용어집"

한 여성과 두 남성이 스테이지에서 기술 정보를 소개하고 있음

## 기여하기 + 네이티브 용어집에 대한 변경, 추가 및 개선은 모든 사람에게 열려있다. 우리는 이 공유된 어휘(lexicon)를 개발 및 개선하기 위해서 CNCF가 관리하는 커뮤니티-주도 프로세스를 사용한다. 이 용어집은 클라우드 네이티브 기술들에 대한 공유 어휘를 관리하기 위해서 벤더-중립적 플랫폼을 제공한다. 본 프로젝트의 목적과 헌장(charter)을 준수하는 모든 참여자의 기여를 환영한다. 기여를 하고 싶은 사람은 GitHub 이슈를 제출하거나 풀 리퀘스트(pull request)를 생성하면 된다. [기여 방법](/ko/contribute/)을 확인하고, [스타일 가이드](/ko/style-guide/)를 준수해야 하며, CNCF Slack의 #glossary 채널에도 참여한다. #glossary-localizations 채널도 있으므로 용어집을 자신의 모국어로 번역하고 싶은 사람이 참여하면 좋다. @@ -23,7 +23,6 @@ Committee) (비지니스 벨류 서브커미티)를 클라우드 네이티브 용어집 프로젝트는 메인테이너인 [Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), [Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), [Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/), [Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/), 그리고 [Seokho Son](https://www.linkedin.com/in/seokho-son/)을 통해 운영 및 관리되고 있다. - 마지막으로, 클라우드 네이티브 용어집의 한글화(한국어 현지화)는 클라우드 네이티브 용어집 한글화팀([#glossary-localization-korean](https://cloud-native.slack.com/archives/C02PC0MLQKU))을 포함한 [Jihoon Seo (서지훈)](https://www.linkedin.com/in/jihoon-seo/), [Seokho Son (손석호)](https://www.linkedin.com/in/seokho-son/), [Yunkon Kim (김윤곤)](https://www.linkedin.com/in/%EC%9C%A4%EA%B3%A4-%EA%B9%80-47257914a/) 및 다양한 기여자의 기여를 통해서 개시되었다. ## 라이선스 diff --git a/content/ko/cloud_computing.md b/content/ko/cloud_computing.md index 56ac638067..1c8a13f510 100644 --- a/content/ko/cloud_computing.md +++ b/content/ko/cloud_computing.md @@ -5,12 +5,13 @@ category: 개념 --- ## 개념 + 클라우드 컴퓨팅은 인터넷을 통해 CPU, 네트워크, 디스크와 같은 컴퓨팅 리소스를 온디맨드(on-demand)로 제공하는 모델이다. 클라우드 컴퓨팅은 사용자가 물리적으로 원격에 위치한 컴퓨팅 파워(power)에 접속 및 사용할 수 있게 기능을 제공한다. AWS, GCP, Azure, DigitalOcean 등 다양한 클라우드 제공자들은 제 3자에게 지리적으로 다양한 위치에 있는 컴퓨팅 리소스에 대한 액세스(access) 권한을 임대할 수 있도록 기능을 제공한다. ## 다루는 문제 + 전통적으로 조직들은 컴퓨팅 파워에 대한 사용을 확장하려고 할 때 두 가지 주요 문제에 직면했다. 그들은 물리적 서버와 네트워크를 호스팅 하기 위한 시설에 대한 구입, 지원, 설계, 비용 지불 단계를 거치거나 해당 시설들을 확장 및 관리하게 된다. 반면, 클라우드 컴퓨팅은 조직이 컴퓨팅 요구 사항의 일부를 다른 조직에 아웃소싱(outsource)할 수 있게 한다. ## 문제 해결 방식 -클라우드 제공자는 조직들이 컴퓨팅 리소스를 온디맨드로 임대하고 사용한 만큼 비용을 지불할 수 있도록 한다. 이를 통해 두 가지 주요 혁신이 가능하다. 조직들은 신규 물리 인프라(infrastructure)에 대한 CAPEX를 계획 및 소비하는 데 시간을 낭비하지 않고 원하는 것을 시도할 수 있으며, 필요에 따라 온디맨드로 [확장(scale)](/scalability/)할 수 있다. 클라우드 컴퓨팅을 통해서 조직들은 인프라를 필요한 만큼만 도입할 수 있다. - +클라우드 제공자는 조직들이 컴퓨팅 리소스를 온디맨드로 임대하고 사용한 만큼 비용을 지불할 수 있도록 한다. 이를 통해 두 가지 주요 혁신이 가능하다. 조직들은 신규 물리 인프라(infrastructure)에 대한 CAPEX를 계획 및 소비하는 데 시간을 낭비하지 않고 원하는 것을 시도할 수 있으며, 필요에 따라 온디맨드로 [확장(scale)](/scalability/)할 수 있다. 클라우드 컴퓨팅을 통해서 조직들은 인프라를 필요한 만큼만 도입할 수 있다. diff --git a/content/ko/container.md b/content/ko/container.md index 961aac655c..a898853884 100644 --- a/content/ko/container.md +++ b/content/ko/container.md @@ -5,12 +5,15 @@ category: 기술 --- ## 개념 + 컨테이너(container)는 컴퓨터 운영 체제를 통해 관리되며 리소스 및 기능에 제약을 가지는 구동 프로세스(running process)이다. 컨테이너 프로세스에서 사용할 수 있는 파일은 컨테이너 이미지로 패키징된다. 동일한 머신(machine)에서 컨테이너들은 서로 인접한 형태로 실행되지만, 일반적으로 운영 체제는 개별 컨테이너 프로세스들이 서로 상호 작용하는 것을 방지한다. ## 다루는 문제 + 컨테이너를 사용하기 전에는, 각 애플리케이션을 실행하기 위한 개별 머신이 필요했다. 이 경우 각 머신은 자체 운영 체제(CPU, 메모리 및 디스크 공간을 차지)가 필요하고, 주로 대부분의 자원들이 개별 애플리케이션을 구동하기 위해 사용된다. 또한 운영 체제에 대한 유지 관리, 업그레이드 및 구동(startup)은 또 다른 노역의 원인(source of toil)이 될 수 있다. ## 문제 해결 방식 + 컨테이너들은 동일한 운영 체제와 머신의 리소스를 공유하여 운영 체제의 리소스 부하(overhead)를 분산시키고 물리 머신을 효율적으로 사용할 수 있게 한다. 이 특징은 컨테이너간의 상호 작용이 일반적으로 제한되어 있기 때문에 가능하다. 이를 통해 동일한 물리 머신에서 더 많은 애플리케이션들을 실행할 수 있다. 그러나 여기에는 한계도 존재한다. 컨테이너들이 동일한 운영 체제를 공유하므로, 다른 대안들에 비해 프로세스는 덜 안전해 보일 수 있다는 점이다. 또한 컨테이너에는 공유 리소스에 대한 제한도 필요하다. 리소스를 보장하기 위해 관리자는 메모리와 CPU 사용을 제약(constrain) 및 제한(limit)하여 다른 애플리케이션들의 성능이 저하되지 않도록 해야 한다. diff --git a/content/ko/contribute/_index.md b/content/ko/contribute/_index.md index abc1d2ef2d..8d47268de5 100644 --- a/content/ko/contribute/_index.md +++ b/content/ko/contribute/_index.md @@ -16,9 +16,11 @@ menu: 4) [용어집 번역에 참여하기](#help-translate-the-glossary) ## Glossary 커뮤니티에 들어오세요! {#join-the-glossary-community} + 정기적으로 기여하고 싶다면, 용어집 워킹 그룹(Glossary Working Group) 월간 미팅에 참여할 수 있다. [CNCF 캘린더](https://www.cncf.io/calendar/)에서 미팅 상세 정보를 확인할 수 있다. 또한 CNCF 슬랙의 [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) 채널에서 메인테이너 및 기여자들과 소통할 수 있다. 어서오세요! ## 열려 있는 이슈에 대해 작업하기 {#work-on-an-existing-issue} + [용어집 GitHub 저장소 이슈](https://github.com/cncf/glossary/issues)를 확인한다. 여기서 모든 이슈의 목록을 볼 수 있다. 레이블을 이용하여 이슈를 필터링할 수 있다(예: 영어, 'help needed', 'good first issue'). 이러한 작업을 하려면 GitHub 계정이 필요하다. ![이슈와 레이블](/images/how-to/issue-and-labels.png) @@ -36,11 +38,13 @@ menu: 메인테이너가 해당 용어를 당신에게 할당하면, 이제 그 용어에 대해 작업을 시작할 수 있다. 다음 단계로, [새로운 용어 추가하기(PR 열기)](#submitting-a-new-term-creating-a-pr) 섹션을 참고한다. ## 새로운 용어 제안하기 {#propose-new-terms} + 새로운 용어를 제안하면서, 다른 사람이 작업할 수 있도록 하거나, 그에 대한 정의를 직접 작성할 수도 있다. 어느 쪽이든, 이슈를 작성하여 이 과정을 시작한다. 아래는 아직 GitHub에 익숙하지 않은 사람들을 위한 단계별 가이드이다. **당신이 GitHub에 익숙하다면**, 가이드를 빠르게 참고하여 현재 설정되어 있는 이슈 템플릿을 활용하고, 적합한 네이밍 컨벤션을 따르고, PR을 작성했음을 슬랙에 알리고(메인테이너가 놓치지 않도록), 파일 템플릿이 어디에 있는지 확인한다. 그리고 시작하기 전에 [스타일 가이드](/ko/style-guide/)를 꼭 확인한다. 감사합니다! ### 이슈 생성하기 {#creating-an-issue} + [용어집 GitHub 저장소 이슈](https://github.com/cncf/glossary/issues)로 이동하여, "New issue"를 클릭한다. ![New issue](/images/how-to/howto-01.png) @@ -51,8 +55,8 @@ menu: 제안하려는 용어를 작성하고, 아래의 두 질문에 대한 답을 입력하고, 체크리스트를 읽고 체크하고, "Submit new issue" 버튼을 누른다. 새로운 용어를 단지 제안하기만 하는 것이라면, 과정이 완료되었다! 만약 이 용어에 대해 작업하고 싶다면, 다음 단계를 수행한다. - ### 분류(triage) 과정 거치기 {#triaging-your-issue} + 다음으로, 메인테이너가 이슈를 분류할 것이다. 즉, 이 용어가 용어집에 포함되는 것이 적절한지를 메인테이너가 평가한다(참고: 모든 용어가 허용되지는 않는다. 확실히 자리를 잡았고(established) 널리 사용되는 클라우드 네이티브 용어만 허용될 것이다). 새로운 용어를 제안했음을 메인테이너가 놓치고 지나가지 않도록, 슬랙을 통해 메인테이너에게 알린다. _@Catherine Paganini_, _@jmo_, _@Seokho Son_, _@Jihoon Seo_, _@iamnoah_ 중 전부 또는 일부를 태그하면 좋다. 해당 용어가 승인되고 당신이 해당 용어에 대해 작업하고 싶다는 의사를 밝혔다면, 메인테이너가 해당 용어를 당신에게 할당할 것이다. @@ -100,9 +104,11 @@ PR 생성 화면으로 이동하며, "Create pull request"를 누르면 PR을 ![prs](/images/how-to/howto-13.png) ## 기존 용어 수정하기 {#update-an-existing-term} + 기존 용어를 수정하려면, 이슈를 올려 수정 제안을 하거나 바로 풀 리퀘스트(PR)를 열어 직접 수정할 수 있다. ### 이슈를 올려 수정 제안하기 {#request-a-change-via-an-issue} + 용어에 대한 문제를 발견했지만 어떻게 수정해야 하는지 모르거나 직접 수정하고 싶지 않다면, "Report issue"를 클릭한다. ![Report issue](/images/how-to/howto-14.png) @@ -112,6 +118,7 @@ PR 생성 화면으로 이동하며, "Create pull request"를 누르면 PR을 ![Submit new issue](/images/how-to/howto-15.png) ### 용어 직접 수정하기 {#update-a-term-directly} + 용어를 직접 수정하려면, "Edit this page"를 클릭한다. ![Edit this page](/images/how-to/howto-16.png) @@ -119,4 +126,5 @@ PR 생성 화면으로 이동하며, "Create pull request"를 누르면 PR을 해당 용어의 GitHub 페이지가 열릴 것이다. 용어를 수정하고 PR을 제출한다. 자세한 설명은 위의 "새로운 용어 추가하기(PR 열기)" 섹션을 참고한다(마크다운에 대해 설명하는 문단으로 건너뛴다). ## 용어집 번역에 참여하기 {#help-translate-the-glossary} + 용어집을 당신의 모국어로 번역하는 데 참여하고 싶다면, CNCF 슬랙의 #glossary-localizations 채널에 참여하고 메인테이너를 언급한다. 현재 존재하는 언어 팀에 참여하거나, 새로운 언어 팀을 만들 수도 있다(필요 사항을 보려면 [현지화 가이드](https://github.com/cncf/glossary/blob/main/LOCALIZATION.md)를 참고한다). 용어집 워킹 그룹(Glossary Working Group) 월간 미팅에 참여하면 더욱 좋다. [CNCF 캘린더](https://www.cncf.io/calendar/)에서 미팅 상세 정보를 확인할 수 있다. 미팅에 참여하길 기대한다. diff --git a/content/ko/contributor-ladder/_index.md b/content/ko/contributor-ladder/_index.md index 81f0ba04fb..fba22ba2ec 100644 --- a/content/ko/contributor-ladder/_index.md +++ b/content/ko/contributor-ladder/_index.md @@ -14,7 +14,7 @@ menu: 프로젝트에 기여할 수 있는 다양한 방법이 있으며, 다음을 포함한다. -- **콘텐츠 기여자(Content contributors)**: 기존 용어를 ​​개선하거나 새 용어에 기여하는 모든 사람 +- **콘텐츠 기여자(Content contributors)**: 기존 용어를 개선하거나 새 용어에 기여하는 모든 사람 - **현지화 기여자(Localization contributors)**: 용어집을 다른 언어로 번역하는 데 도움을 주는 사람 - **도우미(Helpers)**: GitHub, Slack 또는 커뮤니티 구성원이 지원을 필요로 하는 모든 곳에서 다른 사람을 돕는 사람 - **대사(Ambassadors)**: 정보를 퍼뜨리는 데 도움을 주는 사람, 기여 방법과 기여해야 하는 이유에 대해 교육하는 사람 diff --git a/content/ko/microservices.md b/content/ko/microservices.md index d6d46e4e03..269d6749cb 100644 --- a/content/ko/microservices.md +++ b/content/ko/microservices.md @@ -5,12 +5,14 @@ category: 개념 --- ## 개념 + 마이크로서비스(microservices)는 애플리케이션 개발에 대한 근래의 접근 방법으로 클라우드 네이티브(cloud native) 기술을 활용한다. 넷플릭스(Netflix)와 같은 최신의 애플리케이션들은 단일 앱처럼 보이지만, 실제로는 모두 긴밀하게 동작하는 작은 서비스들의 모음이다. 예를 들어, 영상에 접속하고, 검색하며, 미리보기 할 수 있는 단일 페이지는 각 기능을 처리하는 더욱 작은 단위의 서비스들(예, 브라우저상에서 검색, 인증 및 미리보기 실행)에 의해 구동될 수 있다. 간단히 말해서, 마이크로서비스는 [모놀리식 애플리케이션(monolithic applications)](/monolithic_apps/)에 대조되는 애플리케이션 아키텍처 패턴을 나타낸다. ## 다루는 문제 + 마이크로서비스는 모놀리식 애플리케이션에서 제기된 도전과제(challenges)에 대한 대응안(response)이다. 일반적으로, 애플리케이션에서 각기 다른 부분들은 별도로 [확장(scaled)](/scalability/)해야 할 필요가 있을 것이다. 예를 들어, 온라인 상점은 계산(checkouts) 횟수보다 제품 조회 횟수가 더 많을 것이다. @@ -22,6 +24,7 @@ category: 개념 대개 모놀리스는 개발자가 전체 코드베이스를 이해해야 하며 그 이후 성과를 낼 수 있다. ## 문제 해결 방식 + 기능을 서로 다른 마이크로서비스로 분리하면 독립적으로 배치, 업데이트 및 확장하기 더욱 쉬워진다. 서로 다른 팀들이 큰 애플리케이션 중 각자가 맡은 작은 부분에 집중하게 되면, 맡은 부분 이외의 구조 및 체계(organization)에 부정적으로 영향을 끼치지 않으면서 더 쉽게 앱 관련 작업을 수행할 수 있다. 마이크로서비스가 많은 문제를 해결하였지만, 운영적 오버헤드 또한 만들어 낸다. 즉, 배포하고 추적해야 할 것들이 지수적 혹은 그 이상으로 증가한다. diff --git a/content/ko/monolithic_apps.md b/content/ko/monolithic_apps.md index fbcd28d968..9ced1d18b2 100644 --- a/content/ko/monolithic_apps.md +++ b/content/ko/monolithic_apps.md @@ -5,16 +5,19 @@ category: 개념 --- ## 개념 + 모놀리식 애플리케이션(monolithic application)은 단독으로 배포 가능한 프로그램에 모든 기능을 포함한다. 이것은 보통 애플리케이션을 만들 때 선택할 수 있는, 가장 간단한 시작 형태라 할 수 있다. 그러나, 애플리케이션의 복잡성이 올라가는 경우, 모놀리스(monoliths)의 유지 및 관리가 더욱 어려워질 수 있다. 동일한 코드베이스(codebase)에서 작업하는 개발자가 많아질수록, 변경 사항의 충돌 가능성과 개발자 간의 대인 커뮤니케이션의 필요성이 증가한다. ## 다루는 문제 + 애플리케이션을 [마이크로서비스(microservices)](/microservices/)로 전환하면 운영 오버헤드가 증가한다. 덧붙여 말하면, 테스트, 배포 및 지속 실행해야 하는 보다 많은 항목이 존재하게 된다. 제품의 생명주기(Lifecycle) 초기에는 제품이 성공적이라 판단될 때까지 이러한 복잡한 것을 뒤로 미루고 모놀리식 애플리케이션을 구축하는 것이 유리할 수 있다. ## 문제 해결 방식 + 잘 설계된 모놀리스는 간결함을 유지할 수 있는데 이는 애플리케이션을 구동하는 가장 간단한 방법이기 때문이다. 모놀리식 애플리케이션의 비즈니스 가치가 성공적으로 입증되면 마이크로서비스로 분해될 수 있다. 가치가 입증되기 전에 마이크로서비스 기반 앱으로 만드는 것은 엔지니어링 노력을 투입하는 측면에서 시기상조 일 수 있다. diff --git a/content/ko/style-guide/_index.md b/content/ko/style-guide/_index.md index bf672b3c63..d4deb4a787 100644 --- a/content/ko/style-guide/_index.md +++ b/content/ko/style-guide/_index.md @@ -130,7 +130,6 @@ Google 또는 Word 문서로 시작하여, 며칠을 두고 계속 개선하는 시작하기 전에, 게시되어 있는 용어집 용어 몇 개를 읽어 보고 설명 수준, 난이도, 예시를 소개하면 좋은 상황 등을 파악한다. - ## 리뷰 프로세스 - 어떤 일이 일어나는가 현재 몇 명의 메인테이너가 여유 시간에 리뷰를 수행하고 있음을 참고한다. 용어 제안을 빠르게 리뷰할 때도 있지만, 시간이 걸릴 때도 있다. 인내심을 가져야 한다. 질문이 있다면, #glossary 슬랙 채널에 문의한다([기여 방법](/ko/contribute/) 문서 참고). diff --git a/content/ko/virtual_machine.md b/content/ko/virtual_machine.md index fe690d56ed..01f50e5ffa 100644 --- a/content/ko/virtual_machine.md +++ b/content/ko/virtual_machine.md @@ -5,17 +5,20 @@ category: 기술 --- ## 개념 + 가상 머신(VM, virtual machine)은 특정 하드웨어에 구속(종속)되지 않는 컴퓨터 및 해당 운영 체제(operating system)이다. VM은 [가상화(virtualization)](https://glossary.cncf.io/virtualization/)를 필요로 하는데 이는 단일 물리 컴퓨터를 여러 대의 가상 컴퓨터로 분할하기 위함이다. 이러한 분할을 통해 조직(organization)과 인프라스트럭처 제공자(infrastructure provider)는 하드웨어에 영향을 주지 않고 VM을 쉽게 생성 및 삭제할 수 있다. ## 다루는 문제 + 가상 머신은 가상화를 활용한다. [베어 메탈(bare metal)](https://glossary.cncf.io/bare_metal_machine/) 머신이 단일 운영 체제에 구속(종속)되면 머신의 자원을 효율적으로 활용하는데 다소 제약이 있다. 또한, 운영 체제가 단일 물리 머신에 구속(종속)되는 경우, 운영 체제의 이용 가능성은 해당 하드웨어에 직결된다. 만약 물리 머신이 유지 관리 또는 하드웨어 오류로 인해 오프라인 상태가 되면, 운영 체제도 오프라인 상태가 된다. ## 문제 해결 방식 + 운영 체제와 단일 물리 머신 사이에 직접적인 관계를 제거함으로써, 베어 메탈 머신의 여러 문제를 해결할 수 있다. (프로비저닝 시간(provisioning time), 하드웨어 이용률(hardware utilization) 및 회복력(resiliency) 등) 새로운 하드웨어의 구비, 설치 또는 이를 지원하기 위한 환경 설정이 필요 없으므로, 새 컴퓨터의 프로비저닝 시간이 대폭 향상된다. diff --git a/content/pt-br/.gitkeep b/content/pt-br/.gitkeep deleted file mode 100644 index e69de29bb2..0000000000 diff --git a/content/pt-br/_index.md b/content/pt-br/_index.md index 5ee0360515..d9d9106341 100755 --- a/content/pt-br/_index.md +++ b/content/pt-br/_index.md @@ -3,22 +3,24 @@ title: "Glossário Cloud Native" --- # Glossário Cloud Native + O Glossário Cloud Native é um projeto liderado pelo *CNCF Business Value Subcommittee* (BVS). Seu objetivo é explicar os conceitos de aplicações nativas de nuvem (do inglês, *cloud native applications*) em linguagem clara e simples, sem exigir nenhum conhecimento técnico prévio.

A woman and two men presenting technical info on a stage

## Contribuições + Todas as pessoas são convidadas a sugerir alterações e melhorias ao glossário. Empregamos um processo orientado pela comunidade governado pela CNCF para desenvolver e melhorar este vocabulário compartilhado. Este glossário fornece uma plataforma independente de fornecedor para organizar um vocabulário compartilhado em torno de tecnologias nativas de nuvem. As contribuições são bem-vindas de todos os participantes que cumpram o propósito e o regulamento do projeto. Qualquer pessoa que desejar fazer uma contribuição pode criar uma *issue* ou um *Pull Request* no GitHub. Para isso, certifique-se de seguir o [guia de estilo](/pt-br/style-guide/), ler o [guia do contribuidor](/pt-br/contribute/) e entrar no canal `#glossary` no slack da CNCF. Para interesse em traduzir o glossário para seu idioma nativo, entrar no canal `#glossary-localizations` também no slack da CNCF. ## Agradecimentos + O glossário Cloud Native foi iniciado pelo *CNCF Marketing Committee* e inclui contribuições de [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), [Seokho Son](https://www.linkedin.com/in/seokho-son/) e muitas outras pessoas contribuidoras. Para uma lista completa, verificar na [lista de contribuidores do repositório no Github](https://github.com/cncf/glossary/graphs/contributors). Essa versão do glossário Cloud Native em português inclui contribuições de [Edson Ferreira](https://www.linkedin.com/in/edsoncelio/), [Bruno Guidone](https://www.linkedin.com/in/brunoguidone), [Jéssica Lins](https://www.linkedin.com/in/jessica-lins/), [Willian Oliveira](https://www.linkedin.com/in/willian-dos-santos-oliveira-a4442682/), [Marcelo Mansur](https://www.linkedin.com/in/mdmansur/), Erlison Santos e muitas outras pessoas contribuidoras. ## Licença -Todas as contribuições de código estão sob a licença Apache 2.0. A documentação é distribuída em CC BY 4.0. - +Todas as contribuições de código estão sob a licença Apache 2.0. A documentação é distribuída em CC BY 4.0. diff --git a/content/pt-br/abstraction.md b/content/pt-br/abstraction.md index bdebcb28cf..4aac0e9e04 100644 --- a/content/pt-br/abstraction.md +++ b/content/pt-br/abstraction.md @@ -3,6 +3,7 @@ title: Abstração status: Completed category: propriedade --- + No contexto computacional, uma abstração é uma representação que oculta especificidades para um consumidor de serviços, tornando sua utilização mais genérica e de fácil entendimento. Um bom exemplo é o sistema operacional (S.O) do seu laptop. Ele abstrai todos os detalhes de como o computador funciona. Você não precisa ter nenhum conhecimento sobre CPU, memória e como os programas são executados, você apenas opera o S.O e o S.O lida com os detalhes. Todos esses detalhes são ocultos por trás das cortinas do S.O - ou seja, uma abstração. Normalmente os sistemas tem multiplas camadas de abstração. Isso simplifica de forma significativa o desenvolvimento. Na programação, os desenvolvedores constroem componentes compatíveis com uma camada de abstração específica e não precisam se preocupar com todas as especificidades subjacentes, que podem ser heterogêneas. Se o componente funcionar com a camada de abstração, ele funciona no sistema - não importando o que está por debaixo dos panos. diff --git a/content/pt-br/agile_software_development.md b/content/pt-br/agile_software_development.md index 8c22a2a78c..beaca235b0 100644 --- a/content/pt-br/agile_software_development.md +++ b/content/pt-br/agile_software_development.md @@ -5,10 +5,13 @@ category: conceito --- ## O que é + Um conjunto de práticas que enfatizam ciclos de desenvolvimento iterativo e equipes auto-organizadas. Em contraste com projetos do tipo cascata, onde o valor é gerado apenas no final de um projeto, o desenvolvimento ágil de software se concentra em uma entrega incremental e contínua de valor e na melhoria evolutiva do próprio processo. ## Problema relacionado + Definir, comunicar e entender os requisitos de todas as partes interessadas em um projeto é algo dificil de se fazer, se não impossível. No entanto, os clientes querem que seus projetos sejam entregues no prazo, com boa qualidade, dentro do orçamento e do escopo. Com sua natureza cíclica, o desenvolvimento ágil de software permite a adaptação contínua dos requisitos e a adaptação mais rápida a todas as outras circunstâncias, em oposição às estratégias do tipo cascata. ## Como isso ajuda + O desenvolvimento de software ágil contém todas as fases das estratégias tradicionais (tipo cascata), como engenharia de requisitos, planejamento, implementação, revisão, teste e entrega. A maior diferença é que durante todo o tempo de projeto, ele é dividido em iterações, cada uma contendo todas essas fases citadas. Após cada iteração, o valor criado pode ser revisado com o cliente e os requisitos podem ser ajustados para o objetivo final. Além disso, a equipe de desenvolvimento faz uma retrospectiva sobre quais ações devem ser tomadas para melhorar o próprio processo. diff --git a/content/pt-br/auto_scaling.md b/content/pt-br/auto_scaling.md index 5047291aee..c1f48af137 100644 --- a/content/pt-br/auto_scaling.md +++ b/content/pt-br/auto_scaling.md @@ -9,4 +9,3 @@ O Auto scaling é a capacidade de um sistema de escalar automaticamente, normalm No passado, a infraestrutura e os aplicativos eram arquitetados para considerar o pico de uso do sistema. Essa arquitetura significava que mais recursos eram subutilizados e não eram flexíveis às mudanças na demanda consumida. A inflexibilidade significou custos mais altos para o negócio e perda de negócios devido a interrupções ocasionadas pela demanda excessiva de recursos. Ao alavancar o uso da nuvem, virtualização e conteinerização de aplicações e suas dependências, as organizações podem criar aplicações que podem ser escaladas de acordo com as demandas dos usuários. Eles podem monitorar a demanda de aplicações e escala-las automaticamente, proporcionando uma experiência ideal. Considere o aumento na audiência da Netflix todas as sextas-feiras à noite. O auto scaling significa adicionar mais recursos dinamicamente: por exemplo, aumentar o número de servidores possibilitando um tempo maior de streaming de vídeo e reduzir os recursos quando o consumo for normalizado. - diff --git a/content/pt-br/canary_deployment.md b/content/pt-br/canary_deployment.md index 01847018e7..05df8d1269 100644 --- a/content/pt-br/canary_deployment.md +++ b/content/pt-br/canary_deployment.md @@ -5,12 +5,15 @@ category: conceito --- ## O que é + Implantação Canário é uma estratégia de implantação que começa com dois ambientes: um com tráfego e outro contendo o código atualizado sem tráfego. O tráfego é gradualmente movido da versão original do aplicativo para a versão atualizada. Pode começar movendo 1% do tráfego, depois 10%, 25% e assim por diante, até que tudo esteja passando pela versão atualizada. As organizações podem testar a nova versão do software em produção, obter feedback, diagnosticar erros e reverter rapidamente para a versão estável, se necessário. O termo "canário" refere-se à prática do "canário em uma mina de carvão", onde aves canárias foram levadas para minas de carvão para manter os mineiros seguros. Se gases nocivos inodoros estivessem presentes, o pássaro morreria e os mineiros sabiam que tinham que evacuar rapidamente. Da mesma forma, se algo der errado com o código atualizado, o tráfego será "evacuado" de volta à versão original. ## Problema relacionado + Não importa o quão completa seja a estratégia de teste, sempre existirá alguns bugs a serem descobertos na produção. Mudar 100% do tráfego de uma versão de um aplicativo para outra pode levar a falhas mais impactantes. ## Como isso ajuda -As implantações canários permitem que as organizações vejam como o novo aplicativo se comporta nos cenários de produção antes de mover o tráfego para a nova versão. Essa estratégia permite que as organizações minimizem o tempo de inatividade e a reversão rápida em caso de problemas com a nova implantação. Também permite testes de aplicativos de produção mais aprofundados sem um impacto significativo na experiência geral do usuário. \ No newline at end of file + +As implantações canários permitem que as organizações vejam como o novo aplicativo se comporta nos cenários de produção antes de mover o tráfego para a nova versão. Essa estratégia permite que as organizações minimizem o tempo de inatividade e a reversão rápida em caso de problemas com a nova implantação. Também permite testes de aplicativos de produção mais aprofundados sem um impacto significativo na experiência geral do usuário. diff --git a/content/pt-br/client_server_architecture.md b/content/pt-br/client_server_architecture.md index 9d181a21d7..2484e7398d 100644 --- a/content/pt-br/client_server_architecture.md +++ b/content/pt-br/client_server_architecture.md @@ -15,4 +15,4 @@ Uma arquitetura cliente-servidor resolve um grande desafio que os aplicativos in ## Como isso ajuda -Ao implementar a lógica do aplicativo em um servidor ou serviço remoto, os operadores podem atualizar isso sem precisar alterar a lógica no lado do cliente. Isso significa que as atualizações podem ser feitas com muito mais frequência. Armazenar dados no servidor permite que muitos clientes vejam e compartilhem os mesmos dados. Considere a diferença entre usar um processador de texto online, comparado a um processador de texto offline tradicional. No primeiro, seus arquivos existem no lado do servidor e podem ser compartilhados com outros usuários que simplesmente os baixam do servidor. No mundo legado, os arquivos precisavam ser copiados para mídia removível (disquetes!) e compartilhados com indivíduos. \ No newline at end of file +Ao implementar a lógica do aplicativo em um servidor ou serviço remoto, os operadores podem atualizar isso sem precisar alterar a lógica no lado do cliente. Isso significa que as atualizações podem ser feitas com muito mais frequência. Armazenar dados no servidor permite que muitos clientes vejam e compartilhem os mesmos dados. Considere a diferença entre usar um processador de texto online, comparado a um processador de texto offline tradicional. No primeiro, seus arquivos existem no lado do servidor e podem ser compartilhados com outros usuários que simplesmente os baixam do servidor. No mundo legado, os arquivos precisavam ser copiados para mídia removível (disquetes!) e compartilhados com indivíduos. diff --git a/content/pt-br/cloud_native_apps.md b/content/pt-br/cloud_native_apps.md index 269ef94fe4..c31102528e 100644 --- a/content/pt-br/cloud_native_apps.md +++ b/content/pt-br/cloud_native_apps.md @@ -5,10 +5,13 @@ category: conceito --- ## O que é + As aplicações nativas em nuvem são projetadas especificamente para aproveitar as inovações em [computação em nuvem](/cloud_computing/). Essas aplicações se integram facilmente às suas respectivas arquiteturas de nuvem, aproveitando, assim, os recursos e o [dimensionamento](/scalability/) da nuvem. Também se refere a aplicativos que aproveitam as inovações da infraestrutura impulsionadas pela computação em nuvem. Hoje, as aplicações nativas em nuvem incluem aplicativos que são executados tanto em datacenter de um provedor de nuvem pública, quanto em plataformas de nuvens privadas. ## Problema relacionado + Tradicionalmente, os ambientes locais forneciam recursos de computação de maneira bastante personalizada. Cada datacenter tinha seus serviços [fortemente acomplados](/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](/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 -Embora não haja um "caminho único" para aplicativos nativos em nuvem, eles têm alguns pontos em comum. Os aplicativos nativos em nuvem são resilientes, gerenciáveis e auxiliados pelo conjunto de serviços em nuvem que os acompanham. Os vários serviços em nuvem permitem um alto grau de [observabilidade](/observability/), permitindo que os usuários detectem e resolvam problemas antes que eles escalem. Combinados com automação robusta, eles permitem que os engenheiros façam mudanças de alto impacto com frequência e previsivelmente com o mínimo de esforço. \ No newline at end of file + +Embora não haja um "caminho único" para aplicativos nativos em nuvem, eles têm alguns pontos em comum. Os aplicativos nativos em nuvem são resilientes, gerenciáveis e auxiliados pelo conjunto de serviços em nuvem que os acompanham. Os vários serviços em nuvem permitem um alto grau de [observabilidade](/observability/), permitindo que os usuários detectem e resolvam problemas antes que eles escalem. Combinados com automação robusta, eles permitem que os engenheiros façam mudanças de alto impacto com frequência e previsivelmente com o mínimo de esforço. diff --git a/content/pt-br/cluster.md b/content/pt-br/cluster.md index aa9b85d147..b52cbbf522 100644 --- a/content/pt-br/cluster.md +++ b/content/pt-br/cluster.md @@ -5,12 +5,13 @@ category: conceito --- ## O que é + Um cluster é um grupo de máquinas ou aplicações que trabalham juntos para um objetivo comum. No contexto da computação nativa em nuvem, o termo é mais frequentemente aplicado ao Kubernetes. Um cluster Kubernetes é um conjunto de serviços (ou cargas de trabalho) executados em seus próprios contêineres, geralmente em máquinas diferentes. O conjunto de todos esses serviços [contêinerizados](/pt-br/containerization/), conectados em uma rede, representam um cluster. ## Problema relacionado + Um software executado em uma única máquina, apresenta um único ponto de falha, por exemplo, se essa máquina travar ou alguém desconectar acidentalmente o cabo de alimentação, algum sistema crítico para os negócios pode ficar offline. É por isso que os softwares modernos geralmente são construídos como [sistemas distribuídos](/distributed_apps/), agrupados em clusters. ## Como isso ajuda -Aplicações distribuídas em cluster são executadas em várias máquinas, eliminando um único ponto de falha. Mas construir sistemas distribuídos é muito difícil. Na verdade, é uma disciplina de ciência da computação com suas especificidades. A necessidade de sistemas globais e anos de tentativa e erro levaram ao desenvolvimento de um novo tipo de *stack* de tecnologia: [tecnologias nativas da nuvem](/cloud_native_tech/). Essas novas tecnologias são as peças chaves que facilitam a operação e a criação de sistemas distribuídos. - +Aplicações distribuídas em cluster são executadas em várias máquinas, eliminando um único ponto de falha. Mas construir sistemas distribuídos é muito difícil. Na verdade, é uma disciplina de ciência da computação com suas especificidades. A necessidade de sistemas globais e anos de tentativa e erro levaram ao desenvolvimento de um novo tipo de *stack* de tecnologia: [tecnologias nativas da nuvem](/cloud_native_tech/). Essas novas tecnologias são as peças chaves que facilitam a operação e a criação de sistemas distribuídos. diff --git a/content/pt-br/container.md b/content/pt-br/container.md index 7d19b93a74..c2abc28379 100644 --- a/content/pt-br/container.md +++ b/content/pt-br/container.md @@ -5,12 +5,15 @@ category: tecnologia --- ## O que é + Um contêiner é um processo em execução com restrições de recursos e capacidade gerenciadas pelo sistema operacional. Os arquivos disponíveis para o processo de contêiner são empacotados como uma imagem de contêiner. Os contêineres são executados um ao lado do outro na mesma máquina, mas normalmente o sistema operacional impede que os processos de contêiner separados interajam entre si. ## Problema relacionado + Antes da existência dos contêineres, eram necessárias máquinas separadas eram para executar os aplicativos. Cada máquina exigiria seu próprio sistema operacional, que consome CPU, memória e espaço em disco, tudo para que um aplicativo individual funcione. Além disso, a manutenção, atualização e inicialização de um sistema operacional é outra fonte significativa de trabalho repetitivo. ## Como isso ajuda + Os contêineres compartilham o mesmo sistema operacional e seus recursos de máquina, diminuindo a sobrecarga de recursos do sistema operacional e criando um uso eficiente da máquina física. Essa funcionalidade só é possível porque os contêineres geralmente têm limitações para interagir uns com os outros. Isso permite que muitos outros aplicativos sejam executados na mesma máquina física. No entanto, existem limitações. Como os contêineres compartilham o mesmo sistema operacional, os processos podem ser considerados menos seguros do que outras alternativas. Os contêineres também exigem limites nos recursos compartilhados. Para garantir recursos, os administradores devem restringir e limitar o uso de memória e CPU para que outros aplicativos não tenham um desempenho ruim. diff --git a/content/pt-br/containerization.md b/content/pt-br/containerization.md index 926ebd8edc..31dfe5ca35 100644 --- a/content/pt-br/containerization.md +++ b/content/pt-br/containerization.md @@ -5,10 +5,13 @@ category: tecnologia --- ## O que é + A conteinerização é o processo de agrupar uma aplicação e suas dependências em uma [imagem de contêiner](/container-image/). O processo de criação do contêiner requer adesão ao padrão [Open Container Initiative](https://opencontainers.org) (OCI). Desde que a saída seja uma imagem de contêiner que atenda a esse padrão, a ferramenta de conteinerização usada não importa. ## Problema relacionado + Antes que o uso de contêineres se tornasse mais comum , as organizações usavam máquinas virtuais (VMs) para orquestrar várias aplicações em uma única [máquina bare metal](/pt-br/bare_metal_machine/). As VMs são significativamente maiores que os contêineres e exigem um *hypervisor* para serem executados. Devido ao armazenamento, backup e transferência desses *templates* de VM maiores, a criação dos *templates* de VM também é lenta. Além disso, as VMs podem sofrer inconsistências nas configurações, o que viola o princípio da [imutabilidade](/immutable_infrastructure/). ## Como isso ajuda + As imagens de contêiner são leves (ao contrário das VMs tradicionais) e o processo de conteinerização requer apenas um arquivo com uma lista de dependências. Esse arquivo pode ser versionado e o processo de compilação pode ser automatizado, permitindo que uma organização se concentre em outras prioridades enquanto os processos automatizados cuidam da compilação. Uma imagem de contêiner é armazenada por um identificador exclusivo vinculado ao seu conteúdo e configuração exatos. À medida que os contêineres são programados e reprogramados, eles sempre são redefinidos para seu estado inicial, o que elimina inconsistências de configuração. diff --git a/content/pt-br/continuous_delivery.md b/content/pt-br/continuous_delivery.md index 23ece989ed..566b6f6000 100644 --- a/content/pt-br/continuous_delivery.md +++ b/content/pt-br/continuous_delivery.md @@ -5,10 +5,13 @@ category: conceito --- ## O que é + A entrega contínua, muitas vezes conhecida como CD, é um conjunto de práticas nas quais as alterações de código são implantadas automaticamente em um ambiente de aceitação (ou, no caso de implantação contínua, na produção). A entrega contínua inclui procedimentos cruciais para garantir que o software seja testado adequadamente antes da implantação e fornecer uma maneira de reverter as alterações, se necessário. A integração contínua (CI) é o primeiro passo para a entrega contínua (ou seja, as alterações precisam se fundir de forma limpa antes de serem testadas e implantadas). ## Problema relacionado + Implantar atualizações [confiáveis](/reliability/) se torna um problema em escala. Idealmente, implantaríamos com mais frequência para oferecer melhor valor aos usuários finais. No entanto, fazê-lo manualmente se traduz em altos custos de transação para cada alteração. Historicamente, para evitar esses custos, as organizações lançam com menos frequência, implantando mais mudanças de uma só vez e aumentando o risco que algo dê errado. ## Como isso ajuda + As estratégias de entrega contínua criam um caminho totalmente automatizado para a produção que testa e implanta o software usando várias estratégias de implantação, como versões [canary](/pt-br/canary_deployment/) ou [blue-green](/pt-br/blue_green_deployment/). Isso permite que os desenvolvedores implantem o código com frequência, dando a tranquilidade de que a nova revisão foi testada. Normalmente, o desenvolvimento *trunk-based* é usado em estratégias de entrega contínua, em oposição aos recursos de *branch* ou *pull requests*. diff --git a/content/pt-br/continuous_integration.md b/content/pt-br/continuous_integration.md index d2c7631bbf..1c28e59603 100644 --- a/content/pt-br/continuous_integration.md +++ b/content/pt-br/continuous_integration.md @@ -5,10 +5,13 @@ category: conceito --- ## O que é + A integração contínua (continuous integration - CI), é a prática de integrar mudanças de código da maneira mais regular possível. A integração contínua é um pré-requisito para a [entrega contínua](/pt-br/continuous_delivery/). Tradicionalmente, o processo de integração contínua começa quando as alterações do código são confirmadas em um sistema de controle de código-fonte (Git, Mercurial ou Subversion) e termina com o artefato testado e pronto para ser consumido por um sistema de entrega contínua. ## Problema relacionado + Os sistemas de software geralmente são grandes e complexos, com vários desenvolvedores mantendo e atualizando-os. Trabalhando em paralelo e em diferentes partes do sistema, esses desenvolvedores podem fazer alterações conflitantes e inadvertidamente podem atrapalhar o trabalho um do outro. Além disso, com vários desenvolvedores trabalhando no mesmo projeto, quaisquer tarefas diárias, como testar e avaliar a qualidade do código, precisariam ser repetidas por cada desenvolvedor, e assim, ocasionando a perda de tempo. ## Como isso ajuda + A integração contínua verifica automaticamente se as alterações de código são mescladas de forma limpa sempre que um desenvolvedor confirma uma alteração. É uma prática quase onipresente usar o servidor de integração contínua para executar as verificações de qualidade de código, testes e até implantações. Assim, torna-se uma implementação concreta do controle de qualidade dentro das equipes. A integração contínua permite que as equipes de software transformem cada envio do código em uma falha concreta ou em um candidato a versão estável. diff --git a/content/pt-br/contribute/_index.md b/content/pt-br/contribute/_index.md index 90b1f990f4..e1d59c54d2 100644 --- a/content/pt-br/contribute/_index.md +++ b/content/pt-br/contribute/_index.md @@ -14,12 +14,14 @@ Você pode contribuir de três formas: 2) Atualizando termos existentes 3) Traduzindo o glossário para seu idioma nativo -## Faça parte da comunidade do glossário! +## Faça parte da comunidade do glossário Considere participar das nossas reuniões mensais do grupo de trabalho do glossário se quiser contribuir regularmente. Você pode encontrar detalhes da reunião no calendário da CNCF. Você também pode falar com as pessoas mantenedoras e colaboradoras em nosso canal `#glossary` no slack da CNCF. + ## Sugira novos termos + Você pode sugerir um novo termo para outra pessoas trabalharem na definição ou criar você mesmo. De qualquer forma, você deve começar abrindo uma *issue* (importante notar que você precisa de uma conta do Github para isso). @@ -27,6 +29,7 @@ Abaixo, temos um passo a passo para caso você ainda não esteja familiarizado c [guia de estilo](/pt-br/style-guide/). ### Abrindo uma issue + Vá para as *issues* do [repositório no Github](https://github.com/cncf/glossary/issues) e clique em "nova issue". ![issues](/images/how-to/howto-01.png) @@ -59,7 +62,6 @@ Uma vez que o termo esteja pronto para submeter o pull request, vá para o diret ![content](/images/how-to/howto-05.png) - Então `en/` (ou o diretório da linguagem que está propondo o termo): ![language folder](/images/how-to/howto-06.png) @@ -95,9 +97,11 @@ Agora você já deve ver seu pull request em "Pull Requests": ![prs](/images/how-to/howto-13.png) ## Atualizando um termo existente + Para atualizar um termo existente, você pode sugerir uma mudança abrindo uma *issue* ou diretamente criando um pull request. ### Solicitando uma mudança por meio de uma issue + Se você quer informar um problema com um termo mas não sabe ou não quer corrigir você mesmo, clique em "report issue": ![report issue](/images/how-to/howto-14.png) @@ -107,6 +111,7 @@ Isso vai imediatamente vai abrir uma *issue*. Escreva quais mudanças são neces ![submit issue](/images/how-to/howto-15.png) ### Atualizando diretamente um termo + Para alterar um termo diretamente, vá para "edit this page": ![edit this page](/images/how-to/howto-16.png) @@ -115,8 +120,6 @@ Isso vai abrir a definição do termo no Github. Faça suas alterações e envie informações detalhadas sobre como fazer isso. ## Ajude a traduzir o glossário + Para ajudar a traduzir o glossário para o seu idioma nativo, participe do canal `#glossary-localizations` no slack da CNCF. Você pode fazer parte de um time existente ou criar uma novo. Participe também das reuniões mensais do grupo de trabalho do glossário. Você pode encontrar detalhes da reunião no [calendário da CNCF](https://www.cncf.io/calendar/). - - - diff --git a/content/pt-br/contributor-ladder/_index.md b/content/pt-br/contributor-ladder/_index.md index 8eaae3075f..71717ac114 100644 --- a/content/pt-br/contributor-ladder/_index.md +++ b/content/pt-br/contributor-ladder/_index.md @@ -96,4 +96,3 @@ Se e quando os níveis de comprometimento dos contribuidores mudam, os contribui ## Voltando para uma função anterior Se e quando alguém estiver disponível para voltar a uma função de colaborador anterior, a liderança do projeto pode providenciar e considerar isso. - diff --git a/content/pt-br/devops.md b/content/pt-br/devops.md index 58706a6064..28df78ba5c 100644 --- a/content/pt-br/devops.md +++ b/content/pt-br/devops.md @@ -5,13 +5,16 @@ category: conceito --- ## O que é + DevOps é uma metodologia em que times são responsáveis por todo o processo desde o desenvolvimento da aplicação até a operação em produção, por isso o nome DevOps (Dev e Ops). Esta metodologia vai além da implementação de um conjunto de tecnologias, requer uma mudança profunda na cultura e nos processos. Além disso, DevOps orienta que o trabalho dos times seja focado em pequenos componentes (ao invés de uma funcionalidade completa), diminuindo as tranferências de responsabilidade ( _handoffs_ ), que são uma fonte comum de erros. ## 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. 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. ## Como isso ajuda + Com apenas um time gerenciando todo o ciclo de vida de uma aplicação, o número de transferências de trabalho (responsabilidade) são menores, os riscos de implantação em produção são reduzidos, a qualidade do código é melhorada pois os times são também responsáveis pela performance do código em produção, e a satisfação dos trabalhadores é maior devido à maior autonomia e responsabilidade. diff --git a/content/pt-br/style-guide/_index.md b/content/pt-br/style-guide/_index.md index e69416e51c..3a48862c62 100644 --- a/content/pt-br/style-guide/_index.md +++ b/content/pt-br/style-guide/_index.md @@ -64,8 +64,8 @@ title: Modelo de Definição A label `status` vem logo depois da label de título. Essa label serve para indicar se a definição já está completamente revisada e aprovada, ou se requer mais esforços. - Os valores aceitos são: + - Completed (em português, finalizado) - Feedback Appreciated (em português, aceitando feedbacks) - Not Started (em português, não iniciado) @@ -97,6 +97,7 @@ category: Conceito ### Definição do glossário #### Subcabeçalhos + As definições para **tecnologia** e **conceito** contém três subcabeçalhos: - **O que é**: forneça uma visão curta e clara da definição abordada. diff --git a/content/zh-cn/_index.md b/content/zh-cn/_index.md index 1b4546952a..81a03c93e3 100644 --- a/content/zh-cn/_index.md +++ b/content/zh-cn/_index.md @@ -1,4 +1,3 @@ - --- title: "云原生词汇表" --- diff --git a/content/zh-cn/container-image.md b/content/zh-cn/container-image.md index 77ece20f06..16c1abf358 100644 --- a/content/zh-cn/container-image.md +++ b/content/zh-cn/container-image.md @@ -23,4 +23,3 @@ category: 概念 容器镜像将一个应用程序与它的任何运行时的依赖性捆绑在一起，例如一个应用程序服务器。 这提供了所有环境的一致性，包括开发人员的机器。 容器镜像可用于实例化所需的多个容器，允许更大的可扩展性。 - diff --git a/content/zh-cn/container.md b/content/zh-cn/container.md index 02c4c5fb7f..dbbc83f254 100644 --- a/content/zh-cn/container.md +++ b/content/zh-cn/container.md @@ -23,4 +23,3 @@ category: 技术 但是，有一些限制。由于容器共享相同的操作系统，因此可以认为进程不如替代方法安全。 容器还需要对共享资源进行限制。 为了保证资源， 管理员必须约束和限制内存和 CPU 的使用，以使其他应用程序不会表现不佳。 - diff --git a/content/zh-cn/continuous_delivery.md b/content/zh-cn/continuous_delivery.md index 2b4bb75fb3..d3730b54a3 100644 --- a/content/zh-cn/continuous_delivery.md +++ b/content/zh-cn/continuous_delivery.md @@ -22,4 +22,3 @@ CD 关键是包括确保软件在部署前得到充分测试的程序，并提 CD 策略创建了一个完全自动化的生产路径，使用各种部署策略测试和部署软件，如 [canary](/zh-cn/canary_deployment/) 或 [blue-green](/zh-cn/blue_green_deployment/) 发布。 这使得开发人员可以频繁地部署代码，让他们放心地认为新的修订版已经过测试。 通常情况下，CD 策略中使用基于主干的开发，而不是功能分支或拉动请求。 - diff --git a/content/zh-cn/contribute/_index.md b/content/zh-cn/contribute/_index.md index b271c4033a..eaff030f34 100644 --- a/content/zh-cn/contribute/_index.md +++ b/content/zh-cn/contribute/_index.md @@ -15,10 +15,12 @@ menu: 3) [更新现有术语](#更新现有术语) 4) [云原生词汇表翻译帮助](#云原生词汇表翻译帮助) -## 加入 Glossary 社区! +## 加入 Glossary 社区 + 如果你想定期做出贡献，可以考虑加入我们每月的词汇工作组会议。你可以在 [CNCF 日历](https://www.cncf.io/calendar/) 中找到会议细节。你也可以在 CNCF Slack 的 [#glossary](https://cloud-native.slack.com/archives/C02TX20MQBB) 频道中与维护者和其他贡献者联系，我们很乐意见到你! ## 在现有的议题上工作 + 进入云原生词汇表 GitHub 仓库的 [议题](https://github.com/cncf/glossary/issues)。在那里你会看到一个所有议题的列表。你可以通过标签来过滤（例如，English language, help needed, good first issue）。请注意，你需要一个 GitHub 账户来做这些事情。 ![Issue 和 labels](/images/how-to/issue-and-labels.png) @@ -36,11 +38,13 @@ menu: 一旦他们把它分配给你，你就可以开始工作了。接下来的步骤，请参考 [提交一个新术语（创建一个PR）](#submitting-a-new-term)部分。 ## 提出新术语 + 你可以提出一个新的术语让别人去研究，或者自己创造一个新的定义。无论哪种方式，你都要从创建一个议题开始。请注意，术语必须符合 [CNCF的云原生定义](https://github.com/cncf/toc/blob/main/DEFINITION.md)。唯一的例外是理解云原生概念所需的基础性术语。 以下是为那些还不熟悉 GitHub 的人提供的分步指南。**如果你是 GitHub 的专业人员**，请**特别**看一下，确保你使用我们的议题模板，适当的命名惯例，在 Slack 上声明一个 PR（否则我们可能会错过它），以及在哪里找到文件模板。在开始之前，请确保阅读 [风格指南](/zh-cn/style-guide/)--谢谢! ### 创建议题 + 进入云原生词汇表 GitHub 仓库的 [议题](https://github.com/cncf/glossary/issues)，点击 "new issue"。 ![议题](/images/how-to/howto-01.png) @@ -52,6 +56,7 @@ menu: 添加你所建议的词，回答下面的两个议题，勾选复选框，然后点击 "submit new issue"。如果你只是提出一个新词，你就完成了! 要进行工作，请按照接下来的步骤进行。 ### 分流你的议题 + 接下来，维护者将对该议题进行分流。这意味着他们将评估该术语是否应成为术语表的一部分（注意，不是每个术语都会被接受。术语应该是既定的、广泛使用的云计算原生术语）。 请让维护者知道你已经在 Slack 上提交了一个术语，否则他们可能会错过它。最好标记 @Catherine Paganini, @jmo, @Seokho Son, @Jihoon Seo, 和/或 @iamnoah。如果该术语被批准，并且你想从事该工作，他们会将其分配给你。 @@ -99,9 +104,11 @@ menu: ![prs](/images/how-to/howto-13.png) ## 更新现有术语 + 要更新现有术语，您可以通过议题提出更改建议，也可以通过提交拉取请求 (PR) 直接更新术语。 ### 通过 issue 请求更改 + 如果您想标记一个术语的议题，但不知道如何或想自己修复它，请单击 "report issue"。 ![报告议题](/images/how-to/howto-14.png) @@ -111,6 +118,7 @@ menu: ![提交议题](/images/how-to/howto-15.png) ### 直接更新术语 + 如要直接更改术语，请转到“edit this page”。 ![编辑此页面](/images/how-to/howto-16.png) @@ -118,4 +126,5 @@ menu: 这将打开术语的 GitHub 页面。进行更改并提交 PR。有关详细说明，请参阅上面的“提交新术语”(跳转到有关降价的部分)。 ## 云原生词汇表翻译帮助 + 为了帮助将云原生词汇表翻译成您的母语，请加入 CNCF Slack 上的 #glossary-localizations 频道并告诉我们。您可以加入现有团队或创建新团队（要查看需要什么，请查看 [Localization Guide](https://github.com/cncf/glossary/blob/main/LOCALIZATION.md)）。也请参加我们每月的词汇表工作组会议。你可以在 [CNCF 日历](https://www.cncf.io/calendar/) 中找到会议详情。我们期待在那里与您见面！ diff --git a/content/zh-cn/devops.md b/content/zh-cn/devops.md index c43f4e7ba7..50993253d8 100644 --- a/content/zh-cn/devops.md +++ b/content/zh-cn/devops.md @@ -5,12 +5,15 @@ category: 概念 --- ## 是什么 + 开发运维是一种方法论，其中团队拥有从应用程序开发到生产操作的整个过程，因此 DevOps，它不仅仅是实施一套技术，还需要文化和流程的彻底转变。 DevOps 需要一组工程师来处理小组件（相对于整个功能），从而减少交接——一个常见的错误来源。 ## 强调的问题 + 传统上，在具有 [紧密耦合](/tightly_coupled_architectures/) [单体应用程序](/zh-cn/monolithic_apps/) 的复杂组织中，工作通常分散在多个组之间。 这导致了多次交接和较长的交货时间。 每次组件或更新准备就绪时，都会将其放入队列中以供下一个团队使用。 因为个人只参与了项目的一小部分，这种方法导致缺乏所有权。 他们的目标是将工作交给下一个小组，而不是为客户提供正确的功能——明显的优先级错位。 到代码最终投入生产时，它经过了这么多开发人员，排了这么多队列，如果代码不起作用，很难追查问题的根源。 DevOps 颠覆了这种方法。 ## 如何帮助 + 让一个团队拥有应用程序的整个生命周期可以最大限度地减少交接，降低部署到生产中的风险，提高代码质量，因为团队还负责代码在生产中的执行方式，并且由于更多的自主权和所有权而提高了员工满意度。 diff --git a/content/zh-cn/load_balancer.md b/content/zh-cn/load_balancer.md index a10d872ada..5418929955 100644 --- a/content/zh-cn/load_balancer.md +++ b/content/zh-cn/load_balancer.md @@ -5,10 +5,13 @@ category: 概念 --- ## 是什么 + 负载均衡器是一种在后端的一组服务器之间分配传入网络流量的方法。 该解决方案可以是基于软件或硬件的。 ## 解决的问题 + 这有助于解决与高可用性和分布式系统相关的问题。 在处理需要扩展到数十万用户的应用程序或服务时，通常需要将该应用程序分布在多个服务器上。 负载均衡器是路由流量的“交通警察”。 ## 如何帮助 + 负载均衡器将充当网络流量和客户端的前端。 它通常有多种方法来检查哪些服务器已启动并且处理请求的负载最低。 diff --git a/content/zh-cn/reliability.md b/content/zh-cn/reliability.md index 392b29832c..daafd9acbb 100644 --- a/content/zh-cn/reliability.md +++ b/content/zh-cn/reliability.md @@ -5,4 +5,3 @@ category: 属性 --- 从云原生的角度来看，可靠性是指系统对故障的响应能力。 如果我们有一个可以在基础架构更改和单个组件发生故障时继续工作的[分布式系统](/zh-cn/distributed_systems/) ，那么它是可靠的。 另一方面，如果它很容易出现故障，并且需要操作人员手动干预以保持其运行，则它是不可靠的。 [云原生应用程序](/zh-cn/cloud_native_apps/) 的目标是构建内在可靠的系统。 - diff --git a/content/zh-cn/serverless.md b/content/zh-cn/serverless.md index 2e4a41dbea..e4aca3320e 100644 --- a/content/zh-cn/serverless.md +++ b/content/zh-cn/serverless.md @@ -5,11 +5,14 @@ Category: Technology --- ## 是什么 + Serverless 是一种云原生开发模型，允许开发人员构建和运行应用程序，而无需管理服务器。 Serverless 中仍有服务器，但它们被 [抽象](/abstraction/) 出来，远离应用程序开发。 云提供商处理配置、维护和 [扩展](/zh-cn/scalability/) 服务器基础架构的日常工作。 开发人员可以简单地将他们的代码打包在 [容器](/zh-cn/container/) 中进行部署。 部署后，Serverless 应用程序会响应需求并根据需要自动扩展和缩减。 公共云提供商的 Serverless 产品通常通过事件驱动的执行模型按需计量。 因此，当无服务器功能处于空闲状态时，它不会花费任何费用。 ## 解决的问题 + 在标准的 [基础设施即服务 (IaaS)](/infrastructure_as_a_service/) [云计算](/zh-cn/cloud_computing/) 模型下，用户预先购买容量单位，这意味着您需要向公共云提供商支付永远在线的服务器组件的费用来运行您的应用程序。 用户有责任在高需求时扩展服务器容量，并在不在需要该容量时缩减容量。 即使在不使用应用程序时，运行应用程序所需的云基础设施也处于活动状态。 ## 如何帮助 + 相比之下，使用Serverless架构，应用程序仅在需要时启动。 当事件触发应用程序代码运行时，公共云提供商会为该代码动态分配资源。 当代码执行完成后，用户就停止为资源付款。除了成本和效率优势之外，Serverless还使开发人员从与应用程序扩展和服务器配置相关的日常和琐碎任务中解放出来。 借助Serverless，管理操作系统和文件系统、安全补丁、负载平衡、容量管理、扩展、日志记录和监控等日常任务都被交给云服务提供商。 diff --git a/content/zh-cn/style-guide/_index.md b/content/zh-cn/style-guide/_index.md index d92c01867a..d0605f935c 100644 --- a/content/zh-cn/style-guide/_index.md +++ b/content/zh-cn/style-guide/_index.md @@ -18,7 +18,7 @@ menu: 6. [力求以积极的形式表述](https://examples.yourdictionary.com/positive-sentence-examples.html) 7. [引号外不加感叹号](https://www.grammarly.com/blog/exclamation-mark/) 8. 不要夸大其词 -9. 避免重复 +9. 避免重复 10. 要简明扼要 ## Definition Template diff --git a/content/zh-cn/zero_trust_architecture.md b/content/zh-cn/zero_trust_architecture.md index 647742eb1c..18e6939017 100644 --- a/content/zh-cn/zero_trust_architecture.md +++ b/content/zh-cn/zero_trust_architecture.md @@ -18,4 +18,4 @@ category: 概念 ## 如何帮助 -采用零信任架构带来的主要好处是增加安全，减少攻击面。从你的企业系统中移除信任，现在增加了攻击者必须通过的安全门的数量和强度，以获得对系统的其他区域的访问。 \ No newline at end of file +采用零信任架构带来的主要好处是增加安全，减少攻击面。从你的企业系统中移除信任，现在增加了攻击者必须通过的安全门的数量和强度，以获得对系统的其他区域的访问。 From a9d64e5191c1887598679101efc5b99eca0d1ddd Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Thu, 2 Jun 2022 11:14:20 +0900 Subject: [PATCH 2/4] [en] Add semantic line breaks Signed-off-by: Jihoon Seo --- content/en/TLS(Transport Layer Security).md | 17 +++++-- content/en/_index.md | 37 ++++++++++---- content/en/abstraction.md | 17 ++++++- content/en/agile_software_development.md | 16 ++++-- content/en/api_gateway.md | 20 ++++++-- .../en/application_programming_interface.md | 14 ++++-- content/en/auto_scaling.md | 17 +++++-- content/en/bare_metal_machine.md | 22 ++++++-- content/en/blue_green_deployment.md | 19 +++++-- content/en/canary_deployment.md | 21 ++++++-- content/en/chaos_engineering.md | 21 ++++++-- content/en/client_server_architecture.md | 24 +++++++-- content/en/cloud_computing.md | 16 ++++-- content/en/cloud_native_apps.md | 20 ++++++-- content/en/cloud_native_security.md | 21 ++++++-- content/en/cloud_native_tech.md | 21 ++++++-- content/en/cluster.md | 17 +++++-- content/en/container-image.md | 18 +++++-- content/en/container.md | 20 ++++++-- content/en/containerization.md | 20 ++++++-- content/en/containers_as_a_service.md | 24 +++++++-- content/en/continuous_delivery.md | 20 ++++++-- content/en/continuous_deployment.md | 18 +++++-- content/en/continuous_integration.md | 16 ++++-- content/en/data_center.md | 21 ++++++-- content/en/database_as_a_service.md | 18 +++++-- content/en/debugging.md | 17 +++++-- content/en/devops.md | 21 ++++++-- content/en/devsecops.md | 20 ++++++-- content/en/distributed_apps.md | 17 +++++-- content/en/distributed_systems.md | 21 ++++++-- content/en/firewall.md | 14 ++++-- content/en/function_as_a_service.md | 26 ++++++++-- content/en/gitops.md | 20 ++++++-- content/en/horizontal_scaling.md | 22 ++++++-- content/en/idempotence.md | 4 +- content/en/immutable_infrastructure.md | 19 ++++++- content/en/infrastructure_as_a_service.md | 23 +++++++-- content/en/infrastructure_as_code.md | 14 ++++-- content/en/kubernetes.md | 50 +++++++++++++++---- content/en/load_balancer.md | 11 ++-- content/en/loosely_coupled_architecture.md | 13 ++++- .../mTLS (Mutual Transport Layer Security).md | 13 +++-- content/en/managed_services.md | 11 ++-- content/en/microservices.md | 30 +++++++++-- content/en/monolithic_apps.md | 16 ++++-- content/en/nodes.md | 16 ++++-- content/en/observability.md | 13 ++++- content/en/platform_as_a_service.md | 12 +++-- content/en/policy_as_code.md | 14 ++++-- content/en/portability.md | 8 ++- content/en/reliability.md | 5 +- content/en/scalability.md | 15 +++++- content/en/security_chaos_engineering.md | 23 +++++++-- content/en/self_healing.md | 6 ++- content/en/serverless.md | 23 +++++++-- content/en/service.md | 6 ++- content/en/service_discovery.md | 12 +++-- content/en/service_mesh.md | 18 +++++-- content/en/service_proxy.md | 18 +++++-- content/en/shift_left.md | 32 +++++++++--- content/en/site_reliability_engineering.md | 17 +++++-- content/en/software_as_a_service.md | 18 +++++-- content/en/stateful_apps.md | 19 +++++-- content/en/stateless_apps.md | 24 +++++++-- content/en/tightly_coupled_architectures.md | 14 +++++- content/en/versioncontrol.md | 17 +++++-- content/en/vertical_scaling.md | 17 +++++-- content/en/virtual_machine.md | 25 ++++++++-- content/en/virtualization.md | 18 +++++-- content/en/zero_trust_architecture.md | 24 +++++++-- 71 files changed, 1076 insertions(+), 235 deletions(-) diff --git a/content/en/TLS(Transport Layer Security).md b/content/en/TLS(Transport Layer Security).md index ebeb726204..5ac331db30 100644 --- a/content/en/TLS(Transport Layer Security).md +++ b/content/en/TLS(Transport Layer Security).md @@ -6,12 +6,23 @@ category: Concept ## What it is -Transport Layer Security (TLS) is a protocol designed to provide increased security to communication over a network. It ensures the secure delivery of data sent over the Internet, avoiding possible monitoring and/or alteration of the data. This protocol is widely used in applications such as messaging, e-mail, etc. +Transport Layer Security (TLS) is a protocol designed to provide increased security to communication over a network. +It ensures the secure delivery of data sent over the Internet, +avoiding possible monitoring and/or alteration of the data. +This protocol is widely used in applications such as messaging, e-mail, etc. ## Problem it addresses -Without TLS, sensitive information such as browsing habits, e-mail correspondence, online chats, and conferencing calls can easily be traced and modified by others during the transmission. Enabling server and client applications to support TLS ensures that data transmitted between them is encrypted and not viewable by third parties. +Without TLS, sensitive information such as browsing habits, e-mail correspondence, online chats, and conferencing calls can +easily be traced and modified by others during the transmission. +Enabling server and client applications to support TLS ensures that +data transmitted between them is encrypted and not viewable by third parties. ## How it helps -TLS uses a combination of encoding techniques that provide security while transmitting data over a network. TLS allows for an encrypted connection between a client application and a server, like a web browser and a banking site. It also allows client applications to positively identify the server they are calling to, which reduces the risk of a client talking to a fraudulent site. This ensures that third parties are unable to see and monitor data transmitted between applications using TLS, which protects sensitive and private information such as credit card numbers, passwords, location, etc. +TLS uses a combination of encoding techniques that provide security while transmitting data over a network. +TLS allows for an encrypted connection between a client application and a server, like a web browser and a banking site. +It also allows client applications to positively identify the server they are calling to, +which reduces the risk of a client talking to a fraudulent site. +This ensures that third parties are unable to see and monitor data transmitted between applications using TLS, +which protects sensitive and private information such as credit card numbers, passwords, location, etc. diff --git a/content/en/_index.md b/content/en/_index.md index 02f42cece3..9e5aff4b9a 100755 --- a/content/en/_index.md +++ b/content/en/_index.md @@ -4,25 +4,42 @@ title: "Cloud Native Glossary" # Cloud Native Glossary -The Cloud Native Glossary is a project led by the CNCF Business Value Subcommittee (BVS). Its goal is to explain cloud native concepts in clear and simple language without requiring any previous technical knowledge. +The Cloud Native Glossary is a project led by the CNCF Business Value Subcommittee (BVS). +Its goal is to explain cloud native concepts in clear and simple language without requiring any previous technical knowledge.

A woman and two men presenting technical info on a stage

## Contributing -Everybody is invited to suggest changes, additions, and improvements to the Cloud Native Glossary. We employ a community-driven process governed by the CNCF to develop and improve upon this shared lexicon. This Glossary provides a vendor-neutral platform to organize a shared vocabulary around cloud native technologies. Contributions are welcome from all participants who abide by the project's purpose and charter. +Everybody is invited to suggest changes, additions, and improvements to the Cloud Native Glossary. +We employ a community-driven process governed by the CNCF to develop and improve upon this shared lexicon. +This Glossary provides a vendor-neutral platform to organize a shared vocabulary around cloud native technologies. +Contributions are welcome from all participants who abide by the project's purpose and charter. -Anyone who wishes to make a contribution may submit a GitHub issue or create a pull request. Please ensure you follow the [Style Guide](/style-guide/), read the [How To Contribute](/contribute/) doc, and join the #glossary channel on the CNCF Slack. There is also a #glossary-localizations channel for those who want to help translate the glossary into their native language. +Anyone who wishes to make a contribution may submit a GitHub issue or create a pull request. +Please ensure you follow the [Style Guide](/style-guide/), read the [How To Contribute](/contribute/) doc, and join the #glossary channel on the CNCF Slack. +There is also a #glossary-localizations channel for those who want to help translate the glossary into their native language. ## 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. For a complete contributor list, please refer to [this GitHub page](https://github.com/cncf/glossary/graphs/contributors). - -The Glossary is maintained by [Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), [Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), [Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/), [Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/), and [Seokho Son](https://www.linkedin.com/in/seokho-son/). +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. +For a complete contributor list, please refer to [this GitHub page](https://github.com/cncf/glossary/graphs/contributors). + +The Glossary is maintained by +[Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), +[Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), +[Jihoon Seo](https://www.linkedin.com/in/jihoon-seo/), +[Noah Ispas](https://www.linkedin.com/in/noah-ispas-0665b42a/), +and [Seokho Son](https://www.linkedin.com/in/seokho-son/). ## License -All code contributions are under the Apache 2.0 license. Documentation is distributed under CC BY 4.0. +All code contributions are under the Apache 2.0 license. +Documentation is distributed under CC BY 4.0. diff --git a/content/en/abstraction.md b/content/en/abstraction.md index 7d5248ef52..dd8d966831 100644 --- a/content/en/abstraction.md +++ b/content/en/abstraction.md @@ -4,6 +4,19 @@ status: Completed category: Property --- -In the context of computing, an abstraction is a representation that hides specifics from a consumer of [services](/service/) (a consumer being a computer program or human), making a system more generic and thus easily understood. A good example is your laptop's operating system (OS). It abstracts away all the details of how your computer works. You don't need to know anything about CPU, memory, and how programs are handled, you just operate the OS and the OS deals with the details. All these details are hidden behind the OS "curtain" or abstraction. +In the context of computing, an abstraction is a representation that +hides specifics from a consumer of [services](/service/) +(a consumer being a computer program or human), +making a system more generic and thus easily understood. +A good example is your laptop's operating system (OS). +It abstracts away all the details of how your computer works. +You don't need to know anything about CPU, memory, and how programs are handled, +you just operate the OS and the OS deals with the details. +All these details are hidden behind the OS "curtain" or abstraction. -Systems typically have multiple abstraction layers. This significantly simplifies development. When programming, developers build components compatible with a particular abstraction layer and don't have to worry about all underlying specifics that can be very heterogeneous. If it works with the abstraction layer, it works with the system — no matter what's under the hood. +Systems typically have multiple abstraction layers. +This significantly simplifies development. +When programming, developers build components compatible with a particular abstraction layer and +don't have to worry about all underlying specifics that can be very heterogeneous. +If it works with the abstraction layer, it works with the system +— no matter what's under the hood. diff --git a/content/en/agile_software_development.md b/content/en/agile_software_development.md index d28374cabe..6e10ef93e2 100644 --- a/content/en/agile_software_development.md +++ b/content/en/agile_software_development.md @@ -6,12 +6,22 @@ category: concept ## What it is -A set of practices that emphasize iterative development cycles and self-organizing teams. In contrast to waterfall-like projects where value is generated only at the very end of a project, agile software development focuses on a continuous, incremental delivery of value and evolutionary improvement of the process itself. +A set of practices that emphasize iterative development cycles and self-organizing teams. +In contrast to waterfall-like projects where value is generated only at the very end of a project, +agile software development focuses on a continuous, incremental delivery of value and +evolutionary improvement of the process itself. ## Problem it addresses -Defining, communicating and understanding requirements for all stakeholders in a software project is very difficult, if not impossible. Yet, customers want their software projects to be delivered on time, in good quality, on budget and on scope. With its cyclical nature, agile software development enables continuous adaptation of requirements and faster adaptation to all other circumstances as opposed to waterfall-like strategies. +Defining, communicating and understanding requirements for all stakeholders in a software project is very difficult, if not impossible. +Yet, customers want their software projects to be delivered on time, in good quality, on budget and on scope. +With its cyclical nature, agile software development enables continuous adaptation of requirements and +faster adaptation to all other circumstances as opposed to waterfall-like strategies. ## How it helps -Agile software development contains all the phases of traditional (waterfall-like) strategies, like requirements engineering, planning, implementation, review, testing and delivery. The biggest difference is that the whole time span of a software project is sliced into iterations, which each contain all those phases. After each iteration, the created value can be reviewed with the customer and requirements can be adjusted towards the end goal. Additionally the development team retrospects on which actions items to take in order to improve the process itself. +Agile software development contains all the phases of traditional (waterfall-like) strategies, +like requirements engineering, planning, implementation, review, testing and delivery. +The biggest difference is that the whole time span of a software project is sliced into iterations, which each contain all those phases. +After each iteration, the created value can be reviewed with the customer and requirements can be adjusted towards the end goal. +Additionally the development team retrospects on which actions items to take in order to improve the process itself. diff --git a/content/en/api_gateway.md b/content/en/api_gateway.md index 73ec058171..52608f64d9 100644 --- a/content/en/api_gateway.md +++ b/content/en/api_gateway.md @@ -6,12 +6,26 @@ category: technology ## What it is -An [API](/application_programming_interface/) gateway is a tool that aggregates unique application APIs, making them all available in one place. It allows organizations to move key functions, such as authentication and authorization or limiting the number of requests between applications, to a centrally managed location. An API gateway functions as a common interface to (often external) API consumers. +An [API](/application_programming_interface/) gateway is a tool that +aggregates unique application APIs, making them all available in one place. +It allows organizations to move key functions, +such as authentication and authorization or limiting the number of requests between applications, +to a centrally managed location. +An API gateway functions as a common interface to (often external) API consumers. ## Problem it addresses -If you’re making APIs available to external consumers, you'll want one entry point to manage and control all access. Additionally, if you need to apply functionality on those interactions, an API gateway allows you to uniformly apply it to all traffic without requiring any app code changes. +If you’re making APIs available to external consumers, +you'll want one entry point to manage and control all access. +Additionally, if you need to apply functionality on those interactions, +an API gateway allows you to uniformly apply it to all traffic without requiring any app code changes. ## How it helps -Providing one single access point for various APIs in an application, API gateways make it easier for organizations to apply cross-cutting business or security logic in a central location. They also allow application consumers to go to a single address for all their needs. An API gateway can simplify operational concerns like security and [observability](/observability/) by providing a single access point for requests to all web services in a system. As all requests flow through the API gateway, it presents a single place to add functionality like metrics-gathering, rate-limiting, and authorization. +Providing one single access point for various APIs in an application, +API gateways make it easier for organizations to apply cross-cutting business or security logic in a central location. +They also allow application consumers to go to a single address for all their needs. +An API gateway can simplify operational concerns like security and [observability](/observability/) +by providing a single access point for requests to all web services in a system. +As all requests flow through the API gateway, it presents a single place to +add functionality like metrics-gathering, rate-limiting, and authorization. diff --git a/content/en/application_programming_interface.md b/content/en/application_programming_interface.md index ce3b3ca22d..58ed019f79 100644 --- a/content/en/application_programming_interface.md +++ b/content/en/application_programming_interface.md @@ -6,12 +6,20 @@ category: technology ## What it is -An API is a way for computer programs to interact with each other. Just as humans interact with a website via a web page, an API allows computer programs to interact with each other. Unlike human interactions, APIs have limitations on what can and cannot be asked of them. The limitation on interaction helps to create stable and functional communication between programs. +An API is a way for computer programs to interact with each other. +Just as humans interact with a website via a web page, an API allows computer programs to interact with each other. +Unlike human interactions, APIs have limitations on what can and cannot be asked of them. +The limitation on interaction helps to create stable and functional communication between programs. ## Problem it addresses -As applications become more complex, small code changes can have drastic effects on other functionality. Applications need to take a modular approach to their functionality if they can grow and maintain stability simultaneously. Without APIs, there is a lack of a framework for the interaction between applications. Without a shared framework, it is challenging for applications to [scale](/scalability/) and integrate. +As applications become more complex, small code changes can have drastic effects on other functionality. +Applications need to take a modular approach to their functionality if they can grow and maintain stability simultaneously. +Without APIs, there is a lack of a framework for the interaction between applications. +Without a shared framework, it is challenging for applications to [scale](/scalability/) and integrate. ## How it helps -APIs allow computer programs or applications to interact and share information in a defined and understandable manner. They are the building blocks for modern applications and they provide developers with a way to integrate applications together. Whenever you hear about [microservices](/microservices/) working together, you can infer that they interact via an API. +APIs allow computer programs or applications to interact and share information in a defined and understandable manner. +They are the building blocks for modern applications and they provide developers with a way to integrate applications together. +Whenever you hear about [microservices](/microservices/) working together, you can infer that they interact via an API. diff --git a/content/en/auto_scaling.md b/content/en/auto_scaling.md index 1fa3640fa0..6f371dd1ff 100644 --- a/content/en/auto_scaling.md +++ b/content/en/auto_scaling.md @@ -4,11 +4,22 @@ status: Completed category: property --- -Autoscaling is the ability of a system to [scale](/scalability/) automatically, typically, in terms of computing resources. With an autoscaling system, resources are automatically added when needed and can scale to meet fluctuating user demands. The autoscaling process varies and is configurable to scale based on different metrics, such as memory or process time. Managed cloud services are typically associated with autoscaling functionality as there are more options and implementations available than most on-premise deployments. +Autoscaling is the ability of a system to [scale](/scalability/) automatically, typically, in terms of computing resources. +With an autoscaling system, resources are automatically added when needed and can scale to meet fluctuating user demands. +The autoscaling process varies and is configurable to scale based on different metrics, such as memory or process time. +Managed cloud services are typically associated with autoscaling functionality +as there are more options and implementations available than most on-premise deployments. -Previously, infrastructure and applications were architected to consider peak system usage. This architecture meant that more resources were underutilized and inelastic to changing consumer demand. The inelasticity meant higher costs to the business and lost business from outages due to overdemand. +Previously, infrastructure and applications were architected to consider peak system usage. +This architecture meant that more resources were underutilized and inelastic to changing consumer demand. +The inelasticity meant higher costs to the business and lost business from outages due to overdemand. -By leveraging the cloud, [virtualizing](/virtualization/), and [containerizing](/containerization/) applications and their dependencies, organizations can build applications that scale according to user demands. They can monitor application demand and automatically scale them, providing an optimal user experience. Take the increase in viewership Netflix experiences every Friday evening. Autoscaling out means dynamically adding more resources: for example, increasing the number of servers allowing for more video streaming and scaling back once consumption has normalized. +By leveraging the cloud, [virtualizing](/virtualization/), and [containerizing](/containerization/) applications and their dependencies, +organizations can build applications that scale according to user demands. +They can monitor application demand and automatically scale them, providing an optimal user experience. +Take the increase in viewership Netflix experiences every Friday evening. +Autoscaling out means dynamically adding more resources: for example, +increasing the number of servers allowing for more video streaming and scaling back once consumption has normalized. ## Related terms diff --git a/content/en/bare_metal_machine.md b/content/en/bare_metal_machine.md index efe8e93e29..4212e02757 100644 --- a/content/en/bare_metal_machine.md +++ b/content/en/bare_metal_machine.md @@ -6,14 +6,28 @@ category: technology ## What it is -Bare metal refers to a physical computer, more specifically a server, that has one, and only one, operating system. The distinction is important in modern computing because many, if not most, servers are [virtual machines](/virtual_machine/). A physical server is typically a fairly large computer with powerful hardware built-in. Installing an operating system and running applications directly on that physical hardware, without [virtualization](/virtualization/), is referred to as running on “bare metal.” +Bare metal refers to a physical computer, more specifically a server, that has one, and only one, operating system. +The distinction is important in modern computing because many, if not most, servers are [virtual machines](/virtual_machine/). +A physical server is typically a fairly large computer with powerful hardware built-in. +Installing an operating system and running applications directly on that physical hardware, +without [virtualization](/virtualization/), is referred to as running on “bare metal.” ## Problem it addresses -Pairing one operating system with one physical computer is the original pattern of computing. All the resources of the physical computer are available directly to the operating system and with no virtualization layer present, there is no artificial delay in translating operating system instructions to hardware. +Pairing one operating system with one physical computer is the original pattern of computing. +All the resources of the physical computer are available directly to the operating system and with no virtualization layer present, +there is no artificial delay in translating operating system instructions to hardware. ## How it helps -By dedicating all compute resources of a computer to a single operating system, you potentially provide the best possible performance to the operating system. If you need to run a workload that must have extremely fast access to hardware resources, bare metal may be the right solution. +By dedicating all compute resources of a computer to a single operating system, +you potentially provide the best possible performance to the operating system. +If you need to run a workload that must have extremely fast access to hardware resources, +bare metal may be the right solution. -In the context of [cloud native apps](/cloud_native_apps/), we generally think of performance in terms of [scaling](/scalability/) to a large number of concurrent events, which can be handled by [horizontal scaling](/horizontal_scaling/) (adding more machines to your resource pool). But some workloads may require [vertical scaling](/vertical_scaling/) (adding more power to an existing physical machine) and/or an extremely fast physical hardware response in which case bare metal is better suited. Bare metal also allows you to tune the physical hardware and possibly even hardware drivers to help accomplish your task. +In the context of [cloud native apps](/cloud_native_apps/), +we generally think of performance in terms of [scaling](/scalability/) to a large number of concurrent events, +which can be handled by [horizontal scaling](/horizontal_scaling/) (adding more machines to your resource pool). +But some workloads may require [vertical scaling](/vertical_scaling/) (adding more power to an existing physical machine) +and/or an extremely fast physical hardware response in which case bare metal is better suited. +Bare metal also allows you to tune the physical hardware and possibly even hardware drivers to help accomplish your task. diff --git a/content/en/blue_green_deployment.md b/content/en/blue_green_deployment.md index bbad2a0882..3abaab5cf9 100644 --- a/content/en/blue_green_deployment.md +++ b/content/en/blue_green_deployment.md @@ -6,12 +6,25 @@ category: concept ## What it is -Blue-green deployment is a strategy for updating running computer systems with minimal downtime. The operator maintains two environments, dubbed “blue” and “green”. One serves production traffic (the version all users are currently using), whilst the other is updated. Once testing has concluded on the non-active (green) environment, production traffic is switched over (often via the use of a load balancer). Note that blue-green deployment usually means switching the entire environments, comprising many services, all at once. Confusingly, sometimes the term is used with regard to individual services within a system. To avoid this ambiguity, the term “zero-downtime deployment” is preferred when referring to individual components. +Blue-green deployment is a strategy for updating running computer systems with minimal downtime. +The operator maintains two environments, dubbed “blue” and “green”. +One serves production traffic (the version all users are currently using), whilst the other is updated. +Once testing has concluded on the non-active (green) environment, +production traffic is switched over (often via the use of a load balancer). +Note that blue-green deployment usually means switching the entire environments, comprising many services, all at once. +Confusingly, sometimes the term is used with regard to individual services within a system. +To avoid this ambiguity, the term “zero-downtime deployment” is preferred when referring to individual components. ## Problem it addresses -Blue-green deployments allow minimal downtime when updating software that must be changed in "lockstep" owing to a lack of backwards compatibility. For example, blue-green deployment would be appropriate for an online store consisting of a website and a database that needs to be updated, but the new version of the database doesn’t work with the old version of the website, and vice versa. In this instance, both need to be changed at the same time. If this was done on the production system, customers would notice downtime. +Blue-green deployments allow minimal downtime when updating software that must be changed in "lockstep" owing to a lack of backwards compatibility. +For example, blue-green deployment would be appropriate for an online store +consisting of a website and a database that needs to be updated, +but the new version of the database doesn’t work with the old version of the website, and vice versa. +In this instance, both need to be changed at the same time. +If this was done on the production system, customers would notice downtime. ## How it helps -Blue-green deployment is an appropriate strategy for non-cloud native software that needs to be updated with minimal downtime. However, its use is normally a "smell" that legacy software needs to be re-engineered so that components can be updated individually. +Blue-green deployment is an appropriate strategy for non-cloud native software that needs to be updated with minimal downtime. +However, its use is normally a "smell" that legacy software needs to be re-engineered so that components can be updated individually. diff --git a/content/en/canary_deployment.md b/content/en/canary_deployment.md index dd23fa1539..18895f9b6f 100644 --- a/content/en/canary_deployment.md +++ b/content/en/canary_deployment.md @@ -6,14 +6,27 @@ category: concept ## What it is -Canary deployments is a deployment strategy that starts with two environments: one with live traffic and the other containing the updated code without live traffic. The traffic is gradually moved from the original version of the application to the updated version. It can start by moving 1% of live traffic, then 10%, 25%, and so on, until all traffic is running through the updated version. Organizations can test the new version of the software in production, get feedback, diagnose errors, and quickly rollback to the stable version if necessary. +Canary deployments is a deployment strategy that starts with two environments: +one with live traffic and the other containing the updated code without live traffic. +The traffic is gradually moved from the original version of the application to the updated version. +It can start by moving 1% of live traffic, then 10%, 25%, and so on, +until all traffic is running through the updated version. +Organizations can test the new version of the software in production, get feedback, +diagnose errors, and quickly rollback to the stable version if necessary. -The term “canary” refers to the "canary in a coal mine" practice where canary birds were taken into coal mines to keep miners safe. If odorless harmful gases were present, the bird would die, and the miners knew they had to evacuate quickly. Similarly, if something goes wrong with the updated code, live traffic is "evacuated" back to the original version. +The term “canary” refers to the "canary in a coal mine" practice +where canary birds were taken into coal mines to keep miners safe. +If odorless harmful gases were present, the bird would die, and the miners knew they had to evacuate quickly. +Similarly, if something goes wrong with the updated code, live traffic is "evacuated" back to the original version. ## Problem it addresses -No matter how thorough the testing strategy, there are always some bugs discovered in production. Shifting 100% of traffic from one version of an app to another can lead to more impactful failures. +No matter how thorough the testing strategy, there are always some bugs discovered in production. +Shifting 100% of traffic from one version of an app to another can lead to more impactful failures. ## How it helps -Canary deployments allow organizations to see how new software behaves in real-world scenarios before moving significant traffic to the new version. This strategy enables organizations to minimize downtime and quickly rollback in case of issues with the new deployment. It also allows more in-depth production application testing without a significant impact on the overall user experience. +Canary deployments allow organizations to see how new software behaves in real-world scenarios +before moving significant traffic to the new version. +This strategy enables organizations to minimize downtime and quickly rollback in case of issues with the new deployment. +It also allows more in-depth production application testing without a significant impact on the overall user experience. diff --git a/content/en/chaos_engineering.md b/content/en/chaos_engineering.md index 15bc952ba0..febc415377 100644 --- a/content/en/chaos_engineering.md +++ b/content/en/chaos_engineering.md @@ -6,12 +6,27 @@ category: concept ## What it is -Chaos Engineering or CE is the discipline of experimenting on a [distributed system](/distributed_systems/) in production to build confidence in the system's capability to withstand turbulent and unexpected conditions. +Chaos Engineering or CE is the discipline of experimenting on a [distributed system](/distributed_systems/) in production +to build confidence in the system's capability to withstand turbulent and unexpected conditions. ## Problem it addresses -[SRE](/site_reliability_engineering/) and [DevOps](/devops/) practices focus on techniques to increase product resiliency and [reliability](/reliability/). A system's ability to tolerate failures while ensuring adequate service quality is typically a software development requirement. There are several aspects involved that could lead to outages of an application, like infrastructure, platform or other moving parts of a ([microservice](/microservices/)-based) application. High-frequency deployment of new features to the production environment can result in a high probability of downtime and a critical incident — with considerable consequences to the business. +[SRE](/site_reliability_engineering/) and [DevOps](/devops/) practices focus on +techniques to increase product resiliency and [reliability](/reliability/). +A system's ability to tolerate failures while ensuring adequate service quality is +typically a software development requirement. +There are several aspects involved that could lead to outages of an application, +like infrastructure, platform or other moving parts of a ([microservice](/microservices/)-based) application. +High-frequency deployment of new features to the production environment can +result in a high probability of downtime and a critical incident +— with considerable consequences to the business. ## How it helps -Chaos engineering is a technique to meet resilience requirements. It is used to achieve resilience against infrastructure, platform, and application failures. Chaos engineers use chaos experiments to proactively inject random failures to verify that an application, infrastructure, or platform can self-heal and the failure cannot noticeably impact customers. Chaos experiments aim to discover blind spots (e.g. monitoring or autoscaling techniques) and to improve the communications between teams during critical incidents. This approach helps increase resiliency and the team's confidence in complex systems, particularly production. +Chaos engineering is a technique to meet resilience requirements. +It is used to achieve resilience against infrastructure, platform, and application failures. +Chaos engineers use chaos experiments to proactively inject random failures +to verify that an application, infrastructure, or platform can self-heal and the failure cannot noticeably impact customers. +Chaos experiments aim to discover blind spots +(e.g. monitoring or autoscaling techniques) and to improve the communications between teams during critical incidents. +This approach helps increase resiliency and the team's confidence in complex systems, particularly production. diff --git a/content/en/client_server_architecture.md b/content/en/client_server_architecture.md index dc517ffbef..b8d24fa936 100644 --- a/content/en/client_server_architecture.md +++ b/content/en/client_server_architecture.md @@ -6,14 +6,30 @@ category: concept ## What it is -In a client-server architecture, the logic (or code) that makes up an application is split between two or more components: a client that asks for work to be done (e.g. the Gmail web application running in your web browser), and one or more servers that satisfy that request (e.g. the "send email" service running on Google’s computers in the cloud). In this example, outgoing emails that you write are sent by the client (web application running in your web browser) to a server (Gmail's computers, which forward your outgoing emails to their recipients). +In a client-server architecture, the logic (or code) that makes up an application is split between two or more components: +a client that asks for work to be done +(e.g. the Gmail web application running in your web browser), +and one or more servers that satisfy that request +(e.g. the "send email" service running on Google’s computers in the cloud). +In this example, outgoing emails that you write are sent by the client (web application running in your web browser) +to a server (Gmail's computers, which forward your outgoing emails to their recipients). -This contrasts with self-contained applications (such as desktop applications) that do all the work in one place. For example, a word processing program like Microsoft Word may be installed and run entirely on your computer. +This contrasts with self-contained applications (such as desktop applications) that do all the work in one place. +For example, a word processing program like Microsoft Word may be installed and run entirely on your computer. ## Problem it addresses -A client-server architecture solves a big challenge self-contained applications pose: regular updates. In a self-contained app, for each update, users would have to download and install the latest version. Imagine having to download all of Amazon’s product catalog to your own computer before being able to browse it! +A client-server architecture solves a big challenge self-contained applications pose: regular updates. +In a self-contained app, for each update, users would have to download and install the latest version. +Imagine having to download all of Amazon’s product catalog to your own computer before being able to browse it! ## How it helps -By implementing application logic in a remote server or service, operators can update that without needing to change the logic on the client-side. This means updates can be made much more frequently. Storing data on the server allows many clients to all see and share the same data. Consider the difference between using an online word processor, compared to a traditional offline word processor. In the former, your files exist on the server-side and can be shared with other users who simply download them from the server. In the legacy world, files needed to be copied to removable media (floppy disks!) and shared with individuals. +By implementing application logic in a remote server or service, +operators can update that without needing to change the logic on the client-side. +This means updates can be made much more frequently. +Storing data on the server allows many clients to all see and share the same data. +Consider the difference between using an online word processor, compared to a traditional offline word processor. +In the former, your files exist on the server-side and +can be shared with other users who simply download them from the server. +In the legacy world, files needed to be copied to removable media (floppy disks!) and shared with individuals. diff --git a/content/en/cloud_computing.md b/content/en/cloud_computing.md index 0c5424a05b..82c968a12e 100644 --- a/content/en/cloud_computing.md +++ b/content/en/cloud_computing.md @@ -6,12 +6,22 @@ category: concept ## What it is -Cloud computing is a model that offers compute resources like CPU, network, and disk capabilities on-demand over the internet. Cloud computing gives users the ability to access and use computing power in a remote physical location. Cloud providers like AWS, GCP, Azure, DigitalOcean, and others all offer third parties the ability to rent access to compute resources in multiple geographic locations. +Cloud computing is a model that offers compute resources like CPU, network, and disk capabilities on-demand over the internet. +Cloud computing gives users the ability to access and use computing power in a remote physical location. +Cloud providers like AWS, GCP, Azure, DigitalOcean, and others all offer third parties +the ability to rent access to compute resources in multiple geographic locations. ## Problem it addresses -Organizations traditionally faced two main problems when attempting to expand their use of computing power. They either acquire, support, design, and pay for facilities to host their physical servers and network or expand and maintain those facilities. Cloud computing allows organizations to outsource some portion of their computing needs to another organization. +Organizations traditionally faced two main problems when attempting to expand their use of computing power. +They either acquire, support, design, and pay for facilities +to host their physical servers and network or expand and maintain those facilities. +Cloud computing allows organizations to outsource some portion of their computing needs to another organization. ## How it helps -Cloud providers offer organizations the ability to rent compute resources on-demand and pay for usage. This allows for two major innovations: organizations can try things without wasting time planning and spending money or resources on new physical infrastructure and they can [scale](/scalability/) as needed and on-demand. Cloud computing allows organizations to adopt as much or as little infrastructure as they need. +Cloud providers offer organizations the ability to rent compute resources on-demand and pay for usage. +This allows for two major innovations: +organizations can try things without wasting time planning and spending money or resources on new physical infrastructure +and they can [scale](/scalability/) as needed and on-demand. +Cloud computing allows organizations to adopt as much or as little infrastructure as they need. diff --git a/content/en/cloud_native_apps.md b/content/en/cloud_native_apps.md index 2bd13e8e55..fdadf24f91 100644 --- a/content/en/cloud_native_apps.md +++ b/content/en/cloud_native_apps.md @@ -6,12 +6,26 @@ category: concept ## What it is -Cloud native applications are specifically designed to take advantage of innovations in [cloud computing](/cloud_computing/). These applications integrate easily with their respective cloud architectures, taking advantage of the cloud’s resources and [scaling](/scalability/) capabilities. It also refers to applications that take advantage of innovations in infrastructure driven by cloud computing. Cloud native applications today include apps that run in a cloud provider’s datacenter and on cloud native platforms on-premise. +Cloud native applications are specifically designed to take advantage of innovations in [cloud computing](/cloud_computing/). +These applications integrate easily with their respective cloud architectures, +taking advantage of the cloud’s resources and [scaling](/scalability/) capabilities. +It also refers to applications that take advantage of innovations in infrastructure driven by cloud computing. +Cloud native applications today include apps that run in a cloud provider’s datacenter and on cloud native platforms on-premise. ## 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, 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. For example, apps that require manual intervention to start correctly cannot scale automatically, nor can they be automatically restarted in the event of a failure. +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, +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. +For example, apps that require manual intervention to start correctly cannot scale automatically, +nor can they be automatically restarted in the event of a failure. ## How it helps -While there is no “one size fits all” path to cloud native applications, they do have some commonalities. Cloud native apps are resilient, manageable, and aided by the suite of cloud services that accompany them. The various cloud services enable a high degree of [observability](/observability/), enabling users to detect and address issues before they escalate. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. +While there is no “one size fits all” path to cloud native applications, they do have some commonalities. +Cloud native apps are resilient, manageable, and aided by the suite of cloud services that accompany them. +The various cloud services enable a high degree of [observability](/observability/), +enabling users to detect and address issues before they escalate. +Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. diff --git a/content/en/cloud_native_security.md b/content/en/cloud_native_security.md index 07a77d19c2..f795e15bac 100644 --- a/content/en/cloud_native_security.md +++ b/content/en/cloud_native_security.md @@ -6,12 +6,27 @@ category: concept ## What it is -Cloud native security is an approach that builds security into [cloud native applications](/cloud_native_apps/). It ensures that security is part of the entire application lifecycle from development to production. Cloud native security seeks to ensure the same standards as traditional security models while adapting to the particulars of cloud native environments, namely rapid code changes and highly ephemeral infrastructure. Cloud native security is highly related to the practice called [DevSecOps](/devsecops/). +Cloud native security is an approach that builds security into [cloud native applications](/cloud_native_apps/). +It ensures that security is part of the entire application lifecycle from development to production. +Cloud native security seeks to ensure the same standards as traditional security models +while adapting to the particulars of cloud native environments, +namely rapid code changes and highly ephemeral infrastructure. +Cloud native security is highly related to the practice called [DevSecOps](/devsecops/). ## Problem it addresses -Traditional security models were built with a number of assumptions that are no longer valid. Cloud native apps change frequently, use a large number of open source tools and libraries, often run in vendor-controlled infrastructure, and are subject to rapid infrastructure changes. Code reviews, long quality assurance cycles, host-based vulnerability scanning, and last minute security reviews cannot scale with cloud native applications. +Traditional security models were built with a number of assumptions that are no longer valid. +Cloud native apps change frequently, use a large number of open source tools and libraries, +often run in vendor-controlled infrastructure, and are subject to rapid infrastructure changes. +Code reviews, long quality assurance cycles, host-based vulnerability scanning, +and last minute security reviews cannot scale with cloud native applications. ## How it helps -Cloud native security introduces a new way of working that protects applications by migrating from traditional security models to one where security is involved in every step of the release cycle. Manual audits and checks are largely replaced with automated scans. Rapid code release pipelines are integrated with tools that scan code for vulnerabilities before they’re compiled. Open source libraries are pulled from trusted sources and monitored for vulnerabilities. Instead of slowing change a cloud native security model embraces it by frequently updated vulnerable components or ensuring infrastructure is regularly replaced. +Cloud native security introduces a new way of working that protects applications +by migrating from traditional security models to one where security is involved in every step of the release cycle. +Manual audits and checks are largely replaced with automated scans. +Rapid code release pipelines are integrated with tools that scan code for vulnerabilities before they’re compiled. +Open source libraries are pulled from trusted sources and monitored for vulnerabilities. +Instead of slowing change a cloud native security model embraces it +by frequently updated vulnerable components or ensuring infrastructure is regularly replaced. diff --git a/content/en/cloud_native_tech.md b/content/en/cloud_native_tech.md index 77a518863a..0d0900a317 100644 --- a/content/en/cloud_native_tech.md +++ b/content/en/cloud_native_tech.md @@ -6,12 +6,27 @@ category: Concept ## What it is -Cloud native technologies, also referred to as the cloud native stack, are the technologies used to build [cloud native applications](/cloud_native_apps/). These technologies enable organizations to build and run scalable applications in modern and dynamic environments such as public, private, and hybrid clouds, while leveraging [cloud computing](/cloud_computing/) benefits to their fullest. They are designed from the ground up to exploit the capabilities of cloud computing and containers, service meshes, microservices, and immutable infrastructure exemplify this approach. +Cloud native technologies, also referred to as the cloud native stack, +are the technologies used to build [cloud native applications](/cloud_native_apps/). +These technologies enable organizations to build and run scalable applications in modern and dynamic environments +such as public, private, and hybrid clouds, +while leveraging [cloud computing](/cloud_computing/) benefits to their fullest. +They are designed from the ground up to exploit the capabilities of cloud computing and containers, service meshes, microservices, +and immutable infrastructure exemplify this approach. ## Problem it addresses -The cloud native stack has many different technology categories, addressing a variety of challenges. If you have a look at the [CNCF Cloud Native Landscape](https://landscape.cncf.io/), you'll see how many different areas it touches upon. But on a high level, they address one main set of challenges: the downsides of traditional IT operating models. Challenges include difficulties creating scalable, fault-tolerant, self-healing applications, as well as inefficient resource utilization, among others. +The cloud native stack has many different technology categories, addressing a variety of challenges. +If you have a look at the [CNCF Cloud Native Landscape](https://landscape.cncf.io/), +you'll see how many different areas it touches upon. +But on a high level, they address one main set of challenges: +the downsides of traditional IT operating models. +Challenges include difficulties creating scalable, fault-tolerant, self-healing applications, +as well as inefficient resource utilization, among others. ## How it helps -While each technology addresses a very specific problem, as a group, cloud native technologies enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. Desirable traits of cloud native systems are easier to achieve with the cloud native stack. +While each technology addresses a very specific problem, +as a group, cloud native technologies enable loosely coupled systems that are resilient, manageable, and observable. +Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. +Desirable traits of cloud native systems are easier to achieve with the cloud native stack. diff --git a/content/en/cluster.md b/content/en/cluster.md index ebb05dfd15..e053991cae 100644 --- a/content/en/cluster.md +++ b/content/en/cluster.md @@ -6,12 +6,23 @@ category: Concept ## What it is -A cluster is a group of computers or applications that work together towards a common goal. In the context of cloud native computing, the term is most often applied to Kubernetes. A Kubernetes cluster is a set of services (or workloads) that run in their own containers, usually on different machines. The collection of all these [containerized](/containerization/) services, connected over a network, represent a cluster. +A cluster is a group of computers or applications that work together towards a common goal. +In the context of cloud native computing, the term is most often applied to Kubernetes. +A Kubernetes cluster is a set of services (or workloads) that run in their own containers, usually on different machines. +The collection of all these [containerized](/containerization/) services, connected over a network, represent a cluster. ## Problem it addresses -Software that runs on a single computer presents a single point of failure — if that computer crashes, or someone accidentally unplugs the power cable, then some business-critical system may be taken offline. That's why modern software is generally built as [distributed applications](/distributed_apps/), grouped together as clusters. +Software that runs on a single computer presents a single point of failure +— if that computer crashes, or someone accidentally unplugs the power cable, +then some business-critical system may be taken offline. +That's why modern software is generally built as [distributed applications](/distributed_apps/), grouped together as clusters. ## How it helps -Clustered, distributed applications run across multiple machines, eliminating a single point of failure. But building distributed systems is really hard. In fact, it's a computer science discipline in its own right. The need for global systems and years of trial and error led to the development of a new kind of tech stack: [cloud native technologies](/cloud_native_tech/). These new technologies are the building blocks that make the operation and creation of distributed systems easier. +Clustered, distributed applications run across multiple machines, eliminating a single point of failure. +But building distributed systems is really hard. +In fact, it's a computer science discipline in its own right. +The need for global systems and years of trial and error led to the development of a new kind of tech stack: +[cloud native technologies](/cloud_native_tech/). +These new technologies are the building blocks that make the operation and creation of distributed systems easier. diff --git a/content/en/container-image.md b/content/en/container-image.md index f1233cd434..2b3b04a7e2 100644 --- a/content/en/container-image.md +++ b/content/en/container-image.md @@ -6,12 +6,24 @@ category: concept ## What it is -A container image is an immutable, static file containing the dependencies for the creation of a container. These dependencies may include a single executable binary file, system libraries, system tools, environment variables, and other required platform settings. Container images result from an application's containerization and are typically stored in container registries, where they can be downloaded and run as an isolated process using a Container Runtime Interface (CRI). A container image framework must follow the standard schema defined by the Open Container Initiative (OCI). +A container image is an immutable, static file containing the dependencies for the creation of a container. +These dependencies may include a single executable binary file, system libraries, +system tools, environment variables, and other required platform settings. +Container images result from an application's containerization and are typically stored in container registries, +where they can be downloaded and run as an isolated process using a Container Runtime Interface (CRI). +A container image framework must follow the standard schema defined by the Open Container Initiative (OCI). ## Problem it addresses -Traditionally, application servers are configured per environment, and applications are deployed to them. Any misconfiguration between environments is problematic and often leads to downtime or failed deployments. An application's environment needs to be repeatable and well-defined; otherwise, the chance of environment-related bugs increases. When application environments are configured inadequately or inaccurate, horizontal and vertical scaling of applications becomes challenging. +Traditionally, application servers are configured per environment, and applications are deployed to them. +Any misconfiguration between environments is problematic and often leads to downtime or failed deployments. +An application's environment needs to be repeatable and well-defined; +otherwise, the chance of environment-related bugs increases. +When application environments are configured inadequately or inaccurate, +horizontal and vertical scaling of applications becomes challenging. ## How it helps -Container images bundle an application with any of its runtime dependencies, such as an application server. This provides consistency across all environments, including a developer's machine. Container images can be used to instantiate as many containers as needed, allowing for greater scalability. +Container images bundle an application with any of its runtime dependencies, such as an application server. +This provides consistency across all environments, including a developer's machine. +Container images can be used to instantiate as many containers as needed, allowing for greater scalability. diff --git a/content/en/container.md b/content/en/container.md index 9ce4a298c3..151eb432bb 100644 --- a/content/en/container.md +++ b/content/en/container.md @@ -6,14 +6,26 @@ category: technology ## What it is -A container is a running process with resource and capability constraints managed by a computer’s operating system. The files available to the container process are packaged as a container image. Containers run adjacent to each other on the same machine, but typically the operating system prevents the separate container processes from interacting with each other. +A container is a running process with resource and capability constraints managed by a computer’s operating system. +The files available to the container process are packaged as a container image. +Containers run adjacent to each other on the same machine, +but typically the operating system prevents the separate container processes from interacting with each other. ## Problem it addresses -Before containers were available, separate machines were necessary to run applications. Each machine would require its own operating system, which takes CPU, memory, and disk space, all for an individual application to function. Additionally, the maintenance, upgrade, and startup of an operating system is another significant source of toil. +Before containers were available, separate machines were necessary to run applications. +Each machine would require its own operating system, which takes CPU, memory, and disk space, +all for an individual application to function. +Additionally, the maintenance, upgrade, and startup of an operating system is another significant source of toil. ## How it helps -Containers share the same operating system and its machine resources, spreading the operating system’s resource overhead and creating efficient use of the physical machine. This capability is only possible because containers are typically limited from being able to interact with each other. This allows many more applications to be run on the same physical machine. +Containers share the same operating system and its machine resources, +spreading the operating system’s resource overhead and creating efficient use of the physical machine. +This capability is only possible because containers are typically limited from being able to interact with each other. +This allows many more applications to be run on the same physical machine. -There are limitations, however. Since containers share the same operating system, processes can be considered less secure than alternatives. Containers also require limits on the shared resources. To guarantee resources, administrators must constrain and limit memory and CPU usage so that other applications do not perform poorly. +There are limitations, however. +Since containers share the same operating system, processes can be considered less secure than alternatives. +Containers also require limits on the shared resources. +To guarantee resources, administrators must constrain and limit memory and CPU usage so that other applications do not perform poorly. diff --git a/content/en/containerization.md b/content/en/containerization.md index b37c3c2db3..f7432d35b8 100644 --- a/content/en/containerization.md +++ b/content/en/containerization.md @@ -6,12 +6,26 @@ category: Technology ## What it is -Containerization is the process of bundling an application and its dependencies into a [container image](/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 bundling an application and its dependencies into a [container image](/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. ## Problem it addresses -Before containers became prevalent, organizations relied on virtual machines (VMs) to orchestrate multiple applications on a single [bare-metal machine](/bare_metal_machine/). VMs are significantly larger than containers and require a hypervisor to run. Due to the storage, backup, and transfer of these larger VM templates, creating the VM templates is also slow. Additionally, VMs can suffer from configuration drift which violates the principle of [immutability](/immutable_infrastructure/). +Before containers became prevalent, organizations relied on virtual machines (VMs) to +orchestrate multiple applications on a single [bare-metal machine](/bare_metal_machine/). +VMs are significantly larger than containers and require a hypervisor to run. +Due to the storage, backup, and transfer of these larger VM templates, creating the VM templates is also slow. +Additionally, VMs can suffer from configuration drift which violates the principle of [immutability](/immutable_infrastructure/). ## How it helps -Container images are lightweight (unlike traditional VMs) and the containerization process requires a file with a list of dependencies. This file can be version controlled and the build process automated, allowing an organization to focus on other priorities while the automated processes take care of the build. A container image is stored by a unique identifier that is tied to its exact content and configuration. As containers are scheduled and rescheduled, they are always reset to their initial state which eliminates configuration drift. +Container images are lightweight (unlike traditional VMs) and +the containerization process requires a file with a list of dependencies. +This file can be version controlled and the build process automated, +allowing an organization to focus on other priorities +while the automated processes take care of the build. +A container image is stored by a unique identifier +that is tied to its exact content and configuration. +As containers are scheduled and rescheduled, +they are always reset to their initial state which eliminates configuration drift. diff --git a/content/en/containers_as_a_service.md b/content/en/containers_as_a_service.md index b644e6c7c3..b408e398ce 100644 --- a/content/en/containers_as_a_service.md +++ b/content/en/containers_as_a_service.md @@ -6,14 +6,30 @@ category: Technology ## What it is -Containers-as-a-Service (CaaS) is a cloud service that helps manage and deploy apps using [container](/container/)-based [abstraction](/abstraction/). This service can be deployed on-premises or in the cloud. +Containers-as-a-Service (CaaS) is a cloud service that helps manage and deploy apps +using [container](/container/)-based [abstraction](/abstraction/). +This service can be deployed on-premises or in the cloud. -CaaS providers offer a framework or orchestration platform that automates key IT functions on which containers are deployed and managed. It helps developers build secure and [scalable](/scalability/) containerized apps. Because users only buy the resources they need (scheduling capabilities, load balancing, etc.), they save money and increase efficiency. Containers create consistent environments to rapidly develop and deliver [cloud-native applications](/cloud_native_apps/) that can run anywhere. +CaaS providers offer a framework or orchestration platform that +automates key IT functions on which containers are deployed and managed. +It helps developers build secure and [scalable](/scalability/) containerized apps. +Because users only buy the resources they need (scheduling capabilities, load balancing, etc.), +they save money and increase efficiency. +Containers create consistent environments to rapidly develop and +deliver [cloud-native applications](/cloud_native_apps/) that can run anywhere. ## Problem it addresses -Without CaaS, software development teams need to deploy, manage, and monitor the underlying infrastructure that containers run on. +Without CaaS, software development teams need to deploy, manage, and monitor +the underlying infrastructure that containers run on. ## How it helps -When deploying containerized applications to a CaaS platform, users gain visibility into system performance through log aggregation and monitoring tools. CaaS also includes built-in functionality for [auto scaling](/auto_scaling/) and orchestration management. It enables teams to build high visibility and high availability [distributed systems](/distributed_systems/). In addition, by allowing rapid deployments, CaaS increases team development velocity. While containers ensure a consistent deployment target, CaaS lowers engineering operating costs by reducing needed [DevOps](/devops/) resources needed to manage a deployment. +When deploying containerized applications to a CaaS platform, +users gain visibility into system performance through log aggregation and monitoring tools. +CaaS also includes built-in functionality for [auto scaling](/auto_scaling/) and orchestration management. +It enables teams to build high visibility and high availability [distributed systems](/distributed_systems/). +In addition, by allowing rapid deployments, CaaS increases team development velocity. +While containers ensure a consistent deployment target, +CaaS lowers engineering operating costs +by reducing needed [DevOps](/devops/) resources needed to manage a deployment. diff --git a/content/en/continuous_delivery.md b/content/en/continuous_delivery.md index 04166b8e18..1940493a51 100644 --- a/content/en/continuous_delivery.md +++ b/content/en/continuous_delivery.md @@ -6,15 +6,29 @@ category: concept ## What it is -Continuous delivery, often abbreviated as CD, is a set of practices in which code changes are automatically deployed into an acceptance environment (or, in the case of continuous deployment, into production). CD crucially includes procedures to ensure that software is adequately tested before deployment and provides a way to rollback changes if deemed necessary. Continuous integration (CI) is the first step towards continuous delivery (i.e., changes have to merge cleanly before being tested and deployed). +Continuous delivery, often abbreviated as CD, is a set of practices +in which code changes are automatically deployed into an acceptance environment +(or, in the case of continuous deployment, into production). +CD crucially includes procedures to ensure that software is adequately tested +before deployment and provides a way to rollback changes if deemed necessary. +Continuous integration (CI) is the first step towards continuous delivery +(i.e., changes have to merge cleanly before being tested and deployed). ## Problem it addresses -Deploying [reliable](/reliability/) updates becomes a problem at scale. Ideally, we'd deploy more frequently to deliver better value to end-users. However, doing it manually translates into high transaction costs for every change. Historically, to avoid these costs, organizations have released less frequently, deploying more changes at once and increasing the risk that something goes wrong. +Deploying [reliable](/reliability/) updates becomes a problem at scale. +Ideally, we'd deploy more frequently to deliver better value to end-users. +However, doing it manually translates into high transaction costs for every change. +Historically, to avoid these costs, organizations have released less frequently, +deploying more changes at once and increasing the risk that something goes wrong. ## How it helps -CD strategies create a fully automated path to production that tests and deploys the software using various deployment strategies such as [canary](/canary_deployment/) or [blue-green](/blue_green_deployment/) releases. This allows developers to deploy code frequently, giving them peace of mind that the new revision has been tested. Typically, trunk-based development is used in CD strategies as opposed to feature branching or pull requests. +CD strategies create a fully automated path to production +that tests and deploys the software using various deployment strategies +such as [canary](/canary_deployment/) or [blue-green](/blue_green_deployment/) releases. +This allows developers to deploy code frequently, giving them peace of mind that the new revision has been tested. +Typically, trunk-based development is used in CD strategies as opposed to feature branching or pull requests. ## Related terms diff --git a/content/en/continuous_deployment.md b/content/en/continuous_deployment.md index 5c392c8580..81d32c007b 100644 --- a/content/en/continuous_deployment.md +++ b/content/en/continuous_deployment.md @@ -6,15 +6,27 @@ category: concept ## What it is -Continuous deployment, often abbreviated as CD, goes a step further than [continuous delivery](/continuous_delivery/) by deploying finished software directly to production. Continuous deployment (CD) goes hand in hand with [continuous integration](/continuous_integration/) (CI), and is often referred to as CI/CD. The CI process tests if the changes to a given application are valid, and the CD process automatically deploys the code changes through an organization's environments from test to production. +Continuous deployment, often abbreviated as CD, goes a step further than [continuous delivery](/continuous_delivery/) +by deploying finished software directly to production. +Continuous deployment (CD) goes hand in hand with [continuous integration](/continuous_integration/) (CI), +and is often referred to as CI/CD. +The CI process tests if the changes to a given application are valid, +and the CD process automatically deploys the code changes through an organization's environments from test to production. ## Problem it addresses -Releasing new software versions can be a labor-intensive and error-prone process. It is also often something that organizations will only want to do infrequently to avoid production incidents and reduce the number of time engineers need to be available outside of regular business hours. Traditional software deployment models leave organizations in a vicious cycle where the process of releasing software fails to meet organizational needs around both stability and feature velocity. +Releasing new software versions can be a labor-intensive and error-prone process. +It is also often something that organizations will only want to do infrequently to avoid production incidents +and reduce the number of time engineers need to be available outside of regular business hours. +Traditional software deployment models leave organizations in a vicious cycle +where the process of releasing software fails to meet organizational needs around both stability and feature velocity. ## How it helps -By automating the release cycle and forcing organizations to release to production more frequently, CD does what CI did for development teams for operations teams. Specifically, it forces operations teams to automate the painful and error-prone portions of production deployments, reducing overall risk. It also makes organizations better at accepting and adapting to production changes, which leads to higher stability. +By automating the release cycle and forcing organizations to release to production more frequently, +CD does what CI did for development teams for operations teams. +Specifically, it forces operations teams to automate the painful and error-prone portions of production deployments, reducing overall risk. +It also makes organizations better at accepting and adapting to production changes, which leads to higher stability. ## Related terms diff --git a/content/en/continuous_integration.md b/content/en/continuous_integration.md index aafcba2513..67e8dca297 100644 --- a/content/en/continuous_integration.md +++ b/content/en/continuous_integration.md @@ -6,15 +6,25 @@ category: concept ## What it is -Continuous integration, often abbreviated as CI, is the practice of integrating code changes as regularly as possible. CI is a prerequisite for [continuous delivery](/continuous_delivery/) (CD). Traditionally, the CI process begins when code changes are committed to a source control system (Git, Mercurial, or Subversion) and ends with a tested artifact ready to be consumed by a CD system. +Continuous integration, often abbreviated as CI, is the practice of integrating code changes as regularly as possible. +CI is a prerequisite for [continuous delivery](/continuous_delivery/) (CD). +Traditionally, the CI process begins when code changes are committed to a source control system (Git, Mercurial, or Subversion) +and ends with a tested artifact ready to be consumed by a CD system. ## Problem it addresses -Software systems are often large and complex, with numerous developers maintaining and updating them. Working in parallel on different parts of the system, these developers may make conflicting changes and inadvertently break each other’s work. Additionally, with multiple developers working on the same project, any everyday tasks such as testing and calculating code quality would need to be repeated by each developer, wasting time. +Software systems are often large and complex, with numerous developers maintaining and updating them. +Working in parallel on different parts of the system, +these developers may make conflicting changes and inadvertently break each other’s work. +Additionally, with multiple developers working on the same project, +any everyday tasks such as testing and calculating code quality would need to be repeated by each developer, wasting time. ## How it helps -CI software automatically checks that code changes merge cleanly whenever a developer commits a change. It's a near-ubiquitous practice to use the CI server to run code quality checks, tests, and even deployments. As such, it becomes a concrete implementation of quality control within teams. CI allows software teams to turn every code commit into either a concrete failure or a viable release candidate. +CI software automatically checks that code changes merge cleanly whenever a developer commits a change. +It's a near-ubiquitous practice to use the CI server to run code quality checks, tests, and even deployments. +As such, it becomes a concrete implementation of quality control within teams. +CI allows software teams to turn every code commit into either a concrete failure or a viable release candidate. ## Related terms diff --git a/content/en/data_center.md b/content/en/data_center.md index 90d6d13db0..9a2a9df11e 100644 --- a/content/en/data_center.md +++ b/content/en/data_center.md @@ -6,12 +6,27 @@ category: Technology ## What it is -A data center is a specialised building or facility designed specifically to house computers, most often servers. Data centers tend to be connected to high-speed internet lines, especially in the case of data centers focused on [cloud computing](/cloud_computing/). The buildings data centers are housed in also have equipment to maintain service even in the case of negative events, such as generators to provide power during outages, as well as powerful air conditioning to deal with waste heat produced by the computers. +A data center is a specialised building or facility designed specifically to house computers, most often servers. +Data centers tend to be connected to high-speed internet lines, +especially in the case of data centers focused on [cloud computing](/cloud_computing/). +The buildings data centers are housed in also have equipment to maintain service even in the case of negative events, +such as generators to provide power during outages, +as well as powerful air conditioning to deal with waste heat produced by the computers. ## Problem it addresses -Instead of every business having to host their own server equipment where they are located, data centers allow companies and individuals to take advantage of the specialised knowledge and efficiencies of scale of data center providers. This means not having to worry about managing power supply, fire suppression technology, air conditioning or high speed internet connectivity, for example. +Instead of every business having to host their own server equipment where they are located, +data centers allow companies and individuals to take advantage of the +specialised knowledge and efficiencies of scale of data center providers. +This means not having to worry about managing power supply, fire suppression technology, +air conditioning or high speed internet connectivity, for example. ## How it helps -For cloud computing, data centers are crucial. As resources and infrastructure can be provisioned according to the [scale of demand](/scalability/), businesses can rent cloud computing resources in a data center without having to worry about forecasting – and potentially under-resourcing or overpaying – for computing resources. As data centers exist all over the world, this allows for provisioning resources geographically near to demand without having to physically ship and set up equipment. +For cloud computing, data centers are crucial. +As resources and infrastructure can be provisioned according to the [scale of demand](/scalability/), +businesses can rent cloud computing resources in a data center without having to worry about forecasting +– and potentially under-resourcing or overpaying – for computing resources. +As data centers exist all over the world, +this allows for provisioning resources geographically near to demand +without having to physically ship and set up equipment. diff --git a/content/en/database_as_a_service.md b/content/en/database_as_a_service.md index 9929626d85..fa48a60051 100644 --- a/content/en/database_as_a_service.md +++ b/content/en/database_as_a_service.md @@ -6,12 +6,24 @@ category: Technology ## What it is -Database-as-a-Service (DBaaS) is a service managed by a [cloud](/cloud_computing/) operator (public or private) that supports applications without requiring the application team to perform traditional database administration functions. DBaaS allows app developers to leverage databases without being experts or hiring a database administrator (DBA) to keep the database up to date. +Database-as-a-Service (DBaaS) is a service managed by a [cloud](/cloud_computing/) operator (public or private) +that supports applications without requiring the application team to +perform traditional database administration functions. +DBaaS allows app developers to leverage databases without being experts or +hiring a database administrator (DBA) to keep the database up to date. ## Problem it addresses -Traditionally, in on-premise setups, organizations regularly have to invest in additional storage and processing capacity to accommodate database expansion which can be expensive. Additionally, developers provision and configure databases with the help of IT infrastructure teams, slowing deployment speed of database-driven applications down. Loading and executing them also takes longer. +Traditionally, in on-premise setups, organizations regularly have to invest in +additional storage and processing capacity to accommodate database expansion which can be expensive. +Additionally, developers provision and configure databases with the help of IT infrastructure teams, +slowing deployment speed of database-driven applications down. +Loading and executing them also takes longer. ## How it helps -DBaaS allows developers to outsource all administration/administrative operations to the cloud-based service provider. The service provider ensures the database is running smoothly, including configuration management, backups, patches, upgrades, service monitoring, and more, with a user-friendly interface to manage it all. DBaaS helps organizations develop enterprise-grade applications faster while minimizing database costs. +DBaaS allows developers to outsource all administration/administrative operations to the cloud-based service provider. +The service provider ensures the database is running smoothly, +including configuration management, backups, patches, upgrades, service monitoring, and more, +with a user-friendly interface to manage it all. +DBaaS helps organizations develop enterprise-grade applications faster while minimizing database costs. diff --git a/content/en/debugging.md b/content/en/debugging.md index 896a3a32c3..86eaadcae4 100644 --- a/content/en/debugging.md +++ b/content/en/debugging.md @@ -6,12 +6,23 @@ category: concept ## What it is -Debugging is the process or activity of finding and resolving bugs (or errors) from computer programs, software, or systems to get the desired result. A bug is a defect or a problem leading to incorrect or unexpected results. +Debugging is the process or activity of finding and resolving bugs (or errors) from computer programs, software, or systems to get the desired result. +A bug is a defect or a problem leading to incorrect or unexpected results. ## Problem it addresses -Software development is a complex activity that makes it nearly impossible to write code without introducing bugs. Those bugs lead to code that will likely not function as desired (undefined behavior) when executed. Depending on how critical an application is, bugs can have a significant negative impact — financially or even on human lives. Usually, application code has to go through different stages or environments where it gets tested. The more critical an application is, the more accurate the testing has to be. +Software development is a complex activity that makes it nearly impossible to write code without introducing bugs. +Those bugs lead to code that will likely not function as desired (undefined behavior) when executed. +Depending on how critical an application is, bugs can have a significant negative impact — financially or even on human lives. +Usually, application code has to go through different stages or environments where it gets tested. +The more critical an application is, the more accurate the testing has to be. ## How it helps -When bugs appear, engineers have to debug (e.g., finding and fixing) the app to decrease undesired behavior for production systems. Debugging is no easy task as engineers have to track down the source of the undesired behavior. It requires knowledge about the code itself and the execution context at runtime. This is where different debugging techniques and tools come in handy. Analysis of logs, traces, and metrics, for instance, are used for debugging directly in production. Developers can use interactive debugging to step through the code at runtime while analyzing the related execution context. Once they have identified the source of the failure, they correct the code and create a bug fix or patch. +When bugs appear, engineers have to debug (e.g., finding and fixing) the app to decrease undesired behavior for production systems. +Debugging is no easy task as engineers have to track down the source of the undesired behavior. +It requires knowledge about the code itself and the execution context at runtime. +This is where different debugging techniques and tools come in handy. +Analysis of logs, traces, and metrics, for instance, are used for debugging directly in production. +Developers can use interactive debugging to step through the code at runtime while analyzing the related execution context. +Once they have identified the source of the failure, they correct the code and create a bug fix or patch. diff --git a/content/en/devops.md b/content/en/devops.md index 4cb5ab01eb..4c5469fd88 100644 --- a/content/en/devops.md +++ b/content/en/devops.md @@ -6,14 +6,27 @@ category: concept ## What it is -DevOps is a methodology in which teams own the entire process from application development to production operations, hence DevOps. It goes beyond implementing a set of technologies and requires a complete shift in culture and processes. DevOps calls for groups of engineers that work on small components (versus an entire feature), decreasing handoffs – a common source of errors. +DevOps is a methodology in which teams own the entire process from application development to production operations, hence DevOps. +It goes beyond implementing a set of technologies and requires a complete shift in culture and processes. +DevOps calls for groups of engineers that work on small components (versus an entire feature), decreasing handoffs – a common source of errors. ## Problem it addresses -Traditionally, in complex organizations with [tightly-coupled](/tightly_coupled_architectures/) [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. Because individuals only worked on one small piece of the project, this approach led to a lack of ownership. Their goal was to get the work to the next group, not deliver the right functionality to the customer — a clear misalignment of priorities. +Traditionally, in complex organizations with [tightly-coupled](/tightly_coupled_architectures/) [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. +Because individuals only worked on one small piece of the project, this approach led to a lack of ownership. +Their goal was to get the work to the next group, not deliver the right functionality to the customer +— a clear misalignment of priorities. -By the time code finally got into production, it went through so many developers, waiting in so many queues that it was difficult to trace the origin of the problem if the code didn’t work. DevOps turns this approach upside down. +By the time code finally got into production, it went through so many developers, +waiting in so many queues that it was difficult to trace the origin of the problem if the code didn’t work. +DevOps turns this approach upside down. ## How it helps -Having one team own the entire lifecycle of an application results in minimized handoffs, reduce risk when deploying into production, better code quality as teams are also responsible for how code performs in production and increased employee satisfaction due to more autonomy and ownership. +Having one team own the entire lifecycle of an application results in +minimized handoffs, reduce risk when deploying into production, better code quality +as teams are also responsible for how code performs in production +and increased employee satisfaction due to more autonomy and ownership. diff --git a/content/en/devsecops.md b/content/en/devsecops.md index 630b7e129c..dd9e3b65f5 100644 --- a/content/en/devsecops.md +++ b/content/en/devsecops.md @@ -6,12 +6,26 @@ category: concept ## What it is -The term DevSecOps refers to a cultural merger of the development, operational, and security responsibilities. It extends the [DevOps](/devops/) approach to include security priorities with minimal to no disruption in the developer and operational workflow. Like DevOps, DevSecOps is a cultural shift, pushed by the technologies adopted, with unique adoption methods. +The term DevSecOps refers to a cultural merger of the development, operational, and security responsibilities. +It extends the [DevOps](/devops/) approach to include security priorities +with minimal to no disruption in the developer and operational workflow. +Like DevOps, DevSecOps is a cultural shift, pushed by the technologies adopted, with unique adoption methods. ## Problem it addresses -DevOps practices include [continuous integration](/continuous_integration/) and [continuous deployment](/continuous_delivery/) and accelerate application development and release cycles. Unfortunately, automated release processes that fail to represent all organizational stakeholders adequately can exacerbate existing issues. A process that rapidly releases new software without considering security needs can degrade an organizations’ security posture. +DevOps practices include [continuous integration](/continuous_integration/) and [continuous deployment](/continuous_delivery/) +and accelerate application development and release cycles. +Unfortunately, automated release processes that fail to represent +all organizational stakeholders adequately can exacerbate existing issues. +A process that rapidly releases new software without considering security needs +can degrade an organizations’ security posture. ## How it helps -DevSecOps focuses on breaking down team silos and promotes the creation of secure, automated workflows. When selecting security applications, organizations must take advantage of automated CI/CD workflows and policy enforcement that empower the developer. The goal is not to be a blocker but to enforce security policies while giving users accurate information on how to move their project forward. When properly implemented, an organization will gain better team communication and reduce security mishaps and associated costs. +DevSecOps focuses on breaking down team silos and promotes the creation of secure, automated workflows. +When selecting security applications, organizations must take advantage of +automated CI/CD workflows and policy enforcement that empower the developer. +The goal is not to be a blocker but to enforce security policies +while giving users accurate information on how to move their project forward. +When properly implemented, an organization will gain better team communication and +reduce security mishaps and associated costs. diff --git a/content/en/distributed_apps.md b/content/en/distributed_apps.md index 4844a6af5f..be6325e0e7 100644 --- a/content/en/distributed_apps.md +++ b/content/en/distributed_apps.md @@ -6,12 +6,23 @@ category: concept ## What it is -A distributed application is an application where the functionality is broken down into multiple smaller independent parts. Distributed applications are usually composed of individual [microservices](/microservices/) that handle different concerns within the broader application. In a cloud native environment, the individual components typically run as [containers](/container/) on a [cluster](/cluster/). +A distributed application is an application where the functionality is broken down into multiple smaller independent parts. +Distributed applications are usually composed of individual [microservices](/microservices/) +that handle different concerns within the broader application. +In a cloud native environment, the individual components typically run as [containers](/container/) on a [cluster](/cluster/). ## Problem it addresses -An application running on one single computer represents a single point of failure — if that computer fails, the application becomes unavailable. Distributed applications are often contrasted to monolithic applications. A monolithic app can be harder to scale as the various components can't be scaled independently. They can also become a drag on developer velocity as they grow because more developers need to work on a shared codebase that doesn't necessarily have well defined boundaries. +An application running on one single computer represents a single point of failure — if that computer fails, the application becomes unavailable. +Distributed applications are often contrasted to monolithic applications. +A monolithic app can be harder to scale as the various components can't be scaled independently. +They can also become a drag on developer velocity as they grow +because more developers need to work on a shared codebase that doesn't necessarily have well defined boundaries. ## How it helps -When splitting an application into different pieces and running them in many places, the overall system can tolerate more failures. It also allows an application to take advantage of scaling features not available to a single application instance, namely the ability to [scale horizontally](/horizontal_scaling/). This does, however, come at a cost: increased complexity and operational overhead — you’re now running lots of application components instead of one app. +When splitting an application into different pieces and running them in many places, the overall system can tolerate more failures. +It also allows an application to take advantage of scaling features not available to a single application instance, +namely the ability to [scale horizontally](/horizontal_scaling/). +This does, however, come at a cost: increased complexity and operational overhead +— you’re now running lots of application components instead of one app. diff --git a/content/en/distributed_systems.md b/content/en/distributed_systems.md index 8d89a03e64..6ea076167b 100644 --- a/content/en/distributed_systems.md +++ b/content/en/distributed_systems.md @@ -6,16 +6,27 @@ category: concept ## What it is -A distributed system is a collection of autonomous computing elements connected over a network that appears to users as a single coherent system. Generally referred to as [nodes](/nodes/), these components can be hardware devices (e.g. computers, mobile phones) or software processes. Nodes are programmed to achieve a common goal and, to collaborate, they exchange messages over the network. +A distributed system is a collection of autonomous computing elements +connected over a network that appears to users as a single coherent system. +Generally referred to as [nodes](/nodes/), these components can be hardware devices (e.g. computers, mobile phones) or software processes. +Nodes are programmed to achieve a common goal and, to collaborate, they exchange messages over the network. ## Problem it addresses -Numerous modern applications today are so big they'd need supercomputers to operate. Think Gmail or Netflix. No single computer is powerful enough to host the entire application. By connecting multiple computers, compute power becomes nearly limitless. Without distributed computing, many applications we rely on today wouldn't be possible. +Numerous modern applications today are so big they'd need supercomputers to operate. +Think Gmail or Netflix. No single computer is powerful enough to host the entire application. +By connecting multiple computers, compute power becomes nearly limitless. +Without distributed computing, many applications we rely on today wouldn't be possible. -Traditionally, systems would [scale](/scalability/) vertically. That's when you add more CPU or memory to an individual machine. Vertical scaling is time-consuming, requires downtime, and reaches its limit quickly. +Traditionally, systems would [scale](/scalability/) vertically. +That's when you add more CPU or memory to an individual machine. +Vertical scaling is time-consuming, requires downtime, and reaches its limit quickly. ## How it helps -Distributed systems allow for [horizontal scaling](/horizontal_scaling/) (e.g. adding more nodes to the system whenever needed). This can be automated allowing a system to handle a sudden increase in workload or resource consumption. +Distributed systems allow for [horizontal scaling](/horizontal_scaling/) (e.g. adding more nodes to the system whenever needed). +This can be automated allowing a system to handle a sudden increase in workload or resource consumption. -A non-distributed system exposes itself to risks of failure because if one machine fails, the entire system fails. A distributed system can be designed in such a way that, even if some machines go down, the overall system can still keep working to produce the same result. +A non-distributed system exposes itself to risks of failure because if one machine fails, the entire system fails. +A distributed system can be designed in such a way that, +even if some machines go down, the overall system can still keep working to produce the same result. diff --git a/content/en/firewall.md b/content/en/firewall.md index 27b599d962..e63d1853f3 100644 --- a/content/en/firewall.md +++ b/content/en/firewall.md @@ -6,12 +6,20 @@ category: Technology ## What it is -A firewall is a system that filters network traffic on the basis of specified rules. Firewalls can be hardware, software, or a combination of the two. +A firewall is a system that filters network traffic on the basis of specified rules. +Firewalls can be hardware, software, or a combination of the two. ## Problem it addresses -By default, a network will allow anyone to enter and depart as long as they follow the network's routing rules. Because of this default behavior, securing a network is challenging. For example, in a microservices-based banking app, the services communicate with one another by transmitting highly sensitive financial data through their network. A malicious actor may infiltrate the network, intercept communication, and do damage if there was no firewall in place. +By default, a network will allow anyone to enter and depart as long as they follow the network's routing rules. +Because of this default behavior, securing a network is challenging. +For example, in a microservices-based banking app, the services communicate with one another +by transmitting highly sensitive financial data through their network. +A malicious actor may infiltrate the network, intercept communication, and do damage if there was no firewall in place. ## How it helps -A firewall examines network traffic using pre-defined rules. All traffic is filtered, and any traffic coming from untrustworthy or suspect sources is blocked — only traffic configured to be accepted gets in. Firewalls establish a barrier between secured and controlled internal trusted networks. +A firewall examines network traffic using pre-defined rules. +All traffic is filtered, and any traffic coming from untrustworthy or suspect sources is blocked +— only traffic configured to be accepted gets in. +Firewalls establish a barrier between secured and controlled internal trusted networks. diff --git a/content/en/function_as_a_service.md b/content/en/function_as_a_service.md index aee30534e5..ccb2422f98 100644 --- a/content/en/function_as_a_service.md +++ b/content/en/function_as_a_service.md @@ -6,12 +6,32 @@ category: Technology ## What it is -Function as a Service (FaaS) is a type of [serverless](/serverless/) [cloud computing](/cloud_computing/) [service](/service/) that allows executing code in response to events without maintaining the complex infrastructure typically associated with building and launching [microservices](/microservices/) applications. With FaaS, users manage only functions and data while the cloud provider manages the application. This allows developers to get the functions they need without paying for services when code isn’t running. Some popular FaaS examples include: [Amazon's AWS Lambda](https://aws.amazon.com/lambda/), [Google Cloud Functions](https://cloud.google.com/functions/) and [Microsoft Azure Functions](https://azure.microsoft.com/en-us/services/functions/). +Function as a Service (FaaS) is a type of [serverless](/serverless/) [cloud computing](/cloud_computing/) [service](/service/) +that allows executing code in response to events +without maintaining the complex infrastructure +typically associated with building and launching [microservices](/microservices/) applications. +With FaaS, users manage only functions and data while the cloud provider manages the application. +This allows developers to get the functions they need without paying for services when code isn’t running. +Some popular FaaS examples include: [Amazon's AWS Lambda](https://aws.amazon.com/lambda/), +[Google Cloud Functions](https://cloud.google.com/functions/) and [Microsoft Azure Functions](https://azure.microsoft.com/en-us/services/functions/). ## Problem it addresses -In a traditional on-premises scenario, a business manages and maintains its own data center. The business must invest in servers, storage, software, and other technologies and potentially hire an IT staff or contractors to purchase, manage, and upgrade all the equipment and licenses. The data center has to be built to meet peak demand, even when workloads decline and those resources stand idle. Conversely, if the business grows quickly, the IT department might struggle to keep up. Under a standard [Infrastructure-as-a-Service (IaaS)](/infrastructure_as_a_service/) cloud computing model, users pre-purchase capacity units, meaning you pay a public cloud provider for always-on server components to run your apps. It’s the user’s responsibility to scale up server capacity during times of high demand and scale down when that capacity is no longer needed. The cloud infrastructure necessary to run an app is active even when the app isn’t being used. +In a traditional on-premises scenario, a business manages and maintains its own data center. +The business must invest in servers, storage, software, and other technologies +and potentially hire an IT staff or contractors to purchase, manage, and upgrade all the equipment and licenses. +The data center has to be built to meet peak demand, even when workloads decline and those resources stand idle. +Conversely, if the business grows quickly, the IT department might struggle to keep up. +Under a standard [Infrastructure-as-a-Service (IaaS)](/infrastructure_as_a_service/) cloud computing model, +users pre-purchase capacity units, meaning you pay a public cloud provider for always-on server components to run your apps. +It’s the user’s responsibility to scale up server capacity during times of high demand +and scale down when that capacity is no longer needed. +The cloud infrastructure necessary to run an app is active even when the app isn’t being used. ## How it helps -FaaS gives developers an [abstraction](/abstraction/) for running web applications in response to events without managing servers. For example, uploading a file could trigger custom code that transcodes the file into various formats. FaaS infrastructure will auto-scale the code for heavy use, and the developer does not have to spend any time or resources building the code for [scalability](//scalability/). Billing is based on computation time alone, which means businesses do not have to pay when the functions are not in use. +FaaS gives developers an [abstraction](/abstraction/) for running web applications in response to events without managing servers. +For example, uploading a file could trigger custom code that transcodes the file into various formats. +FaaS infrastructure will auto-scale the code for heavy use, +and the developer does not have to spend any time or resources building the code for [scalability](/scalability/). +Billing is based on computation time alone, which means businesses do not have to pay when the functions are not in use. diff --git a/content/en/gitops.md b/content/en/gitops.md index b0b8dc2b6b..671ff0ddf9 100644 --- a/content/en/gitops.md +++ b/content/en/gitops.md @@ -6,15 +6,25 @@ category: Concept ## What it is -GitOps is a set of best practices based on [shared principles](https://opengitops.dev/), applied to a workflow that depends on software agents that enable automation to reconcile a declared system state or configuration in a git repository. -These software agents and practices are used to execute a cohesive workflow that leverages a source control system like Git as the “single source of truth” and extends this practice to applications, infrastructure, and operational procedures. +GitOps is a set of best practices based on [shared principles](https://opengitops.dev/), +applied to a workflow that depends on software agents that +enable automation to reconcile a declared system state or configuration in a git repository. +These software agents and practices are used to execute a cohesive workflow that +leverages a source control system like Git as the “single source of truth” and +extends this practice to applications, infrastructure, and operational procedures. ## Problem it addresses -Existing processes for infrastructure configuration management can face challenges such as configuration drift, failed deployments, relying on a system's previous state for success, missing documentation, or unknown development history. +Existing processes for infrastructure configuration management can face challenges +such as configuration drift, failed deployments, relying on a system's previous state for success, +missing documentation, or unknown development history. Adopting a GitOps workflow can help alleviate these issues, among several others. ## How it helps -GitOps is a paradigm that can be applied to a workflow to help manage an application and cloud system infrastructure. It enables organizations several advantages such as better coordination, transparency, stability, and reliability of a system. -Operating in a close loop ensures the current live state of a system matches against the desired target state, specified in the git repository. +GitOps is a paradigm that can be applied to a workflow +to help manage an application and cloud system infrastructure. +It enables organizations several advantages +such as better coordination, transparency, stability, and reliability of a system. +Operating in a close loop ensures the current live state of a system matches +against the desired target state, specified in the git repository. diff --git a/content/en/horizontal_scaling.md b/content/en/horizontal_scaling.md index 461a390799..d5c8c6cc5a 100644 --- a/content/en/horizontal_scaling.md +++ b/content/en/horizontal_scaling.md @@ -6,17 +6,31 @@ category: Concept ## What it is -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. +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. -This approach enhances the performance of an application by adding new instances, or [nodes](/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. +This approach enhances the performance of an application by adding new instances, or [nodes](/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. ## Problem it addresses -As demand for an application grows beyond the current capacity of that application instance, we need to find a way to [scale](/scalability/) (add capacity to) the system. We can either add more nodes to the system (horizontal scaling) or more compute resources to existing nodes (vertical scaling). +As demand for an application grows beyond the current capacity of that application instance, +we need to find a way to [scale](/scalability/) (add capacity to) the system. +We can either add more nodes to the system (horizontal scaling) +or more compute resources to existing nodes (vertical scaling). ## How it helps -Horizontal scaling allows applications to scale to whatever limits the underlying cluster provides. By adding more instances to the system, the app can process a greater number of requests. If a single node can handle 1,000 requests per second, each additional node should increase the total number of requests by around 1,000 requests per second. This allows the application to do more work concurrently without needing to increase the capacity of any node in particular. +Horizontal scaling allows applications to scale to whatever limits the underlying cluster provides. +By adding more instances to the system, the app can process a greater number of requests. +If a single node can handle 1,000 requests per second, +each additional node should increase the total number of requests by around 1,000 requests per second. +This allows the application to do more work concurrently +without needing to increase the capacity of any node in particular. ## Related terms diff --git a/content/en/idempotence.md b/content/en/idempotence.md index 5f7fee154b..b59744472e 100644 --- a/content/en/idempotence.md +++ b/content/en/idempotence.md @@ -4,4 +4,6 @@ status: Completed category: Property --- -In maths or computer science, idempotence describes an operation that always leads to the same outcome, no matter how many times you execute it. If the parameters are the same, an idempotent operation won't affect the application it calls. +In maths or computer science, idempotence describes an operation that always leads to the same outcome, +no matter how many times you execute it. +If the parameters are the same, an idempotent operation won't affect the application it calls. diff --git a/content/en/immutable_infrastructure.md b/content/en/immutable_infrastructure.md index 14ba9285a8..5e91d6840e 100644 --- a/content/en/immutable_infrastructure.md +++ b/content/en/immutable_infrastructure.md @@ -4,6 +4,21 @@ status: Completed category: property --- -Immutable Infrastructure refers to computer infrastructure ([virtual machines](/virtual_machine/), [containers](/container/), network appliances) that cannot be changed once deployed. This can be enforced by an automated process that overwrites unauthorized changes or through a system that won't allow changes in the first place. Containers are a good example of immutable infrastructure because persistent changes to containers can only be made by creating a new version of the container or recreating the existing container from its image. +Immutable Infrastructure refers to computer infrastructure +([virtual machines](/virtual_machine/), [containers](/container/), network appliances) +that cannot be changed once deployed. +This can be enforced by an automated process that overwrites unauthorized changes or +through a system that won't allow changes in the first place. +Containers are a good example of immutable infrastructure +because persistent changes to containers can only be made by +creating a new version of the container or recreating the existing container from its image. -By preventing or identifying unauthorized changes, immutable infrastructures make it easier to identify and mitigate security risks. Operating such a system becomes a lot more straightforward because administrators can make assumptions about it. After all, they know no one made mistakes or changes they forgot to communicate. Immutable infrastructure goes hand-in-hand with [infrastructure as code](/infrastructure_as_code/) where all automation needed to create infrastructure is stored in version control (e.g. Git). This combination of immutability and version control means that there is a durable audit log of every authorized change to a system. +By preventing or identifying unauthorized changes, +immutable infrastructures make it easier to identify and mitigate security risks. +Operating such a system becomes a lot more straightforward +because administrators can make assumptions about it. +After all, they know no one made mistakes or changes they forgot to communicate. +Immutable infrastructure goes hand-in-hand with [infrastructure as code](/infrastructure_as_code/) +where all automation needed to create infrastructure is stored in version control (e.g. Git). +This combination of immutability and version control means that +there is a durable audit log of every authorized change to a system. diff --git a/content/en/infrastructure_as_a_service.md b/content/en/infrastructure_as_a_service.md index ec0937cf37..3093ca6b5e 100644 --- a/content/en/infrastructure_as_a_service.md +++ b/content/en/infrastructure_as_a_service.md @@ -6,14 +6,29 @@ category: Technology ## What it is -Infrastructure as a service, or IaaS, is a [cloud computing](/cloud_computing/) service model that offers [physical](/bare_metal_machine/) or [virtualized](/virtualization/) compute, storage, and network resources on-demand on a pay-as-you-go model. Cloud providers own and operate the hardware and software, available to consumers in public, private, or hybrid cloud deployments. +Infrastructure as a service, or IaaS, is a [cloud computing](/cloud_computing/) service model that +offers [physical](/bare_metal_machine/) or [virtualized](/virtualization/) +compute, storage, and network resources on-demand on a pay-as-you-go model. +Cloud providers own and operate the hardware and software, +available to consumers in public, private, or hybrid cloud deployments. ## Problem it addresses -In traditional on-premise setups, organizations often struggle with effective computing resource usage. Data centers have to be built for potential peak demand, even if it's only needed 1% of the time. During lower demand, these compute resources are idle. And, if the workload spikes beyond the expected demand, there is a shortage of computing resources to process the workload. This lack of scalability leads to increased costs and ineffective resource usage. +In traditional on-premise setups, organizations often struggle with effective computing resource usage. +Data centers have to be built for potential peak demand, even if it's only needed 1% of the time. +During lower demand, these compute resources are idle. +And, if the workload spikes beyond the expected demand, +there is a shortage of computing resources to process the workload. +This lack of scalability leads to increased costs and ineffective resource usage. ## How it helps -With IaaS organizations can avoid purchasing and maintaining compute and data center space for their applications. An on-demand infrastructure allows them to rent compute resources as needed and defer large capital expenditures, or [CAPEX](https://en.wikipedia.org/wiki/Capital_expenditure), while giving them the flexibility to scale up or down. +With IaaS organizations can avoid purchasing and maintaining compute and data center space for their applications. +An on-demand infrastructure allows them to rent compute resources as needed and +defer large capital expenditures, or [CAPEX](https://en.wikipedia.org/wiki/Capital_expenditure), +while giving them the flexibility to scale up or down. -IaaS reduces the upfront costs of experimenting or trying a new application and provides facilities to rapidly deploy infrastructure. A cloud provider is an excellent option for development or test environments, which helps developers experiment and innovate. +IaaS reduces the upfront costs of experimenting or trying a new application and +provides facilities to rapidly deploy infrastructure. +A cloud provider is an excellent option for development or test environments, +which helps developers experiment and innovate. diff --git a/content/en/infrastructure_as_code.md b/content/en/infrastructure_as_code.md index 86b156b24e..e67526c493 100644 --- a/content/en/infrastructure_as_code.md +++ b/content/en/infrastructure_as_code.md @@ -6,12 +6,20 @@ category: concept ## What it is -Infrastructure as code is the practice of storing the definition of infrastructure as one or more files. This replaces the traditional model where infrastructure as a service is provisioned manually, usually through shell scripts or other configuration tools. +Infrastructure as code is the practice of storing the definition of infrastructure as one or more files. +This replaces the traditional model where infrastructure as a service is provisioned manually, +usually through shell scripts or other configuration tools. ## Problem it addresses -Building applications in a cloud native way requires infrastructure to be disposable and reproducible. It also needs to [scale](/scalability/) on-demand in an automated and repeatable way, potentially without human intervention. Manual provisioning cannot meet the responsiveness and scale requirements of [cloud native applications](/cloud_native_apps/). Manual infrastructure changes are not reproducible, quickly run into scale limits, and introduces misconfiguration errors. +Building applications in a cloud native way requires infrastructure to be disposable and reproducible. +It also needs to [scale](/scalability/) on-demand in an automated and repeatable way, potentially without human intervention. +Manual provisioning cannot meet the responsiveness and scale requirements of [cloud native applications](/cloud_native_apps/). +Manual infrastructure changes are not reproducible, quickly run into scale limits, and introduces misconfiguration errors. ## How it helps -By representing the data center resources such as servers, load balancers, and subnets as code, it allows infrastructure teams to have a single source of truth for all configurations and also allows them to manage their data center in a [CI](/continuous_integration/)/[CD](/continuous_delivery/) pipeline, implementing version control and deployment strategies. +By representing the data center resources such as servers, load balancers, and subnets as code, +it allows infrastructure teams to have a single source of truth for all configurations and +also allows them to manage their data center in a [CI](/continuous_integration/)/[CD](/continuous_delivery/) pipeline, +implementing version control and deployment strategies. diff --git a/content/en/kubernetes.md b/content/en/kubernetes.md index 602e378c06..5e39f43487 100644 --- a/content/en/kubernetes.md +++ b/content/en/kubernetes.md @@ -6,19 +6,49 @@ category: technology ## What it is -Kubernetes, often abbreviated as K8s, is an open source container orchestrator that automates the life-cycle of [containerized](/container/) applications on modern infrastructures. It's like a data center operating system that manages applications running across a [distributed system](/distributed_systems/) (just like the OS on your laptop that manages your apps). - -Kubernetes schedules containers across [nodes](/nodes/) in a [cluster](/cluster/). It bundles several infrastructure constructs, sometimes referred to as “primitives,” like an instance of an app, load balancers, persistent storage, and others together in a way that they can be composed into applications. - -Kubernetes enables automation and extensibility, allowing users to deploy applications declaratively in a reproducible way. Software products and projects in the Kubernetes ecosystem take advantage of that automation and extensibility to extend the Kubernetes [API](/application_programming_interface/). This enables them to leverage Kubernetes’ automation and make their tools more accessible to experienced Kubernetes practitioners. +Kubernetes, often abbreviated as K8s, is an open source container orchestrator that +automates the life-cycle of [containerized](/container/) applications on modern infrastructures. +It's like a data center operating system that manages applications +running across a [distributed system](/distributed_systems/) +(just like the OS on your laptop that manages your apps). + +Kubernetes schedules containers across [nodes](/nodes/) in a [cluster](/cluster/). +It bundles several infrastructure constructs, sometimes referred to as “primitives,” +like an instance of an app, load balancers, persistent storage, and others together +in a way that they can be composed into applications. + +Kubernetes enables automation and extensibility, +allowing users to deploy applications declaratively in a reproducible way. +Software products and projects in the Kubernetes ecosystem take advantage of that automation and extensibility +to extend the Kubernetes [API](/application_programming_interface/). +This enables them to leverage Kubernetes’ automation and +make their tools more accessible to experienced Kubernetes practitioners. ## Problem it addresses -Infrastructure automation and declarative configuration management have been important concepts for a long time and have only become more pressing as [cloud computing](/cloud_computing/) has gained popularity. As demand for compute resources increases and organizations feel pressured to provide more operational capabilities with fewer engineers, new technologies and working methods are required to meet that demand. Additionally, the rise of cloud computing was paired with [containerization](/containerization/) and organizations that were busy automating more traditional infrastructure needed a mechanism to automate the configuration and deployment of their containers. +Infrastructure automation and declarative configuration management have been important concepts for a long time and +have only become more pressing as [cloud computing](/cloud_computing/) has gained popularity. +As demand for compute resources increases and +organizations feel pressured to provide more operational capabilities with fewer engineers, +new technologies and working methods are required to meet that demand. +Additionally, the rise of cloud computing was paired with [containerization](/containerization/) and +organizations that were busy automating more traditional infrastructure needed a mechanism to +automate the configuration and deployment of their containers. ## How it helps -Kubernetes helps with automation in a manner similar to traditional infrastructure as code tools but has the advantage of working with containers that are more resistant to configuration drift than virtual or physical machines. -Kubernetes works declaratively, which means that instead of operators providing the instructions about how to do something they instead describe, usually as manifest files (e.g. YAML), what they want to be done; Kubernetes will take care of the "how" on its own. This results in Kubernetes being extremely compatible with infrastructure as code. - -Kubernetes also self-heals. This means that it ensures the cluster’s actual state always matches the operator’s desired state. If Kubernetes detects a deviation, a Kubernetes controller kicks in and fixes it. So while the infrastructure it uses may be continually changing Kubernetes itself is continually, and automatically adapting to changes and ensuring that it matches with the desired state. +Kubernetes helps with automation in a manner similar to traditional infrastructure as code tools +but has the advantage of working with containers +that are more resistant to configuration drift than virtual or physical machines. +Kubernetes works declaratively, which means that +instead of operators providing the instructions about how to do something +they instead describe, usually as manifest files (e.g. YAML), what they want to be done; +Kubernetes will take care of the "how" on its own. +This results in Kubernetes being extremely compatible with infrastructure as code. + +Kubernetes also self-heals. +This means that it ensures the cluster’s actual state always matches the operator’s desired state. +If Kubernetes detects a deviation, a Kubernetes controller kicks in and fixes it. +So while the infrastructure it uses may be continually changing +Kubernetes itself is continually, and automatically adapting to changes and +ensuring that it matches with the desired state. diff --git a/content/en/load_balancer.md b/content/en/load_balancer.md index 4b2ad39106..d23c0c238d 100644 --- a/content/en/load_balancer.md +++ b/content/en/load_balancer.md @@ -6,12 +6,17 @@ category: concept ## What it is -A load balancer is a method to distribute incoming network traffic across a group of servers in the back-end. The solution can be software or hardware based. +A load balancer is a method to distribute incoming network traffic across a group of servers in the back-end. +The solution can be software or hardware based. ## Problem it addresses -This helps solve the issue related to high availability and distributed systems. When working on an application or service that needs to scale to hundreds of thousands of users, one will often need to distribute that application on multiple servers. The load balancer is the "traffic cop" that routes traffic. +This helps solve the issue related to high availability and distributed systems. +When working on an application or service that needs to scale to hundreds of thousands of users, +one will often need to distribute that application on multiple servers. +The load balancer is the "traffic cop" that routes traffic. ## How it helps -A load balancer will act as front-end for network traffic and clients. It often has various methods to check which server(s) is up and has the lowest load to handle the request. +A load balancer will act as front-end for network traffic and clients. +It often has various methods to check which server(s) is up and has the lowest load to handle the request. diff --git a/content/en/loosely_coupled_architecture.md b/content/en/loosely_coupled_architecture.md index 740f366ea6..5d3b0244fd 100644 --- a/content/en/loosely_coupled_architecture.md +++ b/content/en/loosely_coupled_architecture.md @@ -4,6 +4,15 @@ status: Completed category: 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/), 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 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/), 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/mTLS (Mutual Transport Layer Security).md b/content/en/mTLS (Mutual Transport Layer Security).md index 5db1a9d550..5a21b877f3 100644 --- a/content/en/mTLS (Mutual Transport Layer Security).md +++ b/content/en/mTLS (Mutual Transport Layer Security).md @@ -6,12 +6,19 @@ category: Concept ## What it is -Mutual TLS (mTLS) is a technique used to authenticate and encrypt messages sent between two [services](/service/). Mutual TLS is the standard [Transport Layer Security](/tlstransport-layer-security/) (TLS) protocol but, instead of validating the identity of just one connection, both sides are validated. +Mutual TLS (mTLS) is a technique used to authenticate and encrypt messages sent between two [services](/service/). +Mutual TLS is the standard [Transport Layer Security](/tlstransport-layer-security/) (TLS) protocol but, +instead of validating the identity of just one connection, both sides are validated. ## Problem it addresses -[Microservices](/microservices/) communicate over a network and, just like your wifi network, communication in transit over that network can be hacked. mTLS ensures that no unauthorized party can listen in on or impersonate legitimate requests. +[Microservices](/microservices/) communicate over a network and, +just like your wifi network, communication in transit over that network can be hacked. +mTLS ensures that no unauthorized party can listen in on or impersonate legitimate requests. ## How it helps -mTLS ensures that traffic is secure and trusted in both directions between a client and server, providing an additional layer of security for users who log in to a network or applications. It also verifies connections with client devices that do not follow a login process, such as Internet of Things (IoT) devices. Attacks like on-path attacks, spoofing attacks, credential stuffing, brute force attacks, etc. can be prevented by mTLS. +mTLS ensures that traffic is secure and trusted in both directions between a client and server, +providing an additional layer of security for users who log in to a network or applications. +It also verifies connections with client devices that do not follow a login process, such as Internet of Things (IoT) devices. +Attacks like on-path attacks, spoofing attacks, credential stuffing, brute force attacks, etc. can be prevented by mTLS. diff --git a/content/en/managed_services.md b/content/en/managed_services.md index db4ae83cc6..66fc9f154e 100644 --- a/content/en/managed_services.md +++ b/content/en/managed_services.md @@ -6,12 +6,17 @@ category: Technology ## What it is -A managed service is a software offering where operations and management are taken care of by a third party. Examples include database as a service offerings like Amazon’s RDS or an external monitoring service like Datadog. +A managed service is a software offering where operations and management are taken care of by a third party. +Examples include database as a service offerings like Amazon’s RDS or an external monitoring service like Datadog. ## Problem it addresses -Managing software is complex, especially considering all the different technologies that make up a modern stack. Managing each aspect of it and/or having in-house experts able to do so may be too expensive or not worth your engineers' time. Your team is likely better off building new capabilities than taking care of the operational tasks that can be easily outsourced. +Managing software is complex, especially considering all the different technologies that make up a modern stack. +Managing each aspect of it and/or having in-house experts able to do so may be too expensive or not worth your engineers' time. +Your team is likely better off building new capabilities than taking care of the operational tasks that can be easily outsourced. ## How it helps -Managed services are ready to use from day one with very little operational overhead. They allow organizations to effectively outsource tasks that fall outside of their core competency with well defined, and usually [API](/application_programming_interface/) driven, boundaries. +Managed services are ready to use from day one with very little operational overhead. +They allow organizations to effectively outsource tasks that fall outside of their core competency +with well defined, and usually [API](/application_programming_interface/) driven, boundaries. diff --git a/content/en/microservices.md b/content/en/microservices.md index e30953f7c0..0d0c060b50 100644 --- a/content/en/microservices.md +++ b/content/en/microservices.md @@ -6,14 +6,34 @@ category: concept ## What it is -Microservices are a modern approach to application development that takes advantage of cloud native technologies. While modern applications, like Netflix, appear to be a single app, they are actually a collection of smaller services – all closely working together. For instance, a single page that allows you to access, search, and preview videos is likely powered by smaller services that each handle one aspect of it (e.g. search, authentication, and running previews in your browser). In short, microservices refer to an application architecture pattern usually contrasted with [monolithic applications](/monolithic_apps/). +Microservices are a modern approach to application development that takes advantage of cloud native technologies. +While modern applications, like Netflix, appear to be a single app, +they are actually a collection of smaller services – all closely working together. +For instance, a single page that allows you to access, search, and preview videos is likely +powered by smaller services that each handle one aspect of it +(e.g. search, authentication, and running previews in your browser). +In short, microservices refer to an application architecture pattern +usually contrasted with [monolithic applications](/monolithic_apps/). ## Problem it addresses -Microservices are a response to challenges posed by monolithic applications. Generally, different parts of an application will need to be [scaled](/scalability/) separately. An online store, for example, is going to have more product views than checkouts. That means you'll need more copies of the product view functionality running than the checkout. In a monolithic application, those bits of logic can't be deployed separately. If you can't scale the product functionality individually, you'll have to duplicate the entire app with all other components you don't need – an inefficient use of resources. -Monolithic applications 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 often require developers to understand the entire codebase before they can be productive. +Microservices are a response to challenges posed by monolithic applications. +Generally, different parts of an application will need to be [scaled](/scalability/) separately. +An online store, for example, is going to have more product views than checkouts. +That means you'll need more copies of the product view functionality running than the checkout. +In a monolithic application, those bits of logic can't be deployed separately. +If you can't scale the product functionality individually, +you'll have to duplicate the entire app with all other components you don't need – an inefficient use of resources. +Monolithic applications 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 often require developers to understand the entire codebase before they can be productive. ## How it helps -Separating functionality into different microservices makes them easier to deploy, update, and scale independently. By allowing different teams to focus on their own small part of a bigger application you also make it easier for them to work on their apps without negatively impacting the rest of the organization. -While microservices solve many problems, they also create operational overhead—the things you need to deploy and keep track of increase by order of magnitude or more. Many [cloud-native technologies](/cloud_native_tech/) aim to make microservices easier to deploy and manage. +Separating functionality into different microservices makes them easier to deploy, update, and scale independently. +By allowing different teams to focus on their own small part of a bigger application +you also make it easier for them to work on their apps without negatively impacting the rest of the organization. +While microservices solve many problems, they also create operational overhead +— the things you need to deploy and keep track of increase by order of magnitude or more. +Many [cloud-native technologies](/cloud_native_tech/) aim to make microservices easier to deploy and manage. diff --git a/content/en/monolithic_apps.md b/content/en/monolithic_apps.md index 4200b085a7..8279d481c8 100644 --- a/content/en/monolithic_apps.md +++ b/content/en/monolithic_apps.md @@ -6,12 +6,22 @@ category: concept ## What it is -A monolithic application contains all functionality in a single deployable program. This is often the simplest and easiest place to start when making an application. However, once the application grows in complexity, monoliths can become hard to maintain. With more developers working on the same codebase, the likelihood of conflicting changes and the need for interpersonal communication between developers increases. +A monolithic application contains all functionality in a single deployable program. +This is often the simplest and easiest place to start when making an application. +However, once the application grows in complexity, monoliths can become hard to maintain. +With more developers working on the same codebase, +the likelihood of conflicting changes and the need for interpersonal communication between developers increases. ## Problem it Addresses -Devolving an application into [microservices](/microservices/) increases its operational overhead — there are more things to test, deploy, and keep running. Early in a product’s lifecycle, it may be advantageous to defer this complexity and build a monolithic application until the product is determined successful. +Devolving an application into [microservices](/microservices/) increases its operational overhead +— there are more things to test, deploy, and keep running. +Early in a product’s lifecycle, it may be advantageous to defer this complexity and build a monolithic application +until the product is determined successful. ## How it Helps -A well-designed monolith can uphold lean principles by being the simplest way to get an application up and running. When the business value of the monolithic application proves successful, it can be decomposed into microservices. Crafting a microservices-based app before it has proven valuable may be premature spending of engineering effort. If the application yields no value, that effort becomes wasted. +A well-designed monolith can uphold lean principles by being the simplest way to get an application up and running. +When the business value of the monolithic application proves successful, it can be decomposed into microservices. +Crafting a microservices-based app before it has proven valuable may be premature spending of engineering effort. +If the application yields no value, that effort becomes wasted. diff --git a/content/en/nodes.md b/content/en/nodes.md index 2e6f7abfe0..1062cbe6c3 100644 --- a/content/en/nodes.md +++ b/content/en/nodes.md @@ -6,12 +6,22 @@ category: Concept ## What it is -A node is a computer that works in concert with other computers, or nodes, to accomplish a common task. Take your laptop, modem, and printer, for example. They are all connected over your wifi network communicating and collaborating, each representing one node. In [cloud computing](/cloud_computing/), a node can be a physical computer, a virtual computer, referred to as a VM, or even a [container](/container/). +A node is a computer that works in concert with other computers, or nodes, to accomplish a common task. +Take your laptop, modem, and printer, for example. +They are all connected over your wifi network communicating and collaborating, each representing one node. +In [cloud computing](/cloud_computing/), a node can be a physical computer, +a virtual computer, referred to as a VM, or even a [container](/container/). ## Problem it addresses -While an application could (and many do) run on one single machine, there are some risks involved with that. Namely that the failure of the underlying system will disrupt the application. To address this, developers started creating [distributed applications](/distributed_apps/) where each process runs on its own node. Thus, nodes run apps or processes as part of a group forming a [cluster](/cluster/), or group, of nodes that works together to achieve a common goal. +While an application could (and many do) run on one single machine, there are some risks involved with that. +Namely that the failure of the underlying system will disrupt the application. +To address this, developers started creating [distributed applications](/distributed_apps/) where each process runs on its own node. +Thus, nodes run apps or processes as part of a group forming a [cluster](/cluster/), or group, of nodes that works together to achieve a common goal. ## How it helps -A node gives you a distinct unit of compute (memory, CPU, network) that you can assign to a cluster. In a cloud native platform or app a node represents a single unit that can perform work. Ideally, individual nodes are undifferentiated in that any one node of a particular type is indistinguishable from any other node of the same type. +A node gives you a distinct unit of compute (memory, CPU, network) that you can assign to a cluster. +In a cloud native platform or app a node represents a single unit that can perform work. +Ideally, individual nodes are undifferentiated in that +any one node of a particular type is indistinguishable from any other node of the same type. diff --git a/content/en/observability.md b/content/en/observability.md index 978049518c..a044923f68 100644 --- a/content/en/observability.md +++ b/content/en/observability.md @@ -4,6 +4,15 @@ status: Completed category: property --- -Observability is a characteristic of an application that refers to how well a system's state or status can be understood from its external outputs. Computer systems are measured by observing CPU time, memory, disk space, latency, errors, etc. The more observable a system is, the easier it is to understand how it’s doing by looking at it. +Observability is a characteristic of an application that refers to +how well a system's state or status can be understood from its external outputs. +Computer systems are measured by observing CPU time, memory, disk space, latency, errors, etc. +The more observable a system is, the easier it is to understand how it’s doing by looking at it. -The observability of a system has a significant impact on its operating cost. Observable systems yield meaningful, actionable data to their operators, allowing them to achieve favorable outcomes and less downtime. Note that more information does not necessarily translate into a more observable system. In fact, sometimes the amount of information generated by a system can make it harder to identify valuable health signals from the noise generated by the application. Observability requires the right data to make the right decisions. +The observability of a system has a significant impact on its operating cost. +Observable systems yield meaningful, actionable data to their operators, +allowing them to achieve favorable outcomes and less downtime. +Note that more information does not necessarily translate into a more observable system. +In fact, sometimes the amount of information generated by a system can make it harder to +identify valuable health signals from the noise generated by the application. +Observability requires the right data to make the right decisions. diff --git a/content/en/platform_as_a_service.md b/content/en/platform_as_a_service.md index f9450f2278..1cd7b2e1d2 100644 --- a/content/en/platform_as_a_service.md +++ b/content/en/platform_as_a_service.md @@ -6,12 +6,18 @@ category: Technology ## What it is -A Platform as a Service, or PaaS, is an external platform for application development teams to deploy and run their apps. Heroku, Cloud Foundry, App Engine are examples of PaaS offerings. +A Platform as a Service, or PaaS, is an external platform for application development teams to deploy and run their apps. +Heroku, Cloud Foundry, App Engine are examples of PaaS offerings. ## Problem it addresses -To take advantage of cloud native patterns like [microservices](/microservices/) or [distributed applications](/distributed_apps/), operations teams and developers need to be able to offload a significant amount of operations and maintenance work. These include tasks like provisioning infrastructure, handling [service discovery](/service_discovery/) and load balancing, and [scaling](/scalability/) applications. +To take advantage of cloud native patterns like [microservices](/microservices/) or [distributed applications](/distributed_apps/), +operations teams and developers need to be able to offload a significant amount of operations and maintenance work. +These include tasks like provisioning infrastructure, +handling [service discovery](/service_discovery/) and load balancing, and [scaling](/scalability/) applications. ## How it helps -A PaaS provides common infrastructure tools to application developers in a fully automated fashion. It allows developers to understand and worry less about infrastructure and devote more time and effort to writing application code. It also provides some monitoring and [observability](/observability/) to help application teams ensure their apps are healthy. +A PaaS provides common infrastructure tools to application developers in a fully automated fashion. +It allows developers to understand and worry less about infrastructure and devote more time and effort to writing application code. +It also provides some monitoring and [observability](/observability/) to help application teams ensure their apps are healthy. diff --git a/content/en/policy_as_code.md b/content/en/policy_as_code.md index 0fa1327f4e..967df341e5 100644 --- a/content/en/policy_as_code.md +++ b/content/en/policy_as_code.md @@ -6,12 +6,20 @@ category: concept ## What it is -Policy as Code is the practice of storing the definition of policies as one or more files in machine readable and processable form. This replaces the traditional model where policies are documented in human-readable form, in separate documents. +Policy as Code is the practice of storing the definition of policies as one or more files in machine readable and processable form. +This replaces the traditional model where policies are documented in human-readable form, in separate documents. ## Problem it addresses -Building applications and infrastructures is often constrained by a lot of policies, that are defined by an organization, e.g. security policies that forbid to store secrets in source code, to run a container with superuser permissions, or to store some data outside a specific geo region. It is very labor-intensive and error-prone for developers and reviewers to manually check applications and infrastructure against documented policies. Manual checking against policies cannot meet the responsiveness and scale requirements of cloud native applications. +Building applications and infrastructures is often constrained by a lot of policies, that are defined by an organization, +e.g. security policies that forbid to store secrets in source code, +to run a container with superuser permissions, or to store some data outside a specific geo region. +It is very labor-intensive and error-prone for developers and reviewers to +manually check applications and infrastructure against documented policies. +Manual checking against policies cannot meet the responsiveness and scale requirements of cloud native applications. ## How it helps -By using Policy as Code it is possible to automate the checking of system properties and actions. Best practices of software development can be applied to Policy as Code authoring, e.g. by using Git and associated workflows. +By using Policy as Code it is possible to automate the checking of system properties and actions. +Best practices of software development can be applied to Policy as Code authoring, +e.g. by using Git and associated workflows. diff --git a/content/en/portability.md b/content/en/portability.md index 0433344f67..140d0ea837 100644 --- a/content/en/portability.md +++ b/content/en/portability.md @@ -4,6 +4,10 @@ status: Completed category: Property --- -A software characteristic, portability is a form of reusability that helps to avoid "lock-in" to certain operating environments, e.g. cloud providers, operating systems or vendors. +A software characteristic, portability is a form of reusability that helps to avoid "lock-in" to certain operating environments, +e.g. cloud providers, operating systems or vendors. -Traditionally, software is often built for specific environments (e.g. AWS or Linux). Portable software, on the other hand, works in different operating environments without needing major rework. An application is considered portable if the effort required to adapt it to a new environment is within reasonable limits. The phrase "to port" means to modify software and make it adaptable to work on a different computer system. +Traditionally, software is often built for specific environments (e.g. AWS or Linux). +Portable software, on the other hand, works in different operating environments without needing major rework. +An application is considered portable if the effort required to adapt it to a new environment is within reasonable limits. +The phrase "to port" means to modify software and make it adaptable to work on a different computer system. diff --git a/content/en/reliability.md b/content/en/reliability.md index 92a744a98a..08a4352af0 100644 --- a/content/en/reliability.md +++ b/content/en/reliability.md @@ -4,4 +4,7 @@ status: Completed category: property --- -From a cloud native perspective, reliability refers to how well a system responds to failures. If we have a [distributed system](/distributed_systems/) that keeps working as infrastructure changes and individual components fail, it is reliable. On the other hand, if it fails easily and operators need to intervene manually to keep it running, it is unreliable. The goal of [cloud native applications](/cloud_native_apps/) is to build inherently reliable systems. +From a cloud native perspective, reliability refers to how well a system responds to failures. +If we have a [distributed system](/distributed_systems/) that keeps working as infrastructure changes and individual components fail, it is reliable. +On the other hand, if it fails easily and operators need to intervene manually to keep it running, it is unreliable. +The goal of [cloud native applications](/cloud_native_apps/) is to build inherently reliable systems. diff --git a/content/en/scalability.md b/content/en/scalability.md index 8b5d36cf49..1935368df5 100644 --- a/content/en/scalability.md +++ b/content/en/scalability.md @@ -4,6 +4,17 @@ status: Completed category: property --- -Scalability refers to how well a system can grow. That is increasing the ability to do whatever the system is supposed to do. For example, a [Kubernetes](/kubernetes/) [cluster](/cluster/) scales by increasing or reducing the number of [containerized](/containerization/) apps, but that scalability depends on several factors. How many [nodes](/nodes/) does it have, how many [containers](/container/) can each node handle, and how many records and operations can the control plane support? +Scalability refers to how well a system can grow. +That is increasing the ability to do whatever the system is supposed to do. +For example, a [Kubernetes](/kubernetes/) [cluster](/cluster/) scales by +increasing or reducing the number of [containerized](/containerization/) apps, +but that scalability depends on several factors. +How many [nodes](/nodes/) does it have, how many [containers](/container/) can each node handle, +and how many records and operations can the control plane support? -A scalable system makes it easy to add more capacity. We differentiate between two scaling approaches. On the one hand, there is [horizontal scaling](/horizontal_scaling/) which adds more nodes to handle increased load. In contrast, in [vertical scaling](/vertical_scaling/) individual nodes are made more powerful to perform more transactions (e.g. by adding more memory or CPU to an individual machine). A scalable system is able to change easily and meet user needs. +A scalable system makes it easy to add more capacity. +We differentiate between two scaling approaches. +On the one hand, there is [horizontal scaling](/horizontal_scaling/) which adds more nodes to handle increased load. +In contrast, in [vertical scaling](/vertical_scaling/) individual nodes are made more powerful to perform more transactions +(e.g. by adding more memory or CPU to an individual machine). +A scalable system is able to change easily and meet user needs. diff --git a/content/en/security_chaos_engineering.md b/content/en/security_chaos_engineering.md index c40876be96..fee5782e84 100644 --- a/content/en/security_chaos_engineering.md +++ b/content/en/security_chaos_engineering.md @@ -6,14 +6,29 @@ category: concept ## What it is -Security Chaos Engineering or SCE is a discipline based on [Chaos Engineering](/chaos_engineering/). SCE performs proactive security experimentation on a distributed system to build confidence in the system's capability to withstand turbulent and malicious conditions. Security chaos engineers use scientific method loops to achieve this, including steady-state, hypothesis, continuous verification, lesson learned, and mitigation implementation. +Security Chaos Engineering or SCE is a discipline based on [Chaos Engineering](/chaos_engineering/). +SCE performs proactive security experimentation on a distributed system +to build confidence in the system's capability to withstand turbulent and malicious conditions. +Security chaos engineers use scientific method loops to achieve this, +including steady-state, hypothesis, continuous verification, lesson learned, and mitigation implementation. ## Problem it addresses -The main priority for [site reliability engineers](/site_reliability_engineering/) (SREs) and cyber security engineers is to restore service as fast as possible with the goal of achieving zero downtime and minimizing business impact. SREs and cyber security engineers deal both with pre-failure and post-failure incidents situations. Most security issues are challenging to discover and patch quickly, impacting application or system functionality. Additionally, security incidents are usually tricky to uncover during the development phase. +The main priority for [site reliability engineers](/site_reliability_engineering/) (SREs) and cyber security engineers is +to restore service as fast as possible with the goal of achieving zero downtime and minimizing business impact. +SREs and cyber security engineers deal both with pre-failure and post-failure incidents situations. +Most security issues are challenging to discover and patch quickly, impacting application or system functionality. +Additionally, security incidents are usually tricky to uncover during the development phase. ## How it helps -Security Chaos Engineering is built around [observability](/observability/) and cyber resiliency practices. It aims to uncover the "unknown unknowns" and build confidence in the system, increasing cyber resiliency and improving observability. +Security Chaos Engineering is built around [observability](/observability/) and cyber resiliency practices. +It aims to uncover the "unknown unknowns" and build confidence in the system, +increasing cyber resiliency and improving observability. -Engineering teams will progressively improve the understanding for security concerns 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 create confidence in the system, increase cyber resiliency and improve observability. +Engineering teams will progressively improve the understanding for security concerns +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 +create confidence in the system, increase cyber resiliency and improve observability. diff --git a/content/en/self_healing.md b/content/en/self_healing.md index 91ecd24ec8..fd57e4748a 100644 --- a/content/en/self_healing.md +++ b/content/en/self_healing.md @@ -4,4 +4,8 @@ status: Completed category: property --- -A self-healing system is capable of recovering from certain types of failure without any human intervention. It has a "convergence" or "control" loop that actively looks at the system’s actual state and compares it to the state that the operators initially desired. If there is a difference (e.g., fewer application instances are running than desired), it will take corrective action (e.g., start new instances). +A self-healing system is capable of recovering from certain types of failure without any human intervention. +It has a "convergence" or "control" loop that actively looks at the system’s actual state and +compares it to the state that the operators initially desired. +If there is a difference (e.g., fewer application instances are running than desired), +it will take corrective action (e.g., start new instances). diff --git a/content/en/serverless.md b/content/en/serverless.md index d844262d55..3f43298469 100644 --- a/content/en/serverless.md +++ b/content/en/serverless.md @@ -6,12 +6,29 @@ Category: Technology ## What it is -Serverless is a cloud native development model that allows developers to build and run applications without having to manage servers. There are still servers in serverless, but they are [abstracted](/abstraction/) away from app development. A cloud provider handles the routine work of provisioning, maintaining, and [scaling](/scalability/) the server infrastructure. Developers can simply package their code in [containers](/container/) for deployment. Once deployed, serverless apps respond to demand and automatically scale up and down as needed. Serverless offerings from public cloud providers are usually metered on-demand through an event-driven execution model. As a result, when a serverless function is sitting idle, it doesn’t cost anything. +Serverless is a cloud native development model that allows developers to +build and run applications without having to manage servers. +There are still servers in serverless, but they are [abstracted](/abstraction/) away from app development. +A cloud provider handles the routine work of provisioning, maintaining, and [scaling](/scalability/) the server infrastructure. +Developers can simply package their code in [containers](/container/) for deployment. +Once deployed, serverless apps respond to demand and automatically scale up and down as needed. +Serverless offerings from public cloud providers are usually metered on-demand through an event-driven execution model. +As a result, when a serverless function is sitting idle, it doesn’t cost anything. ## Problem it addresses -Under a standard [Infrastructure-as-a-Service (IaaS)](/infrastructure_as_a_service/) [cloud computing](/cloud_computing/) model, users pre-purchase units of capacity, meaning you pay a public cloud provider for always-on server components to run your apps. It’s the user’s responsibility to scale up server capacity during times of high demand and to scale down when that capacity is no longer needed. The cloud infrastructure necessary to run an app is active even when the app isn’t being used. +Under a standard [Infrastructure-as-a-Service (IaaS)](/infrastructure_as_a_service/) [cloud computing](/cloud_computing/) model, +users pre-purchase units of capacity, meaning you pay a public cloud provider for always-on server components to run your apps. +It’s the user’s responsibility to scale up server capacity during times of high demand and +to scale down when that capacity is no longer needed. +The cloud infrastructure necessary to run an app is active even when the app isn’t being used. ## How it helps -With serverless architecture, by contrast, apps are launched only as needed. When an event triggers app code to run, the public cloud provider dynamically allocates resources for that code. The user stops paying when the code finishes executing. In addition to the cost and efficiency benefits, serverless frees developers from routine and menial tasks associated with app scaling and server provisioning. With serverless, routine tasks such as managing the operating system and file system, security patches, load balancing, capacity management, scaling, logging, and monitoring are all offloaded to a cloud services provider. +With serverless architecture, by contrast, apps are launched only as needed. +When an event triggers app code to run, the public cloud provider dynamically allocates resources for that code. +The user stops paying when the code finishes executing. +In addition to the cost and efficiency benefits, +serverless frees developers from routine and menial tasks associated with app scaling and server provisioning. +With serverless, routine tasks such as managing the operating system and file system, security patches, +load balancing, capacity management, scaling, logging, and monitoring are all offloaded to a cloud services provider. diff --git a/content/en/service.md b/content/en/service.md index fc3ef5a40c..54230ca89b 100644 --- a/content/en/service.md +++ b/content/en/service.md @@ -4,4 +4,8 @@ status: Completed category: concept --- -Please note that in IT, service has multiple meanings. In this definition, we'll focus on the more traditional one: service as in microservice. How or even if services differ from microservices is nuanced and different people may have different opinions. For a high-level definition, we'll treat them as the same. Please refer to the [microservices](/microservices/) definition. +Please note that in IT, service has multiple meanings. +In this definition, we'll focus on the more traditional one: service as in microservice. +How or even if services differ from microservices is nuanced and different people may have different opinions. +For a high-level definition, we'll treat them as the same. +Please refer to the [microservices](/microservices/) definition. diff --git a/content/en/service_discovery.md b/content/en/service_discovery.md index 3e95d13e51..b77b799611 100644 --- a/content/en/service_discovery.md +++ b/content/en/service_discovery.md @@ -6,12 +6,18 @@ category: concept ## What it is -Service discovery is the process of finding individual instances that make up a service. A service discovery tool keeps track of the various nodes or endpoints that make up a service. +Service discovery is the process of finding individual instances that make up a service. +A service discovery tool keeps track of the various nodes or endpoints that make up a service. ## Problem it addresses -Cloud native architectures are dynamic and fluid, meaning they are constantly changing. A [containerized](/containerization/) app will likely end up starting and stopping multiple times in its lifetime. Each time that happens, it will have a new address and any app that wants to find it needs a tool to provide the new location information. +Cloud native architectures are dynamic and fluid, meaning they are constantly changing. +A [containerized](/containerization/) app will likely end up starting and stopping multiple times in its lifetime. +Each time that happens, it will have a new address and +any app that wants to find it needs a tool to provide the new location information. ## How it helps -Service discovery keeps track of apps within the network so they can find one another when needed. It provides a common place to find and potentially identify individual services. Service discovery engines are database-like tools that store info about what services exist and how to locate them. +Service discovery keeps track of apps within the network so they can find one another when needed. +It provides a common place to find and potentially identify individual services. +Service discovery engines are database-like tools that store info about what services exist and how to locate them. diff --git a/content/en/service_mesh.md b/content/en/service_mesh.md index 75f0b7715a..f6d8425ec5 100644 --- a/content/en/service_mesh.md +++ b/content/en/service_mesh.md @@ -6,12 +6,24 @@ category: technology ## What it is -In a [microservices](/microservices/) world, apps are broken down into multiple smaller [services](/service/) that communicate over a network. Just like your wifi network, computer networks are intrinsically unreliable, hackable, and often slow. Service meshes address this new set of challenges by managing traffic (i.e., communication) between services and adding [reliability](/reliability/), [observability](/observability/), and security features uniformly across all services. +In a [microservices](/microservices/) world, apps are broken down into multiple smaller [services](/service/) that communicate over a network. +Just like your wifi network, computer networks are intrinsically unreliable, hackable, and often slow. +Service meshes address this new set of challenges by managing traffic (i.e., communication) between services and +adding [reliability](/reliability/), [observability](/observability/), and security features uniformly across all services. ## Problem it addresses -Having moved to a microservices architecture, engineers are now dealing with hundreds, possibly even thousands of individual services, all needing to communicate. That means a lot of traffic is going back and forth over the network. On top of that, individual applications may need to encrypt communications to support regulatory requirements, provide common metrics to operations teams, or provide detailed insight into traffic to help diagnose issues. If built into the individual applications, each one of these features will cause friction between teams and slow down development of new features. +Having moved to a microservices architecture, engineers are now dealing with hundreds, +possibly even thousands of individual services, all needing to communicate. +That means a lot of traffic is going back and forth over the network. +On top of that, individual applications may need to encrypt communications to support regulatory requirements, +provide common metrics to operations teams, or provide detailed insight into traffic to help diagnose issues. +If built into the individual applications, +each one of these features will cause friction between teams and slow down development of new features. ## How it helps -Service meshes add reliability, observability, and security features uniformly across all services across a cluster without requiring code changes. Before service meshes, that functionality had to be encoded into every single service, becoming a potential source of bugs and technical debt. +Service meshes add reliability, observability, and security features +uniformly across all services across a cluster without requiring code changes. +Before service meshes, that functionality had to be encoded into every single service, +becoming a potential source of bugs and technical debt. diff --git a/content/en/service_proxy.md b/content/en/service_proxy.md index 959498fbb1..724efb1fea 100644 --- a/content/en/service_proxy.md +++ b/content/en/service_proxy.md @@ -6,16 +6,24 @@ category: technology ## What it is -A service proxy intercepts traffic to or from a given [service](/service/), applies some logic to it, then forwards that traffic to another service. It essentially acts as a “go-between” that collects information about network traffic and/or applies rules to it. +A service proxy intercepts traffic to or from a given [service](/service/), +applies some logic to it, then forwards that traffic to another service. +It essentially acts as a “go-between” that collects information about network traffic and/or applies rules to it. ## Problem it addresses -To keep track of service to service communication (aka network traffic) and potentially transform or redirect it, we need to collect data. Traditionally, the code enabling data collection and network traffic management was embedded within each application. +To keep track of service to service communication (aka network traffic) and +potentially transform or redirect it, we need to collect data. +Traditionally, the code enabling data collection and network traffic management was embedded within each application. ## How it helps -A service proxy allows us to “externalize” this functionality. No longer does it need to live within the apps. Instead, it’s now embedded into the platform layer (where your apps run). +A service proxy allows us to “externalize” this functionality. +No longer does it need to live within the apps. +Instead, it’s now embedded into the platform layer (where your apps run). -Acting as gatekeepers between services, proxies provide insight into what type of communication is happening. Based on their insight, they determine where to send a particular request or even deny it entirely. +Acting as gatekeepers between services, proxies provide insight into what type of communication is happening. +Based on their insight, they determine where to send a particular request or even deny it entirely. -Proxies gather critical data, manage routing (spreading traffic evenly among services or rerouting if some services break down), encrypt connections, and cache content (reducing resource consumption). +Proxies gather critical data, manage routing (spreading traffic evenly among services or rerouting if some services break down), +encrypt connections, and cache content (reducing resource consumption). diff --git a/content/en/shift_left.md b/content/en/shift_left.md index 8cde7f21a6..d64a460c9f 100644 --- a/content/en/shift_left.md +++ b/content/en/shift_left.md @@ -6,18 +6,34 @@ category: Concept ## What it is -Left in Shift Left refers to earlier stages in a software development lifecycle, thinking of the lifecycle as a line where stages are executed from left to right. Shift Left is the practice of implementing tests, security, or other development practices early in the software development lifecycle rather than towards the end. +Left in Shift Left refers to earlier stages in a software development lifecycle, +thinking of the lifecycle as a line where stages are executed from left to right. +Shift Left is the practice of implementing tests, security, or other development practices +early in the software development lifecycle rather than towards the end. -Although originally used to refer to the process of testing early, Shift Left can now also be applied to other aspects of software development and [DevOps](/devops/), such as security and deployment. +Although originally used to refer to the process of testing early, +Shift Left can now also be applied to other aspects of software development and [DevOps](/devops/), such as security and deployment. ## Problem it addresses -Security issues, bugs, and software defects can be more difficult and expensive to fix if they are discovered late in the development cycle or after deployment, particularly if the software has already been deployed into production. +Security issues, bugs, and software defects can be more difficult and expensive to fix +if they are discovered late in the development cycle or after deployment, +particularly if the software has already been deployed into production. ## How it helps -By adopting a Shift Left mindset for software development, teams can implement testing and security throughout the development lifecycle. And because responsibility for testing and security is shared across the development team — from software engineers to quality assurance to operations — everyone plays a part in ensuring the stability and security of an application. - -In addition, shifting left enables continuous improvement and follows an [agile](/agile_software_development/) rather than waterfall approach to development. Teams can make small iterative improvements and identify problems earlier on. This approach allows engineers to adopt security and secure development practices as early as the design and architecture phase. Testing throughout the development cycle, decreases the time required for testing before a software release. - -Many software tools and SaaS solutions help shift these practices left. However, shift left can also be implemented through improved processes and cultural changes within a team. +By adopting a Shift Left mindset for software development, +teams can implement testing and security throughout the development lifecycle. +And because responsibility for testing and security is shared across the development team +— from software engineers to quality assurance to operations — +everyone plays a part in ensuring the stability and security of an application. + +In addition, shifting left enables continuous improvement and +follows an [agile](/agile_software_development/) rather than waterfall approach to development. +Teams can make small iterative improvements and identify problems earlier on. +This approach allows engineers to adopt security and secure development practices +as early as the design and architecture phase. +Testing throughout the development cycle, decreases the time required for testing before a software release. + +Many software tools and SaaS solutions help shift these practices left. +However, shift left can also be implemented through improved processes and cultural changes within a team. diff --git a/content/en/site_reliability_engineering.md b/content/en/site_reliability_engineering.md index 229e61059f..535e1dce4f 100644 --- a/content/en/site_reliability_engineering.md +++ b/content/en/site_reliability_engineering.md @@ -6,12 +6,23 @@ category: concept ## What it is -Site Reliability Engineering or SRE is a discipline that combines operations and software engineering. The latter is applied to infrastructure and operations problems, specifically. Meaning, instead of building product features, Site Reliability Engineers build systems to run applications. There are similarities with DevOps, but while DevOps focuses on getting code to production, SRE ensures that code running in production works properly. +Site Reliability Engineering or SRE is a discipline that combines operations and software engineering. +The latter is applied to infrastructure and operations problems, specifically. +Meaning, instead of building product features, Site Reliability Engineers build systems to run applications. +There are similarities with DevOps, but while DevOps focuses on getting code to production, +SRE ensures that code running in production works properly. ## Problem it addresses -Ensuring applications run reliably requires multiple capabilities, from performance monitoring, alerting, debugging to troubleshooting. Without these, system operators can only react to problems vs. proactively working towards avoiding them — downtime only becomes a matter of time. +Ensuring applications run reliably requires multiple capabilities, +from performance monitoring, alerting, debugging to troubleshooting. +Without these, system operators can only react to problems vs. proactively working towards avoiding them +— downtime only becomes a matter of time. ## How it helps -An SRE approach minimizes the cost, time, and effort of the software development process by continuously improving the underlying system. The system continuously measures and monitors the infrastructure and application components. When something goes wrong, the system points Site Reliability Engineers to when, where, and how to fix it. This approach helps create highly scalable and reliable software systems by automating operational tasks. +An SRE approach minimizes the cost, time, and effort of the software development process +by continuously improving the underlying system. +The system continuously measures and monitors the infrastructure and application components. +When something goes wrong, the system points Site Reliability Engineers to when, where, and how to fix it. +This approach helps create highly scalable and reliable software systems by automating operational tasks. diff --git a/content/en/software_as_a_service.md b/content/en/software_as_a_service.md index 91f3df910b..3e111beaee 100644 --- a/content/en/software_as_a_service.md +++ b/content/en/software_as_a_service.md @@ -6,12 +6,24 @@ Category: Technology ## What it is -Software as a service (SaaS) allows users to connect to and use cloud-based services over the Internet. Common examples are email, calendaring, and office tools (such as Gmail, Amazon Web Services, GitHub, Slack). SaaS provides complete software solutions on a pay-as-you-go basis. All operations and maintenance tasks, and application data, are handled by the service provider. +Software as a service (SaaS) allows users to connect to and use cloud-based services over the Internet. +Common examples are email, calendaring, and office tools (such as Gmail, Amazon Web Services, GitHub, Slack). +SaaS provides complete software solutions on a pay-as-you-go basis. +All operations and maintenance tasks, and application data, are handled by the service provider. ## Problem it addresses -Traditionally, business software is installed on individual computers, requiring an admin to maintain and update. As an example: An organization may use on-premise software for customer relationship management (CRM). This software needs to be purchased, installed, secured, maintained, and regularly upgraded by the internal IT department, placing a burden on the IT team. The up front cost associated with licenses, installation, and potentially additional hardware can be prohibitive. It can also be difficult to respond to demand and [scale](/scalability/) up and down as needed quickly in response to growth or change. +Traditionally, business software is installed on individual computers, requiring an admin to maintain and update. +As an example: An organization may use on-premise software for customer relationship management (CRM). +This software needs to be purchased, installed, secured, maintained, and regularly upgraded +by the internal IT department, placing a burden on the IT team. +The up front cost associated with licenses, installation, and potentially additional hardware can be prohibitive. +It can also be difficult to respond to demand and [scale](/scalability/) up and down +as needed quickly in response to growth or change. ## How it helps -SaaS applications work without requiring any particular effort from your internal IT organization. They are installed, maintained, upgraded, and secured by the vendor. Issues of scale, availability, and capacity are handled by the service provider, and, with a pay-as-you-go model, they can be an affordable way for organizations to leverage enterprise applications. +SaaS applications work without requiring any particular effort from your internal IT organization. +They are installed, maintained, upgraded, and secured by the vendor. +Issues of scale, availability, and capacity are handled by the service provider, and, +with a pay-as-you-go model, they can be an affordable way for organizations to leverage enterprise applications. diff --git a/content/en/stateful_apps.md b/content/en/stateful_apps.md index edc01cacf3..de091e76ab 100644 --- a/content/en/stateful_apps.md +++ b/content/en/stateful_apps.md @@ -6,12 +6,25 @@ category: concept ## What it is -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. ## Problem it addresses -Using an app generally requires multiple requests. For example, when online banking, you'll authenticate yourself by entering your password (request #1), then you may transfer money to a friend (request #2), and finally, you'll want to view transfer details (request #3). To function correctly, each step has to remember the previous ones, and the bank needs to remember the state of everyone’s accounts. Today, most applications we use are at least partly stateful, as they store things like preferences and settings to improve the user experience. +Using an app generally requires multiple requests. +For example, when online banking, you'll authenticate yourself by +entering your password (request #1), +then you may transfer money to a friend (request #2), +and finally, you'll want to view transfer details (request #3). +To function correctly, each step has to remember the previous ones, +and the bank needs to remember the state of everyone’s accounts. +Today, most applications we use are at least partly stateful, +as they store things like preferences and settings to improve the user experience. ## How it helps -There are several ways to store state for a stateful application. The simplest is to hold the state in memory and not persist it anywhere. The problem with that is, whenever the application has to be restarted, all state is lost. In order to prevent that, state is persisted either locally (on disk) or in database systems. +There are several ways to store state for a stateful application. +The simplest is to hold the state in memory and not persist it anywhere. +The problem with that is, whenever the application has to be restarted, all state is lost. +In order to prevent that, state is persisted either locally (on disk) or in database systems. diff --git a/content/en/stateless_apps.md b/content/en/stateless_apps.md index a1e8e22e39..84b08f475a 100644 --- a/content/en/stateless_apps.md +++ b/content/en/stateless_apps.md @@ -6,12 +6,30 @@ category: technology ## What it is -A stateless application doesn’t save any client session (state) data on the server where the application lives. Each session is carried out as if it was the first time and responses are not dependent upon data from a previous session and provides functionality to use print services, CDN (Content Delivery Network) or the Web Servers in order to process every short-term request. For example, someone is searching a question in the search engine and pressed the Enter button. In case if the searching operation gets interrupted or closed due to some reason, you have to start a new one as there is no saved data for your previous request. +A stateless application doesn’t save any client session (state) data on the server where the application lives. +Each session is carried out as if it was the first time and responses are not dependent upon data from a previous session and +provides functionality to use print services, CDN (Content Delivery Network) or the Web Servers +in order to process every short-term request. +For example, someone is searching a question in the search engine and pressed the Enter button. +In case if the searching operation gets interrupted or closed due to some reason, +you have to start a new one as there is no saved data for your previous request. ## Problem it addresses -Stateless applications tackle the problem of resiliency, because different pods across a [cluster](/cluster/) can work independently, with multiple requests coming to them at the same time. If there’s a problem, you can easily restart the application, and it will return to its initial state with little or no downtime. As such, the benefits of stateless applications include resiliency, elasticity, and high availability. However, most applications we use today are at least partly [stateful](/stateful_apps/), as they store things like preferences and settings to improve the user experience. +Stateless applications tackle the problem of resiliency, +because different pods across a [cluster](/cluster/) can work independently, +with multiple requests coming to them at the same time. +If there’s a problem, you can easily restart the application, +and it will return to its initial state with little or no downtime. +As such, the benefits of stateless applications include resiliency, elasticity, and high availability. +However, most applications we use today are at least partly [stateful](/stateful_apps/), +as they store things like preferences and settings to improve the user experience. ## How it helps -Boiling everything down, in a Stateless Application the only thing your cluster is responsible for is the code, and other static content, being hosted on it. That’s it, no changing databases, no writes and no left over files when the pod is deleted. Stateless [containers](/container/) are easier to deploy, and you don’t need to worry about saving container data on persistent storage volumes. You also don't have to worry about backing up the data. +Boiling everything down, in a Stateless Application the only thing your cluster is responsible for is +the code, and other static content, being hosted on it. +That’s it, no changing databases, no writes and no left over files when the pod is deleted. +Stateless [containers](/container/) are easier to deploy, +and you don’t need to worry about saving container data on persistent storage volumes. +You also don't have to worry about backing up the data. diff --git a/content/en/tightly_coupled_architectures.md b/content/en/tightly_coupled_architectures.md index bc781402a9..be805778d2 100644 --- a/content/en/tightly_coupled_architectures.md +++ b/content/en/tightly_coupled_architectures.md @@ -4,6 +4,16 @@ status: Completed category: Property --- -Tightly coupled architecture is an architectural style where a number of application components are interdependent (the opposite paradigm of [loosely coupled architectures](/loosely_coupled_architecture/)). This means that a change in one component will likely impact other components. It is generally easier to implement than more loosely coupled architectural styles, but can leave a system more vulnerable to cascading failures. They also tend to require coordinated rollouts of components which can become a drag on developer productivity. +Tightly coupled architecture is an architectural style where a number of application components are interdependent +(the opposite paradigm of [loosely coupled architectures](/loosely_coupled_architecture/)). +This means that a change in one component will likely impact other components. +It is generally easier to implement than more loosely coupled architectural styles, +but can leave a system more vulnerable to cascading failures. +They also tend to require coordinated rollouts of components +which can become a drag on developer productivity. -Tightly coupled application architectures are a fairly traditional way of building applications. While not necessarily consistent with all the best practices of [microservice](/microservices/) development they can be useful in specific circumstances. They tend to be faster and simpler to implement and much like [monolithic applications](/monolithic_apps/) they can speed up the initial development cycle. +Tightly coupled application architectures are a fairly traditional way of building applications. +While not necessarily consistent with all the best practices of [microservice](/microservices/) development +they can be useful in specific circumstances. +They tend to be faster and simpler to implement and +much like [monolithic applications](/monolithic_apps/) they can speed up the initial development cycle. diff --git a/content/en/versioncontrol.md b/content/en/versioncontrol.md index 7f827b95fd..a0753e023e 100644 --- a/content/en/versioncontrol.md +++ b/content/en/versioncontrol.md @@ -6,12 +6,23 @@ category: Technology ## What it is -Source control (or version control) is the practice of tracking and managing changes to a document. It is a system that records changes to a file or set of files over time so that you can recall specific versions later. +Source control (or version control) is the practice of tracking and managing changes to a document. +It is a system that records changes to a file or set of files over time so that you can recall specific versions later. ## Problem it addresses -Version control systems work to address the following problems, backing up a document or codebase as it changes over time, allowing multiple users to resolve conflicts when there are overlapping changes, and storing a log of changes over time. Application code can often be complex and critical to key business processes, so it is important to track who changed what, when it was changed, and why. Also, many, if not most applications, are modified by multiple developers, and there are often conflicts between the changes introduced by different developers. +Version control systems work to address the following problems, +backing up a document or codebase as it changes over time, +allowing multiple users to resolve conflicts when there are overlapping changes, and +storing a log of changes over time. +Application code can often be complex and critical to key business processes, +so it is important to track who changed what, when it was changed, and why. +Also, many, if not most applications, are modified by multiple developers, +and there are often conflicts between the changes introduced by different developers. ## How it helps -Version control helps developers move fast and preserve efficiency while storing a record of changes and providing a facility to resolve conflicts. It allows them to store application code in a repository and simplify collaboration. Modern application development relies heavily on version control systems, like git, to store their code. +Version control helps developers move fast and preserve efficiency +while storing a record of changes and providing a facility to resolve conflicts. +It allows them to store application code in a repository and simplify collaboration. +Modern application development relies heavily on version control systems, like git, to store their code. diff --git a/content/en/vertical_scaling.md b/content/en/vertical_scaling.md index 5ffbb6fdb4..ae7323bda0 100644 --- a/content/en/vertical_scaling.md +++ b/content/en/vertical_scaling.md @@ -6,15 +6,26 @@ category: Concept ## What it is -Vertical scaling, also known as "scaling up and down", is a technique where a system's capacity is increased by adding CPU and memory to individual [nodes](/nodes/) as the workload increases. Let's say, you have a computer of 4GB RAM and want to increase its capacity to 16GB RAM, scaling it vertically means switching to a 16GB RAM system. (Please refer to [horizontal scaling](/horizontal_scaling/) for a different scaling approach.) +Vertical scaling, also known as "scaling up and down", is a technique where +a system's capacity is increased by adding CPU and memory to individual [nodes](/nodes/) as the workload increases. +Let's say, you have a computer of 4GB RAM and want to increase its capacity to 16GB RAM, +scaling it vertically means switching to a 16GB RAM system. +(Please refer to [horizontal scaling](/horizontal_scaling/) for a different scaling approach.) ## Problem it addresses -As demand for an application grows beyond the current capacity of that application instance, we need to find a way to scale (add capacity to) the system. We can either add more compute resources to existing nodes (vertical scaling) or more nodes to the system ([horizontal scaling](/horizontal_scaling/)). [Scalability](/scalability/) contributes to competitiveness, efficiency, reputation, and quality. +As demand for an application grows beyond the current capacity of that application instance, +we need to find a way to scale (add capacity to) the system. +We can either add more compute resources to existing nodes (vertical scaling) +or more nodes to the system ([horizontal scaling](/horizontal_scaling/)). +[Scalability](/scalability/) contributes to competitiveness, efficiency, reputation, and quality. ## How it helps -Vertical scaling allows you to resize your server without changing the application code. That contrasts to horizontal scaling, where the app must be replicable to scale, potentially requiring code updates. Vertical scaling increases the capacity of an existing application by adding compute resources, allowing the app to process more requests and do more work concurrently. +Vertical scaling allows you to resize your server without changing the application code. +That contrasts to horizontal scaling, where the app must be replicable to scale, potentially requiring code updates. +Vertical scaling increases the capacity of an existing application by +adding compute resources, allowing the app to process more requests and do more work concurrently. ## Related terms diff --git a/content/en/virtual_machine.md b/content/en/virtual_machine.md index 17f31d041b..f3a72bf8c6 100644 --- a/content/en/virtual_machine.md +++ b/content/en/virtual_machine.md @@ -6,14 +6,31 @@ category: Technology ## What it is -A virtual machine (VM) is a computer and its operating system that is not bound to a particular piece of hardware. VMs rely on [virtualization](/virtualization/) to carve a single physical computer into multiple virtual computers. That separation allows organizations and infrastructure providers to easily create and destroy VMs without impacting the underlying hardware. +A virtual machine (VM) is a computer and its operating system +that is not bound to a particular piece of hardware. +VMs rely on [virtualization](/virtualization/) to carve a single physical computer into multiple virtual computers. +That separation allows organizations and infrastructure providers to +easily create and destroy VMs without impacting the underlying hardware. ## Problem it addresses -Virtual machines take advantage of virtualization. When a [bare metal](/bare_metal_machine/) machine is bound to a single operating system, how well the machine's resources can be used is somewhat limited. Also, when an operating system is bound to a single physical machine, its availability is directly tied to that hardware. If the physical machine is offline due to maintenance or hardware failures, so is the operating system. +Virtual machines take advantage of virtualization. +When a [bare metal](/bare_metal_machine/) machine is bound to a single operating system, +how well the machine's resources can be used is somewhat limited. +Also, when an operating system is bound to a single physical machine, +its availability is directly tied to that hardware. +If the physical machine is offline due to maintenance or hardware failures, so is the operating system. ## How it helps -By removing the direct relationship between an operating system and a single physical machine, you solve several problems of bare metal machines: provisioning time, hardware utilization, and resiliency. +By removing the direct relationship between an operating system and a single physical machine, +you solve several problems of bare metal machines: +provisioning time, hardware utilization, and resiliency. -With no new hardware to be bought, installed, or configured to support it, provisioning time for a new computer is dramatically improved. VMs allow you to use your existing physical hardware resources better by placing multiple virtual machines on a single physical machine. Not bound to a particular physical machine, VMs are also more resilient than physical machines. When a physical machine needs to go offline, the VMs running on it can be moved to another machine with little to no downtime +With no new hardware to be bought, installed, or configured to support it, +provisioning time for a new computer is dramatically improved. +VMs allow you to use your existing physical hardware resources better +by placing multiple virtual machines on a single physical machine. +Not bound to a particular physical machine, VMs are also more resilient than physical machines. +When a physical machine needs to go offline, +the VMs running on it can be moved to another machine with little to no downtime diff --git a/content/en/virtualization.md b/content/en/virtualization.md index 23f2ec5f48..3cccd5a950 100644 --- a/content/en/virtualization.md +++ b/content/en/virtualization.md @@ -6,12 +6,24 @@ category: technology ## What it is -Virtualization, in the context of cloud native computing, refers to the process of taking a physical computer, sometimes called a server, and allowing it to run multiple isolated operating systems. Those isolated operating systems and their dedicated compute resources (CPU, memory, and network) are referred to as virtual machines or VMs. When we talk about a virtual machine, we’re talking about a software-defined computer. Something that looks and acts like a real computer but is sharing hardware with other virtual machines. As an example, you can lease a "computer" from AWS – that computer is actually a VM. +Virtualization, in the context of cloud native computing, +refers to the process of taking a physical computer, sometimes called a server, +and allowing it to run multiple isolated operating systems. +Those isolated operating systems and their dedicated compute resources (CPU, memory, and network) are +referred to as virtual machines or VMs. +When we talk about a virtual machine, we’re talking about a software-defined computer. +Something that looks and acts like a real computer but is sharing hardware with other virtual machines. +As an example, you can lease a "computer" from AWS – that computer is actually a VM. ## Problem it addresses -Virtualization addresses a number of problems, including the improvement of physical hardware usage by allowing more apps to run on the same physical machine whilst still being isolated from each other for security. +Virtualization addresses a number of problems, including the improvement of physical hardware usage +by allowing more apps to run on the same physical machine +whilst still being isolated from each other for security. ## How it helps -Apps running on virtual machines have no awareness that they are sharing a physical computer. Virtualization also allows the users of the datacenter to spin up a new "computer" (aka a VM) in minutes without worrying about the physical constraints of adding a new computer to a datacenter. VMs also enable users to speed up the time to get a new virtual computer. +Apps running on virtual machines have no awareness that they are sharing a physical computer. +Virtualization also allows the users of the datacenter to spin up a new "computer" (aka a VM) in minutes +without worrying about the physical constraints of adding a new computer to a datacenter. +VMs also enable users to speed up the time to get a new virtual computer. diff --git a/content/en/zero_trust_architecture.md b/content/en/zero_trust_architecture.md index f59d16a305..9ed8348a69 100644 --- a/content/en/zero_trust_architecture.md +++ b/content/en/zero_trust_architecture.md @@ -6,12 +6,30 @@ category: Concept ## What it is -Zero trust architecture prescribes to an approach to the design and implementation of IT systems where trust is completely removed. The core principle being "never trust, always verify", devices or systems themselves, whilst communicating to other components of a system, always verify themselves before doing so. In many networks today, within the corporate network, systems and devices inside may freely communicate with each other as they are within the trusted boundary of the corporate network perimeter. Zero trust architecture takes the opposite approach where although inside the network perimeter, components within the system first have to pass verification before any communication is made. +Zero trust architecture prescribes to an approach to the design and implementation of IT systems +where trust is completely removed. +The core principle being "never trust, always verify", devices or systems themselves, +whilst communicating to other components of a system, always verify themselves before doing so. +In many networks today, within the corporate network, systems and devices inside may freely communicate with each other +as they are within the trusted boundary of the corporate network perimeter. +Zero trust architecture takes the opposite approach where although inside the network perimeter, +components within the system first have to pass verification before any communication is made. ## Problem it addresses -With the traditional trust based approach where systems and devices that exist within a corporate network perimeter, the assumption is that because there is trust, there is no problem. Zero trust architecture however, recognises that trust is a vulnerability. In the event where an attacker has gained access to a trusted device, depending on the level of trust and access that has been given to that device, the system is now vulnerable to attack as the attacker is within the "trusted" network perimeter and is able to move laterally throughout the system. In a zero trust architecture, trust is removed, therefore reducing the attack surface as an attacker is now forced to verify before going any further throughout the system. +With the traditional trust based approach where systems and devices that exist within a corporate network perimeter, +the assumption is that because there is trust, there is no problem. +Zero trust architecture however, recognises that trust is a vulnerability. +In the event where an attacker has gained access to a trusted device, +depending on the level of trust and access that has been given to that device, +the system is now vulnerable to attack +as the attacker is within the "trusted" network perimeter and is able to move laterally throughout the system. +In a zero trust architecture, trust is removed, therefore reducing the attack surface +as an attacker is now forced to verify before going any further throughout the system. ## How it helps -Adopting a zero trust architecture brings the principal benefit of increased security with a reduction in the attack surface. Removing trust from your corporate system now increases the number and strength of security gates that an attacker has to go through to gain access to other areas of the system. +Adopting a zero trust architecture brings the principal benefit of increased security +with a reduction in the attack surface. +Removing trust from your corporate system now increases the number and strength of security gates +that an attacker has to go through to gain access to other areas of the system. From 2832c5d13329297988223215dabf0f7bbd58db3d Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Tue, 31 May 2022 16:59:42 +0900 Subject: [PATCH 3/4] [all] Rename markdown filenames Signed-off-by: Jihoon Seo --- ...gile_software_development.md => agile-software-development.md} | 0 ...gramming_interface.md => application-programming-interface.md} | 0 content/bn/{cloud_computing.md => cloud-computing.md} | 0 content/bn/{cloud_native_security.md => cloud-native-security.md} | 0 content/bn/{cloud_native_tech.md => cloud-native-tech.md} | 0 content/bn/{software_as_a_service.md => software-as-a-service.md} | 0 ...gile_software_development.md => agile-software-development.md} | 0 content/en/{api_gateway.md => api-gateway.md} | 0 ...gramming_interface.md => application-programming-interface.md} | 0 content/en/{auto_scaling.md => auto-scaling.md} | 0 content/en/{bare_metal_machine.md => bare-metal-machine.md} | 0 content/en/{blue_green_deployment.md => blue-green-deployment.md} | 0 content/en/{canary_deployment.md => canary-deployment.md} | 0 content/en/{chaos_engineering.md => chaos-engineering.md} | 0 ...lient_server_architecture.md => client-server-architecture.md} | 0 content/en/{cloud_computing.md => cloud-computing.md} | 0 content/en/{cloud_native_apps.md => cloud-native-apps.md} | 0 content/en/{cloud_native_security.md => cloud-native-security.md} | 0 content/en/{cloud_native_tech.md => cloud-native-tech.md} | 0 .../en/{containers_as_a_service.md => containers-as-a-service.md} | 0 content/en/{continuous_delivery.md => continuous-delivery.md} | 0 content/en/{continuous_deployment.md => continuous-deployment.md} | 0 .../en/{continuous_integration.md => continuous-integration.md} | 0 content/en/{data_center.md => data-center.md} | 0 content/en/{database_as_a_service.md => database-as-a-service.md} | 0 content/en/{distributed_apps.md => distributed-apps.md} | 0 content/en/{distributed_systems.md => distributed-systems.md} | 0 content/en/{function_as_a_service.md => function-as-a-service.md} | 0 content/en/{horizontal_scaling.md => horizontal-scaling.md} | 0 .../{immutable_infrastructure.md => immutable-infrastructure.md} | 0 ...rastructure_as_a_service.md => infrastructure-as-a-service.md} | 0 .../en/{infrastructure_as_code.md => infrastructure-as-code.md} | 0 content/en/{load_balancer.md => load-balancer.md} | 0 ...ly_coupled_architecture.md => loosely-coupled-architecture.md} | 0 content/en/{managed_services.md => managed-services.md} | 0 content/en/{monolithic_apps.md => monolithic-apps.md} | 0 ...port Layer Security).md => mutual-transport-layer-security.md} | 0 content/en/{platform_as_a_service.md => platform-as-a-service.md} | 0 content/en/{policy_as_code.md => policy-as-code.md} | 0 ...ecurity_chaos_engineering.md => security-chaos-engineering.md} | 0 content/en/{self_healing.md => self-healing.md} | 0 content/en/{service_discovery.md => service-discovery.md} | 0 content/en/{service_mesh.md => service-mesh.md} | 0 content/en/{service_proxy.md => service-proxy.md} | 0 content/en/{shift_left.md => shift-left.md} | 0 ...reliability_engineering.md => site-reliability-engineering.md} | 0 content/en/{software_as_a_service.md => software-as-a-service.md} | 0 content/en/{stateful_apps.md => stateful-apps.md} | 0 content/en/{stateless_apps.md => stateless-apps.md} | 0 ..._coupled_architectures.md => tightly-coupled-architectures.md} | 0 ...S(Transport Layer Security).md => transport-layer-security.md} | 0 content/en/{versioncontrol.md => version-control.md} | 0 content/en/{vertical_scaling.md => vertical-scaling.md} | 0 content/en/{virtual_machine.md => virtual-machine.md} | 0 .../en/{zero_trust_architecture.md => zero-trust-architecture.md} | 0 ...gile_software_development.md => agile-software-development.md} | 0 content/es/{api_gateway.md => api-gateway.md} | 0 content/es/{bare_metal_machine.md => bare-metal-machine.md} | 0 content/es/{blue_green_deployment.md => blue-green-deployment.md} | 0 content/es/{cloud_computing.md => cloud-computing.md} | 0 .../es/{infrastructure_as_code.md => infrastructure-as-code.md} | 0 content/es/{load_balancer.md => load-balancer.md} | 0 ...gile_software_development.md => agile-software-development.md} | 0 content/hi/{auto_scaling.md => auto-scaling.md} | 0 content/hi/{canary_deployment.md => canary-deployment.md} | 0 content/hi/{cloud_native_tech.md => cloud-native-tech.md} | 0 content/hi/{continuous_delivery.md => continuous-delivery.md} | 0 .../hi/{continuous_integration.md => continuous-integration.md} | 0 ...gile_software_development.md => agile-software-development.md} | 0 content/it/{cloud_native_tech.md => cloud-native-tech.md} | 0 .../it/{infrastructure_as_code.md => infrastructure-as-code.md} | 0 content/it/{managed_services.md => managed-services.md} | 0 content/it/{platform_as_a_service.md => platform-as-a-service.md} | 0 ...reliability_engineering.md => site-reliability-engineering.md} | 0 content/it/{virtual_machine.md => virtual-machine.md} | 0 content/ko/{cloud_computing.md => cloud-computing.md} | 0 content/ko/{cloud_native_apps.md => cloud-native-apps.md} | 0 content/ko/{cloud_native_tech.md => cloud-native-tech.md} | 0 content/ko/{monolithic_apps.md => monolithic-apps.md} | 0 content/ko/{service_mesh.md => service-mesh.md} | 0 content/ko/{virtual_machine.md => virtual-machine.md} | 0 ...gile_software_development.md => agile-software-development.md} | 0 content/pt-br/{api_gateway.md => api-gateway.md} | 0 ...gramming_interface.md => application-programming-interface.md} | 0 content/pt-br/{auto_scaling.md => auto-scaling.md} | 0 content/pt-br/{bare_metal_machine.md => bare-metal-machine.md} | 0 .../pt-br/{blue_green_deployment.md => blue-green-deployment.md} | 0 content/pt-br/{canary_deployment.md => canary-deployment.md} | 0 ...lient_server_architecture.md => client-server-architecture.md} | 0 content/pt-br/{cloud_native_apps.md => cloud-native-apps.md} | 0 .../pt-br/{cloud_native_security.md => cloud-native-security.md} | 0 content/pt-br/{continuous_delivery.md => continuous-delivery.md} | 0 .../{continuous_integration.md => continuous-integration.md} | 0 .../zh-cn/{blue_green_deployment.md => blue-green-deployment.md} | 0 content/zh-cn/{canary_deployment.md => canary-deployment.md} | 0 content/zh-cn/{cloud_computing.md => cloud-computing.md} | 0 content/zh-cn/{cloud_native_apps.md => cloud-native-apps.md} | 0 .../zh-cn/{cloud_native_security.md => cloud-native-security.md} | 0 content/zh-cn/{cloud_native_tech.md => cloud-native-tech.md} | 0 .../{containers_as_a_service.md => containers-as-a-service.md} | 0 content/zh-cn/{continuous_delivery.md => continuous-delivery.md} | 0 .../{continuous_integration.md => continuous-integration.md} | 0 content/zh-cn/{data_center.md => data-center.md} | 0 content/zh-cn/{distributed_apps.md => distributed-apps.md} | 0 content/zh-cn/{distributed_systems.md => distributed-systems.md} | 0 content/zh-cn/{load_balancer.md => load-balancer.md} | 0 content/zh-cn/{monolithic_apps.md => monolithic-apps.md} | 0 content/zh-cn/{service_mesh.md => service-mesh.md} | 0 content/zh-cn/{service_proxy.md => service-proxy.md} | 0 content/zh-cn/{virtual_machine.md => virtual-machine.md} | 0 .../{zero_trust_architecture.md => zero-trust-architecture.md} | 0 111 files changed, 0 insertions(+), 0 deletions(-) rename content/bn/{agile_software_development.md => agile-software-development.md} (100%) rename content/bn/{application_programming_interface.md => application-programming-interface.md} (100%) rename content/bn/{cloud_computing.md => cloud-computing.md} (100%) rename content/bn/{cloud_native_security.md => cloud-native-security.md} (100%) rename content/bn/{cloud_native_tech.md => cloud-native-tech.md} (100%) rename content/bn/{software_as_a_service.md => software-as-a-service.md} (100%) rename content/en/{agile_software_development.md => agile-software-development.md} (100%) rename content/en/{api_gateway.md => api-gateway.md} (100%) rename content/en/{application_programming_interface.md => application-programming-interface.md} (100%) rename content/en/{auto_scaling.md => auto-scaling.md} (100%) rename content/en/{bare_metal_machine.md => bare-metal-machine.md} (100%) rename content/en/{blue_green_deployment.md => blue-green-deployment.md} (100%) rename content/en/{canary_deployment.md => canary-deployment.md} (100%) rename content/en/{chaos_engineering.md => chaos-engineering.md} (100%) rename content/en/{client_server_architecture.md => client-server-architecture.md} (100%) rename content/en/{cloud_computing.md => cloud-computing.md} (100%) rename content/en/{cloud_native_apps.md => cloud-native-apps.md} (100%) rename content/en/{cloud_native_security.md => cloud-native-security.md} (100%) rename content/en/{cloud_native_tech.md => cloud-native-tech.md} (100%) rename content/en/{containers_as_a_service.md => containers-as-a-service.md} (100%) rename content/en/{continuous_delivery.md => continuous-delivery.md} (100%) rename content/en/{continuous_deployment.md => continuous-deployment.md} (100%) rename content/en/{continuous_integration.md => continuous-integration.md} (100%) rename content/en/{data_center.md => data-center.md} (100%) rename content/en/{database_as_a_service.md => database-as-a-service.md} (100%) rename content/en/{distributed_apps.md => distributed-apps.md} (100%) rename content/en/{distributed_systems.md => distributed-systems.md} (100%) rename content/en/{function_as_a_service.md => function-as-a-service.md} (100%) rename content/en/{horizontal_scaling.md => horizontal-scaling.md} (100%) rename content/en/{immutable_infrastructure.md => immutable-infrastructure.md} (100%) rename content/en/{infrastructure_as_a_service.md => infrastructure-as-a-service.md} (100%) rename content/en/{infrastructure_as_code.md => infrastructure-as-code.md} (100%) rename content/en/{load_balancer.md => load-balancer.md} (100%) rename content/en/{loosely_coupled_architecture.md => loosely-coupled-architecture.md} (100%) rename content/en/{managed_services.md => managed-services.md} (100%) rename content/en/{monolithic_apps.md => monolithic-apps.md} (100%) rename content/en/{mTLS (Mutual Transport Layer Security).md => mutual-transport-layer-security.md} (100%) rename content/en/{platform_as_a_service.md => platform-as-a-service.md} (100%) rename content/en/{policy_as_code.md => policy-as-code.md} (100%) rename content/en/{security_chaos_engineering.md => security-chaos-engineering.md} (100%) rename content/en/{self_healing.md => self-healing.md} (100%) rename content/en/{service_discovery.md => service-discovery.md} (100%) rename content/en/{service_mesh.md => service-mesh.md} (100%) rename content/en/{service_proxy.md => service-proxy.md} (100%) rename content/en/{shift_left.md => shift-left.md} (100%) rename content/en/{site_reliability_engineering.md => site-reliability-engineering.md} (100%) rename content/en/{software_as_a_service.md => software-as-a-service.md} (100%) rename content/en/{stateful_apps.md => stateful-apps.md} (100%) rename content/en/{stateless_apps.md => stateless-apps.md} (100%) rename content/en/{tightly_coupled_architectures.md => tightly-coupled-architectures.md} (100%) rename content/en/{TLS(Transport Layer Security).md => transport-layer-security.md} (100%) rename content/en/{versioncontrol.md => version-control.md} (100%) rename content/en/{vertical_scaling.md => vertical-scaling.md} (100%) rename content/en/{virtual_machine.md => virtual-machine.md} (100%) rename content/en/{zero_trust_architecture.md => zero-trust-architecture.md} (100%) rename content/es/{agile_software_development.md => agile-software-development.md} (100%) rename content/es/{api_gateway.md => api-gateway.md} (100%) rename content/es/{bare_metal_machine.md => bare-metal-machine.md} (100%) rename content/es/{blue_green_deployment.md => blue-green-deployment.md} (100%) rename content/es/{cloud_computing.md => cloud-computing.md} (100%) rename content/es/{infrastructure_as_code.md => infrastructure-as-code.md} (100%) rename content/es/{load_balancer.md => load-balancer.md} (100%) rename content/hi/{agile_software_development.md => agile-software-development.md} (100%) rename content/hi/{auto_scaling.md => auto-scaling.md} (100%) rename content/hi/{canary_deployment.md => canary-deployment.md} (100%) rename content/hi/{cloud_native_tech.md => cloud-native-tech.md} (100%) rename content/hi/{continuous_delivery.md => continuous-delivery.md} (100%) rename content/hi/{continuous_integration.md => continuous-integration.md} (100%) rename content/it/{agile_software_development.md => agile-software-development.md} (100%) rename content/it/{cloud_native_tech.md => cloud-native-tech.md} (100%) rename content/it/{infrastructure_as_code.md => infrastructure-as-code.md} (100%) rename content/it/{managed_services.md => managed-services.md} (100%) rename content/it/{platform_as_a_service.md => platform-as-a-service.md} (100%) rename content/it/{site_reliability_engineering.md => site-reliability-engineering.md} (100%) rename content/it/{virtual_machine.md => virtual-machine.md} (100%) rename content/ko/{cloud_computing.md => cloud-computing.md} (100%) rename content/ko/{cloud_native_apps.md => cloud-native-apps.md} (100%) rename content/ko/{cloud_native_tech.md => cloud-native-tech.md} (100%) rename content/ko/{monolithic_apps.md => monolithic-apps.md} (100%) rename content/ko/{service_mesh.md => service-mesh.md} (100%) rename content/ko/{virtual_machine.md => virtual-machine.md} (100%) rename content/pt-br/{agile_software_development.md => agile-software-development.md} (100%) rename content/pt-br/{api_gateway.md => api-gateway.md} (100%) rename content/pt-br/{application_programming_interface.md => application-programming-interface.md} (100%) rename content/pt-br/{auto_scaling.md => auto-scaling.md} (100%) rename content/pt-br/{bare_metal_machine.md => bare-metal-machine.md} (100%) rename content/pt-br/{blue_green_deployment.md => blue-green-deployment.md} (100%) rename content/pt-br/{canary_deployment.md => canary-deployment.md} (100%) rename content/pt-br/{client_server_architecture.md => client-server-architecture.md} (100%) rename content/pt-br/{cloud_native_apps.md => cloud-native-apps.md} (100%) rename content/pt-br/{cloud_native_security.md => cloud-native-security.md} (100%) rename content/pt-br/{continuous_delivery.md => continuous-delivery.md} (100%) rename content/pt-br/{continuous_integration.md => continuous-integration.md} (100%) rename content/zh-cn/{blue_green_deployment.md => blue-green-deployment.md} (100%) rename content/zh-cn/{canary_deployment.md => canary-deployment.md} (100%) rename content/zh-cn/{cloud_computing.md => cloud-computing.md} (100%) rename content/zh-cn/{cloud_native_apps.md => cloud-native-apps.md} (100%) rename content/zh-cn/{cloud_native_security.md => cloud-native-security.md} (100%) rename content/zh-cn/{cloud_native_tech.md => cloud-native-tech.md} (100%) rename content/zh-cn/{containers_as_a_service.md => containers-as-a-service.md} (100%) rename content/zh-cn/{continuous_delivery.md => continuous-delivery.md} (100%) rename content/zh-cn/{continuous_integration.md => continuous-integration.md} (100%) rename content/zh-cn/{data_center.md => data-center.md} (100%) rename content/zh-cn/{distributed_apps.md => distributed-apps.md} (100%) rename content/zh-cn/{distributed_systems.md => distributed-systems.md} (100%) rename content/zh-cn/{load_balancer.md => load-balancer.md} (100%) rename content/zh-cn/{monolithic_apps.md => monolithic-apps.md} (100%) rename content/zh-cn/{service_mesh.md => service-mesh.md} (100%) rename content/zh-cn/{service_proxy.md => service-proxy.md} (100%) rename content/zh-cn/{virtual_machine.md => virtual-machine.md} (100%) rename content/zh-cn/{zero_trust_architecture.md => zero-trust-architecture.md} (100%) diff --git a/content/bn/agile_software_development.md b/content/bn/agile-software-development.md similarity index 100% rename from content/bn/agile_software_development.md rename to content/bn/agile-software-development.md diff --git a/content/bn/application_programming_interface.md b/content/bn/application-programming-interface.md similarity index 100% rename from content/bn/application_programming_interface.md rename to content/bn/application-programming-interface.md diff --git a/content/bn/cloud_computing.md b/content/bn/cloud-computing.md similarity index 100% rename from content/bn/cloud_computing.md rename to content/bn/cloud-computing.md diff --git a/content/bn/cloud_native_security.md b/content/bn/cloud-native-security.md similarity index 100% rename from content/bn/cloud_native_security.md rename to content/bn/cloud-native-security.md diff --git a/content/bn/cloud_native_tech.md b/content/bn/cloud-native-tech.md similarity index 100% rename from content/bn/cloud_native_tech.md rename to content/bn/cloud-native-tech.md diff --git a/content/bn/software_as_a_service.md b/content/bn/software-as-a-service.md similarity index 100% rename from content/bn/software_as_a_service.md rename to content/bn/software-as-a-service.md diff --git a/content/en/agile_software_development.md b/content/en/agile-software-development.md similarity index 100% rename from content/en/agile_software_development.md rename to content/en/agile-software-development.md diff --git a/content/en/api_gateway.md b/content/en/api-gateway.md similarity index 100% rename from content/en/api_gateway.md rename to content/en/api-gateway.md diff --git a/content/en/application_programming_interface.md b/content/en/application-programming-interface.md similarity index 100% rename from content/en/application_programming_interface.md rename to content/en/application-programming-interface.md diff --git a/content/en/auto_scaling.md b/content/en/auto-scaling.md similarity index 100% rename from content/en/auto_scaling.md rename to content/en/auto-scaling.md diff --git a/content/en/bare_metal_machine.md b/content/en/bare-metal-machine.md similarity index 100% rename from content/en/bare_metal_machine.md rename to content/en/bare-metal-machine.md diff --git a/content/en/blue_green_deployment.md b/content/en/blue-green-deployment.md similarity index 100% rename from content/en/blue_green_deployment.md rename to content/en/blue-green-deployment.md diff --git a/content/en/canary_deployment.md b/content/en/canary-deployment.md similarity index 100% rename from content/en/canary_deployment.md rename to content/en/canary-deployment.md diff --git a/content/en/chaos_engineering.md b/content/en/chaos-engineering.md similarity index 100% rename from content/en/chaos_engineering.md rename to content/en/chaos-engineering.md diff --git a/content/en/client_server_architecture.md b/content/en/client-server-architecture.md similarity index 100% rename from content/en/client_server_architecture.md rename to content/en/client-server-architecture.md diff --git a/content/en/cloud_computing.md b/content/en/cloud-computing.md similarity index 100% rename from content/en/cloud_computing.md rename to content/en/cloud-computing.md diff --git a/content/en/cloud_native_apps.md b/content/en/cloud-native-apps.md similarity index 100% rename from content/en/cloud_native_apps.md rename to content/en/cloud-native-apps.md diff --git a/content/en/cloud_native_security.md b/content/en/cloud-native-security.md similarity index 100% rename from content/en/cloud_native_security.md rename to content/en/cloud-native-security.md diff --git a/content/en/cloud_native_tech.md b/content/en/cloud-native-tech.md similarity index 100% rename from content/en/cloud_native_tech.md rename to content/en/cloud-native-tech.md diff --git a/content/en/containers_as_a_service.md b/content/en/containers-as-a-service.md similarity index 100% rename from content/en/containers_as_a_service.md rename to content/en/containers-as-a-service.md diff --git a/content/en/continuous_delivery.md b/content/en/continuous-delivery.md similarity index 100% rename from content/en/continuous_delivery.md rename to content/en/continuous-delivery.md diff --git a/content/en/continuous_deployment.md b/content/en/continuous-deployment.md similarity index 100% rename from content/en/continuous_deployment.md rename to content/en/continuous-deployment.md diff --git a/content/en/continuous_integration.md b/content/en/continuous-integration.md similarity index 100% rename from content/en/continuous_integration.md rename to content/en/continuous-integration.md diff --git a/content/en/data_center.md b/content/en/data-center.md similarity index 100% rename from content/en/data_center.md rename to content/en/data-center.md diff --git a/content/en/database_as_a_service.md b/content/en/database-as-a-service.md similarity index 100% rename from content/en/database_as_a_service.md rename to content/en/database-as-a-service.md diff --git a/content/en/distributed_apps.md b/content/en/distributed-apps.md similarity index 100% rename from content/en/distributed_apps.md rename to content/en/distributed-apps.md diff --git a/content/en/distributed_systems.md b/content/en/distributed-systems.md similarity index 100% rename from content/en/distributed_systems.md rename to content/en/distributed-systems.md diff --git a/content/en/function_as_a_service.md b/content/en/function-as-a-service.md similarity index 100% rename from content/en/function_as_a_service.md rename to content/en/function-as-a-service.md diff --git a/content/en/horizontal_scaling.md b/content/en/horizontal-scaling.md similarity index 100% rename from content/en/horizontal_scaling.md rename to content/en/horizontal-scaling.md diff --git a/content/en/immutable_infrastructure.md b/content/en/immutable-infrastructure.md similarity index 100% rename from content/en/immutable_infrastructure.md rename to content/en/immutable-infrastructure.md diff --git a/content/en/infrastructure_as_a_service.md b/content/en/infrastructure-as-a-service.md similarity index 100% rename from content/en/infrastructure_as_a_service.md rename to content/en/infrastructure-as-a-service.md diff --git a/content/en/infrastructure_as_code.md b/content/en/infrastructure-as-code.md similarity index 100% rename from content/en/infrastructure_as_code.md rename to content/en/infrastructure-as-code.md diff --git a/content/en/load_balancer.md b/content/en/load-balancer.md similarity index 100% rename from content/en/load_balancer.md rename to content/en/load-balancer.md diff --git a/content/en/loosely_coupled_architecture.md b/content/en/loosely-coupled-architecture.md similarity index 100% rename from content/en/loosely_coupled_architecture.md rename to content/en/loosely-coupled-architecture.md diff --git a/content/en/managed_services.md b/content/en/managed-services.md similarity index 100% rename from content/en/managed_services.md rename to content/en/managed-services.md diff --git a/content/en/monolithic_apps.md b/content/en/monolithic-apps.md similarity index 100% rename from content/en/monolithic_apps.md rename to content/en/monolithic-apps.md diff --git a/content/en/mTLS (Mutual Transport Layer Security).md b/content/en/mutual-transport-layer-security.md similarity index 100% rename from content/en/mTLS (Mutual Transport Layer Security).md rename to content/en/mutual-transport-layer-security.md diff --git a/content/en/platform_as_a_service.md b/content/en/platform-as-a-service.md similarity index 100% rename from content/en/platform_as_a_service.md rename to content/en/platform-as-a-service.md diff --git a/content/en/policy_as_code.md b/content/en/policy-as-code.md similarity index 100% rename from content/en/policy_as_code.md rename to content/en/policy-as-code.md diff --git a/content/en/security_chaos_engineering.md b/content/en/security-chaos-engineering.md similarity index 100% rename from content/en/security_chaos_engineering.md rename to content/en/security-chaos-engineering.md diff --git a/content/en/self_healing.md b/content/en/self-healing.md similarity index 100% rename from content/en/self_healing.md rename to content/en/self-healing.md diff --git a/content/en/service_discovery.md b/content/en/service-discovery.md similarity index 100% rename from content/en/service_discovery.md rename to content/en/service-discovery.md diff --git a/content/en/service_mesh.md b/content/en/service-mesh.md similarity index 100% rename from content/en/service_mesh.md rename to content/en/service-mesh.md diff --git a/content/en/service_proxy.md b/content/en/service-proxy.md similarity index 100% rename from content/en/service_proxy.md rename to content/en/service-proxy.md diff --git a/content/en/shift_left.md b/content/en/shift-left.md similarity index 100% rename from content/en/shift_left.md rename to content/en/shift-left.md diff --git a/content/en/site_reliability_engineering.md b/content/en/site-reliability-engineering.md similarity index 100% rename from content/en/site_reliability_engineering.md rename to content/en/site-reliability-engineering.md diff --git a/content/en/software_as_a_service.md b/content/en/software-as-a-service.md similarity index 100% rename from content/en/software_as_a_service.md rename to content/en/software-as-a-service.md diff --git a/content/en/stateful_apps.md b/content/en/stateful-apps.md similarity index 100% rename from content/en/stateful_apps.md rename to content/en/stateful-apps.md diff --git a/content/en/stateless_apps.md b/content/en/stateless-apps.md similarity index 100% rename from content/en/stateless_apps.md rename to content/en/stateless-apps.md diff --git a/content/en/tightly_coupled_architectures.md b/content/en/tightly-coupled-architectures.md similarity index 100% rename from content/en/tightly_coupled_architectures.md rename to content/en/tightly-coupled-architectures.md diff --git a/content/en/TLS(Transport Layer Security).md b/content/en/transport-layer-security.md similarity index 100% rename from content/en/TLS(Transport Layer Security).md rename to content/en/transport-layer-security.md diff --git a/content/en/versioncontrol.md b/content/en/version-control.md similarity index 100% rename from content/en/versioncontrol.md rename to content/en/version-control.md diff --git a/content/en/vertical_scaling.md b/content/en/vertical-scaling.md similarity index 100% rename from content/en/vertical_scaling.md rename to content/en/vertical-scaling.md diff --git a/content/en/virtual_machine.md b/content/en/virtual-machine.md similarity index 100% rename from content/en/virtual_machine.md rename to content/en/virtual-machine.md diff --git a/content/en/zero_trust_architecture.md b/content/en/zero-trust-architecture.md similarity index 100% rename from content/en/zero_trust_architecture.md rename to content/en/zero-trust-architecture.md diff --git a/content/es/agile_software_development.md b/content/es/agile-software-development.md similarity index 100% rename from content/es/agile_software_development.md rename to content/es/agile-software-development.md diff --git a/content/es/api_gateway.md b/content/es/api-gateway.md similarity index 100% rename from content/es/api_gateway.md rename to content/es/api-gateway.md diff --git a/content/es/bare_metal_machine.md b/content/es/bare-metal-machine.md similarity index 100% rename from content/es/bare_metal_machine.md rename to content/es/bare-metal-machine.md diff --git a/content/es/blue_green_deployment.md b/content/es/blue-green-deployment.md similarity index 100% rename from content/es/blue_green_deployment.md rename to content/es/blue-green-deployment.md diff --git a/content/es/cloud_computing.md b/content/es/cloud-computing.md similarity index 100% rename from content/es/cloud_computing.md rename to content/es/cloud-computing.md diff --git a/content/es/infrastructure_as_code.md b/content/es/infrastructure-as-code.md similarity index 100% rename from content/es/infrastructure_as_code.md rename to content/es/infrastructure-as-code.md diff --git a/content/es/load_balancer.md b/content/es/load-balancer.md similarity index 100% rename from content/es/load_balancer.md rename to content/es/load-balancer.md diff --git a/content/hi/agile_software_development.md b/content/hi/agile-software-development.md similarity index 100% rename from content/hi/agile_software_development.md rename to content/hi/agile-software-development.md diff --git a/content/hi/auto_scaling.md b/content/hi/auto-scaling.md similarity index 100% rename from content/hi/auto_scaling.md rename to content/hi/auto-scaling.md diff --git a/content/hi/canary_deployment.md b/content/hi/canary-deployment.md similarity index 100% rename from content/hi/canary_deployment.md rename to content/hi/canary-deployment.md diff --git a/content/hi/cloud_native_tech.md b/content/hi/cloud-native-tech.md similarity index 100% rename from content/hi/cloud_native_tech.md rename to content/hi/cloud-native-tech.md diff --git a/content/hi/continuous_delivery.md b/content/hi/continuous-delivery.md similarity index 100% rename from content/hi/continuous_delivery.md rename to content/hi/continuous-delivery.md diff --git a/content/hi/continuous_integration.md b/content/hi/continuous-integration.md similarity index 100% rename from content/hi/continuous_integration.md rename to content/hi/continuous-integration.md diff --git a/content/it/agile_software_development.md b/content/it/agile-software-development.md similarity index 100% rename from content/it/agile_software_development.md rename to content/it/agile-software-development.md diff --git a/content/it/cloud_native_tech.md b/content/it/cloud-native-tech.md similarity index 100% rename from content/it/cloud_native_tech.md rename to content/it/cloud-native-tech.md diff --git a/content/it/infrastructure_as_code.md b/content/it/infrastructure-as-code.md similarity index 100% rename from content/it/infrastructure_as_code.md rename to content/it/infrastructure-as-code.md diff --git a/content/it/managed_services.md b/content/it/managed-services.md similarity index 100% rename from content/it/managed_services.md rename to content/it/managed-services.md diff --git a/content/it/platform_as_a_service.md b/content/it/platform-as-a-service.md similarity index 100% rename from content/it/platform_as_a_service.md rename to content/it/platform-as-a-service.md diff --git a/content/it/site_reliability_engineering.md b/content/it/site-reliability-engineering.md similarity index 100% rename from content/it/site_reliability_engineering.md rename to content/it/site-reliability-engineering.md diff --git a/content/it/virtual_machine.md b/content/it/virtual-machine.md similarity index 100% rename from content/it/virtual_machine.md rename to content/it/virtual-machine.md diff --git a/content/ko/cloud_computing.md b/content/ko/cloud-computing.md similarity index 100% rename from content/ko/cloud_computing.md rename to content/ko/cloud-computing.md diff --git a/content/ko/cloud_native_apps.md b/content/ko/cloud-native-apps.md similarity index 100% rename from content/ko/cloud_native_apps.md rename to content/ko/cloud-native-apps.md diff --git a/content/ko/cloud_native_tech.md b/content/ko/cloud-native-tech.md similarity index 100% rename from content/ko/cloud_native_tech.md rename to content/ko/cloud-native-tech.md diff --git a/content/ko/monolithic_apps.md b/content/ko/monolithic-apps.md similarity index 100% rename from content/ko/monolithic_apps.md rename to content/ko/monolithic-apps.md diff --git a/content/ko/service_mesh.md b/content/ko/service-mesh.md similarity index 100% rename from content/ko/service_mesh.md rename to content/ko/service-mesh.md diff --git a/content/ko/virtual_machine.md b/content/ko/virtual-machine.md similarity index 100% rename from content/ko/virtual_machine.md rename to content/ko/virtual-machine.md diff --git a/content/pt-br/agile_software_development.md b/content/pt-br/agile-software-development.md similarity index 100% rename from content/pt-br/agile_software_development.md rename to content/pt-br/agile-software-development.md diff --git a/content/pt-br/api_gateway.md b/content/pt-br/api-gateway.md similarity index 100% rename from content/pt-br/api_gateway.md rename to content/pt-br/api-gateway.md diff --git a/content/pt-br/application_programming_interface.md b/content/pt-br/application-programming-interface.md similarity index 100% rename from content/pt-br/application_programming_interface.md rename to content/pt-br/application-programming-interface.md diff --git a/content/pt-br/auto_scaling.md b/content/pt-br/auto-scaling.md similarity index 100% rename from content/pt-br/auto_scaling.md rename to content/pt-br/auto-scaling.md diff --git a/content/pt-br/bare_metal_machine.md b/content/pt-br/bare-metal-machine.md similarity index 100% rename from content/pt-br/bare_metal_machine.md rename to content/pt-br/bare-metal-machine.md diff --git a/content/pt-br/blue_green_deployment.md b/content/pt-br/blue-green-deployment.md similarity index 100% rename from content/pt-br/blue_green_deployment.md rename to content/pt-br/blue-green-deployment.md diff --git a/content/pt-br/canary_deployment.md b/content/pt-br/canary-deployment.md similarity index 100% rename from content/pt-br/canary_deployment.md rename to content/pt-br/canary-deployment.md diff --git a/content/pt-br/client_server_architecture.md b/content/pt-br/client-server-architecture.md similarity index 100% rename from content/pt-br/client_server_architecture.md rename to content/pt-br/client-server-architecture.md diff --git a/content/pt-br/cloud_native_apps.md b/content/pt-br/cloud-native-apps.md similarity index 100% rename from content/pt-br/cloud_native_apps.md rename to content/pt-br/cloud-native-apps.md diff --git a/content/pt-br/cloud_native_security.md b/content/pt-br/cloud-native-security.md similarity index 100% rename from content/pt-br/cloud_native_security.md rename to content/pt-br/cloud-native-security.md diff --git a/content/pt-br/continuous_delivery.md b/content/pt-br/continuous-delivery.md similarity index 100% rename from content/pt-br/continuous_delivery.md rename to content/pt-br/continuous-delivery.md diff --git a/content/pt-br/continuous_integration.md b/content/pt-br/continuous-integration.md similarity index 100% rename from content/pt-br/continuous_integration.md rename to content/pt-br/continuous-integration.md diff --git a/content/zh-cn/blue_green_deployment.md b/content/zh-cn/blue-green-deployment.md similarity index 100% rename from content/zh-cn/blue_green_deployment.md rename to content/zh-cn/blue-green-deployment.md diff --git a/content/zh-cn/canary_deployment.md b/content/zh-cn/canary-deployment.md similarity index 100% rename from content/zh-cn/canary_deployment.md rename to content/zh-cn/canary-deployment.md diff --git a/content/zh-cn/cloud_computing.md b/content/zh-cn/cloud-computing.md similarity index 100% rename from content/zh-cn/cloud_computing.md rename to content/zh-cn/cloud-computing.md diff --git a/content/zh-cn/cloud_native_apps.md b/content/zh-cn/cloud-native-apps.md similarity index 100% rename from content/zh-cn/cloud_native_apps.md rename to content/zh-cn/cloud-native-apps.md diff --git a/content/zh-cn/cloud_native_security.md b/content/zh-cn/cloud-native-security.md similarity index 100% rename from content/zh-cn/cloud_native_security.md rename to content/zh-cn/cloud-native-security.md diff --git a/content/zh-cn/cloud_native_tech.md b/content/zh-cn/cloud-native-tech.md similarity index 100% rename from content/zh-cn/cloud_native_tech.md rename to content/zh-cn/cloud-native-tech.md diff --git a/content/zh-cn/containers_as_a_service.md b/content/zh-cn/containers-as-a-service.md similarity index 100% rename from content/zh-cn/containers_as_a_service.md rename to content/zh-cn/containers-as-a-service.md diff --git a/content/zh-cn/continuous_delivery.md b/content/zh-cn/continuous-delivery.md similarity index 100% rename from content/zh-cn/continuous_delivery.md rename to content/zh-cn/continuous-delivery.md diff --git a/content/zh-cn/continuous_integration.md b/content/zh-cn/continuous-integration.md similarity index 100% rename from content/zh-cn/continuous_integration.md rename to content/zh-cn/continuous-integration.md diff --git a/content/zh-cn/data_center.md b/content/zh-cn/data-center.md similarity index 100% rename from content/zh-cn/data_center.md rename to content/zh-cn/data-center.md diff --git a/content/zh-cn/distributed_apps.md b/content/zh-cn/distributed-apps.md similarity index 100% rename from content/zh-cn/distributed_apps.md rename to content/zh-cn/distributed-apps.md diff --git a/content/zh-cn/distributed_systems.md b/content/zh-cn/distributed-systems.md similarity index 100% rename from content/zh-cn/distributed_systems.md rename to content/zh-cn/distributed-systems.md diff --git a/content/zh-cn/load_balancer.md b/content/zh-cn/load-balancer.md similarity index 100% rename from content/zh-cn/load_balancer.md rename to content/zh-cn/load-balancer.md diff --git a/content/zh-cn/monolithic_apps.md b/content/zh-cn/monolithic-apps.md similarity index 100% rename from content/zh-cn/monolithic_apps.md rename to content/zh-cn/monolithic-apps.md diff --git a/content/zh-cn/service_mesh.md b/content/zh-cn/service-mesh.md similarity index 100% rename from content/zh-cn/service_mesh.md rename to content/zh-cn/service-mesh.md diff --git a/content/zh-cn/service_proxy.md b/content/zh-cn/service-proxy.md similarity index 100% rename from content/zh-cn/service_proxy.md rename to content/zh-cn/service-proxy.md diff --git a/content/zh-cn/virtual_machine.md b/content/zh-cn/virtual-machine.md similarity index 100% rename from content/zh-cn/virtual_machine.md rename to content/zh-cn/virtual-machine.md diff --git a/content/zh-cn/zero_trust_architecture.md b/content/zh-cn/zero-trust-architecture.md similarity index 100% rename from content/zh-cn/zero_trust_architecture.md rename to content/zh-cn/zero-trust-architecture.md From bba3069b8258f2d1fde1df573633b179dbf72b0c Mon Sep 17 00:00:00 2001 From: Jihoon Seo Date: Thu, 2 Jun 2022 13:38:14 +0900 Subject: [PATCH 4/4] [all] Update relevant links Signed-off-by: Jihoon Seo --- content/bn/abstraction.md | 2 +- content/bn/cloud-native-security.md | 2 +- content/bn/cloud-native-tech.md | 2 +- content/bn/cluster.md | 4 ++-- content/bn/devops.md | 2 +- content/bn/style-guide/_index.md | 2 +- content/en/api-gateway.md | 2 +- content/en/auto-scaling.md | 4 ++-- content/en/bare-metal-machine.md | 8 ++++---- content/en/chaos-engineering.md | 4 ++-- content/en/cloud-native-apps.md | 6 +++--- content/en/cloud-native-security.md | 2 +- content/en/cloud-native-tech.md | 4 ++-- content/en/cluster.md | 4 ++-- content/en/containerization.md | 4 ++-- content/en/containers-as-a-service.md | 6 +++--- content/en/continuous-delivery.md | 6 +++--- content/en/continuous-deployment.md | 8 ++++---- content/en/continuous-integration.md | 6 +++--- content/en/data-center.md | 2 +- content/en/database-as-a-service.md | 2 +- content/en/devops.md | 2 +- content/en/devsecops.md | 2 +- content/en/distributed-apps.md | 2 +- content/en/distributed-systems.md | 2 +- content/en/function-as-a-service.md | 4 ++-- content/en/horizontal-scaling.md | 6 +++--- content/en/immutable-infrastructure.md | 4 ++-- content/en/infrastructure-as-a-service.md | 4 ++-- content/en/infrastructure-as-code.md | 4 ++-- content/en/kubernetes.md | 6 +++--- content/en/loosely-coupled-architecture.md | 2 +- content/en/managed-services.md | 2 +- content/en/microservices.md | 6 +++--- content/en/mutual-transport-layer-security.md | 2 +- content/en/nodes.md | 4 ++-- content/en/platform-as-a-service.md | 4 ++-- content/en/reliability.md | 4 ++-- content/en/scalability.md | 4 ++-- content/en/security-chaos-engineering.md | 4 ++-- content/en/serverless.md | 2 +- content/en/shift-left.md | 2 +- content/en/stateful-apps.md | 2 +- content/en/stateless-apps.md | 2 +- content/en/style-guide/_index.md | 2 +- content/en/tightly-coupled-architectures.md | 4 ++-- content/en/vertical-scaling.md | 8 ++++---- content/en/virtual-machine.md | 2 +- content/es/api-gateway.md | 2 +- content/es/bare-metal-machine.md | 4 ++-- content/es/devops.md | 2 +- content/es/infrastructure-as-code.md | 4 ++-- content/es/kubernetes.md | 6 +++--- content/es/style-guide/_index.md | 2 +- content/hi/cloud-native-tech.md | 2 +- content/hi/containerization.md | 2 +- content/hi/continuous-delivery.md | 2 +- content/hi/continuous-integration.md | 2 +- content/hi/devops.md | 2 +- content/hi/style-guide/_index.md | 2 +- content/it/cloud-native-tech.md | 4 ++-- content/it/cluster.md | 4 ++-- content/it/devops.md | 2 +- content/it/infrastructure-as-code.md | 2 +- content/it/managed-services.md | 4 ++-- content/it/microservices.md | 6 +++--- content/it/nodes.md | 4 ++-- content/it/platform-as-a-service.md | 2 +- content/it/style-guide/_index.md | 10 +++++----- content/it/virtual-machine.md | 2 +- content/ko/cloud-native-apps.md | 4 ++-- content/ko/cloud-native-tech.md | 2 +- content/ko/containerization.md | 2 +- content/ko/devops.md | 2 +- content/ko/microservices.md | 6 +++--- content/ko/style-guide/_index.md | 2 +- content/ko/virtual-machine.md | 4 ++-- content/pt-br/api-gateway.md | 2 +- content/pt-br/bare-metal-machine.md | 4 ++-- content/pt-br/cloud-native-apps.md | 4 ++-- content/pt-br/cloud-native-security.md | 2 +- content/pt-br/cluster.md | 6 +++--- content/pt-br/containerization.md | 2 +- content/pt-br/continuous-delivery.md | 2 +- content/pt-br/continuous-integration.md | 4 ++-- content/pt-br/devops.md | 2 +- content/pt-br/style-guide/_index.md | 2 +- content/zh-cn/cloud-native-apps.md | 4 ++-- content/zh-cn/cloud-native-security.md | 2 +- content/zh-cn/cloud-native-tech.md | 2 +- content/zh-cn/cluster.md | 4 ++-- content/zh-cn/containerization.md | 4 ++-- content/zh-cn/containers-as-a-service.md | 6 +++--- content/zh-cn/continuous-delivery.md | 2 +- content/zh-cn/continuous-integration.md | 2 +- content/zh-cn/data-center.md | 2 +- content/zh-cn/devops.md | 2 +- content/zh-cn/distributed-apps.md | 2 +- content/zh-cn/distributed-systems.md | 2 +- content/zh-cn/kubernetes.md | 6 +++--- content/zh-cn/microservices.md | 6 +++--- content/zh-cn/reliability.md | 2 +- content/zh-cn/scalability.md | 4 ++-- content/zh-cn/serverless.md | 2 +- content/zh-cn/style-guide/_index.md | 2 +- content/zh-cn/virtual-machine.md | 2 +- 106 files changed, 178 insertions(+), 178 deletions(-) diff --git a/content/bn/abstraction.md b/content/bn/abstraction.md index dd39686354..6784a1d358 100644 --- a/content/bn/abstraction.md +++ b/content/bn/abstraction.md @@ -4,6 +4,6 @@ status: Completed category: বৈশিষ্ট্য --- -কম্পিউটিং এর প্রেক্ষাপটে, অ্যাবস্ট্রাকশন অথবা বিমূর্ততা হল এক ধরনের উপস্থাপনা যেখানে সাধারণ ব্যবহারকারী এবং [সেবা](https://glossary.cncf.io/service/) ভোগকারীদের (কম্পিউটার প্রোগ্রাম অথবা মানুষ) কাছ থেকে সিস্টেমের জটিল এবং অপ্রয়োজনীয় বিষয়গুলি লুকিয়ে রাখা হয়, এভাবে সিস্টেমকে খুব সিম্পল ভাবে উপস্থাপন করা হয় ফলে সিস্টেমকে বুঝতেও সুবিধা হয়। একটি ভালো উদাহরণ হল আপনার ল্যাপটপের অপারেটিং সিস্টেম (OS)। এটি আপনার কম্পিউটার কিভাবে কাজ করে তার সমস্ত বিবরণ বিমূর্ত করে। আপনার সিপিইউ মেমোরি অথবা প্রোগ্রামগুলোকে কিভাবে পরিচালনা করতে হয় সে সম্পর্কে কিছু জানার দরকার নেই, আপনি শুধু আপনার অপারেটিং সিস্টেম চালান এবং আপনার OS নিজেই এই জটিল বিষয়গুলো পরিচালনা করে। OS কিভাবে কাজগুলো হ্যান্ডেল করে করে তা আপনার জানার দরকার নেই এবং সমস্ত বিবরণ এই OS "পর্দা" বা বিমূর্ততার পিছনে লুকানো রয়েছে। +কম্পিউটিং এর প্রেক্ষাপটে, অ্যাবস্ট্রাকশন অথবা বিমূর্ততা হল এক ধরনের উপস্থাপনা যেখানে সাধারণ ব্যবহারকারী এবং [সেবা](/service/) ভোগকারীদের (কম্পিউটার প্রোগ্রাম অথবা মানুষ) কাছ থেকে সিস্টেমের জটিল এবং অপ্রয়োজনীয় বিষয়গুলি লুকিয়ে রাখা হয়, এভাবে সিস্টেমকে খুব সিম্পল ভাবে উপস্থাপন করা হয় ফলে সিস্টেমকে বুঝতেও সুবিধা হয়। একটি ভালো উদাহরণ হল আপনার ল্যাপটপের অপারেটিং সিস্টেম (OS)। এটি আপনার কম্পিউটার কিভাবে কাজ করে তার সমস্ত বিবরণ বিমূর্ত করে। আপনার সিপিইউ মেমোরি অথবা প্রোগ্রামগুলোকে কিভাবে পরিচালনা করতে হয় সে সম্পর্কে কিছু জানার দরকার নেই, আপনি শুধু আপনার অপারেটিং সিস্টেম চালান এবং আপনার OS নিজেই এই জটিল বিষয়গুলো পরিচালনা করে। OS কিভাবে কাজগুলো হ্যান্ডেল করে করে তা আপনার জানার দরকার নেই এবং সমস্ত বিবরণ এই OS "পর্দা" বা বিমূর্ততার পিছনে লুকানো রয়েছে। সিস্টেমে সাধারণত একাধিক অ্যাবস্ট্রাকশন স্তর থাকে। এটি সিস্টেম ডেভেলপমেন্ট কে অনেক সহজ করে তোলে। প্রোগ্রামিং এর সময় ডেভলপাররা নির্দিষ্ট অ্যাবস্ট্রাকশন স্তরের সাথে সামঞ্জস্য রেখে সব কিছু তৈরি করে এবং অন্যান্য অন্তর্নিহিত সুনির্দিষ্ট বিষয়গুলো নিয়ে তাদের আর চিন্তা করতে হয় না যা খুবই জটিল হতে পারত। কোন কিছু যদি কোনো নির্দিষ্ট অ্যাবস্ট্রাকশন স্তরের সাথে কাজ করে তবে তা সিস্টেমের সাথে কাজ করবে — নিচের স্তরগুলো তে যাই থাকুক না কেন। diff --git a/content/bn/cloud-native-security.md b/content/bn/cloud-native-security.md index 7ccd4a023c..a7e8a921ea 100644 --- a/content/bn/cloud-native-security.md +++ b/content/bn/cloud-native-security.md @@ -6,7 +6,7 @@ category: ধারণা ## এটা কি -ক্লাউড নেটিভ সিকিউরিটি এমন একটি পদ্ধতি যা [ক্লাউড নেটিভ অ্যাপ্লিকেশন](/cloud_native_apps/) এ নিরাপত্তা তৈরি করে। এটি নিশ্চিত করে যে নিরাপত্তা উন্নয়ন থেকে উৎপাদন পর্যন্ত সমগ্র অ্যাপ্লিকেশন জীবনচক্রের অংশ। ক্লাউড নেটিভ সিকিউরিটি ক্লাউড নেটিভ এনভায়রনমেন্টের বিবরণ, যথা দ্রুত কোড পরিবর্তন এবং অত্যন্ত ক্ষণস্থায়ী অবকাঠামোর সাথে খাপ খাওয়ানোর সময় প্রথাগত নিরাপত্তা মডেলের মতো একই মান নিশ্চিত করতে চায়। ক্লাউড নেটিভ নিরাপত্তা [DevSecOps](/devsecops/) নামক অনুশীলনের সাথে অত্যন্ত সম্পর্কিত। +ক্লাউড নেটিভ সিকিউরিটি এমন একটি পদ্ধতি যা [ক্লাউড নেটিভ অ্যাপ্লিকেশন](/cloud-native-apps/) এ নিরাপত্তা তৈরি করে। এটি নিশ্চিত করে যে নিরাপত্তা উন্নয়ন থেকে উৎপাদন পর্যন্ত সমগ্র অ্যাপ্লিকেশন জীবনচক্রের অংশ। ক্লাউড নেটিভ সিকিউরিটি ক্লাউড নেটিভ এনভায়রনমেন্টের বিবরণ, যথা দ্রুত কোড পরিবর্তন এবং অত্যন্ত ক্ষণস্থায়ী অবকাঠামোর সাথে খাপ খাওয়ানোর সময় প্রথাগত নিরাপত্তা মডেলের মতো একই মান নিশ্চিত করতে চায়। ক্লাউড নেটিভ নিরাপত্তা [DevSecOps](/devsecops/) নামক অনুশীলনের সাথে অত্যন্ত সম্পর্কিত। ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে diff --git a/content/bn/cloud-native-tech.md b/content/bn/cloud-native-tech.md index eb5cc311ed..057a7b7b3a 100644 --- a/content/bn/cloud-native-tech.md +++ b/content/bn/cloud-native-tech.md @@ -6,7 +6,7 @@ category: ধারণা ## এটা কি -ক্লাউড নেটিভ টেকনোলজি, ক্লাউড নেটিভ স্ট্যাক হিসেবেও উল্লেখ করা হয়, [ক্লাউড নেটিভ অ্যাপ্লিকেশন](/cloud_native_apps/) তৈরি করতে ব্যবহৃত প্রযুক্তি। সরকারী, প্রাইভেট এবং হাইব্রিড ক্লাউডের মতো আধুনিক, গতিশীল পরিবেশে মাপযোগ্য অ্যাপ্লিকেশনগুলি তৈরি এবং চালানোর জন্য সংস্থাগুলিকে সক্ষম করে, তারা 'ক্লাউডের প্রতিশ্রুতি' বজায় রাখে এবং ক্লাউড কম্পিউটিং সুবিধাগুলি তাদের সম্পূর্ণরূপে লাভ করে। ক্লাউড কম্পিউটিং এবং কন্টেইনার, সার্ভিস মেশ, মাইক্রোসার্ভিসেস এবং অপরিবর্তনীয় অবকাঠামোর ক্ষমতাকে কাজে লাগানোর জন্য গ্রাউন্ড আপ থেকে ডিজাইন করা হয়েছে এই পদ্ধতির উদাহরণ। +ক্লাউড নেটিভ টেকনোলজি, ক্লাউড নেটিভ স্ট্যাক হিসেবেও উল্লেখ করা হয়, [ক্লাউড নেটিভ অ্যাপ্লিকেশন](/cloud-native-apps/) তৈরি করতে ব্যবহৃত প্রযুক্তি। সরকারী, প্রাইভেট এবং হাইব্রিড ক্লাউডের মতো আধুনিক, গতিশীল পরিবেশে মাপযোগ্য অ্যাপ্লিকেশনগুলি তৈরি এবং চালানোর জন্য সংস্থাগুলিকে সক্ষম করে, তারা 'ক্লাউডের প্রতিশ্রুতি' বজায় রাখে এবং ক্লাউড কম্পিউটিং সুবিধাগুলি তাদের সম্পূর্ণরূপে লাভ করে। ক্লাউড কম্পিউটিং এবং কন্টেইনার, সার্ভিস মেশ, মাইক্রোসার্ভিসেস এবং অপরিবর্তনীয় অবকাঠামোর ক্ষমতাকে কাজে লাগানোর জন্য গ্রাউন্ড আপ থেকে ডিজাইন করা হয়েছে এই পদ্ধতির উদাহরণ। ## এটা যেসব সমস্যাতে ফোকাস করে diff --git a/content/bn/cluster.md b/content/bn/cluster.md index 4b2847c117..a2650a685b 100644 --- a/content/bn/cluster.md +++ b/content/bn/cluster.md @@ -10,8 +10,8 @@ category: ধারণা ## এটা যেসব সমস্যাতে দৃষ্টিপাত করে -একটি একক কম্পিউটারে চলা সফ্টওয়্যার ব্যর্থতার একটি একক পয়েন্ট উপস্থাপন করে — যদি সেই কম্পিউটারটি ক্র্যাশ হয়ে যায়, বা কেউ দুর্ঘটনাক্রমে পাওয়ার কেবলটি আনপ্লাগ করে, তবে কিছু ব্যবসা-সংক্রান্ত সমস্যা সিস্টেম অফলাইনে নেওয়া হতে পারে। এই কারণেই আধুনিক সফ্টওয়্যারগুলি সাধারণত [ডিস্ট্রিবিউটেড অ্যাপ্লিকেশন(Distributed application)](/distributed_apps/) হিসাবে তৈরি করা হয়, ক্লাস্টার হিসাবে একসাথে গ্রুপ করা হয়। +একটি একক কম্পিউটারে চলা সফ্টওয়্যার ব্যর্থতার একটি একক পয়েন্ট উপস্থাপন করে — যদি সেই কম্পিউটারটি ক্র্যাশ হয়ে যায়, বা কেউ দুর্ঘটনাক্রমে পাওয়ার কেবলটি আনপ্লাগ করে, তবে কিছু ব্যবসা-সংক্রান্ত সমস্যা সিস্টেম অফলাইনে নেওয়া হতে পারে। এই কারণেই আধুনিক সফ্টওয়্যারগুলি সাধারণত [ডিস্ট্রিবিউটেড অ্যাপ্লিকেশন(Distributed application)](/distributed-apps/) হিসাবে তৈরি করা হয়, ক্লাস্টার হিসাবে একসাথে গ্রুপ করা হয়। ## এটা কিভাবে সাহায্য করে -ক্লাস্টারড, বিতরণ করা অ্যাপ্লিকেশনগুলি একাধিক মেশিন জুড়ে চলে, একটি একক বিন্দু ব্যর্থতা দূর করে। কিন্তু বিতরণ সিস্টেম নির্মাণ সত্যিই কঠিন. প্রকৃতপক্ষে, এটি তার নিজের অধিকারে একটি কম্পিউটার বিজ্ঞান শৃঙ্খলা। বিশ্বব্যাপী সিস্টেমের প্রয়োজনীয়তা এবং বছরের পর বছর ট্রায়াল এবং ত্রুটি একটি নতুন ধরণের প্রযুক্তিগত স্ট্যাকের বিকাশের দিকে পরিচালিত করে: [ক্লাউড নেটিভ টেকনোলজি(Cloud Native Technology)](/bn/cloud_native_tech/)। এই নতুন প্রযুক্তিগুলি হল বিল্ডিং ব্লক যা বিতরণ করা সিস্টেমগুলির পরিচালনা এবং নির্মাণকে সহজ করে তোলে। +ক্লাস্টারড, বিতরণ করা অ্যাপ্লিকেশনগুলি একাধিক মেশিন জুড়ে চলে, একটি একক বিন্দু ব্যর্থতা দূর করে। কিন্তু বিতরণ সিস্টেম নির্মাণ সত্যিই কঠিন. প্রকৃতপক্ষে, এটি তার নিজের অধিকারে একটি কম্পিউটার বিজ্ঞান শৃঙ্খলা। বিশ্বব্যাপী সিস্টেমের প্রয়োজনীয়তা এবং বছরের পর বছর ট্রায়াল এবং ত্রুটি একটি নতুন ধরণের প্রযুক্তিগত স্ট্যাকের বিকাশের দিকে পরিচালিত করে: [ক্লাউড নেটিভ টেকনোলজি(Cloud Native Technology)](/bn/cloud-native-tech/)। এই নতুন প্রযুক্তিগুলি হল বিল্ডিং ব্লক যা বিতরণ করা সিস্টেমগুলির পরিচালনা এবং নির্মাণকে সহজ করে তোলে। diff --git a/content/bn/devops.md b/content/bn/devops.md index 700b9d9119..116de1a2c3 100644 --- a/content/bn/devops.md +++ b/content/bn/devops.md @@ -10,7 +10,7 @@ category: ধারণা ## এটি যেই সমস্যাটি নির্দেশ করে -ঐতিহ্যগতভাবে, জটিল সংস্থা [শক্তভাবে মিলিত](/tightly_coupled_architectures/) ও [মনোলিথিক অ্যাপস](/monolithic_apps/) এর কাজ সাধারণত একাধিক দলের মধ্যে খণ্ডিত ছিল । এটি অসংখ্য হ্যান্ডঅফ এবং দীর্ঘ পরবর্তী সময় নেয়। প্রতিবার যখনই একটি উপাদান বা আপডেট প্রস্তুত ছিল, এটি পরবর্তী দলের জন্য একটি সারিতে স্থাপন করা হয়েছিল। যেহেতু ব্যক্তিরা কেবলমাত্র প্রকল্পের একটি ছোট অংশে কাজ করেছিল, এই পদ্ধতির ফলে মালিকানার অভাব দেখা দেয়। তাদের লক্ষ্য ছিল পরবর্তী দলের কাছে কাজটি পৌঁছে দেওয়া, গ্রাহকের কাছে সঠিক কার্যকারিতা সরবরাহ না করা যাকে অগ্রাধিকারগুলির একটি স্পষ্ট বিভ্রান্তি হিসেবে বলা যায়। +ঐতিহ্যগতভাবে, জটিল সংস্থা [শক্তভাবে মিলিত](/tightly-coupled-architectures/) ও [মনোলিথিক অ্যাপস](/monolithic-apps/) এর কাজ সাধারণত একাধিক দলের মধ্যে খণ্ডিত ছিল । এটি অসংখ্য হ্যান্ডঅফ এবং দীর্ঘ পরবর্তী সময় নেয়। প্রতিবার যখনই একটি উপাদান বা আপডেট প্রস্তুত ছিল, এটি পরবর্তী দলের জন্য একটি সারিতে স্থাপন করা হয়েছিল। যেহেতু ব্যক্তিরা কেবলমাত্র প্রকল্পের একটি ছোট অংশে কাজ করেছিল, এই পদ্ধতির ফলে মালিকানার অভাব দেখা দেয়। তাদের লক্ষ্য ছিল পরবর্তী দলের কাছে কাজটি পৌঁছে দেওয়া, গ্রাহকের কাছে সঠিক কার্যকারিতা সরবরাহ না করা যাকে অগ্রাধিকারগুলির একটি স্পষ্ট বিভ্রান্তি হিসেবে বলা যায়। কোডটি শেষ পর্যন্ত আসার সময় পর্যন্ত, এটি এত বেশি ডেভেলপারের মধ্য দিয়ে গিয়েছিল, এত সারিতে অপেক্ষা করেছিল যে কোডটি কাজ না করলে সমস্যার উৎস খুঁজে বের করা কঠিন ছিল। ডেভওপস এই পদ্ধতিকে উল্টো করে দেয়। diff --git a/content/bn/style-guide/_index.md b/content/bn/style-guide/_index.md index 089d0c06ba..233c65edc3 100644 --- a/content/bn/style-guide/_index.md +++ b/content/bn/style-guide/_index.md @@ -114,7 +114,7 @@ category: ধারণা আপনার সংজ্ঞায় ব্যবহৃত হলে, সর্বদা **বিদ্যমান শব্দকোষের শর্তাবলীর সাথে লিঙ্ক করুন** (শুধুমাত্র প্রথম উল্লেখ হাইপারলিঙ্ক করা উচিত)। -**উদাহরণ**: [পরিষেবা মেশ সংজ্ঞা](/service_mesh/) এর “এটি কী” বিভাগটি একবার দেখুন। এটি মাইক্রোসার্ভিস, পরিষেবা, নির্ভরযোগ্যতা এবং পর্যবেক্ষণযোগ্যতার সংজ্ঞাগুলির সাথে লিঙ্ক করে। উপরন্তু, এটি একটি মাইক্রোসার্ভিসেস পরিবেশে নেটওয়ার্ক চ্যালেঞ্জের তুলনা করে একটি বাস্তব-বিশ্বের উদাহরণ ব্যবহার করে (এমন কিছু যা অ-প্রযুক্তিগত লোকেরা সম্পর্কিত হতে পারে না) ওয়াইফাই সমস্যার (যা কেউ ল্যাপটপ ব্যবহার করে বুঝতে পারে)সাথে । যেখানে সম্ভব, সেই সংযোগটি তৈরি করার চেষ্টা করুন। +**উদাহরণ**: [পরিষেবা মেশ সংজ্ঞা](/service-mesh/) এর “এটি কী” বিভাগটি একবার দেখুন। এটি মাইক্রোসার্ভিস, পরিষেবা, নির্ভরযোগ্যতা এবং পর্যবেক্ষণযোগ্যতার সংজ্ঞাগুলির সাথে লিঙ্ক করে। উপরন্তু, এটি একটি মাইক্রোসার্ভিসেস পরিবেশে নেটওয়ার্ক চ্যালেঞ্জের তুলনা করে একটি বাস্তব-বিশ্বের উদাহরণ ব্যবহার করে (এমন কিছু যা অ-প্রযুক্তিগত লোকেরা সম্পর্কিত হতে পারে না) ওয়াইফাই সমস্যার (যা কেউ ল্যাপটপ ব্যবহার করে বুঝতে পারে)সাথে । যেখানে সম্ভব, সেই সংযোগটি তৈরি করার চেষ্টা করুন। #### একটি Google বা Word ডক দিয়ে শুরু করুন diff --git a/content/en/api-gateway.md b/content/en/api-gateway.md index 52608f64d9..60cc683320 100644 --- a/content/en/api-gateway.md +++ b/content/en/api-gateway.md @@ -6,7 +6,7 @@ category: technology ## What it is -An [API](/application_programming_interface/) gateway is a tool that +An [API](/application-programming-interface/) gateway is a tool that aggregates unique application APIs, making them all available in one place. It allows organizations to move key functions, such as authentication and authorization or limiting the number of requests between applications, diff --git a/content/en/auto-scaling.md b/content/en/auto-scaling.md index 6f371dd1ff..1d6982ad58 100644 --- a/content/en/auto-scaling.md +++ b/content/en/auto-scaling.md @@ -23,5 +23,5 @@ increasing the number of servers allowing for more video streaming and scaling b ## Related terms -* [Horizontal Scaling](/horizontal_scaling/) -* [Vertical Scaling](/vertical_scaling/) +* [Horizontal Scaling](/horizontal-scaling/) +* [Vertical Scaling](/vertical-scaling/) diff --git a/content/en/bare-metal-machine.md b/content/en/bare-metal-machine.md index 4212e02757..ad6227a2ab 100644 --- a/content/en/bare-metal-machine.md +++ b/content/en/bare-metal-machine.md @@ -7,7 +7,7 @@ category: technology ## What it is Bare metal refers to a physical computer, more specifically a server, that has one, and only one, operating system. -The distinction is important in modern computing because many, if not most, servers are [virtual machines](/virtual_machine/). +The distinction is important in modern computing because many, if not most, servers are [virtual machines](/virtual-machine/). A physical server is typically a fairly large computer with powerful hardware built-in. Installing an operating system and running applications directly on that physical hardware, without [virtualization](/virtualization/), is referred to as running on “bare metal.” @@ -25,9 +25,9 @@ you potentially provide the best possible performance to the operating system. If you need to run a workload that must have extremely fast access to hardware resources, bare metal may be the right solution. -In the context of [cloud native apps](/cloud_native_apps/), +In the context of [cloud native apps](/cloud-native-apps/), we generally think of performance in terms of [scaling](/scalability/) to a large number of concurrent events, -which can be handled by [horizontal scaling](/horizontal_scaling/) (adding more machines to your resource pool). -But some workloads may require [vertical scaling](/vertical_scaling/) (adding more power to an existing physical machine) +which can be handled by [horizontal scaling](/horizontal-scaling/) (adding more machines to your resource pool). +But some workloads may require [vertical scaling](/vertical-scaling/) (adding more power to an existing physical machine) and/or an extremely fast physical hardware response in which case bare metal is better suited. Bare metal also allows you to tune the physical hardware and possibly even hardware drivers to help accomplish your task. diff --git a/content/en/chaos-engineering.md b/content/en/chaos-engineering.md index febc415377..657e3ea28d 100644 --- a/content/en/chaos-engineering.md +++ b/content/en/chaos-engineering.md @@ -6,12 +6,12 @@ category: concept ## What it is -Chaos Engineering or CE is the discipline of experimenting on a [distributed system](/distributed_systems/) in production +Chaos Engineering or CE is the discipline of experimenting on a [distributed system](/distributed-systems/) in production to build confidence in the system's capability to withstand turbulent and unexpected conditions. ## Problem it addresses -[SRE](/site_reliability_engineering/) and [DevOps](/devops/) practices focus on +[SRE](/site-reliability-engineering/) and [DevOps](/devops/) practices focus on techniques to increase product resiliency and [reliability](/reliability/). A system's ability to tolerate failures while ensuring adequate service quality is typically a software development requirement. diff --git a/content/en/cloud-native-apps.md b/content/en/cloud-native-apps.md index fdadf24f91..e0c1125431 100644 --- a/content/en/cloud-native-apps.md +++ b/content/en/cloud-native-apps.md @@ -6,7 +6,7 @@ category: concept ## What it is -Cloud native applications are specifically designed to take advantage of innovations in [cloud computing](/cloud_computing/). +Cloud native applications are specifically designed to take advantage of innovations in [cloud computing](/cloud-computing/). These applications integrate easily with their respective cloud architectures, taking advantage of the cloud’s resources and [scaling](/scalability/) capabilities. It also refers to applications that take advantage of innovations in infrastructure driven by cloud computing. @@ -15,8 +15,8 @@ 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, -often relying heavily on manual provisioning for infrastructure, like [virtual machines](/virtual_machine/) and services. +Each datacenter had services that [tightly coupled](/tightly-coupled-architectures/) 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. For example, apps that require manual intervention to start correctly cannot scale automatically, diff --git a/content/en/cloud-native-security.md b/content/en/cloud-native-security.md index f795e15bac..07eccad7c0 100644 --- a/content/en/cloud-native-security.md +++ b/content/en/cloud-native-security.md @@ -6,7 +6,7 @@ category: concept ## What it is -Cloud native security is an approach that builds security into [cloud native applications](/cloud_native_apps/). +Cloud native security is an approach that builds security into [cloud native applications](/cloud-native-apps/). It ensures that security is part of the entire application lifecycle from development to production. Cloud native security seeks to ensure the same standards as traditional security models while adapting to the particulars of cloud native environments, diff --git a/content/en/cloud-native-tech.md b/content/en/cloud-native-tech.md index 0d0900a317..165b1b05c5 100644 --- a/content/en/cloud-native-tech.md +++ b/content/en/cloud-native-tech.md @@ -7,10 +7,10 @@ category: Concept ## What it is Cloud native technologies, also referred to as the cloud native stack, -are the technologies used to build [cloud native applications](/cloud_native_apps/). +are the technologies used to build [cloud native applications](/cloud-native-apps/). These technologies enable organizations to build and run scalable applications in modern and dynamic environments such as public, private, and hybrid clouds, -while leveraging [cloud computing](/cloud_computing/) benefits to their fullest. +while leveraging [cloud computing](/cloud-computing/) benefits to their fullest. They are designed from the ground up to exploit the capabilities of cloud computing and containers, service meshes, microservices, and immutable infrastructure exemplify this approach. diff --git a/content/en/cluster.md b/content/en/cluster.md index e053991cae..96d1ba7ee8 100644 --- a/content/en/cluster.md +++ b/content/en/cluster.md @@ -16,7 +16,7 @@ The collection of all these [containerized](/containerization/) services, connec Software that runs on a single computer presents a single point of failure — if that computer crashes, or someone accidentally unplugs the power cable, then some business-critical system may be taken offline. -That's why modern software is generally built as [distributed applications](/distributed_apps/), grouped together as clusters. +That's why modern software is generally built as [distributed applications](/distributed-apps/), grouped together as clusters. ## How it helps @@ -24,5 +24,5 @@ Clustered, distributed applications run across multiple machines, eliminating a But building distributed systems is really hard. In fact, it's a computer science discipline in its own right. The need for global systems and years of trial and error led to the development of a new kind of tech stack: -[cloud native technologies](/cloud_native_tech/). +[cloud native technologies](/cloud-native-tech/). These new technologies are the building blocks that make the operation and creation of distributed systems easier. diff --git a/content/en/containerization.md b/content/en/containerization.md index f7432d35b8..fe6b5999d5 100644 --- a/content/en/containerization.md +++ b/content/en/containerization.md @@ -13,10 +13,10 @@ As long as the output is a container image that adheres to this standard, which ## Problem it addresses Before containers became prevalent, organizations relied on virtual machines (VMs) to -orchestrate multiple applications on a single [bare-metal machine](/bare_metal_machine/). +orchestrate multiple applications on a single [bare-metal machine](/bare-metal-machine/). VMs are significantly larger than containers and require a hypervisor to run. Due to the storage, backup, and transfer of these larger VM templates, creating the VM templates is also slow. -Additionally, VMs can suffer from configuration drift which violates the principle of [immutability](/immutable_infrastructure/). +Additionally, VMs can suffer from configuration drift which violates the principle of [immutability](/immutable-infrastructure/). ## How it helps diff --git a/content/en/containers-as-a-service.md b/content/en/containers-as-a-service.md index b408e398ce..9193e0327f 100644 --- a/content/en/containers-as-a-service.md +++ b/content/en/containers-as-a-service.md @@ -16,7 +16,7 @@ It helps developers build secure and [scalable](/scalability/) containerized app Because users only buy the resources they need (scheduling capabilities, load balancing, etc.), they save money and increase efficiency. Containers create consistent environments to rapidly develop and -deliver [cloud-native applications](/cloud_native_apps/) that can run anywhere. +deliver [cloud-native applications](/cloud-native-apps/) that can run anywhere. ## Problem it addresses @@ -27,8 +27,8 @@ the underlying infrastructure that containers run on. When deploying containerized applications to a CaaS platform, users gain visibility into system performance through log aggregation and monitoring tools. -CaaS also includes built-in functionality for [auto scaling](/auto_scaling/) and orchestration management. -It enables teams to build high visibility and high availability [distributed systems](/distributed_systems/). +CaaS also includes built-in functionality for [auto scaling](/auto-scaling/) and orchestration management. +It enables teams to build high visibility and high availability [distributed systems](/distributed-systems/). In addition, by allowing rapid deployments, CaaS increases team development velocity. While containers ensure a consistent deployment target, CaaS lowers engineering operating costs diff --git a/content/en/continuous-delivery.md b/content/en/continuous-delivery.md index 1940493a51..fc078a3b53 100644 --- a/content/en/continuous-delivery.md +++ b/content/en/continuous-delivery.md @@ -26,11 +26,11 @@ deploying more changes at once and increasing the risk that something goes wrong CD strategies create a fully automated path to production that tests and deploys the software using various deployment strategies -such as [canary](/canary_deployment/) or [blue-green](/blue_green_deployment/) releases. +such as [canary](/canary-deployment/) or [blue-green](/blue-green-deployment/) releases. This allows developers to deploy code frequently, giving them peace of mind that the new revision has been tested. Typically, trunk-based development is used in CD strategies as opposed to feature branching or pull requests. ## Related terms -* [Continuous Integration](/continuous_integration/) -* [Continuous Deployment](/continuous_deployment/) +* [Continuous Integration](/continuous-integration/) +* [Continuous Deployment](/continuous-deployment/) diff --git a/content/en/continuous-deployment.md b/content/en/continuous-deployment.md index 81d32c007b..f84e790150 100644 --- a/content/en/continuous-deployment.md +++ b/content/en/continuous-deployment.md @@ -6,9 +6,9 @@ category: concept ## What it is -Continuous deployment, often abbreviated as CD, goes a step further than [continuous delivery](/continuous_delivery/) +Continuous deployment, often abbreviated as CD, goes a step further than [continuous delivery](/continuous-delivery/) by deploying finished software directly to production. -Continuous deployment (CD) goes hand in hand with [continuous integration](/continuous_integration/) (CI), +Continuous deployment (CD) goes hand in hand with [continuous integration](/continuous-integration/) (CI), and is often referred to as CI/CD. The CI process tests if the changes to a given application are valid, and the CD process automatically deploys the code changes through an organization's environments from test to production. @@ -30,5 +30,5 @@ It also makes organizations better at accepting and adapting to production chang ## Related terms -* [Continuous Integration](/continuous_integration/) -* [Continuous Delivery](/continuous_delivery/) +* [Continuous Integration](/continuous-integration/) +* [Continuous Delivery](/continuous-delivery/) diff --git a/content/en/continuous-integration.md b/content/en/continuous-integration.md index 67e8dca297..457ac56b3f 100644 --- a/content/en/continuous-integration.md +++ b/content/en/continuous-integration.md @@ -7,7 +7,7 @@ category: concept ## What it is Continuous integration, often abbreviated as CI, is the practice of integrating code changes as regularly as possible. -CI is a prerequisite for [continuous delivery](/continuous_delivery/) (CD). +CI is a prerequisite for [continuous delivery](/continuous-delivery/) (CD). Traditionally, the CI process begins when code changes are committed to a source control system (Git, Mercurial, or Subversion) and ends with a tested artifact ready to be consumed by a CD system. @@ -28,5 +28,5 @@ CI allows software teams to turn every code commit into either a concrete failur ## Related terms -* [Continuous Delivery](/continuous_delivery/) -* [Continuous Deployment](/continuous_deployment/) +* [Continuous Delivery](/continuous-delivery/) +* [Continuous Deployment](/continuous-deployment/) diff --git a/content/en/data-center.md b/content/en/data-center.md index 9a2a9df11e..e52eba7be8 100644 --- a/content/en/data-center.md +++ b/content/en/data-center.md @@ -8,7 +8,7 @@ category: Technology A data center is a specialised building or facility designed specifically to house computers, most often servers. Data centers tend to be connected to high-speed internet lines, -especially in the case of data centers focused on [cloud computing](/cloud_computing/). +especially in the case of data centers focused on [cloud computing](/cloud-computing/). The buildings data centers are housed in also have equipment to maintain service even in the case of negative events, such as generators to provide power during outages, as well as powerful air conditioning to deal with waste heat produced by the computers. diff --git a/content/en/database-as-a-service.md b/content/en/database-as-a-service.md index fa48a60051..86bd3ac2ae 100644 --- a/content/en/database-as-a-service.md +++ b/content/en/database-as-a-service.md @@ -6,7 +6,7 @@ category: Technology ## What it is -Database-as-a-Service (DBaaS) is a service managed by a [cloud](/cloud_computing/) operator (public or private) +Database-as-a-Service (DBaaS) is a service managed by a [cloud](/cloud-computing/) operator (public or private) that supports applications without requiring the application team to perform traditional database administration functions. DBaaS allows app developers to leverage databases without being experts or diff --git a/content/en/devops.md b/content/en/devops.md index 4c5469fd88..c503420954 100644 --- a/content/en/devops.md +++ b/content/en/devops.md @@ -12,7 +12,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-architectures/) [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/devsecops.md b/content/en/devsecops.md index dd9e3b65f5..1dffb4eb09 100644 --- a/content/en/devsecops.md +++ b/content/en/devsecops.md @@ -13,7 +13,7 @@ Like DevOps, DevSecOps is a cultural shift, pushed by the technologies adopted, ## Problem it addresses -DevOps practices include [continuous integration](/continuous_integration/) and [continuous deployment](/continuous_delivery/) +DevOps practices include [continuous integration](/continuous-integration/) and [continuous deployment](/continuous-delivery/) and accelerate application development and release cycles. Unfortunately, automated release processes that fail to represent all organizational stakeholders adequately can exacerbate existing issues. diff --git a/content/en/distributed-apps.md b/content/en/distributed-apps.md index be6325e0e7..a5e905ed41 100644 --- a/content/en/distributed-apps.md +++ b/content/en/distributed-apps.md @@ -23,6 +23,6 @@ because more developers need to work on a shared codebase that doesn't necessari When splitting an application into different pieces and running them in many places, the overall system can tolerate more failures. It also allows an application to take advantage of scaling features not available to a single application instance, -namely the ability to [scale horizontally](/horizontal_scaling/). +namely the ability to [scale horizontally](/horizontal-scaling/). This does, however, come at a cost: increased complexity and operational overhead — you’re now running lots of application components instead of one app. diff --git a/content/en/distributed-systems.md b/content/en/distributed-systems.md index 6ea076167b..a2f22c6557 100644 --- a/content/en/distributed-systems.md +++ b/content/en/distributed-systems.md @@ -24,7 +24,7 @@ Vertical scaling is time-consuming, requires downtime, and reaches its limit qui ## How it helps -Distributed systems allow for [horizontal scaling](/horizontal_scaling/) (e.g. adding more nodes to the system whenever needed). +Distributed systems allow for [horizontal scaling](/horizontal-scaling/) (e.g. adding more nodes to the system whenever needed). This can be automated allowing a system to handle a sudden increase in workload or resource consumption. A non-distributed system exposes itself to risks of failure because if one machine fails, the entire system fails. diff --git a/content/en/function-as-a-service.md b/content/en/function-as-a-service.md index ccb2422f98..ab9932b6dc 100644 --- a/content/en/function-as-a-service.md +++ b/content/en/function-as-a-service.md @@ -6,7 +6,7 @@ category: Technology ## What it is -Function as a Service (FaaS) is a type of [serverless](/serverless/) [cloud computing](/cloud_computing/) [service](/service/) +Function as a Service (FaaS) is a type of [serverless](/serverless/) [cloud computing](/cloud-computing/) [service](/service/) that allows executing code in response to events without maintaining the complex infrastructure typically associated with building and launching [microservices](/microservices/) applications. @@ -22,7 +22,7 @@ The business must invest in servers, storage, software, and other technologies and potentially hire an IT staff or contractors to purchase, manage, and upgrade all the equipment and licenses. The data center has to be built to meet peak demand, even when workloads decline and those resources stand idle. Conversely, if the business grows quickly, the IT department might struggle to keep up. -Under a standard [Infrastructure-as-a-Service (IaaS)](/infrastructure_as_a_service/) cloud computing model, +Under a standard [Infrastructure-as-a-Service (IaaS)](/infrastructure-as-a-service/) cloud computing model, users pre-purchase capacity units, meaning you pay a public cloud provider for always-on server components to run your apps. It’s the user’s responsibility to scale up server capacity during times of high demand and scale down when that capacity is no longer needed. diff --git a/content/en/horizontal-scaling.md b/content/en/horizontal-scaling.md index d5c8c6cc5a..889c01a18a 100644 --- a/content/en/horizontal-scaling.md +++ b/content/en/horizontal-scaling.md @@ -7,7 +7,7 @@ category: Concept ## What it is 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/)). +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. @@ -34,5 +34,5 @@ without needing to increase the capacity of any node in particular. ## Related terms -* [Vertical Scaling](/vertical_scaling/) -* [Auto Scaling](/auto_scaling/) +* [Vertical Scaling](/vertical-scaling/) +* [Auto Scaling](/auto-scaling/) diff --git a/content/en/immutable-infrastructure.md b/content/en/immutable-infrastructure.md index 5e91d6840e..1eacc86874 100644 --- a/content/en/immutable-infrastructure.md +++ b/content/en/immutable-infrastructure.md @@ -5,7 +5,7 @@ category: property --- Immutable Infrastructure refers to computer infrastructure -([virtual machines](/virtual_machine/), [containers](/container/), network appliances) +([virtual machines](/virtual-machine/), [containers](/container/), network appliances) that cannot be changed once deployed. This can be enforced by an automated process that overwrites unauthorized changes or through a system that won't allow changes in the first place. @@ -18,7 +18,7 @@ immutable infrastructures make it easier to identify and mitigate security risks Operating such a system becomes a lot more straightforward because administrators can make assumptions about it. After all, they know no one made mistakes or changes they forgot to communicate. -Immutable infrastructure goes hand-in-hand with [infrastructure as code](/infrastructure_as_code/) +Immutable infrastructure goes hand-in-hand with [infrastructure as code](/infrastructure-as-code/) where all automation needed to create infrastructure is stored in version control (e.g. Git). This combination of immutability and version control means that there is a durable audit log of every authorized change to a system. diff --git a/content/en/infrastructure-as-a-service.md b/content/en/infrastructure-as-a-service.md index 3093ca6b5e..76fcc0bf58 100644 --- a/content/en/infrastructure-as-a-service.md +++ b/content/en/infrastructure-as-a-service.md @@ -6,8 +6,8 @@ category: Technology ## What it is -Infrastructure as a service, or IaaS, is a [cloud computing](/cloud_computing/) service model that -offers [physical](/bare_metal_machine/) or [virtualized](/virtualization/) +Infrastructure as a service, or IaaS, is a [cloud computing](/cloud-computing/) service model that +offers [physical](/bare-metal-machine/) or [virtualized](/virtualization/) compute, storage, and network resources on-demand on a pay-as-you-go model. Cloud providers own and operate the hardware and software, available to consumers in public, private, or hybrid cloud deployments. diff --git a/content/en/infrastructure-as-code.md b/content/en/infrastructure-as-code.md index e67526c493..921abe514e 100644 --- a/content/en/infrastructure-as-code.md +++ b/content/en/infrastructure-as-code.md @@ -14,12 +14,12 @@ usually through shell scripts or other configuration tools. Building applications in a cloud native way requires infrastructure to be disposable and reproducible. It also needs to [scale](/scalability/) on-demand in an automated and repeatable way, potentially without human intervention. -Manual provisioning cannot meet the responsiveness and scale requirements of [cloud native applications](/cloud_native_apps/). +Manual provisioning cannot meet the responsiveness and scale requirements of [cloud native applications](/cloud-native-apps/). Manual infrastructure changes are not reproducible, quickly run into scale limits, and introduces misconfiguration errors. ## How it helps By representing the data center resources such as servers, load balancers, and subnets as code, it allows infrastructure teams to have a single source of truth for all configurations and -also allows them to manage their data center in a [CI](/continuous_integration/)/[CD](/continuous_delivery/) pipeline, +also allows them to manage their data center in a [CI](/continuous-integration/)/[CD](/continuous-delivery/) pipeline, implementing version control and deployment strategies. diff --git a/content/en/kubernetes.md b/content/en/kubernetes.md index 5e39f43487..baf0bc83fd 100644 --- a/content/en/kubernetes.md +++ b/content/en/kubernetes.md @@ -9,7 +9,7 @@ category: technology Kubernetes, often abbreviated as K8s, is an open source container orchestrator that automates the life-cycle of [containerized](/container/) applications on modern infrastructures. It's like a data center operating system that manages applications -running across a [distributed system](/distributed_systems/) +running across a [distributed system](/distributed-systems/) (just like the OS on your laptop that manages your apps). Kubernetes schedules containers across [nodes](/nodes/) in a [cluster](/cluster/). @@ -20,14 +20,14 @@ in a way that they can be composed into applications. Kubernetes enables automation and extensibility, allowing users to deploy applications declaratively in a reproducible way. Software products and projects in the Kubernetes ecosystem take advantage of that automation and extensibility -to extend the Kubernetes [API](/application_programming_interface/). +to extend the Kubernetes [API](/application-programming-interface/). This enables them to leverage Kubernetes’ automation and make their tools more accessible to experienced Kubernetes practitioners. ## Problem it addresses Infrastructure automation and declarative configuration management have been important concepts for a long time and -have only become more pressing as [cloud computing](/cloud_computing/) has gained popularity. +have only become more pressing as [cloud computing](/cloud-computing/) has gained popularity. As demand for compute resources increases and organizations feel pressured to provide more operational capabilities with fewer engineers, new technologies and working methods are required to meet that demand. diff --git a/content/en/loosely-coupled-architecture.md b/content/en/loosely-coupled-architecture.md index 5d3b0244fd..62ee698a6c 100644 --- a/content/en/loosely-coupled-architecture.md +++ b/content/en/loosely-coupled-architecture.md @@ -6,7 +6,7 @@ category: 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/)). +(the opposite paradigm of [tightly coupled architectures](/tightly-coupled-architectures/)). Each component, sometimes referred to as a [microservice](/microservices/), 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 diff --git a/content/en/managed-services.md b/content/en/managed-services.md index 66fc9f154e..f95d52f559 100644 --- a/content/en/managed-services.md +++ b/content/en/managed-services.md @@ -19,4 +19,4 @@ Your team is likely better off building new capabilities than taking care of the Managed services are ready to use from day one with very little operational overhead. They allow organizations to effectively outsource tasks that fall outside of their core competency -with well defined, and usually [API](/application_programming_interface/) driven, boundaries. +with well defined, and usually [API](/application-programming-interface/) driven, boundaries. diff --git a/content/en/microservices.md b/content/en/microservices.md index 0d0c060b50..1ee355b432 100644 --- a/content/en/microservices.md +++ b/content/en/microservices.md @@ -13,7 +13,7 @@ For instance, a single page that allows you to access, search, and preview video powered by smaller services that each handle one aspect of it (e.g. search, authentication, and running previews in your browser). In short, microservices refer to an application architecture pattern -usually contrasted with [monolithic applications](/monolithic_apps/). +usually contrasted with [monolithic applications](/monolithic-apps/). ## Problem it addresses @@ -25,7 +25,7 @@ In a monolithic application, those bits of logic can't be deployed separately. If you can't scale the product functionality individually, you'll have to duplicate the entire app with all other components you don't need – an inefficient use of resources. Monolithic applications 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 +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 often require developers to understand the entire codebase before they can be productive. @@ -36,4 +36,4 @@ By allowing different teams to focus on their own small part of a bigger applica you also make it easier for them to work on their apps without negatively impacting the rest of the organization. While microservices solve many problems, they also create operational overhead — the things you need to deploy and keep track of increase by order of magnitude or more. -Many [cloud-native technologies](/cloud_native_tech/) aim to make microservices easier to deploy and manage. +Many [cloud-native technologies](/cloud-native-tech/) aim to make microservices easier to deploy and manage. diff --git a/content/en/mutual-transport-layer-security.md b/content/en/mutual-transport-layer-security.md index 5a21b877f3..a57eb94247 100644 --- a/content/en/mutual-transport-layer-security.md +++ b/content/en/mutual-transport-layer-security.md @@ -7,7 +7,7 @@ category: Concept ## What it is Mutual TLS (mTLS) is a technique used to authenticate and encrypt messages sent between two [services](/service/). -Mutual TLS is the standard [Transport Layer Security](/tlstransport-layer-security/) (TLS) protocol but, +Mutual TLS is the standard [Transport Layer Security](/transport-layer-security/) (TLS) protocol but, instead of validating the identity of just one connection, both sides are validated. ## Problem it addresses diff --git a/content/en/nodes.md b/content/en/nodes.md index 1062cbe6c3..e1ed3e166f 100644 --- a/content/en/nodes.md +++ b/content/en/nodes.md @@ -9,14 +9,14 @@ category: Concept A node is a computer that works in concert with other computers, or nodes, to accomplish a common task. Take your laptop, modem, and printer, for example. They are all connected over your wifi network communicating and collaborating, each representing one node. -In [cloud computing](/cloud_computing/), a node can be a physical computer, +In [cloud computing](/cloud-computing/), a node can be a physical computer, a virtual computer, referred to as a VM, or even a [container](/container/). ## Problem it addresses While an application could (and many do) run on one single machine, there are some risks involved with that. Namely that the failure of the underlying system will disrupt the application. -To address this, developers started creating [distributed applications](/distributed_apps/) where each process runs on its own node. +To address this, developers started creating [distributed applications](/distributed-apps/) where each process runs on its own node. Thus, nodes run apps or processes as part of a group forming a [cluster](/cluster/), or group, of nodes that works together to achieve a common goal. ## How it helps diff --git a/content/en/platform-as-a-service.md b/content/en/platform-as-a-service.md index 1cd7b2e1d2..b82241a2e8 100644 --- a/content/en/platform-as-a-service.md +++ b/content/en/platform-as-a-service.md @@ -11,10 +11,10 @@ Heroku, Cloud Foundry, App Engine are examples of PaaS offerings. ## Problem it addresses -To take advantage of cloud native patterns like [microservices](/microservices/) or [distributed applications](/distributed_apps/), +To take advantage of cloud native patterns like [microservices](/microservices/) or [distributed applications](/distributed-apps/), operations teams and developers need to be able to offload a significant amount of operations and maintenance work. These include tasks like provisioning infrastructure, -handling [service discovery](/service_discovery/) and load balancing, and [scaling](/scalability/) applications. +handling [service discovery](/service-discovery/) and load balancing, and [scaling](/scalability/) applications. ## How it helps diff --git a/content/en/reliability.md b/content/en/reliability.md index 08a4352af0..d21bdeb9dd 100644 --- a/content/en/reliability.md +++ b/content/en/reliability.md @@ -5,6 +5,6 @@ category: property --- From a cloud native perspective, reliability refers to how well a system responds to failures. -If we have a [distributed system](/distributed_systems/) that keeps working as infrastructure changes and individual components fail, it is reliable. +If we have a [distributed system](/distributed-systems/) that keeps working as infrastructure changes and individual components fail, it is reliable. On the other hand, if it fails easily and operators need to intervene manually to keep it running, it is unreliable. -The goal of [cloud native applications](/cloud_native_apps/) is to build inherently reliable systems. +The goal of [cloud native applications](/cloud-native-apps/) is to build inherently reliable systems. diff --git a/content/en/scalability.md b/content/en/scalability.md index 1935368df5..feaf584f79 100644 --- a/content/en/scalability.md +++ b/content/en/scalability.md @@ -14,7 +14,7 @@ and how many records and operations can the control plane support? A scalable system makes it easy to add more capacity. We differentiate between two scaling approaches. -On the one hand, there is [horizontal scaling](/horizontal_scaling/) which adds more nodes to handle increased load. -In contrast, in [vertical scaling](/vertical_scaling/) individual nodes are made more powerful to perform more transactions +On the one hand, there is [horizontal scaling](/horizontal-scaling/) which adds more nodes to handle increased load. +In contrast, in [vertical scaling](/vertical-scaling/) individual nodes are made more powerful to perform more transactions (e.g. by adding more memory or CPU to an individual machine). A scalable system is able to change easily and meet user needs. diff --git a/content/en/security-chaos-engineering.md b/content/en/security-chaos-engineering.md index fee5782e84..b5f6d184e3 100644 --- a/content/en/security-chaos-engineering.md +++ b/content/en/security-chaos-engineering.md @@ -6,7 +6,7 @@ category: concept ## What it is -Security Chaos Engineering or SCE is a discipline based on [Chaos Engineering](/chaos_engineering/). +Security Chaos Engineering or SCE is a discipline based on [Chaos Engineering](/chaos-engineering/). SCE performs proactive security experimentation on a distributed system to build confidence in the system's capability to withstand turbulent and malicious conditions. Security chaos engineers use scientific method loops to achieve this, @@ -14,7 +14,7 @@ including steady-state, hypothesis, continuous verification, lesson learned, and ## Problem it addresses -The main priority for [site reliability engineers](/site_reliability_engineering/) (SREs) and cyber security engineers is +The main priority for [site reliability engineers](/site-reliability-engineering/) (SREs) and cyber security engineers is to restore service as fast as possible with the goal of achieving zero downtime and minimizing business impact. SREs and cyber security engineers deal both with pre-failure and post-failure incidents situations. Most security issues are challenging to discover and patch quickly, impacting application or system functionality. diff --git a/content/en/serverless.md b/content/en/serverless.md index 3f43298469..2590c92db9 100644 --- a/content/en/serverless.md +++ b/content/en/serverless.md @@ -17,7 +17,7 @@ As a result, when a serverless function is sitting idle, it doesn’t cost anyth ## Problem it addresses -Under a standard [Infrastructure-as-a-Service (IaaS)](/infrastructure_as_a_service/) [cloud computing](/cloud_computing/) model, +Under a standard [Infrastructure-as-a-Service (IaaS)](/infrastructure-as-a-service/) [cloud computing](/cloud-computing/) model, users pre-purchase units of capacity, meaning you pay a public cloud provider for always-on server components to run your apps. It’s the user’s responsibility to scale up server capacity during times of high demand and to scale down when that capacity is no longer needed. diff --git a/content/en/shift-left.md b/content/en/shift-left.md index d64a460c9f..698f0a68f7 100644 --- a/content/en/shift-left.md +++ b/content/en/shift-left.md @@ -29,7 +29,7 @@ And because responsibility for testing and security is shared across the develop everyone plays a part in ensuring the stability and security of an application. In addition, shifting left enables continuous improvement and -follows an [agile](/agile_software_development/) rather than waterfall approach to development. +follows an [agile](/agile-software-development/) rather than waterfall approach to development. Teams can make small iterative improvements and identify problems earlier on. This approach allows engineers to adopt security and secure development practices as early as the design and architecture phase. diff --git a/content/en/stateful-apps.md b/content/en/stateful-apps.md index de091e76ab..7535ead52d 100644 --- a/content/en/stateful-apps.md +++ b/content/en/stateful-apps.md @@ -6,7 +6,7 @@ category: concept ## What it is -When we speak of stateful (and [stateless](/stateless_apps/)) apps, +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. diff --git a/content/en/stateless-apps.md b/content/en/stateless-apps.md index 84b08f475a..94f08e80f8 100644 --- a/content/en/stateless-apps.md +++ b/content/en/stateless-apps.md @@ -22,7 +22,7 @@ with multiple requests coming to them at the same time. If there’s a problem, you can easily restart the application, and it will return to its initial state with little or no downtime. As such, the benefits of stateless applications include resiliency, elasticity, and high availability. -However, most applications we use today are at least partly [stateful](/stateful_apps/), +However, most applications we use today are at least partly [stateful](/stateful-apps/), as they store things like preferences and settings to improve the user experience. ## How it helps diff --git a/content/en/style-guide/_index.md b/content/en/style-guide/_index.md index d875e5bfc9..8da0ae9388 100644 --- a/content/en/style-guide/_index.md +++ b/content/en/style-guide/_index.md @@ -137,7 +137,7 @@ When appropriate, use **real-world examples** that help readers (especially non- When used in your definition, always **link to existing glossary terms** (only the first mention should be hyperlinked). -**Example**: take a look at the “What it is” section of the [service mesh definition](/service_mesh/). +**Example**: take a look at the “What it is” section of the [service mesh definition](/service-mesh/). It links back to the microservices, service, reliability, and observability definitions. Additionally, it uses a real-world example comparing network challenges in a microservices environment (something non-technical people can't relate to) to wifi problems (something anyone using a laptop can understand). diff --git a/content/en/tightly-coupled-architectures.md b/content/en/tightly-coupled-architectures.md index be805778d2..50a4b186de 100644 --- a/content/en/tightly-coupled-architectures.md +++ b/content/en/tightly-coupled-architectures.md @@ -5,7 +5,7 @@ category: Property --- Tightly coupled architecture is an architectural style where a number of application components are interdependent -(the opposite paradigm of [loosely coupled architectures](/loosely_coupled_architecture/)). +(the opposite paradigm of [loosely coupled architectures](/loosely-coupled-architecture/)). This means that a change in one component will likely impact other components. It is generally easier to implement than more loosely coupled architectural styles, but can leave a system more vulnerable to cascading failures. @@ -16,4 +16,4 @@ Tightly coupled application architectures are a fairly traditional way of buildi While not necessarily consistent with all the best practices of [microservice](/microservices/) development they can be useful in specific circumstances. They tend to be faster and simpler to implement and -much like [monolithic applications](/monolithic_apps/) they can speed up the initial development cycle. +much like [monolithic applications](/monolithic-apps/) they can speed up the initial development cycle. diff --git a/content/en/vertical-scaling.md b/content/en/vertical-scaling.md index ae7323bda0..cb5133cba0 100644 --- a/content/en/vertical-scaling.md +++ b/content/en/vertical-scaling.md @@ -10,14 +10,14 @@ Vertical scaling, also known as "scaling up and down", is a technique where a system's capacity is increased by adding CPU and memory to individual [nodes](/nodes/) as the workload increases. Let's say, you have a computer of 4GB RAM and want to increase its capacity to 16GB RAM, scaling it vertically means switching to a 16GB RAM system. -(Please refer to [horizontal scaling](/horizontal_scaling/) for a different scaling approach.) +(Please refer to [horizontal scaling](/horizontal-scaling/) for a different scaling approach.) ## Problem it addresses As demand for an application grows beyond the current capacity of that application instance, we need to find a way to scale (add capacity to) the system. We can either add more compute resources to existing nodes (vertical scaling) -or more nodes to the system ([horizontal scaling](/horizontal_scaling/)). +or more nodes to the system ([horizontal scaling](/horizontal-scaling/)). [Scalability](/scalability/) contributes to competitiveness, efficiency, reputation, and quality. ## How it helps @@ -29,5 +29,5 @@ adding compute resources, allowing the app to process more requests and do more ## Related terms -* [Horizontal Scaling](/horizontal_scaling/) -* [Auto Scaling](/auto_scaling/) +* [Horizontal Scaling](/horizontal-scaling/) +* [Auto Scaling](/auto-scaling/) diff --git a/content/en/virtual-machine.md b/content/en/virtual-machine.md index f3a72bf8c6..4d65dd283e 100644 --- a/content/en/virtual-machine.md +++ b/content/en/virtual-machine.md @@ -15,7 +15,7 @@ easily create and destroy VMs without impacting the underlying hardware. ## Problem it addresses Virtual machines take advantage of virtualization. -When a [bare metal](/bare_metal_machine/) machine is bound to a single operating system, +When a [bare metal](/bare-metal-machine/) machine is bound to a single operating system, how well the machine's resources can be used is somewhat limited. Also, when an operating system is bound to a single physical machine, its availability is directly tied to that hardware. diff --git a/content/es/api-gateway.md b/content/es/api-gateway.md index 7c2e097aec..9c75fcc309 100644 --- a/content/es/api-gateway.md +++ b/content/es/api-gateway.md @@ -6,7 +6,7 @@ category: Tecnología ## ¿Qué es esto? -Un API Gateway es una herramienta que concentra diferentes aplicaciones [APIs](/application_programming_interface/), centralizando a todas en un solo lugar. Esto permite a las organizaciones mover funciones clave, como puede ser la autenticación y la autorización o limitando el número de peticiones entre aplicaciones a una ubicación de administración centralizada. Un API Gateway funciona como una interface común para los que la consumen (usualmente aplicaciones externas). +Un API Gateway es una herramienta que concentra diferentes aplicaciones [APIs](/application-programming-interface/), centralizando a todas en un solo lugar. Esto permite a las organizaciones mover funciones clave, como puede ser la autenticación y la autorización o limitando el número de peticiones entre aplicaciones a una ubicación de administración centralizada. Un API Gateway funciona como una interface común para los que la consumen (usualmente aplicaciones externas). ## El problema que aborda diff --git a/content/es/bare-metal-machine.md b/content/es/bare-metal-machine.md index 6438a9d8a1..b32363ae0c 100644 --- a/content/es/bare-metal-machine.md +++ b/content/es/bare-metal-machine.md @@ -6,7 +6,7 @@ category: Tecnología ## ¿Qué es? -Bare metal se refiere a una computadora física, más específicamente un servidor, que tiene un solo sistema operativo. La distinción es importante en la informática moderna porque muchos, si no es que la mayoría, de los servidores son [máquinas virtuales](/virtual_machine/). Un servidor físico suele ser una computadora bastante grande con un potente hardware incorporado. La instalación de un sistema operativo y la ejecución de aplicaciones directamente en ese hardware físico, sin [virtualización](/virtualization/), se conoce como ejecución "bare metal". +Bare metal se refiere a una computadora física, más específicamente un servidor, que tiene un solo sistema operativo. La distinción es importante en la informática moderna porque muchos, si no es que la mayoría, de los servidores son [máquinas virtuales](/virtual-machine/). Un servidor físico suele ser una computadora bastante grande con un potente hardware incorporado. La instalación de un sistema operativo y la ejecución de aplicaciones directamente en ese hardware físico, sin [virtualización](/virtualization/), se conoce como ejecución "bare metal". ## Problema que aborda @@ -16,4 +16,4 @@ Emparejar un sistema operativo con una computadora física es el patrón origina Al dedicar todos los recursos informáticos de una computadora a un solo sistema operativo, potencialmente se proporciona el mejor rendimiento posible al sistema operativo. Si necesita ejecutar una carga de trabajo que debe tener un acceso extremadamente rápido a los recursos de hardware, bare metal puede ser la solución adecuada. -En el contexto de las [aplicaciones nativas de la nube](/cloud_native_apps/), generalmente pensamos en el rendimiento en términos de [escalabilidad](/scalability/) para una gran cantidad de eventos simultáneos, que pueden mitigarse mediante el [escalado horizontal](/horizontal_scaling/) (agregando más máquinas a su grupo de recursos). Sin embargo, algunas cargas de trabajo pueden requerir [escalado vertical](/vertical_scaling/) (agregar más potencia a una máquina física existente) y/o una respuesta extremadamente rápida de hardware físico, en cuyo caso se adapta mejor el bare metal. Bare metal también le permite ajustar el hardware físico y posiblemente incluso los controladores de hardware para ayudarlo a realizar su tarea. +En el contexto de las [aplicaciones nativas de la nube](/cloud-native-apps/), generalmente pensamos en el rendimiento en términos de [escalabilidad](/scalability/) para una gran cantidad de eventos simultáneos, que pueden mitigarse mediante el [escalado horizontal](/horizontal-scaling/) (agregando más máquinas a su grupo de recursos). Sin embargo, algunas cargas de trabajo pueden requerir [escalado vertical](/vertical-scaling/) (agregar más potencia a una máquina física existente) y/o una respuesta extremadamente rápida de hardware físico, en cuyo caso se adapta mejor el bare metal. Bare metal también le permite ajustar el hardware físico y posiblemente incluso los controladores de hardware para ayudarlo a realizar su tarea. diff --git a/content/es/devops.md b/content/es/devops.md index 2116a28a2a..5412f0bafa 100644 --- a/content/es/devops.md +++ b/content/es/devops.md @@ -10,7 +10,7 @@ DevOps es una metodología en la que los equipos son dueños de todo el proceso, ## Problema que aborda -Tradicionalmente, en organizaciones complejas con [aplicaciones monolíticas](/monolithic_apps/) con arquitecturas [estrechamente acopladas](/tightly_coupled_architectures/), el trabajo generalmente se distribuía entre varios equipos. Esta fragmentación del desarrollo dio lugar a numerosos traspasos y largos plazos de entrega. Cada vez que un componente o alguna actualización estaba lista, se colocaba en una cola para el siguiente equipo. Debido a que las personas solo trabajaron en una pequeña parte del proyecto, este enfoque condujo a una falta de propiedad. Su objetivo era entregar el trabajo al siguiente grupo, en vez de ofrecer la funcionalidad correcta al cliente - un claro desajuste de prioridades. +Tradicionalmente, en organizaciones complejas con [aplicaciones monolíticas](/monolithic-apps/) con arquitecturas [estrechamente acopladas](/tightly-coupled-architectures/), el trabajo generalmente se distribuía entre varios equipos. Esta fragmentación del desarrollo dio lugar a numerosos traspasos y largos plazos de entrega. Cada vez que un componente o alguna actualización estaba lista, se colocaba en una cola para el siguiente equipo. Debido a que las personas solo trabajaron en una pequeña parte del proyecto, este enfoque condujo a una falta de propiedad. Su objetivo era entregar el trabajo al siguiente grupo, en vez de ofrecer la funcionalidad correcta al cliente - un claro desajuste de prioridades. Cuando el código finalmente entró en producción, pasó por tantos desarrolladores, esperando en tantas colas que era difícil rastrear el origen del problema si el código no funcionaba. DevOps dio la vuelta a este enfoque. diff --git a/content/es/infrastructure-as-code.md b/content/es/infrastructure-as-code.md index 240064c6a4..6d2743f0e2 100644 --- a/content/es/infrastructure-as-code.md +++ b/content/es/infrastructure-as-code.md @@ -10,8 +10,8 @@ Infraestructura como código es una práctica para almacenar la definición de l ## Problema que aborda -Construir aplicaciones de forma nativa para la nube requiere que la infraestructura sea desechable y reproducible. Además requiere [escalar](/scalability/) bajo demanda de forma automática y repetible, potencialmente sin la intervención humana. El aprovisionamiento manual no puede cumplir los requerimientos de respuesta y escalado de las [aplicaciones nativas para la nube](/cloud_native_apps/). Los cambios manuales no son reproducibles, rápidamente se enfrentan a limites de escalabilidad, e introducen errores de configuración. +Construir aplicaciones de forma nativa para la nube requiere que la infraestructura sea desechable y reproducible. Además requiere [escalar](/scalability/) bajo demanda de forma automática y repetible, potencialmente sin la intervención humana. El aprovisionamiento manual no puede cumplir los requerimientos de respuesta y escalado de las [aplicaciones nativas para la nube](/cloud-native-apps/). Los cambios manuales no son reproducibles, rápidamente se enfrentan a limites de escalabilidad, e introducen errores de configuración. ## ¿Cómo ayuda? -Representados los recursos del [centro de datos](/data_center/) tales como servidores, balanceadores de carga y sub-redes como código, les permite a los equipos de infraestructura poseer una fuente única de verdad para todas las configuraciones y también les permite administrar sus [centro de datos](/data_center/) en flujos de [CI](/continuous_integration/)/[CD](/continuous_delivery/) implementando un sistema de control de versiones y estrategias de despliegue. +Representados los recursos del [centro de datos](/data-center/) tales como servidores, balanceadores de carga y sub-redes como código, les permite a los equipos de infraestructura poseer una fuente única de verdad para todas las configuraciones y también les permite administrar sus [centro de datos](/data-center/) en flujos de [CI](/continuous-integration/)/[CD](/continuous-delivery/) implementando un sistema de control de versiones y estrategias de despliegue. diff --git a/content/es/kubernetes.md b/content/es/kubernetes.md index a149147150..06e1525447 100644 --- a/content/es/kubernetes.md +++ b/content/es/kubernetes.md @@ -6,15 +6,15 @@ category: Tecnología ## ¿Qué es? -Kubernetes, comúnmente abreviado como K8s, es una herramienta de código abierto para la automatización de infraestructura moderna. Puedes compararlo con un sistema operativo en un Centro de Datos que administra las aplicaciones ejecutándose en [sistemas distribuidos](/distributed_systems/) (ó como el sistema operativo en tu laptop que administra tus aplicaciones). +Kubernetes, comúnmente abreviado como K8s, es una herramienta de código abierto para la automatización de infraestructura moderna. Puedes compararlo con un sistema operativo en un Centro de Datos que administra las aplicaciones ejecutándose en [sistemas distribuidos](/distributed-systems/) (ó como el sistema operativo en tu laptop que administra tus aplicaciones). Kubernetes gestiona [contenedores](/container/) en los [nodos](/nodes/) de un [clúster](/cluster/). Agrupa muchos componentes de infraestructura, en ocasiones referidos como "primitivos", como una instancia de una aplicación, balanceadores de carga, almacenamiento persistente y otros, de manera que puedan integrarse en aplicaciones. -Kubernetes permite la automatización y extensibilidad, permitiendo a los usuarios desplegar sus aplicaciones de una manera declarativa y reproducible. Los productos de Software en el Ecosistema de Kubernetes toman ventaja de la automatización para extender la [API](/application_programming_interface/) de Kubernetes. Lo que permite aprovechar la automatización de Kubernetes y hacer que sus herramientas sean más accesibles para profesionistas experimentados de Kubernetes. +Kubernetes permite la automatización y extensibilidad, permitiendo a los usuarios desplegar sus aplicaciones de una manera declarativa y reproducible. Los productos de Software en el Ecosistema de Kubernetes toman ventaja de la automatización para extender la [API](/application-programming-interface/) de Kubernetes. Lo que permite aprovechar la automatización de Kubernetes y hacer que sus herramientas sean más accesibles para profesionistas experimentados de Kubernetes. ## Problema que aborda -La automatización de infraestructura y administración de configuración declarativa han sido conceptos muy importantes por un largo tiempo, y han sumado más importancia desde que la [Computación en la Nube](/es/cloud_computing/) ha ganado popularidad. La demanda de recursos de cómputo incrementa día con día y las organizaciones sienten presión por proveer más capacidad operativa, con menos ingenieros. Para cumplir con esta demanda nuevas tecnologías y metodologías de trabajo deben ser creadas. +La automatización de infraestructura y administración de configuración declarativa han sido conceptos muy importantes por un largo tiempo, y han sumado más importancia desde que la [Computación en la Nube](/es/cloud-computing/) ha ganado popularidad. La demanda de recursos de cómputo incrementa día con día y las organizaciones sienten presión por proveer más capacidad operativa, con menos ingenieros. Para cumplir con esta demanda nuevas tecnologías y metodologías de trabajo deben ser creadas. Además, el auge de la computación en la nube se combinó con la [contenerización](/containerization/) y las organizaciones que estaban ocupadas automatizando una infraestructura tradicional necesitaban un mecanismo para automatizar la configuración y el despliegue de sus contenedores. diff --git a/content/es/style-guide/_index.md b/content/es/style-guide/_index.md index 1470412e19..c83449b758 100644 --- a/content/es/style-guide/_index.md +++ b/content/es/style-guide/_index.md @@ -112,7 +112,7 @@ Cuando corresponda, use **ejemplos del mundo real** que ayuden a los lectores (e Cuando se use en su definición, siempre **enlace a los términos existentes del glosario** (solo la primera mención debe tener un hipervínculo). -**Ejemplo**: eche un vistazo a la sección "Qué es" de la [definición de service mesh](/service_mesh/). Se vincula con las definiciones de microservicios, servicio, fiabilidad y observabilidad. Además, utiliza un ejemplo del mundo real que compara los desafíos de la red en un entorno de microservicios (algo con lo que las personas no técnicas no pueden relacionarse) con los problemas de wifi (algo que cualquiera que use una computadora portátil puede entender). Siempre que sea posible, trate de hacer esa conexión. +**Ejemplo**: eche un vistazo a la sección "Qué es" de la [definición de service mesh](/service-mesh/). Se vincula con las definiciones de microservicios, servicio, fiabilidad y observabilidad. Además, utiliza un ejemplo del mundo real que compara los desafíos de la red en un entorno de microservicios (algo con lo que las personas no técnicas no pueden relacionarse) con los problemas de wifi (algo que cualquiera que use una computadora portátil puede entender). Siempre que sea posible, trate de hacer esa conexión. #### Comience con un documento de Google o Word diff --git a/content/hi/cloud-native-tech.md b/content/hi/cloud-native-tech.md index 2fab5202d4..7196e33c7e 100644 --- a/content/hi/cloud-native-tech.md +++ b/content/hi/cloud-native-tech.md @@ -7,7 +7,7 @@ exclude_search: true ## यह क्या है -क्लाउड नेटिव प्रौद्योगिकी, जिसे क्लाउड नेटिव स्टैक के रूप में भी जाना जाता है, वे तकनीकें हैं जिनका उपयोग [क्लाउड नेटिव एप्लिकेशन](/cloud_native_apps/) बनाने के लिए किया जाता है। सार्वजनिक, निजी और हाइब्रिड क्लाउड जैसे आधुनिक, गतिशील वातावरण में स्केलेबल एप्लिकेशन बनाने और चलाने के लिए संगठनों को सक्षम करते हुए, वे 'क्लाउड के वादे' को कायम रखते हैं और क्लाउड कंप्यूटिंग लाभों का पूरा लाभ उठाने की अनुमति देता है। वे क्लाउड कंप्यूटिंग और कंटेनर, सर्विस मेश, माइक्रोसर्विसेज की क्षमताओं का फायदा उठाने के लिए जमीन से तैयार किए गए हैं, अपरिवर्तनीय अवसंरचना इस दृष्टिकोण को स्पष्ट करे हैं। +क्लाउड नेटिव प्रौद्योगिकी, जिसे क्लाउड नेटिव स्टैक के रूप में भी जाना जाता है, वे तकनीकें हैं जिनका उपयोग [क्लाउड नेटिव एप्लिकेशन](/cloud-native-apps/) बनाने के लिए किया जाता है। सार्वजनिक, निजी और हाइब्रिड क्लाउड जैसे आधुनिक, गतिशील वातावरण में स्केलेबल एप्लिकेशन बनाने और चलाने के लिए संगठनों को सक्षम करते हुए, वे 'क्लाउड के वादे' को कायम रखते हैं और क्लाउड कंप्यूटिंग लाभों का पूरा लाभ उठाने की अनुमति देता है। वे क्लाउड कंप्यूटिंग और कंटेनर, सर्विस मेश, माइक्रोसर्विसेज की क्षमताओं का फायदा उठाने के लिए जमीन से तैयार किए गए हैं, अपरिवर्तनीय अवसंरचना इस दृष्टिकोण को स्पष्ट करे हैं। ## समस्या diff --git a/content/hi/containerization.md b/content/hi/containerization.md index bcba527f1c..5732712c8a 100644 --- a/content/hi/containerization.md +++ b/content/hi/containerization.md @@ -11,7 +11,7 @@ exclude_search: true ## समस्या -कंटेनरों के प्रचलित होने से पहले, संगठन एक ही [बेयर-मेटल मशीन](/bare_metal_machine/) पर कई एप्लीकेशन को व्यवस्थित करने के लिए वर्चुअल मशीनों (VMs) पर निर्भर थे। VMs कंटेनरों से काफी बड़े होते हैं और उन्हें चलाने के लिए एक हाइपरवाइजर की आवश्यकता होती है। इन बड़े VM टेम्प्लेट के स्टोरेज, बैकअप और ट्रांसफर के कारण, VM टेम्पलेट्स बनाना एक धीमी प्रक्रिया है। इसके अतिरिक्त, VMs कॉन्फ़िगरेशन ड्रिफ्ट से पीड़ित हो सकते हैं जो [अपरिवर्तनीयता](/immutable_infrastructure/) के सिद्धांत का उल्लंघन करता है। +कंटेनरों के प्रचलित होने से पहले, संगठन एक ही [बेयर-मेटल मशीन](/bare-metal-machine/) पर कई एप्लीकेशन को व्यवस्थित करने के लिए वर्चुअल मशीनों (VMs) पर निर्भर थे। VMs कंटेनरों से काफी बड़े होते हैं और उन्हें चलाने के लिए एक हाइपरवाइजर की आवश्यकता होती है। इन बड़े VM टेम्प्लेट के स्टोरेज, बैकअप और ट्रांसफर के कारण, VM टेम्पलेट्स बनाना एक धीमी प्रक्रिया है। इसके अतिरिक्त, VMs कॉन्फ़िगरेशन ड्रिफ्ट से पीड़ित हो सकते हैं जो [अपरिवर्तनीयता](/immutable-infrastructure/) के सिद्धांत का उल्लंघन करता है। ## समाधान diff --git a/content/hi/continuous-delivery.md b/content/hi/continuous-delivery.md index b150214182..4f50269b48 100644 --- a/content/hi/continuous-delivery.md +++ b/content/hi/continuous-delivery.md @@ -15,4 +15,4 @@ exclude_search: true ## समाधान -CD रणनीतियाँ उत्पादन के लिए एक पूरी तरह से स्वचालित पथ बनाती हैं जो विभिन्न डिप्लॉयमेंट रणनीतियों जैसे: [कैनरी](/hi/canary_deployment/) या [ब्लू-ग्रीन](/blue_green_deployment/) रिलीज़ का उपयोग करके सॉफ़्टवेयर का परीक्षण और उसको डिप्लॉय करती है। यह डेवलपर्स को बार-बार कोड डिप्लॉय करने की अनुमति देता है, जिससे उन्हें मानसिक शांति मिलती है कि नए संशोधन का परीक्षण किया गया है। आम तौर पर, फीचर ब्रांचिंग या पुल रिक्वेस्ट (PR) के विपरीत, CD रणनीतियों में ट्रंक-आधारित विकास का उपयोग किया जाता है। +CD रणनीतियाँ उत्पादन के लिए एक पूरी तरह से स्वचालित पथ बनाती हैं जो विभिन्न डिप्लॉयमेंट रणनीतियों जैसे: [कैनरी](/hi/canary-deployment/) या [ब्लू-ग्रीन](/blue-green-deployment/) रिलीज़ का उपयोग करके सॉफ़्टवेयर का परीक्षण और उसको डिप्लॉय करती है। यह डेवलपर्स को बार-बार कोड डिप्लॉय करने की अनुमति देता है, जिससे उन्हें मानसिक शांति मिलती है कि नए संशोधन का परीक्षण किया गया है। आम तौर पर, फीचर ब्रांचिंग या पुल रिक्वेस्ट (PR) के विपरीत, CD रणनीतियों में ट्रंक-आधारित विकास का उपयोग किया जाता है। diff --git a/content/hi/continuous-integration.md b/content/hi/continuous-integration.md index 36ed13ca8d..bb289e2d3f 100644 --- a/content/hi/continuous-integration.md +++ b/content/hi/continuous-integration.md @@ -7,7 +7,7 @@ exclude_search: true ## यह क्या है -निरंतर एकीकरण (Continuous_Integration) , जिसे अक्सर CI कहा जाता है, कोड परिवर्तन को जल्दी से जल्दी एकीकृत करने का एक अभ्यास है। CI, [CD](/hi/continuous_delivery/) पढ़ने के लिए आवश्यक है। ऐतिहासिक रूप से, CI की प्रक्रिया तब शरू होती है जब कोड परिवर्तन को सोर्स नियंत्रण सिस्टम (Git, Mercurial, या Subversal) में कमिट किया जाता है और वह परीक्षित उत्पाद, CD सिस्टम में जाने के लिए तैयार होता है। +निरंतर एकीकरण (Continuous Integration) , जिसे अक्सर CI कहा जाता है, कोड परिवर्तन को जल्दी से जल्दी एकीकृत करने का एक अभ्यास है। CI, [CD](/hi/continuous-delivery/) पढ़ने के लिए आवश्यक है। ऐतिहासिक रूप से, CI की प्रक्रिया तब शरू होती है जब कोड परिवर्तन को सोर्स नियंत्रण सिस्टम (Git, Mercurial, या Subversal) में कमिट किया जाता है और वह परीक्षित उत्पाद, CD सिस्टम में जाने के लिए तैयार होता है। ## समस्या diff --git a/content/hi/devops.md b/content/hi/devops.md index a253a1280c..fc7981c836 100644 --- a/content/hi/devops.md +++ b/content/hi/devops.md @@ -11,7 +11,7 @@ DevOps एक कार्यप्रणाली है जिसमें ट ## समस्या -परंपरागत रूप से, [टाइटली-कपल्ड](/tightly_coupled_architectures/) [मोनोलिथिक ऐप्स](/monolith_apps/) का प्रयोग वाले जटिल संगठनों में, काम आम तौर पर कई समूहों के बीच खंडित होता था। इसमें एप्लीकेशन कई टीमों के बीच जाता था और काफी लम्बा समय लगता था। हर बार जब कोई घटक या अपडेट तैयार होता था, तो उसे अगली टीम के लिए एक कतार में रखा जाता था। क्योंकि प्रत्येक व्यक्ति केवल परियोजना के एक छोटे से हिस्से पर काम करता था, इस दृष्टिकोण के कारण स्वामित्व की कमी होती थी। उनका लक्ष्य काम को अगले समूह तक पहुंचाना था, न कि ग्राहक को सही कार्यक्षमता प्रदान करना - प्राथमिकताओं का एक स्पष्ट गलत संरेखण। +परंपरागत रूप से, [टाइटली-कपल्ड](/tightly-coupled-architectures/) [मोनोलिथिक ऐप्स](/monolithic-apps/) का प्रयोग वाले जटिल संगठनों में, काम आम तौर पर कई समूहों के बीच खंडित होता था। इसमें एप्लीकेशन कई टीमों के बीच जाता था और काफी लम्बा समय लगता था। हर बार जब कोई घटक या अपडेट तैयार होता था, तो उसे अगली टीम के लिए एक कतार में रखा जाता था। क्योंकि प्रत्येक व्यक्ति केवल परियोजना के एक छोटे से हिस्से पर काम करता था, इस दृष्टिकोण के कारण स्वामित्व की कमी होती थी। उनका लक्ष्य काम को अगले समूह तक पहुंचाना था, न कि ग्राहक को सही कार्यक्षमता प्रदान करना - प्राथमिकताओं का एक स्पष्ट गलत संरेखण। जब तक कोड अंततः उत्पादन में आया, तब तक यह इतने सारे डेवलपर्स के माध्यम से चला गया, इतनी कतारों में प्रतीक्षा कर रहा था कि यदि कोड काम नहीं करता है तो समस्या की उत्पत्ति का पता लगाना मुश्किल था। DevOps ने इस दृष्टिकोण को पलट कर रख दिया। diff --git a/content/hi/style-guide/_index.md b/content/hi/style-guide/_index.md index 1515fe2433..995dae001d 100644 --- a/content/hi/style-guide/_index.md +++ b/content/hi/style-guide/_index.md @@ -113,7 +113,7 @@ category: अवधारणा जब आपकी परिभाषा में उपयोग किया जाता है, तो हमेशा **मौजूदा शब्दावली शब्दों से लिंक करें** (केवल पहला उल्लेख हाइपरलिंक किया जाना चाहिए)। -**उदाहरण**: [सर्विस मेष परिभाषा](/service_mesh/) के "यह क्या है" अनुभाग पर एक नज़र डालें। यह माइक्रोसर्विसेज, सर्विस, रिलायबिलिटी और ऑब्ज़र्वेबिलिटी परिभाषाओं से वापस जुड़ता है। इसके अतिरिक्त, यह एक माइक्रोसर्विस वातावरण में नेटवर्क चुनौतियों (जिसे गैर तकनिकी लोग नहीं समझ सकते) को wifi समस्या (जिसे लैपटॉप का उपयोग करने वाला कोई भी व्यक्ति समझ सकता है) से तुलना करते हुए एक वास्तविक उदाहरण का उपयोग करता है। जहां संभव हो, इस संबंध को बनाने का प्रयास करें। +**उदाहरण**: [सर्विस मेष परिभाषा](/service-mesh/) के "यह क्या है" अनुभाग पर एक नज़र डालें। यह माइक्रोसर्विसेज, सर्विस, रिलायबिलिटी और ऑब्ज़र्वेबिलिटी परिभाषाओं से वापस जुड़ता है। इसके अतिरिक्त, यह एक माइक्रोसर्विस वातावरण में नेटवर्क चुनौतियों (जिसे गैर तकनिकी लोग नहीं समझ सकते) को wifi समस्या (जिसे लैपटॉप का उपयोग करने वाला कोई भी व्यक्ति समझ सकता है) से तुलना करते हुए एक वास्तविक उदाहरण का उपयोग करता है। जहां संभव हो, इस संबंध को बनाने का प्रयास करें। #### Google या Word दस्तावेज़ से प्रारंभ करें diff --git a/content/it/cloud-native-tech.md b/content/it/cloud-native-tech.md index 878e927b1f..c10fa8aa26 100644 --- a/content/it/cloud-native-tech.md +++ b/content/it/cloud-native-tech.md @@ -6,11 +6,11 @@ category: Concetto ## Cos'è -Le tecnologie _cloud native_, a cui ci si riferisce anche con il termine _cloud native stack_, sono le tecnologie utilizzate per la creazione di [applicazioni _cloud native_](/cloud_native_apps/). Consentendo alle organizzazioni di implementare e gestire applicazioni scalabili in contesti moderni e dinamici quali le piattaforme cloud (pubbliche, private o ibride), mantengono la "promessa del cloud" e sfruttano al massimo i benefici del [_cloud computing_](/cloud_computing/). Sono progettate da zero con l'intento di impiegare le funzionalità di cloud computing e [container](/container/). Il [mesh di servizi](/service_mesh/), i [microservizi](/it/microservices/) e le [infrastrutture immutabili](/immutable_infrastructure/) sono esempi di questo approccio. +Le tecnologie _cloud native_, a cui ci si riferisce anche con il termine _cloud native stack_, sono le tecnologie utilizzate per la creazione di [applicazioni _cloud native_](/cloud-native-apps/). Consentendo alle organizzazioni di implementare e gestire applicazioni scalabili in contesti moderni e dinamici quali le piattaforme cloud (pubbliche, private o ibride), mantengono la "promessa del cloud" e sfruttano al massimo i benefici del [_cloud computing_](/cloud-computing/). Sono progettate da zero con l'intento di impiegare le funzionalità di cloud computing e [container](/container/). Il [mesh di servizi](/service-mesh/), i [microservizi](/it/microservices/) e le [infrastrutture immutabili](/immutable-infrastructure/) sono esempi di questo approccio. ## Quale problema affronta -Il _cloud native stack_ è formato da molte categorie di tecnologie diverse tra loro; ciascuna si propone di risolvere un problema specifico. Consultando il [CNCF Cloud Native Landscape](https://landscape.cncf.io/), potrai renderti conto di quante aree differenti coinvolga. In linea generale, il _cloud native stack_ affronta un gruppo principale di sfide, ossia gli aspetti negativi dei modelli operativi IT tradizionali. Fra gli altri vi sono: la difficoltà di creare applicazioni scalabili, _fault-tolerant_ (tolleranti agli errori) e [_self-healing_](/self_healing/) (auto riparanti), o anche l'utilizzo inefficiente delle risorse. +Il _cloud native stack_ è formato da molte categorie di tecnologie diverse tra loro; ciascuna si propone di risolvere un problema specifico. Consultando il [CNCF Cloud Native Landscape](https://landscape.cncf.io/), potrai renderti conto di quante aree differenti coinvolga. In linea generale, il _cloud native stack_ affronta un gruppo principale di sfide, ossia gli aspetti negativi dei modelli operativi IT tradizionali. Fra gli altri vi sono: la difficoltà di creare applicazioni scalabili, _fault-tolerant_ (tolleranti agli errori) e [_self-healing_](/self-healing/) (auto riparanti), o anche l'utilizzo inefficiente delle risorse. ## In che modo aiuta diff --git a/content/it/cluster.md b/content/it/cluster.md index 902fbdb7ee..874194d8f6 100644 --- a/content/it/cluster.md +++ b/content/it/cluster.md @@ -10,8 +10,8 @@ Un cluster è un gruppo di computer o applicazioni che lavorano insieme verso un ## Quali problematiche affronta -Il software che è in esecuzione su un singolo computer presenta un singolo punto di vulnerabilità: se quel computer si blocca, o qualcuno accidentalmente ne scollega il cavo di alimentazione, parte del sistema critico di business potrebbe andare offline. Ecco perché un software moderno è generalmente sviluppato come [applicazioni distribuite](/distributed_apps/), raggruppate in cluster. +Il software che è in esecuzione su un singolo computer presenta un singolo punto di vulnerabilità: se quel computer si blocca, o qualcuno accidentalmente ne scollega il cavo di alimentazione, parte del sistema critico di business potrebbe andare offline. Ecco perché un software moderno è generalmente sviluppato come [applicazioni distribuite](/distributed-apps/), raggruppate in cluster. ## In che modo aiuta -Le applicazioni distribuite o clusterizzate vengono eseguite su più macchine, eliminando un singolo punto di vulnerabilità. Tuttavia, costruire sistemi distribuiti è davvero difficile e costituisce, infatti, una disciplina informatica a sé stante. La necessità di sistemi globali e anni di prove ed errori hanno portato allo sviluppo di un nuovo tipo di stack tecnologico: le [tecnologie cloud native](/it/cloud_native_tech/). Queste nuove tecnologie sono i pilastri che rendono più facile il mantenimento, il funzionamento e la creazione di sistemi distribuiti. +Le applicazioni distribuite o clusterizzate vengono eseguite su più macchine, eliminando un singolo punto di vulnerabilità. Tuttavia, costruire sistemi distribuiti è davvero difficile e costituisce, infatti, una disciplina informatica a sé stante. La necessità di sistemi globali e anni di prove ed errori hanno portato allo sviluppo di un nuovo tipo di stack tecnologico: le [tecnologie cloud native](/it/cloud-native-tech/). Queste nuove tecnologie sono i pilastri che rendono più facile il mantenimento, il funzionamento e la creazione di sistemi distribuiti. diff --git a/content/it/devops.md b/content/it/devops.md index 25ce5c70b1..5481cc1867 100644 --- a/content/it/devops.md +++ b/content/it/devops.md @@ -10,7 +10,7 @@ DevOps è una metodologia in cui i team sono responsabili dell'intero processo: ## Quali problematiche affronta -Tradizionalmente, nelle organizzazioni complesse con [applicazioni monolitiche](/monolithic_apps/) dai [componenti strettamente accoppiati](/tightly_coupled_architectures/), il lavoro era generalmente frammentato tra più team. Questo portava a numerosi passaggi di mano e a lunghi tempi di consegna. Ogni volta che un componente o un aggiornamento era pronto, veniva messo in coda per il team successivo. Poiché gli individui lavoravano solo su una piccola parte del progetto, questo approccio portava ad una mancanza di ownership (titolarità) sull'intero progetto. Il loro obiettivo era quello di passare il lavoro al gruppo successivo e non di consegnare la giusta funzionalità al cliente - un evidente e chiaro disallineamento delle priorità. +Tradizionalmente, nelle organizzazioni complesse con [applicazioni monolitiche](/monolithic-apps/) dai [componenti strettamente accoppiati](/tightly-coupled-architectures/), il lavoro era generalmente frammentato tra più team. Questo portava a numerosi passaggi di mano e a lunghi tempi di consegna. Ogni volta che un componente o un aggiornamento era pronto, veniva messo in coda per il team successivo. Poiché gli individui lavoravano solo su una piccola parte del progetto, questo approccio portava ad una mancanza di ownership (titolarità) sull'intero progetto. Il loro obiettivo era quello di passare il lavoro al gruppo successivo e non di consegnare la giusta funzionalità al cliente - un evidente e chiaro disallineamento delle priorità. Quando il codice arrivava finalmente in produzione, passava da così tanti sviluppatori, stando in attesa in così tante code, che diventava difficile rintracciare l'origine del problema se il codice non funzionava. DevOps inverte questo approccio. diff --git a/content/it/infrastructure-as-code.md b/content/it/infrastructure-as-code.md index 7e1ac00f05..8e73f98079 100644 --- a/content/it/infrastructure-as-code.md +++ b/content/it/infrastructure-as-code.md @@ -14,4 +14,4 @@ La creazione di applicazioni native sul cloud richiede che l'infrastruttura sia ## In cosa aiuta -Rappresentando le risorse del data center come server, sistemi di bilanciamento del carico e sottoreti come codice, i team operations possono disporre di un'unica fonte di verità per tutte le configurazioni e possono gestire il proprio data center in una pipeline [CI](/continuous_integration/)/[CD](/continuous_delivery/), implementando sistemi di controllo di versione e strategie di deployment. +Rappresentando le risorse del data center come server, sistemi di bilanciamento del carico e sottoreti come codice, i team operations possono disporre di un'unica fonte di verità per tutte le configurazioni e possono gestire il proprio data center in una pipeline [CI](/continuous-integration/)/[CD](/continuous-delivery/), implementando sistemi di controllo di versione e strategie di deployment. diff --git a/content/it/managed-services.md b/content/it/managed-services.md index b3dfd26d46..c9348c146b 100644 --- a/content/it/managed-services.md +++ b/content/it/managed-services.md @@ -6,7 +6,7 @@ category: Tecnologia ## Cos'è -Con _managed service_ si intende un'offerta di servizio da parte di un fornitore che comprende un software assieme alla sua gestione ordinaria e manutenzione. Ne sono esempi i servizi di [Database as a Service](/database_as_a_service/) come RDS di Amazon, o i servizi esterni di monitoring come Datadog. +Con _managed service_ si intende un'offerta di servizio da parte di un fornitore che comprende un software assieme alla sua gestione ordinaria e manutenzione. Ne sono esempi i servizi di [Database as a Service](/database-as-a-service/) come RDS di Amazon, o i servizi esterni di monitoring come Datadog. ## Quali problematiche affronta @@ -14,4 +14,4 @@ La gestione di un software è un'attività complessa, specialmente considerando ## In che modo aiuta -I managed services sono soluzioni pronte da usare subito, che richiedono sforzi limitati dal punto di vista operativo. Consentono alle organizzazioni di esternalizzare le attività che non fanno parte del proprio core business, e connettersi ad esse tramite ben definite interfacce, solitamente seguendo i principi di sviluppo delle [API](/application_programming_interface/). +I managed services sono soluzioni pronte da usare subito, che richiedono sforzi limitati dal punto di vista operativo. Consentono alle organizzazioni di esternalizzare le attività che non fanno parte del proprio core business, e connettersi ad esse tramite ben definite interfacce, solitamente seguendo i principi di sviluppo delle [API](/application-programming-interface/). diff --git a/content/it/microservices.md b/content/it/microservices.md index 3aec99a08c..99456fb0e3 100644 --- a/content/it/microservices.md +++ b/content/it/microservices.md @@ -6,12 +6,12 @@ category: Concetto ## Che cos’è -I microservizi sono un approccio moderno allo sviluppo di applicazioni che sfrutta le tecnologie native del cloud. Sebbene le applicazioni moderne, come Netflix, sembrino essere un'unica app, in realtà sono una raccolta di servizi più piccoli, tutti in stretta collaborazione. Ad esempio, una singola pagina che ti consente di accedere, cercare e visualizzare in anteprima i video è probabilmente alimentata da servizi più piccoli che ne gestiscono ciascuno un aspetto (ad esempio ricerca, autenticazione ed esecuzione di anteprime nel browser). In breve, i microservizi si riferiscono a un modello di architettura dell'applicazione solitamente in contrasto con le [applicazioni monolitiche](/monolithic_apps/). +I microservizi sono un approccio moderno allo sviluppo di applicazioni che sfrutta le tecnologie native del cloud. Sebbene le applicazioni moderne, come Netflix, sembrino essere un'unica app, in realtà sono una raccolta di servizi più piccoli, tutti in stretta collaborazione. Ad esempio, una singola pagina che ti consente di accedere, cercare e visualizzare in anteprima i video è probabilmente alimentata da servizi più piccoli che ne gestiscono ciascuno un aspetto (ad esempio ricerca, autenticazione ed esecuzione di anteprime nel browser). In breve, i microservizi si riferiscono a un modello di architettura dell'applicazione solitamente in contrasto con le [applicazioni monolitiche](/monolithic-apps/). ## Quale problema affronta -I microservizi sono una risposta alle sfide poste dalle applicazioni monolitiche. In genere, le diverse parti di un'applicazione dovranno essere [scalabili](/scalability/) separatamente. Per esempio, un negozio online avrà più visualizzazioni di prodotti che pagamenti. Ciò significa che avrai bisogno di più copie della funzionalità di visualizzazione del prodotto in esecuzione rispetto al pagamento. In un'applicazione monolitica, quei bit di logica non possono essere creati separatamente. Se non riesci a ridimensionare la funzionalità del prodotto individualmente, dovrai duplicare l'intera app con tutti gli altri componenti che non ti servono - un uso inefficiente delle risorse. Le applicazioni monolitiche causano agli sviluppatori di soccombere facilmente alle insidie della progettazione. Poiché tutto il codice è in un unico posto, è più facile rendere quel codice [strettamente accoppiato](/tightly_coupled_architectures/) ed è più difficile applicare il principio della separazione dei contesti. I monoliti spesso richiedono agli sviluppatori di comprendere l'intera base di codice prima di poter essere produttivi. +I microservizi sono una risposta alle sfide poste dalle applicazioni monolitiche. In genere, le diverse parti di un'applicazione dovranno essere [scalabili](/scalability/) separatamente. Per esempio, un negozio online avrà più visualizzazioni di prodotti che pagamenti. Ciò significa che avrai bisogno di più copie della funzionalità di visualizzazione del prodotto in esecuzione rispetto al pagamento. In un'applicazione monolitica, quei bit di logica non possono essere creati separatamente. Se non riesci a ridimensionare la funzionalità del prodotto individualmente, dovrai duplicare l'intera app con tutti gli altri componenti che non ti servono - un uso inefficiente delle risorse. Le applicazioni monolitiche causano agli sviluppatori di soccombere facilmente alle insidie della progettazione. Poiché tutto il codice è in un unico posto, è più facile rendere quel codice [strettamente accoppiato](/tightly-coupled-architectures/) ed è più difficile applicare il principio della separazione dei contesti. I monoliti spesso richiedono agli sviluppatori di comprendere l'intera base di codice prima di poter essere produttivi. ## In che modo aiuta -La separazione delle funzionalità in diversi microservizi ne semplifica la distribuzione, l'aggiornamento e la scalabilità in modo indipendente. Consentendo a diversi team di concentrarsi sulla propria piccola parte di un'applicazione più grande, rende loro più facile per loro lavorare sulle proprie app senza avere un impatto negativo sul resto dell'organizzazione. Sebbene i microservizi risolvano molti problemi, creano anche un sovraccarico operativo, le cose che ti servono per distribuire e tenere traccia del suo aumento per ordine di grandezza, ed altro. Molte [tecnologie cloud native](/it/cloud_native_tech/) mirano a semplificare la distribuzione e la gestione dei microservizi. +La separazione delle funzionalità in diversi microservizi ne semplifica la distribuzione, l'aggiornamento e la scalabilità in modo indipendente. Consentendo a diversi team di concentrarsi sulla propria piccola parte di un'applicazione più grande, rende loro più facile per loro lavorare sulle proprie app senza avere un impatto negativo sul resto dell'organizzazione. Sebbene i microservizi risolvano molti problemi, creano anche un sovraccarico operativo, le cose che ti servono per distribuire e tenere traccia del suo aumento per ordine di grandezza, ed altro. Molte [tecnologie cloud native](/it/cloud-native-tech/) mirano a semplificare la distribuzione e la gestione dei microservizi. diff --git a/content/it/nodes.md b/content/it/nodes.md index aed972a0e7..a8728e808c 100644 --- a/content/it/nodes.md +++ b/content/it/nodes.md @@ -6,11 +6,11 @@ category: Concetto ## Cos'è -Un nodo è un computer che lavora insieme ad altri computer, o nodi, per realizzare un compito comune. Prendi per esempio il tuo portatile, il modem e la stampante. Sono tutti collegati alla tua rete wireless che comunicano e collaborano: ognuno rappresenta un nodo. Nel [cloud computing](/cloud_computing/), un nodo può essere un computer fisico, un computer virtuale (chiamato [VM](/it/virtual_machine/)) o anche un [container](/container/). +Un nodo è un computer che lavora insieme ad altri computer, o nodi, per realizzare un compito comune. Prendi per esempio il tuo portatile, il modem e la stampante. Sono tutti collegati alla tua rete wireless che comunicano e collaborano: ognuno rappresenta un nodo. Nel [cloud computing](/cloud-computing/), un nodo può essere un computer fisico, un computer virtuale (chiamato [VM](/it/virtual-machine/)) o anche un [container](/container/). ## Quali problematiche affronta -Un'applicazione potrebbe (e in molti casi è così) girare su una singola macchina, ma ci sono alcuni rischi legati a questo. Il malfunzionamento del sistema sottostante, ad esempio, potrebbe interrompere l'esecuzione dell'applicazione. Per risolvere questo problema, gli sviluppatori hanno iniziato a creare [applicazioni distribuite](/distributed_apps/) dove ogni processo viene eseguito su un nodo differente. Perciò, i nodi che eseguono le applicazioni o processi come parte di un gruppo formano un [cluster](/it/cluster/), o gruppo di nodi che lavorano insieme per raggiungere un obiettivo comune. +Un'applicazione potrebbe (e in molti casi è così) girare su una singola macchina, ma ci sono alcuni rischi legati a questo. Il malfunzionamento del sistema sottostante, ad esempio, potrebbe interrompere l'esecuzione dell'applicazione. Per risolvere questo problema, gli sviluppatori hanno iniziato a creare [applicazioni distribuite](/distributed-apps/) dove ogni processo viene eseguito su un nodo differente. Perciò, i nodi che eseguono le applicazioni o processi come parte di un gruppo formano un [cluster](/it/cluster/), o gruppo di nodi che lavorano insieme per raggiungere un obiettivo comune. ## In che modo aiuta diff --git a/content/it/platform-as-a-service.md b/content/it/platform-as-a-service.md index dffcfcaa62..7bdd681ce5 100644 --- a/content/it/platform-as-a-service.md +++ b/content/it/platform-as-a-service.md @@ -10,7 +10,7 @@ Una Platform as a Service, o PaaS, è una piattaforma esterna ai team di svilupp ## Quali problematiche affronta -Per sfruttare i modelli nativi del cloud come i [microservizi](/microservices/) o le [applicazioni distribuite](/distributed_apps/), i team delle operation e gli sviluppatori devono essere in grado di esternalizzare una quantità significativa di operazioni e lavori di manutenzione. Questi includono attività come il provisioning dell'infrastruttura, la gestione dell'[individuazione dei servizi](/service_discovery/), il bilanciamento del carico e la [scalabilità](/scalability/) delle applicazioni. +Per sfruttare i modelli nativi del cloud come i [microservizi](/microservices/) o le [applicazioni distribuite](/distributed-apps/), i team delle operation e gli sviluppatori devono essere in grado di esternalizzare una quantità significativa di operazioni e lavori di manutenzione. Questi includono attività come il provisioning dell'infrastruttura, la gestione dell'[individuazione dei servizi](/service-discovery/), il bilanciamento del carico e la [scalabilità](/scalability/) delle applicazioni. ## In che modo aiuta diff --git a/content/it/style-guide/_index.md b/content/it/style-guide/_index.md index f428b9a27d..667610ac8a 100644 --- a/content/it/style-guide/_index.md +++ b/content/it/style-guide/_index.md @@ -11,11 +11,11 @@ Questa guida ti aiuterà a comprendere chi sono i destinatari del Glossario, la Il Glossario Cloud Native rispetta la [Guida di Stile](https://github.com/cncf/foundation/blob/master/style-guide.md) del repository CNCF, ma si è posto regole aggiuntive e specifiche: 1. Usa un linguaggio semplice, accessibile e che eviti tecnicismi spinti e buzzwords -2. Evita un linguaggio eccessivamente colloquiale -3. Usa un linguaggio concreto ed espressioni letterali +2. [Evita un linguaggio eccessivamente colloquiale](https://en.wikipedia.org/wiki/Colloquialism) +3. [Usa un linguaggio concreto ed espressioni letterali](https://guidetogrammar.org/grammar/composition/abstract.htm) 4. Fai attenzione agli accenti, alla correlazione dei tempi verbali e alla punteggiatura -5. Prediligi la forma attiva -6. Utilizza preferibilmente la forma affermativa +5. [Prediligi la forma attiva](https://www.ef.com/ca/english-resources/english-grammar/passive-voice/) +6. [Utilizza preferibilmente la forma affermativa](https://examples.yourdictionary.com/positive-sentence-examples.html) 7. Non eccedere con le parentesi 8. Non esagerare 9. Evita le ripetizioni @@ -115,7 +115,7 @@ Quando opportuno, fa' riferimenti ad **esempi reali** che aiutino i lettori (sop Se vengono menzionati lemmi che sono già disponibili, ricordati di **inserire un link alla definizione presente nel Glossario** (è sufficiente farlo solo la prima volta che viene usato nel testo). -**Esempio**: dà un'occhiata al paragrafo "Cos'è" del [lemma service mesh](/service_mesh/). Se noti, contiene link ai termini microservices, service, reliability e observability. Inoltre, il confronto tra le criticità del network in un ambiente a microservizi (qualcosa di tecnico con cui è difficile relazionarsi da non tecnici) con le problematiche di una rete wi-fi (un esempio che chiunque usi un portatile può capire) permette una migliore comprensione generale. Quando possibile, cerca di individuare una connessione simile tra i due mondi. +**Esempio**: dà un'occhiata al paragrafo "Cos'è" del [lemma service mesh](/service-mesh/). Se noti, contiene link ai termini microservices, service, reliability e observability. Inoltre, il confronto tra le criticità del network in un ambiente a microservizi (qualcosa di tecnico con cui è difficile relazionarsi da non tecnici) con le problematiche di una rete wi-fi (un esempio che chiunque usi un portatile può capire) permette una migliore comprensione generale. Quando possibile, cerca di individuare una connessione simile tra i due mondi. #### Inizia con un Word o un Google doc diff --git a/content/it/virtual-machine.md b/content/it/virtual-machine.md index 7e3f3459ed..b603cf8e68 100644 --- a/content/it/virtual-machine.md +++ b/content/it/virtual-machine.md @@ -10,7 +10,7 @@ Una macchina virtuale (VM) è un computer e il suo sistema operativo che non è ## Quale problema affronta -Le macchine virtuali sfruttano la virtualizzazione. Quando una macchina [bare metal](/bare_metal_machine/) è vincolata a un singolo sistema operativo (OS), il modo in cui le risorse della macchina possono essere utilizzate è alquanto limitato. Inoltre, quando un sistema operativo è legato a una singola macchina fisica, la sua disponibilità è direttamente legata a quell'hardware. Se la macchina fisica è offline a causa di manutenzione o guasti hardware, lo è anche il sistema operativo. +Le macchine virtuali sfruttano la virtualizzazione. Quando una macchina [bare metal](/bare-metal-machine/) è vincolata a un singolo sistema operativo (OS), il modo in cui le risorse della macchina possono essere utilizzate è alquanto limitato. Inoltre, quando un sistema operativo è legato a una singola macchina fisica, la sua disponibilità è direttamente legata a quell'hardware. Se la macchina fisica è offline a causa di manutenzione o guasti hardware, lo è anche il sistema operativo. ## In che modo aiuta diff --git a/content/ko/cloud-native-apps.md b/content/ko/cloud-native-apps.md index b97b29c42b..816b35fe24 100644 --- a/content/ko/cloud-native-apps.md +++ b/content/ko/cloud-native-apps.md @@ -6,11 +6,11 @@ category: 개념 ## 개념 -클라우드 네이티브 애플리케이션은 [클라우드 컴퓨팅](/ko/cloud_computing/)의 혁신을 활용하도록 특화 설계되었다. 이러한 애플리케이션은 각각의 클라우드 아키텍처와 쉽게 통합되며, 클라우드의 리소스와 [확장](/scalability/) 기능을 활용한다. 또한 클라우드 네이티브 애플리케이션은 클라우드 컴퓨팅 기반 인프라의 혁신을 활용하는 애플리케이션을 의미한다. 오늘날 클라우드 네이티브 애플리케이션은 클라우드 공급자의 데이터센터에서 실행되는 앱과 온프레미스(on-premises) 클라우드 네이티브 플랫폼에서 실행되는 앱을 포함한다. +클라우드 네이티브 애플리케이션은 [클라우드 컴퓨팅](/ko/cloud-computing/)의 혁신을 활용하도록 특화 설계되었다. 이러한 애플리케이션은 각각의 클라우드 아키텍처와 쉽게 통합되며, 클라우드의 리소스와 [확장](/scalability/) 기능을 활용한다. 또한 클라우드 네이티브 애플리케이션은 클라우드 컴퓨팅 기반 인프라의 혁신을 활용하는 애플리케이션을 의미한다. 오늘날 클라우드 네이티브 애플리케이션은 클라우드 공급자의 데이터센터에서 실행되는 앱과 온프레미스(on-premises) 클라우드 네이티브 플랫폼에서 실행되는 앱을 포함한다. ## 다루는 문제 -전통적으로, 온프레미스 환경은 상당한 맞춤형 방식으로 컴퓨팅 리소스를 제공했다. 각 데이터센터는 애플리케이션이 특정 환경에 [강결합(tightly coupled)](/tightly_coupled_architectures/)된 형태의 서비스를 실행하고 있었으며, [가상 머신](/ko/virtual_machine/) 및 서비스와 같은 인프라에 대한 수동 프로비저닝에 크게 의존하는 경우가 많았다. 이는 결과적으로 개발자와 해당 애플리케이션이 특정 데이터센터를 사용하도록 한정시켰다. 클라우드용으로 설계되지 않은 애플리케이션은 클라우드 환경의 탄력성과 확장성 기능을 활용할 수 없었다. 예를 들어, 정상적으로 실행하기 위해 수동 개입이 필요한 앱은 자동으로 확장할 수 없으며, 오류 발생 시 자동으로 다시 실행할 수도 없다. +전통적으로, 온프레미스 환경은 상당한 맞춤형 방식으로 컴퓨팅 리소스를 제공했다. 각 데이터센터는 애플리케이션이 특정 환경에 [강결합(tightly coupled)](/tightly-coupled-architectures/)된 형태의 서비스를 실행하고 있었으며, [가상 머신](/ko/virtual-machine/) 및 서비스와 같은 인프라에 대한 수동 프로비저닝에 크게 의존하는 경우가 많았다. 이는 결과적으로 개발자와 해당 애플리케이션이 특정 데이터센터를 사용하도록 한정시켰다. 클라우드용으로 설계되지 않은 애플리케이션은 클라우드 환경의 탄력성과 확장성 기능을 활용할 수 없었다. 예를 들어, 정상적으로 실행하기 위해 수동 개입이 필요한 앱은 자동으로 확장할 수 없으며, 오류 발생 시 자동으로 다시 실행할 수도 없다. ## 문제 해결 방식 diff --git a/content/ko/cloud-native-tech.md b/content/ko/cloud-native-tech.md index eb1ce9e0ff..6a11cf95e7 100644 --- a/content/ko/cloud-native-tech.md +++ b/content/ko/cloud-native-tech.md @@ -6,7 +6,7 @@ category: 개념 ## 개념 -클라우드 네이티브 스택(the cloud native stack)이라고도 하는 클라우드 네이티브 기술은 [클라우드 네이티브 애플리케이션](/cloud_native_apps/)을 구축하는 데 사용되는 기술이다. 조직이 퍼블릭, 프라이빗 및 하이브리드 클라우드와 같은 현대적이고 역동적인 환경에서 확장 가능한 애플리케이션을 구축 및 실행할 수 있도록 함으로써, '클라우드의 약속(promise of the cloud)'을 지키고 클라우드 컴퓨팅 이점을 최대한 활용하게 한다. 이 기술은 클라우드 컴퓨팅 및 컨테이너, 서비스 메시(mesh), 마이크로서비스(microservices), 이뮤터블 인프라(immutable infrastructure)의 특징 및 기능(capabilities)을 활용하도록 처음부터 설계되었다. +클라우드 네이티브 스택(the cloud native stack)이라고도 하는 클라우드 네이티브 기술은 [클라우드 네이티브 애플리케이션](/cloud-native-apps/)을 구축하는 데 사용되는 기술이다. 조직이 퍼블릭, 프라이빗 및 하이브리드 클라우드와 같은 현대적이고 역동적인 환경에서 확장 가능한 애플리케이션을 구축 및 실행할 수 있도록 함으로써, '클라우드의 약속(promise of the cloud)'을 지키고 클라우드 컴퓨팅 이점을 최대한 활용하게 한다. 이 기술은 클라우드 컴퓨팅 및 컨테이너, 서비스 메시(mesh), 마이크로서비스(microservices), 이뮤터블 인프라(immutable infrastructure)의 특징 및 기능(capabilities)을 활용하도록 처음부터 설계되었다. ## 다루는 문제 diff --git a/content/ko/containerization.md b/content/ko/containerization.md index 0b7e6b12bc..4f46c85cc4 100644 --- a/content/ko/containerization.md +++ b/content/ko/containerization.md @@ -10,7 +10,7 @@ category: 기술 ## 다루는 문제 -컨테이너가 보편화되기 전에는, 단일 [베어메탈 머신](/bare_metal_machine/) 상에 여러 애플리케이션을 오케스트레이션(orchestration) 하기 위해 가상 머신(VM)에 의존했다. VM은 컨테이너보다 훨씬 크며 이를 실행하기 위해 하이퍼바이저(hypervisor)를 필요로 한다. 상대적으로 크기가 큰 VM 템플릿(template)을 저장, 백업, 전송해야 하기 때문에, VM 템플릿을 생성하는 속도 또한 느리다. 추가적으로, VM은 [불변성(immutability)](/immutable_infrastructure/) 원칙에 위배되는 구성 변경(configuration drift) 문제를 겪을 수도 있다. +컨테이너가 보편화되기 전에는, 단일 [베어메탈 머신](/bare-metal-machine/) 상에 여러 애플리케이션을 오케스트레이션(orchestration) 하기 위해 가상 머신(VM)에 의존했다. VM은 컨테이너보다 훨씬 크며 이를 실행하기 위해 하이퍼바이저(hypervisor)를 필요로 한다. 상대적으로 크기가 큰 VM 템플릿(template)을 저장, 백업, 전송해야 하기 때문에, VM 템플릿을 생성하는 속도 또한 느리다. 추가적으로, VM은 [불변성(immutability)](/immutable-infrastructure/) 원칙에 위배되는 구성 변경(configuration drift) 문제를 겪을 수도 있다. ## 문제 해결 방식 diff --git a/content/ko/devops.md b/content/ko/devops.md index ab16b201b8..df87514ee5 100644 --- a/content/ko/devops.md +++ b/content/ko/devops.md @@ -10,7 +10,7 @@ DevOps(데브옵스)는 각 팀이 애플리케이션 개발(development)부터 ## 다루는 문제 -전통적으로, [긴밀하게 연결된](/tightly_coupled_architectures/) [모놀리식 앱](/ko/monolithic_apps/)을 관리하는 복잡한 조직에서의 업무는, 일반적으로 여러 그룹 사이에서 파편화(fragmented)되었다. 이로 인해 수많은 핸드오프와 긴 리드 타임(lead time)이 발생했다. 구성 요소 또는 업데이트가 준비될 때마다, 그것이 다음 팀의 대기열에 배치되었다. 각 개인이 프로젝트의 작은 부분에 대해서만 작업을 수행했기 때문에 이러한 접근 방식은 오너십 부족으로 이어졌다. 그들의 목표는 고객에게 올바른 기능을 제공하는 것이 아니라 다음 그룹에 작업을 잘 전달하는 것으로 바뀌었는데, 이는 명백한 우선순위의 불일치였다. +전통적으로, [긴밀하게 연결된](/tightly-coupled-architectures/) [모놀리식 앱](/ko/monolithic-apps/)을 관리하는 복잡한 조직에서의 업무는, 일반적으로 여러 그룹 사이에서 파편화(fragmented)되었다. 이로 인해 수많은 핸드오프와 긴 리드 타임(lead time)이 발생했다. 구성 요소 또는 업데이트가 준비될 때마다, 그것이 다음 팀의 대기열에 배치되었다. 각 개인이 프로젝트의 작은 부분에 대해서만 작업을 수행했기 때문에 이러한 접근 방식은 오너십 부족으로 이어졌다. 그들의 목표는 고객에게 올바른 기능을 제공하는 것이 아니라 다음 그룹에 작업을 잘 전달하는 것으로 바뀌었는데, 이는 명백한 우선순위의 불일치였다. 코드가 마침내 프로덕션으로 배치될 쯤이면, 그 코드가 정말 많은 대기열과 개발자들을 거쳤기 때문에, 만약 코드가 동작하지 않는다면 문제의 원인을 추적하기가 어려웠다. DevOps는 이러한 접근 방식을 완전히 뒤집는다. diff --git a/content/ko/microservices.md b/content/ko/microservices.md index 269d6749cb..1dde83769f 100644 --- a/content/ko/microservices.md +++ b/content/ko/microservices.md @@ -9,7 +9,7 @@ category: 개념 마이크로서비스(microservices)는 애플리케이션 개발에 대한 근래의 접근 방법으로 클라우드 네이티브(cloud native) 기술을 활용한다. 넷플릭스(Netflix)와 같은 최신의 애플리케이션들은 단일 앱처럼 보이지만, 실제로는 모두 긴밀하게 동작하는 작은 서비스들의 모음이다. 예를 들어, 영상에 접속하고, 검색하며, 미리보기 할 수 있는 단일 페이지는 각 기능을 처리하는 더욱 작은 단위의 서비스들(예, 브라우저상에서 검색, 인증 및 미리보기 실행)에 의해 구동될 수 있다. -간단히 말해서, 마이크로서비스는 [모놀리식 애플리케이션(monolithic applications)](/monolithic_apps/)에 대조되는 애플리케이션 아키텍처 패턴을 나타낸다. +간단히 말해서, 마이크로서비스는 [모놀리식 애플리케이션(monolithic applications)](/monolithic-apps/)에 대조되는 애플리케이션 아키텍처 패턴을 나타낸다. ## 다루는 문제 @@ -20,7 +20,7 @@ category: 개념 모놀리식 애플리케이션에서는, 이러한 논리적인 기능 부분들을 나누어 배치할 수 없다. 만약 제품을 각 기능별로 확장할 수 없다면, 전체 애플리케이션을 중복 배치해야 하고 이것에는 필수가 아닌 모든 기능요소(components)가 포함되므로 비효율적으로 자원을 사용하게 된다. 또한, 모놀리식 애플리케이션은 설계상의 잠재적 위험을 개발자가 쉽게 묵인(succumb)하도록 만든다. -모든 코드가 한 곳에 있으므로, 코드가 [강결합(tightly-coupled)](/tightly_coupled_architectures/)되기 쉽고, 주요 사항(concerns) 별로 분리하는 원리를 적용하기 더욱 어려워진다. +모든 코드가 한 곳에 있으므로, 코드가 [강결합(tightly-coupled)](/tightly-coupled-architectures/)되기 쉽고, 주요 사항(concerns) 별로 분리하는 원리를 적용하기 더욱 어려워진다. 대개 모놀리스는 개발자가 전체 코드베이스를 이해해야 하며 그 이후 성과를 낼 수 있다. ## 문제 해결 방식 @@ -28,4 +28,4 @@ category: 개념 기능을 서로 다른 마이크로서비스로 분리하면 독립적으로 배치, 업데이트 및 확장하기 더욱 쉬워진다. 서로 다른 팀들이 큰 애플리케이션 중 각자가 맡은 작은 부분에 집중하게 되면, 맡은 부분 이외의 구조 및 체계(organization)에 부정적으로 영향을 끼치지 않으면서 더 쉽게 앱 관련 작업을 수행할 수 있다. 마이크로서비스가 많은 문제를 해결하였지만, 운영적 오버헤드 또한 만들어 낸다. 즉, 배포하고 추적해야 할 것들이 지수적 혹은 그 이상으로 증가한다. -여러 [클라우드 네이티브 기술(cloud-native technologies)](/cloud_native_tech/)은 마이크로서비스를 더욱 쉽게 배치하고 관리할 수 있게 하는 것을 목표로 삼고 있다. +여러 [클라우드 네이티브 기술(cloud-native technologies)](/cloud-native-tech/)은 마이크로서비스를 더욱 쉽게 배치하고 관리할 수 있게 하는 것을 목표로 삼고 있다. diff --git a/content/ko/style-guide/_index.md b/content/ko/style-guide/_index.md index d4deb4a787..7ff58239c2 100644 --- a/content/ko/style-guide/_index.md +++ b/content/ko/style-guide/_index.md @@ -120,7 +120,7 @@ category: Concept 이미 존재하는 용어집 용어를 문서에 사용한 경우, **해당 용어집 용어로 링크를 건다** (맨 처음 언급에만 링크를 걸어야 한다). -**예시**: [서비스 메시(service mesh) 정의](/ko/service_mesh/)의 "개념" 섹션을 참고한다. 마이크로서비스, 서비스, 안정성, 관찰 가능성(observability) 항목으로 가는 링크가 존재한다. 또한, 마이크로서비스 환경의 네트워크 문제(기술적이지 않은 사람은 이해할 수 없음)와 Wi-Fi 문제(노트북을 사용하는 사람이면 누구나 이해할 수 있음)를 비교하는 실제 사례를 사용한다. 가능한 경우, 이러한 연관 관계를 소개한다. +**예시**: [서비스 메시(service mesh) 정의](/ko/service-mesh/)의 "개념" 섹션을 참고한다. 마이크로서비스, 서비스, 안정성, 관찰 가능성(observability) 항목으로 가는 링크가 존재한다. 또한, 마이크로서비스 환경의 네트워크 문제(기술적이지 않은 사람은 이해할 수 없음)와 Wi-Fi 문제(노트북을 사용하는 사람이면 누구나 이해할 수 있음)를 비교하는 실제 사례를 사용한다. 가능한 경우, 이러한 연관 관계를 소개한다. #### Google 또는 Word 문서로 시작 diff --git a/content/ko/virtual-machine.md b/content/ko/virtual-machine.md index 01f50e5ffa..2f0fe0c926 100644 --- a/content/ko/virtual-machine.md +++ b/content/ko/virtual-machine.md @@ -7,13 +7,13 @@ category: 기술 ## 개념 가상 머신(VM, virtual machine)은 특정 하드웨어에 구속(종속)되지 않는 컴퓨터 및 해당 운영 체제(operating system)이다. -VM은 [가상화(virtualization)](https://glossary.cncf.io/virtualization/)를 필요로 하는데 이는 단일 물리 컴퓨터를 여러 대의 가상 컴퓨터로 분할하기 위함이다. +VM은 [가상화(virtualization)](/virtualization/)를 필요로 하는데 이는 단일 물리 컴퓨터를 여러 대의 가상 컴퓨터로 분할하기 위함이다. 이러한 분할을 통해 조직(organization)과 인프라스트럭처 제공자(infrastructure provider)는 하드웨어에 영향을 주지 않고 VM을 쉽게 생성 및 삭제할 수 있다. ## 다루는 문제 가상 머신은 가상화를 활용한다. -[베어 메탈(bare metal)](https://glossary.cncf.io/bare_metal_machine/) 머신이 단일 운영 체제에 구속(종속)되면 머신의 자원을 효율적으로 활용하는데 다소 제약이 있다. +[베어 메탈(bare metal)](/bare-metal-machine/) 머신이 단일 운영 체제에 구속(종속)되면 머신의 자원을 효율적으로 활용하는데 다소 제약이 있다. 또한, 운영 체제가 단일 물리 머신에 구속(종속)되는 경우, 운영 체제의 이용 가능성은 해당 하드웨어에 직결된다. 만약 물리 머신이 유지 관리 또는 하드웨어 오류로 인해 오프라인 상태가 되면, 운영 체제도 오프라인 상태가 된다. diff --git a/content/pt-br/api-gateway.md b/content/pt-br/api-gateway.md index 90f932ee0c..aafd49f0d1 100644 --- a/content/pt-br/api-gateway.md +++ b/content/pt-br/api-gateway.md @@ -6,7 +6,7 @@ category: conceito ## O que é -Um gateway de [API](/pt-br/application_programming_interface/) é uma ferramenta que agrega aplicações APIs exclusivas, tornando-as todas disponíveis em um só lugar. Ele permite que as organizações movam funções importantes, como autenticação e autorização ou limitação do número de solicitações entre aplicativos, para um local com gerenciamento centralizado. Um gateway de API funciona como uma interface comum para consumidores de API (geralmente externos). +Um gateway de [API](/pt-br/application-programming-interface/) é uma ferramenta que agrega aplicações APIs exclusivas, tornando-as todas disponíveis em um só lugar. Ele permite que as organizações movam funções importantes, como autenticação e autorização ou limitação do número de solicitações entre aplicativos, para um local com gerenciamento centralizado. Um gateway de API funciona como uma interface comum para consumidores de API (geralmente externos). ## Problema relacionado diff --git a/content/pt-br/bare-metal-machine.md b/content/pt-br/bare-metal-machine.md index dfe73755c4..9a1d29c16f 100644 --- a/content/pt-br/bare-metal-machine.md +++ b/content/pt-br/bare-metal-machine.md @@ -6,7 +6,7 @@ category: tecnologia ## O que é -Bare metal refere-se a um computador físico, mais especificamente um servidor, que tem um, e apenas um sistema operacional. A distinção é importante na computação moderna porque muitos, se não a maioria, servidores são [máquinas virtuais](/virtual_machine/). Um servidor físico geralmente é um computador com grande capacidade e com hardware embutido. Instalar um sistema operacional e executar aplicativos diretamente nesse hardware físico, sem [virtualização](/virtualization/), é conhecido como executar em “bare metal”. +Bare metal refere-se a um computador físico, mais especificamente um servidor, que tem um, e apenas um sistema operacional. A distinção é importante na computação moderna porque muitos, se não a maioria, servidores são [máquinas virtuais](/virtual-machine/). Um servidor físico geralmente é um computador com grande capacidade e com hardware embutido. Instalar um sistema operacional e executar aplicativos diretamente nesse hardware físico, sem [virtualização](/virtualization/), é conhecido como executar em “bare metal”. ## Problema relacionado @@ -16,4 +16,4 @@ Instalar um sistema operacional em um computador físico é o padrão original d Ao dedicar todos os recursos de computação de um computador a um único sistema operacional, você potencialmente fornece o melhor desempenho possível ao sistema operacional. Se você precisa executar uma carga alta de trabalho que deve ter acesso extremamente rápido aos recursos de hardware, o bare metal pode ser a solução ideal. -No contexto de [aplicações nativas em nuvem](/pt-br/cloud_native_apps/), geralmente pensamos em desempenho em termos de [escala](/scalability/) para um grande número de eventos simultâneos, que podem ser tratados por [escala horizontal](/horizontal_scaling/) (adicionando mais máquinas ao recursos disponíveis). Mas algumas cargas de trabalho podem exigir um redimensionamento vertical (adicionando mais energia a uma máquina física existente) e/ou uma resposta extremamente rápida de um hardware físico, caso em que o bare metal é mais adequado. Bare metal também permite que você ajuste o hardware físico e possivelmente até os drivers do hardware para melhorar a realização da sua tarefa. +No contexto de [aplicações nativas em nuvem](/pt-br/cloud-native-apps/), geralmente pensamos em desempenho em termos de [escala](/scalability/) para um grande número de eventos simultâneos, que podem ser tratados por [escala horizontal](/horizontal-scaling/) (adicionando mais máquinas ao recursos disponíveis). Mas algumas cargas de trabalho podem exigir um redimensionamento vertical (adicionando mais energia a uma máquina física existente) e/ou uma resposta extremamente rápida de um hardware físico, caso em que o bare metal é mais adequado. Bare metal também permite que você ajuste o hardware físico e possivelmente até os drivers do hardware para melhorar a realização da sua tarefa. diff --git a/content/pt-br/cloud-native-apps.md b/content/pt-br/cloud-native-apps.md index c31102528e..e183b1126f 100644 --- a/content/pt-br/cloud-native-apps.md +++ b/content/pt-br/cloud-native-apps.md @@ -6,11 +6,11 @@ category: conceito ## O que é -As aplicações nativas em nuvem são projetadas especificamente para aproveitar as inovações em [computação em nuvem](/cloud_computing/). Essas aplicações se integram facilmente às suas respectivas arquiteturas de nuvem, aproveitando, assim, os recursos e o [dimensionamento](/scalability/) da nuvem. Também se refere a aplicativos que aproveitam as inovações da infraestrutura impulsionadas pela computação em nuvem. Hoje, as aplicações nativas em nuvem incluem aplicativos que são executados tanto em datacenter de um provedor de nuvem pública, quanto em plataformas de nuvens privadas. +As aplicações nativas em nuvem são projetadas especificamente para aproveitar as inovações em [computação em nuvem](/cloud-computing/). Essas aplicações se integram facilmente às suas respectivas arquiteturas de nuvem, aproveitando, assim, os recursos e o [dimensionamento](/scalability/) da nuvem. Também se refere a aplicativos que aproveitam as inovações da infraestrutura impulsionadas pela computação em nuvem. Hoje, as aplicações nativas em nuvem incluem aplicativos que são executados tanto em datacenter de um provedor de nuvem pública, quanto em plataformas de nuvens privadas. ## Problema relacionado -Tradicionalmente, os ambientes locais forneciam recursos de computação de maneira bastante personalizada. Cada datacenter tinha seus serviços [fortemente acomplados](/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](/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 acomplados](/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](/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/cloud-native-security.md b/content/pt-br/cloud-native-security.md index 9da6a82c79..e8a9475f80 100644 --- a/content/pt-br/cloud-native-security.md +++ b/content/pt-br/cloud-native-security.md @@ -6,7 +6,7 @@ category: conceito ## O que é -A segurança nativa da nuvem é uma abordagem que transforma a segurança em [aplicações nativas em nuvem](/pt-br/cloud_native_apps/). Isso garante que a segurança faça parte de todo o ciclo de vida do aplicativo, desde o desenvolvimento até a produção. A segurança nativa da nuvem busca garantir os mesmos padrões que os modelos de segurança tradicionais, enquanto se adapta aos detalhes dos ambientes nativos da nuvem, ou seja, mudanças rápidas de código e infraestrutura altamente efêmera. A segurança nativa da nuvem está altamente relacionada à prática chamada [DevSecOps](/devsecops/). +A segurança nativa da nuvem é uma abordagem que transforma a segurança em [aplicações nativas em nuvem](/pt-br/cloud-native-apps/). Isso garante que a segurança faça parte de todo o ciclo de vida do aplicativo, desde o desenvolvimento até a produção. A segurança nativa da nuvem busca garantir os mesmos padrões que os modelos de segurança tradicionais, enquanto se adapta aos detalhes dos ambientes nativos da nuvem, ou seja, mudanças rápidas de código e infraestrutura altamente efêmera. A segurança nativa da nuvem está altamente relacionada à prática chamada [DevSecOps](/devsecops/). ## Problema relacionado diff --git a/content/pt-br/cluster.md b/content/pt-br/cluster.md index b52cbbf522..b8f96d9e3e 100644 --- a/content/pt-br/cluster.md +++ b/content/pt-br/cluster.md @@ -4,14 +4,14 @@ status: Completed category: conceito --- -## O que é +## O que é Um cluster é um grupo de máquinas ou aplicações que trabalham juntos para um objetivo comum. No contexto da computação nativa em nuvem, o termo é mais frequentemente aplicado ao Kubernetes. Um cluster Kubernetes é um conjunto de serviços (ou cargas de trabalho) executados em seus próprios contêineres, geralmente em máquinas diferentes. O conjunto de todos esses serviços [contêinerizados](/pt-br/containerization/), conectados em uma rede, representam um cluster. ## Problema relacionado -Um software executado em uma única máquina, apresenta um único ponto de falha, por exemplo, se essa máquina travar ou alguém desconectar acidentalmente o cabo de alimentação, algum sistema crítico para os negócios pode ficar offline. É por isso que os softwares modernos geralmente são construídos como [sistemas distribuídos](/distributed_apps/), agrupados em clusters. +Um software executado em uma única máquina, apresenta um único ponto de falha, por exemplo, se essa máquina travar ou alguém desconectar acidentalmente o cabo de alimentação, algum sistema crítico para os negócios pode ficar offline. É por isso que os softwares modernos geralmente são construídos como [sistemas distribuídos](/distributed-apps/), agrupados em clusters. ## Como isso ajuda -Aplicações distribuídas em cluster são executadas em várias máquinas, eliminando um único ponto de falha. Mas construir sistemas distribuídos é muito difícil. Na verdade, é uma disciplina de ciência da computação com suas especificidades. A necessidade de sistemas globais e anos de tentativa e erro levaram ao desenvolvimento de um novo tipo de *stack* de tecnologia: [tecnologias nativas da nuvem](/cloud_native_tech/). Essas novas tecnologias são as peças chaves que facilitam a operação e a criação de sistemas distribuídos. +Aplicações distribuídas em cluster são executadas em várias máquinas, eliminando um único ponto de falha. Mas construir sistemas distribuídos é muito difícil. Na verdade, é uma disciplina de ciência da computação com suas especificidades. A necessidade de sistemas globais e anos de tentativa e erro levaram ao desenvolvimento de um novo tipo de *stack* de tecnologia: [tecnologias nativas da nuvem](/cloud-native-tech/). Essas novas tecnologias são as peças chaves que facilitam a operação e a criação de sistemas distribuídos. diff --git a/content/pt-br/containerization.md b/content/pt-br/containerization.md index 31dfe5ca35..ea919cad3f 100644 --- a/content/pt-br/containerization.md +++ b/content/pt-br/containerization.md @@ -10,7 +10,7 @@ A conteinerização é o processo de agrupar uma aplicação e suas dependência ## Problema relacionado -Antes que o uso de contêineres se tornasse mais comum , as organizações usavam máquinas virtuais (VMs) para orquestrar várias aplicações em uma única [máquina bare metal](/pt-br/bare_metal_machine/). As VMs são significativamente maiores que os contêineres e exigem um *hypervisor* para serem executados. Devido ao armazenamento, backup e transferência desses *templates* de VM maiores, a criação dos *templates* de VM também é lenta. Além disso, as VMs podem sofrer inconsistências nas configurações, o que viola o princípio da [imutabilidade](/immutable_infrastructure/). +Antes que o uso de contêineres se tornasse mais comum , as organizações usavam máquinas virtuais (VMs) para orquestrar várias aplicações em uma única [máquina bare metal](/pt-br/bare-metal-machine/). As VMs são significativamente maiores que os contêineres e exigem um *hypervisor* para serem executados. Devido ao armazenamento, backup e transferência desses *templates* de VM maiores, a criação dos *templates* de VM também é lenta. Além disso, as VMs podem sofrer inconsistências nas configurações, o que viola o princípio da [imutabilidade](/immutable-infrastructure/). ## Como isso ajuda diff --git a/content/pt-br/continuous-delivery.md b/content/pt-br/continuous-delivery.md index 566b6f6000..74e9f69110 100644 --- a/content/pt-br/continuous-delivery.md +++ b/content/pt-br/continuous-delivery.md @@ -14,4 +14,4 @@ Implantar atualizações [confiáveis](/reliability/) se torna um problema em es ## Como isso ajuda -As estratégias de entrega contínua criam um caminho totalmente automatizado para a produção que testa e implanta o software usando várias estratégias de implantação, como versões [canary](/pt-br/canary_deployment/) ou [blue-green](/pt-br/blue_green_deployment/). Isso permite que os desenvolvedores implantem o código com frequência, dando a tranquilidade de que a nova revisão foi testada. Normalmente, o desenvolvimento *trunk-based* é usado em estratégias de entrega contínua, em oposição aos recursos de *branch* ou *pull requests*. +As estratégias de entrega contínua criam um caminho totalmente automatizado para a produção que testa e implanta o software usando várias estratégias de implantação, como versões [canary](/pt-br/canary-deployment/) ou [blue-green](/pt-br/blue-green-deployment/). Isso permite que os desenvolvedores implantem o código com frequência, dando a tranquilidade de que a nova revisão foi testada. Normalmente, o desenvolvimento *trunk-based* é usado em estratégias de entrega contínua, em oposição aos recursos de *branch* ou *pull requests*. diff --git a/content/pt-br/continuous-integration.md b/content/pt-br/continuous-integration.md index 1c28e59603..6fac1fac6c 100644 --- a/content/pt-br/continuous-integration.md +++ b/content/pt-br/continuous-integration.md @@ -4,9 +4,9 @@ status: Completed category: conceito --- -## O que é +## O que é -A integração contínua (continuous integration - CI), é a prática de integrar mudanças de código da maneira mais regular possível. A integração contínua é um pré-requisito para a [entrega contínua](/pt-br/continuous_delivery/). Tradicionalmente, o processo de integração contínua começa quando as alterações do código são confirmadas em um sistema de controle de código-fonte (Git, Mercurial ou Subversion) e termina com o artefato testado e pronto para ser consumido por um sistema de entrega contínua. +A integração contínua (continuous integration - CI), é a prática de integrar mudanças de código da maneira mais regular possível. A integração contínua é um pré-requisito para a [entrega contínua](/pt-br/continuous-delivery/). Tradicionalmente, o processo de integração contínua começa quando as alterações do código são confirmadas em um sistema de controle de código-fonte (Git, Mercurial ou Subversion) e termina com o artefato testado e pronto para ser consumido por um sistema de entrega contínua. ## Problema relacionado diff --git a/content/pt-br/devops.md b/content/pt-br/devops.md index 28df78ba5c..c3c6bf71bf 100644 --- a/content/pt-br/devops.md +++ b/content/pt-br/devops.md @@ -11,7 +11,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](/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. 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/style-guide/_index.md b/content/pt-br/style-guide/_index.md index 3a48862c62..443988b83e 100644 --- a/content/pt-br/style-guide/_index.md +++ b/content/pt-br/style-guide/_index.md @@ -115,7 +115,7 @@ Quando apropriado, use **exemplos do mundo real** que ajudam os leitores (especi Quando usado na sua definição, sempre aponte para termos existentes do glossário (apenas a primeira menção deve ser um *link*). -**Exemplo**: veja seção "O que é" da definição de [service mesh](/service_mesh/). Ele se refere aos conceitos de microsserviços, serviços, confiabilidade e observabilidade. Além disso, é usado um exemplo do mundo real comparando desafios de rede em um ambiente de microsserviços (algo que pessoas não técnicas pode não ter conhecimento prévio) a problemas de *wifi* (algo que qualquer pessoa usando um computador pode entender). Sempre que possível tente fazer esse tipo de conexão. +**Exemplo**: veja seção "O que é" da definição de [service mesh](/service-mesh/). Ele se refere aos conceitos de microsserviços, serviços, confiabilidade e observabilidade. Além disso, é usado um exemplo do mundo real comparando desafios de rede em um ambiente de microsserviços (algo que pessoas não técnicas pode não ter conhecimento prévio) a problemas de *wifi* (algo que qualquer pessoa usando um computador pode entender). Sempre que possível tente fazer esse tipo de conexão. #### Comece com um documento de texto diff --git a/content/zh-cn/cloud-native-apps.md b/content/zh-cn/cloud-native-apps.md index 07f2ffc07b..7f35fdfd3b 100644 --- a/content/zh-cn/cloud-native-apps.md +++ b/content/zh-cn/cloud-native-apps.md @@ -6,7 +6,7 @@ category: 概念 ## What it is -云原生应用程序专门设计用于利用 [云计算](/zh-cn/cloud_computing/) 中的创新。 +云原生应用程序专门设计用于利用 [云计算](/zh-cn/cloud-computing/) 中的创新。 这些应用程序可以轻松地与其各自的云架构集成，充分利用云的资源和 [可扩展性](/zh-cn/scalability/) 功能。 它还指利用云计算驱动的基础设施创新的应用程序。 今天的云原生应用程序包括在云提供商的数据中心和本地云原生平台上运行的应用程序。 @@ -14,7 +14,7 @@ category: 概念 ## Problem it addresses 传统上，本地环境以相当定制的方式提供计算资源。 -每个数据中心都有与特定环境 [紧密耦合](/tightly_coupled_architectures/) 应用程序的服务，通常严重依赖于基础设施的手动配置，例如 [虚拟机](/zh-cn/virtual_machine/) 和服务。 +每个数据中心都有与特定环境 [紧密耦合](/tightly-coupled-architectures/) 应用程序的服务，通常严重依赖于基础设施的手动配置，例如 [虚拟机](/zh-cn/virtual-machine/) 和服务。 这反过来又将开发人员及其应用程序限制在该特定数据中心。 不是为云设计的应用程序无法利用云环境的弹性和扩展能力。 例如，需要手动干预才能正确启动的应用程序无法自动扩展，也无法在发生故障时自动重启。 diff --git a/content/zh-cn/cloud-native-security.md b/content/zh-cn/cloud-native-security.md index d4233a07e4..c3b1dc1d51 100644 --- a/content/zh-cn/cloud-native-security.md +++ b/content/zh-cn/cloud-native-security.md @@ -6,7 +6,7 @@ category: 概念 ## 是什么 -云原生安全是一种将安全性构建到 [云原生应用程序](/zh-cn/cloud_native_apps/) 中的方法。 +云原生安全是一种将安全性构建到 [云原生应用程序](/zh-cn/cloud-native-apps/) 中的方法。 它确保安全是从开发到生产的整个应用程序生命周期的一部分。 云原生安全旨在确保与传统安全模型相同的标准，同时适应云原生环境的特殊性，即快速的代码更改和高度短暂的基础设施。 云原生安全与称为 [测试左移](/devsecops/) 的实践高度相关。 diff --git a/content/zh-cn/cloud-native-tech.md b/content/zh-cn/cloud-native-tech.md index e36e3a4c83..032c684b46 100644 --- a/content/zh-cn/cloud-native-tech.md +++ b/content/zh-cn/cloud-native-tech.md @@ -6,7 +6,7 @@ category: 概念 ## 是什么 -云原生技术，也称为云原生技术栈，是用于构建 [云原生应用程序](/zh-cn/cloud_native_apps/) 的技术。 +云原生技术，也称为云原生技术栈，是用于构建 [云原生应用程序](/zh-cn/cloud-native-apps/) 的技术。 使组织能够在公共云、私有云和混合云等现代动态环境中构建和运行可扩展的应用程序，他们坚持“云的承诺”并充分利用云计算的优势。 它们从头开始设计，以利用云计算和容器的功能，服务网格、微服务和不可变的基础设施就是这种方法的例证。 diff --git a/content/zh-cn/cluster.md b/content/zh-cn/cluster.md index 61aef79806..355289dd1a 100644 --- a/content/zh-cn/cluster.md +++ b/content/zh-cn/cluster.md @@ -14,9 +14,9 @@ Kubernetes 集群是一组服务（或工作负载），它们在各自的容器 ## 强调的问题 在单台计算机上运行的软件会出现单点故障——如果这台计算机崩溃了，或者有人不小心拔掉了电源线，那么一些关键的业务系统就可能被下线。 -这就是为什么现代软件通常被构建为 [分布式应用](/zh-cn/distributed_apps/)，以集群的形式组合在一起。 +这就是为什么现代软件通常被构建为 [分布式应用](/zh-cn/distributed-apps/)，以集群的形式组合在一起。 ## 如何帮助 集群式的分布式应用在多台机器上运行，消除了单点故障。但构建分布式系统真的很难，事实上，它本身就是一门计算机科学的学科。 -对全球系统的需求和多年的试验和错误导致了一种新的技术栈的发展：[云原生技术](/zh-cn/cloud_native_tech/)，这些新技术是使分布式系统的操作和创建更容易的构件。 +对全球系统的需求和多年的试验和错误导致了一种新的技术栈的发展：[云原生技术](/zh-cn/cloud-native-tech/)，这些新技术是使分布式系统的操作和创建更容易的构件。 diff --git a/content/zh-cn/containerization.md b/content/zh-cn/containerization.md index 3850cc8f3a..fdcfbd037d 100644 --- a/content/zh-cn/containerization.md +++ b/content/zh-cn/containerization.md @@ -12,9 +12,9 @@ category: 技术 ## 解决的问题 -在容器盛行之前，企业依靠虚拟机 (VMs) 在一台 [裸机](/bare_metal_machine/) 上协调多个应用程序。 +在容器盛行之前，企业依靠虚拟机 (VMs) 在一台 [裸机](/bare-metal-machine/) 上协调多个应用程序。 虚拟机比容器大得多，需要一个管理程序来运行。由于这些较大的虚拟机模板的存储、备份和传输，创建虚拟机模板也很慢。 -此外，虚拟机可能会出现配置漂移，这违反了 [不变性](/immutable_infrastructure/) 的原则。 +此外，虚拟机可能会出现配置漂移，这违反了 [不变性](/immutable-infrastructure/) 的原则。 ## 如何帮助 diff --git a/content/zh-cn/containers-as-a-service.md b/content/zh-cn/containers-as-a-service.md index 34c13b1098..d9135ae735 100644 --- a/content/zh-cn/containers-as-a-service.md +++ b/content/zh-cn/containers-as-a-service.md @@ -12,7 +12,7 @@ category: 技术 CaaS 供应商提供了一个框架或协调平台，使容器部署和管理的关键 IT 功能自动化。 它帮助开发者建立安全和 [可扩展](/zh-cn/scalability/) 的容器化应用。 因为用户只购买他们需要的资源（调度能力、负载平衡等），他们可以节省资金并提高效率。 -容器创造了一致的环境，以快速开发和交付可以在任何地方运行的 [云原生应用](/zh-cn/cloud_native_apps/)。 +容器创造了一致的环境，以快速开发和交付可以在任何地方运行的 [云原生应用](/zh-cn/cloud-native-apps/)。 ## 解决的问题 @@ -21,6 +21,6 @@ CaaS 供应商提供了一个框架或协调平台，使容器部署和管理的 ## 如何帮助 当把容器化应用部署到 CaaS 平台时，用户可以通过日志聚合和监控工具获得对系统性能的可见性。 -CaaS 还包括 [自动扩展](/auto_scaling/) 和协调管理的内置功能。 -它使团队能够建立高可见性和高可用性的 [分布式系统](/zh-cn/distributed_systems/)。 +CaaS 还包括 [自动扩展](/auto-scaling/) 和协调管理的内置功能。 +它使团队能够建立高可见性和高可用性的 [分布式系统](/zh-cn/distributed-systems/)。 此外，通过允许快速部署，CaaS 提高了团队的开发速度。在容器确保一致的部署目标的同时，CaaS 通过减少管理部署所需的 [DevOps](/zh-cn/devops/) 资源，降低了工程运营成本。 diff --git a/content/zh-cn/continuous-delivery.md b/content/zh-cn/continuous-delivery.md index d3730b54a3..d74256e9ed 100644 --- a/content/zh-cn/continuous-delivery.md +++ b/content/zh-cn/continuous-delivery.md @@ -19,6 +19,6 @@ CD 关键是包括确保软件在部署前得到充分测试的程序，并提 ## 如何帮助 -CD 策略创建了一个完全自动化的生产路径，使用各种部署策略测试和部署软件，如 [canary](/zh-cn/canary_deployment/) 或 [blue-green](/zh-cn/blue_green_deployment/) 发布。 +CD 策略创建了一个完全自动化的生产路径，使用各种部署策略测试和部署软件，如 [canary](/zh-cn/canary-deployment/) 或 [blue-green](/zh-cn/blue-green-deployment/) 发布。 这使得开发人员可以频繁地部署代码，让他们放心地认为新的修订版已经过测试。 通常情况下，CD 策略中使用基于主干的开发，而不是功能分支或拉动请求。 diff --git a/content/zh-cn/continuous-integration.md b/content/zh-cn/continuous-integration.md index 0554ca3aa9..2386ef6e96 100644 --- a/content/zh-cn/continuous-integration.md +++ b/content/zh-cn/continuous-integration.md @@ -7,7 +7,7 @@ category: 概念 ## 是什么 持续集成，通常缩写为CI，是尽可能定期集成代码变化的做法。 -CI 是 [持续交付](/zh-cn/continuous_delivery/)（CD）的前提。 +CI 是 [持续交付](/zh-cn/continuous-delivery/)（CD）的前提。 传统上，CI 过程从代码修改提交到源码控制系统（Git、Mercurial 或 Subversion）时开始，以准备被CD系统使用的测试工件结束。 ## 解决的问题 diff --git a/content/zh-cn/data-center.md b/content/zh-cn/data-center.md index 6d4146e624..4d85a8c7be 100644 --- a/content/zh-cn/data-center.md +++ b/content/zh-cn/data-center.md @@ -6,7 +6,7 @@ category: 技术 ## 是什么 -数据中心是专门设计用于容纳计算机（通常是服务器）的专用建筑物或设施。 数据中心往往连接到高速互联网线路，尤其是专注于 [云计算](/zh-cn/cloud_computing/) 的数据中心。 数据中心所在的建筑物还配备了即使在发生负面事件时也能维持服务的设备，例如在停电期间提供电力的发电机，以及处理计算机产生的废热的强大空调。 +数据中心是专门设计用于容纳计算机（通常是服务器）的专用建筑物或设施。 数据中心往往连接到高速互联网线路，尤其是专注于 [云计算](/zh-cn/cloud-computing/) 的数据中心。 数据中心所在的建筑物还配备了即使在发生负面事件时也能维持服务的设备，例如在停电期间提供电力的发电机，以及处理计算机产生的废热的强大空调。 ## 解决的问题 diff --git a/content/zh-cn/devops.md b/content/zh-cn/devops.md index 50993253d8..0c3de93f96 100644 --- a/content/zh-cn/devops.md +++ b/content/zh-cn/devops.md @@ -10,7 +10,7 @@ category: 概念 ## 强调的问题 -传统上，在具有 [紧密耦合](/tightly_coupled_architectures/) [单体应用程序](/zh-cn/monolithic_apps/) 的复杂组织中，工作通常分散在多个组之间。 这导致了多次交接和较长的交货时间。 每次组件或更新准备就绪时，都会将其放入队列中以供下一个团队使用。 因为个人只参与了项目的一小部分，这种方法导致缺乏所有权。 他们的目标是将工作交给下一个小组，而不是为客户提供正确的功能——明显的优先级错位。 +传统上，在具有 [紧密耦合](/tightly-coupled-architectures/) [单体应用程序](/zh-cn/monolithic-apps/) 的复杂组织中，工作通常分散在多个组之间。 这导致了多次交接和较长的交货时间。 每次组件或更新准备就绪时，都会将其放入队列中以供下一个团队使用。 因为个人只参与了项目的一小部分，这种方法导致缺乏所有权。 他们的目标是将工作交给下一个小组，而不是为客户提供正确的功能——明显的优先级错位。 到代码最终投入生产时，它经过了这么多开发人员，排了这么多队列，如果代码不起作用，很难追查问题的根源。 DevOps 颠覆了这种方法。 diff --git a/content/zh-cn/distributed-apps.md b/content/zh-cn/distributed-apps.md index 5f5f760326..6095c921f5 100644 --- a/content/zh-cn/distributed-apps.md +++ b/content/zh-cn/distributed-apps.md @@ -19,5 +19,5 @@ category: 概念 ## 如何帮助 当把一个应用程序拆分成不同的部分并在许多地方运行时，整个系统可以容忍更多的故障。 -它还允许应用程序利用单个应用程序实例所不具备的扩展功能，即 [水平扩展](/horizontal_scaling/)的能力。 +它还允许应用程序利用单个应用程序实例所不具备的扩展功能，即 [水平扩展](/horizontal-scaling/)的能力。 然而，这也是有代价的：增加了复杂性和操作开销--你现在正在运行很多应用组件，而不是一个应用。 diff --git a/content/zh-cn/distributed-systems.md b/content/zh-cn/distributed-systems.md index 53bc780797..9a3e6e399a 100644 --- a/content/zh-cn/distributed-systems.md +++ b/content/zh-cn/distributed-systems.md @@ -21,6 +21,6 @@ category: 概念 ## 如何帮助 -分布式系统允许 [水平扩展](/horizontal_scaling/)（例如，在需要时向系统添加更多节点）。这可以是自动化的，允许系统处理工作负荷或资源消耗的突然增加。 +分布式系统允许 [水平扩展](/horizontal-scaling/)（例如，在需要时向系统添加更多节点）。这可以是自动化的，允许系统处理工作负荷或资源消耗的突然增加。 非分布式系统面临着故障的风险，因为如果一台机器发生故障，整个系统都会故障。分布式系统可以设计成这样，即使一些机器发生故障，整个系统仍然可以继续工作，产生相同的结果。 diff --git a/content/zh-cn/kubernetes.md b/content/zh-cn/kubernetes.md index 26205b26cc..5f461cc654 100644 --- a/content/zh-cn/kubernetes.md +++ b/content/zh-cn/kubernetes.md @@ -7,18 +7,18 @@ category: 技术 ## 是什么 Kubernetes，通常缩写为K8s，是一种流行的现代基础设施自动化的开源工具。 -它就像一个数据中心的操作系统，管理在 [分布式系统](/zh-cn/distributed_systems/) 上运行的应用程序（就像你笔记本上的操作系统，管理你的应用程序）。 +它就像一个数据中心的操作系统，管理在 [分布式系统](/zh-cn/distributed-systems/) 上运行的应用程序（就像你笔记本上的操作系统，管理你的应用程序）。 Kubernetes在 [集群](/zh-cn/cluster/) 的 [节点](/nodes/) 上调度 [容器](/zh-cn/container/)。 它捆绑了几个基础设施结构，有时被称为 "基元"，如应用程序的实例、负载平衡器、持久性存储等，以一种可以被组成应用程序的方式。 Kubernetes 实现了自动化和可扩展性，使用户能够以可重复的方式声明性地部署应用程序。 -Kubernetes 生态系统中的软件产品和项目利用这种自动化和可扩展性来扩展 Kubernetes [API](/application_programming_interface/) 。 +Kubernetes 生态系统中的软件产品和项目利用这种自动化和可扩展性来扩展 Kubernetes [API](/application-programming-interface/) 。 这使他们能够利用 Kubernetes 的自动化，并使他们的工具更容易被有经验的 Kubernetes 从业者所接受。 ## 解决的问题 -长期以来，基础设施自动化和声明性配置管理一直是重要的概念，而且随着 [云计算](/zh-cn/cloud_computing/) 的普及而变得更加紧迫。 +长期以来，基础设施自动化和声明性配置管理一直是重要的概念，而且随着 [云计算](/zh-cn/cloud-computing/) 的普及而变得更加紧迫。 随着对计算资源的需求增加，组织感到压力，要用更少的工程师提供更多的操作能力，需要新的技术和工作方法来满足这一需求。 此外，云计算的兴起与 [容器化](/zh-cn/containerization/) 相搭配，那些忙于自动化更多传统基础设施的组织需要一种机制来自动配置和部署其容器。 diff --git a/content/zh-cn/microservices.md b/content/zh-cn/microservices.md index 6dfde9f189..5d9d9f91c3 100644 --- a/content/zh-cn/microservices.md +++ b/content/zh-cn/microservices.md @@ -8,17 +8,17 @@ category: 概念 微服务是一种利用云原生技术进行应用开发的现代方法。虽然现代应用程序，如 Netflix，看起来是一个单一的应用程序，但它们实际上是一个较小的服务的集合——所有的服务都密切配合。 例如，一个允许你访问、搜索和预览视频的单一页面很可能是由较小的服务提供的，它们各自处理其中的一个方面（如搜索、认证和在浏览器中运行预览）。 -简而言之，微服务指的是一种应用架构模式，通常与 [单体应用](/zh-cn/monolithic_apps/) 形成对比。 +简而言之，微服务指的是一种应用架构模式，通常与 [单体应用](/zh-cn/monolithic-apps/) 形成对比。 ## 解决的问题 微服务是对单体应用所带来的挑战的一种回应。一般来说，一个应用程序的不同部分需要分别进行 [扩展](/zh-cn/scalability/)。 例如，一个在线商店将有更多的产品视图而不是结账。这意味着你需要更多的产品视图功能的运行，而不是结账。 在一个单一的应用程序中，这些逻辑位不能被单独部署。如果你不能单独扩展产品功能，你将不得不复制整个应用程序和所有其他你不需要的组件--这是一种低效的资源利用。 -单机式应用程序也使开发人员容易屈服于设计陷阱。因为所有的代码都在一个地方，所以更容易使这些代码 [高耦合](/tightly_coupled_architectures/)，更难执行关注点分离的原则。 +单机式应用程序也使开发人员容易屈服于设计陷阱。因为所有的代码都在一个地方，所以更容易使这些代码 [高耦合](/tightly-coupled-architectures/)，更难执行关注点分离的原则。 单机通常要求开发人员了解整个代码库，然后才能有成效。 ## 如何帮助 将功能分离成不同的微服务，使它们更容易独立部署、更新和扩展。通过允许不同的团队专注于更大的应用中他们自己的一小部分，也让他们更容易在不对组织的其他部分产生负面影响的情况下对他们的应用进行工作。 -虽然微服务解决了许多问题，但它们也产生了运营开销——你需要部署和跟踪的东西增加了一个数量级或更多。许多 [云原生技术](/zh-cn/cloud_native_tech/) 旨在使微服务更容易部署和管理。 +虽然微服务解决了许多问题，但它们也产生了运营开销——你需要部署和跟踪的东西增加了一个数量级或更多。许多 [云原生技术](/zh-cn/cloud-native-tech/) 旨在使微服务更容易部署和管理。 diff --git a/content/zh-cn/reliability.md b/content/zh-cn/reliability.md index daafd9acbb..ff6d566ef7 100644 --- a/content/zh-cn/reliability.md +++ b/content/zh-cn/reliability.md @@ -4,4 +4,4 @@ status: Completed category: 属性 --- -从云原生的角度来看，可靠性是指系统对故障的响应能力。 如果我们有一个可以在基础架构更改和单个组件发生故障时继续工作的[分布式系统](/zh-cn/distributed_systems/) ，那么它是可靠的。 另一方面，如果它很容易出现故障，并且需要操作人员手动干预以保持其运行，则它是不可靠的。 [云原生应用程序](/zh-cn/cloud_native_apps/) 的目标是构建内在可靠的系统。 +从云原生的角度来看，可靠性是指系统对故障的响应能力。 如果我们有一个可以在基础架构更改和单个组件发生故障时继续工作的[分布式系统](/zh-cn/distributed-systems/) ，那么它是可靠的。 另一方面，如果它很容易出现故障，并且需要操作人员手动干预以保持其运行，则它是不可靠的。 [云原生应用程序](/zh-cn/cloud-native-apps/) 的目标是构建内在可靠的系统。 diff --git a/content/zh-cn/scalability.md b/content/zh-cn/scalability.md index 03be9f341f..352dfa5d90 100644 --- a/content/zh-cn/scalability.md +++ b/content/zh-cn/scalability.md @@ -4,6 +4,6 @@ status: Completed category: 属性 --- -可扩展性指的是一个系统能有多大的发展。这就是增加做任何系统应该做的事情的能力。 例如，[Kubernetes](/zh-cn/kubernetes/) [集群](/zh/cluster/) 通过增加或减少 [容器化](/zh-cn/containerization/) 应用程序的数量来进行扩展，但这种可扩展性取决于几个因素。 它有多少[节点](/nodes/)，每个节点可以处理多少个[容器](/zh-cn/container/)，控制平面可以支持多少条记录和操作？ +可扩展性指的是一个系统能有多大的发展。这就是增加做任何系统应该做的事情的能力。 例如，[Kubernetes](/zh-cn/kubernetes/) [集群](/zh-cn/cluster/) 通过增加或减少 [容器化](/zh-cn/containerization/) 应用程序的数量来进行扩展，但这种可扩展性取决于几个因素。 它有多少[节点](/nodes/)，每个节点可以处理多少个[容器](/zh-cn/container/)，控制平面可以支持多少条记录和操作？ -可扩展的系统使添加更多容量更容易。 主要有两种缩放方法。 一方面，有 [水平扩展](/horizontal_scaling/) 添加更多节点来处理增加的负载。 相比之下，在 [垂直扩展](/vertical_scaling/) 中，单个节点的功能更强大，可以执行更多事务（例如，通过向单个机器添加更多内存或 CPU）。 可扩展的系统能够轻松更改并满足用户需求。 +可扩展的系统使添加更多容量更容易。 主要有两种缩放方法。 一方面，有 [水平扩展](/horizontal-scaling/) 添加更多节点来处理增加的负载。 相比之下，在 [垂直扩展](/vertical-scaling/) 中，单个节点的功能更强大，可以执行更多事务（例如，通过向单个机器添加更多内存或 CPU）。 可扩展的系统能够轻松更改并满足用户需求。 diff --git a/content/zh-cn/serverless.md b/content/zh-cn/serverless.md index e4aca3320e..fa1437231f 100644 --- a/content/zh-cn/serverless.md +++ b/content/zh-cn/serverless.md @@ -10,7 +10,7 @@ Serverless 是一种云原生开发模型，允许开发人员构建和运行应 ## 解决的问题 -在标准的 [基础设施即服务 (IaaS)](/infrastructure_as_a_service/) [云计算](/zh-cn/cloud_computing/) 模型下，用户预先购买容量单位，这意味着您需要向公共云提供商支付永远在线的服务器组件的费用来运行您的应用程序。 +在标准的 [基础设施即服务 (IaaS)](/infrastructure-as-a-service/) [云计算](/zh-cn/cloud-computing/) 模型下，用户预先购买容量单位，这意味着您需要向公共云提供商支付永远在线的服务器组件的费用来运行您的应用程序。 用户有责任在高需求时扩展服务器容量，并在不在需要该容量时缩减容量。 即使在不使用应用程序时，运行应用程序所需的云基础设施也处于活动状态。 ## 如何帮助 diff --git a/content/zh-cn/style-guide/_index.md b/content/zh-cn/style-guide/_index.md index d0605f935c..87f0f995c5 100644 --- a/content/zh-cn/style-guide/_index.md +++ b/content/zh-cn/style-guide/_index.md @@ -122,7 +122,7 @@ category: 概念 当在你的定义中使用时，一定要 **链接到现有的词汇表术语**（只有第一次提到的时候应该有超链接）。 -**例子**：看看 [服务网状](/zh-cn/service_mesh/)的 "是什么 "部分。它链接到了微服务、服务、可靠性和可观察性的定义。此外，它还使用了一个真实的例子，将微服务环境中的网络挑战（非技术人员无法理解的问题）与 wifi 问题（使用笔记本电脑的人都能理解的问题）进行比较。在可能的情况下，尝试建立这种联系。 +**例子**：看看 [服务网状](/zh-cn/service-mesh/)的 "是什么 "部分。它链接到了微服务、服务、可靠性和可观察性的定义。此外，它还使用了一个真实的例子，将微服务环境中的网络挑战（非技术人员无法理解的问题）与 wifi 问题（使用笔记本电脑的人都能理解的问题）进行比较。在可能的情况下，尝试建立这种联系。 #### 从谷歌或Word文档开始 diff --git a/content/zh-cn/virtual-machine.md b/content/zh-cn/virtual-machine.md index b9e6077875..f68ddbf445 100644 --- a/content/zh-cn/virtual-machine.md +++ b/content/zh-cn/virtual-machine.md @@ -13,7 +13,7 @@ category: 技术 ## 解决的问题 虚拟机利用了虚拟化的优势。 -当 [裸机](/bare_metal_machine/) 机器被束缚在一个单一的操作系统上时，该机器的资源的使用受到一定的限制。 +当 [裸机](/bare-metal-machine/) 机器被束缚在一个单一的操作系统上时，该机器的资源的使用受到一定的限制。 另外，当一个操作系统被绑定在一个单一的物理机上时，它的可用性直接与该硬件联系在一起。 如果物理机由于维护或硬件故障而脱机，操作系统也会脱机。