Amazon Web Services and Azure both provide more than a hundred services each for various kinds of cloud computing needs. This blog post does not go into service level analysis on who has the best tools on various scenarios, but tries to bring some light to the ideological differences between the two.
Basic building blocks
Both of the products have quite similar basic building blocks, which is IaaS. You can go full ’bah humbug’ to modern services and build your systems on virtual machines on both clouds. The pieces are the same: routes, security groups, networks and VMs. Be warned though: there are differences on how the pieces are planned to be stacked on different clouds. Even if you know your stuff in one cloud it doesn’t mean that you can succeed in another; at least not in a secure and fault tolerant way.
Pieces vs models
One ideological aspect that differentiates the two cloud providers is the way services are built and designed. In AWS there is a sort of linux analogy going on with one service providing input to another. In order to build a functional system you do those service-to-service joins, spend some time deciding on inter-service-permissions and end up with some kind of mesh of services that provide you with the functionality that you want. For Azure it’s a little bit different: a single service (typically) is a bundle of functionality that tries to fulfill all your needs regarding it. If you need some external service pieces (IPs, logging, storage etc.) you just enable them on the service dialog. This ease of use and management comes with a caveat though: if you don’t like the service options you are given, it’s hard to extend or alter the functionality. When choosing a combination of cloud & services you have to balance the ease of infrastructure implementation with the functionality you are given.
Playing nicely with your existing toys
My four-year-old likes to play with Duplo by mixing them with cars, dinosaurs and train tracks, but playing with Lego consists of only playing with … Lego. In Azure almost every service I’ve studied has an aspect of being an extension to your on-premises datacenter. If a service has a Windows-server equivalent, you can be sure it can be integrated with your Azure cloud account. It’s an understatement to say that hybrid cloud thinking is strong in Azure, as for Azure it’s a way to differentiate from others. AWS has components that work well with your on-prem datacenter, but rather than hybrid they are more like an extension. You can extend your storage to cloud for example, or virtual networks, but you think of your on-prem and cloud as different entities.
Future & Common ground
Azure has been taking some steps in to the typical realm of AWS by introducing PostgreSQL and MySQL as managed databases and Linux based PaaS in App Services. AWS has also introduced services that have a more Azure-like mindset such as CodeStar (in addition to existing Elastic Beanstalk). Recently they both released the preview versions of Kubernetes as a service for container orchestration. My guess is that in the coming years the two behemoths will come to resemble each other even more, with more focus being on providing an easy way for developers to publish their code and less on building complicated himmelis (https://en.wiktionary.org/wiki/himmeli) to meet that need. Maybe there will even be a time (in the near future) when the OPS-people become obsolete as the developers can push their code out in the open assisted by systems that have elasticity, redundancy and sane defaults.
Further reading form the Gofore blog
5 things you should know before going Cloud
Kohtaus 6 pilvipalveluista kertovasta näytelmästä
