371–380 of 394 posts
Earlier quoted context omitted.
Wait what, it's not available through an API? That's ridiculous.
Of course there's an API for creating and resizing instances. The issue is there are quotas that cap how many CPUs you can have, and increasing that is a manual process.
Earlier quoted context omitted.
I disagree. Once you learn IAM and able to segregate users into groups each with its own layer of security, then it is good enough. Often the UI, and docs make it seem like everything is all over the place but AWS feels like lego with some pieces tucked away. That is where I think AWS can be improved upon with a better documentation UI and discoverability. I do have to commend Google on Flutter + Firebase + Firebase…
IAM shouldn't be a thing to learn. It's account management, default and easy to access options should be sane enough for most people to use. At big companies, sure someone has it as a dedicated part of their job description. But if you're in the majority of smaller companies, ones maybe that's just doing e-commerce and tech isn't their core skill set, account settings should be near invisible and still be trustworthy…
Yes its a bit of a pain having to add policies sometimes when you are first getting started but once it's up and running you can rest easy.
Learning it isn't that much more time consuming or difficult, its just a bit of effort that is all (we are talking a few hours at most).
Earlier quoted context omitted.
What makes GCP's Kubernetes offering better than the competition?
There are several reasons: - Google has a lot of experience running containerized services because of Borg. Google Research says that they have been running these workloads since 2005. - The above gives them insight into how to do this well. They would have the internal infrastructure, logging and monitoring already setup. - They are the creator and still a major contributor to Kubernetes itself which means they can…
What were your pain points with ECS? Did you use ECS with or without fargate? What about EKS, since that sounds like a closer equivalent to GKE.
Earlier quoted context omitted.
There are several reasons: - Google has a lot of experience running containerized services because of Borg. Google Research says that they have been running these workloads since 2005. - The above gives them insight into how to do this well. They would have the internal infrastructure, logging and monitoring already setup. - They are the creator and still a major contributor to Kubernetes itself which means they can…
The Borg thing is pure marketing. Amazon also has been running internally on containers for years before ECS. But workloads for massive FAANG companies designed by FAANG engineers turn out to be quite different than most AWS/GCP customers. Just like EC2 wasn't Amazon selling its "spare capacity during off-peak" but always a purpose built service with completely isolated data centers and network fabric from day 1, the…
2. Does ECS have something similar to pods, i.e. colocated containers which can communicate over localhost, share filesystems, etc? A quick search didn't turn anything up.
Earlier quoted context omitted.
>I’m surprised that they didn’t include Azure. I'm not. Nobody likes Azure.
Is that universally true? Especially given its the second largest cloud computing platform in North America (if not the world)
The only people who like Azure are managers that get bonuses for their stupid contracts. Azure is not built for engineers. All of their offerings, especially the automation and tooling, are vastly inferior to AWS and GCP
Earlier quoted context omitted.
> When was the last time a landlord reduced your rent? This is a different market and one which is ultimately constrained by the availability of land. Notably, cloud prices do fall especially relative to the compute power. Specifically I remember when Fargate moved to firecracker and prices fell by like 40% or something similarly considerable. Maybe managing your own internal cloud is indeed cheaper (especially if yo…
Maybe cars or trucks are a better example. The ROI of buying, leasing or renting a vehicle varies and the optimal answer depends on the scenario! It’s always better for you as a person to rent box truck to move. If you’re a company that needs a truck 3-5 times a month, there’s a probability that leasing may make more sense. I’d say that businesses that suck at managing on-prem will not magically get competent in a pu…
It takes time to build a competency. If you have to figure out how to operate everything from the hardware and networking all the way up to application, then you might very well fail as a business. If you can pay Amazon to manage your networking, hardware, databases, managed services, etc while you work on your application-level competencies, you stand a much better chance of succeeding ("I don't know if I could build everything from the ground up, but I can probably fumble my way to a container image"). As you become very proficient, you can cut costs, and if you're super proficient you might get off a public cloud altogether or more likely you'll just use that as leverage to negotiate a lower cloud bill.
Interestingly, you don't hear about many businesses that are so competent that they move from the public cloud to their own private clouds. Some people will shout "Lock in!", but I don't buy that--I've migrated between public cloud providers before and it's work, but if you're competent enough to run your own private data centers then you're plenty competent enough to migrate to them.
Earlier quoted context omitted.
Sure. - No way to upgrade major postgres version without full export and import into new cluster. - Incredible delay between postgres versions. IIRC, it took nearly 2 years for them to add postgres 11 after it was released. - HA is basically useless. Costs double, still has 4-5 minute window of downtime as it fails over, doesn't avoid maintenance window downtime (both primary/standby have same maintenance window) and…
> Incredible delay between postgres versions To be fair, it looks like GCP supported Postgres 13 (Nov 5, 2020) before AWS did (Nov 27, 2020) and AWS currently marks Postgres 13 as a preview. Maybe GCP had a large initial engineer-cost to support multiple versions of Postgres and now the incremental cost to add new versions is small? > It's just a lot of money to pay for a crashy, outdated version of Postgres. Have yo…
Earlier quoted context omitted.
I tried explaining this to some Azure product teams, and they gave me a blank stare in return. Sure, you can have zone-redundant Azure SQL Databases, but not Azure App Service! You can have zonal Azure App Service, but with a different network model than the default, so it's a breaking change for some apps. It's as if nobody has actually sat down at Microsoft to build something similar to what their customers are bui…
My experience with MSFT is that the account reps are clueless by design. Even the sales assistants with fancy technical titles are short of clues. Easier for them to oversell when they don’t know what’s really going on underneath. We have to go 3 or 4 deep into their product org to find someone who will fess up to product issues that we are already aware of.
In general, Microsoft, Google and others are behaving really enterprise-y in that they are slow, you cannot reach anybody of importance to solve massive issues with their products and everything is actually quite expensive for what it does.
Earlier quoted context omitted.
There are several reasons: - Google has a lot of experience running containerized services because of Borg. Google Research says that they have been running these workloads since 2005. - The above gives them insight into how to do this well. They would have the internal infrastructure, logging and monitoring already setup. - They are the creator and still a major contributor to Kubernetes itself which means they can…
I was hoping for something more concrete, like limitations or incidents and not just "Google has more Kubernetes experience". What were your pain points with ECS? Did you use ECS with or without fargate? What about EKS, since that sounds like a closer equivalent to GKE.
I've used ECS more than fargate. My biggest problem comes from reliability and having to manage things. We still run things on ECS and we get about 30x as many maintenance things we need to do, like retiring instances or instances just dying on us and we have to move things off of it manually.
I have a little bit of experience in Fargate from a previous job but not enough to make a real conclusion about it.
I've never used EKS but I do have friends that would rather roll their own version of Kubernetes on EC2 instance instead of using EKS.
Earlier quoted context omitted.
What I am saying is that this obsession was normal to us also. I didn't know any Googlers (whether in support or engineering) who didn't care about customers. We did whatever it took to resolve a support case in the quickest yet most satisfactory manner, even if it meant doing some crazy research, meanwhile we got of course overloaded with more support cases coming in. I had 100% customer satisfaction from all survey…
I really appreciate that. Both as a customer, but also as a fellow practitioner. At the end of the day, I don't think the complaints you hear about GCP Support / Service has anything to do with the people working on the line. There's always better or not better examples of folks you encounter as a customer. As a support consumer, I've learned that my feelings about the person on the other side are very much colored b…
A lot of support became outsourced and the original support team became more of a tier 3 backline support with the first 2 tiers being handled by vendors. This started for GCP just after I left in mid 2013.
The vendors responsible for support have contracts to meet certain customer satisfaction metrics and time to first response metrics (based on customer tier and ticket priority). The majority of inbound support cases would get auto assigned to the vendor team. Only the top customers would reach Google employees directly.
The vendor and their staff simply have no incentive to troubleshoot an unusual issue - they also cannot have access to the tools that may expedite such troubleshooting. It's all about pattern recognition to quickly resolve a ticket. As many vendors were overeager to escalate support cases to the Googlers it became necessary to impose more requirements on the vendor team to be able to escalate an issue - invalid escalations were being tracked and the vendor would be penalized for the total of these.
I built the internal tool via which GSuite and GCP outages or significant issues would be managed from a support perspective. This had the advantage that vendors didn't need to waste their time (poorly) parroting (with a delay) the status of an outage as related incidents could be (manually) grouped together and then all be updated at once by the current incident manager on the support team - freeing up lots of support folks to work on other support cases.
I definitely agree this vendor-based support model is a frustrating experience for everyone involved. I witnessed that myself after leaving Google. By the way, I'm very surprised GCP tries to upsell you on consulting services based on your support interactions.
Running a support organization for a very technical product with so many unknowns and variables at scale is hard. I wonder who does that well and how they accomplish it (from an operational perspective).
I have no idea how AWS manages support internally. I work at Azure - until last week as a Developer Advocate, now as a software engineer in Azure CTO incubations - I have no idea how our support organization is run or what their quality is. However, from what I hear Azure support is eager to help anyone and everyone. I remember being very confused I got a phone call to inquire whether I needed help within a day or two of signing up for an Azure free trial.