Episode 069: Developer Perspectives on Cloud & DevOps | CloudSkills.fm

Mike Pfeiffer on April, 01, 2020

In this episode I catch up with Elkhan Yusubov to understand the developers perspective when it comes to working in cloud and DevOps.

Elkhan is a Developer Advocate, Speaker, and Microsoft Certified Trainer (MCT) with 18+ years in software delivery/automation (including healthcare, tech-training, manufacturing, retail).

Don’t forget to subscribe to our mailing list at cloudskills.io/subscribe for weekly updates, exclusive training, and advice on how to amplify your career.

Full Transcript:

Mike Pfeiffer:
Hey, what’s up everybody? It’s Mike Pfeiffer and you’re listening to the CloudSkills.fm podcast.

Mike Pfeiffer:
What’s up everybody? It’s Mike Pfeiffer. Welcome back to another episode of the CloudSkills.fm podcast. Super excited to have you here today as usual. On today’s episode we’ve got some really great content for you. We’re going to be taking a look at things from a developer’s perspective when we’re talking about DevOps. I have Elkhan Yusubov with me. Elkhan, how’s it going man?

Elkhan Yusubov:
Good, good. Thank you. Thank you for having me on the show Mike. I think we are going to hit some very interesting topics today and it’s going to very exciting to look at this DevOps moment from developer’s perspective and give it a little bit flavor from developer perspective. Yeah.

Mike Pfeiffer:
Yeah man, I really appreciate it because we’ve been doing lots of infrastructure conversations about DevOps on this show and I know that you got tons of background as a developer. So for the folks that don’t know you, maybe you could talk about your background, how you got to where you’re at today and actually what you’re working on.

Elkhan Yusubov:
Sure. I got into development from the early 2000s. The first thing when you start at that time, you didn’t have the SQLs and developments. Everything was starting pretty much from command line. We had Visual Basic. And pretty much, getting input from the command line. Your first name, last name. Basically learning the stuff. But later on once this new frameworks came up and new, rapid application development, language, frameworks appear, then we gradual moving into more enterprise, doing things that are more reliable and you’re persisting a session and stuff like that. Then there was, I would say mid-2000s close to 2010 that is web booming, right? You get a lot more web applications. So the constant change. Part of me, I was lucky that I stick .NET framework.

Elkhan Yusubov:
Basically I was learning what’s going on in the pipeline. In 2005 when this .NET framework 2.0 came around, it was kind of big change. It was change. Shift from the desktop more into web environment. On my end I would say I just followed this trend. I tried to learn what’s going on and I tried to pass some exams, get certification, understand more deeply what’s going on behind the scene. That’s how I grow my career.

Elkhan Yusubov:
Of course part of it is not just developing the app but also how you’re delivering that shipping to the end users. How it is going to run and how your DevOps, how your operation people, I would say, going to handle situations like when application stops working or some issues right. Like networking issues, you name it. That the base is not getting connected and stuff like that.

Elkhan Yusubov:
At that point I get more involved into the operations part of it, not just developer and then trying to move things to make sure it’s easier to host, it’s easier to manage, it’s easier to run the application. That’s my background. Yeah.

Mike Pfeiffer:
Yeah. Awesome. I was doing .NET development back in the early days. To your point .NET 2.0 and really a big shift, right? A lot of stuff going web-based versus desktop, which had been really ruling the development world, especially in the Microsoft space. I bet that … What I was doing in that time was complete manual deployments, a lot of point and click, total RDP into the server and manually installing stuff. I bet you’ve seen a lot of that in the early days and then massive change over the years. Maybe talk about that a little bit.

Elkhan Yusubov:
Yeah, just to your point, if you remember the old days where we have this CONFIG file right? And then you actually do have it right now. So it’s still [inaudible 00:03:43]. What was happening is this CONFIG files, we were having some transformation of these CONFIG files based on the environment, and then were injecting or adding an editor scripts. If this editor scripts was already call automation, I would say. Changing the environment connections, changing the database connection and all other connections that your app requires to run.

Elkhan Yusubov:
That all the happening basically just by this change of configurations and transforming them. That what was behind the scene. At that time the good practice was that, okay, whenever you do your deployments or whenever you are trying to connect a different environment, make sure that your transformational’s CONFIG is in place, it is secure, it is not checked in somewhere in source code that’s irritable. And that was a recommendation, we didn’t have anything like Key Vault. We didn’t have anything like [inaudible 00:04:34] where you can rely securely and don’t worry about exposing your credential and stuff like that. That was the way to go. Yes.

Mike Pfeiffer:
Yeah. It’s easy to forget about how good we have it right now. To your point, we’ve got things like Key Vault now and all this cool stuff. I think one of the main things that’s really interesting about this is that as we talk about this, like I mentioned before, we’ve had lots of episodes. We’re talking about infrastructure and code and stuff like that.

Mike Pfeiffer:
From a DevOps perspective for a developer, you know we’ve got things to think about like static code analysis and code quality and worrying about vulnerabilities. Maybe you could speak to some of that. As a developer, what are you thinking about today versus back in the early days? Today you’re thinking much differently as it comes to getting the application built and deployed, all that kind of stuff. Is that something that you’re dealing with?

Elkhan Yusubov:
Yes. Yes. Today’s completely different. Today I would say we are trying to rely more on managed services like the one that we rely on now is called SonarCloud, which is a static code analysis tool that you can run pretty much on every build. On every build that you’re on your feature branch, I’m not talking about not deploying to production or some higher environment, just on the feature branch where you want to make sure that your integration of new code pieces for the existing app actually goes smoothly.

Elkhan Yusubov:
At that point, at each build, when we’re on our code coverage, our unit tests, our static code analysis, and if you are dealing with containers, there’s a container scanning. I forgot the name, but there’s a container scanning basically recommendations that you follow. So all of these steps basically are just adding quality into your code, into your build process. That’s ended up to be much better code, much better results and happier team I would say.

Mike Pfeiffer:
Sure. Yeah, makes a lot of sense. I guess now that I think about it, we should probably back up. There’s probably a lot of people like, I’ve heard static code analysis, but I’m not sure what it is. Or they have heard about the feature branch workflow and have heard of pull requests, but I’m not really sure what that is. Maybe we could just like high level real quick, just level set.

Elkhan Yusubov:
Coming back to pull requests. It’s something that in Git world that’s very popular. What it is, is basically once you have your main application which you wrote, and then for each features, for each new pieces of code, you basically get another branch out of that branch and then do your development there.

Elkhan Yusubov:
Then when it’s ready, once you run your code review and all these processes that you have in place with your team, when you merge it at that point it’s basically the pull request goes against. That pull request is something where you want to run all your quality measures. I would say quality processes. That’s actually automated so as a developer you also learn from the processes. What pieces in your code are lacking, where are the vulnerabilities, right? Or where you may have potential box that would expose your credentials or expose your valuable connection formations that you don’t want to go out.

Mike Pfeiffer:
Makes sense. Right. So when we hear people talking about shifting left, one of the things they’re talking about is what you’re saying, is as early as possible in that continuous integration process, making sure that we don’t have any weird things going on that’s going to be a technical debt issue down the road. Right?

Elkhan Yusubov:
Yes. Just to add to your points. Basically failing early. Make sure that you can fail early so you can learn before you hit that production or staging environment. You know what’s not working. As a developer you see it, you have a chance to correct it and learn in the process.

Speaker 1:
Developers, you see it, you have a chance to correct it and learn in the process.

Speaker 2:
Yeah. That’s what’s so great about that is, that continuous just feedback of, is that working or not? And if it’s not, just tweaking it and trying something else. One of the other things too that I would love to ask you about is, it seems like the responsibilities for a developer is getting way big.

Speaker 2:
Before it was just, okay, focus on this thing and now you’re stretched into, you know, full stack software development. And you’re thinking about infrastructure more than you used to. How are developers dealing with that?

Speaker 1:
Yeah, I would say it depends where you are. If you love to do that thing, then you would feel that you know, you’re just adding something very valuable into your tool skills. And as you mentioned, the biggest point I would say, is a learning process within these tools and [inaudible 00:00:52], this is where as a developer, you may not be exposed to let’s say, multi-scale or very big projects, where you have multiple team members who are knowledgeable in different sections of the code.

Speaker 1:
Or let’s say, it can be security, it can be trapped, owner built it, it could be multi-treading, it could be handling errors in a specific way. So there are different ways that you never had the chance to work on or through this static code analysis and through these managed tools, you are gaining that experience to these feedbacks, you know, that the tool is providing to you. And then in addition to the beautiful things about let’s say, SonarCloud is that, it will tell you why it is wrong.

Speaker 1:
And what rule is broke. And if you see that the rule is not applicable to your case, just because it still doesn’t mean it’s always going to tell you …There are false positives, that you need to be aware about. And at that point, you need to make just a conscious decision, you need to make a knowledgeable decision and saying, “Okay, this rule I can flag now because it’s not applicable.”

Speaker 1:
So gives you that I would say, trust or it builds the trust in the team, that at least you … It’s not just, you looked at that and your few team members looked at the code but it’s basically, you are relied on a up to date community of developers who are maintaining this SonarCloud. And whatever you build is up to the community standard. And plus, there are these are like these [OWASP 00:10:19] group. So basically those standards are also applied there.

Speaker 1:
So it’s not just developer perspect but also secured the perspective in it and dev ops perspective in it. So you get all this good recommendation out of the tool, that just I would say, it’s invaluable and it’s something that you would never be able to get, if you just work with it 10 years ago or so.

Speaker 2:
Yeah, that’s definitely true. And so for anybody listening that hasn’t heard of SonarCloud, we’ll put a link in the show notes. But I mean, it’s widely used in the industry and it’s a first-class citizen, if you will, in something like Azure pipelines where you could just plug in the tasks and call out to SonarCloud and do that stuff really easily. And to your point, you can publish the reports right there and you could use it with any system, I guess, right?

Speaker 1:
Yes, that’s correct. Yes.

Speaker 2:
And so, are doing a lot of work inside Azure DevOps these days?

Speaker 1:
Yes. Inside the Azure DevOps what we do, basically with Azure DevOps, what we did, the biggest thing that I liked and I kind of find it invaluable is that, part of this developers ecosystem, when you’re getting your code prepared to be deployed, automating each step. Meaning that, once this code is checked into your repository, to the code base, kicking these bills automatically to Azure DevOps pipelines and then seeing the end result, where it’s actually deployed into your dev environment.

Speaker 1:
Or later on, promoted the test environment, where your quality analysts or tester, whoever is going to test it, is able just to go and start testing, without any intervention. I would say that saves a lot of time to us. And this is something that I believe the end goal of CI/CD, right. Where there is no intervention. There’s like on the first checking of the code to the repository, when a new change happen, when you build this, kicking off, it’s running all this code analysis and everything.

Speaker 1:
Code coverage unit tests, whatever, you name it. Whichever code quality steps you have in your pipeline, they go through and then it’s ready for the testing. And part of the testing actually, because I mentioned [inaudible 00:12:31] is automated testing. So within this CI/CD pipeline, putting this automated testing and it could be like UI testing. It could be something that you run on your selenium or if it’s a mobile app, there’s actually mobile app …

Speaker 1:
Because we also develop mobile apps. Part of it is, you have an Appian framework, which will run on your virtual device through app center, which is another tool for that. That’s all in valuable. A lot of automations goes in it and it cuts a lot of time from your starting off code, first line of code that you put and having this, I would say, output.

Speaker 1:
Having your product with your service, your website, your mobile app, you know that gets released, being there already. You run certain tests and certain quality measures already baked in.

Speaker 2:
Yeah, it’s pretty cool, what you can do with different projects and stuff. One of the things I’ll add to the show notes, where they do a really good job of just showing off Azure DevOps is, azuredevopslabs.com.

Speaker 1:
Yes.

Speaker 2:
Where there’s just bunch of kind of step by step labs that really take you through a lot of these things. So you can get some hands on practice. They’ll actually spin up a devops organization for you in Azure DevOps with code pre-populated and stuff. But I’m curious, when you work in Azure DevOps, there is the classic pipelines and then there’s [AMO 00:13:46] pipelines. Right?

Speaker 2:
So Microsoft’s been kind of transitioning [crosstalk 00:13:50] actions, right? Microsoft owns GitHub now. And so, I guess what are your thoughts on pipelines as code and maybe some of your experience with that so far up to this point?

Speaker 1:
I think pipelines as code is a next evolution into the CI/CD pipeline that the team are doing. I would say, first step probably in the learning, the way that with our team that we went through is, you service it, like manual adding each step into your pipeline. And then just making sure your CI/CD pipeline is running. But to the point that you want to have it as a code as a configuration, where everything is coded, it’s in your report.

Speaker 1:
The next step evolutions that we did was that thing. And the beauty of that is that, if you already have something in place and let’s say, you build it through manual step, you can go and look at each step and get from there the [AMO 00:14:39] code because it’s just provided by that devops pipelines. And then just integrate that into your build process and then run it.

Speaker 1:
And get into point that, whenever you want to spin up a new CI/CD pipeline, you can rely on that script and you will have your variables in place for each new environment. And then you just supply these variables and kick the, I would say, provisioning step and your new CI/CD pipeline for new environment would be ready.

Speaker 2:
Awesome. Yeah. So switching gears just a little bit, I’m curious like your thoughts on the current infrastructure that you’re able to use for these applications. So there’s containers and Kubernetes or serverless at this point.

Speaker 2:
That’s obviously a big deal, because that changes the landscape. What’s your favorite to go with and what do you think about both of those options for a developer?

Speaker 1:
As you mentioned, the Kubernetes and containers are very buzzy now. Everybody wants to be in that playground, that where you have your containers and everything, which is cool. From my opinion that, you can’t look at that as like bullet point or silver bullet point that will solve everything. So it depends what solution you are trying to deliver.

Speaker 1:
And I will give you a simple example. Let’s say you have your single page application, which mainly has this static page and plus Java Script, CSS, whatever it has, that’s get bundled during your build process and it relies on a backend service.

Elkhan Yusubov:
… that get bundled in your build process and it relies on a back-end service, which might be a Node.js service or it can be a web API, the way you have it behind the skin. In our case we use Node.js. So your Node.js as it’s a web API, you can definitely rely on containers, right, where you basically build your first images based on that solution that you are trying to provide. And that images are basically used as a containers from your Azure container repository or whatever then, or it can be Docker hub, depending which one you have and then pulled off from there and orchestrated with your Kubernetes, right? So that’s what I would say would work very well.

Elkhan Yusubov:
But if you would try to do the same thing with your single page application, I would say it’s going to be… It would work, but would it be an efficient solution or not? That would be the question. At that point, what I found, that it’s not. And the reason is that there’s like storage account in Azure world, which is actually serving just a single page application and it’s more cost efficient. It’s less trouble. I would say it’s much easier to do and there’s a big efficiency behind that. So from that perspective, I would say yes. From that perspective, yes. Kubernetes containerization is very important to have as a tool belt. But you could not treat each project in a way that you just put it into images or containers and try to use your Kubernetes.

Mike Pfeiffer:
Yeah, it’s an important point because I think if you kind of just listen to social media, sometimes it’s easy to like think, “Oh, there’s nothing else.” Right? But serverless is compelling. And to your point, instead of running a single page app in a container and wasting all those resources, just throwing it in Azure storage and that’s already a managed scalable system where I don’t even need to host a web service. I could just literally put my static website up there, my single page app or whatever. And then the back-end for that could be something like an Azure Function app, right? Or maybe we call on those functions through like an API gateway or something like that.

Mike Pfeiffer:
But what do you think about the whole Azure Functions development experience and even like the DevOps scenarios around? Are they deploying to function apps and stuff like that?

Elkhan Yusubov:
I would say Azure Functions a revolution in terms of how they host APA, back-end services that are based on the unpredictable traffic. And what it means, it means that one day you may have, let’s say not just 50 concurrent users. Next day you get like hundreds or thousands. For that type of scenarios, I would say it’s indispensable. In our case, at least from my experience, we use Azure Function a lot for the data ingestion purposes. Or if you don’t know the load, how many requests would come in? And at that point splitting your functionality behind your API gateway and scaling to Azure Functions is something that in a real world, if you try to do your own, you’d have to spend a lot of time and hours to set up your back-end services. And most of them are going to be redundant because you don’t get high traffic each day.

Elkhan Yusubov:
But on the days when you need that infrastructure in place, then Azure functions will be there to support you and it would basically [inaudible 00:19:11] because on the other days you wouldn’t have to run that much… You wouldn’t need to have that much infrastructure. It will scale back whenever traffic is low and then you would basically pay for what they would use it for.

Mike Pfeiffer:
The pay for what you use thing is super compelling. And if you’re doing kind of like the default consumption model, which is pay for your code when it’s executing, they give you a bunch of free executions, right? What has been like the main challenging thing for you working in Azure functions? Like the biggest maybe frustration or something you could add in that might help somebody listening get around some kind of major issue that you ran into?

Elkhan Yusubov:
I would say there’s certain things that when you run, you head into that issues when you basically work with them, right? So some of them that I faced is like the versioning of Azure Functions is very important because certain things, like for example durable functions, you need to make sure it’s a version two. If you tried to run it when you set it up and put this extension, durable function extension, you will see that there was a bunch of errors. And to some search in Google you would find out, “Hey, the issue’s that you’re using wrong version.” You just get the latest version but it’s not meant to work as that thing. That’s one thing.

Elkhan Yusubov:
And next thing, I would say there was like big leap toward improvements with version two. When I start to use the Azure Function for like 18 months ago or so, it was in a version one and there wasn’t that much support to that. And another piece of that, if you were using Node.js as their run time and it has own kind of limitations. At that point it was more like understanding how to use that efficiently. But for just to give credit to the Azure Function team is version 2.0 they made a lot of improvements and including in our connectors, your bindings, your triggers and stuff like that. So that it became very later on, they say that by making this decision to go serverless as Azure Functions, we just save a bunch of time and bunch of headache in the future which is basically handled by Azure Functions for you.

Mike Pfeiffer:
Yeah and one of the things that you mentioned there and we talked also about the consumption billing, which is pay for code as it’s executing. You mentioned durable functions. And so one of the things that comes up in the conversation of serverless is cold start. So maybe we can unpack that for anybody listening and then also talk about what are our options in Azure to get around those issues?

Elkhan Yusubov:
Yes. One way, as you mentioned, it depends on your application type, I would say, how much cold start it can tolerate with your users, right? So if the user expectation’s instant, to get this instantiate or they are looking for the response right away, it’s kind of like real time. At that point you can still use Azure Function but you need to change how you host that, basically at the point of… And you can do that at the point when you provision them through service plans, right, that you have.

Elkhan Yusubov:
And there’s like different service plan. There’s like premium one that came up maybe six months ago or so, which comes very powerful with 14 gig RAM and I don’t know, 8 core CPUs and stuff like that. But of course you have to pay for that. So it’s going to cost you some credits. But if you just run regular function… And for certain functions you want to make sure there is no cold start issue, you just need to provision with a service app plan. Plus you need to make sure it’s always on. There’s such a option there. And then you, for that certain… And probably you don’t need it for all Azure Functions. You just need for the initial ones where you keep the process or you want to make sure that the end users are getting this response right away. Right? Notifications. Yeah, at that point you just use that and for the rest, you just use a consumption plan because that’s the most recommended way to save one infrastructure.

Mike Pfeiffer:
Right? Yeah. I do hear people talking about that a lot, about cold start and stuff like that. But you had a good point there and not every single function is going to be something someone’s interfacing with because it might be an event driven invocation about function. No one sees it. And so that doesn’t matter if there’s a cold start. And then like you said, also about six months ago or whatever, at Ignite, they [inaudible 00:23:20] Azure Functions premium, right, which is like the Cadillac. You pay a little bit more money, but it’s like there’s no cold start because the whole environment, whatever you’re running in there is loaded and you’re good to go.

Mike Pfeiffer:
So yeah, that’s awesome. I haven’t looked at the version three run time and what’s coming with that? Any major cool stuff coming down the road on that?

Elkhan Yusubov:
I would say mostly it’s improvements and according to the Azure Function team, they recommend to basically test your functions, which will lead to version two compatible. Most of them are going to run out of the box. I would say certain thing that doesn’t work there is like durable functions. If you already use durable functions on a version two, they are not going to work on that V strip platform yet.

Elkhan Yusubov:
… work on that … on these three platform yet. And there a few minor things that I don’t remember from top of my head, but that’s I would say mostly whatever works on Veto is going to work on these three. Taking into account that you take your diligence and run your tests.

Mike Pfeiffer:
And you’ve got to do the legwork right, to make sure. But I actually was super pumped when PowerShow came back in version two runtime and I’ve been using that a lot on projects. But I guess one of the questions I have also, thinking about this stuff, because I work with customers sometimes where the development team is not … you would expect… it seems like everybody is doing dev ops but the reality is not.

Mike Pfeiffer:
Some development teams, they’re still doing things old school. So for somebody that’s on a team and they’re listening to this, what’s a way that somebody could start to get that conversation going or maybe starts the dev ops process in a smaller team?

Elkhan Yusubov:
I would say the good part is getting this full stack mindset in place. And what it is, is basically not just this code is running on my box, but also it is packaged in a way that once you deploy it, it should have the same behavior on the host environment, wherever you want to run it. So once you bring developers into that conversation, so how they can package the code, the way that it’s containerized or all the dependencies are well documented and they are part of the deployment process or not get forgetting, at that point I would say they get more deep into the understanding of how the operations will happen and then they can I believe, contribute into dev ops process at that point.

Mike Pfeiffer:
Those are great tips. So what do you think about certification? Do you think that, that’s an important concept or thing for people to pursue that’s … or going after DevOps, type of … or education? Are you a fan of the certifications that are out there?

Elkhan Yusubov:
Yes, actually I am. I would say the most of my career when I was building that certification helped me a lot in terms of understanding the gaps on … gaps in my knowledge and plus gaps in the framework or tool that I’m using. Because usually again on the anything that you use during development process, you just touch the corners or a technology that your project requires and you don’t see the full picture.

Elkhan Yusubov:
To get this full picture of the holistically about this framework, holistically about the tool that you are going to invest your time in, certifications are, I would say invaluable. Not because you pass your certification but because the knowledge that you gain and you get this understand, in their understanding at what time or at which cases scenarios you need to apply, what options and what is the … and what’s the … and why. Why it is the inner commended way to go with that.

Elkhan Yusubov:
You get deep knowledge about that and that I would say that from certification perspective is very valuable and maybe, not maybe but part of even like these Azure devOps expert certification which I put on my pipeline to have later on this year is that you can go to that one from the developer’s perspective, so part of the certification I would say for the developers, if you look at Azure DevOps pass is Microsoft expert certification is actually once you pass your Azure developer certification and then you go to the next one which is AZ-400, I believe, then you can still get your Azure DevOps expert certification.

Elkhan Yusubov:
Meaning that part of this Azure DevOps is not just to administration and infrastructure and then learning DevOps, but also being as a developer understanding this DevOps process and then trying to get certified into that. So from that perspective, that’s my path that I’m following now. And I would say this is invaluable to get the full picture and be basically more valuable team member for the project where you are, for the company where you are. Certifications are always big plus in my … from my opinion and from my experience. Yes.

Mike Pfeiffer:
Likewise, and I think everybody listening knows my stance on the certifications. I talk about it a lot, but I had the similar experience, and it’s always pushed me into stuff and I’m glad it did. And to your point, AZ-400, the Azure DevOps professional certification or the expert certification, it is gnarly but totally worth it because you have to … you end up having an appreciation about at least somebody else’s job in the IT organization regardless of what background you’re coming from.

Mike Pfeiffer:
And I think, if you’re an Azure practitioner, even if you just do it so you know what developers are working on or you just do it so you know what the infrastructure people are really spending most of their time on, that is the big takeaway from it. It’s not necessarily, hey, I’m going to wear every hat in the organization, but it’s just, I’m able to talk to other people now, and understand what they’re working on. Which kind of leads me to my next question.

Mike Pfeiffer:
I’m sure as a developer over all these years and actually doing a lot of DevOps work in practice, that the cultural side of this stuff has come up and I’d just love to hear your thoughts about that. So maybe some things somebody could latch onto that might help them out there in terms of thinking through this process or working together or better with other people and collaborating. What are your thoughts on that?

Elkhan Yusubov:
Yes, I would say the DevOps mindset is also part of the mindset of growth and how you can expand your understanding and plus your career, right? Because at the point a before the project or product that you’re working on, what matters is that the delivery to the end users happen and then operations meaning that when they use your product they get satisfactory results.

Elkhan Yusubov:
So I would say into that equation, right, if you get into that sweet spot where what you worked on is actually appreciated, you need to take into account the operations part of it and not just the development.

Mike Pfeiffer:
I agree 100%, man. Well, Elkhan this has been awesome conversation man. As we’re kind of wrapping stuff up, where should we send listeners outside this episode, in the show notes I’m going to put a bunch of other resources at things we’ve already talked about, but is there things you’re working on or things you think other people should take a look at?

Elkhan Yusubov:
I mainly try to post my IDs and everything on LinkedIn account that I have. So I would primarily forward them there. In addition to that I would say, listening to the cloud skillset fam, that’s kind of something that I discovered probably last year or so. Which is a, I don’t know, seven, eight months ago. But the more I listen into that, the better understanding of the trends, better sign of what are they … people are working on, what they are trying to solve.

Elkhan Yusubov:
Understanding the trends in the industry. I would say that’s very important because then you can put all your extra effort of learning, understanding study into correct paths so that whatever you invest your time in, you can get the value out of it.

Mike Pfeiffer:
Awesome. Well. I really appreciate that, Elkhan. And for everybody listening, make sure you follow Elkhan on LinkedIn. I’ll put his profile link in the show notes and really appreciate you guys taking the time out and listening today. Thank you guys and thanks Elkhan.

Elkhan Yusubov:
Thank you, Mike. The pleasure is mine.

Subscribe to the CloudSkills Weekly Newletter

Get exclusive access to special trainings, updates on industry trends, and tips on how to advance your career in the tech industry.