Screaming in the Cloud - A Day in the Life of Azure DevOps with Sasha Rosenbaum

Episode Date: November 13, 2019

About Sasha RosenbaumSasha 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: Sponsor: Snark.cloud/AWSsolutionsTwitter Username: @DivineOpsLinkedIn URL: https://www.linkedin.com/in/sasha-rosenbaum/Personal site: https://www.sasharosenbaum.com/Youtube channel: Azure DevOpsCompany site: microsoft.com

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 the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. 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 slash AWS solutions. Again, that is snark.cloud slash AWS solutions. And my thanks to AWS for their generous sponsorship of this episode.

Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Sasha Rosenbaum. Sasha, welcome to the show. Thank you. Thank you for having me. 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? Okay, so thank you for this question. It's kind of a complicated question. So I've held many sidles 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. This is 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 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.

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 DevOps? 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. This is maybe along these lines, but also words tend to evolve. The folks who coined the word DevOps meant one thing, and right now we're seeing it all over the industry,

where people apply it to all sorts of different things. 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 managing the project, planning and artifacts and all sorts of things. So kind of the whole package as a SaaS product. 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. 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 Jithub, as I insist on pronouncing it, seems to be focused fairly heavily on expanding beyond just a place to host your git repos or chit 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, 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? 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 awesome that they can get 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 funny to me. On the GitHub question, I feel like I've answered every single one of your questions with 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 have a little bit of shades of gray answer to the question. The Azure DevOps is a product that evolved out of TFS. It's been in development for over 10 years and we've modernized big parts and pieces of it. 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. So as far as this journey back a year ago, I guess when GitHub released actions, the biggest request for them was to implement CI CD with actions, right? Cuz originally they did not intend to do that.

And so once they saw the overwhelming request from the community, they decided to go after that workload. Which means that yes, you're right, we kinda in a Microsoft family and I now have two products that can solve the same questions, the same workload. It's also true for repositories, right? Because obviously GitHub is the biggest source code 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 gonna get into the technical differences. I think we're gonna 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 gonna 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 like in the long, long run,

we're probably all looking at GitHub. Gotcha. 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 having two completely different tracks moving forward 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 gonna become sort of the Azure first platform, right? Because GitHub is gonna 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. 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 we do obviously create more integrations around that stuff, but we don't set the goals for these companies. That's an interesting perspective. I suppose that having GitHub or GitHub retain its independent leadership is absolutely critical to maintain the culture that it's built and 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. 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 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. Five person company? I didn't know that. 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. Yeah, we all are, right?

Unfortunately, working with computers doesn't help. Yeah, so, you know, it's a great point. And I've seen it a lot on, 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? So whenever you were building and releasing software, we wanted you to be on the same platform for CICD, right? 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's some issue with the release. So that's a big, powerful thing, because otherwise what you see is, like you said, people are competing with the same product and that 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. Sometimes it doesn't quite align with what GitHub wants to do. And so we will definitely maintain 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. 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 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 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. 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. 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. And I've seen, you know, large companies take 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. Yeah. 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. And because nothing is a complete solution, you're going to continue having these little startups innovate in a particular area. One thing that personally I think is that like 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 manage the same compute and to manage the same availability and to manage 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 ahead with that. Oh, yeah, and 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 provider someone picks. If it's Azure, if 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. 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 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, it kind of doesn't matter which cloud you call it on, it still responds to you and stuff like that. So you could, and again, Azure DevOps as 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. Yeah. So changing gears slightly, I've 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 dev reliper 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, this public storytelling. What's that like? Yeah, so I think that's, you're spot on.

So for me, the 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 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, you know, have done it to myself, but in the moment, I'm really enjoying it. I think, you know, part of it is just wanting to contribute to the community. You know, I also am an organizer of DevOps at 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 is called DeliveryConf and again

the biggest mission for all these things is just connecting people and sharing knowledge 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 experiences and telling you how to, instead of you going and, you know, 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 is 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. I like 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, et cetera, et cetera. And inherently, you see the same companies, 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. 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. 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 it's good. I can find the time spot in my movie. But if my bank didn't start at the place that I left it off, I would be very severely disappointed. Not to mention that would face legal problems if they did that. So, you know, eventual consistency is 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.

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, like when I, when I talk about the Microsoft DevOps journey, there's a real transformation there because we didn't start that way, right? The 40 year old company, we did not release software on a three week cadence. I mean, we released software on a two year cadence, right? And so there was a big, big difference

and big sort of understanding a lot of things and evolving in how we structure teams and how we do leases and how we even get to life site management and stuff like that. So there's a lot of lessons learned for enterprises that are trying to evolve towards that goal. 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 a route in production, for example, is not really one that your auditors will listen to without throwing you out of the building. That has to come with the audience. 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 Gantt 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. 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 started with Ken, of like, hey, we've been doing DevOps Days for a while, 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?

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 a 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. 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 CloudBees and whatever it is, you know, 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 gonna try as best we can to select practitioners for giving the talks. So I think the content is gonna be really good. 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 that DevOps Day is 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 um and you can actually have a conversation um and these conversations sometimes are the most valuable thing um that comes out of any conference and so but the 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. 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 let's say, you know, you presented on ML and I totally disagree with your conclusions, I can still participate in that discussion, right?

Whereas usually, you know, when we ask for Q&A, we ask for Q&A that, you know, a question ends with a question mark and it's not an argument. So you're totally 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, anyway, it's going to be the content that's available on our website. Once we release 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. 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. Right. Well, you're welcome to attend and participate. You can talk from a first party, you know, experience. 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 earlier this morning before we recorded, my schedule for the next year at conferences, I'm still slated to go to at least 16.

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 uphill and down dale for various conferences, despite the fact that there are so many I want to do professionally that don't necessarily lend themselves to me spending a week going uphill and down dale for various conferences, despite the fact that there are so many I want to go to. Well, see, you beat me on conferences, you know, talking about different things. But so we did schedule delivery conf in January, January 21st and 22nd, which is 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. It's kind of, you know, you could go to three conferences every week if you wanted to. 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 eke 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. 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 in 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.

Yeah, that's exactly the entire point. 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. Certainly. 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? 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, sprint videos, which are about every three weeks.

So we do record video updates. So if you wanna watch me on video, which is always torturous on my side to watch myself on video, I 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 at DivineOps. 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. Yeah, I appreciate you having me, and it's always been a pleasure. I'm looking forward to more snarky tweets from you. 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. Okay. 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. 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. This has been a HumblePod production. Stay humble.