Transcript
Joel Parks 0:10
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. In today’s episode, we’ve got two juicy news stories to dissect, and we’ll discuss cloud accounts. How do you structure your cloud accounts and services to support the efforts of your team? So as always, I am Joel Parks. i
Jon Shanks 0:31
I’m Jon Shanks.
Joel Parks 0:33
And, Jon, welcome back to the podcast. This is starting to feel like a little bit of a clubhouse.
Jon Shanks 0:39
It really is. Yeah. Which I believe somebody was talking about doing Clubhouse soon, but I’m not sure….
Joel Parks 0:47
Yeah, that’s oooh that’s spooky? Well, I don’t know. We’ll see. Anytime somebody says basically Twitter with video that just fills my heart with dread. But I guess you know, we’ll see. Let us know if you’re if you’re a listener, and you’d like us to do something on Clubhouse, send us an email or a tweet, we’d be happy to look at that. But moving right along, let’s just jump straight into the news.
So we have two articles this week. They’re sort of interesting on different levels. The first one, I thought was super interesting. And this is very specific to the US. But there was last year, I believe it was last year the Pentagon awarded a contract for cloud computing to Microsoft. Now, that was met with a bunch of legal challenges and such because Amazon felt that there was undue pressure applied by the Trump administration to block the contract awarding contract award to Amazon. And it’s really what I thought was interesting out of this article, oh, two interesting things. The contract is called Jedi. So you know, does that mean that the Pentagon is the Death Star?
Or that Trump’s the Sith Lord?
ooof, careful!
*I find your lack of faith disturbing*
So anyway, but yeah, I just thought that was interesting. But anyway, there was an interesting quote, from the Pentagon press secretary Jamal Brown, he said, ‘we’re going to have to assess where we are in regards to the ongoing litigation and determine what the best path forward is for the department.’ So we were talking in a couple of the previous episodes about blockers and challenges to cloud adoption. Holy smokes is this the biggest possible barrier you could run into is, you know, sort of long protracted litigation, especially in the government space. So wowwee.
Jon Shanks 2:55
Does this mean that they they are still plodding along anyway? Until the legals, like it’s just like will this be like, basically, there’ll be in Microsoft and the legal they’ll be just going on for like years in the background, and it’ll be too late?
Joel Parks 3:08
I literally have no idea what’s going to happen. Are they gonna un-award the contract? I don’t even know how that would work. I mean, are they looking for the courts to invalidate it? Like this, this is nuts, but it’s it’s one that’s sort of interesting to me on on a level of like, wow, okay, the Pentagon is trying to do something and the cloud vendors are, you know, in a knife fight with each other, it seems to sort of either win or go home. So I thought that was sort of interesting. And again, we’ll we’ll tweet the links to these articles out so if you want to reference the the article, just check out check out the Twitter feed.
The second article is absolutely completely different. It’s an article about cloud adoption, specifically, and what caught my eye was what they were talking about, you know, that the greatest strength of cloud is also its biggest weakness, which we’ve also touched on. I’ll read a bit from the article:, ‘you know thecloud provides a composable set of services that allow organisations to create solutions that best fit their, their business purpose.’ All of that sounds great, right? ‘In many ways, yes, but the benefit of cloud computing is also its main drawback. Users can access cloud environments from anywhere with an internet connection. And by the by the same logic, so can cyber criminals and adversaries, so how to organisations keep IT environment secure and leveraging the full benefits benefits of cloud without losing the value that cloud provides?’ It then goes on to talk about new categories of tooling that are coming into the market that is specifically abbreviated CNAPP, which stands for Cloud Native App Protection Platforms. And really what this is designed to do, or this category of tool that is emerging, it’s designed to prevent or it’s designed to enable cloud utilisation but ensuring that security standards are met before, during and after the application deploy. So it’s pretty interesting. So this is an acronym I hadn’t run across before the landscape is always changing. But be on the lookout for CNAPP and your local Gartner Magic Quadrant.
Jon Shanks 5:37
I’ve never even heard ever heard of that either. Is it just, when did this come out? Is this like a new thing?
Joel Parks 5:42
Yeah, so and we’ll send the link out to this and Twitter as well. And there’s, if you if you check our Slack, I sent a link to it earlier. But it sounds like this is a convergence or a re bucketing of tooling in this specific space. So that talks about that there are there are tools that have accomplished portions of this before, but it was always an integrated approach. Now, numerous vendors are taking sort of, you know, one ring to rule them approach to this type of activity. So very relevant to our discussion about getting started, making sure security concerns are met. So if you are having those discussions, go look at this CNAPP group.
Jon Shanks 6:27
K-NAPP, maybe.
Joel Parks 6:31
Yeah, yeah. Submit your your interpretations of the acronym to the podcast. We’re happy to read those. But I thought both of those were pretty, pretty interesting little nuggets, and relevant to our conversations, maybe less so on the Pentagon side, but I just thought that was weird and fun. Fun in a bad way.
So moving right along. Our main topic today is about cloud accounts. So we’ve talked previously about designing your deliverable, you know, what is it that you’re going to deliver? Then we talked about building your team and shaping the organisation that’s going to drive that deliverable. But really, this is all moving toward the cloud provider. So if we’re going to do this in the cloud, we need to get started somewhere, we need an account. And, Jon do you want to want to kick this off?
Jon Shanks 7:21
Yeah, I guess without, you know, getting taken to court under the new Jedi contract, I guess, choosing the right cloud, it does kinda begin there. Really on like, what is the right cloud for the business? And I think, you know, inherently, a lot of companies will have relationships already with some of the vendors, i.e. Microsoft, and therefore, sometimes it’s the easiest route, because it’s the most familiar route. Not sold on that being the right approach, obviously, for the business applications. So if the value is about looking at the business services, what is the best set of cloud services and a cloud experience for those business apps is probably the most appropriate thing rather than just sticking to what you know, but obviously, at the same time, people do stick to what they know, because it’s just easier to work with people that they already trust.
Joel Parks 8:15
Right, yeah. And there may be extensions to that to where it’s not just an existing business relationship, but maybe one cloud or the other, has tooling or features that are more accommodating to the technologies that are really core to your product, and what you intend to do. So each of the clouds does have a slightly different mix of services. And in a certain sense, slightly different specialisation. So looking at the way that they have gone about crafting the portfolio of applications and functions on the cloud, may read backwards to you in a way to say, Oh, well, the technological fit is cloud A right? Maybe the the technological fit is, is Google for, maybe you’re doing something very involved with data. Right. But that’s just one data point. Right? The business or the contractual relationship, may be something you can’t get around, maybe this has already been decided for you.
Jon Shanks 9:11
Yeah, which a lot of the time is the case, the commercials, the commercials are in place before the business case is sometimes, right? On like defining the requirements, sometimes the commercials in place before the requirements are even understood. And you know, that’s just what you’re using now. And it’s time to just crack on and the team just has to adopt it, no matter what. But I think if people do have the opportunity to start doing it properly from the beginning, then assessing which services you know, appeal more so to the business applications. Also speaking to similar companies or companies, you know, that might be using some of those services, some of the case studies surrounding them some of the outcomes they’ve driven. If you get to kind of spend that time looking at that that’ll be obviously of more value because it’s gonna bring more of an outcome value for you if they match and align. But yeah, I guess what you were saying around the account structure, which is probably what, you know, if we’re kind of agreeing that you’ve got to choose, they do do it differently, right? Each cloud has a different way of organising itself. And architectural frameworks around them are slightly different per cloud provider. So you’ve kind of got to learn, you know, whatever the cloud provider gives you in the ways that they give it to you. And some, in my experience, do things better than others?
Joel Parks 10:34
Oh, for sure!
Jon Shanks 10:37
Our engineering teams have pulled hair out with certain cloud vendors without naming names from an engineering perspective. But yeah, what’s your what’s your take on the account structures for the different clouds, Joel?
Joel Parks 10:52
So they, while the implementation is different, and we’re going to contain this discussion, just for context, for the listener, we’re going to contain this to talking about Amazon, Microsoft and Google because they’re likely the three that you will be evaluating in your first pass right? There are others to be certain, but we’re gonna focus on those. So while the implementation differs from cloud to cloud, they all have a similar construct, meaning that they have a hierarchy of accounts and organisation structure that is put in place deliberately, to allow organisations to apply not only reports, but also controls at different levels of the organisation. So you can think about the account structure on each of the three clouds generically speaking, as there being a high level structure that really defines the business on the whole, your overall, the umbrella under which all of your resources will live. One level down in the hierarchy from that there’s really the line of business structure. This is one level down from that big umbrella that is more focused around, you know, a specific line of business, or perhaps a specific customer, if that’s the way that your organisation is set up, you may have different lines of business that are attached to specific contracts or specific customers. And then one level down from that line of business structure is really the team structure. It’s where the applications themselves live, and where the application development teams really have a direct line of sight into where application A, B, or C is actually going to run.
So if you think about that structure, it allows you to, let’s say, if you want to get a report on the overall cost of everything that an organisation is running in the cloud, well, you can run that against the high level structure and pull a report that gives you everything. If you just want to know that same information but for a specific line of business or for a specific application, the structure of the accounts allows you to apply the reporting the policy mechanisms, the controls, that an established, you know, medium to large enterprise is going to need when they’re starting to move workloads into the cloud.
Jon Shanks 13:17
Some of this is new as well, like, you know, from an Amazon perspective, originally, you know, you’d have your account, or maybe a few accounts. And then they had this VPC concept, which is obviously, you kind of segregating at a network level, I guess, in some principle, your virtual private cloud. And that was the segregation, even though there was limits surrounding these. And then, later on, they recognise that people were using accounts as the isolation, not really VPCs because it didn’t scale as well. And then they’ve kind of adopted new services and Amazon called organisations and, you know, control tower and you know…
Joel Parks 13:56
Yeah, so this is absolutely… the fact that all three major clouds have adopted a similar hierarchy and a similar structure is really an industry wide learning that’s come I’d say in the last five years of watching large organisations adopt cloud and then finding that, you know, the structure of the account or the structure of the way that the resources are, you know, sort of contextualised or ring fenced within the account was was something that everybody struggled with. So they all sort of arrived at a similar hierarchy. Now, the way that it’s implemented in each of the three clouds like Jon was teasing, a little bit of the AWS stuff is slightly different.
So we’ll start with Amazon. So when you think about the high level structure, the line of business structure and the team structure for Amazon specifically that high level structure is the organisation and the organisation is set up to be the big umbrella under which the various accounts which is the line of business structure willsit, you can segregate control, you can segregate reporting, policy etc, you know further down the tree to either something that is relevant to the entire organisation and a standard, let’s say in the case of a policy that all teams and all lines of business should follow. Or maybe it’s something specific to a line of business. But then even going further, when you get to the team structure, the third level down, you now get to the VPC. So there may be things that are specific to configurations or policies, or reports that you want to pull on specific applications or if those applications relate to a specific team that you may want to get at one common issue there, since we’ve touched on cost already, is understanding how costs break down for a given application team across development, you know, sort of QA, tests, staging, whatever that environments or whatever that environment or environments looks like, and then production, and they want to see the relative cost of those environments and then be able to attribute that back to the team that was doing the work.
Jon Shanks 16:11
Are you being attacked, the hounds are loose!
Joel Parks 16:17
No, not being attacked. But I guess the listeners have now been introduced to my dogs. So they are now through the magic of editing put away.
Jon Shanks 16:26
They know a lot about cloud, that’s the thing … you need to get them on!
Joel Parks 16:31
Yeah, the little one especially, she’s pretty bossy, she knows everything. So going from Amazon now to Microsoft Azure. So in AWS, we had organisations, accounts and VPCs. The structure within Azure is similar, but it just has different names. So the high level structure and equivalent to the AWS organisation is the Azure Enterprise Enrollment. So you can think of this as being in a lot of cases tied to your Microsoft ELA. So you can pre negotiate terms with Microsoft and include Azure spend as part of your your ELA, if that is how you’re consuming it. But this that is the big umbrella construct that defines the organisation at the top level, the the next structure down are Azure accounts. So you have AWS accounts, you have Azure accounts. They serve the same organisational purpose. And then for Team structures, instead of VPCs, they actually call those subscriptions. So that’s where it gets a little confusing if you’re talking about AWS subscriptions are one level up in the hierarchy. Here, subscriptions are the lowest level of the hierarchy. And v nets and resources sit within those subscriptions.
So you can see here that they’re all taking a similar approach. But the names can get a little crossed up and confused if you don’t clearly communicate which cloud you’re talking about, and what level of the hierarchy you’re discussing.
Jon Shanks 18:02
Yeah, I think with Azure, from memory, their licencing model changes depending on how you’re ordering the creation and management of the subscriptions and central billing and all that.
Joel Parks 18:15
So we can have an entire conversation about that, because each of the three clouds has a different idea of how you would do that. So Amazon has an Enterprise Agreement method. So does Microsoft so does Google. And we’ll touch on that in a future episode. But speaking of Google for Google Cloud Platform, you know, at the high level you have the Jeep GCP organisation. That organisation is the high level construct one level down that this is where Google gets a little googly. I’m just gonna say that right? Because they have, they have three different ways to accomplish that mid level structure. So this is equivalent to an AWS account or an Azure account.
They have folders, teams and projects. So there are different methods to be able to organise resources at that level of the hierarchy. And then the low level constructs within GCP is a GCP project. So just for clarity, because I know that we’ve thrown a lot of words at the listeners. So the high level account structures on AWS is an organisation on Azure is an enterprise enrollment and on Google Cloud Platform is an organisation.
The line of business structure, the mid level of the hierarchy on AWS is an account on Azure is an account and on GCP is either a folder, a team or a project. And the team structure, the lowest level of the hierarchy for AWS is a VPC. For Azure, it a subscription and on GCP, it’s a project. So really all this matters in the context of setting up your first foray into the cloud driving your first deliverable into the cloud. Because one of the success criteria should be: Is this sustainable? You know, and you know, making this something that really provides, we talked about having it be something that provides real business value. Part of that is going to be demonstrating that it can be maintained and controlled over time that it can survive the rigours of day-2 operations. And this structure, if you adopt it, as the cloud providers prescribed that you do, will help you avoid some of the pitfalls around sustainability, that a lot of organisations prior to this, and Jon, maybe you’ve got a war story that you can tell. But you know a lot of organisations prior to this being sort of a commonly held structure really ran into problems with, mixed context and poorly organised infrastructure and potentially some some downtime.
Jon Shanks 21:04
Yeah, and security concerns. And, you know, and everything had to be like your kind of proficiency or making sure you do everything perfectly, to make sure that everything’s as it needs to be to get the billing right. And you didn’t end up with some random unallocated resources in Amazon that you didn’t know, like, who owns it, but it’s costing us like 400 grand a month. And then you’re on the hunt, to find out like, who provisioned this, where did it come from? Why is it costing so much money? Which team does it belong to? So you know, that’s basically was the origin of all these things. And then you’re like, Well, actually, if we create an account for the team, or two accounts for that team, you can use the accounts for teams really, then it’s isolated, right. So you know, those accounts are owned by that team. That’s much easier than trying to tag everything within an account for a team and making sure that, you know, you’ve done a really good job and all the tagging, and then you have tagging policies and all these other overheads that you’ve got to do in your business to do it, right.
Joel Parks 22:09
Yeah, so I think we may have a quick digression into story time. So this story is about a an AWS account named Tony. So Tony was created by oddly enough, Tony. And I changed the name to protect the innocent, but Tony was an app dev manager at a company that was sort of, it’s an established company but they were, let’s say, reinventing some of their products to be more cloud friendly. And he was one of the early champions of this approach. And some of the early work was done…drumroll please…in a Shadow IT mode. So the way that they prove business value was by you know, creating a sandbox on AWS. The account was called Tony. And it had some of the early prototypes of what they envisioned the new form of their product to be. Well, fast forward, they did a lot more development on those prototypes, they began to mature, they began to get or look like they were ready for GA. But they were still running in Tony. And Tony became the bane of everyone’s existence, because it was a completely flat structure, there was no hierarchy as we defined before, which means that it was very difficult to determine who owned what, how to attribute costs for anything, how to govern, if you can imagine, you know, if everything’s in one big flat bucket, you know, how do you apply configuration management to that, for the the infrastructure resources that you have? How do you attribute, you know, the the cost of maybe somebody left a dev environment running, or some components in a dev environment running over the weekend, and it ran up a huge bill. Well, who who would does that actually go back to? You know, whose budget does that come out of? So it ended up at the end, a rather lengthy, unnecessary exercise for this team to go and extract everything away from Tony. And eventually, Tony was decommissioned. So there’s your your bedtime story, and cautionary tale of Tony.
Jon Shanks 24:25
And Tony if you’re listening, you know who you are! I’m joking…
Joel Parks 24:30
But it’s but it’s the type of real world thing that can happen if you don’t sort of think through the structures or you don’t take advantage of the tools that the cloud providers now give you. So it can save you a lot of headache in the long run, if you just adopt these structures up front because they’re they’re quick ways to get up and running with them, which we’ll talk about in a second. But they also make your cloud resources look a lot more like how your organisation is structured.
Jon Shanks 25:02
Yes, it’s the Conway’s Law. Isn’t it? But that story was a very, like, standard story. I think I think everybody knows a ‘Tony account
Joel Parks 25:16
100% Yeah, it was set up with a credit card swipe and a pay pay as you go model. And it never got refactored, until they got very, very late in the product development cycle. And they had to, I didn’t say this, but they had to put the brakes on some other things that they had planned to do. Because they had to go back and remediate that stuff, before it could go live. It became a blocker for them. So again, you know, in a way of sort of paying this forward and helping you avoid pitfalls or challenges that you otherwise wouldn’t have to face. I know, we’re talking about maybe some dry stuff this time around. But it really is to your benefit to take a look at this, understand it and make sure that the way that you deploy or move resources into your first cloud environment obeys this sort of structure, because it will eliminate that downstream roadblock, or the the possibility that you’ve got to do tech debt elimination. At some point in the future.
Jon Shanks 26:16
Yeah so I think the rule really is segregate at an account level, or a project level, really, as much as you possibly can, you can then put controls, especially in Amazon, and you can put the controls over the top of that account. But historically, in Amazon, obviously I’m speaking a lot about Amazon because that’s where most of my experience lies, I remember when you couldn’t really tag. Certain services didn’t have the tag capability on them at all. So it took time sometimes before tagging was even available on that service that they just released. So you could never attribute a cost if the account was shared, because there’s no way to tag who owned it. So you know it’s much easier when it’s done much higher level when the segregation is done higher up than it is when you’re trying to do it lower down in the stack, because it’ll just cause you a lot of pain. So.
Joel Parks 27:04
Right, exactly. And that’s, that is 100%. The learning that all the cloud providers took away from some of these large early adopters is they needed a more hierarchical structure, to contain the resources and to make them maintainable. So now that you have a general understanding of what that hierarchy is, and how it’s implemented in three clouds, the next task that you’re going to face as a team is okay, got that? But where do we draw the line? You know, what exists at the organisational level? what exists at the line of business level? And what exists at the team or product level? So I’ve put together a list of questions. And these are things that I would suggest that you ask within your team when you’re wrestling with this question that will help you determine where that line needs to be drawn.
So the first question is, who is answerable for the budget? And how do you want to track those budgets? So in other words, as you’re doing the work, you are going to accrue cost in the cloud? Who is ultimately answerable for that budget? Is it the line of business? Is it the team? Is it the organisation? If the answer is likely, some of all of the above, think about the structure that makes the most sense from the standpoint of what would it you know, how do you want to pull cost reports and what report needs to see what.
Jon Shanks 28:35
I think so also, just because some people might be moving from a capex model, where cloud isn’t a concern, as in cloud costs aren’t really a thing, because you’ve just purchased it all. It’s all on-prem, and it’s done. And it’s then a shared cost back to the, you know, that the business is kind of owned. So if you are moving to cloud with the first time designing this, you know, in the right way, really, who needs to care about the implication of a high cost, and who has the power to change the cost, right? So if it’s the team that can reduce the cost in the end, and they need to be the ones that have oversight of the cost, because there’s no point to somebody that isn’t in the team, knowing how expensive it is, and not the team that can actually reduce the cost. So, you know, making sure I kind of get that right is important.
Joel Parks 29:22
Right, so that’s one way to think of how to draw the line. Another question would be what is the separation of duties? So if you think about a typical organisation of, you know, lines of business sitting, you know, that have teams and products, then there are some higher-level executives that sit across all the lines of business, you know, what are the separation of duties for the application? How do you intend to provide access to the teams that are actually doing the work while minimising the chance that they’re going to step on each other? So if you have multiple things going on at the same time, how do you segregate those in a sane way that looks a little bit like your organisational structure or your reporting structure. Without putting unnecessary controls or blocking processes in place, that’s we’ve already talked about that being a bit of an anti-pattern. But think through it on a separation of duties lines.
Another question to ask is really at the end of all of your work when you’ve delivered successfully the thing that you defined? How are you going to show this off? And who’s the audience for that show and tell? If the audience is line of business managers? That sort of implies one way of thinking about it? If the audience is the C suite, that implies a different set of concerns? And I would ask, I would ask the question within the team, what are they going to see when you do the final show and tell and show off what you were able to accomplish? And is the structure that they see going to make sense to them? Is it something that’s going to be familiar or you’re going to have to spend a lot of you’re probably very time-constrained, you know, presentation, explaining things that look weird to them right? Now, I’m not saying that you should avoid that outright. Maybe that’s something that you do some pre-emptive education on before you do your show and tell. But it’s always helpful to think about who is the audience for when we’re going to show this off? And how do we make this? How do we make the impact of what we’ve done resonate with them?
Jon Shanks 31:34
Yeah, and there’s some actually some other things I just thought about, while you were talking, is networking. Now I know we kind of keep speaking about this. But before it is a bit contentious, and it probably is the most contentious thing in cloud in truth, because there are many different ways you can achieve certain things, you can obviously pair it in a VPC level, that will live in an account. But you can also have some obviously, Amazon itself has like transit gateways, for example, that you can then have one thing that’s doing all the routings somewhere, and then things then attach into it. But the automation around these things kind of really isn’t there, there are some ad hoc tools around all of this stuff, it makes it quite difficult. So assessing how and what each team needs access to what the services are. And then also what the data is surrounding them. Because you know, as Joseph mentioned, you’ve met is kind of brought up segregation of duties. But also there might be different data owners within the business. Even for that one team, the team might be delivering on behalf of two different business units of which there are two different data owners. So it just depends on whether you’re segregating by the data, as well as in like, actually, they’re separate business units and delivering for rather than the team perspective, or whether you’re doing it from the team perspective, overall, and they’re responsible for the data, and putting those policies in place. But I’m not going to get into the networking, because I have spent so much time talking.
When it comes to cloud, I think that is a topic in itself that we should probably talk about when we’re further down the road, we get into more of the technical stuff. We could have maybe a technical, technical podcast on networking, and maybe bring somebody on from one of the cloud vendors actually, because is is enough to tear your hair out with all the different options of how you achieve it and working out which one’s the right one.
Joel Parks 33:28
Yeah, if that sounds good to the listeners, you know, give us some feedback. And let us know if you’d like to have a deeper dive on that topic. sounds completely reasonable to me on the the account structure is there. The good news is there are mechanisms that help you apply these structures. Now in a in a in an easier way you do it. This isn’t a manual configuration task. And I should probably preface upfront that it should not be a manual configuration task. When you go to set up these account structures. It’s a really good idea at this stage of the game to define those using the cloud providers, native mechanisms and automation tools. Because one of the key learnings that you’re going to have in going down the cloud path or beginning your cloud journey is learning how to define things as code and letting the automation tools create the structures that are defined in code. And we’ll touch on that in a couple of ways in just a second. But for AWS, there’s a there’s a tool called control tower and control tower was really built out of the need to rapidly stand up very, you know, well thought through best practice based account structures in AWS. So it has a very defined way of creating these organisation account and VPC structures that are, you know, more or less ready to go. There’s still things that you’re going to have to do, but they meet all of the AWS well architected standards for an account structure. So that tool is very, very helpful. If you’re on the AWS side.
Jon Shanks 35:05
As a caveat to that, though, briefly, there is no API for control tower, just to let people know. So I think that the assumption is that you’re using control tower to give you the accounts of which then you do all of the all of the stuff. And and there isn’t, unfortunately, an API for it. Yeah, I believe they are going to release one. Because we had to work with them quite closely on some of these constraints.
Jon Debbie-Downer Shanks!
I know, I’m sorry! I don’t work four Amazon here. So you know, don’t shoot the messenger. unless they’ve changed it. You know, they may have brought the API out. I’m not sure. But tthere wasn’t one when last time I looked?
Joel Parks 35:47
Well one thing we can guarantee is that if you’re doing a podcast about cloud technology, everything that we say is going to be wrong eventually.
Jon Shanks 35:56
So yeah, I love the API, Joel, do you?!
Joel Parks 36:01
Just an edit a couple years from now. But on the Azure side, it’s slightly different. So they have a concept in Azure called Azure Resource Manager templates, they’re sort of correlated to cloud formation templates. On the AWS side, they there are a set of ARM templates that define Azure account structure that you can use to get up and running. But it doesn’t really do anything for you on the day-two, it just gets you up and running with a structure, but then they’re assuming that you’re going to apply other things to maintain that structure over time. And on the GCP side, as best I can tell, really, the best way to do it right now is through terraform. And I believe that that GCP can provide some some terraform templates that have you know, the basic structure of what they recommend with some fill in the blank variables that will get you up and running. But AWS is the only one of the three that has a purpose built tool for this at the moment, the other two still are relying on, you know, configuration or automation tools that are aware of their their particular environment.
Jon Shanks 37:21
Yeah, I think you have to roll your own. I think with Google, you have to create a project. If you are going to automate it, I believe you have to create a project that has permissions to create projects.
Joel Parks 37:33
That sounds about right.
Jon Shanks 37:34
Yeah and then you have a service account inside that project that’s got the permission to go and create other projects. And you end up using that to kind of streamline the automation. But yeah, yeah, that’s kind of like most of them are roll your own solution. But there are examples out there. I don’t know how many people are really doing that, to be honest, because it seems to be a bit of a other than Amazon with this product, you can’t really find a huge amount in the industry of people kind of doing it this way, which is a bit strange, I kind of think so be good to get a good game that I really like who is automating account creation or subscription creations or project creations across these cloud providers for teams?
Joel Parks 38:11
Yeah, I think a lot of times that falls to, you know, consultants or professional services teams to come in and provide some of that, however, the options directly from the cloud providers have gotten markedly better over the years. AWS is just I’d say, you know, about two steps ahead of the rest of the rest of them. But I have no question in my mind that, you know, fast forward, just a little bit in time here and Azure and GCP, you’re gonna have similar similar tools to control tower, it just, yeah, I don’t I don’t see any reason why they wouldn’t.
So that’s sort of the the account structure, how you get everything ready to go. The next question that commonly falls right behind that is, alright, now we need to start scoping our services, what services on that cloud provider now that we have a structure, we can begin to instantiate workloads, you know, what are the the services from that cloud provider that are in scope for our delivery? And that’s a long question. But I can I think what I want to do here is just provide a couple of pieces of guidance. The first one is, you know, when you’re scoping this, take a look at the technologies that you’re going to require to meet your deliverable. And where at all possible, use the platform provided services from the cloud vendor, if you can. Now, just to be clear what I’m talking about, it’s the difference between if you’re on Azure using Azure SQL, versus creating an Azure VM and installing sequel on it. In one in that mode, you’re responsible for the maintenance of another infrastructure component, that you’re going to have to learn how works. In the other case, in the case of Azure SQL, it’s merely just a service that you turn on. And you can deploy your schemas and data to, if you can make maximum use of the platform services, you will be I, I’d say a lot lot closer to how cloud really wants to work. And you’ll also avoid some of the temptations for scope creep. And that boil the ocean thing, where infrastructure creeps back into the equation, if you have to use infrastructure do but just know, it’s going to be an opening for old ways of thinking to come back in because people are gonna see, oh, it’s a VM? Oh, well, I can bring all my tools. And we can do it exactly like we do on prem.
Jon Shanks 40:43
Yeah. And this is, again, got to fit into what why are you going to cloud to begin with. I mean, you’re not, well, hopefully, you’re not going to cloud to repeat your on premise way of working, you’re going to cloud for operational efficiencies and scale efficiencies. And, you know, unless your business is also to be cloud, which I’m guessing most companies unless you’re a cloud one aren’t, then there’s no value. There’s no business value in trying to compete with the cloud by running the services they already run, like, why bother? So you may as well kind of use the services as they are, unless you’ve got a legitimate reason, you know, maybe there’s a service they don’t have? Or maybe there’s some limitations to that service. But that’s very edge. Very edge case.
Joel Parks 41:27
Yeah, absolutely. So what I would say about scoping services is used platform services as much as possible, right? It will, it will help shortcut some of the boil the ocean tendencies that you’re likely to run into if you have to use infrastructure. Just, it’s not a bad thing. But we’re trying to use standard images, don’t try and create your own images, if you can get away from it. Again, that’s just an added level of complexity that at this stage of the game, it’s not going to benefit you. And also don’t deploy those VMs manually use infrastructure as code to define your infrastructure and deploy on the cloud provider. If you’re getting into the console, clicking around instantiating instances, that’s okay, if you’re doing it in a learning capacity, if you’re familiarising yourself with the environment, but when it comes time to actually define the resources that are going to be used in your app, in the thing that you’re delivering, make sure that everything is repeatable and can be deployed from infrastructures, code definitions, if that’s the path that you have to go down. And the one thing and this is just a pet peeve of mine, so I’m behind the microphone. So I’m gonna say it. For the love of God do not bring your existing system patching or config management system to the cloud. I’m talking about satellite, I’m talking about system centre, I’m talking about the things that you do to patch operating systems in place, don’t do it, use the cloud provided mechanisms for accomplishing that task. If you try and involve a system like that, in this early stage, you it’s you’re gonna find your self backed into a corner very, very quickly.
Jon Shanks 43:09
Yeah, I think the projectile is. Absolutely, if you’re making a change, it’s new, right? So you throw the old away, and you provision the new, that’s kind of the art of it, or you provision the new, you move the traffic to it, and then you remove the old, you know, everything’s like that’s the design of cloud, you’re not there to try and change the old to become new on the fly. Because obviously, you’re gonna have downtime. And there’s a lot of risk with that, as opposed to kind of more of a kind of Canary releasing an AB situation, which is like, let’s get the new up. And let’s like, reduce traffic to the old and then decommission the old. That’s kind of that’s the way of thinking for cloud.
Joel Parks 43:48
Yeah. And really, when it comes to services, scoping at this stage of the game, if you had to sum up everything that I’ve seen trip teams up in the past, it’s what you don’t include, in your design, at this stage of the game is more important than what you do include, right? It’s whittling that complexity down and ensuring that you’re not just bringing legacy with you to the cloud, right? Use the cloud for what it’s built to do. And resist the urge to try and pull everything along. You know, if it doesn’t need to be there, then don’t include it.
Jon Shanks 44:24
Yeah, exactly. bare minimum really isn’t it minimum is read only if you can kind of get away with it as much as possible, obviously, reducing the risk of you know, at the end of the attack surface area by not having as many things installed, therefore, there is less risk. There’s less entry point. So that’s that’s kind of how you have to think is, the smaller the better. The more lean the better. The more repeatable the better, I guess.
Joel Parks 44:50
Yeah, absolutely. So at this stage, you’ve defined a deliverable. You’ve built a team, you have an account that has a structure behind it. That’s supported by the cloud vendor that you’ve chosen to use, you’ve scoped the services that are going to be included in your first design. All that’s left to do at this stage is to build a racy. So if you’re not familiar with a racy, it’s a structured for defining shared accountability and function. And the raci are a CI stands for responsible, accountable, consulted and informed. So for any given activity or area of responsibility, there will be individuals for that task that will be responsible for accomplishing it, there will be people who are accountable for accomplishing it. So that may be a manager, or responsible and accountable may actually be the same person. In some cases, there are people and teams that will be consulted, they won’t be directly responsible, but maybe we need information from them, we need their input security teams are almost always in the consulted category on every task. And then there’s informed, who do we need to keep who do we need to send status updates to who needs to be informed of our progress, they’re not actively involved, but they need to stay informed. And in the loop, by defining that raci, what you’re really doing is taking the account structure, the team, the services scoping, and you’re plumbing them together. So as you start to define the tasks, and who’s going to own what, and who’s going to do what put it in the context of a racy, and in the raci, make sure that you’re accounting for Okay, within the account structure, you have the organisation, the line of business level and the team level? Who is going to where, at what level of the organisation who owns each of those structures?
Jon Shanks 46:42
Yeah, I guess we’re a good accelerator. A good example would be, you know, Amazon’s releasing some new services all the time. Do you want all the teams to be able to use all the new services all the time? Does security need to review some of those services first, because it might be new. And therefore, you need to think about how do I control which services get used by which teams. And that’s, that’s a prime example of how you might need to start organising and thinking, you know, as a real life case, you might not be comfortable. And therefore you want some process around it. But then you might be people responsible might be some people that are consulted, you might have somebody requesting it, etc. and is somebody accountable in the end, for those service consumptions, once you’ve approved them, and you’re tracking who’s use
Joel Parks 47:30
and also service definitions, if you’re going if you are going to use in the case of my example, as your SQL over the way that you’ve traditionally consumed it in the past, your DBA team probably needs to be involved right. Now, the level to which they are involved, is something that you’ll need to think through in the context of the raci. Are they going to be responsible for that service definition? Are they some, are they a team that we’re merely going to consult with, and then another team is going to pick up that work to help define how, as your SQL gets used in this context, putting things in the context of a racy, again, will help you to connect all of these dots and make sure that not only do you have a structure that you’re working against, you have tasks that you’re working against, and everyone knows their responsibility within a given task, or, you know, thing that needs to get accomplished?
Jon Shanks 48:20
Yeah, I think, I mean, I’m not, I’m not a huge fan of it, because I think, I think they’re necessary when your organisation is structured in a specific way. Ideally, you structure your organisation in a way where there’s some autonomy, and the right people are in a multidisciplinary team representing the right disciplines. so that people can just get on with things and consume things. And everyone knows what’s going on, you know, in relation to that business line and line of business, and they report back, you know, what’s happening. And so there’s some oversight, but you’re not gating and controlling, and people can just get on with the job, but obviously, not all organisations like that. So, you know, you kind of have to represent the need, so you don’t end up with security risks and other issues going on. But, yeah, that’s my
Joel Parks 49:07
Yeah, in an ideal world, you wouldn’t need this. But in all likelihood, if you’re, if you’re making the change in your mindset, your thinking your processes, your skill sets, your technologies, from one context, you know, sort of on prem to cloud, there’s likely to be some confusion as to well who does this now. And a racy is the lightest weight thing I can think of, that lets you sort of start to bucket these concerns. Yeah. So that everybody knows how to communicate, because that’s the that’s the biggest thing. And we touched on it a couple of episodes ago where, you know, reinforcing sort of a common vocabulary so that everybody’s speaking the same language. In my view, this is an extension of that, at least early on. Now, at a certain point, it won’t matter everybody will just will be experienced will know how to interact in this context and you won’t have to map things out to this. level of detail. But if you’re beginning this journey, if this is the first foray into Cloud, I found this structure to be really helpful in preventing you from getting stuck.
Jon Shanks 50:15
What’s your take? I know, I know, we’ve got a bit of a shorter window today. So we can’t go like, we’re not going to go to town that we did last time on an epic, epic podcast a bit tight. What’s your take on this on the on the central team gating the services that people are allowed to use with some long process of evaluation of the cloud services before the businesses, you know, before any line of business is allowed to touch it? And do you think that’s, that’s a good approach? Do you think people should be just allowed to kind of get on with things and let that line of business, I think,
Joel Parks 50:46
certainly, I think service evaluation is a good thing, if for no other reason than if it’s net new to the cloud provider, then it’s something that, you know, by definition, we have to understand how it works. Because it may be something that we want to use, it may be something that just, you know, maybe on the surface looked applicable, but once we get into the details of it, it doesn’t really apply to us. And there’s there are a bunch of services on any of the cloud providers that don’t don’t think that you’re going to use all of them, some of them just won’t apply to you. And that’s okay. They’re, they’re there to be to fit a multitude of use cases. And your use cases may not align with how that tool was built, or how that product came together. Putting it in as a blocking task where there’s some very long arduous evaluation and preventing anybody from touching it. Even an experimental capacity, I don’t think that’s particularly healthy. But certainly by the time something is, is being included as a core component of an application, or a service, or something that’s going to get used by customers in a production context, by probably deserves a bit of scrutiny. Yeah, for no other, if for no other reason than to understand what the operational considerations are of just okay, when this fails, how does it fail? How will we know it? Does this constitute a change in like, how we monitor for things? You know, is this going to improve? Like, you get what I’m saying? Like, there’s just
Jon Shanks 52:15
I think, the reason, the reason I brought it up was because, obviously, there’s mechanisms now with certain cloud providers where you can push down controls and stop people doing things, right. So if you’ve got the power, you can obviously do, you know, wherever you want, and stop people using certain things, you could just say, you know, people can all teams could only use EC2, right. And then we’re kind of back to the problem we just said, which is like, but there’s cloud services that offer operational value. And now I’ve been forced to use EC2. So I think, you know, we have to be careful that we don’t command and control for the wrong reasons. And if you are going to, if you are going to enable people to use the cloud, work with that team, to prove the value, understand how they want to use it, and sit with them and watch them use it. And you can basically understand the use case, you know, live as opposed to trying to maybe just blanket yes, no, kind of binary approaches to cloud services.
Joel Parks 53:11
Absolutely. So I think that really wraps up the the meat of what we wanted to talk about today. Would you agree, Jon?
Jon Shanks 53:19
Yeah, I mean, I do. You know, we’ve been chatting on the side a little bit around multi cloud, which kind of fitted into some of these things we’re talking about, use the right cloud for the job, potentially, if you have that luxury, hybrid cloud. So I think next episode, it’d be great to kind of to unpick some of this because it’s complicated. The hybrid, the on prem, you know, the all in on the cloud, the multi cloud, you know, I think we should probably talk about the next episode. What do you think?
Joel Parks 53:54
I actually have that written down.
Jon Shanks 53:57
Oh, you do?
Jon is the king of segways, yep. So next episode, look forward to hybrid multi or single cloud … oh, my! Should you go all in on one? What about on prem? You know, how does that fit or does it or what if you’re just a Verruca Salt and you want it all now, you know, how does that actually play out? And how might that work in your context? So as always, if you have questions or comments or other feedback on the show, we would love to hear from you. You can tweet us at cloud_unplugged, or email us at cloudunpluggedpodcast@gmail.com. We will see you next time and discuss hybrid, multi or single cloud.
Yeah, Tony, if you’re out there, get in touch. But yeah, good talking.
Joel Parks 54:52
Thanks. See you next time.
Jon Shanks 54:53
Bye, bye.
Transcribed by https://otter.ai
