Welcome to Experts in Polo Shirts.
I'm Chris. I'm Ryan.
Today, we're talking about supercharging development in Azure.
I thought it might be useful to paint a picture on what we feel legacy or traditional kind of feels like from a development perspective, so... And it's not to say that legacy necessarily a bad thing, but obviously the faster you can develop, the more tools you can use, the higher your throughput velocity can be of development activity. The more value you can release me development team.
So, a good example is, you know, if you're deploying code manually to environments, you're managing loads of IIS servers, you're perhaps developing locally and then publishing it to an IIS box and maybe, you're not getting predictable, repeatable deployments. You're perhaps spending time fixing security after the fact rather than it being part of the release.
Can you think of any other sort of typical scenarios that like, would mean legacy development environment?
Also, it's the the IaaS versus the platform side as well. So, you're also having to manage probably a Windows box, maybe a Linux box. So, now you also have to consider those Windows updates so, you have to look after the operating system. You have to have security on there - how is your security product going to interact with your actual deployment and your web app, as well?
Yeah, I suppose it's the concept we often talk about, which is the whole like, trying to get everything to cattle versus pets. Whereas pets, you know, you having to manage all these VMs and do that when there's updates and look after them, and it's time spent doing that that should be focused on other things.
I suppose if we if we kick off what we feel like a- a more modern environment feels like I guess at the heart of that is Azure DevOps.
What is Azure DevOps?
Azure DevOps is a solution that lets you - you can push code down a pipeline - so you can have your Azure DevOps pipeline - so, you can push code down a pipeline. But it's not necessarily just the code, it's also -- it can automate the infrastructure behind that as well. So, it's automating not just the code, pushing through, and then, maybe security is an element, and there's different stages.
But yeah, it's also the infrastructure that comes behind. It can also be part of that automated deployment.
So effectively, it's ‘A’, a repository for all of your codebase, in one central location. Then, it's also coupling Azure and other platforms into release pipelines, so that when code is actually committed into that environment, that can be deployed into environments in Azure.
I think it's also important so that -- from a -- one challenge we see, and we were talking about legacy environments in terms of like local development environments and having, perhaps having things that you build locally and then you push into production manually. One thing that you can do with pipelines is you can automate the transition of code through different environments, that's gated. So you could, make a commit, deploy into say, staging or development and then deploy that into production. Once you say, "yep, I've tested it", pass on to the next one.
I suppose one - one important element is, improving automated test coverage as you start to build more pipelines, because, again, you can make that part of the release in terms of: do those unit tests actually pass? Because that creates more predictability around the builds.
So, you mentioned security. What are the sort of common things that take place in - when we're talking about pipelines - what is it you can do from a security perspective to enhance that via pipelines?
OWASP.
I mean, that's the first one. You can have the OWASP 10 be looked into during the deployment. So, once you're going through your CI/CD, you can have this look at your code, and then try and find the most common vulnerabilities that are - that are out there for your type of web app. So, it'll look for those vulnerabilities for you.
So, effectively, there's like a pre-check - you're moving security testing left of deployment. So, there's reduced chances of actually -- it's almost like we're eradicating the vulnerabilities before the code is released. So, therefore we're spending less time dealing with the security estate, which probably - well, it does - drive a much higher level of maturity, from an organisational perspective, because often when we know that managing vulnerabilities after the fact is always painful.
And especially when it comes to things like web apps where you've got, you know, that codebase and any modules can quickly become out of date, and then you've got an element of like, refactoring to go and fix all of that.
It's going to be one of the most targeted things, right? It's facing the internet, so everyone can get to it. I mean, you can put a geo-lock down, but anyone can spin up a VM within a country and then get in, or they can use a VPN. So, geo-locks are nice - they're a nice idea - but it's not really going to stop someone that wants to really try your app.
You've got to have security as part of standard process, and you've got to be considering it constantly - not just monitoring it - but just have it as part of the process. And it just covers it for you - don't need a third party tool, just integrate within your pipeline.
One bit that I've noticed is, something like this can really drive up the velocity - the amount of releases per day - because you get that predictability. You know, this this is like, a really simple example, but someone says, "I'd really like that text box to have, this piece of text in it before someone types in it". Or, "I'd like this button to be this colour...".
And often, without this kind of technology, you'd be like, "So, that can go in next week's release", whereas actually, you could deploy that, without interruption, into the environment. And things like that really going to expedite the software delivery process.
I think - and I'll probably like, screw this quote up - but I think Microsoft spent a period of time where they actually said that all activity that improved development throughput was prioritised over and above the actual development.
Because over time, the growth that -- there's an exponential improvement for throughput.
Yes, the ROI is ginormous because, yeah, you increase the throughput, you increase the quality by doing these things and locking it all in in one process, which means that you can do smaller pushes without it having to be such a big effort that requires so many man hours to go and check code, because you got there's so much automated testing already happening.
Yeah, it completely makes sense.
I've got -- I've seen a report by the DevOps Research Agency said the same thing, like 20 to 100% ROI over a few years, depending on the size of organisation. The larger you are, the smaller it seems to work out, but still, it always seems to be more than -- more than the effort you put in is the result you get out because it's more throughput, more quality, more predictable. Yeah, it's just great.
So, we often talk around -- sort of, if we move on to like, Platform as a Service, when it comes to things like, we've got -- so we've got database technology, whether that's like SQL or a variety of other database technologies in Azure. And yeah, we've got things like app services - we've got AKS, Azure Kubernetes Service.
What are the key benefits of something like app services when it comes to development as opposed to things like IIS?
App services versus IIS? It's definitely the fact that, you're not managing a server. So that, like, from a infrastructure point of view, there's one less piece of infrastructure to worry about. Let the cloud provider manage that sort of backend, manage the operating system for you. You just worry about the code, pushing the code, using your deployment slots if you need to, and that's one element.
Also, cost is another element, like, you could potentially save money because now you're not wasting time on the overhead of just running an operating system. And another benefit of app service is scalability, versus an IIS box where, "we need more"... "Okay, turn it off, increase the skew or spin another one up and put it in their cluster" or whatever.
Don't need to do that. You can scale within the platform.
I suppose another thing that we often see a pain from on managing servers is, certificate management, and app services makes that… and I know, there are things like Certbot that can make that a lot easier on IIS, but I suppose that straightaway alleviates an element of pain, particularly if the Google change happens with SSL, where they'll expire in 90 days, that will become an even bigger headache.
And I think that's a that's a huge benefit. There's a… I remember we spoke about this before… There's a particular debug console isn’t there? And then you got, you got tools like erm… Kudu? What’s it called? Kudu, I think it is.
I know that's been really useful for a lot of development teams in terms of being able to see log output directly, without trawling through an IIS box.
I think also it's a good point like, just because you've not got your operating system anymore and you used to browse to see program data, and go to exactly where you need to, the tools still exist - you can still get them with an app service. Yeah, just a slightly different tool but once you're in it, it'll feel very familiar. And it's great for debugging - I've used it many times to fix plenty of issues.
So, one of the things I really like is application insights. I think it's really, really cool. So, the ability to… I know it does require an element of amendment to the application to actually install application insights but that level of detail allows you to very quickly debug where the problem is in your platform, in your environment, how are things performing, what is causing a slowdown in the user experience and how was that performing previously versus where is it now. So, was that a deployment that made that problem occur?
So, things like that I think are really, really powerful. And you're getting those features kind of baked in... Well, I'm sure there is a small charge for them but you're getting those features baked into that.
Now, that's not to say if you're using something similar - good - but you're probably using the third party app, right? And now it's one less third party app to use. The cost is minimal. So, it's just it's one less platform on the solution to worry about because you can just have it integrated and it does a great job as well.
App service is just one example of like, Platform as a Service. And I know having maintained a lot of SQL instances that SQL as a Service is just infinitely easier to manage. So one of the key things that I've noticed is when it comes to managing things like, SQL Platform as a Service, you get the almost like the in-built performance analysis query tuner - these things are missing.
And a good example of that are missing indexes. It's so easy to miss an index. It causes a huge performance problem and actually, moving into PaaS will surface those performance issues much simpler and easier than logging on to a SQL box and having a very particular skillset. I think that's one thing... Does it almost -- not dumbs it down because effectively there's still a lot of control there. But it really helps to bring those performance problems to the surface. And you don't need to be a wizard. A developer can go in and actually figure out why is it misbehaving, why isn’t it performing.
Yeah. It's funny because some of the debug that we've done is -- would be reserved for like quite senior DBAs. And we've been able to do it because we just got the tools - the tools are just there for us now. So it just yeah, it helps. Again it's the quality, the throughput - it just makes it easier to find these things, look at them and yeah, fix any issues that we can see that previously might have been invisible to pure infrastructure teams, now you can see it.
And I suppose when it comes to PaaS and actually infrastructure, one thing we've not even spoke about is infrastructure as code. So, the ability to actually fully templatise the entire environment. So we've got the code, we've got the deployment of the code but we've also then got the actual infrastructure itself it runs on. So, we can almost clone that out. And if we needed to, we could blow it away and redeploy it. Almost like, like Netflix and various others, use this term of like 'chaos engineering' and the concept that we should able to destroy a single service and the application system carries on functioning as normal. And I know that's… for a lot of organisations, IaC is they're still in the early stages, and it's often one of the more complicated things to go and actually to deliver.
But what sort of benefits do you see from the use of IaC?
So, it is exactly what you said there - that you're not relying on one box and holding the hand of that box and then bringing it through and upgrading the--the OS over time and bringing it up to a modern standard. If you've got IaC for your platform - for IaaS - for every part of it, then it can all be redeployed as required. So, whether you need to move tenant, whether you're moving around, but there's a better way to do something and you can push that out to everything.
IaC like you say, you can redeploy instantly. You can recover instantly. The chaos engineering is a great example. If you lost everything, if you lost your tenant - we're not talking about a few servers that've got malware on them - you lost your tenant. What are you going to do? You're going to go to your git repository and you're just going to push out your entire infrastructure again like it's... The complexity of it though does require even pushing out simple changes. Now, you need a level of DevOps, even within your infrastructure team.
You can't just operate with ClickOps. You can't have bespoke handmade servers. You do need to make sure that everyone gets trained and upskilled so that--there's one of the considerations is like the training side of it but the benefits, if you can do it true and accurately, is amazing. It could be immeasurable.
I suppose it's one thing to deploy your IaaS, but I think when it comes to PaaS, that's almost like an easier a stepping stone to deploy through code, because often you'd be building greenfield to migrate services in. I know that one of the approaches that we're quite keen on is where we're migrating to app services is to almost like--be using that as a way to introduce like pipelines, move to your DevOps and also implement Infrastructure as Code.
So, no great podcast would be complete without talking about the effects of AI on development in Azure. And I don't necessarily mean from the Azure function perspective. So, it's just--and it might not even be specifically Azure because I know one of them is owned by Microsoft but isn't specifically Azure. So yeah, I've been playing around a little bit with, GitHub Copilot.
And I'm not a developer, but I feel like tools like that are certainly worth talking about because they massively improve throughput and can help, you know, write elements of code to save time.
You know, and there'll be lots of developers that, you know, that probably aren't huge fans of AI tooling because, you know... "This is going to come along and replace me".
And I think there was the AI hype train that sort of, came along like three-six months ago and it's going to be the next big thing. I still think it's going to be a really important part of like, technology moving forwards. Will it be this great big thing that replaces everything that we do? I don't think so. Will it be an important, cog in the machine? Absolutely.
I think it enables people to work outside their bracket maybe? I don't know the exact term that I’d use, but it allows people that don't know something to at least make a small change or start to work on something. I have never touched Python and now making Python scripts to scrape websites and grab the data that I need for different projects that I'm working on - it’s amazing.
Like, it is great for like -- think I could maybe add two numbers together in a script and now I'm literally having it browse through website, click a login button, login for me, grab the information I need. It's just -- yeah -- the steps that you can take just like, above your station, is amazing.
Yeah, that's true. It's almost like enabling, perhaps, more junior developers to explore new technologies or languages, and also potentially to validate code that's been written.
Yeah, it's another tool - it's not going to replace you as a person. But the person that uses it and you don't, they're going to have an edge. So interact with it, learn it, understand its limitations. It isn't going to replace you overnight, but the person that uses it might. That's why you need to think about it.
So, this is a very particular development tool I've been playing with, which has been phenomenal, which is a tool called Replit. So, Replit is an AI-powered, naturally language-driven - effectively ChatGPTesque - development tool. And what it allows you to do is to write the application requirements out to the AI, and then it will actually go and build the code.
Now, that's most AI tools to do that, whether it's Claude, ChatGPT... What's special is it will then spin up a container to actually run that code, spin up a database, and actually build the architecture and deploy it. Once it's deployed, it then uses computer vision to check whether the apps are actually working or not, and then iteratively improves upon it. So, in my testing, it did take a lot of like, prompt, of sort of tweaking, to actually get the result.
You were taking the output, putting it into ChatGPT to get that answer, to give back to Replit!
But that's… but I think tools like that like, are phenomenal for like, prototyping. Be able to go MVP with something and you know, I even said like, !I want to integrate Okta or this API or that API", and it was able to go and read the API docs, and go and come back, and actually produce the query in the way that I needed to.
And things like that are just gonna like, vastly modernise. If you can, if you work in an IT department or an organisation, you can go and use Replit to do a POC. And say look, "I'm not a developer - here's a little POC I built based on this--this tool. I've proven the use case for this thing that we need. Now, we need to go and hire a developer or development team".
And we can go and build app almost like properly because the reality is you just, you know, if you're not a developer, you're not going to know whether you've met all the right controls for an application.
I've been blown away with that and like you say like Python, like be able to write scripts to do and automate various tasks, when you're not a developer, is just massive.
I never knew that Python could manipulate spreadsheets and stuff, and that's been cool to play with. And read PDFs. Python is great - it's powerful.
Well, yeah, it's almost like we've come full circle from the start we were talking about throughput and quality. We're talking about the same thing.
With AI, it increases throughput of a dev that it's using it or someone that is non-dev can start to use it, and then just start like creating an MVP (Minimum Viable Product) right there. And then using it to check things, check the code, tidy things up, reduce the amount of lines, whatever.
Again, we've come back to throughput and quality.
And I think it's such a shame that some organisations just do not want to develop -- to use that tooling and technology. Because effectively what they're doing is they are denying themselves that advantage that is there to be gained. And that unfair advantage.
We talk about enabling the game changers. And this kind of technology, for me, is one of the key things that is about enabling the game changers.
I'm Chris. I'm Ryan.
Today, we're talking about supercharging development in Azure.
I thought it might be useful to paint a picture on what we feel legacy or traditional kind of feels like from a development perspective, so... And it's not to say that legacy necessarily a bad thing, but obviously the faster you can develop, the more tools you can use, the higher your throughput velocity can be of development activity. The more value you can release me development team.
So, a good example is, you know, if you're deploying code manually to environments, you're managing loads of IIS servers, you're perhaps developing locally and then publishing it to an IIS box and maybe, you're not getting predictable, repeatable deployments. You're perhaps spending time fixing security after the fact rather than it being part of the release.
Can you think of any other sort of typical scenarios that like, would mean legacy development environment?
Also, it's the the IaaS versus the platform side as well. So, you're also having to manage probably a Windows box, maybe a Linux box. So, now you also have to consider those Windows updates so, you have to look after the operating system. You have to have security on there - how is your security product going to interact with your actual deployment and your web app, as well?
Yeah, I suppose it's the concept we often talk about, which is the whole like, trying to get everything to cattle versus pets. Whereas pets, you know, you having to manage all these VMs and do that when there's updates and look after them, and it's time spent doing that that should be focused on other things.
I suppose if we if we kick off what we feel like a- a more modern environment feels like I guess at the heart of that is Azure DevOps.
What is Azure DevOps?
Azure DevOps is a solution that lets you - you can push code down a pipeline - so you can have your Azure DevOps pipeline - so, you can push code down a pipeline. But it's not necessarily just the code, it's also -- it can automate the infrastructure behind that as well. So, it's automating not just the code, pushing through, and then, maybe security is an element, and there's different stages.
But yeah, it's also the infrastructure that comes behind. It can also be part of that automated deployment.
So effectively, it's ‘A’, a repository for all of your codebase, in one central location. Then, it's also coupling Azure and other platforms into release pipelines, so that when code is actually committed into that environment, that can be deployed into environments in Azure.
I think it's also important so that -- from a -- one challenge we see, and we were talking about legacy environments in terms of like local development environments and having, perhaps having things that you build locally and then you push into production manually. One thing that you can do with pipelines is you can automate the transition of code through different environments, that's gated. So you could, make a commit, deploy into say, staging or development and then deploy that into production. Once you say, "yep, I've tested it", pass on to the next one.
I suppose one - one important element is, improving automated test coverage as you start to build more pipelines, because, again, you can make that part of the release in terms of: do those unit tests actually pass? Because that creates more predictability around the builds.
So, you mentioned security. What are the sort of common things that take place in - when we're talking about pipelines - what is it you can do from a security perspective to enhance that via pipelines?
OWASP.
I mean, that's the first one. You can have the OWASP 10 be looked into during the deployment. So, once you're going through your CI/CD, you can have this look at your code, and then try and find the most common vulnerabilities that are - that are out there for your type of web app. So, it'll look for those vulnerabilities for you.
So, effectively, there's like a pre-check - you're moving security testing left of deployment. So, there's reduced chances of actually -- it's almost like we're eradicating the vulnerabilities before the code is released. So, therefore we're spending less time dealing with the security estate, which probably - well, it does - drive a much higher level of maturity, from an organisational perspective, because often when we know that managing vulnerabilities after the fact is always painful.
And especially when it comes to things like web apps where you've got, you know, that codebase and any modules can quickly become out of date, and then you've got an element of like, refactoring to go and fix all of that.
It's going to be one of the most targeted things, right? It's facing the internet, so everyone can get to it. I mean, you can put a geo-lock down, but anyone can spin up a VM within a country and then get in, or they can use a VPN. So, geo-locks are nice - they're a nice idea - but it's not really going to stop someone that wants to really try your app.
You've got to have security as part of standard process, and you've got to be considering it constantly - not just monitoring it - but just have it as part of the process. And it just covers it for you - don't need a third party tool, just integrate within your pipeline.
One bit that I've noticed is, something like this can really drive up the velocity - the amount of releases per day - because you get that predictability. You know, this this is like, a really simple example, but someone says, "I'd really like that text box to have, this piece of text in it before someone types in it". Or, "I'd like this button to be this colour...".
And often, without this kind of technology, you'd be like, "So, that can go in next week's release", whereas actually, you could deploy that, without interruption, into the environment. And things like that really going to expedite the software delivery process.
I think - and I'll probably like, screw this quote up - but I think Microsoft spent a period of time where they actually said that all activity that improved development throughput was prioritised over and above the actual development.
Because over time, the growth that -- there's an exponential improvement for throughput.
Yes, the ROI is ginormous because, yeah, you increase the throughput, you increase the quality by doing these things and locking it all in in one process, which means that you can do smaller pushes without it having to be such a big effort that requires so many man hours to go and check code, because you got there's so much automated testing already happening.
Yeah, it completely makes sense.
I've got -- I've seen a report by the DevOps Research Agency said the same thing, like 20 to 100% ROI over a few years, depending on the size of organisation. The larger you are, the smaller it seems to work out, but still, it always seems to be more than -- more than the effort you put in is the result you get out because it's more throughput, more quality, more predictable. Yeah, it's just great.
So, we often talk around -- sort of, if we move on to like, Platform as a Service, when it comes to things like, we've got -- so we've got database technology, whether that's like SQL or a variety of other database technologies in Azure. And yeah, we've got things like app services - we've got AKS, Azure Kubernetes Service.
What are the key benefits of something like app services when it comes to development as opposed to things like IIS?
App services versus IIS? It's definitely the fact that, you're not managing a server. So that, like, from a infrastructure point of view, there's one less piece of infrastructure to worry about. Let the cloud provider manage that sort of backend, manage the operating system for you. You just worry about the code, pushing the code, using your deployment slots if you need to, and that's one element.
Also, cost is another element, like, you could potentially save money because now you're not wasting time on the overhead of just running an operating system. And another benefit of app service is scalability, versus an IIS box where, "we need more"... "Okay, turn it off, increase the skew or spin another one up and put it in their cluster" or whatever.
Don't need to do that. You can scale within the platform.
I suppose another thing that we often see a pain from on managing servers is, certificate management, and app services makes that… and I know, there are things like Certbot that can make that a lot easier on IIS, but I suppose that straightaway alleviates an element of pain, particularly if the Google change happens with SSL, where they'll expire in 90 days, that will become an even bigger headache.
And I think that's a that's a huge benefit. There's a… I remember we spoke about this before… There's a particular debug console isn’t there? And then you got, you got tools like erm… Kudu? What’s it called? Kudu, I think it is.
I know that's been really useful for a lot of development teams in terms of being able to see log output directly, without trawling through an IIS box.
I think also it's a good point like, just because you've not got your operating system anymore and you used to browse to see program data, and go to exactly where you need to, the tools still exist - you can still get them with an app service. Yeah, just a slightly different tool but once you're in it, it'll feel very familiar. And it's great for debugging - I've used it many times to fix plenty of issues.
So, one of the things I really like is application insights. I think it's really, really cool. So, the ability to… I know it does require an element of amendment to the application to actually install application insights but that level of detail allows you to very quickly debug where the problem is in your platform, in your environment, how are things performing, what is causing a slowdown in the user experience and how was that performing previously versus where is it now. So, was that a deployment that made that problem occur?
So, things like that I think are really, really powerful. And you're getting those features kind of baked in... Well, I'm sure there is a small charge for them but you're getting those features baked into that.
Now, that's not to say if you're using something similar - good - but you're probably using the third party app, right? And now it's one less third party app to use. The cost is minimal. So, it's just it's one less platform on the solution to worry about because you can just have it integrated and it does a great job as well.
App service is just one example of like, Platform as a Service. And I know having maintained a lot of SQL instances that SQL as a Service is just infinitely easier to manage. So one of the key things that I've noticed is when it comes to managing things like, SQL Platform as a Service, you get the almost like the in-built performance analysis query tuner - these things are missing.
And a good example of that are missing indexes. It's so easy to miss an index. It causes a huge performance problem and actually, moving into PaaS will surface those performance issues much simpler and easier than logging on to a SQL box and having a very particular skillset. I think that's one thing... Does it almost -- not dumbs it down because effectively there's still a lot of control there. But it really helps to bring those performance problems to the surface. And you don't need to be a wizard. A developer can go in and actually figure out why is it misbehaving, why isn’t it performing.
Yeah. It's funny because some of the debug that we've done is -- would be reserved for like quite senior DBAs. And we've been able to do it because we just got the tools - the tools are just there for us now. So it just yeah, it helps. Again it's the quality, the throughput - it just makes it easier to find these things, look at them and yeah, fix any issues that we can see that previously might have been invisible to pure infrastructure teams, now you can see it.
And I suppose when it comes to PaaS and actually infrastructure, one thing we've not even spoke about is infrastructure as code. So, the ability to actually fully templatise the entire environment. So we've got the code, we've got the deployment of the code but we've also then got the actual infrastructure itself it runs on. So, we can almost clone that out. And if we needed to, we could blow it away and redeploy it. Almost like, like Netflix and various others, use this term of like 'chaos engineering' and the concept that we should able to destroy a single service and the application system carries on functioning as normal. And I know that's… for a lot of organisations, IaC is they're still in the early stages, and it's often one of the more complicated things to go and actually to deliver.
But what sort of benefits do you see from the use of IaC?
So, it is exactly what you said there - that you're not relying on one box and holding the hand of that box and then bringing it through and upgrading the--the OS over time and bringing it up to a modern standard. If you've got IaC for your platform - for IaaS - for every part of it, then it can all be redeployed as required. So, whether you need to move tenant, whether you're moving around, but there's a better way to do something and you can push that out to everything.
IaC like you say, you can redeploy instantly. You can recover instantly. The chaos engineering is a great example. If you lost everything, if you lost your tenant - we're not talking about a few servers that've got malware on them - you lost your tenant. What are you going to do? You're going to go to your git repository and you're just going to push out your entire infrastructure again like it's... The complexity of it though does require even pushing out simple changes. Now, you need a level of DevOps, even within your infrastructure team.
You can't just operate with ClickOps. You can't have bespoke handmade servers. You do need to make sure that everyone gets trained and upskilled so that--there's one of the considerations is like the training side of it but the benefits, if you can do it true and accurately, is amazing. It could be immeasurable.
I suppose it's one thing to deploy your IaaS, but I think when it comes to PaaS, that's almost like an easier a stepping stone to deploy through code, because often you'd be building greenfield to migrate services in. I know that one of the approaches that we're quite keen on is where we're migrating to app services is to almost like--be using that as a way to introduce like pipelines, move to your DevOps and also implement Infrastructure as Code.
So, no great podcast would be complete without talking about the effects of AI on development in Azure. And I don't necessarily mean from the Azure function perspective. So, it's just--and it might not even be specifically Azure because I know one of them is owned by Microsoft but isn't specifically Azure. So yeah, I've been playing around a little bit with, GitHub Copilot.
And I'm not a developer, but I feel like tools like that are certainly worth talking about because they massively improve throughput and can help, you know, write elements of code to save time.
You know, and there'll be lots of developers that, you know, that probably aren't huge fans of AI tooling because, you know... "This is going to come along and replace me".
And I think there was the AI hype train that sort of, came along like three-six months ago and it's going to be the next big thing. I still think it's going to be a really important part of like, technology moving forwards. Will it be this great big thing that replaces everything that we do? I don't think so. Will it be an important, cog in the machine? Absolutely.
I think it enables people to work outside their bracket maybe? I don't know the exact term that I’d use, but it allows people that don't know something to at least make a small change or start to work on something. I have never touched Python and now making Python scripts to scrape websites and grab the data that I need for different projects that I'm working on - it’s amazing.
Like, it is great for like -- think I could maybe add two numbers together in a script and now I'm literally having it browse through website, click a login button, login for me, grab the information I need. It's just -- yeah -- the steps that you can take just like, above your station, is amazing.
Yeah, that's true. It's almost like enabling, perhaps, more junior developers to explore new technologies or languages, and also potentially to validate code that's been written.
Yeah, it's another tool - it's not going to replace you as a person. But the person that uses it and you don't, they're going to have an edge. So interact with it, learn it, understand its limitations. It isn't going to replace you overnight, but the person that uses it might. That's why you need to think about it.
So, this is a very particular development tool I've been playing with, which has been phenomenal, which is a tool called Replit. So, Replit is an AI-powered, naturally language-driven - effectively ChatGPTesque - development tool. And what it allows you to do is to write the application requirements out to the AI, and then it will actually go and build the code.
Now, that's most AI tools to do that, whether it's Claude, ChatGPT... What's special is it will then spin up a container to actually run that code, spin up a database, and actually build the architecture and deploy it. Once it's deployed, it then uses computer vision to check whether the apps are actually working or not, and then iteratively improves upon it. So, in my testing, it did take a lot of like, prompt, of sort of tweaking, to actually get the result.
You were taking the output, putting it into ChatGPT to get that answer, to give back to Replit!
But that's… but I think tools like that like, are phenomenal for like, prototyping. Be able to go MVP with something and you know, I even said like, !I want to integrate Okta or this API or that API", and it was able to go and read the API docs, and go and come back, and actually produce the query in the way that I needed to.
And things like that are just gonna like, vastly modernise. If you can, if you work in an IT department or an organisation, you can go and use Replit to do a POC. And say look, "I'm not a developer - here's a little POC I built based on this--this tool. I've proven the use case for this thing that we need. Now, we need to go and hire a developer or development team".
And we can go and build app almost like properly because the reality is you just, you know, if you're not a developer, you're not going to know whether you've met all the right controls for an application.
I've been blown away with that and like you say like Python, like be able to write scripts to do and automate various tasks, when you're not a developer, is just massive.
I never knew that Python could manipulate spreadsheets and stuff, and that's been cool to play with. And read PDFs. Python is great - it's powerful.
Well, yeah, it's almost like we've come full circle from the start we were talking about throughput and quality. We're talking about the same thing.
With AI, it increases throughput of a dev that it's using it or someone that is non-dev can start to use it, and then just start like creating an MVP (Minimum Viable Product) right there. And then using it to check things, check the code, tidy things up, reduce the amount of lines, whatever.
Again, we've come back to throughput and quality.
And I think it's such a shame that some organisations just do not want to develop -- to use that tooling and technology. Because effectively what they're doing is they are denying themselves that advantage that is there to be gained. And that unfair advantage.
We talk about enabling the game changers. And this kind of technology, for me, is one of the key things that is about enabling the game changers.
