Azure Devops with AWS? Our Sweet and Savory Mix

Written by: Gabor Kovacs, VP of Delivery

As I described in a recent article, I really love to talk to candidates about our tech stack. The reason for this is that you can see their faces and questioning looks when you tell them something cool… or not so cool. I can only imagine what it feels like telling them that your tech-stack involves a database engine not used since 2008 or that you are still using Windows XP computers. Yes, you would have great feedback on your company’s cutting-edginess.

I conducted tons of these introductory rounds, and I only have one thing that most people will ask back about, and thankfully not in an “OMG” fashion, but rather interested: how did we end up using AWS as our cloud provider and Azure DevOps for everything else? This is a very strange combination, and not at all something people might think about when hearing multi-cloud environment.

The trick is that at this point I expect this question, and I intentionally say less about this and let them ask about it themselves. And now… maybe I will not need to do this anymore, because I will tell you why, but also, I will tell you that maybe you should consider our reasons.

The first thing you should know is that the AWS came first: it was added for cost-saving reasons, and generally I don’t consider neither Azure, nor GCP better or worse in any general fields. I think this is one of the most evenly played out fields in IT. I would have preferred Azure before, but now that I’ve used AWS for multiple years, I can say they are all great. But why Azure DevOps, if we already had the other one?

As I mentioned in another article, our main tech-stack revolves around docker, and almost all of them are .NET containers. This means that most of our infrastructure is based on the AWS service called ECS and ECR: Elastic Container Service and Registry. This is a great service that provides a lot of tools we can work with from a rolling release to auto-scaling. This also results in most of our CI/CD pipelines involving .NET artifacts: either NuGet packages or .net based docker builds.

If you follow that line, you can guess that most of our development team are .NET developers, and generally .NET developers are closer to the Microsoft world as any other ones. They use Visual Studio, and most of the .NET company will use Azure, but certainly many of them will use Azure DevOps.

If you are unfamiliar with the name, Azure DevOps is something that connects to Azure only in name. It is Microsoft’s own web-based solution for multiple operations around development starting with git repositories, through CI/CD pipelines, artifact storage, and ending up at ticket management. It is one shared solution instead of using of multiple different platforms within a company. As an added bonus, it works very well with Visual Studio, and it connects easily to other Microsoft solutions (such as Azure), but also has a Marketplace for anybody to create addons as well.

Since most of the developers are working using ticket management, a codebase, and a CI/CD pipeline, using Azure Devops meanstheir job is limited to using only one platform, which makes things very easy, especially considering the added integration with their own IDE (Integrated Development Environment) too. If we would use solutions such AWS CodePipeline, this would have been jeopardized, even if we move all other things there… ticket management is not really an option there.

The most important question is: how do you deploy in reality? That must be hard… but it isn’t. AWS created free addons for Azure DevOps that you can use for downloading or uploading files from S3 (file storage in AWS) or pushing containers though ECR and ECS. In a week, using the simplified – and for Linux users, “dumb” – drag-and-drop solutions to create pipelines, most of our junior developers can do a NuGet package build, without learning another platform, or some other technology (like Jenkins).

This setup enables us to hire .NET developers, who will probably already know our ticket-management, CI/CD, repositories, and will only need to dig deeper into AWS when most of the onboarding has already happened.

I can’t really imagine now not doing this the way we do, but back when we made the decision, it was a democratic decision. There was great discussion and competition between various solutions, and the majority of the votes went for the Azure DevOps approach. After more than 20 months, I’m still very happy with this combination and an only recommend trying this out if you work on a major Microsoft stack and have other financial reasons to stay with AWS anyway, because it really works for us.