The challenge that I am seeing is teams not able to understand if they are building an application or a platform. Another challenge is to win the argument of using a higher level abstraction on top of Kubernetes, within the organization. (...contd)
We need to equip the teams to handle objections, when they tell decision makers about why they should use a higher level abstraction, why it makes more sense, why it still utilizes the power of K8s underneath and so on. (...contd)
We have almost created a situation, where a developer is embarrassed to say that they are not using K8s. In the interim, make no mistake, there are teams, who avoid the herd mentality & are choosing the right developer experience, from their cloud provider of choice. 💪
• • •
Missing some Tweet in this thread? You can try to
force a refresh
A long thread on understanding Google Cloud Platform Compute Engine pricing and how to utilize the various pricing levers at your disposal via the Google Cloud Cost Calculator. Let’s go. (contd)
Google Compute Engine provides a core infrastructure component : Virtual Machines (VM) that are classified into diff families (general, memory optimized, compute optimized) & each family has various machine types. See this guide on how to choose :cloud.google.com/compute/docs/m… (contd)
Each of the machine types (e.g. N1 general purpose) will have several *fixed* or *pre-defined* configurations (instance types) of VPU and RAM. You can choose the appropriate instance types. A set of instance types for N1 is shown below: (contd)