Benefits of Infrastructure as Code

In this conversation, Peter Filitz interviews Connor Morrison, one of BCN’s Señor Cloud Services Architects who explains his work, predominantly with Azure cloud resources and collaborating with developers to build solutions. 

As Connor explains, infrastructure as code refers to the provisioning of infrastructure through code, allowing businesses to apply this concept practically. The pair discuss the benefits of infrastructure as code and how it brings value to businesses, by allowing developers to configure the resources they need to run on a server, eliminating the need for manual deployment. 

Conor highlights the use of templates to standardise the deployment process and ensure consistency and explains how this approach increases efficiency, reduces human error, and improves security, a genuine game-changer for businesses, allowing them to deploy infrastructure quickly and control versions and compliance. 

BCN capacity to manage and deploy entire estates and environments in a matter of hours rather than weeks can save business time, stress and money.

Find out more at https://bcn.co.uk/

Key Takeaways

The Benefits of Infrastructure as Code: 

Infrastructure as Code enables the provisioning of infrastructure through code. This approach streamlines processes, making them more efficient and less prone to error compared to manual deployment methods.

Collaboration Between Developers and Cloud Architects: 

Synergy between cloud architects and developers in leveraging cloud resources effectively is essential

Standardisation through Templates: 

Templates standardise the deployment process, ensuring consistency across deployments and making it easier to manage infrastructure and reducing the risk of errors.

Efficiency and Time Savings: 

Adopting Infrastructure as Code increases efficiency, reduces human error, and saves time. This aligns with the broader theme of leveraging technology to optimise business processes and save resources.

Improved Security:

By automating deployment and configuration processes, businesses can better manage security measures, reducing vulnerabilities and ensuring compliance.

Rapid Deployment and Cost Savings:

BCN’s capability to deploy entire estates and environments in a matter of hours rather than weeks underscores the speed and cost-effectiveness of Infrastructure as Code. This rapid deployment capability translates into tangible time, stress, and cost savings for businesses.

Thanks for listening!

Connect with us on LinkedIn or visit our website.

Transcript

Peter: 0:04

Hello and welcome to BCN's Podcast. Today I have the pleasure of speaking with Connor. Connor is one of our senior cloud services architects, and the topic we'll be discussing is infrastructure as code. Connor, hello and welcome to today's podcast.

Connor: 0:20

Hi, okay, Peter. How are you doing?

Peter: 0:22

Yes, good thanks. Connor, I think before we dive in, do you want to give the audience just a little background in terms of who you are, what you do at BCN, and some of your experience?

Connor: 0:33

Yeah, so I think you mentioned then I'm one of BCN's cloud solutions architects. Um so I predominantly work with Azure, Cloud Resources, I work with developers, and part of my role is to build them solutions and what the stuff that the developers want to do runs them, how that works, the infrastructure security, etc. I've been with BCN now for around three years. We've been having a look at this infrastructure's code journey, and we're we're getting rid of the lift off of it um later.

Peter: 0:59

Thanks for that, Connor. So, topic of today, as we we mentioned, was infrastructure as code. And really what we want to do is do a deeper dive in terms of understanding what that actually means, how businesses can practically apply this to their businesses, and really what the benefits are that this brings to the table. So, Connor, do you want to just give us a high-level overview in terms of what we mean by infrastructure as code?

Connor: 1:31

So I think it pretty much does what it says on the TIM is the provisioning of infrastructure through code. Now, what that means is traditionally in your on-premise environments, you may have had somebody go out with a server, a box, they've put it into a rack, they've done the connectivity around it, and then you can pass that to your developers then to start configuring what they need to run on that server. And that changed point two in the cloud world where you had this thing called ClickOps. You had a portal where you could go in and you could say, actually click that button, click that button, click that button, and that would then go and deploy a server in a cloud environment on your behalf. So you got rid of that need for a physical person to go out and do it. What infrastructure as code is doing is provisioning that cloud infrastructure through basically coding language, bicep predominantly is what we use. So now you don't have to do that clicking process, you don't have to go into a portal, you don't have to say, I want this to be built in such a manner, I want this to be built in under this framework, this compliancer. We can build the code to do that, and then we can deploy it as many times as we want.

Peter: 2:40

That's that's really interesting. And from what you've explained there, a game changer for businesses. So you can deploy infrastructure a lot quicker, you can control the versions, and and I'm guessing with it being standardized, you can ensure that the infrastructure and environments are deployed in a safer manner, which which ultimately improves and bolsters the level of security in these environments as well.

Connor: 3:06

Yeah, 100%. So if you can imagine almost a cookie-cooter approach, if you've got like we'll use an example again of a virtual machine, and a virtual machine needs to be configured in such a way to maybe meet NHS or NIST compliance, we have a template on how to configure that virtual machine. So what we can do is we can keep that template, and then if you need five virtual machines, we can just change the parameters and reuse that template. So we're getting the same output every time. It increases the efficiency of deployment, it removes room for human error, so we we can't misclick because the template is dictating how we should deploy that resource, and we just reuse it every time again. But like I say, that cookie-cutter approach. Predominantly it's fantastic for businesses that are trying to target the platform as a service world where there's no infrastructure, there's no operating systems to manage, and we can take it to the next level there. And instead of deploying individual resources, we can deploy entire estates, environments, full solutions, but we can deploy that multiple times as well. So if you need a new environment for some devs that are coming on board, we can deploy your dev environment again and call it dev point two. I mean you've got an environment for just Vem devs to work into. We can deploy your production environment multiple times just by using that cookie-cutter approach and merging everything together for a dependent and full environment at any given time.

Peter: 4:30

That's super impressive. So talking a little more about BCN's capability and and I guess what sort of separates us from a lot of the other providers out there, could you sort of elaborate on our approach? So if we've got a client or a business that's interested in exploring this for their environment, how would we engage?

Connor: 4:52

Yeah, so again, 100% of a kind of revert back to what I was just saying. Um, and I can't take the credit for this. We've had some fantastic engineers working on the code in the background, and how we've got to this level of the templates and pre-built topology that we have. And we we can use an example of a customer which come through this kind of process very recently, and what we've been working with, that customer has been working with their dev team to decide what infrastructure runs our application best. And we've built a configuration file, a repository built around this customer. And what that means is these guys can now, this is where we've probably taken it again to the next level, is use this as a disaster recovery solution. So we have customer configuration 1.0.0, and we can release their configuration and infrastructure almost in the same controlled manner as a software release. We can branch it, we can test it, and we can push it to production. Where the really interesting bit comes in is, and this is in line with some of the changes that Microsoft are making, so Microsoft are removing disaster recovery requirement for our app services in 2025. There's no replacement service for it. So your option is to basically deploy them app services twice into another region. What we can do is we can deploy your infrastructure upon a regional failure to that secondary region, which means customers aren't paying for a full-time disaster recovery solution anymore. We're just upkeeping that configuration file and just deploying it as many times as we want. So yeah, it gives us that state of configuration and we can just deploy anywhere at any time.

Peter: 6:24

That's really, really interesting. And I guess infrastructure as a code, I mean, obviously it's being used to deploy systems in in multiple cloud environments. Maybe we should talk about some of the commercial benefits for using infrastructure as code.

Connor: 6:40

100%. I mean, you've gone from, you know, 10 years ago, somebody goes out with a server, they plug that into a data center, then that has to be connected up, you've got to do the networking, there's a lot of cables have got to go together, and then eventually someone gets access to that and off we go. And then we move to almost phase two of that, which is cloud deployments, which was the clicking of buttons in a portal and off you go. But then in today's world, even that's you know quite slow. And what you can do now is you can actually build the kitchen and then just pump everything out. You can deploy these entire estates in a single pipeline. I'm trying to get that in place with the idea of the governance, infrastructure, and security that builds around it, but the ability to replicate that environment as many times as you want. Because if you've got say a disaster recovery solution, what's happening in 2025 is Microsoft just said for app services, there's used to be this disaster recovery mode where your app service would be available to recover into a secondary region. And in September 2025, Microsoft would just turn around and go, which I'm not doing map, just don't fancy it anymore. Go build your app services in the secondary region and load balance your two regions, which means you've got to pay for both of them infrastructures. And what we've said is, well actually, why don't we just build it in code? And if you do need to fail over to that region, at that point it's not going to take us three weeks to go through the portal and click every setting. It actually takes us less than three hours now, and we can deploy your entire estate to the secondary region and then just fail you over to it. And once you're done, we can just deploy it back to your primary and just fail you over to it.

Peter: 8:19

Yeah, well, I mean that's a game changer, right? Because uh we all know that backup disaster recovery are expenses incurred by businesses that don't actually get to realize the benefit or a return on investment on that. Whereas now, with the development of this service and technology, clients don't need to essentially run unnecessary environments incurring ongoing costs for a service that they may never actually use. So, with this technology, as you were saying, they can quickly deploy a live environment in a totally different region on a different infrastructure within a matter of hours rather than days or weeks.

Connor: 9:08

Yeah, so previously what you'd like to say, you'd have to do is let's say that you've got a simple design of an app service and a database, you'd go into your secondary region, you deploy your app service, and then you'd fail your database or use a mystery or redundant storage, which you can keep your data on. What we're now saying is all of them dependent resources, everything that creates an entire estate, we'll configure using BICEP and an infrastructure's code configuration file, and then we'll set your data. The rest of the environment is something called ARM Azure Resource Manager. It's all JSON. That can be deployed or changed as much as we want. Your data is the only thing that is specific to your organization. If we can deploy your entire JSON or your front end, your web services, your API, your firewalls, and your network using Azure Resource Manager our way to communicate with your resource manager, which in our case is the bicep plan, to your secondary region, all we need to do is protect that data. So we protect your data with what's called read access georred storage, and we can deploy all the front end of the application and then just back up that database within one hour recovery point objective. The pipeline itself takes about three hours to generally run for quite a large infrastructure. If we were to do the ClickOps process, like I say, it's you're looking at about two to three weeks to deploy an entire correctly configured and tested infrastructure. Or we can test your infrastructure, you just ask a recovery and deploy it when needed using a pipeline which takes that down to three hours. So you can now, in the event of London goes missing, for instance, we lose the south of the UK, we can deploy that entire estate within that three-hour point in time without having to pay for that entire secondary infrastructure at that point, just by maintaining what it should look like in the real world through DevOps.

Peter: 10:59

I mean, that is a game changer. Being in the industry for the past 20 years and having sold and worked with businesses and numerous technologies and solutions around backup and DR, I mean, that is truly astounding. And I I think you know that feeds into some of the key benefits, specifically tangible benefits that businesses are ultimately concerned with, which is cost, right? Um, cost is ultimately the driving factor for all businesses at the end of the day. And if you're able to deliver the same or similar functionality from a backup and DR perspective at a significantly reduced investment, then you know that is a massive positive. And so, too, with the actual implementation of the infrastructure, if if you no longer need to rely on humans to click buttons and go to sites and deploy actual hardware, the infrastructure deployment would cost less because you're spending less time, right?

Connor: 11:58

So I we could probably say that again and we can level that up. Again, the clever engineers have been working on this in the background, we've actually built logic into our pipeline, our deployment files. And a really good example of how that works and MatLogic is we wanted to make these deployments as simple as possible for the end user. If they need to invoke a secondary development environment, if we want to delete development and redeploy for maybe a new dev firm that we're working with, we wanted to make that really human-friendly. We didn't want people to be going into some parcel changing code. So we've actually taken it down to radial buttons of what that looks like. And if one of our customers go into this solution and we deploy their dev environment and we we check the box to say that their entire estate should be dev, we're deploying all that infrastructure correctly configured, but we're using development SKUs to save the customer money. So we're using the basic SKUs, the development tiers, the stuff that you want to test and play around with. But in that same respect, if we deploy it as a production environment, there's logic inside the deployment files, which calls for your big boy, your SLA back skews, your premium, your business critical skews for your infrastructure. And that's actually baked into the code itself. So the end user can now tick what kind of environment do I want, where do I want that environment deployed to, click play, and then it will paste that environment out for you. Your dev spend level, that application layer on top of that platform we've just deployed for you, and there's your full infrastructure and business up and running again. We've made it really human-friendly.

Peter: 13:31

Yeah, and that's so important, is providing a service that is easy to interact with and and understand. So, Connor, I guess for our audience and businesses who are listening to us today, how do they get started? I mean, what what is the approach they should take?

Connor: 13:49

Obviously, at first, give us a call. It's something we'll discuss with customers going forward of how do we deploy them environments. Previously, we've gone very much, we'll get the usual engineers and we're going to go through that click-ops process. But during that pre-sales process now, what we'll do is we'll discuss if you're compatible or if you can use this infrastructure as code. If you're interested in it, we can do demos and run-throughs of what it'd look like. If you've got to go down that path, we'll take that as part of one of our projects. It's our bread and butter stuff at that point. But yeah, we we could have that conversation and decide what compatibility is.

Peter: 14:22

So I guess to break it down into simple terms, if you're a business out there that has an aging infrastructure, either on site or you're running a dated cloud-based infrastructure and you're looking at moving or creating a new environment in which to run your applications and data in, give us a ring. We can run through the requirements and see, as Connor was saying, if you're a good candidate for infrastructure as code, and um that might just um give you what you need in a much quicker time frame and potentially at a much lower cost versus the more conventional approach for deploying environments. Would you say that's fair to say, Connor? Yeah, 100%. 100%. Excellent. So if you've enjoyed today's podcast, don't forget to like and subscribe. We've also got a wealth of information on our website. That's www.bcn.co.uk. If you'd like to know more or would like to get in touch, then please feel free to grab our details on our site, and Connor and the team are more than happy to assist you with your requirements. Thanks for tuning in.