291–300 of 311 posts
Earlier quoted context omitted.
Last time I checked, Google and AWS both had very, very high egress prices. At these levels, it's far cheaper to connect to a Tier 1 provider or three.
Did you check what their price was at the $2B purchase volume?
So they hit $400m of revenue in 2016 and have committed to spend at least that much on infrastructure each year for the next 5 years? After all the costs for staffing and everything else they better I hope they achieve amazing growth if they ever intend to profit.
Will Snap exist in 5 years?
Many talking of software here, but at this scale I think we should be looking at the cost of energy. Suppose Google has a true edge on the rest of the market in terms of what the cost of a Watt is to them. Take that outlook over the horizon of 5 years; all software arguments are thereby moot. If Google can generate a Watt in 5 years at 10% the cost that AWS can, then this drastically changes the equation.
I don't follow these things closely, but what's the reason to expect that Google will be able to generate a watt at 10% of the cost that AWS can? 10x seems like a massively impressive edge to have over another huge player in the market for a commodity good like power.
Earlier quoted context omitted.
> Also them starting the project along with the knowledge they have internally scaling containers helps. FWIW, Most of this are advertising gimmicks though and Google has a pretty different internal infrastructure for orchestrating containers that has hardly much to do with K8s.
This is not correct. I've worked with both borg and k8s and k8s is effectively a rewrite of borg using the same container infrastructure. There are differences, but they aren't meaningful.
Am I totally off-base, if you're able to speak to this? (Maybe it exists and I've missed it, but I'd love to see a blow-by-blow of the differences and their rationale, too, because that'd be valuable insight on how Google learns.)
Earlier quoted context omitted.
This is not correct. I've worked with both borg and k8s and k8s is effectively a rewrite of borg using the same container infrastructure. There are differences, but they aren't meaningful.
I can think of a couple that seem meaningful, like cluster state management architecture (borgmasters/checkpointing vs. everything lives under consensus in etcd -- ish), which seem to have introduced real difficulty in bringing Kubernetes to parity with Borg, particularly in the scale department. Then I see a comment like yours and realize again that thought was put into it by much smarter people than me, but that on…
When I say k8s is like borg I mean: it has the same concepts of tasks, jobs, and allocs. The scheduling of those is handled by a k8s scheduler which resembles the borgmaster scheduler (a lot of hand waving here), and the containers themselves execute in an environment much like the borglet provides for containers.
Many of the valuable features provided by borgmaster and borglet are provided in k8s and you configure them through similar mechanisms.
Beyond that, how they are implemented specifically, there are a ton of differences but for an end user who is just using k8s, not setting up and managing k8s infrastructure, it's conceptually isomorphic.
Earlier quoted context omitted.
Easily move? It seems to me that you have no serious experience in the real world. There's something called "data gravity", and the non-secondary issue of how to migrate a "live" system (in production) from one cloud to another over the course of typically several weeks. Moving from one cloud to another, even with containers, is never easy at large scale. (source: I have worked at AWS for 6 years, at VMware for 2, an…
I consider 'toomuchtodo a voice of authority on operations based on much reading and discussion (particularly on moving to physical, which we've discussed before), have performed the very exercise being discussed four times in my own career ranging from a couple cabinets to a couple hundred million in capital, completely agree with the entire comment to which you are replying, and feel that your jab about "serious ex…
It'd be one thing if they were going to use some of the IPO money to cost-optimize revenue, but I get the feeling that they need to focus on growing revenue due to how Insta Stories gutted them in 2016. That means hiring more people and writing bigger checks to Google.
And they're branding themselves as a "camera company." Their hardware division does not contribute materially to revenue (not profit: Revenue), and practically every other consumer camera company, from Kodak to GoPro, is dying.
This is not a healthy company.
But DocuSign derives a lot of money from B2B and uptime and location of the servers is important to other Enterprises. DocuSign also started building out its services more than a decade ago before a lot of the AWS or Google Cloud infra got built. So, the decision to build your own infra is as much a decision based on alternatives available. Few alternatives? Build your own infra.
By staying on GCP, Snapchat also guarantees its service and uptime will not change appreciably over the next several years. They built on GCP and migrating the whole service off would probably be a gargantuan task (how do you flip a switch and move all your compute overnight without hurting customer experience?). Staying with GCP allows Snap to maintain consistency of service while also buying time to build a transferable version of Snapchat that they could move to other infrastructure after the Google contract is over.
Investors on Wallstreet don't like seeing huge changes to company strategy too close to IPO. If GCP has worked for Snap thus far, it is far less risky to investors for Snap to keep on going "business as usual." It's better to overspend to guarantee certainty of service and business health over next few years than do a massive capital investment. Once Snap gets off the ground post-IPO, they can make longer term decisions about their infra.
Earlier quoted context omitted.
Can anyone here provide some info or make a comparison with the Azure Container Service here, or any AWS option? I'm going to go through all of the service offerings this weekend - from Docker Inc's Docker for Azure and Docker for AWS to the native container services on each.
Azure Container Service is simply a PaaS-ish offering of Swam, DC/OS, or Kubernetes. It still spins up VMs that you can log into, but handles deployment/provisioning of the product, and makes some assumptions about your use case. It's a great way to push a button and have a "real" deployment of those services to evaluate, especially if your goal is a platform-agnostic target. I work for an Azure-focused cloud consult…