No. I work exclusively with scaling Linux workloads in Azure and local failover happens fairly regularly without the user ever seeing any indication. The hypervisor has its own cache which is tied more to your storage acct & runtime data-disks than the VM itself. This is true even with the lowest cost storage option: LRS standard blob-storage.
Howwwwever, LRS storage does not save you if the whole datacenter goes down, or during scheduled maintenance (when the whole datacenter is down.) For that, you'll need ZRS (which does failover to a co-lo in the event of the primary datacenter going down) or GRS (for which you can configure/test your failover options.)
Also, Microsoft's strength is in their PaaS services, like app-service or Azure-Functions. Those usually have CosmosDB on the backend, which is pretty much the best failover/DB-availability server-software on the market in my opinion.
VMs in all clouds are always tied to specific machines. If that machine fails unexpectedly then those VMs will restart. If it is a controlled reboot (e.g. host update) then they may not restart...
On Google's cloud, at least, VMs don't get killed for planned hypervisor downtime, which is a potential differentiator for them. Of course, this should matter a lot less for workloads that have been explicitly designed run on Kubernetes...
Well, at least in Google Cloud for planned updates you can get your VM host migrated and not lose a Node due to a planned maintenance. I am not aware if Azure supports this, but my guess is they do not.
Came here to post this. To me it shows the gap between Azure and the non-enterprise world. Azure did this awhile back, as well as the managed k8s thing, neither of which got much run on HN.
Perhaps Azure needs to work on marketing? Is there a legitimate reason Azure isn't getting more traction in the non-enterprise world? I mean that as a totally serious question, not in a dickish way. Is it because it has the Microsoft name attached to it or just because AWS has so much traction?
As always, full disclosure that I work at MSFT as well.
Devs in my team can pretty much chose their favourite cloud to deploy things to. Everyone always picks AWS, it's just the easiest to navigate and feels like everything links together well.
I think the only things we use Azure for is the Directory, and Functions to run some PowerShell.
As AWS is the industry standard, I feel that a lot of people like to stick with what they know too.
I'm in the unfortunate position of being curious about the one thing that folks are best advised not to share, your security/compliance stack. Based on what I've seen to date, nothing handles all three equally well, but I'm curious if you've found anything that gets close.
> Is it because it has the Microsoft name attached to it or just because AWS has so much traction?
Yes on both counts.
Also, the perception is common that Microsoft = Windows Server, to a very high degree of bias. Thus, if you don't operate on that platform, you'd immediately disregard Azure. A lot more work is needed to convince non-Windows operations & developers to buy into Microsoft's offerings around Linux. Emphasis that that says nothing about the quality of existing offerings, rather, the issue is of perception. The perception is that Linux is and will always be a secondary concern with Microsoft; and potentially worse, skepticism over whether Microsoft will invest into and support Linux over the very long term. If one buy into that skepticism or doubts Microsoft's commitment to Linux, AWS is immediately a superior choice as a long-term platform bet.
I work for Pivotal and have observed that Cloud Foundry, which has had a boatload of success in this space so far (including on Azure, we won Azure NA consumption partner of the year in 2016 AND google Cloud partner of the year), but you wouldn’t know this from HN posts and comments. It’s some strange big relic from 2012...
HN has strong biases towards things that are startup-targeted or individual hacker targeted: open, inexpensive or new and small, or ubiquitous. Kubernetes and AWS in general get a lot of play compared to Azure , GCP or VMware (or even OpenStack these days). Nothing wrong with that necessarily, just a cognitive bias of the up voters.
"Perhaps Azure needs to work on marketing? Is there a legitimate reason Azure isn't getting more traction in the non-enterprise world? I mean that as a totally serious question, not in a dickish way. Is it because it has the Microsoft name attached to it or just because AWS has so much traction?"
The problems of support and network effects go two ways. People perceive that Azure favours Microsoft tech, and may not support other platforms as well, which may or may not be true. More definitely, the tools and libraries for non-Microsoft languages tend to support AWS as the cloud of choice by having more features and being more heavily-used and tested with AWS than GCP or Azure.
Azure is doing a lot of address this but creating repeatable infrastructure with Hashicorp tools like Packer and Terraform just required way too many steps. However, they are much closer to competing with AWS than GCP.
Exactly this. I think this is pretty much the use case most people envision when they think about a container orchestration service (it was for me, anyway). My understanding is that EC2 and friends didn't deliver this on day 0 because efficient container isolation is hard.
Copy in the sense of the product features, not the product implementation. Joyent has long provided a "run your container as a service" which IMHO is the best way for a small/medium to run container services. The whole create VM's to run containers creates a lot of extra work. Plus this could be great for teams doing data analysis, just spin up 100 containers for 30 seconds type of workloads.
The OP is short on details anyways, does Fargate run on a tuned xen vm's or do they have linux servers under there (or maybe they're SmartOS ;) ).
Yeah, looks very similar. I will be interested to see how quickly containers can be provisioned on FarGate.
Maybe I was doing something wrong, but my experience so far with ACI is that it consistently took about three to four minutes until a smallish container was ready for use.
What image were you running? Our internal monitoring indicates that it is generally significantly faster than that, but image pull is almost always the long pole for container startup time.
Each container has hypervisor level isolation. We are not relying on kernel level isolation for security isolation between different user's containers.
Disclosure: lead eng for azure containers and kubernetes founder here...
a) For the longest time, I've wanted a "TTL" extension for Kubernetes objects, maybe this is a good excuse to build it. But concretely, since you are paying for the VMs in the cluster (IaaS) the Pods you deploy are "free" (until you run out of cluster capacity, of course)
b) The right way to do this is Kubernetes namespaces. You can specify a different Namespace in each user's draft config file that will place each developer's containers in a different namespace.
Now that I write that, though, that seems like too much work. We should probably automagically build a unique namespace for you...
They're by no means perfect, but we try to be super open about our development process.
Many of the github issues also have comprehensive discussions of topics, searching the repo for topics you're interested in will often surface interesting discussions.
If you want to get more deeply involved, I'd suggest the Kubernetes community meeting (Thurs, 10am Pacific)
Are you guys still working on the documentation ? I tried to setup a test Kubernetes cluster for a recent hackathon and couldn't get it to work. minikube kept cribbing that 'host only adapter we created cannot be found' ( I think this error is from docker-machine ) and the vsphere tutorial failed while trying to upload the vmdk file.
Software Engineer (Cloud) | Microsoft (Azure) | Seattle, WA
Come work on Azure Resource Manager, the core API gateway and template engine for all of Azure. We're a large-scale, distributed, highly reliable service that enables deployment across all resources in the Azure stack. Development in C# with an agile (scrum + backlog) methodology. Position is onsite in Redmond, WA.
For more information, email bburns [at] microsoft [dot] com
