Recently, Ron Harnik, our Product Marketing Manager, and Sebastian Stadil, Scalr’s CEO, hosted a webinar on AWS and Azure – breaking down exactly what was the difference between the world’s leading cloud providers. It was one of our highest performing webinars – letting us know that developers and administrators are still searching for the right direction in building their cloud solutions. As the number of multi-cloud enterprises continues to grow, we thought it would be essential to boil down the details of that webinar into the following summary.
If you want to watch the webinar in it’s entirety (it’s worth it), visit the link below.
Otherwise, read on.
Ron started the webinar off with an excellent statement – enterprises tend to listen to analysts and other enterprises. While the developers and front-line IT engineers experiment with cloud providers in small pockets, it’s the top down mandate from the CIO that defines what big companies use across the board. In other words, what are all the other kids doing, and should I be doing it? In searching for the answer to the above question, we talked to Scalr customers, analysts and enterprises we have relationships with. There’s three core facts that we learned.
- More often there is no cloud adoption policy, multi-cloud tends to just ‘happen’
- This also doesn’t happen at the team or application level, it’s typically at a business unit/department perspective
- Phase 1 is on premise/VMware
- Phase 2 is when pockets of developers use AWS, Azure
- Phase 3 is discovering multiple pockets of cloud usage across business units, and central IT has to find a solution to this
- Most companies use AWS or AWS + Azure
- Single cloud companies are exploring to try other clouds
- Azure is gaining ground not because of technical superiority, but through an aggressive discounting campaign
- Microsoft Enterprise Agreement customers will get significant discounts. It’s the lowest-cost bidder concept.
- AWS isn’t necessarily interested in playing the ground-game now that they’ve proved themselves.
- Huge ecosystem of services, tools, and relationships with vendors
- Strong IaaS and PaaS products
- Aggressive release schedule. Every other day they’re making improvements
- Because of all of this, AWS/Amazon knowledge is easy to find in administrators and developers
- Easy to use, hard to master
- AWS puts a lot of work into the most popular services (which is obvious), but the less popular ones get faded away
- Complex pricing (mentioned in depth)
- Complex support – it’s not relationship based, it’s more tiered based. More premium support. I.e. big company size doesn’t matter – everyone pays at the tiered levels
- Choice paralysis – it’s a full time job keeping up to date with everything being released and best practices
- Cost management tools are often needed to supplement Cost Center/Billing
- Through 2013 – 2015 Azure has been rapidly rolling out releases and support. Customers say that the overall infrastructure is ‘good enough’ for now
- Support for Linux and other OSes has been released, not just forced to use Windows Server
- Azure Stack, now in technical preview 2, is an on-premises deployment that works great with cloud providers. It’s an extension of the cloud environment
- In efforts to race to market, not all features are finished, or have complete API support
- Documentation can’t keep up with releases – as an example as Security Groups have evolved on the dev side over the past few months, the public documentation hasn’t kept up
- In contrast to AWS, there’s a limited number of Azure experts
- Vendors are reporting problems with secure authentication, slowing down deployment. But this is relatively minor – Azure is still extremely focused on
What Customers Are Saying
As you may have guessed, most companies are more inclined towards AWS because of their broad range of services. There’s tons of cloud-based solutions for services companies would be interested in using (like Service Catalog) or simple solutions to products they’ve hobbled together (like data warehousing with RedShift). On the other hand, Azure is meeting the baseline requirements of most companies as an IaaS. In other words, most companies don’t need all the bells and whistles – give us VMs, storage, load balancers and databases and we can figure out the rest.
Azure Stack (now in Technical Preview 2) has been generating a little bit of buzz, and will be released on dedicated on-premise infrastructure. The precursor to this, Azure Pack was an interim solution, a free collection of Microsoft Azure technologies available to Microsoft customers. It integrates with Windows Server, System Center, and SQL Server to offer a self-service portal and cloud services such as virtual machine hosting (IaaS), database as a services (DBaaS), scalable web app hosting (PaaS), and more.
On the Azure side, customers also mentioned that even if the Support system isn’t too helpful at the low level, you’ll almost always be put in direct contact with Engineering so you’ll get solutions.
Here’s the analog of the individual services provided by both clouds.
A quick summary on the less popular services above:
Direct Connect/ExpressRoute helps companies establish a dedicated network connection between the public cloud provider and their on-prem network. The benefit is consistent network performance and a reduction in bandwidth costs by funneling data directly through the provider.
AWS GovCloud/Azure Government is for the most compliancy-driven organizations – governments. By running on dedicated hardware separate from other cloud customers, 24/7 monitoring, multiple backups across data centers, and all servers held on country soil (i.e. clients using Azure Government would have all servers on continental U.S. soil), these solutions are engineered for security.
AWS Directory Service for Microsoft Active Directory (Enterprise Edition)/AWS Microsoft AD/Azure AD is a directory and identity management service. The big benefit is integrated into your directories that already exist (single sign-on access to SaaS applications that a company may already be using like Salesforce or DropBox. Azure AD also includes a full suite of identity management capabilities including multi-factor authentication, device registration, self-service password management, self-service group management, privileged account management, role based access control, application usage monitoring, rich auditing and security monitoring and alerting. As for the naming scheme – they all integrate with Microsoft AD which AWS conceded that most enterprises wouldn’t migrate from.
Everyone’s biggest concern at scale is typically security. As it rightly should be – not only do we have to make sure our applications and information are secure at the network level, we also have to create systems that ensure that user error won’t be the downfall of our infrastructure. In both AWS and Azure, Security Groups are the main way to manage network security. One of the big challenges in cloud are when you’re trying to enforce old security paradigms on cloud providers. The issue? There’s no single enforcement point.
AWS Security Groups
- Can secure EC2, RDS, ELB
- Security Groups are applied to the primary Elastic Network Interface(ENI) by default
- You can apply multiple security groups to an instance
- White list only – only allow rules (inbound/outbound). I.e. allow HTTPS for your public facing sites, SSH only from your IP for email servers
Azure Network Security Groups (NSGs)
- Can secure VMs and Subnets
- Applied to primary NIC on servers, or all VMs in subnet
- Both Allow & Deny rules. For more detail on how NSGs work, visit this blog post
- Unlike AWS, you can’t attach multiple NSGs to a VM or Subnet. The difference is only from the administrative perspective – you can easily get out of control with multiple security groups on instances. This NSG structure dictates better user habit.
- All rules are stateful
Generally, the consensus is that AWS pricing gets confusing, especially once you start to use more and more services, across regions. Cost visibility isn’t stellar, and while you can tag resources to track billing, the process tends to fall apart as more developers and end users use Accounts.
There’s three types of AWS pricing.
- On Demand – Services billed by the hour. A typical example would be when selecting instances and you can see the difference between instance families (i.e. T3.larges charge $0.019 an hour)
- Spot – Bid for instances. When cost goes over, bid instance is determined.
- Reserved – You are able to reserve instances and compute capacity for 1-3 years. You can receive up to a 75% discount for reserved instances when you pay up front. There’s two types – Standard and Scheduled. Standard means you’ll be reserving this instance full-time for the next year. Scheduled means you can reserving these instances at specific times. Examples: we need more processing power at night-time as we turn over data, or during the holidays e-commerce sites need boosted services over a stretch of time when our infrastructure gets overwhelmed.
In addition to pricing, here’s how support ties into AWS.
Here’s how Amazon defines what AWS Support you may need:
Developer Support – Experimenting with AWS
Individual developers exploring the potential of AWS, looking for access to technical support resources to help quickly and effectively get started.
Business Support – Production Use of AWS
Businesses looking for guidance and best practices to enable availability, scalability, and security of production workloads – reducing the need for reactive support.
Enterprise Support – Business Critical Use of AWS
Businesses whose success is directly linked with the performance of workloads and applications, benefiting from high-touch proactive/preventive services.
- On Demand – Billed by the minute. There’s two options: Standard or Basic, which defines the support you have around those instances.
- Pre-Pay: Companies are able to reserve VMs at a 5% discount when purchasing over a year-long period.
And how support ties into Azure:
Like we mentioned, Azure really is the MVP of cloud providers in a sense – when you really just need IaaS and already have a Microsoft Enterprise Agreement, the choice is pretty much made for a lot of big companies. You’re not getting the best product per-se, but it’s straightforward. AWS won the lowest cost bidder game back when they first came out, so they’re no longer interested in the ground game. Pricing has become more convoluted and complex.
Following Ron’s analysis of pricing and and security, Sebastian Stadil, our CEO, spoke on the legal complexity behind both providers. Curiously enough, Amazon makes you sign a IP Non-Assert Clause when using their products. If you’re a company that has an IP(Intellectual Property) based business, be wary because it’s a pass through agreement. There’s two troubling issues: duration and scope. Duration states that this clause of the contract lasts in perpetuity. So if one of your employees has ever signed the agreement to use an AWS product and Amazon starts infringing on your IP, they’d have great grounds to keep you from taking them to court. Scope also means that if several developers have been using AWS and signing these pass-through agreements, any case you would bring against the company wouldn’t stand too much of a chance.
On the flip side, Microsoft has more leniency in the legal department. There’s no clauses like this in the Azure agreements. After the brutal IP wars Microsoft has gone through over the years, and especially in the 90s, Azure doesn’t have any of the ‘gotcha’ agreements written into AWS. Again, all of this isn’t worrisome to most companies, but if you have an IP centered company, it would be essential to work out an agreement beforehand.
After a fantastic Q&A from the audience (check out the webinar for that – starting at the 40 minute mark. Sample question we got: As a startup what are the pivotal decisions in deciding between AWS and Azure?)
Access & Permissions
AWS and Azure handle access and permissions a little bit differently. AWS is centered around users, and groups via Identity Access Management (IAM) Policies. Policies define what resources can be accessed or what actions can be performed. In other words, policies define the WHAT and WHERE. Groups are the collection of users those policies are applied to.
On the other hand, Azure uses Role Based Access Control (RBAC), which associates Users with Roles. Roles grant hierarchical permissions to resources, meaning that they define WHO, WHAT, and WHERE. If you’ve used Google Cloud Platform, the organizational structure is similar.
Here’s how that workflow usually works:
- Create an IAM Group:
- Add Users to that Group. An example would be Q&A team, developers, sales engineers, and so on.
- Create Policy: You have three options in creating policies. You can copy and edit existing policies. AWS has a ton of them that cover the basics you need, like access to S3, EC2, and so on. There’s also an IAM policy generator. Lastly, you can also write your own JSON policies.
- Associate Users with Roles
- That’s it. With resources(instances, load balancers, etc) organized into resource groups, you assign your users to roles in the scope of these resource groups.
At the end of the webinar, Ron & Sebastian had a great freeform discussion on what cloud provider companies should use. The general consensus is that you should start with AWS – going back to that concept of ‘easy to use, hard to master’, and then expand into other clouds as you look for better solutions. Most enterprises end up with a multi cloud solution, as different business units and teams will use a particular public cloud for a specific solution. That’s not an issue though – with cloud management platforms you can take the concepts we discussed above and easily abstract them to a higher level, meaning that visibility with pricing, security, role based access, and services are easily solved through one interface.
This is just an overview on the webinar, so if you’d like to learn more and specifically how Scalr solves the issues we mentioned above, watch our on-demand webinar – AWS vs Azure – 5 Differences You Need To Know. The first half covers an overview on how enterprises manage multiple AWS account, then at the thirty-five minute mark we jump into solutions for the challenges discussed above.