Hi everyone, I'm new to this forum but I have a qu...
# general
m
Hi everyone, I'm new to this forum but I have a question. How "Platform Engineering" would resole following issue: • IDP consist o a mongodb cluster (on the cloud) and template to create mongodb databases by the teams. • There is a new version of mongodb. • Team A wants to use it, but IDP ("Platform") only support previous version of mongodb. Should Platform Team: 1. Update IDP and force everyone to use new version of mongodb 2. Should they create V2 IDP with new mongodb cluster and support 2 clusters (old and new for Team A) 3. Platform Team should NOT support mongodb clusters and it's bad practice to share resource (mongodb cluster) between teams like this?
a
@Mateusz Świetlicki: If I understand your question correctly, when a resource is not shared among multiple microservices, we provide our microservice team with sufficient control to provision their own database of choice, including the version they prefer. We offer them a custom CDK construct that incorporates certain governance measures. In addition to that, the team has the freedom to use any database or version they desire. This approach enables teams to provision different databases according to their specific requirements. However, if the resource is shared among multiple teams, we have a shared GitHub repository that provisions the necessary infrastructure. This repository is accessible to all teams, ensuring consistency and coordination across multiple projects. All the infra provisioning is happening through pipelines. Every microservice team is having there own pipeline.
m
Thanks @Anshul Garg, but how do you manage cost optimalizations like shared clusters? In my example Platform Team prepared mongodb cluster for everyone to use as part of IDP to manage cost of it and better use it's resources (CPU/Ram). From what I understand you would give microservice team ability to create a cluster so that they would be able to have a version they preferer. PS: It's easier with consumption based services :)
a
Hello @Mateusz Świetlicki: Interesting Question, we are about to work on a similar requirement in nearby future and thinking to consider Kubecost for cost allocation. It's important to have a comprehensive approach that includes both Kubernetes cost analysis tools like Kubecost and native cloud provider features such as AWS Cost Allocation Tags. By using Kubecost, you'll have a powerful solution for cost visibility and optimization within your Kubernetes cluster. It will enable you to track and analyze the costs of your workloads at a granular level. You'll be able to identify inefficiencies, optimize resource allocation, and make informed decisions to control your Kubernetes costs effectively. In addition to Kubecost, leveraging AWS Cost Allocation Tags is a smart approach for managing costs associated with managed resources on AWS. By tagging your AWS resources with specific cost allocation tags, you can attribute the costs to the respective teams or projects. This allows for accurate cost allocation and facilitates cost bifurcation. Furthermore, by incorporating infrastructure automation into the process, you can ensure that the appropriate cost allocation tags are automatically associated with the acquired resources. This helps streamline the cost attribution process and reduces the chances of manual errors. Overall, combining Kubecost for Kubernetes cost analysis and AWS Cost Allocation Tags for managing costs of AWS resources will provide you with a robust solution to handle your cost allocation requirements. It demonstrates a comprehensive approach that leverages both specialized tools and cloud provider features to achieve accurate cost tracking and fair cost distribution among teams.