> We have a direct line to Seattle, and parts of what we ring up at tickets have made it into the global 365 infrastructure.
This is great for one business, but bad for the whole of businesses IMHO. Microsoft shoehorns every little thing into their products, never asking themselves if they should. As long as they think they can they will. This leads to stupid things like Durable (aka stateful) Azure Functions. Durable functions is a product of a business either not knowing how to use FaaS properly, or they were misusing FaaS for something where they should have chosen a different tech. But Microsoft being Microsoft will try to accommodate any stupidity they can as long as it will please some big customer. In the beginning they get away with it, but over the years that's how they always end up with half baked, slow and buggy products which are inconsistent, incoherent and just awful to use. Azure is certainly on that trajectory from everything I've seen so far and I use Azure every day at a client at the moment so I know what I'm speaking of.
Microsoft is here to stay mainly because once you got your foot in the door at the big companies you will stay forever. The reasoning is indeed since we already have Microsoft guys Azure will fit us well but in practice none of these Microsoft guys will be able to help you on any Azure issue. So when Azure is involved in a big corp, accenture is usually not far behind. The experience with the solutions this doom duo comes up with are absolute hell to deal with.
In upfront cost Azure looks better but in general that's rarely the case. All the azure API's seem half baked. Once you're doing anything more advanced you will run into issues, just look at the terraform azure provider issue tracker for a bunch of issues that people run into because it's not clear until you actually try out the apis.
Here's another example if you want to use shared storage on kubernetes with any reasonable iops, the azurefile premium storage increases IOPS per Gigabyte allocated. So if you want any kind of reasonable experience/price you have to easier spin up your own nfs server, use azure netapp or allocate 10TB shared premium filesystem per share, which is something like 70k a year.
I like AWS, but AWS EFS has the same problem. They've improved it a bit through some recent changes, but it's not much better.
The way it would work: they gave you absolutely pitiful base IOPS credits for EFS and everything else was related to disk space used. So more disk space used (and paid), more IOPS. After that they'd completely detroy your IOPS if you used up all the credits. By destroy I mean IOPS at the level of a HDD from 1995.
I set up a Jenkins using EFS and initially it went well. It barely had any activity and after about 2 weeks it used up all the credits. After that even the login page would take 20 seconds to load.
I think it's throughput credits that EFS gives you (e.g r/w MiB/s), not IOPS. AFAIK they don't document the IOPS available at all.
In my experience the latency for an individual i/o operation on EFS is always at the "HDD from 1995" level regardless of available burst credits. Something that does lots of small random I/O like checking out got repos on Jenkins workers is basically worst case for EFS.
It's NFS, so the bad latency isn't surprising. The problem is that they don't have anything faster -- it tops out at 2GBy/s or something, even with hundreds of TB, even with multiple clients. You have to share your data over multiple EFS volumes, or build your own virtual gluster, which are extremely shit options. Also makes any kind of bug data HPC impractical.
Bezos, if you're listening, fire someone. You should have next generation pNFS or lustre like protocols by 2016.
But also, how does the pricing work? It seems to be half the price of EFS? It almost seems like that are assuing S3 read or Direct Connect to populate the FSx volume.
The agents were in ECS with no persistent storage, so that wasn't the problem. I was just running the Jenkins master off of EFS, for the persistent configuration storage.
And I don't think it's the latency that's killing EFS usage, it's the throughput. While the credits were there, everything went smoothly, once the credits ran out, the base throughput was fit for IO meant for the 90s.
We had the same issue with a pgsql server. Started out fine, but to get decent performance you pay out the nose for higher disk throughput.
It looks competitive when your pricing things out and don't know you need to pay for that. When you find out it's a classic sunk cost fallacy and most companies just eat the cost.
To be fair, Microsoft has only decided on Kubernetes within the last year. Before that there was heated debate on whether to support K8 or ServiceFabric, their "competing" standard. Now that all efforts are on K8 we'll see it improve pretty quickly.
> Microsoft shoehorns every little thing into their products
That's just how enterprise software works. It's not a Microsoft thing. It's an enterprise thing.
Consumer software often benefits from simplicity and elegance.
But for enterprise software, clients have hard requirements, so you provide the solutions they request.
There really isn't any choice to it. If you don't build it, they'll go with a competitor who will.
There truly isn't any other solution, unfortunately.
At best, you can spend more money trying to improve UX and interfaces. But when you have a set number of employees, and have to choose between improving the interface or building the features that will land another client, it's easy to see which choice gets made.
I agree, but I think that’s on Microsoft. I’m not sure they’ve ever adopted any suggestions from us that weren’t universally wanted. When teams first became available in 365, it was automatically enabled for everyone. Today it’s not, we requested this change, but I really doubt we were alone in that.
That’s not really what’s important to us, but I should have made that more clear. What is important is the direct line, so that we can call Microsoft and get updates directly from the techs working on the issue when something breaks. Amazon also has genuinely great support, they were even quicker to resolve the GDPR issues that made sure no one outside of the EU will ever access any of our data, not even through logs. But other companies let you talk to automated scripts, and take days to get back to you. So that’s why we like the direct line to Seattle, because it’s better support than most of their competition.
Microsoft also has one of the best and most effective sales machines in the world.
Those direct lines help with customer retention and expansion of services just as well as it provides technical assistance.
Even if AWS has some tech or price superiority, good luck prying those sales teams away from the big orgs and convincing them to go elsewhere - especially after significant ecosystem lock in. Which is another thing Microsoft is better at.
Microsoft simply has the enterprise sales machine completely dominanting and optimized.
It was fascinating watching them role out Azure with the full force of their developer and CTO focused marketing machine which kept hitting me even though I’d never use Microsoft, their ability to penetrate markets was fascinating to watch as an outsider.
This is something Google will never be able to catch up with. And a very important part of these cloud wars which get overlooked while we debate the merits of Microsoft’s engineering yes-to-everything the managers ask approach.
This is great for one business, but bad for the whole of businesses IMHO. Microsoft shoehorns every little thing into their products, never asking themselves if they should. As long as they think they can they will. This leads to stupid things like Durable (aka stateful) Azure Functions. Durable functions is a product of a business either not knowing how to use FaaS properly, or they were misusing FaaS for something where they should have chosen a different tech. But Microsoft being Microsoft will try to accommodate any stupidity they can as long as it will please some big customer. In the beginning they get away with it, but over the years that's how they always end up with half baked, slow and buggy products which are inconsistent, incoherent and just awful to use. Azure is certainly on that trajectory from everything I've seen so far and I use Azure every day at a client at the moment so I know what I'm speaking of.