“What’s in a name? That which we call a rose,
By any other name would smell as sweet.”
Earlier this week, Microsoft’s DevOps platform Visual Studio Team Services (VSTS) was rebranded to Azure DevOps. Is this simply another rename, like going from Visual Studio Online to Visual Studio Team Services? Or is it something more?
A Trip Down Memory Lane
Microsoft’s DevOps offering is evolving rapidly. The pace of that evolution has been increasing thanks in large part to Microsoft’s own internal adoption of DevOps. In 2005, Microsoft released Team Foundation Server (TFS) 2005. I remember those days vividly: I was part of a software team at a financial services company in South Africa – we had around 20 developers. Those were the bad ol’ days. We compiled in Visual Studio and right-click published straight to production with cries of, “Hey, it works on my machine!” We were using zip files for source control (we’d just started dabbling in WinCVS) and didn’t know what Continuous Integration (CI) was. We managed our backlog via Outlook.
In late 2004, I spent a couple days installing and configuring Team Foundation Server 2005 beta 2; in those days, it took a couple of days and several hard drive formats to get TFS installed. It revolutionized our team. Now, we had a central place for source control and could actually manage branches somewhat intelligently.
We implemented automated builds with unit testing, which was a first for us. We also started to manage work using Work Item Tracking. We didn’t call it DevOps back then, but TFS spurred our team on their journey towards delivering better software, faster. When I left 5 years later, we had over 60 developers with hundreds of automated builds and were delivering much more frequently (and with fewer bugs) than in the early days. Scaling the team to that size would have been impossible without a solid platform to build on.
Around 2012, Microsoft launched a cloud version of TFS, running on Azure, called Visual Studio Online, which was rebranded to Visual Studio Team Services (VSTS) around 2014. Initially, VSTS was just TFS “in the cloud.” But as customers embraced this cloud platform, we saw the product team ship features on VSTS before they shipped them on TFS.
The product release cycle also changed dramatically, moving from 2-year cycles to the current 3-week release cycles for VSTS (with TFS updates released approximately every quarter). The product has evolved rapidly over that time and looks very different today compared to the early days.
One of the biggest changes has been the plug-and-play nature of VSTS. Arguably, the biggest competitive advantage that TFS/VSTS had over competing products (like Jira, GitHub, TeamCity and so on) has been the “single pane of glass.”
This “single pane of glass” lets you log a work item in your backlog, link it to a branch, which gets linked to a build, which is then linked to tests and releases – so you get a thread from planning to source code to test to build and release, without spending a ton of time configuring and managing connectors!
However, the “new” Microsoft of the last couple of years has seen a shift from “use our tools or die” to “use whatever tools you want to – and we’ll bring them all together in VSTS”. As Jamie Cool from the Azure DevOps team puts it: “Any language, any platform, any cloud.” This is key to understanding what Azure DevOps means for you.
A Suite of Services
Let’s quickly review the services that are collectively called Azure DevOps:
- Azure Pipelines – CI/CD for any language, platform and cloud
- Azure Boards – work item management through backlogs, Kanban boards, sprints, reporting
- Azure Artifacts – Maven, NuGet, NPM public or private feeds
- Azure Repos – Unlimited Private Git repos and centralized source control (TFVC)
- Azure Test Plans – Manual testing planning, execution and reporting
But what does Azure DevOps ultimately mean for you? That depends on what type of user you are: open source or existing VSTS user.
Goodness for Open Source Continuous Integration and Deployment (CI/CD)
If you’re contributing to an Open Source project, Azure DevOps (specifically Azure Pipelines) is the best news of the decade. Especially if you’re targeting multiple platforms. Many open source projects utilize free build services from providers like CircleCI or Bamboo Pipelines.
CircleCI gives you 1500 build minutes per month (single concurrent pipeline) for Linux; for Mac, you’ll be paying from the start. Bamboo Pipelines gives you a single pipeline and 50 build minutes per month. In other words, if you’re targeting Linux/Mac/Windows and you want concurrent builds, you’re going to have to get creative.
Many teams implement CI in multiple providers with duplicated CI definitions in an attempt some get some sort of concurrency and/or low-cost CI. Not to mention that build systems are usually horrible at releasing software. Here’s where Azure DevOps shines. You get unlimited build minutes and up to 10 concurrent jobs for any open source project and you get an enterprise-grade release management system at the same time.
And these are not some low-grade servers that Microsoft keeps around for “those open source people.” These are the same build resources that the VSTS team uses internally or that paying customers utilize. The VSTS agent runs on .NET Core, which means it’s cross-platform; it can run on Mac, Linux and Windows. And the pipelines you get using Azure Pipelines are hosted— you don’t have to maintain your own build machines (unless you want to).
If you’re contributing to an open source project, chances are your source code is on GitHub. And you can get started with Azure Pipelines right from within GitHub itself. Better yet, you can even pay for additional pipelines using the GitHub marketplace so you don’t have to manage an additional bill somewhere else.
For VSTS Users: Turn Off Services You Don’t Use
If you’re an existing VSTS user, you won’t notice that much change today. If you’ve been using the “new navigation” preview, then you won’t notice much at all. But you’ll be able to turn off services that you don’t use. Don’t use the Test Hub? Turn it off so it’s not in the navigation at all. Other than that, it’s business as usual.
So What’s in a Name?
I think a lot of folks will think this is just a cosmetic change. It’s the VSTS product team jumping onto the Azure bandwagon. Being an MVP who has signed an NDA, I got to see some of the journey that the product team went on for this “branding change”. Initially another name was chosen, but after spending a ton of money on marketing and branding companies for focus groups, the brand that resonated the most turned out to be Azure DevOps.
We all laugh at the adage, “There are two hard things in computer science: cache invalidation, naming, and off-by-one errors.” But it’s true. Naming things is hard. Visual Studio Team Services turned many customers away since it had “Visual Studio” in the name – and it really had nothing to do with Visual Studio.
One common objection I’ve heard to Azure DevOps in the last couple of days is that Microsoft is making the same mistake: Azure implies only Azure, which could potentially turn away AWS or Google Cloud users.
However, I think this is different.
If you’ve never considered VSTS because you’re a Python developer, you probably might look at Azure DevOps if you hear about it’s cross-platform capabilities. Also, Azure DevOps runs on Azure. As of October 2017, over 40% of all VMs in Azure were Linux. Add to that the world-class Kubernetes and container support you get in Azure and you have a recipe for success in Azure, even if you’re a Go or Node.js or Python developer writing microservices for Kubernetes!
The challenge, of course, is going to be to educate potential customers that the platform really is for any language, any platform and any cloud.
This Is Just the Beginning
If you’re open source, you’re celebrating. If you’re an existing VSTS user, you’ll probably be yawning a bit. Besides the being able to turn services on and off, you’re not getting too much at the moment. However, I think that this is a good change for the product.
In Q1 of 2018, Azure outperformed AWS. AWS grew by 49% to $5.44 billion, while Microsoft grew 58% to $6.0 billion. Aligning the DevOps tooling with Microsoft’s “cash cow” Azure makes sense from a long-term strategy perspective: it legitimizes any investments Microsoft makes in the platform. And that’s a good thing for all customers using the platform!
If I “look into the crystal ball” I also foresee some change in the way licensing works. Current licensing does not (yet) align with the service disambiguation that Azure DevOps brings to the platform. In other words, I pay the same per user price if I use Azure Repos and Azure Boards as I do if I just use Azure Repos. As the Azure DevOps platform evolves in the split services I think we’ll see some license splits as well, which will ultimately make the platform more affordable for those that don’t use the entire suite.
The product team are passionate about developers – and you can see that in the way that Azure Pipelines was front and center of the Azure DevOps launch. If Microsoft can win the hearts of developers – especially open source developers – then they have a good chance of moving those developers into more of the Microsoft ecosystem. Again, this is good for all customers of the DevOps platform.
When all is said and done, Azure DevOps is a significant milestone for the world-class DevOps platform that Microsoft builds and uses. It’s an exciting time for developers and I am sure we’re going to continue to see more goodness from this amazing platform.
We’re not the only ones who love Azure DevOps. Check out these posts by other MVPs:
Gian Maria Ricci: Welcome, Azure DevOps
Brian Randell: Azure DevOps, Public Projects, and Pipelines
Jokob Ehn: Meet Azure DevOps – formerly known as VSTS
P.S. Did you know that 10th Magnitude has a Managed Azure DevOps offering? We’ll manage your Azure DevOps organization for you so you can get to the business of delivering value! Learn more.