It’s 2021 and I’m just over a month into my third role as a Software Engineer & Tech Coach. It’s been a whirlwind of a journey so far! Here’s some things I wished I knew about DevOps practices and cloud technologies when I started my first role in tech.
My role wasn’t just about full-stack Software Engineering in C#, but also involved DevOps practices and Cloud technologies
During my career switch into tech, I thought that DevOps practices and Cloud technologies were utilised solely by DevOps Engineers and Cloud Engineers. I under appreciated how much of my role involved DevOps practices and Cloud.
When I spoke to people in my network and especially those who have recently started their first roles in technology; it seemed like there was a mixed bag. Some people were not involved in DevOps and Cloud at all, though they mentioned some of their colleagues were. Others, like myself had more of a hybrid role and some people were doing DevOps and Cloud every single day!
What is DevOps in a nutshell?
AWS states, "DevOps is the combination of...philosophies, practices, and tools that increases an organisation's ability to deliver applications and services…". The infrastructure and process that sits behind software ensures a smoother experience for building code, testing it, shipping it out and monitoring it.
DevOps and Cloud is there to help Developers
Some Software Engineers would say that DevOps and Cloud is not part of their role, so why should they bother; they do have a point there. It’s a massive world, recently, product offerings like AWS Amplify for example, help those who major on the front-end and API domains build mobile/web apps quickly. However, there's value in learning some of the key concepts on how DevOps and cloud is helpful.
In my first role in tech, I wanted to learn some fundamentals of DevOps and Cloud that would support me in my role as a C# Full-Stack Software Engineer.
In my team at the time, one of the projects we were tasked with was re-writing a legacy Excel application into a .NET Core 3.1 C# web application (at the time of writing this post, it’s .NET 5). I really liked the way my team worked together on this, all the developers/testers, business analysts, our product owner and scrum master mobbed on this.
Something popped into my head at the time: “Why can’t we just build the web application and then just deploy it to production for the users, easy right? I can just click around on the Azure Portal and just manually make my resources there and then manually deploy.”
Well, when we started mob programming on the cloud infrastructure process, I realised there was more to just ‘making something work’.
Automated Continuous Integration & Continuous Deployments Using Azure Repos & Pipelines
One of the things that stuck with me was CI/CD (Continuous Integration / Continuous Deployment). According to the AWS DevOps blog, “An integral part of DevOps is adopting the culture of continuous integration and continuous delivery/deployment (CI/CD), where a commit or change to code passes through various automated stage gates, all the way from building and testing to deploying applications, from development to production environments.”
I got to appreciate this by learning about git, git repositories on Azure repos, managing branches and creating pipelines to build and deploy our C# solution.
During my learning process, I had a sneak peak at how different teams were utilising Azure Pipelines. At first I was hard-coding things in and this sort of worked, but then I found myself copying and pasting all the time. I then realised parameterisation was helpful to ensure I could supply different values for the same pipeline variables. This helped me as a developer and for other developers on my team because it meant we could replicate the same setup across the development environments, testing environments, pre-production and production environments of the pipeline. We could configure things to be switched ‘on’ and ‘off’ through code.
Separation of concerns was important here. We decided to go with an infrastructure pipeline and an app pipeline. If there were changes to the web application on a branch, CI/CD will automatically detect this and trigger a build and deploy onto the relevant environments using the relevant pipelines. Test suites would also run automatically too. Once the Pull Request (PR) for the branch has been approved and merged, the CI/CD pipeline will build and deploy to the environments. No more arduous manual deployments that we had to deal with for the original Excel application! Great!
Infrastructure-as-Code
During my first role, I realised that clicking around the settings on the Azure Portal to create and configure resources was helpful for me, but not helpful for others. It wasn’t repeatable. We had to think as a team how we can define the infrastructure and configure it using a better approach. This was where the Azure Resource Manager (ARM) templates came in handy. It enabled the definition of what infrastructure we wanted to make, how we wanted to make it and configure it.
The ARM templates were useful as they could be version controlled through git as well; just like we would version control code. There were also helpful extensions on Visual Studio for structuring and validating these templates.
Most importantly, it enabled a repeatable and testable process for our infrastructure.
Logging & Monitoring
So why do we need logging & monitoring? Let me put it this way, when you release a new feature for your product, that's just the start. Just as a plane has a suite of telemetry to record readings from instruments; it is the same concept for software to ensure everything is operating as it should. Try to think where logging and monitoring makes sense for you.
We used Azure Monitor to add observability into our applications, infrastructure and network.
Final Thoughts
This is just the surface of what DevOps and Cloud technologies can offer to developers, of course there are specialists who go a bit deeper into more concepts that those I've covered here. If you are working in tech, there is some benefit to learning some of the fundamentals about the infrastructure and process that sits behind software to ensure smoother experiences for building code, testing it, shipping it out and monitoring it.
Top comments (0)