6 reasons why we picked Azure, and love it

694 VIEWS

· · · ·

At first, I was a little shy talking with my technical peers about our application that runs on Azure. My first fear was that in some way our application would be inferior to theirs. My second fear — the additional questions it would raise about our application architecture decisions. But after realizing how well our software delivery chain is set up, how well our application runs, and how nice the APIs and services we are using are, I have no qualms about getting into an argument with anyone from the Amazon AWS mafia.

If you are an AWS user, and you chose to use it because “everyone uses it,” then there is no argument. There is no way to even start a conversation. I do not participate in religious discussions that are impossible to win. i’m thinking this is the norm — I’ve yet to talk to someone who gives me a disappointing frown or an “I’m sorry” in regards to Azure who has actually tested anything other than AWS. You really cannot be blamed. The tribe mentality runs deep as part of your primal nature.

We chose to test multiple solutions. We spent three weeks each with AWS, Azure, and Google Cloud to decide what cloud or combination thereof we wanted to use for our PHP-based application called re:each. Our needs were simple. We needed VMs for our backend, a front-end PaaS, a search service, and a classification engine. In the future, we will need push notification service, and big data stuff. In the end, we chose a combination of Azure and Google Cloud, but ended up not using AWS. Here’s why:

Full disclosure Fixate is a BizSpark company — which means we get $150 of credit a month on Azure, among other benefits. But don’t let the freebie confuse you. We are also members of an incubator called i-Gate, where we have an AWS benefit. We don’t get the dollars, but the value would come out to around $500 dollars a month in credits for AWS, which we have leveraged for testing. By being a part of BizSpark, we only show some allegiance to the stack.

1.) Culture: Culture is a very difficult thing to measure, and historically we have seen companies ebb and flow in the quality of their cultures, observed in the form of support, and their relationship with the market. Fortunately we have an inside track to all vendors due to our connection with the DevOps marketplace.

Based on personal experience interacting with the AWS team, and their support, it was interesting to find that their culture looks and smells a lot like Microsoft in the days of Windows domination. Their is a very easy argument to be made about why they would be so smug — because they can, which in all honesty is valid. Just check out their recruiting page.

I cannot say that Microsoft has a fantastic culture. It’s a bit dry. But comparing the support we received from AWS on a technical issue with the report we received from Azure, Azure was far better — and it was also free. The support agent called me, not the other way around.

As part of AWS culture, their product unfortunately appears to be developed in a way that intentionally obfuscates your use of it.

2.) Visibility: AWS does not want you to know that you have rouge instances, and does not want you to be able to identify your burn rate in order to fine-tune it. With Azure, and somewhat with Google, it is very clear what your resource consumption and spend are, on a global level. Granted, we are a smaller application, so complexity is not as high as it is for others. But with the built-in reporting on spend in Azure, and the resource counters in Google, those areas are clear, without a deep dive. To get the same picture with AWS, you have to license another service like Scalr to get visibility. Or you can pay AWS more money for a management service — to find out how much money you are paying them.

3.) UI/UX: I know you die-hard nerds feel powerful when you can type loudly into a terminal window. And at times, the more complex a solution is, the sexier you feel. But we take a different approach. We do not feel compelled to show how well our terminal windows are set up. Rather, we like to save time so we can do more things faster. All of the cloud providers have the challenge of stuffing a lot of services and features into one interface. That alone makes UX tough. But AWS has no excuse for such poor quality. They are supporting modern development, and not even using modern UX. AT&T even managed to create Flow and IoT cloud, which is far more modern and easy to use!

4.) It works: I know it might seem shocking. But normally when you buy a cloud service, the most important thing is not that you buddy likes it. The most important thing is it works. And guess what AWS is not the only cloud that works. Actually all of the cloud providers seem to do just fine with their SLA. There is a lot to be said for something that functions as expected. We have not had a single outage with Azure, and it performs.

Some might say it doesn’t matter. It is true that once you spin up a server, you can live in that server. But I would suggest that in a modern development environment, you are experimenting, and testing constantly. And if you use full-stack deployments, and scripted infrastructure, you are going to be creating instances constantly. That rapid pace cannot survive effectively in a clunky UX.

We just want to get stuff done. Where Azure excels in UX is first with the dashboards. Even out of the box, they tell you so much more about what is going on. Second, their notification system for provisioning is impressive. We also like the service selection and setup wizard. And finally, the feature drill-down in services goes into layers of complexity — See only what you need to see, and basic functionality on top.

5.) The Gallery: Azure is more open, with more third-party integrations than any of the three platforms. For example, we are using SendGrid for email (which we have always wanted to use). I do not know where SendGrid servers are running, and I do not care. We use the service and are billed through Azure. So it’s all in one place. I like that I can jump to the SendGrid dashboard from Azure. You can do it manually of course, but that’s more to manage.

The setup is pretty classic Microsoft, and it has historically been used to decide who they will acquire, or squash. But for us, it’s a win. There are integrations for AWS, but most if not all are external.

Their release cycle: I do not know enough about AWS’s release cycle. When I used it, I never saw a UI update. But I do know that both Google and Azure are on modern delivery cycles. Azure is every other week at minimum, but many times, a week is noticeable. Google is updating constantly with canary releases. This is just the front-end, however. All have the same cadence for launch of services.

When we realized that Azure was a good enough cloud for us, that it had steller out-of-the-box dashboards and visibility (to the point that we did not need external server monitoring tools), with a generally lower price, we staked a claim.

We also realized that Google has APIs that are available with the same visibility, great analytics, and likely superior machine learning and big data algorithms (because they have more data than God). So we had the whole package and covered all the basis for our application needs.

I think the reason that Amazon is so popular is because they made the first move. Microsoft’s initial IaaS was horrible, but they moved quickly to get where they are today. Amazon may also be more popular because of the misunderstanding that many have — that by using Azure they are committing to using Windows. Azure is no more Windows-based then AWS is Linux. Both have their own hypervisor based on their own technology. That’s it.

Ok_Linux

We are running a few Linux instances for our backend, and periodically for testing. When we start using Docker, we will have many more, unless we decide to go crazy and use Windows Server 2016 with Docker — Heaven forbid!

But Microsoft’s work to bring open source (in particular NodeJS) tooling and so on speaks to the future of their cross-platform strategy, including the recent acquisition of Xamarin. Azure does not want to force you into Windows. They want to be a cloud operating system, just like Google and Amazon.

Azure and AWS are an apples-to-apples comparison. “Because Netflix uses it” is not a good justification for using any tool. In the OSS world, we are accustomed to leveraging projects that have the most commits and contributors. So it’s natural for techies to follow the leader. But techies also pride themselves on figuring out things on their own, and not being led by marketing.

We choose Azure and Google Compute, and they allow our application to be fantastic.

Do you think you can beat this Sweet post?

If so, you may have what it takes to become a Sweetcode contributor... Learn More.

Chris Riley is a technologist who has spent 12 years helping organizations transition from traditional development practices to a modern set of culture, processes and tooling.


Discussion

Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *

Menu