CloudTalk- S1E16 - DevOps - Agile Teams


Tolga Tarhan  00:01
Because I think back in the day when applications went through tonnes of cycles, and from code complete to production, could have been six months or a year. I think developers actually did take a bit less responsibility for things. Like how do you configure this application in production? How do you scale it in production? How do you promote it between environments? I think that's all front and center now. When the line between application and infrastructure is virtually invisible in these modern apps.

Jeff DeVerter  00:30
That was Tolga Tarhan. Now despite having the honor of being Cloud Talk's, first returning guest. Tolga is also the corporate CTO at Rackspace. And as you'll hear in this episode, Tolga comes from a deep application modernization background, and has lived the process from the chair of a developer, a team lead, and a business owner. Now, don't think that Tolga's current lofty position has taken him away from the tech, as you'll hear, he's still as close to it as ever.

Intro  01:05
Welcome to Cloud Talk. Here's your host, Jeff DeVerter

Jeff DeVerter  01:08
So I was having a really interesting conversation about a week ago with some of the technologist around the shop here. And we're joking. Seems like we're always joking about this, but there's some words just become relegated to being buzzwords even though they started with with being such a valid part of our lives. And unfortunately, the word DevOps gets pulled into that. And here to help me pull that apart and talk about, the goodness, and the badness of it all is Rackspace's corporate CTO Tolga Tarhan. Welcome to the show again.

Tolga Tarhan  01:45
Jeff thanks for having me. Yeah, second time. Here I am.

Jeff DeVerter  01:47
There you are you. In fact, we were just talking before, you are the first repeat who got his own episode two times. We had somebody on a panel, but I don't know if that's going to count or not.

Tolga Tarhan  01:58
I'm claiming it. Yep, you're right.

Jeff DeVerter  02:00
That's awesome. So DevOps, oh, the buzzword that is DevOps. In fact, we've joked about how we're going to create some interesting collateral around buzzwords, that's to show up later. But, what happened? What went wrong? It was such a good idea in the word DevOps, what went wrong?

Tolga Tarhan  02:18
Gosh doesn't that happen to all of the good buzzwords though. I mean, the word cloud, like everything is cloud now, even your desktop software somehow. The word edge is going through the same kind of trouble today. I think what happens is these words that are exciting, that have a chance to change how we do things. It's very natural to co-opt those words into everything you do, it's a good sales and marketing tactic. And unfortunately, it washes the word out, and you lose the meaning. 

Jeff DeVerter  02:49
And what we're going to talk about here a little bit later, is how, in a truly functioning DevOps team, what that team structure? What the positive impacts are? To how that is a whole part of making this be successful. But not all teams are poised for success when they run down this road. I asked you earlier, what's an example? When did you see it fail? Let's start with the negative example.

Tolga Tarhan  03:13
Yeah, I've seen where people say they're doing DevOps, where they say they're doing agile. And you may even hear this word, wagile, it's like waterfall and agile mixed together. And unfortunately, that's not a great recipe. What happens is, you typically have an organization that has tonnes of functional teams already. So, they have a team that does UX, and a team that does requirements, and a team that does development, and a team that does testing. And one that just does infrastructure builds and maybe automation build outs. And then some other sustainment team that runs it in production. And the problem was, when you do an agile and DevOps transformation, but you don't actually properly refactor all of that. You end up with an org, where maybe the dev team is operating agile, they tend to be the ones that most quickly adopt these methodologies. But then the teams on both sides of them, the left and right of them, in this process are still operating functionally. So, I've had teams that were going to the cloud, and they were going there in a pretty dramatically modern way, all serverless for example. And they would adopt all these processes that made sense in that environment. I mean, how you build and deploy everything is, by definition, immutable in those environments. But yet, when it was time to deploy, they do work with teams whose processes were designed for a different model. And that disconnect actually makes it a lot worse. It probably makes it worse than either model would be. And it creates awkward things like asking permission from the infrastructure team to create a table in something like DynamoDB, where because they're used to launching a database it is a big deal. Launching a database has tonnes of DBAs involved and very clear requirements to find how much performance do we need from this database? And what hardware should it run on? And those processes just don't map when a developer says, "I need a table to store my users and DynamoDB, it's just a button they need to push. So, that's some of the failure scenarios that I've seen quite a bit.

Jeff DeVerter  05:17
Well, when a lot of those technologies even started to come around inside a big enterprises. These were the ones, these original people were like, "Hey, come on get with the program. We're using the database now. It's gonna make all the world better." And all of a sudden you end up with all of this history, and formulated processes that are so rigid, that they just won't bend. And when a new process comes along, they then become the ones who are holding things up. And it's really interesting point you make that even if one community adopts it, you really have to have everybody come along for the party, or the whole thing falls apart.

Tolga Tarhan  05:52
Yeah, as we functionalized IT, I guess two decades ago, and you have specialists. I'm a network guy, I'm a security guy, I'm an application guy or a database guy. I think the way those teams manage their workload was by putting rules in place that said, "Well, to deploy X, you must talk to this team." And those processes are still there today. And the problem is, it's no longer a functional model we're working in. It's all these things are API driven. They're in your automations. They're deployed as part of your app. And really, you want to deploy them as a whole set to each environment. So to dev environments, into staging and prod. And it just doesn't kind of flow through the system the same way. And we need to move on from call it pre-emptive, blocking type controls where you can't do X, without a certain team's oversight. To more of an advisory and monitoring level where, hey, experts do need to help you optimize how you use data and databases. But they don't need to be a gatekeeper to you creating that table in your dev environment. We need to wait to adapt to controls at different points along the way.

Jeff DeVerter  06:58
Yeah, so I was working, this is way many years ago, in early part of my career. But I was working with a company, back when I was in the SharePoint world. And I think there were a lot of characteristics of SharePoint that are similar to what we think of in the cloud today. There's an underlying database that is very malleable, that you can handle through the interface or through an API, security's managed natively inside of it, and all the other things. So up until this point in this organization, if someone's bringing a web app in we could still pull in the DBAs. We could still pull in the infrastructure, we still pull in the security experts. And when we did the kickoff meeting and brought these communities in. And they started raising their hands going, "Well, who's going to control when you get a new table?", "Well, I can just create a list and it goes on their own." And it was example, after example and they were so upset. And security was actually one of the big groups. Because how can you manage your security? You're clearly not able to. But afterwards, one of them came up, and he says, "Okay, we realize we have to do this. So how do we get with the program here and turn these into guiding principles? As opposed to hard and fast rules that you guys can then implement."  And so that was that was the turning point for them.

Tolga Tarhan  08:05
Well, as you get better and better at this, go even further, and use tools that monitor for configuration errors. And so if you have a rule that says, "You must never do X, or you must never do Y". You could put a design review process and try to catch that and slow down every project. Or you could publish the guidelines, do the training, get developers and teams on board with those rules.

Jeff DeVerter  08:28
Yeah.

Tolga Tarhan  08:29
Put in policy compliance automation that looks for those violations. I've seen really great examples of this, where we've got a customer that has this sophisticated methodology. Where if you make a mistake, for example, you open a port to the world that shouldn't be open to the world. It catches it, sends you and your leader an email says, "Hey, this port probably wasn't supposed to be open. Here's a ticket that's been opened if you need an exception, and it just fixes it." But it doesn't prevent you from deploying your applications. You don't have to go ask for someone to look first. Instead, it'll monitor it along the way.

Jeff DeVerter  09:02
Brings up a really interesting point. I was talking to, actually one of the founders of Rackspace, and he's involved in a startup today. And the developers that he has there. They had this really proud moment, about six months ago, when they broke the application. They actually had a party because they broke the application. Because one of the developers, in one of their sprints, had published something out and it broke it. And he was so excited about that. Because it was teaching responsibility to some of these developers who really had just relied on it to be, quote, unquote, somebody else's job in the past. What a lesson.

Tolga Tarhan  09:35
Yeah, Jeff that's a really good point. As I think back in the day when applications went through tonnes of cycles. And from code complete to production could have been six months or a year. I think developers actually did take a bit less responsibility for things like, how do you configure this application in production? How do you scale it in production? How do you promote it between environments? I think that's all front and center now. When the lines between application and infrastructure is virtually invisible in these modern apps.

Jeff DeVerter  10:05
Such an incredible thing. And all of this, of course, plays into how these teams now have to reformulate. How do you build the right team? And then how do you build the interaction around other teams that exist? So let's dig in a little bit, in a DevOps world what does a team look like? Well, wait a minute, before we even say that we haven't defined what DevOps is. Let's talk about DevOps. Let's make sure that Tolga gets to draw a line in the sand of what DevOps mean. And it's not the buzzword of what we think it means.

Tolga Tarhan  10:31
Oh, you heard it here, folks. I'm defining it officially, on behalf of everybody.

Jeff DeVerter  10:34
You're defining it for the next 20 minutes in our conversation.

Tolga Tarhan  10:38
All right, I'll take it. So, here's what it's not. It is not a title. It's not a job title. If your job title is DevOps, it's actually a pretty good indicator that your company has not adopted DevOps. Because it's not someone's job. I think this is more obvious today. If I gave some one the title scrum engineer for a software engineer, you'd be like, "That doesn't make sense. What does that mean?" It's the same thing when you call someone DevOps engineer. Now, what is it? I think it is a series of process changes that apply the agile techniques that we've learned in software development to the rest of the life cycle. So I think, most people don't understand agile software development. I think it's very rare outside of spaceships. And even then I think, SpaceX might be using agile methodologies. But outside of those very, very controlled environments, no one's really doing a waterfall dev approach anymore. Everyone is caught on to the benefits of agile. So this is about bringing those same disciplines to infrastructure, configuration, updates, scaling, but not in an isolated way, when you're done. The agile processes have your dev team and the DevOps processes for your operations. They come together into one thing, like at the end, you shouldn't be able to say the boundary between the two.

Jeff DeVerter  11:59
Got it okay. That makes sense. So then when we start thinking about building a team. And think about the team in the organization, not just here's my group of developers. But what do we have? What kind of personalities do we have to pull in for it to really function? As opposed to the example you gave earlier, where your dev guys were all handling and doing things in an agile fashion, but the rest of the work wasn't. What has to happen?

Tolga Tarhan  12:23
That's right. So you need to go end-to-end. So, let's assume that the dev team has done the front end of this. So, your requirement and UX, and developers are all part of the agile team and your testers too. So now what we're going to do is, we're going to add in people with operations expertise. So somebody whose job typically might have been to configure that application in production or to scale it, or to back it up, or to promote it between environments. Infrastructure engineers, it might be database folks, might be network folks, might be security folks. And what we're going to do is add those disciplines into the two pizza team. So your two pizza team, that was your dev and test, and requirements and UX folks, they now have people who are experts in infrastructure. And those folks are doing two things, three things maybe. They're adding non functional requirements that everybody needs to then go and implement, about how the app might behave, and scale, and how it might be ephemeral and immutable. That always requires some external config that you may not have built into the app on day one. And so they're subject matter experts and how that's going to look and work. Number two, they might actually and should actually write the code for those parts of the application. They're not just sys admins that only know how to work through the UI. But rather, they're going to actually do infrastructure focused, operational focused code, that's going to become part of the code base. That might be a terra, it might be as simple as some terraform. Or it might actually be in the application code to read extra configs.

Jeff DeVerter  13:51
So I was going to ask you. This is an infrastructure person who's listening to this, and we have a lot of lead IT decision makers who are listening to this. But we have a sysadmin who's freaking out, going, "I gotta be a dev now. What's that all about?"

Tolga Tarhan  14:04
I think you do. I think that you do. Now look, it's one thing to sit, to be deep inside the application and to spend your days, headphones on writing code, that's a software engineers job. An infrastructure engineer, an engineer, who's an infrastructure person on a dev team. They're still spending a lot of their time watching how these things operate, collecting metrics, looking for ways to improve, making sure that all the automation is working, and that backups are there and the application is healthy. But why not take those great ideas you have when you think to yourself, "Man, if the dev team would just expose this new monitoring endpoint, I could do a better job running the app." Why not get to a point where you can start to build some of that yourself.

Jeff DeVerter  14:45
 Right, right.

Tolga Tarhan  14:46
You're part of the broader dev team. So, you have the support of the architects and engineers there. You don't have to carry it on your own back. But I think, if you don't draw a boundary that says, "Look, I don't touch the code." It's healthy for you to touch the code.

Jeff DeVerter  15:00
Yeah, it is. Alright. So we're adding security into this, we got the sys admin folks who are going to be part of it. Who else needs to be part of this team?

Tolga Tarhan  15:09
Oh boy. 

Jeff DeVerter  15:09
And making sure that we still have enough food to feed them with only two pizzas available. 

Tolga Tarhan  15:13
That's right. And you know what you bring up a good point. So you're not going to be able to put every discipline, every sub-discipline, every piece of expertise on the team. Because you'd have 30 people, before you had a single actual core developer on the project. That that's not going to scale. It's gonna look like an NFL team with all their all their kind of special teams. What to do instead? Is still have Centers of Excellence, or whatever you want to call them, for these disciplines, for infrastructure, for reliability, for security. But you want to have representatives from those on these dev teams. And they can still reach back to their colleagues, to the deep expertise that exists in the org. You don't need to be an island. And so as a result, I actually think most dev teams should have just a couple of folks. One or two focused on infrastructure and then depending on the app one focused on security. May even be a shared resource across a couple of teams. But the important thing is that these resources feel and act like they're part of the dev team. They're not a check and balance on the dev team. They're not an approver on the dev team, they literally are just part of the dev team. They get all the ceremonies, they have as much ownership over the outcome as the rest of the dev team does.

Jeff DeVerter  16:26
Okay. So it makes me think, if we build one of these teams. These two pizza teams. And they've got all, either all the direct people they need on that team, or access to the guiding people who are inside the organization, the deep thinkers in those specific disciplines. How, with having all that there, it's obvious that is what is going to certainly help the development lifecycle happen faster with speed. But think about that, in in the context of a non technical team, does this methodology apply?

Tolga Tarhan  16:57
So that's what's really cool about this agile stuff is we pretend it was invented for software development. But the root of much of this is kanban, which was actually developed at Toyota for manufacturing. So, they wanted to gate the number of items that could be in each state. And they developed this kanban methodology around it. And, I think you can trace back lots of today's agile processes to that starting point. And so not only can you use it for non dev teams, non technology teams, I think it started there. And I think it's an effective way to manage responsibility. So the big change, that you have to embrace is rather than having people with functional jobs, each doing their little part of a bigger project. You actually take those people and put them onto one project together.

Jeff DeVerter  17:46
Mmm. 

Tolga Tarhan  17:47
So you represent the cross functional elements inside the project where their primary home is a shared outcome. Whatever that shared outcome is. Even if they've got teams behind them that are functional,

Jeff DeVerter  18:01
Isn't that, I mean it's really disruptive to the way we're used to business happening. And obviously, the IT world has adopted this in a pretty significant way. We've easy ways to identify when companies are doing it right. And when they're not. But you called it out right there, Tolga. And you said, they're being driven by the output of their functional team that they've been put on. As opposed to, "What time did I sit in my seat today, was I seen in the right places today? Did I fulfill the quarterly thing that I was supposed to get done for my review?" But being driven by specific output. So, my question or my thought here is, has COVID had a significant impact in accelerating this, as I think that it has. Because everyone's sitting at home doing their job being measured by what they're delivering, as opposed to necessarily have often were they in their chair?

Tolga Tarhan  18:54
Yeah, I think there's probably a couple things at play here. One, you're right, the metrics we typically use have been up-ended. And the other big reason it's changed in COVID times is actually because collaborating with other teams has gotten easier. And, I had a conversation the other day that said, some types of collaboration have gotten much harder. For example, deeply technical whiteboarding sessions are very hard to do over Zoom. There's just not a replacement for a whiteboard and a marker and a room and a pizza. So that's gotten harder. But simpler collaboration have gotten a lot easier because nobody has an in-person meeting. So you're never the one guy on the phone. Think about how awkward it was, if you're working with a team in a different geography and you're the one guy on the phone, it never worked well. So I think what we're seeing now is, easier collaboration leading to it being easier for functional roles, to actually behave as part of a project team and to focus in on what that project team is doing. But at the same time, I think we're seeing some innovative capability last due to the lack of like sort of high bandwidth in-person communication

Jeff DeVerter  20:05
100%. So, interesting point that you make around some pieces of collaboration being so much more difficult to do. I heard another example where you had some some devs who where working on a robotic application, and they really just all needed to be around the one device that was having the problem so that they could solve that problem together. But while there are the niche areas, I'll call them niche areas, I think there are less of those than there are the massive increases in our smaller aspects of collaboration. And like you, I'm particularly excited to hopefully see a major change in behavior. Once we start to go back to an office with whatever that looks like. That will take those folks who aren't in the room a little more seriously or a little more cautiously.

Tolga Tarhan  20:48
Well, and the big disruption that we're all waiting for, that I think someone needs to do is, is merging that physical world collaboration environment with the virtual one. So, I feel like as early as the late 90s, there were these virtual whiteboard type things that could do these big expensive projectors that act like a whiteboard. And none of it has really gotten to where it needs to be, but it's ripe for disruption.

Jeff DeVerter  21:12
Yeah, I saw a really interesting demo that Microsoft did about a year ago, which was all built on their Team's environment. But with a 360 degree camera and HoloLens, you basically had a virtual conference room were everybody was sitting around a conference table. And to the point a little even farther, is that you had to log into that with your devices. And so then you even had a transcript of everything that happened from each individual, and was capturing action items and all the notes and all the things. 

Tolga Tarhan  21:44
It sounds like sci fi. Because probably it works well today in a controlled demo. When that becomes a mainstay, when that becomes something that anybody can use, including non technical executives, I think that's when we'll see the biggest change in collaboration.

Jeff DeVerter  21:59
I totally agree. And it's gonna require some more hardware. But this this whole COVID thing has been such a forcing function. All right, so so agile is a good thing enabled by DevOps capabilities. And that is a mindset. And as a goal, when can you tell when somebody is not necessarily doing it right? Where do you? What words do you hear? What behaviors do you notice?

Tolga Tarhan  22:23
It's interesting. But circling back to the technical domain, one of my trigger words, when I'm talking to a customer about a migration is when they say, "Well, how we're going to do patching?". Let's step back, because if we've talked about all these immutable processes, all these ephemeral instances, what we should have understood by now is that we're going to build automation. And the automation is going to deploy software. And we're hopefully never going to touch the deployed software. So we didn't talk about this earlier in the definition of DevOps. And it's probably not strictly part of the definition. But I do think good DevOps often is ephemeral and immutable infrastructure. Yeah, as a result, it's never patched, it's simply replaced. So that's one of my big trigger words. The other one is when you talk about approval processes. So there should be approval processes for applications that are critical, that are sensitive data. But those approval processes need to be built around and compatible with these DevOps ones. Not, "Hey, the cab meets every third Wednesday, and we authorize deployments every third Friday." Those kinds of models again. They break the sort of move fast, deliver features faster, they break those models. And by no means am I saying, we don't want to be careful and calculated and have people reviewing, I think that's very important. But I think we can start to bring those review processes and approvals closer to our code actually. Because all of our infrastructure is represented as code. Then I don't need to review a document that has the deployment plan and a document with a rollback plan. I can just actually review the proposed changes to the code to the infrastructure automation code.

Jeff DeVerter  24:07
Perfect. So you've been messing around in this whole cloud native, DevOpsy, agile world for just a couple of weeks now? No a little longer than that, a little longer than that. So here, if you were with Onica, you came to Rackspace. We're very thankful for that. But tell us about some of the stuff you're doing before that. Because what I also want you to put in the back of your brain, don't answer the question yet, is the folks listening, probably not everyone has started down this road yet. And how did they take some of those first steps? But let's start by understanding a little bit about your pedigree and and why you are okay to give these examples.

Tolga Tarhan  24:45
What qualifies me? So, by trade, I'm a software engineer. But starting in 2009, I went into the business of software engineering consulting. Started a small company with a partner. We focused on building products. And we did it with these modern approaches. So we were agile, we used all the modern ways to build user interfaces and to design user experiences, and then to reduce that to actual software. We actually did it with onshore developers. Which in the year 2009, was actually novel, right at the height of the offshoring model then. And so we helped a bunch of customers actually transform to think more agile as we did product dev together with them. Those are big Fortune 500 that at least the teams we were working with, the parts of the business we were working with, were transforming. Now, I'm proud to look back. The year 2020, 11 years later, I think everyone has gotten there. I think everyone has got that agility. But my background has been building services businesses since 2009. Then Onica came next. And then Rackspace is where I am now. 

Jeff DeVerter  24:47
Exactly. Excellent. So maybe not everybody is there yet? And especially with some of the customers that I've talked to. I can tell you that not everybody is there yet. How does somebody start down this road? Aside from reading a blog, or listening to this podcast?

Tolga Tarhan  26:17
It kind of reminds me of my past. I remember in 2005, trying to trying to manage projects, leading dev teams. Kind of half agile, probably actually the wagile thing I accused others of, probably doing that. You'd study online, you'd read blogs, you'd read books. And it feels like nothing would really give you the whole picture. It was all very theoretical. It was all like, when everything goes perfectly here's how you do it. But that first step was really hard. I think what I learned is, that making it overly academic actually is going to be what gets in your way. Forget what perfect looks like, forget what good looks like for a second. Start with what works for your team. The whole point of agile is to be flexible. So I'll give you a couple things you should definitely do. And then you should figure the rest out, when what's right for your team. No one can tell you the formula because everyone is doing this slightly differently. But here are a couple tenants, kind of agile and therefore for DevOps. Your iterations, sprints, whatever you want to call them, need to be a fixed duration. They need to be immovable. Because the whole point is to force things into the time box, and to start to learn what fits in the time box and what doesn't. So one of the very first mistakes people make is they extend the time box because they're running late. Don't do that. That's like the first tenant. The second tenant is that your whole team needs to attend all the ceremonies. You need to have the daily stand ups, you need to have this the backlog grooming and the sprint reviews. And everybody needs to be present and participating in those meetings. It's not something that like two guys go off and do, because the rest of the team isn't bought in to what's being done. And then I think you need a consistent way to measure throughput. So story points, t shirt sizes, dog breeds, doesn't matter what you use, but you need a way to size up the work in the backlog. And you need to not modify how you estimate. So what I mean is, when you start your estimates will be way wrong, it's okay. What you should probably not do is try to rechange how you estimate. Just humans are creatures of habit, you will always be wrong. What's better instead is to actually let it self correct. So if you start off thinking that a large story. Let's say, just use t shirt sizes here. A large story is going to be two days of work, if that's where you start. But you find out after four sprints that those large stories take four days of work. Great, keep estimating those as large stories. Just now you know, those take four days of work. And you'll take fewer stories in your backlog and that's self correction is what gets you to a predictable velocity. So those are starters guide I think to this stuff.

Jeff DeVerter  28:59
Alright, so if we draw it back around as we think about not just software Dev, but cloud transformation, helping a customer transform their organization by utilizing the technologies available to us from the hyperscale clouds. So if a company back in 2009 starts to get this right, they start to get the agile development methodology right. How much does the cloud actually accelerate that? Because now we're not waiting for UPS shipments or FedEx shipments of servers. But we're now able to get, we have the world of technology literally at the ends of your fingers.

Tolga Tarhan  29:34
Yeah, that's actually a really good point. So the reason software agile development took place in the early 2000s, or could take place. It didn't need very much hardware, most developments done locally on local machines. You couldn't go, it was harder to go to DevOps until we had the ability to spin up new resources and shut them down and change them at a whim, without sending someone to the data center, without ordering hardware. So the cloud is the enabling tech here. Because I can just say, this instance will exist. And this is what it'll look like, it'll be this size snd this much memory or this API gateway endpoint will route to this serverless function. I can just declare those to be true, deploy my declaration, and it will be true. So that ability to do that, is what lets infrastructure engineers operate like software engineers, they can just type it in their text editor. And simply typing it makes it true. Versus in the past, where you may have typed the plan. But someone had to go to the data center, and rack and stack the stuff, it was a very different model.

Jeff DeVerter  30:41
And isn't it interesting that in our 30 minute conversation, we talked about the cloud for about a minute and a half. And that's all really that technology plays into a true agile transformation. Granted, there's tools, granted there's editors, granted there's other things. But it's people and process. And that's the most difficult piece of making this change. If you can cross that chasm, then technology becomes plug and play.

Tolga Tarhan  31:07
The technology is an enabler, it's more tools in the toolkit. Now, I believe these are extraordinary tools, that will change the future of technology. But if you don't apply them right, like if you can take the back of a screwdriver and use like a hammer, it won't work real well but you can do it. So we need to use the tools the way they were designed. And I would argue they were mostly designed to be used with automation. They were designed to be used immutably with ephemeral environments. And they were used, they're designed for this agile DevOps methodology. If you don't adopt those on the way to the cloud, you actually don't get to leverage the full power, the full innovative capability of the cloud.

Jeff DeVerter  31:49
I can think of no better way to send this recording out than ending on that last quote. Incredible. So we live in extraordinary times. And I don't mean to belittle the amount of power that exists at the end of your fingertips. And I mentioned, I said, "Hey, we only talked about technology for a minute and a half." Well, we could talk about a rocket ship for a minute now that's still a whole lot of technology. But the point is, you can really misuse that technology, if you don't use it, like you said, in a way that it was intended to be used. Tolga, thanks so much for being on the program today. Any last words as you kick people out into this agile world?

Tolga Tarhan  32:25
I think my biggest takeaway would be, don't be afraid of this change. This change when you're done with it, will make your life better. And I hope everyone takes takes the chance to go and adopt agile and DevOps, and adopt the cloud on this more modern way. 

Jeff DeVerter  32:40
Awesome. Tolga thanks so much. Everyone. Thank you for listening today. We sincerely appreciate it. And have a great day.

Closing  32:50
This has been Cloud Talk. You can find Cloud Talk wherever you find your favorite podcasts. And be sure to check out more content from Rackspace Solve at Solve dot Rackspace dot com.

Jeff DeVerter  33:08
So if your title is DevOps, chances are you aren't doing DevOps by right, the cloud is capable of so much more than we ask of it. The challenges of the cloud really don't have much to do with the tech at all, but how we, as humans, rally around it. But isn't that the point of this podcast, providing access to great thinkers like Tolga who lived the cloud life and lived to tell the tale. Now if you haven't already done this, perhaps you would consider subscribing to this podcast on your device. You see, we turn one of these out every week. And that way, if you subscribe you'll have the latest episode ready to go whenever you need it. So should we ever have the opportunity to sit in traffic as we commute to an office again, you'll be ready to go. Speaking of our latest episodes, here's what we have in store for you next week.

Dirk Elmendorf  33:59
Teams allow you to get a company or an organization or an opportunity. And then you can be going you can be great in all these aspects. Because you're not relying on one person to be great in all these aspects. I think that, that sometimes we like in the tech world. We like to celebrate the lone genius, but I'm just going to tell you right now, Steve Jobs, Elan Musk, Jeff Bezos, they didn't do it by themselves. They're just the convenient faces Founders to focus on.

Jeff DeVerter  34:25
That's next time on Cloud Talk.








- 1 -
00Transcribed by https://otter.ai