The industry is becoming more receptive to cloud approaches and all indicators say more and more people are going down this path. But, where do you start in the world of cloud computing? Let's get into it.
The industry is becoming more receptive to cloud approaches and all indicators say more and more people are going down this path. But, where do you start in the world of cloud computing? Let's get into it.
Joel Parks 0:10
Hello and welcome to Cloud Unplugged, the podcast where we take a lighthearted and honest look at the who, what, when, where, why, how and omgs of Cloud computing.
Welcome to Episode One. In today's episode, we're going to take a look at some of the recent Cloud news. And then we're going to dive right into the the topic at hand, which is how you get started in the world of cloud computing. Again, my name is Joel Parks and with me is Jon Shanks.
Jon Shanks 0:36
Hello, Jon Shanks here. Hi.
Joel Parks 0:38
So, how's your week been so far, Jon?
Jon Shanks 0:41
It's been pretty busy! I just want to also apologise for all of the made up words. So, if you do want to use some new words like 'philosophicalise' feel free. The words are out there now in the ether, we might be bringing out a dictionary soon of our own. So, yeah.
Joel Parks 0:59
Has this been bothering you for a week?
Jon Shanks 1:01
It literally has been bothering me for a week, yeah!
Joel Parks 1:05
Okay, so anyway, send your your notes and comments to Jon at ... So yeah, my week has been pretty good. It's been quite busy. And, you know, we're getting to the end of the fiscal quarter here, which is always a bit of an interesting time. You know, there's an uptick in activity and a lot of things going on, not just with us, but in the industry in general. So, the first segment on today's episode is 'It's news time'.
We've got three articles this week, or three things to talk about. The first one that caught my eye is in reference to Google Cloud. Google Cloud had their their earnings call, and it looks like they finally broke through the 4 billion mark in in revenue. Now that's pretty good for them because about a year ago, they really redoubled their efforts to try and get some additional market share and traction because they've been the third player in the market behind AWS and Microsoft for a long time.
It's positive to hear that there's some signs of growth and and life out of Google. The article was, however, quick to point out they're still operating at a loss. Jon, I know that you saw this article this morning? Because it went through our Slack at work. What's, what's your take on what Google's up to?
Jon Shanks 2:38
I mean, I like the way you caveated saying, 'that's good for them'. Because they have been kinda struggling.
I think well, by way of comparison, exactly.
Joel Parks 2:50
Their revenue broke through the 4 billion mark. If you rewind exactly one year, back to the same time, their revenue was sitting around 2.8 billion. So that amount of growth in one year's time especially given all the, let's say, less than ideal stuff that happened last year, is actually great. But yeah, I meannnn, they're still sitting in third place.
Jon Shanks 3:17
They are, yeah. Which is a shame because they're a great cloud, and they've got good products. I think they're not quite as good at listening to their customers, maybe as Azure and Amazon, a little bit. But maybe they are starting to manoeuvre in that space a bit better.
Joel Parks 3:36
Yeah, I think so. I mean, they definitely have invested a lot in their go-to-market effort. And the article is also quick to point out that, you know, at least a healthy portion of that revenue bump is coming from Workspaces. So what was formerly G-Suite, formerly Google Docs. Things change names so many times, like, I can't remember. But anyway, positive signs out of Google.
Moving on to the second article, which is for sure related: Microsoft also posted their earnings. So where Google saw an uptick of about 46% in their revenue, Microsoft is posting a little over 50%. So what's fascinating here is, and obviously they're approaching it in a slightly different way. But clearly the industry, it appears, is just in a generalised uptick. So it's good for Microsoft, it's good for Google, I'm sure it's very good for AWS. But it kind of makes you wonder how much of this is provider specific? And how much of this is the industry just growing up?
Jon Shanks 4:47
It's a tricky one. So with Google, just just a quick one on that. Did Google reclassify their other product sells under now the cloud umbrella and that's what's caused it to increase? Or is this like a wangling of what was falling into what bucket of cloud and suddenly it's like, 'oh, we've recategorised it, we've now got to this amount' Or?
Joel Parks 5:09
So I don't have enough information to say for certain. What they do say is this is only the second quarter that Alphabet has called out GCP revenue, specifically, on the earnings call. So they are breaking that out individually now. So it clearly, I think that probably is, on their part a way to attempt to be more transparent and have the the numbers be more meaningful. So I don't know exactly what what the situation is. But you know, clearly Microsoft is doing well, Google's doing well. Amazon, we know has been really blowing the lid off of things, you know, both in a the AWS space, and also the retail space, which just grew, you know, huge last year. Yeah, AWS is going to be unveiling their new data migration product called 'AWS Sho-vac'. So it'll allow you to quickly vacuum up ... this is totally made up, but you wondered for a second, if shopvac was a real AWS product.
Jon Shanks 6:13
I was just about to go buy it, actually. I was just on the website now as you were talking.
Joel Parks 6:20
I just I can't resist taking a bit of a dig at AWS for their obtuse product names. But even more than that ... so we talked about Google, we talked about Microsoft. And now there's another interesting report that came out about the same time from Gartner. I'll just read, 'global end user spending on public cloud services is forecast to grow to 332 billion in 2021 at a yearly growth of 23%', according to Gartner.
It goes on to say that the COVID situation has really accelerated or really melted a lot of resistance in traditional IT organisations to the cloud. And that a lot of the generalised industry growth is is coming from that necessity to drive virtual desktops, all the things that companies found out when everything went into lockdown that they were rather ill prepared for.
Jon Shanks 7:14
I mean, that makes a lot of sense, really, and given given the conditions, that a lot of businesses have been surrounded by, that move to the cloud was kind of inevitable. It was either that or potentially kind of have severe business risk, wasn't it? So it's like, move fast or move away really, I suppose.
Joel Parks 7:33
Yeah, and I observed that with a bunch of different organisations that I have either professional association with, or simply just friends that work there. There were many organisations that were simply caught off guard with how impactful having to distribute their workforce was going to be. And now all of the things that we've been saying for many years about cloud allowing a lot of flexibility suddenly made a lot of sense. So, we now have an industry that's really primed and ready to accept cloud technologies. And I brought these these articles up specifically to talk them through, I thought they were interesting. But also, I felt like the last bit, really teed us up quite nicely for the subject we were going to discuss today, which is 'getting started'.
So as the industry in general is sort of becoming more receptive to cloud-native ways of working and cloud approaches, more and more organisations, it looks like by all indicators are going to be going down this path. So Jon, do you would you like to set up really the beginning here?
Jon Shanks 8:47
Yeah as we kind of were speaking in, in the previous podcast, we're here to kind of discuss these sometimes quite contentious subjects and difficult subjects as well. Even though people are going to the cloud, which is obviously true, I think there's still this kind of hybrid / multi, whatever you want to kind of call it nowadays. Because so many terms, that kind of roughly mean very similar things. But I think there is still this kind of reality of them being in the data centre and their application still being there, even though things might have moved to the cloud. It doesn't mean that everything's gone there or that they their old applications or old integration stuffs not still there.
Joel Parks 9:30
But Jon, Cloud is just another data centre, right?
Jon Shanks 9:33
It literally is just another data centre. So I think we're done with this topic now, that's it. Thanks for listening, guys, that's the end of the episode! Yeah, no, I mean it's difficult, isn't it? That's what we need to talk about. And people approaching it like Joel's saying, like it is just a data centre, I think is usually the bit of the faux-pas that goes on when people start beginning.
Joel Parks 9:55
Let's tease that apart a little bit. Because when we talk about, you know, we can we can sort of blanketly say that, you know, 'cloud is not just another data centre', right? But let's unpack that a bit. Because I think, especially if people are at the front of the conversation, they may not see exactly what it is we're on about. So I'll throw a first example and then we can sort of go from there.
One way in which cloud is not just another privately run data centre is that it is built, all of the services within the cloud providers are built to be programmable, and programmatically controlled. So if you think about that in context to, we're just going to pick on one thing here for a second: how you do network configurations and exposures in your private data centre. Chances are, you're still relying on lots of configurations to be applied to a series of devices in a chain in order to affect that service exposure, or that change in network topology. And it's usually being done by humans, like the system itself is not holistically programmable. You can't say, give me a path from A to B. And it magically appears. In some cases that might be true, but not generally speaking. In the cloud, that is an assumption. There is a baseline assumption that every resource that you can request, or will be utilised, is available through a programmatic interface for both requesting the resource in the first place and configuring it. So in that sense, there is a big difference in the way of working with cloud resources versus private data centre.
Jon Shanks 11:37
Definitely, and just an aggregation of many services. So rather than been the traditional representation of silos of skills, it's now an amalgamation of pretty much, you know, everything all under one roof so to speak. All the services are there to be consumed from networking to storage to, API gateway. So everything's kind of already at your fingertips ready to go.
Joel Parks 12:04
to be fair, I'm not picking on network teams, it was just the first thing that came to mind.
Jon Shanks 12:08
Stop picking on network teams, Joel!
Joel Parks 12:09
I know, I know. They, they they know what they've done. But that's one example. And another big difference in the way of working is, if you're used to being in a privately controlled data centre, there's always the opportunity for there to be exceptions to the rule, exceptions to the process, exceptions to the service configurations. You simply submit a ticket, you spin up a meeting, you go sit down in the room with everybody who controls the relevant technologies, and now you have an exception to the way of working for that particular piece of technology. AWS, Microsoft, Google. No! The services are defined, they have very specific SLAs, service limits, functionality limits, and in most cases, they're not going to alter that functionality for the customers, because it's meant to be a ubiquitous commodity service rather than something that is very, very specific. Now, it's not to say that there isn't a lot of configurability available.
Jon Shanks 13:13
That's going in the dictionary.
Joel Parks 13:16
Yeah, probably so. But you're not going to raise a ticket with Amazon to go change the way S3 works. Or EC2. And that is another big difference in thinking and approaching the way that organisations consume technology.
Jon Shanks 13:34
Yeah, I think this is important, really. Jokes aside, I think, when people are are approaching cloud in this way, and you coming from a traditional data centre of split roles and responsibilities to this amalgamated place, which is kind of some homogenization of all services really, it is a challenge. Because obviously, you've got to now think about, like, who leads on this thing? Who leads on an abstracted infrastructure-as-code principled and designed, like a new new world data centre, I suppose if you're thinking about it from where you're coming from. And that's always the biggest issue, because you might not already have the skills in your business who already understand cloud really well. And yet you're going to embark on a journey thinking, 'well, let's assign, you know, Joe and Pete'. I don't know if they are called Joe and Pete, but you know ... and Sara.
Joel Parks 14:38
That's the network team.
Jon Shanks 14:39
Exactly. So now go look at Cloud and how we're going to transition into it and what's the risk and let's put a security person on this as well to go and assess everything and, you know, a lot of companies start with with that in mind because you're measuring the risk of change. That's usually how a business is looking at it. So they want to put resources on it to try and map out what's this journey going to look like? What is the risk of change? What does it mean to me? However, there's now a learning uphill, sorry, an uphill learning path that they've got to take. Because it's all new to them too, fundamentally. So they're kind of learning it and trying to understand it and trying to represent the risk at the same time. And haven't maybe felt the change of behaviour or how now teams work, which would be very new. Like the new ways of working with it maybe hasn't been felt and learned by them. So they've got no, they don't know what good looks like, necessarily, because they haven't been in a place where they've felt it and learnt it. So it is a challenge.
Joel Parks 15:39
Yeah. And it's, it doesn't necessarily stay constrained to the technology space within the organisation, because one big change in cloud adoption that generally takes place is the shift from, you know, really Cap-ex focused purchasing processes, schedules and procurement to more of an Op-ex focus, which is more of the the pay-by-the-drink cloud approach to to operating. And, you know, typically, the the evaluation can begin purely on a technical level of, can the resources be be combined to support our technical or business use case? Okay, great. Now, what does that look like from a finance perspective? And what does that mean for us, especially if your organisation is eba. You may be particularly at least without some, some reengineering of the books, you may be particularly allergic to, high amounts of Op-ex. So it's, it's definitely a conversation that's going to have to be injected in the the overall big picture of learning new ways of working together. And it is an organisational experience of learning new ways of working together.
Jon Shanks 16:55
Yeah, absolutely. And people are used to being able to predict and estimate the cost within the year, because that's what the CFO be asking for. Hey, here's a budget, go and forecast now for the year. Well, how do you forecast something you've never done? In a cloud that's variable? Like, however much you consume is what you're going to spend. How now am I supposed to give you numbers? What my numbers gonna be based on? You could try and make sense of the cloud costs but they're not exactly the easiest thing to try and go and predict. And who even knows what your old estate now looks like in the cloud before you've even done it. So, it's a really difficult ask to suddenly forecast a known state in advance for budgets. And I think, already, that's a challenge for a lot of people because most people will be like, 'oh, well, you know, we'll go to the cloud. Maybe we've got some free credits, too.' So it's like, well, I've got free credits too so, I don't know? It's free, so I'll just put zero pounds.'
Joel Parks 17:51
Spend all that Monopoly money. Every last bit of it.
Jon Shanks 17:55
Cloud is, great, because it's free. So this is how is it how it kind of starts. And I think you're in danger if you try and make sense of it too much, as well, because then you're boiling the ocean, and then you get the inertia and then nothing ever happens because you're trying to plan too much. And I think, you know, how you approach it, like you're saying in terms of the behaviours and an iterative process to it to help you get to that place to forecast I think is the key thing.
Joel Parks 18:23
Yeah, and I think you hit on the exact right thing, is as we're sort of trying to take a look at the big picture concerns, the conversations, the things that are likely to sort of maybe get a little irritated in an organisation when cloud is first injected into the conversation. When you're trying to create that starting point and identify, you know, what is the point of origin? What are we going to scope so that we can give ourselves not an infinite problem to solve, but something that is manageable, but something that allows us to learn these new ways of working and prove the value of cloud. Identifying that starting point in a building the, boiling the ocean is really the, the main symptom to be aware of and try and avoid. You're not gonna solve every problem up front.
Jon Shanks 19:13
Which is why I'm gonna be a bit controversial here. And I'm gonna say it, Joel. I know you don't want to say it, but I'm gonna say it.
Joel Parks 19:21
Jon Shanks 19:21
Exactly. This is why Shadow IT sometimes isn't necessarily a bad thing. Now, it's a bad thing when people feel they don't have any control, or they don't understand how it's aligning to the rest of the business. And some people are excluded. So obviously, from an organisational perspective, it's a bad thing. But from a delivery perspective, because it's highly focused on a very ring fenced thing, down to delivering a project or a programme or something. That's usually why they managed to get to cloud successfully quite quickly, because they don't need to boil the ocean.
I mean, obviously, there will be things that might be missed. And there might be some concerns around the data and the security and whether it's aligning. So there's always those things that kind of go on. But in terms of proving the value, like, can you prove getting to the cloud? Well, yes, lots of companies do secretly prove getting to the cloud inside of organisations. And that's kind of what Shadow IT ends up doing.
Joel Parks 20:13
Yeah, 100%. And the, it sort of boils down to a difference in perspective. But the way that I've attempted to explain this to people over the years is, you can either look at it as shadow IT IS THIS shadowy, dark nebulous force, that's, you know, sort of CO opting your, your processes, or you can look at it as Oh, clearly, I've already identified the early adopter team. And if I want guinea pigs, that will be enthusiastic to go figure out the new ways of working and be collaborative. Will they're right there. We know who they are. Yeah, right. So it's a carrot and stick issue of how do you use them to go figure all these out and to be the change champions within the organisation, while at the same time figuring out okay, we don't want to recreate legacy in another form in the cloud, that would be counterproductive, you know, sort of going back to the it's not just another data centre thing. But at the same time, there does need to be some effort and some experience put into exampling, these new ways of doing things, trying things out finding out for the organisation, what specific technologies in the cloud, of which there are many, many, many are going to work best for your use cases and for how you build applications and how you operate.
Jon Shanks 21:39
Yeah, that's so true. I mean, if if there is Shadow IT out there in the business, you know, whether there is risk to that, I mean, people fear the unknown. So, when you're coming from Central IT maybe or you're coming from a place of an uninformed, unknown entity, your first thing is to kind of fear it, or there's going to be some cynicism towards it, you know, there's risk aversion to it all, because you don't understand it. So therefore, it feels inherently more risky. And you have a bunch of questions around it all that you've tried to make sense of, but if you look at it from the other lenses, what you're saying it's like, well, somebody is in the team's gone off and managed to do something. And actually, arguably, maybe that 'something' brought business value. Maybe you managed to ship your product faster, maybe that generated some revenue quite quickly. So you have to look at it from the business perspective, too.
Joel Parks 22:31
Yeah, I think there is probably the right time for storytime.
Jon Shanks 22:37
Joel Parks 22:39
So, time for storytime. I won't name exactly who this is, because I want to maintain some confidences, but there's a large retail organisation in the US. They are a specialty retailer, I would say most folks in the US would know who they are if I said the name. They had a very rigid data centre environment, very rigid processes, pretty much exactly what you would expect to see in an organisation that's been around since the late 80s, early 90s. Right? So they had lots of things that they had accumulated over time. And that's not just technology, that's also processes, ways of thinking and ways of working.
One team that was responsible for the public facing sort of shopping and the website, found that it was too restrictive. They weren't able to really do what they wanted to do, from an experimental point of view. There were things that they wanted to try that it simply just took too long to get resources to run an effective experiment. So what did they do? They went to the cloud. So somebody swiped their credit card, and they got a Cloud account, right? And they experimented around, and what they ended up doing was building a recommendation engine. And the recommendation engine was actually so effective, that the experiment was indicating that it would be a non-trivial impact to their retail sales, if it were implemented. So, what started as a Shadow IT project had a tangible impact on their bottom line. They're publicly traded, and their stock price benefited directly from this experiment from being able to drive revenue and sales in a different way. So, you know, you gotta put this in context of, sometimes these days, you know, I think we all kind of can smell the difference between this isn't going anywhere versus like a really, you know, smartly laid out experiment that's focused on creating real business impact.
But if you have teams that are doing that, and they're doing it in a Shadow IT form or you find out that they are, rather than shut it down, I would strongly recommend you go find out what drove them to look for resources that way to begin with. Because typically, that's a reaction to a process that isn't meeting the need. Would you agree with that?
Jon Shanks 25:23
Yeah, absolutely. It's hard, I suppose, to be quite self reflective and be like, am I meeting the needs of the business as a function? It's not an easy thing. And I suppose your natural instinct might be to try and prove why they're wrong.
Joel Parks 25:39
Nobody's got a crystal ball. But at the same time, I have found almost to the person that if you look at large enterprise, you know, sort of technology teams and application developers. I mean, they've, there's some smart people in there right? Unfortunately, some of the very smart things that they're thinking about and would like to experiment with are sort of blocked because of procedural or cultural roadblocks. That really impact their ability to do the smart thing to go have the interesting conversation or the interesting experiment. And one way that they found to unblock their work over time, is say, Okay, well, I'm not going to do this. I'm not gonna spend a tonne of money, but I am going to go over here, I'm gonna have my own account, my own little sandbox so that I can I can run these experiments and check myself.
Jon Shanks 26:31
Yeah. And it's the 'what if' danger, isn't it? You know, if people overanalyze the whole thing, the business Shadow IT objective is to go and solve a problem that they have in a very niche area. But if you get into this, like, what if well, you know, what, if the security wasn't done properly, what if we can't forecast? What if suddenly, this is costing us a million pounds? What if, you know, you get into this stage of what if inertia, which is like all these possibilities that could happen?
Joel Parks 27:00
I was in a meeting with one of the major cloud providers, one of the big three that we've already talked about, and there was a customer in the room, and the customer said, in a very arm-folded way to one of the cloud, like, high up muckety-muck engineer, guys, , 'prove to me that you can run networks better than I can.'
Jon Shanks 27:20
And it was like, oooooh, okay.
Joel Parks 27:27
Yeah, it's like, I don't think I'm going to be betting on you. But you know, it's sort of interesting. That kind of leads to, you know, if you've got Shadow IT going on, it's not necessarily a bad thing, it could be an indicator that there are things that you can learn from those teams that will advance you along your cloud journey. The other thing that I've seen is in that sort of, like, 'prove to me you can run better networks than me' is, the other mode in early exploration is to do a PLC, right? And those those can range from, you know, brilliant to insane, right? The potentially insane ones are more on the arms folded, 'prove that AWS networks work', or prove that GCP compute instances, run somehow.
Believe me, trust me, let me save you the agony and the ecstasy here: The clouds work, they work just fine. That's not a PRC that's going to be profitable for you to run, what would be far more profitable is for you to look at those projects that have been stalled out internally, or have been contextualised over in Shadow IT or have been pushed, let's say outside of the mainstream channels, for one reason or the other and say, let's give this one a fair shake. Let's put it in this context. And let's actually do it out of the shadows in the light in a collaborative way. And let's see if this let's see if this rolls.
Jon Shanks 29:02
So is that something you'd recommend people start with? Like go hunting for the Shadow IT like all get our torches out and start looking in the dark corners?
Joel Parks 29:15
I think in most big companies, there's a general awareness of where the Shadow IT is. I don't think it's really hard to find, right. I think it's sort of an open secret in pretty much every case. You know, the real challenge here with early stage cloud adoption is you do need to prove to the organisation, if for no other reason than to build your own confidence, that you can move and work in this way. Right?
The technology works, it's fine, right? But it's what the people bring to the technology and how they're going to work within those confines that often needs some exploration. Needs some confidence building, needs some practice. And the trick is finding something that is big enough that if you succeed, it has a real tangible business impact that you can quantify it, you can put dollars or pounds on it. Like this was successful, because this is what it did for the business. But not so big that - you maybe don't start with your public facing website. Don't replace the core of your business logic. Find something that's big enough that it has real value that can demonstrate how people are going to work together with the technology. But small enough that if you have a couple of missteps early on, it's not fatal. You can recover.
Jon Shanks 30:47
And maybe not a commercial end date that's surrounding that thing that's kind of time-sensitive. I think we've all we've all come across that befor, it's like, 'hey, we've got this commercial, it's costing us x', you know, let's use that as the mechanism to get out of this commercial contract into the cloud. And then everything's literally time constrained. And people start getting desperate, you know, the quality of what you're doing. It's just like, I don't know, just just ship it, just move it. We need to get off, and that's usually the wrong the path to go down.
Joel Parks 31:21
Yeah that is, sort of an unfortunate side effect of the way that cloud has been adopted at a bunch of big companies is the first experience that everybody has with Cloud is some very hair on fire lift and shift manoeuvre.
Jon Shanks 31:35
Joel Parks 31:35
And that's just not a good example of what really A) cloud was meant to do in the first place. I mean, you can do that, but it's horrifically expensive, it doesn't work particularly well. And it doesn't really buy you much other than you're not in a data centre that you have a key to, right? Apart from that, it's, it's pretty much the same. You know, it's much better if you can do it on a strategic level or on an application by application basis. But I realise that business pressure sometimes don't really afford you that luxury. So if you have to, do it, but just know don't draw any early conclusions about cloud or how it's going to impact your teams based on doing an accelerated, bare minimum lift and shift effort. Would you agree with that?
Jon Shanks 32:26
Yeah, I definitely agree with that. And I think don't put it under the transformational bucket, really, if you're kind of trying to move and then think that you've kind of transformed in the process? Because I think that's a bit of a stretch. But you're you are, right, I mean, sometimes you just don't, you don't have the luxury of choice. The business is asking for this, and you kind of have to do it because it's legitimate requirement. But I think you need to go eyes wide open to say we're adopting the cloud ... But it's caveated. This is a lift and shift, we know there'll be some procedural change, because obviously, it's different. And how we're doing it is going to be different. And the financing is going to be slightly different. So we obviously have to change some of our procedures, but it's not necessarily a full transformational change, or a full business change around it necessarily when you're kind of working in that way.
Joel Parks 33:16
Yeah, absolutely. Imean, as much as possible, I've tried to talk to, I mean, if you're in that situation, you're in it. So you're gonna have to make the best of it. But if you are in that situation, try and temper expectations and let everybody know, okay, this buys us time, really, to then begin the real work of cloud adoption. But we're going to do the cloud adoption once we're already there. So it's going to be, rather than an adoption in a very orderly migration of functionality as things are refactored, we're going to move everything. And then we're going to sort of refactor once we get there. But really, that second piece, the becoming more cloud-native and adapting what you do to take advantage of what the cloud can provide. That's, that's honestly, that's, that's where the money is.
Jon Shanks 34:09
And just to do a bit of a recap. What you've kind of suggested is, choose something to prove out cloud. If you have the luxury to do it right, and there's no fires going on around you that mean you've got a bypass doing the right thing, because you just don't have the luxury of it, then obviously, do it but then go back around it to try and improve it and then try and fix it up to be in line with with the cloud way I guess. But if you do get to do it properly, and you do have a bit more luxury of time to plan this out, find the right thing that's not going to have massive business impact. If for some reason it takes time or maybe doesn't work out in the way that you assumed to kind of have a good set of outcome metrics to define like what good looks like at the end. Like what Is it that you're gonna measure success by? Something that's got a little bit of low risk, as we kind of mentioned a specific department maybe where it's a bit more ring fenced in a certain business unit?
Joel Parks 35:12
Yeah, that's actually a really good approach. If you can make it something that's very specific to a line of business. Or even, if you're divided up this way: A customer. That's really, really good, because then you can start to deal with the complexity. And especially if you're coming from a data centre, or an environment that has been operational for an extensive period of time, there are just going to be things that you're going to uncover about that environment as you start to move components to the cloud and do things in a different way that it'll take you some time to wrestle with the sins of the past, we'll put it that way. So I would completely agree with that. Find something, ultimately that you can contain the complexity that provides you a real outcome that's business meaningful, that allows you to gain even higher levels of support for what you're trying to do.
And then I'm going to say something that is probably going to make everybody cringe. But it's: Involve security early. I know, I know, I know, we've all....
Jon Shanks 36:25
And that's the end of the podcast....
Joel Parks 36:30
We've all had the experience of the security team being effectively the Department of No, right. And every organisation I've ever been been in, has creative, interesting perspectives on how to involve security, but not really involved security, you know, there's sort of interesting workarounds and things, things of that nature, I would suggest that if you want this to have lasting impact, that you find someone within your security organisation, someone within security, architecture, engineering, that is a champion that can join you in this effort and really speak to the security concerns in a practical way. But somebody who isn't so encumbered by the legacy way of working, that they can't see past it. And it may take you some time to identify the right person in that context. But one thing I can absolutely guarantee you is if you do this, undertake all this work, and you don't involve security in what you're doing, you're likely to meet an uncomfortable end.
Jon Shanks 37:37
Yeah. And let's be honest, though, that their intentions are good. And the questions they ask are the right ones. They tend to have a really good way of looking at the security element in relation to the service, and they do ask all the right questions when they're kind of thinking it through. I guess the frustration is more, the educational side, I suppose for people is like trying to educate others, when they've got the answer in their heads, especially from an engineering perspective. You just kind of want to get on with things because it's like, this is a solved problem. You know, cloud does security, that's the thing is the service is there, it's already taken care of. And I suppose there is a frustration from people that might know it really well, that everybody should know it really well. And I suppose that isn't obviously going to be the case if no one's been on the journey. So you are right: start them early, so they can follow the path and ask all the right questions as you're iterating through so it's not some big thesis at the end that you've got to go through, someone's got to unpick everything you've just done to make sense of it.
Joel Parks 38:43
Or at worst, you get to the end of it and have to defend what you've done. Right? It becomes an adversarial relationship, then that's not going to benefit anybody. But if you can get them involved and make them a first class citizen, in the process of getting to cloud, you may find that once they really understand it, and feel very included, that they could become your biggest champions. And let's just be super honest about this, they have the ear of the C-suite, right. The security teams always do. And when they say jump, the organisation will. So if you want to have a powerful ally on your side, in making the case to go to cloud, enlist your security team because they have a very loud voice when it comes to most organisations.
Jon Shanks 39:35
And it's the same with service, too. You're changing the parameters. The parameters are defined, if you think about it, logically, the practices have been defined and maybe defined for some time in the business. They've matured, the ways of working have matured, when people come into the office every day knowing what to expect and then suddenly, they hear about a thing that completely changes their normal processes and ways of working around the side without being informed, it's probably gonna be slightly de-railing. So I think it's the same with service, like, how do they understand the overall service now that the responsibilities have moved and some of these responsibilities are now Amazon's responsibilities and not necessarily a team's responsibility that was paid for by the company and controlled by the company? So you're now into the service needing to be involved, so they can kind of understand what the impact is. And they kind of feel a bit less fearful of what happens when something goes down. And how am I supposed to respond to it? Are we calling Amazon? Which team member do I now instantiate? What's going on? So, I think it's the same, the same thing goes for probably service too - what do you think?
Joel Parks 40:43
Oh, absolutely. 100%. Not only for the the delineation of responsibility that you were talking about in terms of, you know, where does the cloud providers responsibility end? Where does ours begin? How do we navigate that if we do have to request something of the cloud provider? Who's actually doing that? How do we avoid that becoming a hot potato issue, when there actually is a real problem we have to solve? But all the way up to and including release management. Release management can be a real tricky thing to navigate. As an example, let's deal with with ITIL. You know, if you're trying to do very highly automated delivery of applications and software to the cloud, to really take advantage of what it's great at, that doesn't necessarily mean that the underlying deployment and release process has changed. That's probably a conversation, you'll need to engage with them and to say, 'okay, look, we know that these are the, the the general recommendations, the constraints, the structure of ITIL, what are the options for us to be able to deploy or employ very automated mechanisms to do this, without getting ourselves in trouble when it comes audit time?' Because in a very similar sense, to what the security guys are thinking of the the IT Service Management Team, the ones that are taking care of configuration management, asset management, deploy, release all these things, they're really there to support the company through the audit process, in a lot of ways. And if you neglect them, they're being put in a position of having a lot of responsibility, but no way to really ensure that the company passes audit in a clean way. So their concerns are real. I think, you know, as technology nerds, we can sort of like bypass that consideration. Sometimes it's like, ahhh, they're just worrying too much. No, it's real. It's very real. And those processes were put in place for a reason. But that doesn't mean they have to be locked in, in stone or concrete. Right? They can adapt over time, if you engage the teams in the right way.
Jon Shanks 43:05
Yeah, exactly. I think that's the thing is that historically, you know, change has to happen. Change is good. Change isn't bad. Change is the thing that enables a company to move fast and be agile, and to release things quickly. It's how much you have to manage that change. And I suppose, historically, you had to manage change a lot, because there was a lot of people involved on something getting released. Everything's kind of collapsed and condensed into abstractions and APIs, and the roles and responsibility are a bit merged. So I guess the question is, how much do you now need to manage the change? And I think that's the thing people need to kind of question of themselves now. It's like, well, if things have been made easier, we know the reason technology evolves, is it's trying to solve problems. That's the evolution of tech. And so it's always trying to strive for something easier, simpler, better, so you have to recognise that it's probably changed for the better not for the worse. So has that now made my life easier? Do we need to change our process? Can our processes be simplified, actually now? And do we actually get some operational efficiency out of this?
Joel Parks 44:11
Yeah, and I completely agree with you, I think that there's a temptation sometimes for people to look at a framework and see it as not just a set of considerations that should be accounted for within that environment, but a very prescriptive way of working. And I think sometimes ITIL is interpreted through that very prescriptive lens. And that's not necessarily what they were trying to say. It's about, these are the things that you need to have in place in order to understand the state of things, how they evolve, make sure that there's appropriate controls as to when changes are applied, who's applying them. Those are all reasonable things, but to your point, sometimes those aren't people anymore. In fact, in a lot of cases, they aren't people anymore. It's code.
Jon Shanks 44:59
Joel Parks 44:59
So knowing how to move that along. But when we talk about, you know, security operators, IT Service Management these different teams, I think what we're really coming down to is that knowing where to start is one thing and scoping the problem that you are going to be collectively solving is important. But the next step past that once you can sort of maybe even come up with a list of candidates have, these are the things that maybe we want to put forward as the first problems we solve. The next big step is building the team.
Jon Shanks 45:37
Yeah, and also making sure you're all speaking the same language divides engagement, any confusion of like when you can assign these but I totally agreed that once you've chosen, you know, once you know what you're trying to do, and why you're going to do it, once you know what outcome you're striving for with the engagement of cloud, what problem you want to really address. And there has to be a benefit to realise there's no point. So there's got to be some assessment of know why you're going to do this. And whether it's shipping something quicker, whether it's you get a new feature out faster, whether it's the fact that some operational efficiency and everything. You know, maybe some tech that you get to get rid of, or some total cost of ownership cost that you get rid of like whatever, whatever it really is. That's the driving outcome goal that you're kind of striving for. And then you're tracking against that as being like that's the success outcome we're aiming at.
Joel Parks 46:31
Yeah, absolutely. So I think really, that gives us a nice transition point from the discussion that we've had so far to really where we're going in the next step is. We talked a lot about the deep considerations. The questions, people are likely to have, you know, things that you'll have to navigate in order to determine that, that point of origin that starting point. But what we intend to do next time, is to talk about the mechanics of building the team. When we talk about engaging all these other stakeholders, how do you do that? What are the conversations? Or what are some tricks or some tips that we can provide for for enlisting people to your side and helping to build this new cloud-native working team that you're going to need in order to have really sustainable success in the cloud? Would you agree?
Jon Shanks 47:28
Yeah. And I'm kind of really intrigued with the intro episode as well, when we're going to talk about CatOps and FishOps, and DogOps in relation to cloud. I'm really like on the edge of my seat waiting for this.
Joel Parks 47:42
I have lots of sound effects, so do not tempt me sir! *meowwww* So really, I think unless you have an objection, I think that gets us right where we needed to be. Is that about it, Jon?
Jon Shanks 47:55
That's about it. It's been been good fun.
Joel Parks 47:58
Okay, awesome. So thank you so much for tuning in to this week's episode of cloud unplugged as I teased before next week is building the team. Who do you include? How do you entice these people to participate? What are you going to do once you get them all in the same room? More importantly, how do you avoid getting stuck? If you have questions, comments, or just generally want to disagree with everything that we just said, please send them to us. You can email us at [email protected] or you can tweet us @cloud_unplugged on Twitter. I am Joel.
Jon Shanks 48:34
And I am Jon.
Joel Parks 48:35
And thank you for listening. We'll see you again next week.
Jon Shanks 48:37
See ya later, bye!
Transcribed by https://otter.ai