So you’re in the Cloud… now what?

Without doubt, the era of the cloud is upon us, but in the rush to the cloud, cloud operations and governance are often overlooked. I am Stan Gibson welcoming you to this on demand webcast. We're in the cloud, now what? In just a moment, you'll be hearing from several experts on the topic of cloud operations and governance. But first, just a quick word about this webcast. This webcast is coming to you on demand. And while we can't answer your questions in real time, we'd still like to hear from you. Should a question occur to you at any time, please type it into the Q and A box on your screen and then press send. You'll receive an email reply within just a few days. Also, can change the size and location of the windows on your ON24 interface, So please feel free to make the adjustments that work best for you. And now I'll hand things over to our moderator, Nick Kirkwood, Head of Core Platform Engineering at CutOver. Nick. Hi, I'm Nick Kirkwood, Director of Engineering at CutOver. Now Cutover's been cloud based since we launched, and we've helped many of our customers on their cloud journeys. And part of my role at Cutover is leading cloud engineering, so I'm really, really excited for today's discussion. We've got a great panel, because we shouldn't just be talking about the technology today, but also around the really important process and cultural parts of that ongoing cloud journey. And I'd like to just jump around the panel and introduce you to all of them. So if we could start with Hi everybody, I'm Sonya Scott. I'm a Principal Business Development Manager at AWS, Amazon Web Services. And my passion is cloud operations. I'm also the lead for the AWS Service Management Connectors for ServiceNow and Elastic Jira Service Management. And on the Control Tower Service Catalog and App Registry service teams. And my ultimate goal is helping customers get workloads to Production workloads into the cloud. So in my free time, I love to spend time with family, go on beach vacations and have fun. Yes, Missoni. Sam. Hi, I'm Sam Eiling. I'm a director in Deloitte's UK consulting practice. I sit in our human capital team and I advise clients on strategic business transformation, usually very heavily enabled by digital and cloud technology. And I'm particularly focused and passionate about helping clients with the people side of things, so the people, the organisation or the cultural aspects of transformation, which in my view are often the hardest parts to get right. But I'm biased, I would say that. So very excited to be here to talk about this hot topic and thank you for having me. Thanks Sam, and Kieran. Hi, I'm Kieran, I'm the CTO and Technical Founder at Cutover. Before Cutover I spent a lot of time shipping what I would call shrink-wrap software for the game and mobile industries where there there was definitely a challenge because once you chipped, it could be a one way door and updates were incredibly difficult. And the speed and agility that I'm sure we'll talk about today did not exist. I was involved in developing some large apps for organizations such as BMW, BBC, and Tesco, as well as several startups. And at CutOver, I really try and help keep the balance between the future and delivering software solutions that help our customers right now with great partners such as AWS and Deloitte. Great, thanks very much Kieran. I'd like to start talking about maybe some of that organizational stuff, so how you support an organization with cloud adoption. I know Sam will have a lot of thoughts here, but also everyone else. So I guess to kick things off, how do you upskill the sort of more traditional ops people to be comfortable with the cloud? And how do their skills complement those of engineers who've kind of learned their trade in the cloud? How do you see that working? Sure, so I guess the first point to make is don't underestimate the value of having people that know your organisation really well. So people who understand how your business works, how decisions get made, how to get things, how really to get things done in your business. So I think it's really important to have a mix of those people who understand the on prem architecture and your culture and your kind of legacy processes with new people with a much deeper understanding of new cloud technologies that you might be rolling out. But building these new skills is a really big challenge for our clients. Hiring is super expensive and time consuming and I think we all know these skills are in hot demand, so it's tricky. You need to find the people in your teams who are willing and able to be reskilled and this takes time. We do a lot of work at Deloitte helping clients look at their current teams and try and pinpoint who are the people who can adapt to the new way of working really effectively, whether they need to upskill or reskill, who have the kind of the bare bones of that capability. And we use a platform called Cloud Workforce Analytics, which helps you assess the current workforce and their skills and map them to what you need in your new organisation. So it's kind of underpinned by a huge bank, a library if you will, of skills, both technical and broader business and softer skills, and kind of the typical skills and proficiency levels that you need in typical cloud roles. And I guess the next step is developing the workforce strategy. So once you've understood the gaps, what's the right balance of bills, borrow, buy? Where are you training people? Where are you recruiting? And where are you using perhaps off balance sheet talent, whether that's contractors, consultants, otherwise, to help you kind of flex on specific skills. And I guess final point to land on, it's not just about academic learning, it's about on the job learning. I think that's a really important one and it takes time. Yeah, just on that point, Sam, I think it's really interesting in that if you sort of just treat the cloud as storage and compute, you can have the advantage. You could go across three providers and maybe go across Azure, AWS and GCP if you wanted to sort pick the top three. But then you're not going to get advantages if actually if you go deep with one cloud provider because you wouldn't take advantage of some of the managed services like SageMaker or Amazon Aurora or similar, because you'd just be treating something as an amorphous blob where really it's just an extension of an on prem facility. Yeah, absolutely. I think that phasing is really important. Know, you need to introduce the skills when they're relevant. There's no use hiring a bunch of AIML engineers if you're only in the process of migrating your basic workloads. And you know, when you start, you might not know which providers you're going with, and therefore which deep skills you need. So you need to sort of start generic and then specialise. So I think it's all about the phasing. I think also it's not just the technical skills, it's the interpersonal skills, know, you need people who are going to be able to influence outside of the typical management line, are going be able to evangelise new ideas and new ways of working that are perhaps quite foreign and alien to the organisation. And people who are going to collaborate naturally, so naturally work across team, across border, and have the, I guess, the sort of storytelling skills and the business skills to be able to translate back the kind of the business case of cloud and what you're doing from a technical perspective into business value and help sell it to the rest of the business. And I think the sort of the overall soft skill is adaptability and agility, isn't it? Because cloud moves so quickly. So you need people with that kind of basic basic skill. Sam, I agree with you. And I also think that it's about how are you tying the business value of how cloud enables your customers to be agile and innovate in their competitive market space. Customers need to tie back their department, CIO, and overall company goals, how that innovation works so that when leadership is looking for the value, they can directly show tangible results. So that's why I always recommend to look at not only the technical or the soft skills, but also the business value. Yeah, absolutely. And I think it's also about blending skills and breaking down silos. So, you know, the cloud is always, I always think about it as being sort of a devolution of responsibility. So FinOps is a great example. You know, you can allow every developer to be able to spin up resources in seconds, but if they haven't had to think about the cost of the infrastructure, don't be surprised if they forget to turn it off at the weekend and incur a huge bill. And I suppose that one Sam is really interesting, isn't it? Because the cloud gives you the ability to actually define that in software. You can set alarms and boundaries. There is an electric fence and a perimeter so that somebody can't leave something on and run up that big bill for a thousand dollars, which lets people feel safe in the knowledge that they can experiment freely, but again it needs new skills for people to understand that that's a possibility. Oh thanks very much, I particularly like that stuff you're talking about there around adaptability. I think that's super, super valuable, right? Just, I guess kind of on that topic, how do you see things working for developers, maybe those who've not historically had to care too much about how their software is run? And how do you help get them excited about how engineering in the cloud? I'm very interested by this question because I think it is generally not been a problem for us. I think most developers are desperate to get access to the latest tools and services. So they're very excited about this shift. There's likely to be something for everyone and the cloud will do a lot of the kind of undifferentiated heavy lifting, allowing the developers to focus on the real value add. So I'm really interested to hear what others think about this because it's not something that we've seen as being a massive challenge. Yeah, I would say that, I mean, working at AWS, it can be There's that new shiny bright object coming at companies daily, right? And so I think that to avoid the, I would call it that innovation fatigue, I think you really do need to, even though people wanna learn new skills, but also create some incentive mechanisms and measures for your engineers or if you call them builders, project managers and stakeholders to improve the workloads that they're building. So I had a customer once who created a monthly gift card incentive for builders that were able to improve workloads and reduce costs as a way to keep them motivated and wanting to learn more, wanting to identify different services as they became available to improve the workloads that they were moving to production. So it's all about if an engineer is not excited naturally, then creating instead of mechanisms to do so. And I suppose it's really interesting. I've seen that there can be that pent up demand. It can be a little bit like letting a kid loose in a sweet shop and that they'll suddenly gorge themselves on the new tech and it can be that that's the problem. You really need to make sure that you're not just adopting tech for adopting tech's sake or going hunting for problems. And it's very easy as Miss Sonia touched on, can spin up a Ferrari in AWS at a click of a button or any of the cloud providers. And if actually all you need is a simple car to get you to your end journey, let's make sure we're incentivizing to solve the business problem and not just scratching the developer's itch to learn a new skill or try out a new technology. I think that incentive point's really, really key, isn't it? I guess there we've kind of talked a little bit about the people building and the people running. How about for leaders? Like what do you see, Sam, as been the biggest or the hardest mind shift for leaders to make when they get to the cloud? Yeah, it's an interesting one. I think probably one of the most important points from a sort of people and culture perspective, getting that leadership right. And I think, you know, strong leadership is such an important part of any transformation, you know, setting the tone, setting the culture. For cloud, think the technology leaders need to be able to, it comes back to that storytelling point, need to be able to really sell the value to other parts of the business. And conversely, other leaders outside of the technology domain, I think, need to become much more cloud fluent. And then I think the key point I would make is it's about being bold. So giving teams the right level of sponsorship to push through established ways of working, which is really easy to say, and as I think we all know, really hard to do in most organisations. So for me, it's about that bold, transformational, challenging leadership style rather than incremental changes. And I think that's a lot of that is about creating an environment where risk taking is welcomed, encouraged, and teams can be experimental without fear of failure and kind of embrace the disruption and new ways of working. So going back to the devolution of responsibility point, I think maybe that's a point better played out here. So, you know, leaders in this one, this applies to, you know, this isn't just about the cloud, this is modern leadership, you know, in a digital world. It's about creating the environment for the teams to flourish. The tech's moving too quickly for leaders to keep up in the main. So you're be an expert at everything. So how do you leave that to your teams and it's about how best to do that, think. Yeah, to that point Sam, I'd say governance actually once you're in the cloud becomes easier. Sandboxes are a lot easier to set up and therefore if you can get over that want to have centralized control and really give away the Legos and set up that environment so a team's not got to jump through hurdles to try something new. What you can do is you can de risk it and really limit the blast radius in the cloud because it's easy to set up another domain, get an SSL certificate and then run an experiment that perhaps it wasn't before, which is why the original controls were in place. As you say, you gotta be a bit bold. Yeah, and I would say don't make cloud ops and the introduction of new technology and services an afterthought. A lot of builders tend to create their experimental designs. Now, we've identified what's the proper design to go in on top of applications or in two different cloud workloads, and then operations doesn't even know what's going on, right? And don't assume people understand. So as you're doing your organizational change management, get security involved, get operations involved, get all the key compliance involved, get all the key players involved in the process and having the buy in, because if it's an after start, we used to call it a concept called the great stall, where you'll just see false starts because, you know, different stakeholders weren't aware of what was happening and and the innovation of cloud and were used to traditional or on prem. And then so you had to educate them and you had to do all those different things. So if cloud engineering teams bring those different stakeholders on in the beginning, it's a journey together as opposed to creating false starts. Yeah, I mean, absolutely resonates with me and with, I think what we're seeing. I think it's that collaboration at the sort of leadership level across all functions, if it's to work. And it's not just about the IT, the digital, the technical function. And I think that, I guess, point to sort of another sort of point to land on is we've definitely seen a shift in the last few years from cloud programs being perceived as just about the tech and largely about driven by cost reduction agendas. And I think whilst those slightly more tactical programs do still exist, we're seeing a lot more about cloud as an enabler of broader business transformation. So C suite level programs, multi year global programs, top down, you know, heavy sponsorship about de siloing, de layering an organisation, becoming more innovative, creative, nimble, and cloud is a major enabler of that, which I think is just a fantastic shift over the last few years. Fantastic, thanks so much. Really, really interesting thoughts on that. One area I'm keen to sort of explore a bit further is around the governance side of things. So how you manage governance of your cloud adoption. And I guess to start on this, perhaps Kieran, the cloud, it moves very quickly, right? We've talked about that around, you know, the skills that people need to keep up with and how that works. But you'd also see that around alarms, Things that were once relevant, they just end up far too chatty in the cloud. It's moving too quickly. What does good monitoring and alerting look like would you say? I think it's twofold. You can get away with that idea of human daily checks and things can be done in software first off. All of the cloud service providers provide software monitoring abilities and alerting abilities. And then there's this mindset shift as we've talked about where it's a lot easier to run closer to the limit. So if you're a service, you might have had a previous alarm where you were sort of saying, oh, when it got sixty percent we need to start alerting because we need time to order more capacity or order more storage. And in the cloud you can run much closer to a limit where it's actually just when your developers are interested in, is the service about to break rather than worrying about procurement? Because more capacity is potentially only minutes minutes away or has been completely abstracted if you're moving into a serverless model. And just understanding what those constraints and alerts now need to be now you're operating in a new model. And how about, I guess, like the control side of things, right? Can that governance be scripted, would you say? Like, how do the audit trails that you get, you know, with the various cloud platforms, how do they help support that? Yeah, suppose if we took it's having a look at what your governance was and why it was put in place, because undoubtedly the rules were put in place for a good reason, and those controls were put in place to defend either finance customer experience or something. Won't have just been put in because it was a nice idea and nobody wants to put controls in. So if we took a legacy rule that maybe you've got a note that says every time a new server's been added, it's got to be added to the ITSM system, and then you directly transpose that into the cloud and you've set up against an auto scaling group for EC2 servers that are potentially popping in and out hundreds of times a day, and each time those change requests are getting logged in ITSM, somebody's meant to approve them by hand. You're either gonna have a very disgruntled employee or somebody's going to leave or something's going to break very quickly. So in that example you want to just move the governance up a layer and say if the auto scaling group's limits were altered, that's where you need the good governance in place. And you've just gotta look at all your rules and think, why did we want them? And how do we apply them now directly to the cloud? I'm sure Miss Sonia can add to this. Yeah, I would say the biggest misconception is that ITSM goes away when the cloud comes, right? In my view, I've been in the IT world for over twenty two years and in the nineties, at the end of the nineties, change management was supposed to go away and it's still here because the essence of it is to do what? Minimize business risk. And so it's not that you do that example of for every auto scaling group and approval is needed, but how do you set an account for through preapproved changes, through preapproved pipelines? How do you address those and policies and procedures have certain types of allowed ones? And then if someone wants to expand the scope of what is allowed, then going through approvals at that place. So it's not to get rid of different governance controls because you have to think about the business risk in the event something happens and things do happen, right? So giving the flexibility and agility, but accounting for how this can be addressed in cloud. That's the key thing that every customer should look at all of their service management, governance, compliance controls and say, now how do we address this with this new power to move fast? And I think it sounds like sort of looking at those sort of things as blueprints or templates, and I guess they sound great in theory, but can you maybe talk a bit about how they work in practice here in Statham? Yeah, I think it's the great advantage and the great downside in that software is easy to edit and easy to change. And conceptually it's easy to edit and easy to change. So it can feel as though it's free to make that change. When you accelerate that and sort of think, right, we've now got infrastructure as code and we're gonna template how we stand up things. If there isn't good governance and visibility across the org, you might have a hundred apps that are all running a managed database, and you think that they're running off one template, but you actually find what's happened is your org has taken that template, subtly tweaked it, put it into source control, and adopted it as their own. And if you need to make a change and thought, well, we'll just go and update the template and that will have the trickle down effect, it no longer does. And so you've really got to make sure that that knowledge is syndicated. The downside is obviously because it is so easy to change, you've got to have some controls in place or ways of getting that knowledge spread across the org that is operating at that same pace, Mainly because I think it's about that innovation piece again, that modern software teams, if you've set up everything we're talking about here, you can really let them solve problems rather than saying, here's the solution, just bodge around within these parameters, which will give you a far better customer experience. To that extent, we actually integrated CutOver with Service Catalog so that if you wanted to consume pre approved templates or Lego bricks, they could be used. If you needed to do things before you use that template, might still need to get approval or get a solution architect to have a look at should you be combining those services together. Then using Service Catalog to launch it, and then doing the post tasks within a cutover runbook for what you've just launched, or maybe just reminding yourself to turn it off, can be as simple as that. It's about that self-service that AWS service catalog enables. I totally agree with you. Great, yeah, and I guess that's a really nice point to kind of talk a bit more in detail about cloud operations, right? It's come up through this conversation. But sort of looking at cloud operations perhaps more holistically, how should you address cloud operations? I would say that it's similar from the essence of service management. You have to understand the intersection of your people, your operational processes, and tooling that supports your cloud workloads. At the end of the day, identifying those stakeholders, the third party or the vendor or the technical dependencies, and understanding who's gonna support those workloads, even at three AM. You know? I used to run game day scenarios with customers to make sure as they were moving cloud workloads to production, they knew who who who would you call at three AM. And AWS, we continue to invest, in our product suite called management and governance that has over seventeen plus services that enable customers to establish that right level of control in their environment without slowing down. So our services such as AWS CloudTrail or Config or CloudFormation give you the ability to do those preventative detective controls along with service catalog and app registry, and even our new control tower service, give you that ability to help set up the foundation, the ability to enable provision and operate your services. Yeah, fantastic. And with that, like how do you encourage people to keep innovating once their application is running in the cloud rather than just saying that as right, we're in the cloud, we're done? Yeah, so first of all, it's the mindset. For example, the AWS and Amazonian culture is to always iterate. What we release initially is considered a minimum viable product or even an enterprise viable, depending on what that service may be. And so it's changing the mindset that once something is launched, it's the beginning. It's always day one, continue to improving those services. So what I would encourage customers to do is implement mechanisms, incentives, like I discussed earlier, and goals that incorporate continual service improvement that aligns to standards or IT service management standards. Get end users feedback on those applications to learn what is needed to improve so that you're working on the right things instead of what you're assuming customers need. And that's the same culture that AWS does. Over ninety percent of our features are based on what customers say are important to us. So get that feedback chain and that cycle to build those roadmaps to continually improve your services. And you may find out that an application is no longer warranted, but they need a different type of application. And that's okay, but you're always providing your consumer, your end user, what you need. So that's how I would recommend people to keep innovating. I'd echo that one as well. I think it plays back a little bit to the conversation we're having earlier about skills and how to have some of the softer skills that people need. So I think having people who are curious, who are adaptable, who are agile, are customer centric, you have that kind of innovation mindset is super important. And like you said, incentivizing them in the right way, gathering the right data, the right feedback from end users. Think also there's something around creating the right opportunities for people to innovate. So creating those moments where people come together, perhaps cross teams, they share that end user data, and there's a point at which they are sort of jointly driving improvements, as well as at the individual level. Yeah. I think that that's that's really true. Right? And I think from from what I've seen, folk continue keeping that focus on the user's problem and making sure that you're using that as a a real drive to innovate with those curious people is really key. One other thing that I guess you might kind of think, like, we've got fairly fixed costs in sort of data center world. We've now moved to the cloud. How do you stop costs running out of control in that environment where it's a lot less of a fixed thing, it's a much more elastic thing? Okay. So one, I think that customers should take ownership of recognizing the variation in costs, right? And first let's start with developing a tagging strategy that identifies who owns the resources and who to charge those resources back to. And that tagging is very, very important because it allows you to bundle up to leadership who's doing what, what are the purposes of those services, and identify areas that may need to be improved. Adopting the use of templates, infrastructure as code, like we've stated before, to set those guardrails, not only for security and curated architectures, but also consider costs for that. Enabling mechanisms to turn on and off resources such as certain scripts based on their uses in a given environment. And as everyone knows, cloud is pay as you use or you're consumption based. And think about it just similar to how at night at home, if you leave a light on, the utility companies will charge you. And that's the same thing that we would do as well. So create those mechanisms where things that are not needed, fit for use, fit for purpose, fit for being on based on that purpose. Setting budgets also in addition to your tagging and templates and technical scripts to notify you when resources get to a certain threshold. And it may be that we need to evaluate cost of things that are viable and are needed, but we also may need to identify where we're overusing things and can cut those costs. One example that a financial customer that I worked with did was they educated their engineers on the cost of AWS, different resources and the types of resources and learning about the consumption model. And so by educating those engineers, they also implemented goals and mechanisms to create incentives to keep the cost at certain levels. And so I call those cost conscious engineers. So if you train your engineers about what it will cost, then you may have effective, usage in the workloads that they're designing. And I just can't emphasize enough of giving incentives for engineers to not just create something and keep it on in production, but also to improve it, not only architecturally, but also for cost. Yeah, and I guess that probably ties a little bit to this question, but how do you do that kind of cost control piece without hampering innovation? I say that if you build a repeatable mechanism across your organization that accounts for designing, deploying in operations of workloads. And you set that up through consistent delivery, enabling self-service. Once you establish that agile governance, then the builders can focus on what? Innovation. Because they already have the guardrails in place. They know the parameters that they can work within. And so setting that up is key to help the pace of innovation continue because the builders aren't trying to figure out what policies, what procedures, what's allowed, what's not allowed. They're just able to focus on innovation. Yeah, I think one of the things I've seen there, Missonia, is making sure that tagging, as you mentioned, is consumable to all areas of the business and not just development. Ideally, if you could get the developers to make it automatic so the guardrails can't be circumvented or crafting really great service control policies, but those things can be hard. Some of the reasons we've integrated with cloud services within CutOver was to make those areas more consumable by other areas of the business, because it's not just engineers that can suddenly move at this cloud speed. Everybody can innovate safely. You might find that somebody can spin up some of the new services that are available within AWS if they have the ability and can suddenly do some learning. Tools like AWS Glue might be able to do some simple workloads for people. And we want everybody to be able to operate at the speed of the cloud. And from an engineering point of view and from a cost point of view, it should be as exciting and as predictable as turning off a light switch, as you say. Unfortunately today it quite often isn't, and everybody thinks you need to get an engineering team and an operations team involved, but perhaps you don't have to with a shift of mindset and some bold leadership. Fantastic, well thanks very much, Missonia and Kieran, on that one. We've talked a lot about the, I guess, the pace at which things move, right? And I guess tied into that, what service would you say you're most excited about at the moment, Missonia? Okay. Well, I'm excited about a whole suite of products, right? And hope you allow me to just give a couple seconds about why I'm so The management and governance services such as CloudWatch, Config, Systems Manager, Service Catalog, AppRegistry and Control Tower, and even the marketplace. And the reason I'm excited is because they play a critical role in enabling customers to balance innovation and their control mechanisms. And of course, I'm very excited about our AWS service management connectors for ServiceNow and Elastic Jira Service Management, because these interoperable solutions meet customers where they are in their systems management tools that are normally declared their systems of records to provision, manage, and operate native AWS services and resources. Now, in terms of the buzzy types of services that I'm getting a lot of feedback, as well as the team that I'm on, are for our customers. Services such as ECS Fargate, which is a container service, as well as a machine learning service, such as SageMaker, are common services that our customers are providing us feedback and wanting to learn more, and how can they implement governance and control as their users are using those services. Fantastic, thanks so much, Missonia. I knew I wouldn't be able to tie you down to just one service there. No. That's fantastic. Thanks very much. Thanks very much, Sonia, Sam, and Kieran for that. It's really, it's been really interesting to have covered, you know, technology with AWS, Cultural, with Deloitte, and the process parts of that ongoing cloud journey with CarServer. And I think the overlap there has been really interesting to see, and the collaboration has been fantastic. Thanks very much for joining us today and to our audience. We really appreciate your time and trust you've enjoyed listening to this discussion. Now, if this topic sparked any questions or you want to find out how CutOver, AWS and Deloitte can help you and your organization make your cloud operations better, please do not hesitate to email us at newscutover dot com or reach out to us on LinkedIn. Thank you very much for watching, bye. And thank you very much, Nick, and thanks to all for a lively discussion and great information. That is all the time we have in this on demand webcast. To access additional information on our topic, Cloud Operations and Governance, please see the resources area of your ON24 webcast player. And thanks for joining us. For Cutover and IDG, this is Stan Gibson speaking.