The Podcast
Calendar Icon 11.13.2019
aws-section-divider
Audio Icon
A Day in the Life of Azure DevOps with Sasha Rosenbaum
About Sasha Rosenbaum
Sasha is a Program Manager on the Azure DevOps engineering team, focused on improving the alignment of the product with open-source software.Sasha is a co-organizer of the DevOps Days Chicago and the DeliveryConf conferences, and recently published a book on Serverless computing in Azure with .NET.

Links Referenced: 
Transcript

Announcer: 
Hello and welcome to Screaming in the Cloud with your host cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on this state of the technical world and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.


Corey:
  This episode is sponsored by AWS Solutions, which is the exact opposite of AWS problems. AWS Solutions are vetted, technical reference implementations that are designed to help you solve common problems and build faster. They themselves are free though occasionally some of the products they stand up are, not but it’s a great way to click button wind up receiving a technical solution that’s implemented that ideally solves a problem you have. Visit snark.cloud/AWSsolutions again that is snark.cloud/AWSsolutions and my thanks to AWS for their generous sponsorship of this episode. 


Corey: 
Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Sasha Rosenbaum. Sasha, welcome to the show.


Sasha: 
Thank you. Thank you for having me.


Corey: 
So you're a senior program manager or thereabouts on something called the Azure DevOps engineering team where you focus on improving the alignment of the product with open-source software. That's a wonderful, I guess synopsis of what is almost certainly a much larger story, but let's begin at the beginning. What is it you'd say it is that you do?


Sasha: 
Okay, so thank you for this question. It's kind of a complicated question. So I've held many titles over the years, right? I started off as a developer and I did that for a bunch of years. Then I was a consultant. Then I became a cloud architect, which means I helped a bunch of people move to the cloud, coincidentally happens to be Azure Cloud.


Sasha: 
And this was the first time I'm a program manager and I'm on something that's called a community team for Azure DevOps, which means a lot of my job is around connecting people and so helping us align on different messages and help each other. Because we often find it that different people across the industry or even across the company are working on the same thing and they just don't know that the same effort is going on. So sort of helping people stay aligned is where we are.


Corey: 
Which I guess leads to an interesting question of, and again my apologies for not having done enough homework to be able to answer this myself, but what precisely is an Azure DevOp?


Sasha: 
Okay, so obviously I did not name the product, and as our friend Matt Stratton likes to say, you know "You can't buy DevOps but I can sell it to you." So this is kind of maybe along these lines, but also, you know words tend to evolve. So the folks who coined the word DevOps meant one thing, and right now we're seeing it all over, you know all over the industry where people apply it to all sorts of different things.


Sasha: 
Azure DevOps is a product that is a SAAS product based on Azure that helps you implement CI/CD and also helps you with a whole host of other things related to development, such as you know managing the project, you know planning and [inaudible 00:03:07] and all sorts of things. So kind of the whole package, as a SAAS product.


Corey: 
Okay. There are two things I feel that urge to, I guess one thing is a statement. The second is a question. The first is a statement in that this is an actual product name. So if you see someone in the wild with Azure DevOps on their resume, that's not someone who has no idea what words mean, but rather someone who is effectively dealing with a terrible product name that makes a resume look like random buzzwords thrown together for SEO purposes. Nope, it's real. You're not allowed to make fun of someone or reject them as a candidate for having this on their resume unless they're responsible for having named it.


Corey: 
Secondly, it sounds like the service itself is very similar to what one of your competitors does, except for the fact where you own this competitor, namely GitHub or jif-hub, as I insist on pronouncing it, seems to be focused fairly heavily on expanding beyond just a place to host your Git repos, or jit repos, we're all things to all people here. And increasingly giving insight into these things of being able to handle CI/CD natively rather than just integrations with third parties that provide these things with actions, with workflows, with a bunch of, I guess, almost a pipeline style approach.


Corey: 
Where every time I look at the GitHub landing page when I log in, there's new capabilities I didn't know were there. So now this is sort of the inherent problem of building anything that looks even remotely like a platform. What's the difference, I guess, between what GitHub is doing and Azure DevOps or isn't there one?


Sasha: 
So, first of all, thank you for not holding titles against people, because I know a whole bunch of really excellent people who are you know Azure DevOps professionals, and they are doing great work out there. So it's awesome that they can get you know hired. It's funny because I track Twitter feed for Azure DevOps and I see a whole bunch of job postings with that in a title. So it's kind of funny to me.


Sasha: 
But so on the GitHub question, so this is, and I feel like I've answered every single one of your questions, but like a preface of it's complicated but it is somewhat complicated. This is one of those things where humans like to have a very cohesive story. And we started to have a little bit of shades of gray answer to the question. So we, the Azure DevOps is a product that evolved out of TFS. So it's been in development for over 10 years, and we've modernized big parts and pieces of it.


Sasha: 
But, again, this is sort of a progression of an enterprise facing journey that we've been on. And now recently we've acquired GitHub. So GitHub is now part of the Microsoft family. But at the same time they're a standalone company. They manage their own decisions, right? They're cloud agnostic and all sorts of different things like that.


Sasha: 
So as far as this journey, back a year ago, I guess, when GitHub released Actions, the biggest requests for them was to implement CI/CD with Actions, right, because originally they did not intend to do that. And so once they saw the overwhelming requests from the community, they decided to go after that workload. Which means that, yes, you're right, we kind of in a Microsoft family now have two products that can solve the same questions, the same workload.


Sasha: 
It's also true for repositories, right? Because obviously GitHub is the biggest source code on... you know hosted product in the world and Azure Repos also has Git Repos available. And so we get asked a lot of times on which one should I choose, and the thing is technically there is some differences between the two and one of them might be more applicable to you than the other. And I'm not going to get into the technical differences.


Sasha: 
I think we're going to eventually publish documents, like publicly available documentation on those. But the other thing is, so I think GitHub in terms of CI/CD is kind of starting out, right? So they are ready, like just from releasing the preview of Actions, they've seen amazing adoption and lots and lots of users on the platform. But also in terms of being enterprise ready, it's going to take a while. So again, if you are looking for a SAAS product that's enterprise ready, you might be better off with Azure DevOps, but if you are sort of... In the long, long run, we're probably all looking at GitHub.


Corey: 
Got you. And at some point is there a meaningful distinction between them? Because fundamentally it is all one company and I know that's sort of anathema to a number of large environments where their biggest competitors are other internal groups. But you'd think that at some point when everyone's email address ends with the same domain, that you tend to be aligned on things. Where when an internal group offers a better solution for a particular part of the problem, then well why not just merge those things in rather than having two completely different tracks moving forward?


Sasha: 
Right, so this is not quite the same story because, like I mentioned, GitHub is maintaining its own leadership and its own roadmap and it's not going to become sort of the Azure first platform, right? Because GitHub is going to continue to serve AWS customers and GCP customers and whatnot, you know other things out there. Whereas Azure DevOps is obviously you know sort of tied into Azure, although little known fact, we have lots of integrations and we have like AWS integration that's maintained by AWS. So it's kind of cool.


Sasha: 
So basically again, we're never going to merge them. You kind of have that, and again, I don't know how visible it is outside of Microsoft, but you kind of have that example with LinkedIn, where Microsoft does not control LinkedIn as a company or the roadmap for their products. So sort of, we do obviously create more integrations around that stuff, but we don't set the goals for the these companies.


Corey: 
That's an interesting perspective. I suppose that having GitHub or jif-hub retain its independent leadership is absolutely critical to maintain the culture that it's built and you know maintaining the value that you folks paid for it. But on the other hand, I can't shake the feeling that there's a certain inefficiency when company divisions start competing with other company divisions for public offerings.


Corey: 
And again, this is not in any way a Microsoft-specific problem. I think we see it with every large cloud provider period. We see it with even relatively early stage companies, where they start to offer different product offerings that are differentiated, but also start to step on each other's toes. I, I guess it's one of those things where it's easy for me to sit here as a five person company and say, "Ah, you're getting twisted around an axle here."


Sasha: 
Wait, you have a five-person company? I didn't know that.


Corey: 
Oh yeah, there are two of us who own the thing and then we have three employees and growing. It turns out that we are larger than people thought. I'm just personally scaling horizontally as I eat my way to becoming a 10x engineer.


Sasha: 
Very, very cool. Yeah, we all are, right?


Corey: 
Indeed.


Sasha: 
Unfortunately working with computers doesn't help. Yeah. So, it's a great point and I've seen it a lot you know in the past where, especially in large companies, you kind of start implementing the same thing over and over again. So it's actually an interesting fact that like one of the things that Microsoft did as part of like the DevOps transformation that we had was that we mandated everyone to be on the same platform for CI/CD, right?


Sasha: 
So whenever you were building and releasing software, we wanted you to be on Azure DevOps, which made us our own biggest customer, which means that we can improve much faster, right, and we can test our own stuff, because we do this progressive release, right? And by the time the release hits our actual customers, it's been released to all the internal Microsoft employees, and so between... You know we have 100,000 internal customers, so in the 100,000 hopefully someone raises a red flag if there is some issue with a release.


Sasha: 
So, that's a big powerful thing because otherwise what you see is, like you said, people are competing with the same product, and it gets kind of complicated. Unfortunately here, we can't do that, because you know we still have sort of different constituencies because... So with GitHub, like GitHub has to, has certain set of priorities that will not align with potentially Microsoft internal customers and vice versa, right? We have to serve our internal customers, you know sometimes it doesn't quite align with what GitHub wants to do.


Sasha: 
And so we will definitely maintain so two products for a while. We do share some of the same code base, and we do try to bring features along to both of these platforms and we're going to continue to do that. But again, we still will have a separate roadmap.


Corey: 
Which makes a lot of sense. I think that there's a definite validity to keeping those streams separate. It just does become occasionally confusing when I think from a customer perspective where you're trying to figure out what is the best path forward? Because increasingly as I look down any technical path that transcends virtually any vendor out there, how do I wind up doing thing X?


Corey: 
And it doesn't matter what that thing might be, but it's not that there's an answer to it, it's that there are hundreds, and they're all equally valid at some point. Where it's as soon as you start looking to different blog posts and then starting to combine them together, it turns out that you've built an insane Frankenstein monster that no one fully comprehends and, surprise, you are in unicorn territory where all of your problems are ones of your own making and no one can help.


Corey: 
So the idea of having a blessed golden path to go down is tremendously compelling. I'm just not convinced that it actually exists here in the real world.


Sasha: 
I think, you know and in my personal opinion, the technology landscape just continues to get more complicated, which is really interesting, because if you look at like user experiences for things around us, we make it simpler and simpler as we go. But if you look at the technology experience, like a building technology, it gets more complicated progressively. And part of it is you know open source is a great thing, but it also means that a lot of people are building software you know sort of on small teams or even on weekends.


Sasha: 
And I've seen you know large companies stake dependencies on software packages that were built by someone as a hobby on weekends. And you can imagine that it you know doesn't always turn out so well, you know and unfortunately, I don't know that there is an answer to that. I think it's just going to continue happening and we continue to see companies pop up and solve different problems, at the different levels of the stack, right, and because like you know nothing is a complete solution, you're going to continue having like these little startups innovate in particular area.


Sasha: 
One thing that personally I think is that if you can go with a SAAS product, it's always, like I would always have a preference for that, because, hey, you know we're pretty good at running products at scale. And if you don't trust us that means that you trust your... Like you hire internal people to manage the same compute and to match the same availability and to match all of these things, and honestly it's probably going to cost you way more. And you might not even end up with a result as good as that. Right? So not everyone needs to build their platform from scratch. If you can consume some SAAS based product that will solve most of your problems, just go have that.


Corey: 
Oh yeah. Down this path is the same problem that we see with multi-cloud across the board. This is somewhat challenging for companies that are their own cloud providers to articulate because it sounds incredibly self-serving. But from my neutral third party perspective, I don't care what cloud providers someone picks. If it's Azure, it's AWS. If it's GCP, if God forbid it's Oracle Cloud, great. Pick the thing that you want that makes sense, and then go all in with whatever offerings they've got. Because trying to stitch together 500 platform as a service offerings together to build your own Franken-platform is almost never the right answer for almost everyone.


Sasha: 
I will say, so in terms of going crazy, like I have seen people try to do sort of multi cloud deployments in terms of like you know trying to do the same architecture across the AWS and Azure. Never quite works, right? But at the same time there are certain things that you could consume, right, if you're calling Cognitive Services API kind of it doesn't matter which cloud you call it on, it still works. It responds to you and stuff like that.


Sasha: 
So you could, and again, Azure DevOps is a SAAS product, like we have customers' using it with on prem and with other clouds and stuff like that, right? So, in the end it kind of doesn't matter where it is, but certainly if you are trying to deploy VM skill sets across cloud, I wish you the best of luck.


Corey: 
Yeah. So changing gears slightly, I encountered you at a few different conferences now, which is interesting. I had to triple check your title before we started recording this. Expecting to see advocate or evangelist or some other form of devreloper type job. But instead, no, you are a senior program manager. You've been a fair, you've been in this space for a long time at fairly senior roles. You have a hands on engineering background as well, but you've never had a job where, at least from my reading of LinkedIn, that everything was aligned around storytelling. It seems like that has been incidental, at least public storytelling. What's that like?


Sasha: 
Yeah, so I think that's you're spot on. So for me, this storytelling has been a hobby rather than a primary job. Now granted in my current job, I actually apparently do this more than I used to, but it's never a sort of primary thing that we work on, that I worked on. I do like talking to people. I do like being on stage, even though I... You know usually the half an hour before the talk, I deeply regret that I've you know done it to myself but, and in the moment I'm really enjoying it.


Sasha: 
I think you know part of it is just wanting to contribute to the community. You know I also am an organizer of DevOps Days Chicago and I've been there for I think six years now, and I, we just started a new conference which I want to talk about, which was called Delivery Conf, and again the biggest mission for all of these things is just connecting people and sharing knowledge.


Sasha: 
Because that's one of the things that we, well I don't know if it's as an industry or as humanity are not particularly good at, is sharing experience and telling you how to instead of you going and building a Frankenstein based on blog articles from all over the place. And you know that some of them are not even going to be accurate, which was unfortunate. You can talk to real practitioners who are building the same type of software at big companies, at small companies, right, and sort of learn from that experience.


Corey: 
I liked that you said small companies on there just because one of the, I guess, challenges is that very often we'll see the same collection of companies getting on stage, talking about their journey, how they're going to go ahead and build stories for the future, how they're structuring what you should do as a best practice, etc., etc. And inherently you see the same companies, you see the Netflixes, the Googles, the Capital Ones, the same folks who are already significantly far down whatever transformation or revelatory discovery that they've made and what they're saying doesn't look an awful lot like too many other shops.


Corey: 
Sure, there are lessons there, but the context doesn't seem to filter through very often. And that may be an unfair criticism in some cases. I'm certainly not saying that every talk by someone from those companies is inherently terrible, but it does often come with shades of nuance that are lost on certain audience members. Where, well, this is what Netflix does, so we're going to do it. Ignoring entirely the fact that they stream movies and you're a bank, is a common failure mode that we'll see. You know-


Sasha: 
I will say, Corey, I'm going to interrupt you and say this is my favorite example, right? I mean the Netflix versus a bank, because so when I go to my Netflix queue, it routinely doesn't start where I left it off and I'm fine with that, right? I mean they're running some containers, distributed operation and skydive. I can find the time spot in my movie, right?


Sasha: 
But if my bank didn't start at the place that I left it off, I would be very severely disappointed, right, not to mention that would face legal problems if they did that. So, eventual consistency as well and good, but it doesn't work for everyone. And so we are solving different problems in different industries. And definitely, again, there's a big difference between startups and big companies.


Sasha: 
I will say one thing that is kind of exciting for me at Microsoft is that we are a unicorn, but we're also... Like when I talk about the Microsoft DevOps journey, there is a real transformation there because we didn't start that way, right? We're a 40 year old company, and we did not release software on a three week cadence. I mean we release software on a two year cadence, right?


Sasha: 
And so there was a big, big difference and big sort of understanding a lot of things and evolving in how we structured teams and how we do releases and how we like even get to live site management and stuff like that. Right? So there's a lot of lessons learned for sort of enterprises that are trying to evolve towards that goal.


Corey: 
Absolutely. The trick is of course, making sure that context carries through, and to some extent that responsibility does clearly fall on the audience. Where, huh, if you know you're a bank and your failure mode is somewhat different than a large streaming media company, you have to go in with that expectation. The idea that everyone gets the root and production for example, is not really one that your auditors will listen to without throwing you out of the building. That, that has to come with the audience.


Corey: 
And I think that it's not potentially fair to say, well we shouldn't hear these stories because they won't apply to everyone. That said, I do like the idea that you're going to be hearing at Delivery Conf from folks who are not the usual suspects, that they're not going to inherently just be the same five people that we've all heard from before and telling the same slightly modified version of the talk they gave at the last conference. So I am looking forward to that. I think that there will be a lot of interesting stories coming out of it.


Sasha: 
So I hope so. And so the reason we started, and again, there's a lot of conferences out there, right? And so me and a couple other folks, so Ken Mugrage and Jason Yee, we just sort of came up with this idea and it was, it started with Ken of like, hey, we've been doing DevOps Days for awhile. And DevOps Days is absolutely great, but because it's a single track conference and it caters to a wide audience, we can never get deep into technology, right?


Sasha: 
So we keep talking about principles, we keep talking about culture, we keep talking about high level, hey, you know DevOps transformation and stuff like that. But we can't really get into the nitty gritty, because when you are getting to the nitty gritty you have to show me the tool, right? You can't abstract a way that you're using the particular cloud and a particular automation tool and stuff like that. And for people really to be able to learn from you, you should be able to demonstrate that.


Sasha: 
And we kind of noticed that all of the industry conference, which were technical, were very sort of vendor specific and we wanted to give a stage to a wide variety of vendors. So like, hey, if someone from AWS and someone from Microsoft and someone from cloud be used and whatever it is, wants to go on stage and talk about their stuff. Again, we're not encouraging product pitches but like show me how you solved a problem with a real tool is totally cool. So I am excited for this and we are going to you know try as best we can to select practitioners for giving the talks. So I think the content is going to be really good.


Sasha: 
We're also doing one more thing that is different and we'll see how it goes, but it sounds like a great idea that could work out really well. So we all really appreciate the DevOps Days in terms of having open spaces, and if folks are not familiar with an open space, it's just kind of a space where someone proposes a topic and then a bunch of folks can get into a room and have a discussion on that topic. So it's an open discussion, not a preset you know PowerPoint or whatever, and you can actually have a conversation.


Sasha: 
And these conversations sometimes are the most valuable thing that comes out of any conference. And so, but the problem is that these conversations, like if you're not in that specific room, then you're not going to be a part of it, and you're not going to hear from other practitioners and whatnot.


Sasha: 
So, what we're doing at Delivery Conf is actually we're going to record, so after each session we're going to have a 20 minute, and 20 minutes is not enough but hey, that's what we got, a 20 minute discussion on the same topic. So kind of not around the speaker but around the topic itself. So I'd say, you know you presented on ML and I totally disagree with your conclusions. I can still participate in that discussion, right?


Sasha: 
Whereas usually, you know when we ask for Q and A, we asked for Q and A that a question ends with a question mark and it's not an argument. So you totally, you're welcome to bring your arguments to this discussion and we are going to record the discussions. So it's going to be first part, you know first, oh man... Anyway, it's going to be the content that's available on our website. Once we released the talks, we will also release those discussions so they can become those like mini podcasts or whatnot and people can hear from other practitioners.


Corey: 
That sounds like it's a compelling story. I'd be very interested to hear how it works out just from a what works with conferences and what doesn't perspective.


Sasha: 
Right. Well, you're welcome to attend and participate. Then you can talk from a first party you know experience.


Corey: 
That's the hard part is it seems that if I let myself, I would never be home anymore because I'd be attending too many conferences. I made a concerted effort to knock that down significantly this year. And even as I started to plan early this morning before we recorded, the my schedule for the next year at conferences, I'm still slated to go to at least 16.


Corey: 
And that becomes a bit of an ongoing challenge for me personally just because there are things I have to do professionally that don't necessarily lend themselves to me spending a week going up hill and down dale for various conferences, despite the fact that there are so many I want to go to.


Sasha: 
Well, see you beat me on conferences, you know talking about devrelish things. But so we did schedule Delivery Conf in January, January 21st and 22nd, which was off season for most conferences. So we're kind of hoping that will help offset you know how many events are out there. There's certainly a lot of events out there. You know as I'm venturing into the speaking space a little bit more, I'm just noticing how many are out there. Just kind of, you know you could go to three conferences every week if you wanted to.


Corey: 
Yeah, that's the thing. You don't even need to have an apartment anymore. You can just go from conference to conference and eat nothing, but the buffets and the happy hour drinks and the rest and there's probably an entire subsistence living you could eek out just by going from conferences and migrating around. Problem is, is that is for someone in a very different stage of life than I'm at.


Sasha: 
Well, I do know a couple of people who became sort of digital nomads and like not necessarily conferences, that also happens to be true of like if you are on a consulting team that travels every week. You might arrive at a stage where you don't actually need an apartment. But yeah, if you have family at home, that certainly doesn't work so well.


Corey: 
Yeah, that's exactly the entire point. It's, you've got to at some point be there or people will wind up hurling you into the dumpster of history. It just doesn't go well.


Sasha: 
Certainly.


Corey: 
So if people have enjoyed listening to you, which they should have, if they're paying attention even slightly, where can they go to hear more of your thoughts?


Sasha: 
I don't have me, Sasha, I don't have exactly a channel. I do have a website which is Sasharosenbaum.com and it's sort of, I just post links to recent talks that I've done. So it's not really a blog, it's more of a collection of links. And then we do record weekly you know sprint videos, which are about every three weeks, so we do recorded video updates.


Sasha: 
So if you want to watch me on video, which is always torturous on my side to watch myself on video, I still haven't gotten used to it. So there's a YouTube channel for Azure DevOps that you can follow. Yeah, and then I am on Twitter. I now live on Twitter so you can hear my thoughts on Twitter @DivineOps.


Corey: 
Excellent. We'll throw a link to that in the show notes. Thank you so much for taking the time to speak with me today. I appreciate it.


Sasha: 
Yeah, I appreciate you having me and it's always been a pleasure. I'm looking forward to more snarky tweets from you.


Corey: 
Oh, I don't think we get away from it at this point. It's one of those things that's as certain as the tides these days.


Sasha: 
Okay.


Corey: 
Sasha Rosenbaum, senior program manager at Azure DevOps. I'm Corey Quinn. This is Screaming in the Cloud. If you've enjoyed this podcast, please leave it a five star review on iTunes. If you've hated this podcast, please leave a five star review on iTunes.


Announcer:
  This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever fine snark is sold.


Announcer:
  This has been a HumblePod Production. Stay humble.