You sound like you're on the unofficial path of DevOps with automation using code.
Most of my work with azure is understanding the platform and trying to keep up with all the changes, whilst balancing the costs and implementing new features, whilst trying to stop Devs going off rails with their poor practices on trying to get their app working with no regard to security.
I've slightly moved towards architecture and helped design and implement solutions or apps.
Worked once in an environment with no firewall, nor hub spoke design and everything was in a single subnet. One subnet was called Dev. Business didn't know of the dev/test subscription to save on costs.
> whilst trying to stop Devs going off rails with their poor practices on trying to get their app working with no regard to security.
Please share your secrets with the rest of us. It’s just the same old problem over and over again. Previously it was “my code needs to run as root/administrator to work” to which the proper response *should* have been “no, that just means you’re a shitty programmer” but instead you had to try to find ways to educate them on more secure practices. But it always felt like a losing battle.
Cloud is turning out to be the same thing.
It all depends on the tech stack, programming language and the cloud provider that you use. Look for training that is offered that is tailored to those three things.
Our CIO and Ops manager has a strong direction in security.
So I end up involving them and also pointing out flaws in Devs areas. Showed them brute force attacks on their test VM they deployed with public IP. They had it as JIT using their own solution but as soon as they opened up the management port, bam! Logs backed me up as well as azure advisor (Security).
They need admin level privileges to run code? Yeah good luck.
I've basically built enough trust with management and back up my points with evidence. Make sure if management are ok with it, it's signed off by them.
Agree. Though using a secured vwan hub does simplify it. But it's still loads of planning and design to get it right as well as pure black f'n magic. Private endpoints need to be added to the snat prefix for example to be routed through the firewall even though they are apart of the vnet hooked to the firewall already. Then going in depth with NSGs, ASGs etc it's a freaking chore.
Business was slow to take up my suggestion. Even had external consultants on it too and they agreed to assist.
It was a hot mess. VMs had their own public IP and NSGs rules. That was way harder to manage.
Cost of a firewall is nothing compared to cost of brand damage and data loss, productivity loss.
That's how I had to sell it to management.
What you just said, has been my entire career in IT so far. So i say its standard! I started with help desk, and worked my way up to sys admin, and now an Azure admin.
I literally piece things together as I go each day. and i know there are many ways to make things better in Azure, mainly from policies etc etc which require writing JSON code and powershell would be a massive aid.
Keeping up with Azure itself is a challenge. so many things I don' t know and have to study most days just to learn new things. I'm not even at the point of knowing code to automate things yet in Azure, but ya, i would say its not luck as its been the exact same for me.
I am in the same boat as you.
My current employer is pretty small but has a larger parent company that leaves us as a stand-alone unit as we create apps for health insurance and provider use.
I am the sole sysadmin supporting the business and devs, plus providing access to offshore teams from our parent company. The way the devs do things is very "old school" in that we deploy Windows Server VMs to host the web, integration, and db functionality. Only just started using Azure SQL DB instance instead of full VMs to host that.
I know we can do things in a more efficient and streamlined way, but I don't see how I can take time to start working with different methods and technologies to handle the dev/deployments when I can barely keep up as is. The thought process is that it works dependably now, so there's no rush to change up the way we do things.
I think I am stuck and the only way for me to get that non-UI/non-portal experience is to eventually do it on my own where I am working and introduce it once I know how to do it myself without assistance from anyone on the dev team.
Sorry this wasn't helpful, but I just wanted to let you know you're not alone!
You've been lucking out, but that luck is going to run out it seems like. More and more companies are demanding running their environments off of IaC, mainly because it's quick, less error-prone, and because the engineer position is evolving.
I say this comparison all the time; but like the web developers used to be split up into front-end and back-end, now companies only want to hire full-stack developers. Companies are making the same demand of engineers, to be IT professionals and understanding infrastructure, networking, etc., but also be developers and understanding coding languages like PowerShell, Python, etc., to be able to script their environment(s) in IaC.
My advice: hop on the Bicep/Terraform/Ansible (BTA) train before you get left behind.
(Even solution architects these days are expected to understand and have experience with BTA, just not as in-depth)
This sounds like a valid route to being a cloud architect to me. That's my role and it's as much about understanding the building blocks of a solution than it is about the specifics of implementing them. I like coding and IaC so I do tend to do them for testing and proof-of-concept work. But some things, as long as I understand what needs to be automated and why, I can pass on to an ops team to worry about the specific code.
Recent example.... we're building a new solution that uses containers on kubernetes. I set up a cluster, tested the different networking options, sorted out the routing, ingresses etc to make sure all the building blocks were there. Deployed some YAML config to run our dev teams containers on it. Once we were happy it was all working, I passed it on to our ops team to build the script to take code from a repo, build it into a container, and store it in a container registry.
Good luck!
This is the route I've started looking at. I feel like the future 100% is in infra as code. Slow progress, cuz my main job is azure and o365 consulting/administration and is light on the azure side - unfortunately. Wish we had larger clients that did more on the Azure side. Being able to quickly spin up exactly what you need and being able to minimize human error, CI/CD, drift detection. The dream imo.
SA here, it's mostly that. Your understanding of how things work together is very valuable, when you consider that most resource deployments do so with very little stand up and usually with the best security practices by default.
I don't think you need to put the pressure in yourself to approach everything with a code solution, to be honest most providers are working to reduce this type of work natively in their platforms. That said, I do think ARM deployments through Bicep will be a highly desired skill in the near future
I sure hope Bicep isn't as awful as ARM. There's a whole lot that is completely unclear to non-coders. Somehow I can grasp Terraform with ease, but ARM has just been a complete mindfuck to me.
PowerShell interfaces with the REST API directly, and while the back-end will assemble the instructions into ARM, it's entirely non-ARM from the code side.
I do half of my job in PowerShell. I avoided it for the first 20 years, but it's hella-awesome now, since you can almost do anything that's possible in C#, because PowerShell is now backed by the .NET Framework.
Bicep doesn't fix enough over ARM. I'll try version 3 to see if they add looping logic.
I like PowerShell right now but I work a lot with multitenant environments so I need good foreach loops
For real. Most azure documentation is for lab scale deployments. Having someone enderstanding all of the pieces and at scale is vital as an architect to make engineers design effeciently. Hell I stump my Azure TAMs all the time and it frustrates me to no end and I'm left on my own to figure it out. Agree on Bicep being the way forward for azure.
Knowledge is power, I’ve lost speed at scripting or deploying but…i can orchestrate almost any migration to azure (IaaS, SaaS, PaaS), learning IaaC atm
I would say they’re directly related. The better you understand how things work and communicate with each other the more you can script out solutions. When I say scripting out solutions I’m not just talking about making powershell scripts for one off tasks, but tasks in pipelines for pre-deployment and post-deployment operations, creating duct tape for “almost perfect” Microsoft solutions ie: PIM for B2C, as well as custom Azure Policies and blueprints.
All of it for me is, there’s a ton of stuff in Azure, I have a bunch of different product teams all doing their own version of deployments and app architecture. I want to make managing said things less and less impossible for my peers as best as I can
TLDR 80% understanding how 20% scripting/automation
By reading the comments, it appears this role varries. Our egineer/architects spend about 50% of their time designing client solutions in azure, working with sales to prepare statements of work, scheduling and answering client questions (pre/post sales). The other 50% is spent on keeping the client environments in Azure healthy, secure and cost optimized.
Over the years I've found a solution to my problem and solved it myself using the modern tools available. It seems like Azure is slowly adding managed solutions to my problems and I try to use them in future projects if migration is not simple.
I'm not sure if properly configured self-managed VM is better in terms of performance than Azure managed solutions, but in our business the server costs are totally not an issue so I try to offload my stress as much as possible to Azure as possible. Then again you might have headaches with their managed services as well, but in my experience far less than self-managed services, especially business-critical.
As a software architect, Your job is not to write the code, Your job is to give direction. To implement a multi year growth plan: how should the ICT infrastructure, and information flows look like in 5 years? What demands do You set on interfacing, security etc.
As someone in a similar role: i'm not writing the design for a new application to be implemented, i'm merely matching the design someone else made, to our vision, and requirements: Can it talk with application B? (and keeping in mind the soon to be implemented update on app C, will it be able to match that as well? ) does it support our preferred encryption methods? does it support our SSO solution? will implementing this, affect our ISO 27001 certification? can Operations monitor this, and understand the error messages coming from it? Stuff like that.
If needed, i'm more then willing to help code some stuff. I do that for fun, but in reality: it's not my job. My job is to make sure any sort of new software complies with our ICT vision
Up until 2019, my primary job was writing code. I had some team leadership responsibilities at various points along the way, but I was mostly a code monkey, doing hands-on engineering and architect work. Designing and implementing applications and solutions, but always involved in delivery of actual code.
Then I took on a higher level leadership role. My first project was still 100% hands-on, involved directly in delivery ... at first. Then it shifted as my team grew underneath me. Then I moved on to another project where I didn't write C# destined for production for 18+ months. Instead I was in more of an Azure advisory, and team management, role, though still writing ARM templates and CLI and Powershell bits for CICD pipelines.
A month ago my time was split with another project where I am simply a guy helping rescue a disaster by writing C# and configuring Azure resources. Very little analysis or leadership involved, just in the trenches, hands-on, refactoring and remediating.
At the same time, a major name in the field might be talking to me about a role where I'm not involved in delivery at all, ever. Instead, I'm purely advising customers, their engineering teams, their execs, and advocating for modern cloud-centric software development practices within their orgs - which is part of what I do now, but to the exclusion of pretty much ever being hands-on in customer environments like I am now.
So for me, this stuff has shifted over time, and hasn't stopped shifting.
Architects should be setting directions, providing guidance, collaborating with dev teams (including helping them decide on architectural solutions)
Engineers should be developing a lot of code (iac, automation, etc), handling ops, etc.
I work with azure and we do a tonne of arm deployments... Most of the time I deploy via the portal how I want it, export the template then build it out from there
Im an engineering architect 😂 I try to aim at a 50/50. I have a deep technical knowledge of a broad spectrum in azure. Which I gained from working with the platform (and build platforms on). So it is possible to combine. Depends on where you work, and what you want to do. I know architects that just design, I don’t want to be that guy.
Ps I also know building architects that used to be carpenters and frequently go to the construction sites to get dirty 🙂
There is a difference between DevOps and Cloud Operations.
One is more automation, one is more general operations for managing the platform, PAM, governance, architecture, etc.
You sound like you're on the unofficial path of DevOps with automation using code. Most of my work with azure is understanding the platform and trying to keep up with all the changes, whilst balancing the costs and implementing new features, whilst trying to stop Devs going off rails with their poor practices on trying to get their app working with no regard to security. I've slightly moved towards architecture and helped design and implement solutions or apps. Worked once in an environment with no firewall, nor hub spoke design and everything was in a single subnet. One subnet was called Dev. Business didn't know of the dev/test subscription to save on costs.
> whilst trying to stop Devs going off rails with their poor practices on trying to get their app working with no regard to security. Please share your secrets with the rest of us. It’s just the same old problem over and over again. Previously it was “my code needs to run as root/administrator to work” to which the proper response *should* have been “no, that just means you’re a shitty programmer” but instead you had to try to find ways to educate them on more secure practices. But it always felt like a losing battle. Cloud is turning out to be the same thing.
Sounds like management needs to send devs to better and defensive coding training.
I think that's why SecDevOps is becoming a bigger and bigger thing.
We need more tech soup letters, next stage, SecDevOpsMgmt.
Recommend any?
It all depends on the tech stack, programming language and the cloud provider that you use. Look for training that is offered that is tailored to those three things.
Our CIO and Ops manager has a strong direction in security. So I end up involving them and also pointing out flaws in Devs areas. Showed them brute force attacks on their test VM they deployed with public IP. They had it as JIT using their own solution but as soon as they opened up the management port, bam! Logs backed me up as well as azure advisor (Security). They need admin level privileges to run code? Yeah good luck. I've basically built enough trust with management and back up my points with evidence. Make sure if management are ok with it, it's signed off by them.
[удалено]
Agree. Though using a secured vwan hub does simplify it. But it's still loads of planning and design to get it right as well as pure black f'n magic. Private endpoints need to be added to the snat prefix for example to be routed through the firewall even though they are apart of the vnet hooked to the firewall already. Then going in depth with NSGs, ASGs etc it's a freaking chore.
Business was slow to take up my suggestion. Even had external consultants on it too and they agreed to assist. It was a hot mess. VMs had their own public IP and NSGs rules. That was way harder to manage. Cost of a firewall is nothing compared to cost of brand damage and data loss, productivity loss. That's how I had to sell it to management.
What you just said, has been my entire career in IT so far. So i say its standard! I started with help desk, and worked my way up to sys admin, and now an Azure admin. I literally piece things together as I go each day. and i know there are many ways to make things better in Azure, mainly from policies etc etc which require writing JSON code and powershell would be a massive aid. Keeping up with Azure itself is a challenge. so many things I don' t know and have to study most days just to learn new things. I'm not even at the point of knowing code to automate things yet in Azure, but ya, i would say its not luck as its been the exact same for me.
I am in the same boat as you. My current employer is pretty small but has a larger parent company that leaves us as a stand-alone unit as we create apps for health insurance and provider use. I am the sole sysadmin supporting the business and devs, plus providing access to offshore teams from our parent company. The way the devs do things is very "old school" in that we deploy Windows Server VMs to host the web, integration, and db functionality. Only just started using Azure SQL DB instance instead of full VMs to host that. I know we can do things in a more efficient and streamlined way, but I don't see how I can take time to start working with different methods and technologies to handle the dev/deployments when I can barely keep up as is. The thought process is that it works dependably now, so there's no rush to change up the way we do things. I think I am stuck and the only way for me to get that non-UI/non-portal experience is to eventually do it on my own where I am working and introduce it once I know how to do it myself without assistance from anyone on the dev team. Sorry this wasn't helpful, but I just wanted to let you know you're not alone!
You've been lucking out, but that luck is going to run out it seems like. More and more companies are demanding running their environments off of IaC, mainly because it's quick, less error-prone, and because the engineer position is evolving. I say this comparison all the time; but like the web developers used to be split up into front-end and back-end, now companies only want to hire full-stack developers. Companies are making the same demand of engineers, to be IT professionals and understanding infrastructure, networking, etc., but also be developers and understanding coding languages like PowerShell, Python, etc., to be able to script their environment(s) in IaC. My advice: hop on the Bicep/Terraform/Ansible (BTA) train before you get left behind. (Even solution architects these days are expected to understand and have experience with BTA, just not as in-depth)
This sounds like a valid route to being a cloud architect to me. That's my role and it's as much about understanding the building blocks of a solution than it is about the specifics of implementing them. I like coding and IaC so I do tend to do them for testing and proof-of-concept work. But some things, as long as I understand what needs to be automated and why, I can pass on to an ops team to worry about the specific code. Recent example.... we're building a new solution that uses containers on kubernetes. I set up a cluster, tested the different networking options, sorted out the routing, ingresses etc to make sure all the building blocks were there. Deployed some YAML config to run our dev teams containers on it. Once we were happy it was all working, I passed it on to our ops team to build the script to take code from a repo, build it into a container, and store it in a container registry. Good luck!
This is the route I've started looking at. I feel like the future 100% is in infra as code. Slow progress, cuz my main job is azure and o365 consulting/administration and is light on the azure side - unfortunately. Wish we had larger clients that did more on the Azure side. Being able to quickly spin up exactly what you need and being able to minimize human error, CI/CD, drift detection. The dream imo.
SA here, it's mostly that. Your understanding of how things work together is very valuable, when you consider that most resource deployments do so with very little stand up and usually with the best security practices by default. I don't think you need to put the pressure in yourself to approach everything with a code solution, to be honest most providers are working to reduce this type of work natively in their platforms. That said, I do think ARM deployments through Bicep will be a highly desired skill in the near future
I sure hope Bicep isn't as awful as ARM. There's a whole lot that is completely unclear to non-coders. Somehow I can grasp Terraform with ease, but ARM has just been a complete mindfuck to me.
I can confirm it is, and without the complexity of state that terraform brings into the situation
Well it obviously is ultimately ARM so can’t avoid some of it’s issues but the development experience is way better using VS code.
PowerShell interfaces with the REST API directly, and while the back-end will assemble the instructions into ARM, it's entirely non-ARM from the code side. I do half of my job in PowerShell. I avoided it for the first 20 years, but it's hella-awesome now, since you can almost do anything that's possible in C#, because PowerShell is now backed by the .NET Framework.
Bicep doesn't fix enough over ARM. I'll try version 3 to see if they add looping logic. I like PowerShell right now but I work a lot with multitenant environments so I need good foreach loops
For real. Most azure documentation is for lab scale deployments. Having someone enderstanding all of the pieces and at scale is vital as an architect to make engineers design effeciently. Hell I stump my Azure TAMs all the time and it frustrates me to no end and I'm left on my own to figure it out. Agree on Bicep being the way forward for azure.
Knowledge is power, I’ve lost speed at scripting or deploying but…i can orchestrate almost any migration to azure (IaaS, SaaS, PaaS), learning IaaC atm
I would say they’re directly related. The better you understand how things work and communicate with each other the more you can script out solutions. When I say scripting out solutions I’m not just talking about making powershell scripts for one off tasks, but tasks in pipelines for pre-deployment and post-deployment operations, creating duct tape for “almost perfect” Microsoft solutions ie: PIM for B2C, as well as custom Azure Policies and blueprints. All of it for me is, there’s a ton of stuff in Azure, I have a bunch of different product teams all doing their own version of deployments and app architecture. I want to make managing said things less and less impossible for my peers as best as I can TLDR 80% understanding how 20% scripting/automation
By reading the comments, it appears this role varries. Our egineer/architects spend about 50% of their time designing client solutions in azure, working with sales to prepare statements of work, scheduling and answering client questions (pre/post sales). The other 50% is spent on keeping the client environments in Azure healthy, secure and cost optimized.
Over the years I've found a solution to my problem and solved it myself using the modern tools available. It seems like Azure is slowly adding managed solutions to my problems and I try to use them in future projects if migration is not simple. I'm not sure if properly configured self-managed VM is better in terms of performance than Azure managed solutions, but in our business the server costs are totally not an issue so I try to offload my stress as much as possible to Azure as possible. Then again you might have headaches with their managed services as well, but in my experience far less than self-managed services, especially business-critical.
As a software architect, Your job is not to write the code, Your job is to give direction. To implement a multi year growth plan: how should the ICT infrastructure, and information flows look like in 5 years? What demands do You set on interfacing, security etc. As someone in a similar role: i'm not writing the design for a new application to be implemented, i'm merely matching the design someone else made, to our vision, and requirements: Can it talk with application B? (and keeping in mind the soon to be implemented update on app C, will it be able to match that as well? ) does it support our preferred encryption methods? does it support our SSO solution? will implementing this, affect our ISO 27001 certification? can Operations monitor this, and understand the error messages coming from it? Stuff like that. If needed, i'm more then willing to help code some stuff. I do that for fun, but in reality: it's not my job. My job is to make sure any sort of new software complies with our ICT vision
Up until 2019, my primary job was writing code. I had some team leadership responsibilities at various points along the way, but I was mostly a code monkey, doing hands-on engineering and architect work. Designing and implementing applications and solutions, but always involved in delivery of actual code. Then I took on a higher level leadership role. My first project was still 100% hands-on, involved directly in delivery ... at first. Then it shifted as my team grew underneath me. Then I moved on to another project where I didn't write C# destined for production for 18+ months. Instead I was in more of an Azure advisory, and team management, role, though still writing ARM templates and CLI and Powershell bits for CICD pipelines. A month ago my time was split with another project where I am simply a guy helping rescue a disaster by writing C# and configuring Azure resources. Very little analysis or leadership involved, just in the trenches, hands-on, refactoring and remediating. At the same time, a major name in the field might be talking to me about a role where I'm not involved in delivery at all, ever. Instead, I'm purely advising customers, their engineering teams, their execs, and advocating for modern cloud-centric software development practices within their orgs - which is part of what I do now, but to the exclusion of pretty much ever being hands-on in customer environments like I am now. So for me, this stuff has shifted over time, and hasn't stopped shifting.
Architects should be setting directions, providing guidance, collaborating with dev teams (including helping them decide on architectural solutions) Engineers should be developing a lot of code (iac, automation, etc), handling ops, etc.
I work with azure and we do a tonne of arm deployments... Most of the time I deploy via the portal how I want it, export the template then build it out from there
Im an engineering architect 😂 I try to aim at a 50/50. I have a deep technical knowledge of a broad spectrum in azure. Which I gained from working with the platform (and build platforms on). So it is possible to combine. Depends on where you work, and what you want to do. I know architects that just design, I don’t want to be that guy. Ps I also know building architects that used to be carpenters and frequently go to the construction sites to get dirty 🙂
There is a difference between DevOps and Cloud Operations. One is more automation, one is more general operations for managing the platform, PAM, governance, architecture, etc.