Agree 100%. For instances, you have standard, high memory and high CPU and custom. Super easy to make sense of rather than crawling through webpages to understand what each type of instance mean. For example: AWS has r, t, m, g, p instance types. When you look at the whole platform, naming, gotchas etc AWS creates lot of cognitive overhead for developers. I find Google cloud far easier to use, partially due to things like these.
This is cool - one item I think is wrong/misunderstood is Big Data > Data Lake Store.
It has nothing to do with ETL, it's basically just "HDFS in the cloud" [1] and a successor to using blob storage/regular old storage accounts for distributed/Hadoop-ish workloads.
That's a good high-level list, although the comparisons don't always match up. For example, I'd say Traffic Manager is more like Route 53 than ELB (which only works within a region).
If you're after something a bit more in-depth (but covering less services) then I wrote a three part series last year. It may be a little out-of-date, but most of it still applies. Azure now supports MySQL, for example.
This. This is absolutely brilliant. I have worked with Azure for years, and mostly love it - but I learned about a few services, that I never knew what were.
Yeah, Service Fabric is more like micro-services for when you need to be able to do rolling deployments and automatic roll backs. It's something half-way between a cloud service and Function/Lamda (plus you need to buy four VMs minimum)
If it only was easy to starting playing around with Azure. Only to activate the account they require proper, bank issued, credit or debit card. They explicitly refuse to accept prepaid cards even though they are VISA/MasterCard (BTW the same problem with Google Compute)... or am I doing something wrong?
If you have either a MSDN subscription or sign your startup up for BizSpark, you can activate an Azure account without a credit card and use the credits they give you.
I've got friends who work for another cloud provider and they had major fraud problems until they instituted rules like these. Since cloud providers bill for usage at the end of the month, you can run up quite a bit of charges before the provider realizes that there isn't any money on the prepaid card and you might not be who you say you are.
My problem is not activation but rather that their free tier is too limited in terms of what services you can use.
Say I need an AD with two users, just to play with some stuff I can build for customers with "real" AD implementations? No can do, I'm supposed to pay full whack for AD like I actually needed it to manage a domain. Screw that. I should get a free tier with, say, up to five users or objects (just enough to get an object or two for each common type) or some call limit. As it is, I just let my trial expire and now I won't even think about building anything around AD unless absolutely forced.
I'm not sure what's missing from the free tier that you're looking for. It includes 500k objects. All I use is the free tier for testing against SSO, so maybe it doesn't cover your use case.
Since both AWS and azure some free tiers for a trial period, what other way do you see for them to ensure you aren't abusing the service and just creating a new account every month? Tying it to real financial accounts is unfortunately the easiest way to make that work.
Yeah, and MS is always after that sweet business 'moola, so they really want your boss's credit card. You get so many features out of the box with azure, and the free monthly credit to use them, it's no wonder they have to tie it down somehow even if it makes it an obstacle to a lone dev who just wants to try it out.
This is a problem with Amazon and Google as well, I won't give out my credit card details for an open ended arrangement, I really want to charge up my account when I'm ready.
I'm not sure if it's still this way, but I believe the default behavior is to just stop all your services when the the free trial amount has been reached before ever charging your credit card. You had to remove the spending limit for it to actually charge you. At least that's how it was when I started working with Azure. Can people who have signed up recently confirm?
Spending Limit is a great feature that Azure has that I wish AWS had. They also had it turned on automatically for me as a MSDN subscriber with free credits.
>They explicitly refuse to accept prepaid cards even though they are VISA/MasterCard (BTW the same problem with Google Compute)... or am I doing something wrong?
Prepaid cards can be purchased anonymously. If you were running a cloud provider, would you rent a server to somebody who was essentially untraceable?
I think you overestimate their commitment and responsibility. It's not a server but in case of e.g. EC2 only a virtual container. I don't even get a permanent IP but a rotating one which is already blacklisted by many websites and services. I'm talking about low end, not demanding setup. In such cases I still think that requiring credit card details is too much.
The way to think about Cloud Service is "Azure PaaS 1.0". Service Fabric is "Azure PaaS 2.0" focused on creating a micrososervice architecture for your services. Also, Azure Automation's equivalent is not strictly CloudFormation in AWS (that is Azure Resource Manager) but AWS Lambda for IT/Hybrid, it also does Configuration Management like Puppet/Chef.
"cloud services" isn't really an IaaS at all. Kinda. Cloud services were a deployment model where you basically built code that deployed to two types of "roles". Web roles serviced http calls. Worker roles just executed code from a given entry point/method. Typically an app would be user facing web roles, azure storage or azure sql for persistence, and then worker roles for async processing. They are trying to get cloud service customers to migrate to Service Fabric, which, to be fair, is super dope. Not kidding. It's rad. I've deployed a couple of things on it and its bad ass. Love it. Never really used cloud services.
Azure IaaS is really just what you would think. It's actually quite good. They don't have the "spot market" type instances that Amazon does. They don't oversubscribe CPU cores. (I think they may have one VM type that gives you a "partial core", otherwise your VM core is yours.) To get the most out of it you need to build with update and fault domains in mind. Here's a link...
Short answer - Cloud Services is the old stuff. Virtual Machines is the new stuff. Never use cloud services for new projects. I wouldn't event include it in the article
Sure it's old, but Cloud Services and VMs are two different things and there's only a little overlap (in the sense that VMs creates availability groups and can load balance endpoints). Cloud Services offers machine provisioning via a packaged file that contains the code to run, configuration and other important bits.
Any reason you recommend it to not be used for new projects? (yes, I understand it's ASM and not ARM and shows up as "classic" in the new portal, but you can still get quite a lot out of it that you can't easily get with VMs or App Services).
The reason I don't recommend it is that it clearly has not future. It is not deprecated or killed, but it is kind of frozen. Will continue to be supported but no new investment there. it missed the train, and this train is going places, so you really want to be on it.
Yes, Cloud Services and VMs are two different things, however, Azure's IaaS was built on top of this concept up until when they migrated to ARM and VMs.
The way it used to be, was that Cloud Services was Microsoft's PaaS, and when they introduced IaaS (Yes Azure had PaaS first), they built it on top of cloud services. So essentially IaaS built on top of PaaS. Most people would expect it to work the other way around, and so that's exactly what they did with the new stuff - They invested heavily in re-doing the entire IaaS stack, and then built PaaS components on top of it.
Regarding ARM, VMs, the new stuff- We call it 'new' to differentiate from the 'classic' stuff, but it shouldn't be considered as such. It is old enough, stable enough and it the recommended way to do stuff on Azure.
If you are doing just IaaS - there's no question there. Use the ARM model.
Cloud Services did have nice features mostly for programming model, and code deploy, but there are ways to do that with ARM as well.
There is not a single direct replacement to Cloud Services, and it makes the transition harder. this is because the new model has different architecture and layering of the stack.
If you are looking for these features, I recommend looking at a PaaS framework in the new stack like Service Fabric.
They really want people to transition cloud services apps to Service Fabric. It's quite good and has the same feel, with more flexibility in what your "roles" actually execute. Oh, and Service Fabric runs on Linux too.
Very good overview.
One point that I disagree with, Cloud Services:"Run stuff but worry a fair amount about configuration and patching." We run a bunch of cloud services and MS are responsible for patching, I would describe it more as PaaS that IaaS.
Very useful, as is the one for AWS. Yay! though if these things are being touted as "plain English" they should probably steer rigorously clear of smart-ass insider references (no matter how full of cheer the writer may be feeling at the moment) because that's probably how these titles and terms came to be so opaque in the first place. But, again: yay!
Ok, reading the comments I feel obliged to respond... I could find an error almost in every row, but I picked the most misleading ones:
Service Fabric is not equivalent to Lambda, we have Azure Functions for that. SF is a cluster orchastration framework (think mesos) and it also has a rich .net and java sdk for developing Microservices that will be orchastrated on the cluster. it can also run exe \ containers. it is not server-less at all. It is nothing like API Gateway.
App Services is just web site as a service. I wouldn't call it PaaS but I understand this term is subjective.
Cloud Service is an old concept that we never recommend for new workloads, so I think it doesn't belong on this article.
Virtual Machines is self explenatory and it's very much like EC2 unlike who the article present it.
API Apps is not a proxy, it is an API. You could host you web API (any web framework) here. It is the same as website but with some semantic difference and cool swagger integration.
Virtual Network is not just for hybrid scenarios, it is the fundemantal container of all IaaS based resources in Azure.
Traffic Manages is not a like a classic Load Balancer (as the comparison suggests). It is a "Smart DNS" service for multi-region geo deployment.
Data Lake Analytics foes not "hold" any data. Data Lake Store does. Analytics is a batch processing technology that can process data from Store, but you can use Spark or whatever to do that as well.
Data Lake Store - see above. I think they confused this one with Data Factory.
How about a couple of the most egregious so we can judge, do you have issues with their explanations of the core services or maybe just the more niche stuff like the Media Services?
No, I found that a bit wrong. it's more like Mesos+Marathon, or Kubernetes. It's a cluster management solution that manages your services or processes and their rolling deployments. can run on-prem on your linux or windows machines, or managed on azure with a portal.
You can host any executable (or containers). And it does reverse proxy for you too.
Exactly! I found their description a bit inaccurate too. I am yet to see a true service offering on other platforms like service fabric. [Disclaimer: I work at MSFT]
