Proposal for fleet management overview page #2185
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AndiDog
reviewed
May 3, 2024
| - **Multi-environment**: We support multiple providers, regions and environments. Platform engineers can map their company structure to our platform structure in order to ease the management of their teams and workloads. | ||
| - **Configuration management**: We rely on GitOps principles to manage the configuration of your clusters, environments and workloads having multiple layers of configuration. | ||
| - **Cluster lifecycle management**: We provide a way to manage the lifecycle of your clusters, from creation to deletion, including upgrades and scaling. | ||
| - **Workload management**: We have developed a solution to help your developers to configure and deploy their applications in a cloud-native way. |
There was a problem hiding this comment.
Too vague. What do we describe here? Is it the app platform? If yes, does "workload management" really cut it as a good term?
There was a problem hiding this comment.
yeah I asked Puja for help to define those better, I came up with some ideas but ideally we describe those better :)
Co-authored-by: Andreas Sommer <andreas@giantswarm.io>
…/docs into add-overview-fleet-management
pipo02mix
commented
May 14, 2024
|
|
||
| Based on our extensive experience, we understand that orchestrating a large-scale microservices platform poses significant challenges. Ideally, workloads should be designed for seamless execution in the cloud, tailor-made to optimize the container lifecycle. However, the task becomes exponentially more complex when juggling multiple providers, regions, and environments. Recognizing this, we've developed several abstraction layers to help streamline management and tackle this complexity more effectively. | ||
|
|
||
| ## Features |
There was a problem hiding this comment.
Suggested change
| ## Features | |
| ## Capabilities |
pipo02mix
commented
May 14, 2024
| owner: | ||
| - https://github.com/orgs/giantswarm/teams/sig-product | ||
| --- | ||
|
|
||
| Based on our extensive experience, we understand that orchestrating a large-scale microservices platform poses significant challenges. Ideally, workloads should be designed for seamless execution in the cloud, tailor-made to optimize the container lifecycle. However, the task becomes exponentially more complex when juggling multiple providers, regions, and environments. Recognizing this, we've developed several abstraction layers to help streamline management and tackle this complexity more effectively. |
There was a problem hiding this comment.
Suggested change
| Based on our extensive experience, we understand that orchestrating a large-scale microservices platform poses significant challenges. Ideally, workloads should be designed for seamless execution in the cloud, tailor-made to optimize the container lifecycle. However, the task becomes exponentially more complex when juggling multiple providers, regions, and environments. Recognizing this, we've developed several abstraction layers to help streamline management and tackle this complexity more effectively. | |
| Based on our extensive experience, we understand that orchestrating a large-scale microservices platform poses significant challenges. Ideally, workloads should be designed for seamless execution in the cloud, tailor-made to optimize the container lifecycle. However, the task becomes exponentially more complex when juggling multiple providers, regions, clusters, and environments. Recognizing this, we've developed several abstraction layers to help streamline management and tackle this complexity more effectively. |
AndiDog
reviewed
May 15, 2024
| owner: | ||
| - https://github.com/orgs/giantswarm/teams/sig-product | ||
| --- | ||
|
|
||
| Based on our extensive experience, we understand that orchestrating a large-scale microservices platform poses significant challenges. Ideally, workloads should be designed for seamless execution in the cloud, tailor-made to optimize the container lifecycle. However, the task becomes exponentially more complex when juggling multiple providers, regions, and environments. Recognizing this, we've developed several abstraction layers to help streamline management and tackle this complexity more effectively. |
There was a problem hiding this comment.
Suggested change
| Based on our extensive experience, we understand that orchestrating a large-scale microservices platform poses significant challenges. Ideally, workloads should be designed for seamless execution in the cloud, tailor-made to optimize the container lifecycle. However, the task becomes exponentially more complex when juggling multiple providers, regions, and environments. Recognizing this, we've developed several abstraction layers to help streamline management and tackle this complexity more effectively. | |
| Based on our extensive experience, we understand that orchestrating a large-scale microservices platform poses significant challenges. Ideally, workloads should be designed for seamless execution in the cloud and in containers. However, this becomes exponentially more complex when juggling multiple providers, regions, clusters and environments. Recognizing this, we've developed abstractions to help manage and tackle this complexity effectively. |
Removed some fill words and things that are kind of mentioned multiple times and made the sentence too long.
|
|
||
| Our product is designed to offer a comprehensive set of features to support the construction of robust Cloud Native Platforms. Key features include: | ||
|
|
||
| - **Multi-Environment Support**: Every enterprise has unique requirements and constraints, influencing how they design their developer platforms. Platform engineers often struggle to align their organization's structure and processes with the platform while maintaining the system's ability to foster speed and quality, all in compliance with company standards. Our solution, Giant Swarm, simplifies this process. It empowers you to provide developers with various environments, across different regions and providers, tailored to your organization's needs. |
There was a problem hiding this comment.
Suggested change
| - **Multi-Environment Support**: Every enterprise has unique requirements and constraints, influencing how they design their developer platforms. Platform engineers often struggle to align their organization's structure and processes with the platform while maintaining the system's ability to foster speed and quality, all in compliance with company standards. Our solution, Giant Swarm, simplifies this process. It empowers you to provide developers with various environments, across different regions and providers, tailored to your organization's needs. | |
| - **Multi-Environment Support**: Every enterprise has unique requirements and constraints, influencing how they design their developer platforms. Platform engineers often struggle to align their organization's structure and processes with the platform while maintaining the system's ability to foster speed and quality, all in compliance with company standards. Our solution, the Giant Swarm platform, simplifies this process. It empowers you to provide developers with various environments, across different regions and providers, flexibly adapted to your organization's needs. |
Not sure about "flexibly adapted" – I wanted to add the word "flexible" in some way, to ensure that customers understand that the platform is adaptable, not tailored/hardcoded by Giant Swarm to their environments.
|
|
||
| - **Multi-Environment Support**: Every enterprise has unique requirements and constraints, influencing how they design their developer platforms. Platform engineers often struggle to align their organization's structure and processes with the platform while maintaining the system's ability to foster speed and quality, all in compliance with company standards. Our solution, Giant Swarm, simplifies this process. It empowers you to provide developers with various environments, across different regions and providers, tailored to your organization's needs. | ||
|
|
||
| - **Robust Configuration Management**: Manage your clusters, environments, and workloads with flexibility and precision using our robust configuration management framework. This framework facilitates structured platform configuration with multiple layers of control, all from a single repository. It's crafted to adhere to the principles of GitOps, ensuring seamless and efficient management. |
There was a problem hiding this comment.
We didn't use the term "framework" before. Can we leave that word out or use a term we already have?
|
|
||
| - **Robust Configuration Management**: Manage your clusters, environments, and workloads with flexibility and precision using our robust configuration management framework. This framework facilitates structured platform configuration with multiple layers of control, all from a single repository. It's crafted to adhere to the principles of GitOps, ensuring seamless and efficient management. | ||
|
|
||
| - **Standardized Cluster Lifecycle Management**: Experience a standardized approach to managing the lifecycle of your clusters. Developed in collaboration with the community, Giant Swarm offers a cloud-native solution for cluster lifecycle management. We leverage the Cluster API implementation to streamline lifecycle management, enabling versioning and configuration of clusters as code, thus ensuring consistency and reliability. |
There was a problem hiding this comment.
Better remove title case in this whole bullet point list, since those are not proper nouns/terms.
|
|
||
| - **Robust Configuration Management**: Manage your clusters, environments, and workloads with flexibility and precision using our robust configuration management framework. This framework facilitates structured platform configuration with multiple layers of control, all from a single repository. It's crafted to adhere to the principles of GitOps, ensuring seamless and efficient management. | ||
|
|
||
| - **Standardized Cluster Lifecycle Management**: Experience a standardized approach to managing the lifecycle of your clusters. Developed in collaboration with the community, Giant Swarm offers a cloud-native solution for cluster lifecycle management. We leverage the Cluster API implementation to streamline lifecycle management, enabling versioning and configuration of clusters as code, thus ensuring consistency and reliability. |
There was a problem hiding this comment.
Suggested change
| - **Standardized Cluster Lifecycle Management**: Experience a standardized approach to managing the lifecycle of your clusters. Developed in collaboration with the community, Giant Swarm offers a cloud-native solution for cluster lifecycle management. We leverage the Cluster API implementation to streamline lifecycle management, enabling versioning and configuration of clusters as code, thus ensuring consistency and reliability. | |
| - **Standardized cluster lifecycle management**: Experience a standardized approach to managing the lifecycle of your clusters. Giant Swarm leverages the Cluster API implementation, a Kubernetes subproject developed by the open source community, including Giant Swarm engineers as regular contributors. It allows for consistent and reliable cluster lifecycle management, enabling versioning and configuration of clusters as code. |
|
|
||
| ## Cloud-native applications | ||
|
|
||
| The platform is heavily relying on [Cluster API implementation]({{< relref "/overview/fleet-management/introduction_cluster-api" >}}) to manage the lifecycle of your clusters. It opens up the possibility to manage your clusters in many providers adapting to the infrastructure nuances of each solution while keeping a consistent experience for the user. |
There was a problem hiding this comment.
We already have basically this sentence above, and this sentence doesn't say anything more (apart from linking to other docs). I'd expect very few links in the overview in order to take the audience through the writeup top-down without jumping. Should we have a rough Cluster API explanation on this page instead, or leave off the link?
|
|
||
| The platform is heavily relying on [Cluster API implementation]({{< relref "/overview/fleet-management/introduction_cluster-api" >}}) to manage the lifecycle of your clusters. It opens up the possibility to manage your clusters in many providers adapting to the infrastructure nuances of each solution while keeping a consistent experience for the user. | ||
|
|
||
| Every company requires a different level of control over their infrastructure and its configuration. We work with upstream to offer you a platform that is compliant with all the standards and processes your company imposes. |
There was a problem hiding this comment.
We need to make explicit points in here. This is too vague and not saying more than the bullet list above.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does / why we need it
Towards https://github.com/giantswarm/giantswarm/issues/30179
Things to check/remember before submitting
If you made content changes
make devto render and proofread content changes locally.last_review_datein the front matter header if you reviewed the entire page.