August 15, 2023
Season 1, Episode 24
In this episode of Cloud Unplugged, Jay welcomes Steven and Nick to discuss their experiences and insights into cloud adoption. Both guests share their backgrounds, the challenges they’ve faced, and the importance of culture and collaboration in successful cloud implementation.
Guest Introduction: Nicholas Chang & Steve Nicholl
Nicholas Chang and Steve Nicholl, both esteemed professionals from Kainos, join the Cloud Unplugged podcast to share their profound insights into cloud adoption. With their extensive experience in the field, they bring a wealth of knowledge about the challenges and intricacies of navigating the cloud landscape. Their backgrounds encompass a deep understanding of user needs, the process of discovery, and the challenges of translating high-level visions into actionable tasks.
In this episode, you will learn:
Themes covered in the podcast:
Quick Takeaways:
Follow for more:
Jon Shanks: LinkedIn
Jay Keshur: LinkedIn
Jon & Jay’s startup: Appvia
[00:00:15] Jay: Hi, Steven. Nick. Welcome to Cloud and Plug. It’ll be great to obviously get a bit of an introduction from both of you. I don’t know, Steve, if you wanna give a bit of an intro to your background and what you’ve been up to and how you got into this domain and then obviously I’ll ask Nick to
[00:00:32] Steve: Yes, sure. John, I think first thanks for having us. Um, I’m Steve Nichol. I’m an azure solution architect. Essentially, um, it’s not very much hands on, but my role is in the solution. Architect, Um, I’ve been working with Azure for 7.5 years now, I guess just as a bit of an overview of the technology I’ve been working on my very first a year delivery was using for machine skill sets that were automating delivery of IIS websites. Um, and from there, I’ve kind of gone through the kind of the cloud native space done a lot of work for a number of years. Um, with and now I kind of focus very much on the cloud adoption framework and enterprise scale and exams, and that’s the client that I’m currently working with. I’ve been with for over two years and that we’re focused on. The last six months have been about enterprise scale. That’s kind of where I am now.
[00:01:16] Jay: Oh, cool. Interesting. And, uh, yourself Nick.
[00:01:19] Nicholas: OK, so I’m currently a platform engineer for money for, like, a Microsoft partner called. This is based in Belfast and we work with Macs, soft AWS and Google. So I’m some I work with a on a daily basis. So my last azure project was moving from a KS to app service migration. And this, my current one now is just migration from Jenkins to give actions. And then my next project will be able to go into creative solution like a KS. Right.
[00:01:53] Jay: So you’re both at. Yeah,
[00:01:55] Nicholas: so But we both I met Stephen. Ken. Oh,
[00:01:58] Jay: cool. And so you’re working. What in customers? Different types of customers. Yeah, different type of projects and working on different types of projects. But you’re both primarily in, like, the platform engineering space. You or like cloud space. Specifically, you’re both platform engineers. You’re more of a platform architect. I think that you were kind of saying
[00:02:16] Steve: I am the John, but when I started, it was very much an engineer and a couple of promotions later. Now I’m kind of kind of more of a solution architect than an engineer, although on the current project I am writing code on a daily basis, because sometimes we need to, Um, it’s one of the things that we’re kind of we pride ourselves on is that our tax are still practitioners. So that’s kind of why I’m still hands on sometimes.
[00:02:37] Jay: And yourself, Nick, are you yours? Do you get into the solution Architecture store? Are you like engineering? No,
[00:02:42] Nicholas: I’m just fully hands on. So, yeah, how it works at is that he’s a platform engineer, senior platform engineer. And then there’s a technical specialist. And then there will be a solution after that, which does the the high level design, right? And then we just do the hands on and stuff. So I wanted to stay more technical,
[00:02:58] Jay: so that’s cool. And then how have you both got into car? Because you mentioned Steve. You were IS website hosting. Was that your entry into it? Or before?
[00:03:10] Steve: It was my entry in the cloud. Yeah, so that started. That was almost the first thing I did when I joined K OS, But prior to joining KO, I had been a second line support team lead very much a window system admin. You just, you know, administrating a a DC solutions. Um, the electronic document system. I was my kind of my team was responsible for that. My left joined KO as an engineer and got in the cloud from there. It’s kind of a necessity. I guess it was what I needed to do at that point in time so I can learn from grind up, which was It’s been an interesting journey.
[00:03:39] Jay: Yeah, And do you find, then, both of you? I mean, this is kind of the both of you, I guess, from going from like IIS, which is like, but especially 7.5 years ago, the services were quite diminished to like, 7.5 years later. I mean, even now, going forward Like, how do you both keep up with all of the cloud? Especially if you’re kind of multi cloud as well as Cano is. How are you finding that on the rapid growth of cloud and how you’re keeping up with cloud native space and then the cloud space and technologies and everything else
[00:04:08] Nicholas: so I can answer that. So that’s quite scary, because so how I normally keep up with that is I use social network. So I use networking with other people, go to events, and then I kind of quite active within the outside cloud community. So I normally speak up user group and things. So I try to see what’s the latest tech or go on the road map. Like what? Steven said, Whether it’s a road map on landing zone. So have a look at the Roma you bought the next few
[00:04:38] Steve: years, So I guess I can. I just on top of what’s kind of next to the the other thing for us, I suppose, is that as a partner, a Microsoft partner, we get the opportunity to get involved in those beats, and sometimes you get a lot from those we can keep up to date with what’s happening through that as well, because we know obviously before it’s even become public, that that something’s occurring. A really good example of that was the well architected framework and the that’s available there now on the Microsoft website around well, architected, a colleague and I were involved in one of the groups that actually was helping Microsoft shape that product a few years back. Um, so you can get an insight on where things are going. Um, when you get involved in those groups as a partner
[00:05:17] Jay: and now you see that? I guess not. Just I guess if you’re being more solution, architectural, then you’re a bit more business requirement driven, I guess at the top, as in like what you’re actually trying to do. Some of the well architected framework, like the CF stuff, et cetera, is quite it tries to bridge like operating models into kind of like design of the cloud into kind of then the architectural element and then into then kind of implementation. I don’t know how both of you from a doing execution on it all, and then also from a a customer, even understanding caf and like what it all means and how they’re going to operate. Because I think what I’ve seen is, even after you’ve read it all, it’s kind of detailed but also abstract and high level at the same time, So do do you find it does do people even understand it properly. Are people kind of aware of like what it actually all means when you talk about the activity framework?
[00:06:12] Steve: I think when you give them a high level of review, yes, most people get it. I think the hardest part for me is when an organisation is going down the cloud adoption framework route and they’re trying to adopt. The hardest thing for me is culture, because the culture within organisations can paralyse any attempt, you know, to get into this space and this platform engineering space. And I think you need to be able to create a culture where people feel safe, that they can make mistakes and sometimes it’s quite difficult in large organisations when you go in to help them with this. You know, with kind of traditional mindsets that everything is waterfall and has to be correct the first time you need to let people learn and feel fast and that’s how you’re really going to get on in the cloud space. That’s the hardest part for me, a lot of the technical stuff around it now Microsoft have done a lot of work to make it much easier. They have to find a price landing scale and a price landing zone repository there, which does a lot of your landing zone foundational build out. You just need to learn how to consume it correctly, and from there, I guess it’s an operating model where you need to just work with customers and try to encourage them, I guess, to embrace the culture of, you know, let’s work fast here, but in the process of working fast, we know we’re gonna make mistakes, But we’ll fix it. People will learn, and over time, you know, it’s it’s kind of go slow to go fast, really. You know, if you don’t give people that chance to go slow, then you’re never going to get velocity out of what you’re trying to achieve in the end.
[00:07:26] Nicholas: So I echo what Stephen said, but people can normally learn it from, like whether we’re having a set sandbox environment with multi subscription for test subscription and then deploy like landing zone for terraform, and you can just see and how overview how it works.
[00:07:41] Jay: Yeah, do you think the detail of like I mean this is just my observation? But from the SDLC perspective, like software delivery, life cycle, or development life cycle, you know, call it. There’s so many aspects in relation to that a little bit more tangible. The landing zone is way more operational, I would say, but it’s still kind of technical. But the way that it’s phrased and framed is much more like you were saying. How do you reduce the risk of iteration? But put guardrails over things and you kind of have, like the tenants and the subscriptions and resource groups and all these other obviously nested elements that are surrounding it. Which means the reason you’re choosing those things is because of the design you’re aiming for in your business. Like you know why. You’re kind of isolating things is to to protect from change and things like that and obviously non production production. But it’s quite abstract because it isn’t related to an app. It’s related more to the business, so I don’t know how you find it. Then I guess maybe this is more for you, Nick. How have you found implementing it when it’s got to the application and then the Dev team kind of understanding and using it when you’ve kind of implement, You know, when you started to do the the changes.
[00:08:50] Nicholas: Well, I haven’t implemented it yet, so my best bet would be like looking at the high level design first and then work out like whether it linked to another, like tenant, where multi tenant stuff and then still break it down as well and then test those breakdown whether it’s linked correctly. So that’s how I will link it.
[00:09:09] Steve: Yeah, so I think I found it, OK, I don’t think it causes any issues when done with, uh, done with an approach of trying to give autonomy to developers and the operational teams. I think it’s fine. It works. I think the important thing with the enterprise scale is that you don’t put too many restrictions in place that are unnecessary. I think that you said John, it’s important guard Ras, you know, like if you’re in the online zone, you must have a half your you know, traffic must traverse an ID PS device. It must have some sort of D dos protection in there, those types of policies and things that stop people from doing things that could be damaging. You can’t put an APP service out there with a public IP address with no protection in front of it. You know those kind of policy objects? You You’re putting them in place to help people not effectively damage what they’re trying to do. But at the same time, you’re then sent to them. These guard wheels are in place and down in your subscription. You’ve got free rein to do whatever you need to do because we have the important guard wheels. So things that are really going to cause us issues. If you do it, we’ve got those guard wheels in place to prevent you from doing it. I think it’s a really good balance because it gives that governance, Um, but it also enables people on the ground to be able to work because they don’t have to come and ask centrally for everything they need. I mean, we’re trying with that decentralised model of local autonomy, they can build what they want in their space, provided that complies with sensible governance.
[00:10:24] Jay: And who do you see then? Putting those guard rails in place, I guess, is that how do you collaborate on? Because there’s obviously top level guard, like some of the things you mentioned could be organisational policies. Some could be kind of application centric policies like Who do you see being the people that define them and then instantiate them? And then who’s accountable for them?
[00:10:44] Steve: It’s got to be a broad range of people. It can’t just be the office of the CIO. The people who are going to consume this have to have a chance to put their opinion across. Um, you need to understand what’s going to happen on the ground and know how people actually operate and what you’re looking to implement. And, yes, there are going to be guard rails that people maybe will not have the ability to change. You know, you might have something like your production network can never talk to your non fraud network. That could be a guard deal that’s in place. That’s not negotiable. And that’s there are certain things like that that might have to just be implemented from either the security teams or the office of the CIO, wherever that may be. But for it to work, you really need to have the buy in of the people who are going to be consuming it, and you have to make sure that you’ve given them the ability to do their jobs without being blocked.
[00:11:25] Jay: And do you think, think that? I guess this is maybe one for Nick as well, like as a platform engineer, like working on the like, working on the implementation. This is just obviously a bit of a randomised question, but do you think platform engineers should be guard railed, or should they also have free reign? To do things
[00:11:42] Nicholas: well, you should be able to, like, get do what you’re assigned to, like following the best practise. So, like where you are assigned to only do specific jobs, and you do that in other permission. You need it. You get someone from like a senior engineer platform engineer do those additional permissions.
[00:11:58] Jay: So you think it’s OK. It’s It’s fine them for the different levels of like Maybe you’ve got levels of platform engineering capability. Some people are maybe more experienced than others. Like Guard rail.
[00:12:09] Nicholas: There’s no like one project for landing zone. We work with different teams like security and an architect solution and stuff. There’s no one project, so we collaborate with different teams.
[00:12:20] Jay: Yeah, because I guess the aim of the when you work with customers, then even implementation perspective. Are you inside the teams or are you like Central in the business? I guess each business will differ for Cano, isn’t it? So whatever company you’re working for that might be designed differently. Do you have a preferred mode, though, Where you say we provide central capability or do you not really
[00:12:41] Nicholas: care? No, we don’t because they would be a separate person that eels with the clients and what what they will. And then that will ela with the solution. After that, that does the high level. And then we do technical architect that break it down. And we just do this like, go to scrum meeting. And it’s how we can fix those things. And we’ll find those tickets and just do it.
[00:13:02] Jay: Yeah, So when you’re working with a customer and Steve, do you prefer to do like, do you try and sell them on the benefits of platform engineering and Centricity? I guess. How are you in terms of like the operating model and that you want them to adopt in relation to the landing zone around it? You always have different models and different ways of working and operating. Do you try and promote, like a central engineering, solve the problems centrally for many teams embedded like How do you design
[00:13:29] Steve: them? I think there’s generally always going to be some form of central platform engineering, and someone has to implement the guard rails. And there has to be a process in place there that that allows the kind of the autonomy. So for me, I like a bit of a hybrid. I like that platform engineering space in the middle. But in my opinion, it should be limited in its scope to what it does, because ultimately the real benefit that comes from a business is what they deliver as a product, and that happens down with the engineer. So the central model sometimes, especially when you’re adopting cloud if you bring a centralised model in, can become a bit of a blocker and when you’re kind of just starting to build capabilities, if you start to build the capability and that capability grows with a centralised model and the satellite model doesn’t actually grow with that capability or with that with the capacity of the other teams, then you find yourself in a position where you could have the central team being the team that’s slowing everybody else down, and that’s when the autonomy becomes really important. And we’ve got that platform engineering team potentially in the centre who are helping to advise on best practise who are potentially maintaining the policies and the the kind of some of the guard reals in the policy. Maybe in an enterprise scenario, you still have to have some form of AD M That’s cloud compatible, but you might have some form of a platform engineering capability if you need to maintain that for the security of the business, rather than letting the developers in the platform engineers down on the projects, change and do whatever they want. But I think it’s really important to enable people to make changes to that infrastructure as well. So the likes of when we build our infrastructure code and we build it with pipelines, we can delegate the ability to add a firewall rule, for example, down to net or whoever it might be an actual team, and it might just be that the platform engineering team have a responsibility to ensure that that rule doesn’t get through the PR process. if it’s doing something potentially damaging, that’s kind of the role that, in my opinion, I kind of see the platform engineering in that kind of Federated autonomy space. They provide a level of kind of just assurance, not control, because sometimes when people think they’re being controlled, they don’t like it. It’s just a level of assurance to say that you’ve got a group of people here who are going to make sure that you’re changing the firewall. For example. You’re not gonna do anything that’s gonna break your team, John. You know, Nick doesn’t make a change to the firewall and takes your app offline, you know? So that kind of piece is quite important.
[00:15:42] Jay: Yeah, So I mean, there’s been quite a lot of I guess I’ve maybe jump gone a bit with the platform, because obviously one of the interesting things I think at the moment is because there was platforms historically years ago, then it was it kind of diminished a bit where, you know, because you had, like, the open shift in the large kind of platforms like Cloud Foundry, and then there’s kind of like Karo rise and all these other things. Then It was kind of frowned upon because they were normally like giant monolith. They very prescribed ways of working. And then it was more about tools. And people felt like tools is better because more flexibility you choose the tools. Then I think that’s expanded to like there’s just so many tools. The CNCF landscape is obviously crazy, right? So there’s, like 8 million choices, 8 million different things, and the cloud vendors have got 8 million different choices, all kind of the same, but kind of slightly different. Then platforms come back again. So those that I actually know we do need platform engineering. So I’d be curious the like. What do you define as being platform like, What would you say A platform really is? And then what’s your view on this? There’s a a rise called platform as product, and I think that’s kind of come out on like Team Topo and people looking at the door of metrics and actually treating what you do is like platform engineers as designing something for an end user, which might be the developer in relation to the business and treating it more like product ways of working and product methodologies don’t know if you’re, I guess open to both of you to kind of answer what your opinions are on. What is a platform, and what do you think about platform as a product? Principles.
[00:17:08] Nicholas: I’ve heard about platform as a product, but I think most the cloud native will be leaning towards that like Plad service and stuff. It’s like the majority of AWS is pretty much like pads now, So unless you do some and stuff, but then that’s back in the days like the Steve. So everything, I think it will be like platform as a product. So one solution. Make it scalable like as your container apps. That will be a platform as a product as well. I think so you can scale. You can maintain it as well.
[00:17:38] Jay: Yeah, I think they’re calling it. I guess. Then the platform T when you’re engineering stuff because it’s quite an overused term platform because, like some business app kind of think I said this before in previous episode. But some business app see themselves as a platform because they’re providing like a banking platform. You might have a retail platform like Shopify right or there’s like So the term platform is quite it’s kind of over you, so you might see platform engineers, but they could actually technically be working on a platform that’s different to what we perceive a platform business. There is that kind of nuance on what actually is a platform, is it? The cloud you know, is the cloud end of the platform. Is there some other abstraction in front of the cloud? And it’s a different platform that people are building, like What does it all mean in the industry? When people talk about platform engineering,
[00:18:23] Nicholas: I think it’s probably just deliver solutions like whatever, like an app to a client like using provider like from Mao.
[00:18:32] Steve: Yeah, so for me, platforms, quite it’s a bit broader than just the infrastructure, and I kind of look at platform engineering in a sense that the platform engineer is there to enable the development of whatever product has to come to market. So it’s not just the infrastructure. It’s the C I CD pipelines that support the DLC. It’s about making sure that you know developers have a platform where they can get fast feedback. They can get accurate feedback. It’s the whole kind of observable of platform as a whole, both across infrastructure and ultimately the the software that runs on it. So I think for me, platform engineers have quite a large role to play across that that breadth of technology. It’s not just here, like there’s an IKS service or your service spun out for you. Go ahead and build your stuff. You know the platform engineer might help with the you know, the help in charge. The customised configurations put installing your get up agents, configuring all that. Do you want to service mesh? Well, the platform are potentially going to help with that. So I think platform engineering is quite broad for me, and it doesn’t just include spin out the underground infrastructure. It’s also all the supporting pieces around it and the audience of that.
[00:19:35] Jay: Who do you think like the end customer? The end consumer for a platform engineer kind of is because, obviously, from you know, it just kind of what Nick’s mentioned around. Even like some of the confusion right, The cloud vendors have past services, their platform service. You’ve now got platform engineering as a industry, and then you’ve also got like Dev ops embedded Dev ops. Which is how can I actually help this team get into the cloud and what you’re then talking about Steve is like you’ve really got customers and those customers are like You’ve got end users and you’re trying to facilitate a bunch of end users in relation to the business goals. And you’re there to try and work out. What part of the SSDLC the decisions is a platform team making on behalf of them to help them move faster.
[00:20:18] Steve: It’s also the kind of larger aspect of it is is making sure that everything’s in place for people to deliver quickly so that, you know, that might be, uh, let’s take, I don’t know, give examples or devs as a chosen C I CD to, you know, making sure that’s properly configured, that you have good practise in place or people can’t preach to me. You’ve got to pull request processes. You’ve got to have the correct pros in place, but also that you’ve got the fast feedback in feature branches that developers can. They can find out really quickly what’s breaking or what’s wrong with the code, because ultimately, for for especially in and in some because we do quite a lot, Um in terms of, you know, consulting from just maybe two or three people helping with a bit of platform engineering here there. Or we will We can also do traditionally Software House. So we will also potentially put large teams in the organisations and we’ll do everything. We’ll build their software. We’ll build their platform in that scenario. And for us, the platform engineers’ job is to enable the developers. And that means doing everything for to enable the developers so that they can hit the ground running and start building out the product quickly. Because ultimately that’s what the customer wants. The customer doesn’t want to have four weeks of 456 weeks of spending out an environment where the developers can be productive. They want to be productive from day one. And that’s where the platform engineering piece comes into it for me.
[00:21:32] Nicholas: Yeah, because I normally work with developers anyway. So if developers want anything like secret change keyboard, I normally do it. So essentially I’m part of developers as well. So they’re part of us. They work as one team.
[00:21:44] Jay: Yeah. So you’re focused more on the enablement side, I guess on, like finding out, like implementing what it is they need and seeing if it’s worked for them, I guess. Are you then assessing feedback for yourself in relation to those teams, like did? What I do did is what I’ve just done actually helping and is it working? And so even with some of the services you mentioned obviously got you mentioned a KS there like Cuban eighties. You can’t just be like here, Cuban eight. Go knock yourselves out. Good luck. Just let me know when you have a problem. What do you see there, then, on businesses and yourselves, I guess from engineers the amount of work ancillary to just a KS. Is it high now? Do you think it’s reduced? Do you still think there’s a lot of like time bound activities for platform engineers in that space?
[00:22:30] Steve: It’s probably a lot easier today than it was five years ago to maintain a cluster and that kind of example, you used John, especially when we’re looking at the platform services that are available in the on AWS with a KS and a KS. You know, it takes a lot of the hard, heavy lifting away from actually spending it out in the first place. But there’s still a lot of maintaining to do in those in those clusters. And I think the important thing is you got to ask yourself the question is whether or not it’s it’s worth it. Um, because we went through a phase a phase and somewhat are still were, you know, Ktis was flavour of the month and everybody wanted ktis. But not everyone needs ktis. You know, Are you causing yourself an operational headache and putting a large noose around your neck Just because you want? Because someone has said you should use TTI? You know there are other services out there that will that will do the same thing. And if you don’t need the scale that TTI can scale to, then you know some of those other services are sometimes a better option. The next mention Container apps. There’s obviously you’ve got to use your APP service there as well, which can run on containers. They can interact with each other in the in the same way as services can. If they were running a You know, you’ve got the same protections from an inbound Internet perspective, you’re using different technology. So I guess the question for platform engineers is cobert is always the right choice and not isn’t always necessarily the right choice. There’s a lot of use cases out there where you where now you could potentially get away without using it. You know, I know. Five years ago, Ktis was giving people a lot of benefits and flexibility that you wouldn’t have got from other services. But the cloud vendors have caught up with the other services, and it’s not necessarily always the correct choice now, in my opinion, um, people might disagree with me with that, but there’s a lot of work goes into maintaining a kite cluster. Um, it’s not just easy. And I think sometimes people miss the operational overhead that comes with the kite cluster. Um, because they get lost and they Oh, look at all these cool features.
[00:24:17] Jay: Yeah, I think I guess it’s interesting to hear you both kind of say that, because I think the bit that the platform engineers do is a bridging from a purist development perspective. I think there are lots of valuable services out there architecturally, and I think there may be like a event driven architectures right there are, like, even maybe better architectural principles. From a development perspective. I think the Catch 22 sometimes is when you’ve got such a variety, then to standardise on different ways of implementing in the cloud is the bit. That’s tricky because suddenly I’ve gone from having an agent that was, like, deployed via helm. That basically was a demon set that was collecting all the things that actually got a load of stuff away. And now all of a sudden, I don’t have that because I’ve got Native Cloud Service and it then pumps it to you know, whether it’s going to be azure monitor or wherever else it’s going right. So now you’re like, OK, somehow I Now I now the way of working is different to the developer, as it was maybe somewhere else. So how do I give the same experience to a different flavour of something so I can kind of see why people, even though it might not be the right thing, really, and it probably isn’t There are probably better application centric stuff out there than just keeping eighties. I can kind of understand the stitching together of the experience for a developer being quite an attractive proposition to standardise on, even if it’s conflicting, potentially with, like, better outcomes that you could drive more, simply elsewhere. So, yeah, I guess. What do you do in the situation where you’re diversifying? You know, because the because integration is really the most of the platform engineer job is like It’s the integration, isn’t it? You’re there to start to do the integration, and now the integration, then points keep altering. You kind of caught between a rock and a hard place on doing the right thing. But having to work around now what it means.
[00:26:08] Steve: Yeah, and I think it’s It can sound a bit of a tooting choice, I guess. In that example, you’ve given there particularly around observable. So if we take an example when we’re containerizing app when you choose to use application insights, for example, as the primary kind of platform for observing what’s happening in the application, it doesn’t really matter if it’s running in or it’s running in an in an APP service or it’s running in a container instance or running in a container service. If application insights is your central point, then, then I guess you’re enabling yourself to have that flexibility to choose what flavour of platform you want to run that particular container on. For example, I think that’s where the platform where sometimes I think people shoot themselves on the food a little bit when they they try to not embed themselves in the cloud platform that they’ve chosen and they’ll say we’ll use something else. You know, we’ll use a different service for creating our observ of this application or these these suite of applications because we don’t want to be tied to this cloud platform. It’s a personal opinion of mine, and I might maybe well be wrong. But I kind of a believer in If you choose a platform and invest in the platform, why would you want to spin out some other form of service that you’ve got to manage and maintain? If your cloud platform already gives you that functionality by just consuming another service, you’re not gonna move your service into a cloud platform and then move it again in six months time, generally speaking, so the effort required to move it later is probably less than if you’ve run it there for five years, have had to maintain some other service, some other group of services to provide you with without observ framework. So I think that’s quite important in platform engineering as well. Is building in that flexibility and your decisions? Yeah,
[00:27:41] Nicholas: Most of those are based on the client requirements, whether they want it to stay on the or using AWS or on Prime and Data Centre. Then most of those are just requirements, whether they how they choose to use contain a K instead of other container options as well. So
[00:27:58] Jay: yeah, So I guess then what you’re saying is, you know customers will be driving the requirements anyway then, sometimes by trying to find solutions that the cloud already gives you, you kind of create more complexity for yourself. And I do kind of agree with that. Just sometimes the cloud vendors feature set can be slower because they’ve got, like, 8 million services rather than a vendor, that we just decided to just do one. So I mean so I can’t see. Sometimes it could be just history. They chose a thing before the cloud vendor had that solutions, or it was a little bit too early to go to go native, but then it does create complexity. But I
[00:28:36] Steve: think what you’ve said there is actually a really interesting point. And I think it’s something that I always keep in mind when I’m working with customers with people is that cloud platforms are evolving so quickly that you know what might have been the correct decision three months ago with the information that was available. Make that decision now with the same information that’s available. And actually, there’s a different service that might be a better answer for your problem you had three months ago. So it’s quite important to keep an open mind when you’re looking at solutions that have been built in the cloud. Because, as you said, John, they’re evolving at such a rate. The features that might not have been there, whatever the person made the decision. But now it is, and it’s quite it can be challenging sometimes, especially when you’re kind of working with a customer and you know that they would really benefit from a particular platform service, but it just doesn’t do the one thing that they really, really need. But you know that the benefit of having that provided for you would be massive. And then three weeks later, somebody announces that there’s Oh, here’s a preview for this feature that you need it And then you’re in this position three months later that the feature that would have allowed you to choose that product is not available. But it’s too late, potentially so. Yeah, it’s quite it can be a very challenging environment to work in in that regard.
[00:29:40] Jay: Yeah, Like I said, I don’t think there’s like there’s so many ways to skin the cows and there there’s like you can solve the same problem. Using different technologies, you can reinvent the wheel. You can use cloud services. You can be agnostic to the cloud if you’ve got more than there’s quite a lot of consideration. I guess that there in lazy essence, obviously platform engineering is because there’s so many considerations all the time that you’ve got to engineer something. It’s just what you’re kind of doing. I know we’re kind of close on time now. I don’t suppose it’d be good to probably you got any advice for people, Maybe yourself, Nick, from like people getting into platform engineering. Where to start, Where to begin, Where to look like how to kind of upskill if people are interested in it or wanting to kind of take a career in it.
[00:30:22] Nicholas: OK, so I normally start by just pretty much hands on. Really? Because I live by doing. I was a self learner, so I do like projects like Self Learning Project. So I would advise people to, you know, get hands on like that Time was to a sandbox. And then neither can do some certificate fundamental to get fund standard. But also learn some of the the core fundamental. Whether it if you want to go into a K, maybe learn Linux or something like Linux, come to your air and stuff. So I recommend those as well. Did you
[00:30:56] Jay: do official courses, or did you just do
[00:30:59] Nicholas: well? I was how I get started that I kind of, I guess, floated by self learning. Do certification Do online project, and then I would. I met someone that’s in the company like someone called Thomas and then do networking as in on social media. And then that’s how I get Start and then I get started in. But they have a academy, a platform academy. And then that’s where you want. Learn some of the skills, like improve on terraform, improve some a ws azure, something about gates and, um, and a KS and things you learn some of the fundamental there, but then you still have to learn the fundamental, but the fundamental you’d gain by doing certification and hands on in your spare time.
[00:31:40] Jay: Yeah, that’s very good advice. And then for for both of you, how would they find each of you like, is there a place? Somebody listened and wanted to get in touch because they strongly disagreed with your opinion, Steve, I don’t know. I’m joking. Is there a way we can find you?
[00:31:56] Nicholas: So we’re both on LinkedIn and Twitter so you can find me on. I think you got a new so you send to my twitter, so I’m both. You can search my name on LinkedIn and you can see my picture there. And I’m also on quite active on Twitter. So it’s on a cloud, app and stuff, and then
[00:32:15] Jay: we can all can probably post them in the thing. And then I guess you are on Are you on Twitter as well. And
[00:32:21] Steve: I am John. Yeah, so I think my Twitter name Julie Original underscore. Steven. I’m also on LinkedIn. And let me find me on there too.
[00:32:28] Jay: All right. Well, it’s been fantastic. And you both on there. And then if anybody wants to kind of pick your brains and some of the things you said, they kind of know where to hit you out. But thanks for joining and talking about your experiences.
[00:32:39] Steve: Thank you. Thanks for much. Thank you.
[00:32:41] Nicholas: Thanks for having us. Thank you.
Part of the Appvia family.