Today’s guest on Cloud Gossip is Martyn Coupland! Martyn works as Principal Solution Architect at Ensono, and he’s an Azure MVP and DevOps Ambassador at DevOps Institute. Martyn is going to talk about his role at Ensono and what he has learned from that and from his past experiences. We’re going to learn his definition of DevOps and how these roles have impacted the industry, the technology, and the developers. Martyn is going to talk about the Cloud-Native philosophy and how containers are not always the answer. And we are going to hear his opinions about blockchain, smart hardware, and the value of data. Diversity and inclusion are very important to us and we are going to hear Martyn’s thoughts on how to promote them in the industry and in everyday life. Enjoy the episode and don’t miss the links and resources that Martyn shared with us, you can find them at cloudgossip.net.
Martyn Coupland is a Principal Solution Architect at Ensono, Azure MVP, and DevOps Ambassador at DevOps Institute, as well as an author, speaker, and blogger.
Martyn is a regular speaker at conferences and user groups, published author, and has previously worked for a Microsoft Azure managed service provider leading engineering teams.
He works with clients on their Microsoft Azure deployments, works on creative solutions to unleash the power of cloud for clients, and speaks to them about the adoption of DevOps.
He’s been in technology all of his working life, ever since leaving college, he has worked in various industries and worked in a number of roles from a Service Desk Analyst, Programmer, Systems Engineer, Consultant, Architect, and Senior Manager.
Martyn's his career, like many others, started on the service desk in IT, performing first-line support.
Quote
“Whoever you are, whatever your background is, whether you’re male, female, whatever your religion is, it doesn’t matter...whatever you identify yourself as you’ll build yourself a successful and strong career by being yourself. Because being yourself is what makes you “you” at the end of the day .” - Martyn Coupland
Timestamps
Connect with Martyn on Twitter: @mrcoups
Links mentioned in the Episode:
Connect with Cloud Gossip on:
Connect with Annie on:
Connect with Karl on:
Thanks for listening to Cloud Gossip! You can find us from our website CloudGossip.net.
Please leave us a review and subscribe to us at iTunes, Google, or Spotify!
Annie: [00:00:00] In this episode, we cover DevOps, Cloud-Native and mainframes. Here's a quick taste of the episode and then let's get going.
Martyn: [00:00:11] You have to be a good listener, right? You have to just listen to people. An opinion is purely that. It doesn't mean you have to act on the opinion, but if someone comes to you with an idea, at least here it out.
It may be the best idea in the world.
Annie: [00:00:28] This is Cloud Gossip podcast, demystifying the cloud and the people behind it.
Hi, I'm Annie. I'm a cloud native technology marketing manager, and I've worked with tech companies ranging from startups to enterprises.
Karl: [00:00:51] Hello, my name is Karl and I'm a cloud security leader working in the Swiss financial sector.
Annie: [00:00:57] You are listening to cloud gossip. In today's episode, we're going to talk about DevOps.
Karl: [00:01:03] Martyn is a DevOps Ambassador and a Microsoft MVP. He's based in the UK and working as an expert technology consultant with Ensono in the US.
Annie: [00:01:14] Welcome Martyn. Would you like to briefly introduce yourself, please?
Martyn: [00:01:18] Yeah, sure. Thank you for having me guys, first of all....but yeah, you kind of said most of what there is to say there, to be honest.
Yeah. I work for Ensono, they are a managed service provider. I'm actually in Europe and the U S um, and even I'm based in the UK, I actually work with US clients.
I do very odd hours because of that as well, but it seems it is something you get used to.
But....yeah...I do a lot with cloud native as well, so primarily the work that I do is around really trying to make sure that the clients are looking at what else possible with Azure. Obviously the infrastructure services are great but there's a lot to offer when it comes to cloud native, be that containers or, you know, a huge variety of offerings that Azure has as a platform.
And that kind of ties in really nice actually with the DevOps side as well. So as you said, I'm a DevOps ambassador with a DevOps institute, and they're a great organization. If anyone doesn't know who they are. They do a lot of official certifications around DevOps. So be that from a....Just an understanding of DevOps.
They also go into specific roles like site reliability engineering, and also you can become a DevOps certified leader as well, which is really good. And it looks at the non-technical aspects of DevOps, around culture, people and processes as well. So every great organization to be a part of, and they do a lot of events.
Aimed at skilling up your knowledge ...Attendees knowledge really on different aspects. In February they're talking about Cloud-native, and there's a session I'm presenting there as well. And they're all available after the fact on various different methods of medium as well. So there's always something for everyone.
So I'd encourage people to come check that out. If they want to know more about dev ops and the relationships to some of the technologies that people talk about in DevOps as well.
Karl: [00:03:28] And that's DevOps Institute, right? We'll add that to the show notes over there. Cool. You mentioned that the company you are working for, Ensono, that's actually a managed service provider, so....But you are working as a consultant role....
So does that mean that you're going for, let's say those new customers that you might maybe on board as your clients or, or do you have like a specific set of customers that you nurture and evolve all the time. How does your typical set of engagements work?
Martyn: [00:04:01] Yeah, so it's actually a mix of what you said there.
So whether is new customers and onboarding of new customers into managed services. There's obviously internal processes that make that happen. So there's a few things involved in that, but primarily , it's taken across what solution architects come up with from a
solution perspective and add in the detail and the color to that solution and how it exactly works.
Services they are like the technical, the technical ability to be able to implement the solution and ultimately give the client what it is that they're asking for. That's new clients. It could be existing clients or onboarding a new service as well.So Ensono doesn't just do Cloud, they also do mainframe.
In fact that they originally are a mainframe company...one of the biggest in the US.... And they also do private cloud as well, and also public cloud as well. So they sit across all three of the, yeah. Uh, technology stacks and... it's quite a good story actually...to be able to talk about the ability to move all the way from mainframe, ultimately hopefully into public cloud, if that's what the client wants to go.
So there's plenty, plenty of scope to move around within that, depending on what the client wants.
Karl: [00:05:21] That'sreally amazing to be able to talk to folks who might maybe, maybe seeing of a real computer is something that you walk into or has doors all the way from there to the cloud native an the latest and greatest stuff.
Really, really cool.
Martyn: [00:05:37] Yeah. See it's very interesting talking to people internally as well around. I actually think that...When you look at what a mainframe actually is and what a mainframe actually does. And you think they are serverless... They're actually quite similar, you know, that they're designed to run very specific blocks of compute to do very specific things.
If we're talking about Azure and the Cloud....That's pretty much an Azure function. It's obviously a lot more detailed on the mainframe side than that, but fundamentally they do share a lot of similarities.
So I think it's interesting....we always talk about cycles of process or cycles of evolution of technology in IT as an industry.
And I kind of find that interest in the relationship there I guess between mainframe and public cloud. And some of the things the people thought were incredibly hard to do on mainframe even today with free clicks of a button and deploy, beta ....I can put that into an Azure function and have it running in seconds.
So it's quite interesting to see that cycle coming back up at the top I think.
Annie: [00:06:52] Really, really cool stuff. So let's get to it then. What does dev ops mean to you? How do you define DevOps?
Martyn: [00:07:02] Yeah, this is a great question. I always ask people this on my podcast, to be honest. And I love asking this question because one of the reasons I do is because everyone has a different opinion of what dev ops is.
One of the explanations. I actually love a lot , it's actually Donovan Browns. Who's a DevOps manager at Microsoft and his definition of dev ops. I understand he took quite a few days to come up with this definition and his definition is very, very clear and very, very simple. And says that dev ops is a union of people processes and technology to deliver end value....to deliver value rather to end users.
And I really liked that because we don't talk about code, we don't talk about technology specifically. It talks about value.
When it comes to dev ops...for me, it's all about value. And when I'm talking to organizations, It's always an interesting conversation.
Cause you, you have to wear two hats. I think there's one side of the conversation where you talk to technical people on the ground and they want to know about automation. They want to know more about how we can automate, release and builds of our code and automate the workflows around that.
But then you cannot have those same conversations with a business because it doesn't really mean anything to them.
You have to talk about how dev ops is going to help 10 a needle or move the needle.... if you like....In business sense.
How is what we're going to do, support the business and how is technology going to....support the business's goals and KPIs. And that's really what you have to start driving across the business leaders as to why they should invest all of this money in dev ops and agile working and all of the other things that come with it.
Lots of people changes.... potentially training. Quite frankly, it can be a long process. And with that comes a lot of time where there is no visible game.
But if you execute right in dev ops, there is always visible game. You may just not see it at the top level until a little bit further down the line, but ultimately that business value is rallied around...increasing that time to market, make it faster.
Because at the end of the day.... Especially one thing I think the pandemic has highlighted is.... that when it comes to businesses and teams that are high functioning and using dev ops practices, they were able much quicker to be able to react to what happened on a global level and still carry on doing what they do in a great way to all of a sudden millions and millions, more people and a cost....
I think the thing that we can all relate to is confidence in technology where, you know, not just Microsoft with teams, but also Zoom as well, and plenty of others, all of a sudden, overnight, they had hundreds of thousands of percent increase in their user base.
And....you know, minus all the little issues that I can recall hearing about....there is certainly never been any major outages with any of these platforms. And they've literally had to scale tremendously overnight. A lot of that is obviously down to the technology and the platforms that they are using, but a huge part of that is down to how they work.
And that's where it dev ops comes in.
So for me, dev ops is exactly, as Donovan said, in, in his explanation, it's around making sure that you deliver value to your end users. And that value is obviously different depending on your business and your product, but you should always be looking to deliver value.
And my argument to a lot of customers that I work with is if you are creating releases, And it's not easy to determine what the value is then you probably shouldn't be releasing it in the first place.
Annie: [00:11:11] Yeah. Or really cool. It's really an investment that pays off in the end and works. So really good definition.
So how do you think the definition has evolved over time?
Martyn: [00:11:24] So again, this is, this is a really good question. Had you asked me the same question a year ago? Two years ago? I'd have probably said something different...because one of the things I really love about working in the dev ops space is that my understanding of what dev ops is and how it can help organizations.
And what is available to us as professionals to implement and improve the way organizations work just gets better all the time. Much like technology..., technology is getting better and better all the time. There is more you can do than you could a year ago, or even six months ago. It's the same with implemented dev ops.
The more people that try and implement Dev ops, the more you get to learn from other people's mistakes. And that's not a negative comment towards the people that have tried and failed. Infact failure is kind of a nasty word in dev ops. There is no such thing as failure, as far as we're concerned in a dev ops process.
Every failure is just really an opportunity to learn and improve the next time. And that's really where it comes into it. So, you know, how, how was my definition evolved over time? I think I make initially the classic mistake that people make in assuming that dev ops is all about technology. Technology is important, but for me, you have to invest in culture.
And again, in interesting way, because people come back to you and say, what is culture? What is DevOps culture? What does that mean? But for me, quite simply, it is the way that our teams can collaborate and communicate with each other and creating a safe space for that to happen...along with given them the ability to innovate without fear of retribution of messing anything up or....
Something not being quite right, is that environment that makes everyone feel safe to be able to do those things without the fear of being revoked by any of their teams.
So you have to get the culture right first. Then you have to get the people and the skills in your organization, right as well.
And sadly that sometimes does mean people move in all into roles and bring in other people in.
And then you have to get your process right...there is no point automating bad processes because all you end up doing is automating a poor process and end up with poor results faster than if you would do it manually. So you have to be really careful. So for me, it is around getting process people and culture right first, and then adding technology on top to be able to improve in the investments that you've already made.
And by that point, you have good, solid lean processes that you can then make quicker rather than retrofitting all of that around technology first. So, yeah, , my biggest mistake is really thinking that Devops is about technology and trying to do it from a technology first perspective. What I have learned over the years is that you will get a lot more success if you actually do it the other way around.
And that's for me, that's where my understandings has evolved.
Karl: [00:14:36] Yeah. And just to be clear for myself and for our listeners as well. So when you're talking about the culture, are you,it's not you putting on kind of your Antropology hat or anything like that. It's really all about company culture and bringing this mentality, this mindset that you can learn maybe, maybe not necessarily fail fast, depending on your industry and organization, of course, but having this mentality that as you said: "Failure is an opportunity to gather data. What can we do better next time? "
Martyn: [00:15:09] Yeah, exactly. And I think the last thing I would probably say is that in dev ops, we always talk about continuous improvement and continuous feedback. It is those failures that let you go through those feedback loops and learn from what you have done and make it better the next time.
Even if it is only minutely incrementally better. It's still better than last time. So you've still made an improvement. You,do get to the point where you're at such a high level of maturity that there is very little to change about how you dosomething, but as with anything....and especially in business, as most people saw between January and March,
2000....thesethings can change very, very quickly and you need to be able to react to that.
So again, I think that's more proof for me that... Businesses that do this well were able to see that change in business and trade and environment and say, we need to change how we do things."
And they were able to just pivot over to the direction they needed. And it's still successful today because of those efforts that they've already made.
Annie: [00:16:18] Yeah, for sure. It all comes back in the end. So we think, I think, uh, most of our listeners probably you most likely as well think that DevOps has had a huge impact on the world and society. And we would like to ask you about a few things that DevOps has impacted in general. Three things to be precise...
So we could start with how has DevOps impacted the industry as a whole?
Martyn: [00:16:49] So I think, I think the difference is huge. I think. If we didn't have dev ops today...then organizations would look very, very different. And if you get a chance to have a look, there's a great video on YouTube by, Jessica Deen.... who's a Cloud Advocate at Microsoft...and her and the rest of the cloud advocates produce some amazing content, but there's one video in particular that Jessica has done around "developing with confidence." And for me, this explains in such a short period of time, the impact that dev ops can have on an organization.
And let me try and summarize it a bit more briefly. She talks about Microsoft in kind of the 2010 era where their competitors were, frankly, doing better than they were. And...every internal team was fighting against every over internal team. She brings up a graphic and it's quite widely available online about organization structures and they're all silenced and they have guns pointing at each other.... Because they see everything as a competition.
And the key message behind it is" if it hurts do it more often. "
And for Microsoft, that was deployment. So if you think back to those 2010 times skills... You used to get product updates every one, two years, because they kept pushing those minute changes back forever, back, forever back until there was thousands of lines of codes to change and they would deploy them.
And the reason they didn't deploy them is because they knew it would break stuff. So. This all kind of pivots around when Satya Nadella came in ....in a lot of ways. Andshe goes on to talk about some of the changes that Satya made about using common tooling, right there. Microsoft uses actually dev ops to build and release Azure dev ops.
Right. It's kind of an odd concept to get your head around that they use the same tool that they're building and releasing to build and release that tool. So it's kind of wild to think about it that way, but that common tooling and those common practices, . Microsoft, I think called "one engineering system".
And it's how all of the internal teams work with each other, how they all work together and what release cadence they use. It's a really, really great presentation.I would encourage everyone to go out and watch that... If they can, because it really tells a great story. It's not actually the fundamental focus of what she's presenting, but it's a great five or 10 minutes at the beginning of the presentation that talks about the struggles that Microsoft had and their realization that they needed to change.
And like she says, in business, Everyone is now competitive. Everyone's a software company.
And if you're not doing this, your competitors are already and they are out innovating you. And that will ultimately put you out of business. It's a sad reality, but that is a reality no matter..., but I think you have to go.
Yeah. How did we get to here? I think is another key thing. And. I don't know if you heard of the agile manifesto, but the actual manifesto come in around February, 2001. So there's a ski resort in Utah and 17 people met off this retreat to find some common ground....along software development. And what came out of that is the Agile Manifesto.
So there was representatives from a feature driven development practices, adaptive software development, scrum, extreme programming, pragmatic programming, and many of us who realized the need to change the industry. And what they come out with is, is a
number of things that went into building a manifesto.
So they talk about individuals and interactions of processes and tools, working software over comprehensive documentation, customer collaboration of a contract negotiation. I think the last one is responding to change over following a plan and.... they then go into defining 12 principles of agile software that they start to build out some of these in more detail.
And actually, when you think about where DevOps is now, it is primarily built on a lot of agile ways of working. And actually the concept of bringing development and operations together, isn't really anything new. It's molding it in a way that makes them successful.
Before DevOps became...you know, a real thing....I think it was back in 2008. I certainly can't go forever back then hearing the term dev ops used by Patrick Debois ....at agile conference..And plenty of people have tried and failed before so the concepts are not new...It's just the way that we enabled itis what now makes it successful....and...like everything else it is now huge, popular.
And then in 10 has led to, it means something much more widely adopted.... different models being developed to help and work in different scenarios. So for me now it's much more of a framework is devops rather than a set of things that you do.... You can't pick a dev ops off a shelf and put it into your organization...You will need to modify best practice to fit within your organization rather than the other way around.
Annie: [00:22:36] Yeah. It makes total sense. So what has the impact of DevOps being truly to the daily work of developers?
Martyn: [00:22:47] So I think with my operations hat on, I would say that developers are now much more acutely aware of the impact of poor documentation... poor code and poor instrumentation and what that can have on user experience and the day-to-day lives of everyone in operations.
I actually don't know developers that want to go back to a pre DevOps way of working. If they're working that way at the moment.
They like the interaction of operations early in the process, because at the end of the day, if you think what used to happen was. You know, we'd say, if somebody got thrown over the fence ...a release got thrown over the fence, operations knew nothing about it.
Something went wrong during the middle of the night, the developers had gone home it's operations that need to fix it. And they known nothing. They know nothing about what's new, what's changed. What is now no longer there. All of these things are completely alien to them.
And what really, for me, it really helps is the operations have lots of outstanding questions in that scenario, but there was never the engagement with the developers there to be able to just say, "what do you want to happen in this situation?"
"What is it you need me to do?" And I think that's really, really important because when it comes down to it fundamentally, I think you need to have those people talking together to understand exactly what it means to be supporting a bad release or developing based of no requirements. Right.
Everyone's working blind. So when I think about...daily work of developers... Obviously operations are (inaudible)...as well...But developers now have much more clarity I think, around what is acceptable. What level of instrumentation is need to find out what is making this application go wrong? You know, how is it got to where we have now? Without looking at log files , or system errors that say Unknown error, you know, that's no longer acceptable for that to happen.
So I thinkdevelopers are generally, I would say a lot happier working in DevOps teams and dev ops ways of working...Because they have a lot more clarity in what it is that they need to do and how they need to do it.
Karl: [00:25:05] So does that mean that developers are more of a generalist than they were before?
Is that part of the happiness effect?
Martyn: [00:25:15] Um, Well, maybe not generalist, but that, you know, the good developers especially are obviously really, really good at writing software .
And writing software....let's not forget.... I personally think is an art form, right? It's not just about writing code, but it's about writing codes that is logical and makes sense logically. And for some programming languages that even is down to the way the code is written will affect, um, how efficiently that code will run.
So that is a real art form...being able to do that well. But I think with that then rounded knowledge that can apply of being able to say
" oh, but if I want operations to find out more information, I can put it in. ... can put telemetry into app performance monitoring, or I can write out a log file, or I can write out a log file with this information. And instead of saying, Catch all exceptions write to the log file unknown error and we'll deal with it later."
You know, we all kind of know that situation,we've all done that, right?
We've all done it. If someone says they're not doing it, then, you know, they're telling fibs, as far as I'm concerned. But, you know, it's a much better working environment and it creates levels of trust that I don't think organizations have seen before. Being able to have those working relationships really strong, I think creates a great bond and creates a great team within an organization.
And when the team is happy, when a team is performing well, when a team is under less stress, they produce better quality. And that's the underlying thing for me as to why that's really wax for organizations.
Annie: [00:27:02] Yes, for sure. Okay. And then to the last one, out of the three that I mentioned before on the impact of DevOps...and this time on what has been the impact of dev ops on technologies...
Martyn: [00:27:17] So I think, you know, I think this one's quite easy in a lot of ways, you only have to Google dev ops tooling... And, how many pages come up?
I'm sure you've both seen graphics,and info-posters on the dev ops tool chain. There's hundreds of tools and sometimes there's hundreds of tools for the same thing. But one of the things that I think I would argue, I see where people are coming from... you don't want lots of different tools within your organization. But some of those tools do very specific things for very specific platforms.
So if there's a use case for that tool, Then don't shy away from using that toll just because it's a another tool in your environment. But on the flip side of that, there's always think about the 80/20 rule, right? If, you can put a tool in that does 80% of the job and that 80% will suffice for at least 80% of the time, then question whether you need that other 20%.
If you do...It's like buying commercial off the shelf versus writing your own software....again It's the same. If that commercial off the shelf software does 80% of what you needed to. Do you actually need that other 20%. Can you live without it? And if you can, then obviously it's much better to buy commercial off the shelf because you don't need to hire a team of developers.
But if that 20% is what makes 50% of your revenue, then obviously it is very important to invest in that 20% and add those things onto your product. So....you know, always think about it from that perspective, but don't be put off by it at all, because you may be using the exact use case for that specific tool that makes your life a lot, lot easier.
So its impact on technology is huge. And obviously it keeps a lot of people employed because of the number of tools that are out there today.... So, you know, , the impact on technology from DevOps is huge.
Karl: [00:29:18] A lot of DevOps consultants bring home to (inaudible) on them just by updating those infographics indeed.
Martyn: [00:29:25] That's right.
Karl: [00:29:26] Cool, cool. That actually ties quite nicely to the next topic that... I would like to ask you and let me kind of reiterate and introduce to our listeners as well... so you have this blog post or this mantra or rant about, ..."What really is cloud native philosophy?"
And how not everything which has to Predix cloud native is just built to work with
Kubernetes or does it always have to be something to do with containers, et cetera. And.... Before I kind of let you loose and try to let you explain what's the difference between this , cloud native. And how is it related to the DevOps all together? I want to kind of emphasize from, what you said earlier about that possibility nowadays with software as a service, uh, pretty much any organization can just buy....Pretty much the same level of not just the software, but also the operations part of the commercial off the shelf software.
So, whereas before there, you know, running an email server used to be an actual job and we've had some job security and all of that, and there still is for a number of environments, of course. But for a lot of use cases right now, I would just go ahead and as a new organization, new competitor, I would just come in.
Swipe my credit card or whatever, get the same kind of latest version of the same tools that a large enterprise would just need to actually host and draw and build a lot of infrastructure all around on top of that.
And, you know, putting that kind of.....As a side, I'd like you to tell us about this cloud native philosophy and how is it related to the dev ops and how is it not always only related to containers?
Martyn: [00:31:30] Yeah. So, let's do the second bit first. Cause I think that's what was one of the most contentious things that I think is out there... Actually, a lot of customers that I speak to, if, if we start talking about cloud native, the only thing they will talk about is containers. But, but actually, you know, what, what is cloud-native, right? cloud-native is fundamentally it is technology that supports microservices, microservice-based architecture.
So, you know, what, what is microservice-based architecture? Is the ability to move to a more modular approach to how you write code. So a great example might be an e-commerce platform. Okay. So. When you have an e-commerce platform, you want people to pay, obviously. So you offer payment gateway, but you also have physical stars that use a
point of sale system.
And if someone pays with a card, you may well have different software that does the same payment processing. So in a in a microservice world, we would create a payment processor that works both on your e-commerce website and in your store. So that you could use the same piece of code in multiple locations and have multiple end points.
If you like calling that piece of code is how API has come about and what APIS are. So if I think back to some of the work that I was doing a couple of years ago, when I really, a
couple of years ago, and whenI worked at VirginAtlantic we were very API driven with a lot of the things that I was working on.
How did those API start? They were in Azure functions and they were called via web Hawks that sat behind an API management gateway. So it can control, access and authorization....Where the app services that exposed APIs? No, there were actually serverless apps that did very, very specific things.
So it meant that updating those APIs was now very, very straightforward. Because we could use things like deployment slots, which meant that we could do Canary based deployments, which meant that we could move a set proportion of traffic ontoour new feature and test it and get live telemetry about how it was working.
So there's a huge number of benefits like that. Of course you can do that on containers. But I think, I think his containers was the fast, real, huge foray into this landscape that it's become the defacto technology. And I've actually spoken to a number of customers recently. Three customers recently, actually in the past month, since coming back from, you know, the Christmas break and such where...They've talked about their desire to use containers because they write their own software.
But actually when you dig into the requirements, they don't actually need containers at all. They are writing APIs. That is what they're doing. So is containers always the best place to put it? Absolutely not. You need to think about how you're going to support that technology in the future.
How long is it going to be there? How do you want that environment to scale? Where do you want it to be available? Do you want it to be a global service? Do you want it to be local in a certain region? There's lots of different factors involved. So that's the biggest thing for me. It's a defacto technology for cloud native, but actually there are so many more....different things involved. One of the things that actually happens when you start to look at cloud-native technology. So lets take Azure functions as an example. I don't know if you're familiar with visual studio code at all. It's Microsoft's great tool for doing, you know, really great lightweight development and integrating lots of community and vendor driven plugins in the marketplace.
It's free, it is Cross-Platform. I use actually modern visual studio...If I'm writing any code now, I've.... Kind of moved away a little bit from visual studio, except for very specific use cases. And one of the things you can do with visual studiocode, is you can install the Azure functions add-in, and in there you can go to the command pallet. You can click a new function, you give it a name, your language and your trigger and you start coding it and then you can deploy it all from the same interface.
So that is great. Right? It's really great. But what does that do? That means that we can deploy directly to Azure without operations knowing about what we've done.
So cloud native in a lot of ways it actually cuts developers out of the picture. What can solve that problem and bring developers and operations closer together and back it's dev ops. And so whenever I'm talking to clients and customers, I speak to around Cloud-Native... I will always say just as a throw away comment in the conversation, "what are you doing around dev ops?"
And it's quite interesting how many times they come back and the answer is all technology driven...And it's like, okay... That's great, but how are you going to solve the problem of working together? Right. A tool doesn't make people work together better or more efficiently. If you can have collaboration tools like teams or whatever, and Slack and et cetera.
So you can chat to each other, but that in itself, doesn't bring teams closer together. So for me, dev ops and cloud native go hand in hand and the memories and fall out is that...Actually the technology that you can run your services on ...your application is on... Is now closer to the developer and they actually don't need operations to run a lot of this stuff...because it's platform as a service, there is less that can go wrong with it.
Nine times out of 10, especially in Azure or AWS, you can go to the portal and restart it...And that will probably fix the problem that you've been having, because it will just redeploy it somewhere else. That is really big in terms of how organizations work and where they go ...
because all of a sudden you could end up with a business critical service running in a function,an Azure function...
The operations, know nothing about, and businesses will not, and do not want to be in that situation. So that's where dev ops and culture people process....and then technology can help make developers realize that, "Hey, if you want to do this, and that is fine, but these are the operational concerns. And these are the things that you need to address from an operational perspective backup, DR, High availability, all of these kind of things."
Interacting with our workloads, security, you know, all, all of these things monitoring. They're almost dirty words to developers of years gone past, but they are now very important and dev ops helps address those concerns. So that's why I always put dev ops and cloud native together in one bucket.
Because for me, you cannot do. Uh, you can do Cloud-Native well, but you cannot be excellent at Cloud-Native without dev ops.
Karl: [00:38:38] Exactly.I'd really like to point out in this context that yes, you can do a lot of things on your own, but again, just like with any other tool with great power, again, comes great responsibility as well.
Martyn: [00:38:55] Yeah, completely agree!
And again, right. Just like we were talking about (inaudible) earlier on, you know, everyone's written something and put it straight into production. Again, it's one of those things that people just do. But hopefully this makes those scenarios better...is where I'm trying to go with it really....
So it is important to capture those things and make sure that you understand what impact it's going to have to your business and... DevOps will help you address and highlight some of those problems. It will help you fix them, but it will help you highlight them so they can be fixed.
Annie: [00:39:32] So moving on to our recurring segments for now.
So then we will kick it off with future of tech.
So what are the three things in tech that make you the most excited at this moment?
Martyn: [00:40:01] I think number one has to be IOT, internet of things.
I've been looking more and more at IOT recently.Quite honestly, within a software engineering background and just a general interest in what hardware can do when it has software on top of it...Is an exciting prospect.
And I think I've spent half an hour....trying to look for that one thing that no one had come up with yet, which I sadly had not figured out yet....Because most things have already been done, but there are so many things that people have come up with that solve everyday problems, which....I think even even five years ago, we'd have had this conversation and someone would have said...
"Did you know that you could put a GPS collar around your dog and set a geo-fence in the latch to know when it goes out of a certain area?"
And five years ago, he would be like "Oh, don't talk crazy. That's ridiculous!" Whereas now. I found at least five apps that do that. And, of course they cost money. They're not free because you need a piece of hardware, but the one-off cost for the hardware is not exactly expensive.
And the battery life on some of these things that they come with batteries some of them.... They last 10 years, they send the GPS location every 15 minutes for 10 years. And they're obviously nicely waterproof, they fit nicely around the collar.. So it doesn't irritate the animal. That kind of stuff is great.
It is really, really good. So that for me is number one. Number two....I would say blockchain is an also sort of... Interesting area. But not for cryptocurrency...like most people seem to want to talk about. I actually think as a ledger technology, it has a lot of applications in a lot of areas, right?
Cryptocurrencies is great, because it obviously enables a number of different scenarios, uh, to be able to account for what has been spent, where and redeemed where.... But think of that from an invoicing perspective and ordering of work ...supply chain management in general, it has a lot of applications that could solve some real world issues as well.
I think the third one ....it is kind of boring....I think in a lot of ways.... but data.
Data I thinkis becoming the most important tool in a business's armory to be able to develop new services, to be able to improve customer service, increase their revenue. All sorts of things.
So data along with lots of tools obviously is, is really the key to a lot of businesses success , and it will continue to be. Data....if you think about the pandemic, uh, at the moment, right? If you think about all of these locations, like there's John Hopkins university, with these tracking case numbers...Sometimes on a daily basis in a number of countries.
The UK government have a great dashboard, I think is built on Azure actually, from some of the bits I've seen in some of the tinker around with , DNS lookups and stuff, just to see what it's built on and some of the messages that I've seen come through sporadically, if there's been an error...I think (inaudible) is actually built on Azure functions and a number of different architect technology.
Okay. But their track to a very detailed level locally....How many infections there are? How many people have been admitted to a hospital? How many people have sadly died? The trend of that data? How many people are vaccinated? How many people have received a second dose of their vaccine? What is the case rate per hundred thousands in different age categories and groups?
So they're looking at demographic information as well. You know, this is data that some organizations would kill for a couple of years ago. And now all of this information has been made public and it's all data. So, yeah, I think data is one of the things that will drive a lot of businesses forward as well. And it also ties into the thought that everyone is now a software business.
To be able to interpret the data you need software. And to be able to do that in a custom way, you'll probably need to write something yourself, be that be that a report, or be that piece of software to interpret and analyze that data.... You'll need something.... you will likely find something out the box that works directly for your organization.
Karl: [00:44:39] Excellent. That's a very good list indeed.... Moving maybe a little bit. Let's say more wishful thinking more towards the future. If you could wish any one technology through, you know, from science fiction to, you know, fusion reactors, to proper quantum computing, any sort of technology.
No, no limitations on budget or kind of sense of reality. What will that one technology be?
Martyn: [00:45:11] That's a good question. So I'm actually not a huge Sci-Fi fan, but I would have to say teleportation has to be up there. I travel a lot for work or at least did before the pandemic. So it's kind of coming up to a year since I've been anywhere, but, you know going on a business trip, especially out to the States was always good fun ....coming home, not so great.. Cause you know, you've got to get to the airport, you've got to fly all the way back and then drop back from the airport. I don't live anywhere near an international airport, so it was always a couple of hours to get back from London. So it ain't just feels like wasted time if I'm honest....you know, I love travel, but if I could literally think of where to go and press a button, ...put it in and be there.
That would be awesome.
Karl: [00:46:05] It's very hard for me... I would still need to have wished that there will be some sort of industry about teleportation lounges where you go ahead and wait, sip that champagne and then you press that button.
It's an experience!
Martyn: [00:46:20] It may be the airport lounge of the future. Who knows?
Annie: [00:46:24] For sure. I wouldn't mind teleportation at all. It would be really convenient. Yeah. Yeah, for sure. But then moving on to that second recurring segment...diversity and inclusion.
So Haveyou encountered any really good projects or initiatives in diversity or inclusion space recently?
Martyn: [00:46:59] So I think. There's so many out there at the momentI think. And I think one of the things to remember first and foremost is...As an industry, we've obviously come quite a long way in technology, but we've got a lot further to go... a lot, lot further to go.
I don't subscribe to the discussions I've seen online where technology is a leader in diversity and inclusion, and it doesn't really need to do all else. And it's already done a lot and ...you know what? We have done a lot, but there is so much more to go. I actually think from a project perspective, there's so many (inaudible)that I like.
And somebody that I support in terms of what they're trying to do. But again, I think we're in the perfect industry to apply technology, to make this very easy for people. You think one of the biggest areas that you get a level of criticism and a level of a sexist or racist behavior is probably in the hiring and recruitment process.
So having software that has the ability to rank and show candidates based on pure ability and pure skillset without showing the recruiter, their name, their age, where they're from, because obviously ... those three pieces of information give you a lot of detail about their ethnicity, what their religious beliefs may well be.
People will start making assumptions and it is those assumptions that are dangerous. So anything that can take away that for me, from a software perspective is a really good thing. But I think from the one project that I actually do quite like is in (inaudible) themselves, actually do a bit internally in this space as well.
There's some things that we do around surveys, trying to make sure the, we get feedback as to how the company is performing...and they will act on that feedback, scheduling up certain events and opportunities for people to engage with each other on passionate projects that they share.
We have a weeklyE-Talk slot, which is a half hour for someone in the business to talk to anyone who can attend. It's open to all associates and you can go on and you can talk about something that you are passionate about and it is giving people a stage to be able to talk about it in a confident manner.
And there's been some diversity and inclusion topics on there as well, which should be really good to hear people talk about them. But yeah, I think fundamentally. You know, as a human race, we have a lot further to go.
We are heading in the right direction. You could argue we've gone a step back in the last couple of years in some areas, most definitely for one thing or another....but you know, I think generally we're trending upwards.
But there's a lot, lot further to go and hopefully through, you know, advocates like ourselves and when it comes to Microsoft other MVPs, I know we have a diversity and inclusion code of conduct, right?As an MVP.... that we talk about and we follow. Hey, it's important that everyone's voice is heard equally.
And I certainly think that the program does a good job of doing that for my interactions and experiences so far. So, yeah, it's really important, but we do have a lot further to go.
Karl: [00:50:44] Exactly. It's to be hopeful, on these topics.
I seem to recall a certain bookstore that, that also dabbles with the public cloud, trying out this recruitment algorithm approach, but... sadly, because they use thrill training data, which is already very biased.
So they used the data, about....they used the same training data that they had for their existing hires. So they end result was even more bias than before. So they needed to ...pull the plug on that one. But, hopefully we will get to tackle that, someday in the future as well. But maybe taking it a little bit more realistic.... would you have any specific tips for us or our listeners to, what can we do in our daily lives to be more inclusive?
Martyn: [00:51:37] So I think .... you have to be a good listener, right? Just listen to people. An opinion is purely that.
It doesn't mean you have to act on the opinion. Um, but if someone comes to you with an idea, at least, at least hear it out. It may be the best idea in the world. What would have happened if.... you know, someone turned around and told..... I don't know the best product in the world that it is, you know, you're not going to do it just because it come from,..... a minority member of society, you know, that this is a bad place to be in.
So. In terms of personal tips, right? I think diversity and inclusion for me also includes, you know,people who potentially are not that confident... have trouble speaking up...
It's not just the obvious...it's those kind of things as well
Karl: [00:52:33] neurodiversity.
Martyn: [00:52:34] Yeah, exactly. You know, be just be yourself at the end of the day, right? No one wants you or expects you to be someone you are not. And you will build a career whatever you do, whoever you are, whatever your background is, whether you're male, female, whatever your religion is, it doesn't matter.
Whatever, whatever you identify yourself as you will build yourself a successful and strong career by being yourself, because being yourself is what makes you, you at the end of the day.
Annie: [00:53:08] For sure. I think that's a really, really good thing to always remember. So good advice there. So then there's a last recurring segment and did the last question toour guest of today.
So it's the community corner segment.
Would you like to give a shout out to communities close to your heart?
Martyn: [00:53:44] Um, yeah, definitely. So I think. You know, as we've all spent more time inside in the past 12 months or so. And we've all spent more time virtually, I think a lot of us are into virtual communities. And one of the things that I'm really proud of is the Microsoft community has a lot of stuff going on, whether it is supporting females in STEM, whether it's introducing children to code projects, uh, whether it's other people in the community doing podcasts or videos, anything like that, you know, I could go on and list lots and lots of people that do amazing things.
I don't want to do anyone a disservice by missing out what they're doing, but if you are on LinkedIn or Twitter or Facebook,you should check out the hashtags CloudFamily and Azure family.
Right? All of us that do community content post (inaudible) those tags. So you will find a whole host of absolutely incredible content from incredible people. And I think I speak for everyone that is involved in creating that when I say it is the interaction we have with people that look at our content and feedback on our content and ask us to write specific pieces of content that makes us do that.
Makes us want to be MVPs or AWS heroes or whatever...or Docker heroes...whatever it might be. We all have a passion for sharing what we know and what we love, and everyone is super friendly, so never be afraid to reach out to anyone. It is a great community to be part of. I love being able to just look at that hashtag on Twitter.
Azure Family or Cloud Family and just look at some of the questions, people just ask questions and there's all kinds of people replying back. I've seen people in the Microsoft product groups for various different products, replying back to people on there, reaching out to them via direct message it's to get more feedback.
And you know, this is, this is how technology should be. We are using technology to make technology better and more accessible ....and the people that make these things more accessible. So that for me is certainly from a community perspective, I guess, our own community and the amazing people that are in it.
And certainly what I would like to highlight.
Karl: [00:56:22] Excellent. We'll be sure to add the cloud family hashtags and pages to our show notes as well. Good. So it's time to wrap things up then. Today, we talked with Martyn and we learned all about the DevOps trust and tools. We discussed the cloud native mindset and how cloud native doesn't always have to mean containers.
And we even talked about how we as a tech industry have evolved, or rather have not maybe evolved since the mainframe era. Pleasure to talk with you, Martyn.
Annie: [00:56:56] Yes, truly....It has been a pleasure, Martyn. Thank you for being here.
Martyn: [00:57:02] Thank you both as well.
Karl: [00:57:08] Hey, thanks for listening to cloud gossip. You can find us from our website, cloud gossip.net. Please leave us a review and subscribe to us at iTunes, Google, or Spotify.