Episode Transcript
[00:00:07] Tom: Welcome to the DevSecOps podcast where we explore the past, present and future of computing in the modern workplace.
[00:00:12] Scotti: Your hosts are a trio of experts recordant, each representing different areas within it.
A bit like a nerdy A team.
[00:00:19] Jared: So join Tom, James and Scotty for a regular, mostly serious podcast providing you with pragmatic advice and insights into modernizing your IT environment.
[00:00:30] Scotti: Welcome back to another episode of the DevSecopes podcast. With me today we've got Tom Walker. G', day Tom.
[00:00:36] Tom: G'day Scotti. How are you?
[00:00:37] Scotti: I'm really well, thanks. Cordant specializes in technology modernization and a significant part of that involves software. Given the rapid changes in development tools, practices and the introduction of AI, we thought we'd invite Jared, one of our senior systems engineers, to walk us through today's modern software landscape. Or maybe I should say it like this. He's going to help us put the div base back in DevSecoops. So maybe we'll start with a little bit about yourself, like maybe you can tell us where you're from, what got you started in it and your journey to Cordon.
[00:01:08] Jared: Thanks Scotty, and thanks Tom for having me on the podcast. I was born in Taranaki, New Zealand where I spent the first half of my childhood before moving up to Tauranga. Getting into IT or where I made my start was traveling across to Rotorua where I would pick up some PCs that had the 15 inch CRT. I'd give them a little bit of new life, put some bigger hard drives in them, upgrade the ram, give a bit of a refresh and then I'd sell those on to friends and family. Naturally that progressed into custom building PCs and also small business servers. That then led to attending LAN parties where I would get involved in hosting the game servers, setting up the network which would need to support both gaming and leeching. Of course back in those days that was quite popular. I briefly worked for a software company, Think before Xero and helped to establish a hosted platform for their clients to operate the accounting program. This was namely to overcome the fact that 64 bit operating systems were coming into the market and the accounting product was only 16 bit so it would only run on 32 bit operating systems. From there I moved across to Melbourne at around 2011 and I worked in managed services supporting a nationwide, not for profit other small businesses and that got me really hooked on working smarter and automating at scale. From here I pivoted slightly into the Atlassian space becoming known as Jira Jarrett as I specialized in their workflow product called Jira. I then became an Atlassian community leader. More on that later. And I joined a large bank for about five years where I got to exercise my feet across platform architecture, tooling, competency and delivery management.
[00:02:50] Tom: And now you find yourself with the fine folk at Cordant. Tell us, what's a week in the Life of Jared look like?
[00:02:56] Jared: So, a little bit of everything, really, which is great. I get to work with some amazing customers across, you know, a mix of different platforms and products and different ecosystems.
Some are global, some are national. And along with that, I spend a bit of time behind the scenes working on our unofficial Cordant help desk, providing internal IT support, but also a lot of internal improvements as well. Things like hosting websites and developing some applications that we internally use just to make our jobs and lives a little bit easier.
[00:03:28] Tom: It's like the camera system that you've set to now have us walk through the door and welcome us into the building every time.
[00:03:34] Jared: Yes. And the plants that monitor how moist.
[00:03:37] Tom: They are, actually, on that, you are a bit of a tinkerer. You have a reputation, and I'm not sure it's just internal. I'm pretty sure most people know you as a bit of a tinkerer. Have you been working on any projects internally or externally, professional or otherwise, that sort of captured your interest of late?
[00:03:53] Jared: Yeah, certainly there's a couple, actually. So with the 11 plants that we've got in the office, knowing which ones need the water juice. So we using a product called Home Assistant and went online to the interwebs and got ourselves some Zigbee moisture detectors. We've also increased the scope of that Home Assistant with a Google Coral. And so using the cameras, we're able to do facial recognition and hoping to extend that to do personalized greetings when people enter and exit the building.
[00:04:22] Tom: It'd be great when it says, hello, Tom, instead of hello, nondescript person walking into the building.
[00:04:27] Jared: Yeah, that's it.
[00:04:28] Tom: And at least we know you're not a dog.
[00:04:31] Scotti: Or when it says someone's here and they look like they're going to rob.
[00:04:34] Tom: The place, that's us anyway.
[00:04:36] Jared: Yeah, A tattoo stranger at the door with ripped and rugged clothes wanting to get in.
[00:04:41] Scotti: Yeah, that sounds about right.
[00:04:43] Jared: Recently purchased or upgraded a chicken coop at home. And so looking to put in some cameras, some temperature sensors, automatic doors. That way we're able to sort of keep an eye on them. Recently purchased some young chicks, about six, seven weeks, so they need a little bit of additional attention. So some extra heat when it gets cold at night, but also just making sure that their food and water is topped off. So looking to automate a lot there. Not necessarily to reduce the need to have to look after them, but just provide the additional insights that we can potentially pop up onto a tablet inside that may lead to, hey, go feed them, top up the water, go collect the eggs. There's a hen that's quite clucky. Maybe kick it out of the nest for a few days.
[00:05:27] Scotti: Yeah, it sounds awesome. I also feel like predator detection would be a really useful feature that you could probably introduce as well.
[00:05:33] Tom: Yeah, tattooed man with ripped jeans standing at the door of the chicken coop.
[00:05:37] Scotti: Yeah, it sounds like a cracking good.
[00:05:39] Jared: Especially with the wolves or the foxes out this way. Little hen, let me come in. I huff and I puff and I blow your coop down.
[00:05:46] Tom: Clucking. Brilliant. Okay, you mentioned you spent a great deal of time known as Jira Jared, do you want to talk us through a bit of that Atlassian experience as well? Because I know you've helped us with some Atlassian stuff with some of our JIRA workflows, but this was a serious part of your life and your career for a very large period of time. Talk us through that.
[00:06:04] Jared: Yeah, definitely. So. So it was just over 12, 13 years ago now. Put my hand up to be at the time Atlassian user group leader, which then became known as a community leader. It was really cool because at that time there wasn't a cloud version of it. It was very much software version. And so a lot of people had different installations, different setup, different needs.
Some of the problems could be solved through Marketplace apps. So with having Jira Confluence, BitBucket, Bamboo and the other Atlassian products on premise and on your own servers, you had a lot more flex in regards to integrating those with other products. Automating a lot of your workflow with regards to handing work off between the developers and engineers through the testers releases that true DevOps sort of ecosystem. There was also the community aspect. So bringing project managers, bringing the agile coaches, bringing the developer and engineers into the same room to start to talk about some of the various capabilities that Atlassian or Jira were releasing or upcoming as part of user groups. That was really awesome. Getting them into the room, feeding them up with beers and pizzas, and just being part of that community where these people were able to use Atlassian as a common ground to discuss and collaborate and network.
[00:07:21] Tom: We've had guests on the show before who have been on the show or have been members of the Cordon team because we work Together.
It just so happens that we actually worked together back at Securepay days. Incidentally, we're not working together today because of that time together at Securepay. But you actually helped set up the Jira and Atlassian suite there at Securepay when both Scott and I were working there.
[00:07:44] Jared: Yeah, that's right. I worked alongside a couple of folk and that was really just around capturing all the different work and helping to plan out what we've worked on now next. And later, I think they were trying to get into Sprint, so they were sort of encroaching into that agile landscape. Whereas I think everything was previously quite waterfall. Correct me if I'm wrong.
[00:08:04] Tom: No, spot on. And the interesting thing was at the time, you know, Atlassian was a sort of up and coming underground cool thing to get into.
My perception is now that Atlassian has gone huge. There are people like, like all with the tall poppy syndrome that are starting to become anti Atlassian. What do you feel now that, you know, say for a decade in that role, where do you feel the sentiment is towards Atlassian in the industry these days?
[00:08:28] Jared: Yeah, look, I think they've taken a lot of inspiration from the marketplace ecosystem. They've incorporated a lot of feedback into their various products. At one point they didn't really understand the enterprise market, but now we're starting to see a lot of traction and granularity around not only the project management side of things, but roadmap planning, portfolio management.
They've also opened up a lot of their thinking to the ecosystem. So it's not just Atlassian integration. There's a lot more, you know, outside of the Atlassian ecosystem integrations as well.
So from a growth point, they've definitely considered a lot of their customers. With their release of the SaaS products, you know, that's sort of blown up quite a bit. Anyone with a credit card can go and get a subscription and get started with little to no experience.
The community online is really wholesome with a lot of knowledge and guidance around what you can do and where to get started. And so there's not much of a need for expertise, so to speak, in establishing JIRA or.
[00:09:33] Tom: I think you're on.
[00:09:34] Jared: Right.
[00:09:34] Tom: You're basically saying it's something now that is managed by the industry rather than that sort of grassroots support, users groups and the like.
[00:09:42] Jared: Yeah, 100%. With COVID obviously user groups kind of took a bit of a backseat. They did try to move to being more virtual, but a lot of people suffered from teams fatigue or just video fatigue. And so you know, sort of joining something after work. People were already exhausted. So trying to bring that community together in a virtual ecosystem was quite difficult. Our attendees kind of dropped from, you know, we sort of have anywhere between 50 to 100 people show up to, you know, sort of five, maybe 10 people showing up for a virtual meetup user group.
[00:10:18] Tom: I think that's the natural life cycle of any, any sort of software. You'll have those that were involved in the early days.
Things naturally progress and grow and become enterprise ready. And that's actually the peak adoption point. That's where you want to see something. You've invested time and love and money and you really believe in a product too. But you're going to have people that sort of say oh, they've sold out and it's an enterprise product now. They're no longer worried about the little people. But I think you're right, it's sort of broadened the horizon because in the early days I was pretty anti the Atlassian suite. To me I found it was a bit clunky and user unfriendly if you like, for those that weren't in the development community. But now I actually think things like Confluence better than, dare I say it, things like SharePoint. I just find it so much easier to use as a, as a non developer even more than Microsoft products that were born in the next finish type approach to user experience. So it's kind of the opposite for me. Atlassian's grown on me. Scotty can't believe that I said Atlassian product was better than a Microsoft product.
[00:11:16] Scotti: Yeah, I just want everyone to capture that on record that Tom said that SharePoint was not as good as Confluence. So I definitely see the change from having to run like back in the Skuba days. Yes, we were definitely running it on prem from a security standpoint. I think having it now as an easily consumable SaaS service where things neatly integrate, you're not requiring customers to build, manage and maintain it on prem. I think that's a huge win. I can see that it's really useful and empowering for businesses to be able to just say hey, we've got a project, we want to adapt Agile. I do see and maybe I want to get your view on this Jared. A lot of organizations saying hey, we're going to move to Agile and we're going to use Jira with actually kind of no real understanding of what that actually means that they think that buying JIRA and using JIRA means that they're agile. So I'd really like to get your view on how essentially that's changed. And if organizations are still looking at, we still deal with customers today that say they're agile, but in true reality it's either like a spiral approach, which is more like a fast waterfall, or they really are still doing it, the traditional waterfall approach. So like how do you see organizations really changing that? Or if they really want to adopt agile, where would they get started?
[00:12:29] Tom: It's waterfall with sticky notes.
[00:12:31] Jared: Yeah, 100%. Yeah, look, I almost had a T shirt made that says, you know, I use Jira. They're from agile. My experience with companies wanting to go down the agile path and you know, obviously picking Jira as the product would fall into that trap of, you know, because we use Jira, we're agile. The other thing to take into consideration was there was Atlassian agile. And so a lot of the team playbooks that you sort of read would have Atlassian's way of doing agile. And then you sort of throw into the mix, you've got a whole bunch of various agile coaches and of course, you know, they've got their own spin on things as well. So there's kind of like a mixed mash of fighting definitions of what agile is. A classic call out there would be in scaled agile you've got epic feature story. But you know, in Jira it was commonly first adopted as epic story, epic task. There was no gap in the middle and it wasn't until recent that you could change that.
So there was always that fighting of, you know, hey, we want to adopt some kind of new way of working and you know, we want everyone to be agile but they would take a very waterfall approach and go, let's just change everyone day one. You'll have to use this new tool. By the way. Here's a rollout of definitions of exactly what's what.
Not really take into consideration the different archetypes of teams.
Some teams benefit working in a very waterful way. Other teams would obviously benefit working in an agile way, having that flexibility to kick off every couple of fortnights and smash through some work and it's rate chaotically.
[00:14:07] Scotti: I like that you've highlighted that some teams will definitely benefit using an agile approach and some won't. I still think back, Tom, to that time when we were essentially doing a security led security uplift program at Secure Pay and it was like, no, you must deliver security in an agile way. We're like, you can't really do file rules using an agile methodology. Look, sure we can do it in the two weeks or we can do it within a day. But we're not traditionally following the actual definitions as you've clarified them for us around agile. So I guess it's probably really interesting to see where or how some other organizations have done this. And we know that you've worked for one of the large banks here in Australia, so maybe you could walk us through how they went about adopting an.
[00:14:52] Jared: Agile approach in a very waterful way. I think I touched on this just before.
So a new way of working, massive posters of this is how we're going to change and this is the new hierarchy of which teams are broken down and work is broken down and you know, big sing song, dance and then realized that they didn't exactly have tooling to support a big rollout. And also the fact that the different archetypes of how they actually got work from conceptualization, through requirements, through design, through, you know, building something and spitting it out. The other end, there was a big gap there. So that's where I actually did get involved at one of the big banks for one of the larger divisions in unpacking. I think there's about 40 or 50 tribes that had different ways of working and some of them had dependencies on one another.
And so when you've got a waterfall program that's sort of laid out for the next 12 months, getting some kind of dependency work embedded into that waterfall team that are not very agile is quite difficult. So we've got these two types of teams headbutting, trying to find common ground or trying to get them to work in a hybrid kind of way was the trick. And having tooling that could allow them to not only visualize and capture those dependencies, but also visualize and manage the progress of that work moving forward.
[00:16:18] Scotti: So it's interesting you talk about tooling because I agree with you on the tooling front. Because when you're talking about a bank that traditionally risk adverse, they have a whole range of regulatory requirements that they must meet. So they have to follow certain rigorous processes. They need to exercise due diligence in the way that they build and release features and products to customers. So I'm really interested around the tooling aspect because there are a lot of tools that I think that when I did software development, most of the tools, like there wasn't really a thing called CICD pipelines, it was very much in its infancy. We now have huge pipelines and there's a whole range of automated tools that developers now use. So I'd actually be really interested in Hearing what you think, how that's changed, and certainly how the bank addressed those concerns specifically around issues and risks that might have been introduced by adopting a faster approach.
[00:17:11] Jared: Yeah, Tom's going to love this answer. It's a Microsoft product called Excel. And trying to break the chains of using Excel as the glue was extremely difficult because a lot of people will still use Excel even to this day to do a lot of that finite planning or a lot of that integration between, hey, we've got this work, but then we've got the GRC component, we've got the ITIL component. Some of those obviously have now been digitized into tooling more recently, but a lot of it comes down to, you know, the folk that sort of specialize in those areas and Excel, they just keep coming back to the one product.
[00:17:50] Scotti: Do we think that's limited just to the banks or more broadly? And I haven't worked in a bank, but I have a picture of the type of people that would potentially work in banks. So is it specifically limited, do you think, to the finance industry? Because I've seen so many finance organizations not specifically limited to banks, that their whole business, at the core of it is an Excel spreadsheet with a whole range of macros that then drives all of these other systems, which essentially becomes a huge single point of failure, in my opinion. Is it simply limited to banks or is there a better way?
[00:18:21] Jared: It's not just limited to banks. Banks obviously have got a little bit more coin and so they do invest in some of your bigger products like your SAP's and the ITIL product sites. They can afford to outlay a lot of money, but it's the configuration of those toolings that provides the value. That's I think is where the gap is. There's either not enough need or to configure. Not necessarily complex, but a well thought through pipeline because it's only used periodically or people are just so busy caught up trying to do speed to value. A lot of code gets shipped with hacky band aid approaches with a good intent to fix later, but the focus is always on shipping the next thing. What's the next value? What can we push out next? So similar to the whole CI CD pipeline, it's not until you actually get given the time, the space and the need to configure something or establish where a lot of those different ecosystems can.
[00:19:24] Tom: Be brought together, you really need to commit to change. Because you ask people to start revisiting the way they've done things for a very long time, you've got the competing demands of, hey, we need this really quickly.
BAU doesn't stop whilst you're developing a new way of working and you need to adopt that and communicate that across the whole business. And what you tend to find is you constantly fail to reach that escape velocity of embedding and implementing a new system and it just gets used in parts of the business because you need to make a concerted commitment, both financially, resource wise, time wise to adopting a new system. And I think time and time again you could probably attest this, Jared, the ones that have said, we're going to do this, we're going to do this right, we acknowledge it's not going to be easy and we're not going to get immediate results. They're the ones that get the best value ultimately out of their change.
[00:20:12] Jared: Yeah, 100%. Or the teams that do spend the time and effort, you know, putting something together will build it in such a way that it's quite bespoke and niche just for them. And so it doesn't, you know, become scalable that other teams or other areas of the business can easily adopt.
[00:20:29] Tom: You and I are working on piece for a customer at the moment where they've sort of made a concerted effort to move away from click ops when it comes to cloud deployment and move to a more. I think they're using DevOps pipelines and the like through Azure. That's one where they've sought to do that across the business, whether it's operations and infrastructure or app development. And yeah, I think generally they're one of the ones that have been better in terms of buying into it, but they're also sort of facing the same challenges around that competition for resources and needing to do things quickly and needing to respond to BAU incidents and the like. It's not an easy thing, but I like to sort of laud them for the fact that they've committed to that as an architectural principle, that we will, we will do as much as we can via code first. And you've been instrumental in helping deliver that for things like AVD and the like.
[00:21:17] Jared: Yep, 100%. And where those complexities sort of arise is around how the platform or how the ecosystem has been architected.
Sometimes you've got teams that look after shared infrastructure and then you've got teams that require a change to that shared infrastructure. And so they haven't really thought about IAM and allowing outside teams to make changes to those core or shared infrastructures. And so you're right, there is that Sort of dependency of, oh, hey, you need to go and run this before we can run that. And you know, in a true CI CD environment, you wouldn't necessarily have those kind of people dependencies. It would be orchestrated as code.
[00:21:57] Scotti: So you mentioned Azure DevOps. So if you had a blank slate, right, where would you start and what tools would you use and why?
[00:22:04] Jared: It's a great question.
And from a customer's perspective, it would come down to the ecosystem that they're currently operating in.
A lot of our customers are a Microsoft shop. And so using Azure pipelines and Azure DevOps and those sorts of CI CD tools is the logical choice just because it's already part of what they're using. If it was truly a blank slate, I guess this is really me in a biased opportunity would select obviously like GitHub, it's a fan favorite. Sure, Microsoft kind of purchased it at some point, but there's a lot of capabilities within GitHub that sort of allows a lot more flexibility. So tools like GitHub allow a lot more flexibility in regards to using outside components or capabilities to enhance the CI CD tooling. You've got the likes of, you know, Wiz integration, they can do a lot of the early code and DevOps integrations with Wiz that allow for early detection of CDs or exploits or bad code before that code is actually published out into the wild. There's integrations with the likes of SNYK that do very similar.
I found that GitHub is a fan favorite. There's a lot of Support. So with GitHub and code languages, it's quite agnostic. It doesn't prevent you from or lock you into using, you know, one or two. It's quite open anything from, you know, Python, Ruby, JavaScript, TypeScripts, all the way through to your older languages as well.
[00:23:39] Scotti: You touched on development languages. I think that's great. I love that you threw Ruby in there and I know that you did that just so that I felt loved. If you had to pick a development language, which one would you choose as. As well.
[00:23:47] Jared: Okay, you're probably not going to like this answer, but I like to challenge myself. And so depending on the problem I'm trying to solve or the product that I'm trying to create, I'd probably pick a language I've never used before because there's no better way to learn a new language than in a real life situation.
[00:24:06] Tom: And in situations like that, just about any language counts when it comes to me. I've sort of found AI has Been amazing in terms of being able to get me to code in languages that I, quite frankly, I don't understand. As I mentioned earlier, I know how to code in basic, I know how to code in C, bit of php, which Scotty loves, but that's about the extent of it. I've sort of parked it from there. I do a bit of infrastructure as code stuff since, but AI for me has been awesome, whether it's a KQL query or just saying, hey, I need to write this little Python script that does this. Where do you see from an AI perspective, is AI a threat to you as a developer? Is AI a companion through this? Where do you sort of sit on the spectrum of AI, friend or foe?
[00:24:50] Jared: Yeah, for sure, it's a great question.
So AI, when used blindly, can obviously result in a lot of hallucination. So you get the term vibe developers who, you know, it's almost like just putting on your favorite soundtrack and just, you know, going from question to question, pumping everything into AI and just blindly trusting that what's giving back to you is going to work 100%. Publish that onto the Internet and, you know, all of a sudden you've got attacks coming left, right and center because you haven't really taken into consideration how to actually properly secure code AI if used correctly. And from an assistant point of view, you know, obviously I know how to center a div, but you know, just for shits and giggles, asking AI how to center a div and being given four, five, six different methods or ways, you know, there's always an opportunity that the way I've always entered it may not necessarily be the fastest or most efficient way or, you know, over the last 30 years, there's, there's better ways of doing things. So AI is great with assisted developing, being able to give me a boilerplate function that I can quickly rename or just plug in the missing elements. It's a great learning opportunity, especially for those that are very new to the game. But also as a programmer, you know, AI just being quietly on the side going, oh, hey, you know you've forgotten to do something here. It's like, yep, no, you're right, I did. So, yeah, 100%. It can be used anywhere from beginner developers through to the more seasoned.
[00:26:24] Tom: I definitely. You see that as a, as a friend, when you realize its limitations and its capabilities and what it's doing best for you as a developer.
[00:26:33] Jared: Yeah, that's correct.
[00:26:34] Scotti: You need to be able to understand the difference between when it's giving you good results and giving you good advice versus when it's potentially saying, hey, you should just write a SQL query that's straight up SQL and it's straight up got injection in it. So yeah, I find that it is really useful, certainly if I can write Ruby really well. And I liked your answer to this, Jarrod, when you said, I'll do two things. I will use a language that I want to learn because I want to extend my skills. Typically most people will say, I'll just default to the one that I know, which would probably be my answer, which said, I will, I'll write it in Ruby. Unless Ruby really won't work. There are much better languages, There are faster languages out there for sure, but the other one is using the right tool for the right job. And I think that's actually something that I'm super passionate about. Because in today's world, having something that meets the business requirements quite often doesn't typically fit with what your existing development teams may choose as their default go to because they've known it and they've done it for the last 15 years.
[00:27:32] Jared: So you're right. And with a lot of the code that's being produced by AI, if you as a developer or an engineer are not testing that code, whether it be logically testing it firsthand, or writing a test to test that code, you know, that's obviously where you're going wrong. That's that blind trust, that vibe coding coming through. Then the reverse can be said. If you build the code, there's nothing stopping you from asking, AI, hey, can you test my code? Like, is there something wrong or is there something better that I can be doing?
[00:28:02] Scotti: I'm definitely guilty of writing code and then saying, hey, AI, can you please produce me all my test cases, all my unit tests? And it's a great, efficient use of time because I hate writing test cases and in a lot of cases I wouldn't write them at all. So actually having something that's going to do 80% of the work in, you know, five seconds, and then I can go through and review each test case and say, yeah, these are the ones that I like. These are the ones that I need to add. There are some great operational efficiencies that I see developers and development teams gaining from using AI, but certainly not blindly trusting it.
[00:28:36] Tom: How about the ADHD companion being the. Please go back and write all the comments for me because I just wanted to write code.
[00:28:42] Scotti: I may have done that recently as well.
[00:28:45] Jared: Yeah, please, please write my readme and make it Windows friendly because you know.
[00:28:49] Tom: I'm a MacBook user actually that's another good segue. You mentioned MacBook there and had an episode recently where we've backed a horse in terms of our cloud favorites and obviously we're multi cloud here at Cordant and we get to dabble in a bit of OCI and AWS and Azure, not so much gcp. But what's your personal favorite on that front? Or is it a horse of courses type of affair?
[00:29:10] Jared: All of them good developer weren't hard code for any particular cloud platform. Since joining Cordant, I was introduced to OCI and its simplicity, but also its capability was eye opening and so it was a great learning experience of understanding that it was built by developers for developers and that kind of principle first made it really easy to adopt. And so I love using Oracle at the moment and I think that would be my first go to.
[00:29:42] Tom: I'm actually shocked. I don't think any developer has ever said that in their entire careers. So you heard it here first on the DevSecOps podcast.
[00:29:49] Scotti: I'm absolutely shocked that you said OCI was that great coming from a developer. So obviously I'm biased. I worked there. But to hear someone that didn't work for Oracle like that, isn't Tom or I saying OCI is good? Look, I wasn't expecting the conversation to go there. One of the key things that a lot of organizations struggle with, and I certainly see this across AWS and all of the others, is around portability. AWS is great for building lots of services and releasing them at an unprecedented pace. But you say hey yeah, I want to use this AWS service. You don't find that in oci, you don't find that same service in gcp. So how as a developer, if an organization is truly multi cloud, how would you or what advice would you give organizations saying hey, we want to adopt all these great technologies, but we actually want to be not specifically locked into any one provider.
[00:30:39] Jared: Yeah, that's a great question. And I think it comes down to the different capabilities that each of the cloud offer. If we take Kubernetes for example, Kubernetes, you know, we know that runs on aws, gke, Oracle or OCI as well. Using infrastructure as code such as Terraform can be easily and quickly adapted to each of the cloud environments. And so you're only really having to recode a small element in order to be able to lift and shift between the different clouds. Obviously there's quirks and idiosyncrasies with regards to the different capabilities that are running in a container that may need to be adjusted or tweaked, modified to be multi cloud. I don't see a lot of companies being multi cloud day one, but rather factoring into a doctor plan to be able to say, hey, if that cloud provider ever has a significant outage, we can fall back to a different cloud provider should we need to.
[00:31:34] Scotti: So if I'm hearing you right, I guess having that layer of abstraction, so using something like Kubernetes gives organizations the ability to run across multiple cloud providers. And also on prem, which is kind of key for a lot of organizations.
[00:31:48] Jared: And it depends what's been architected or orchestrated for. Obviously if you're using Oracle, you're probably using Oracle SQL.
Being able to pivot across to a different cloud may not necessarily be as easy, but using something like Postgres or MySQL, where each of the clouds and also on prem, it's a very similar technology, can sort of be migrated between or amongst.
[00:32:12] Scotti: Yeah, once again that layer of abstraction using an object relational mapper or something similar makes sense there. So I want to switch gears a little bit and I love working with you. I think you bring some great energy to the team. I really. And we've worked on some great things together. Really keen to get your view on what some of the most memorable parts that you've experienced in your career and also your time at Corden.
[00:32:37] Jared: One of my most memorable delivery experiences was working at one of the large banks. We were using Jira Confluence. We had about 30,000 users. It was the data center version and so there was multiple nodes for each of the products, obviously backed by a load balancer and a database server. But being on premise, we had performance issues, we had latency between our offshore and onshore and it was getting to the point where doing an update, we could only do one every six to 12 months because the amount of effort involved in spinning up a non prod and maintaining the installation and installing, copying and pasting that between different servers, it was very manual, very tedious given the opportunity to modernize on a cloud. And I think we used AWS at the time we chose Kubernetes and about 98% was infrastructure as code. And that was everything from, you know, standing up the namespace, creating the containers, the load balancer that was using istio, so everything was coded. Spinning up an RDS server, all the integrations, the security and the networking, the connectivity back on PREM is all done as code to the point where to do an update like A minor update could be done in a day. And so we went from sort of three months of installing and testing and troubleshooting to a day. Jira being a monolithic Java application, if it ever had issues or needed a restart or ran out of memory during business hours, it would take anywhere from three to four hours. By the time you hopped onto a call, got permission to restart an application during business hours, to actually being able to restart that server on Kubernetes using essentially the health checks, if something's not responding for more than five minutes, flick it off, spit up a new one, hey, presto, back online in 15 minutes.
[00:34:45] Tom: I think that's actually the one thread that ties the great majority of Cordon employees together. And that is, it's not just about doing fun stuff, it's about the impact that that has on the customer of the organisation or people's lives. You know, you talk about, you know, hey, it was great, you got to play with Kubernetes and the like, but ultimately the thing you were excited about was the fact that something that used to take hours or days now happens in minutes. And something that was a great burden on people is now not even a consideration. And that, you know, I mean, that's why I get up and do what I do every day. Yeah, I don't like doing things that aren't going to have meaningful impact for our customers. I don't like doing stuff just for the sake of doing stuff. And really valid call out there. That's something 30,000 users that is making a huge impact on a household name within Australia. And yeah, you must be very proud of that.
[00:35:39] Jared: Yeah, definitely. And just to continue on from that, integrating Jira with other products such as, you know, sort of GitHub and all the different executions back onto the JIRA tickets would require a port to be open between the two applications.
Previously, you would take six weeks to three months to get change records and to get teams and to get onto people's backlogs. Whereas now that could just be a co commit that's peer reviewed overnight and scheduled in the next change window, which would be seven days away. So speed to value has also increased.
[00:36:16] Tom: I just thought of an interesting question too, because you talked about taking something that is traditionally waterfall and introducing agile there. I know we worked with a customer recently that is quite agile and was prepared to take risks in the name of competitive advantage and the like. And what we were actually trying to do there was introduce some rigour and control around things. When we introduced things like JIRA tickets and the like to the organization. Can you sort of describe the contrast of working in the banking environment to working in in some way that is, rather than being introduced there to speed things up to actually almost the opposite, to take control of things and get some structure and some formality around what they're doing at the moment.
[00:36:56] Jared: When you say Agile, there's actually more rigor around Agile. In fact, there's more data, there's more control in Agile than most people think.
So by connecting up a lot of your applications and bringing all that data together actually solves the problem that both organizations need and that's visibility. What are we working on?
What's our fte? What's our throughput? What's our velocities?
[00:37:26] Jared: Where is our effort being spent? Who's our biggest bottleneck? What teams are delivering the most value?
Being able to slice a pie and understand, okay, cool, we want this capability or this feature to be released. Who do we need to speak to in order to make that happen?
What are teams working on that we can take them off in order to redirect their capability?
And so the trick is one, getting the data, but two, creating an ecosystem in which the right people are looking at data and being able to make data led decisions. Because sometimes it is quite whimsical where you have a project manager or program manager, program director, program coordinator, a CTO who based on their gut feelings would just bark orders, do this, do that.
[00:38:16] Tom: The backed by data is right. It's hard to scramble and get that data. And in the absence of data, you make up data and you go back retrospectively and wonder why did things go wrong? And you don't have those data points to say, yeah, how do we not make this same mistake again? So I think that's why it's pivotal in this case. You're right. It's the visibility of that data and bringing that data together and providing a platform for the collaboration of that data, I guess.
[00:38:41] Jared: Yeah, well, we've all heard of a watermelon status report. Green on the outside, red on the inside. And it's not until it blows open that you just realize just how red it was all along.
So transparency and yeah, having access to that data to inform consistently. Not just once a month or once a quarter or God forbid, once a year, irrespective.
[00:39:03] Tom: It's about the visibility of the data that was meant noise.
[00:39:08] Scotti: Excellent, Jared. I think I speak for both Tom and myself. This has been really useful and certainly the comments around the data and actually having the visibility to drive and inform and improve existing and future development process I think is a really, really great insight for people to take away today. But if they do want to get in touch with you to have a have a further chat, how would they best get in contact with you?
[00:39:31] Jared: Yeah, great question. I'm a millennial. Don't call me, send me a text. If you don't have my Number, jump on LinkedIn. LinkedIn will probably be the best starting point. Otherwise you'll find me at various meetups, various events. We've got an upcoming wiz and wine to be great to meet in person if you can make that. Otherwise follow the Cordant trail. We've got websites, Instagram. You can get in touch through our socials.
[00:39:56] Tom: In fact, on our socials you are the proud custodian of the Cordon Bleu Restaurant Review Instagram page as well.
[00:40:05] Jared: Yes, every week we hit up a breakfast joint on Friday morning as a team celebrate our wins for the week.
And yeah, you're right, inaugural breakfast was just not two months ago. And so we post reviews of the various cafes that we hit up along with a few photos.
[00:40:22] Tom: So awesome. Thanks Jared. Thanks Scotty. As always and to all our listeners, remember to have fun out there. But as always, stay safe. Catch you next week.
[00:40:34] Scotti: If you could use a little help or advice with modernizing your IT environment, visit Cordant Au to start a conversation with us.
[00:40:43] Jared: This has been a KBI Media production.
