Azure vs AWS - What is your experience?

LFaWolf

LFaWolf

[H]ard|Gawd
Joined
Aug 7, 2016
Messages
1,420
If you have used both or using both and don't mind sharing your experience -
1. Setup (VPC/ELB/Subnetting/EC2/RDS)
2. Ease of use
3. Security
4. # of services/resources
5. General/others


We are going AWS but we use MS VS so I think Azure has better integration with VS. However, AWS from I can see has far more resources and documentations.

TIA!
 
AWS is to Azure what VMWare is to Hyper-V.

AWS is industry standard, end of story.
 
DPI said:
AWS is to Azure what VMWare is to Hyper-V.

AWS is industry standard, end of story.
Click to expand...
Pretty much this. GCE and Azure are playing catchup(putting it extremely mildly) on all features. The only real leverage they have is different pricing models that may appeal to different users/companies/etc.
 
I've not seen AWS yet but I did watch an Azure demo at a Microsoft location and was really impressed with how easy it was to spin up servers anywhere in the world.
 
After doing consulting contracts to assist companies in moving to both AWS and Azure, they are very similar in product offerings. In the end from my point of view though, Azure is extremely focused on making users utilize their PaaS offerings such as hosted SQL or Web Apps, and have severe limitations for VMs (notably storage). In Azure, if you have a client with a large SQL database that can't be moved to Azure's PaaS SQL (because these idiots developed everything around SQL 2005 and don't/can't want to refactor code to go on the PaaS SQL 2014), you would naturally just build a VM instance. What you'll find out extremely fast though is that the throughput and speed of storage is incredibly slow, even on their SSD backed premium storage. This client is now limping along on the slow storage while they get their asses in gear to update their code to work on SQL 2014.

AWS is far more forgiving here, and I've had clients just do a straight forklift move of all their systems to EC2 and still perform great.

In the end, the PaaS offerings are a LOT cheaper than running VMs for SQL, but AWS at least makes VMs a viable option where Azure does not really.

EDIT: As a note, if you ever ask microsoft about this, they will come back and basically tell you to use Windows 2012R2 and storage spaces to stripe multiple 1TB SSD disks. Which is certainly a band-aid solution, and extremely costly when you have 8 1TB SSDs just for performance and only use an eighth of the space
 
Azure is behind AWS in so many ways, you end up stubbing your toe on the Azure problems at every turn.
Making subscriptions isn't something you can automate.
They say PFS works on their VPN tunnels, but when it didn't work, their support techs' response was "yeah it doesn't work, I think it would work better if you turned it off"
Their VPN tunnels don't support modern DH groups.
Their blob storage doesn't support a default root page, while S3, GCS and Cloud Files all do.

Billing is such. a. pain. in the ass for non-Azure SKUs. If you spin up Marketplace offerings you get almost zero insight into what the fuck that dollar figure is for. For instance, if you ran a bunch of ClearDB, you'd just get a bill for x hours of the ClearDB offering level, rather than a normal breakdown with meters like the Azure SKUs. Additionally, it can't bill against your Azure commitment, so even if you've put up a goodly amoutn of money in Azure commit like we have, you get a random $xxx bill to handle. If you use those Marketplate services and hope that you'll get enough information out of Azure to do passthrough billing, don't hold your breath.

They have some rather low limits on the number of certain resources you can put in subscriptions, so you have to be aware of all of that way ahead of time and plan way the fuck ahead.
Azure subscription and service limits, quotas, and constraints
Sure you can have 10,000 VMs per region, but you're limited to 200 storage accounts per subscription, so you'll probably have an RBAC isolation need that will eat those up long before you get anywhere near 10,000.
Azure Storage Scalability and Performance Targets
Some of the recommendations are to use a subscription per project and per environment (eg Companyname - Project - Development Subscription, Testing Subscription etc) , and while that's a huge pain in the ass already, maybe it's not such a bad idea.

But ultimately all of that is such a huge pain in the ass over AWS that it's just not worth it. If it weren't so difficult for us to get into AWS or a competitor, it would already be out the door.
 
My company uses both but my division has standardized on Azure. Azure just feels like it's perpetually in public beta with so many features "coming soon". We like to say that Azure is "just a little bit wrong" in pretty much every service they offer.

My biggest gripes:
1 The API is constantly changing so that script you wrote to automate tasks will work one day and suddenly stop the next
2 New features like Managed Disks are rushed to market (the default option for IaaS) with missing features. For example, you can't move/modify a managed disk once it is deployed so the only way to move a VM, change a resource group, or subscription is to delete and redeploy the VM.
3 The names of most objects aren't modifiable once deployed. Try enforcing an ever-evolving naming standard when the only thing you can do is nuke and pave
4 The different Azure services aren't designed from the ground up to integrate with the rest of the Azure ecosystem. Anyone who's used AWS can attest that linking AWS services together is as simple as a drop-down. In Azure, it takes days of research to find the PowerShell commands to maybe accomplish with you are looking to do.
5 Tags aren't as meaningful in Azure as they are in AWS. For example, you can't build a security group policy around specific tags.
6 The functionality of the portal, PowerShell, and the CLI is out of sync. For most advanced tasks, the portal is useless which means you need to write scripts (see point number 1)
7 Different regions have different capabilities
8 No metered billing (great if you want to use third-party products in non-prod environments which don't have tons of traffic)
9 Their Basic Load Balancer object is limited to 250 rules (both NAT and LB) which really prevents you from creating any advanced enterprise-class configurations using Azure specific products. This will be fixed with the Standard LB Speaking of their load balancers, there's no way to see backend host health.
10 Most of their PaaS offerings aren't vnet aware which causes problems if you want to put PaaS infrastructure behinds WAFs or Firewalls. Yes, you can do things by public IP but then you pay double data costs and increase latency

A couple of positives:
1 For us, Azure (at least with our EA) is much cheaper than AWS. MS is trying hard to lure companies in and is giving smoking deals for those who invest heavily.
2 Azure is responsive to feedback and incorporates suggestions into their code pretty regularly
3 Automatic restarts of VMs which are impacted by hardware failures
 
what blackrino9 said, but i just wanted to add, The biggest benefit of azure is ability to control costs. You can be put out of business on AWS (this is as of a year ago, havn't touched it since mostly use digital ocean these days for non windows stuff) with dos and what not. Saw a 500k bill for a guy who normally paid around 30k a month. I have no idea how it was resolved because wasn't someone i was responsible for.
 
Thanks for all the responses. After deciding to use AWS and have been using it for more than a year now, I can honestly say that AWS is much more user friendly and allows us to get up to speed quickly. There are a lot of resources and readings available on AWS if we need to figure things out, whereas Azure, not so much. In addition, billing is a lot easier to read and understand on AWS than on Azure. I wish we could use Azure, as we use Visual Studio 2017, and I still haven't figured out how to deploy from VS or Team Services to AWS (vs deployment to Azure), and the integrated Team Services functionality with Azure should play nicely. If anyone knows how to deploy from MS Team Services to AWS please let me know.
 
Oh, and did I mention that because Azure changes so rapidly and they have two portals (classic officially retires this January) that most of the documentation you will find is out of date?
 
I liked Azures console, it's refreshing after 5 years working on AWS to have an interface that swims with you.

GCEs cloud terminal is nifty, made Kubernetes a bit more friendly for on the fly management.
Kinda takes the in your face panel thing Azure has and spins it in a different way.
Cli hipsters trying to tell me they want to type kube cmds and that's all they need can go was their moustaches.
They can all delve into how Go is the best thing ever.

I like the VS AWS plugins, an AWS ECS guy ran me thru his setup last year.
I've got my SecOps guy using it now.
My node/react guy is always last on the uptake, but he likes it.
I'm teaching my .NET guy AWS-isms so he can take more ownership of his deployments.

The trick is to really understand Cloudformation, use parameters so a Dev environment won't have RDS multi-AZ enabled for cost/resource savings. Understand hold and wait conditions. Know when to prebake and when to pass configs with userdata. There's a flow I found that made stacking old templates for a particular environment very satisfying with VS. I used to use json diff, designer, AWS console, Atom, etc etc etc all opened up in different quadrants on a 4k tv. Doing stack updates that way makes the VSTS plugin good right there. It brought me closer to that single pane of glass Nirvana all the Terraform guys tout, but I never found that cool.

Lambda is a topic onto itself, as my stated fave is all of the effort and time shaving triggered events you can dive into. The SecOps guy really likes Lambda, a lot of good practices can be incorporated within CFN states. Again, it's there in a project explorer and less time consuming for the SO to build in his buddy bumpers.

So it's less about using the VSTS plugin to deploy, but diving deeper into services to make your life easier. We have all found something really slick that we dig on, I think most of it is reducing alt-tab distraction.

Set it up, add your credentials, give it a spin.
 
I find AWS support more helpful than folks at MS.

Haven’t had a good support person every time I called into MS for varies of different issues...
 
It really depends on what your doing with your instances.

AWS: If you are forking your current infrastructure to the cloud, running service whose code is janky, looking to scale older applications, AWS is really the only choice between the two. If you are psuedo cloud, i.e. still running servers with an OS, AWS will beat Azure in pricing through its instance marketplace.

Azure: If you are building from scratch, especially web apps and mobile development, Azure is a great PaaS API. This isn't to say that AWS doesn't have most of the same functionality, but I swear finding the service you want to hook in to takes 4x as long with AWS. As someone noted there is a lot "Beta" like stuff in Azure, but unlike AWS you know that a feature exists or will exist whereas I will sometimes go to a AWS conference and find out that something I had been griping about existed in some backwater corner of the AWS platform for years but I wasn't part of the right Reddit group that would have linked me to it. I find Azure documentation to be a lot better, YMMV.

If you are looking at pushing out a mobile platform, I would recommend looking at Firebase. There is a lot to love about Firebase for rapidly pushing out an app, however I wouldn't put them up against AWS - Azure for broader services. Also, documentation is a mess, I have spent hours implementing something per the documentation only to find they deprecated classes without updating the original documents and no direct index links to the updates via a Google search or their a site search. You would seriously think Google would be on top of this, especially since the services hasn't been around that long but they rank last in terms of documentation ease of use.

I currently have one company running a traditional migrated cloud infrastructure on AWS. That includes virtualizing and migrating accounting servers and local in-house application servers to AWS EC2 with S3 and multi-tiered backups.
I have one company using Azure IoT and PaaS services. It currently services 200K+ clients and is setup to scale to millions.
I then have about two dozen "apps" that run on either Azure or Firebase.
 
somebrains said:
I liked Azures console, it's refreshing after 5 years working on AWS to have an interface that swims with you.

GCEs cloud terminal is nifty, made Kubernetes a bit more friendly for on the fly management.
Kinda takes the in your face panel thing Azure has and spins it in a different way.
Cli hipsters trying to tell me they want to type kube cmds and that's all they need can go was their moustaches.
They can all delve into how Go is the best thing ever.

I like the VS AWS plugins, an AWS ECS guy ran me thru his setup last year.
I've got my SecOps guy using it now.
My node/react guy is always last on the uptake, but he likes it.
I'm teaching my .NET guy AWS-isms so he can take more ownership of his deployments.

The trick is to really understand Cloudformation, use parameters so a Dev environment won't have RDS multi-AZ enabled for cost/resource savings. Understand hold and wait conditions. Know when to prebake and when to pass configs with userdata. There's a flow I found that made stacking old templates for a particular environment very satisfying with VS. I used to use json diff, designer, AWS console, Atom, etc etc etc all opened up in different quadrants on a 4k tv. Doing stack updates that way makes the VSTS plugin good right there. It brought me closer to that single pane of glass Nirvana all the Terraform guys tout, but I never found that cool.

Lambda is a topic onto itself, as my stated fave is all of the effort and time shaving triggered events you can dive into. The SecOps guy really likes Lambda, a lot of good practices can be incorporated within CFN states. Again, it's there in a project explorer and less time consuming for the SO to build in his buddy bumpers.

So it's less about using the VSTS plugin to deploy, but diving deeper into services to make your life easier. We have all found something really slick that we dig on, I think most of it is reducing alt-tab distraction.

Set it up, add your credentials, give it a spin.
Click to expand...

Would you mind telling me how you perform CI/CD with VSTS and deployed to AWS EC2 automatically? I did some searched and found no simple solution.
 
LFaWolf said:
Would you mind telling me how you perform CI/CD with VSTS and deployed to AWS EC2 automatically? I did some searched and found no simple solution.
Click to expand...


Yea, I had to figure it out myself as well since there is no documentation. But once working it's works fantastic.

We have an EC2 build box with the VSTS agent installed (All created/reproducible with cloudformation). The server runs the build, and drops the files in a folder along with the appspec.yml file and our associated powershell run script. VSTS has steps in the release to use AWS CLI to push that directory to codedeploy (zips folder and moves to s3 bucket), then the next step triggers the CD deployment. Then I have a custom powershell script that polls the CD deployment until it's complete (or fails and returns the error). The app servers are also in an autoscale group, so I can scale up/down/cycle boxes for updates and they always pull the latest code.
 
Cfn-hup will pickup updates and kickoff also, but you have to tune up your wait/hold, signal, and dependson conditions bc deployment order isn't guaranteed.

We setup a token in github and map a kickoff with CodeDeploy & CodePipeline, I think we are getting away from Jenkins and using CodeBuild unless a team explicitly want to use rolling updates over time.

How are you tagging your app servers to rollback if you are replacing them in the same ASG? Normally we are going with blue/green as CodeDeploy's 2 options make some of my teams stick with Jenkins and CFN.
 
I'm a developer. If youre wanting to quickly build apps in visual studio there's a lot to love about azure. If the plan is server less everything in the cloud go aws. If there are specific things you want in the cloud azure can be great. We have email and smaller dbs moved to azure. Azure sucks for large high use dbs unless you spend way too much. There is clearly a window I'd pick azure for.
 
blackrino9 said:
Oh, and did I mention that because Azure changes so rapidly and they have two portals (classic officially retires this January) that most of the documentation you will find is out of date?
Click to expand...
This hit me when I was adding sendgrid yesterday... It's hit me a few other times too
 
Don't get me started about MS's bizarre old/new portals. I was on a conference call with my MS rep a few weeks back asking him, why I still have to use IE in 2018 in order to access some functionality. Since my company uses InTune and SCCM for managing in house workstations and servers, there is a constant bounce between IE and (fill the blank modern browser) to manage Azure, Intune, and MS Partner pages. I keep waiting for the day all IE specific pages are gone, but they still keep popping up in MS land.
 
My role, in relation to cloud, over the last 5 years has mostly been around AWS. Interestingly though, I am starting a new opportunity with a Fortune 20 company, in a Sr. "DevOps" role to automate new infrastructure/application/etc to AWS and now Azure. I have been spending the last 2 weeks at my current job, while short-timing it, to start work with learning the basics of Azure and even being able to spin up stacks via Terraform. I must say, looking at my comments from 2 years ago in this thread, Azure has definitely made some strides. I hadn't given it two thoughts since then, but now since its a job req to learn, its impressing me more than i thought. It's not on par with AWS, but its definitely closing the gap quickly. Obviously this is a high level couple sentence response. But, the ease I was able to convert my existing automation knowledge of AWS to Azure in just a few weeks, at least functionally, was surprising. I don't care about portals or GUI access. Purely programmatic manipulation. So far in just two weeks, obviously way more to go, I think I will be able to accomplish anything needed as I could in AWS.
 
4saken said:
My role, in relation to cloud, over the last 5 years has mostly been around AWS. Interestingly though, I am starting a new opportunity with a Fortune 20 company, in a Sr. "DevOps" role to automate new infrastructure/application/etc to AWS and now Azure. I have been spending the last 2 weeks at my current job, while short-timing it, to start work with learning the basics of Azure and even being able to spin up stacks via Terraform. I must say, looking at my comments from 2 years ago in this thread, Azure has definitely made some strides. I hadn't given it two thoughts since then, but now since its a job req to learn, its impressing me more than i thought. It's not on par with AWS, but its definitely closing the gap quickly. Obviously this is a high level couple sentence response. But, the ease I was able to convert my existing automation knowledge of AWS to Azure in just a few weeks, at least functionally, was surprising. I don't care about portals or GUI access. Purely programmatic manipulation. So far in just two weeks, obviously way more to go, I think I will be able to accomplish anything needed as I could in AWS.
Click to expand...


Same goes for AWS. It's massively improved over the past 2 years, and I'm constantly finding previous limitations have been removed. A lot of the improvements are adding functionality to cloudform that was only available through API calls. Still have some services that can't be fully configured through CF, but that list has decreased a lot.

Azure is nice because it's services are more like complete packages. Yes, you can do the same thing in AWS, but it typically requires configuring multiple different services together to get the same functionality as azure. We are all AWS here, but have products that use azure services because of this.
 
AWS is like what the web used to be in in the 90s - primitive UIs, a terrible console, zero integration between services, services they offer are not as performant or feature rich.
GoogleCloud or Azure is like the modern web - there is simply no comparison in the user/developer experience.

The difference is inertia and momentum, and that allows AWS to keep adding new services and slowly improve the popular ones.
 
MrCrispy said:
AWS is like what the web used to be in in the 90s - primitive UIs, a terrible console, zero integration between services, services they offer are not as performant or feature rich.
GoogleCloud or Azure is like the modern web - there is simply no comparison in the user/developer experience.

The difference is inertia and momentum, and that allows AWS to keep adding new services and slowly improve the popular ones.
Click to expand...

100% misinformation here. I have to question how much exp you have in these services. GCE is horribly behind. Azure has a great UI and compares more on services to AWS. But honestly if you are actually using the UI to perform day to day in any of these services, you are already way behind the curve.
 
4saken said:
100% misinformation here. I have to question how much exp you have in these services. GCE is horribly behind. Azure has a great UI and compares more on services to AWS. But honestly if you are actually using the UI to perform day to day in any of these services, you are already way behind the curve.
Click to expand...

I am using the UI and not CloudFormation stacks etc. I am in a small team of 2 and have to do lot so maybe in future. There is no doubt that GCE console and integration is ahead of AWS. Also AWS services that aren't popular are pretty bad - e.g. Elastic Beanstalk, CodeStar, CodeBuild etc are all really slow and lacking in basic features.
 
MrCrispy said:
I am using the UI and not CloudFormation stacks etc. I am in a small team of 2 and have to do lot so maybe in future. There is no doubt that GCE console and integration is ahead of AWS. Also AWS services that aren't popular are pretty bad - e.g. Elastic Beanstalk, CodeStar, CodeBuild etc are all really slow and lacking in basic features.
Click to expand...

lol, OK.
 
MrCrispy said:
I am using the UI and not CloudFormation stacks etc. I am in a small team of 2 and have to do lot so maybe in future. There is no doubt that GCE console and integration is ahead of AWS. Also AWS services that aren't popular are pretty bad - e.g. Elastic Beanstalk, CodeStar, CodeBuild etc are all really slow and lacking in basic features.
Click to expand...

How is elastic beanstalk “not popular”? Its one of their core offerings and massively adopted.
 
Grentz said:
How is elastic beanstalk “not popular”? Its one of their core offerings and massively adopted.
Click to expand...

I don't know that its widely adopted. It is definitely extremely slow and has seen almost no improvements. A deploy takes 5-10min, and a lot of settings are still not exposed in console.
 
MrCrispy said:
I am using the UI and not CloudFormation stacks etc. I am in a small team of 2 and have to do lot so maybe in future. There is no doubt that GCE console and integration is ahead of AWS. Also AWS services that aren't popular are pretty bad - e.g. Elastic Beanstalk, CodeStar, CodeBuild etc are all really slow and lacking in basic features.
Click to expand...

That's the whole point of automation like cloudform.... You take the initial hit on time creating the templates, now you can redeploy entire environments with a simple command.... Once you start codifying/versioning your infrastructure you'll never go back.
 
You must log in or register to reply here.
Back
Top