Speaker: Nathan Lasnoski, Concurrency, MVP
Prepare & Execute
Picture of a tri-athlete. Riding on perfect smooth surface with perfect picture with hands off the brakes. The person is prepared – set up well. Azure operators & devs should be like this. Ready, confident, and on a smooth road with a great experience with no sudden stops.
Preface – Getting Started
Cloud Maturity Curve.
- Legacy: On-prem, business not enabling. IT is a blocker to innovation.
- Legacy +: IT stagnant. Scattered cloud across the business.
- Platform: Target today – operationalized loud. Goverened.
- Fusion: Technology fully business integrated.
What is an “Azure Environment”?
- Operated by the corporation
- Runs with standards, policies, controls
- Diverse workload enablement, powers innovation
- Servers, containers, serverless, PaaS, AI, digital ledger
- Stakeholder management
- Delegated to targeted teams, under corporate oversight
- Representative of technology investments
- Areas like cost should relate to intended investment areas/business value. IT is not the bucket of all IT spend – Those spending should care about the things they pay for.
Number 1 – Employee Organizational Change and Operations
Transformation of organization, tied to DevOps
- Increased multi-skill frameworks
- Emphasis on code, repeatability, automation
New products/projects made up of:
- Cloud architecture & operations
- Innovation and business enablement
- Application and Product DevOps Teams
Number 2 – Define an operational and leave adoption strategy
High level view of a cloud program – diagram in the slides.
- Define an iterative cloud program whith a MVP motion on operations
- OPERATIONAL STANDARDS, PROVISIONING PROCESS, WIKI, MOTIONS
- Be careful about overreaching – Corporation has a bad relationship with IT.
Number 3- Be a Blueprint That is Manageable
A structure of management groups and subscriptions, with limited resource groups.
Left-hand IT, Right-side business. Top – management groups, bottom – IT. Why split corp IT and business areas should be in different subscriptions/management groups.
Using 1 overloaded sub is BAD, even is MS people recommend it (AGREED!). RBAC, cost-management, quotas, etc.
Number 4 – Approaches for provisioning short-term and long-term
Using a portal for provisioning. It’s a manual process. Azure Portal, ServiceNow, whatever – minimise their usage. Problem with portals is that all the old manual problems of on-prem follow to the cloud. No documentation on config. No repeatability. No change control.
Source Code Release (Azure DevOps) > Control Plane (ARM, Policy) > Deployment.
Subscriptions should be read-only. Only time you use the portal to deploy/config should be sandboxes. Enterprise deployments should be done as code:
- Program code
This includes 3rd party stuff you put in VMs.
This is the right way to start. And it prepares you for PaaS, e.g. AKS, App Services, etc.
Number 5 – Define Structures for Naming and Tagging
You cannot work in the cloud long-term without this.
- Owning team
- Business unit
- Application Name
- Classification (security)
- Environment moniker (dev, test, production, etc)
- Cost Center
Number 6 – Recovery and re-deployment approaches
- Assume re-deployment at every level, especially corp-IT.
- The Corp IT infrastructure is code too, store it in a code repository
- Build based on release management pipeline
- Re-deployability such as AKS
- Re-deployable app environments
- App Services
- Data services
- OAM, RUDR, DAPR
- Re-deployable app environments
Number 7 – Adapt Security Controls For The Cloud
Movement to vertical network design. On-prem IT is flat and horizontal and things talk directly to things. In the cloud, direct connections should be limited with micro-segmentation – see previous blog posts.
This is easier to do in the cloud, and it should be done during migration and new-builds. According to Nathan, it’s one of the reasons to migrate to the cloud at all!
Use Azure Security Center to assess the environment and monitor it from a security perspective. Leverage automated responses to react, e.g. playbooks in Azure Sentinel. Use custom policies to audit Azure too.
- Segment addresses – don’t use admin email accounts for Azure accounts.
- Limit owner rights. Contributor at most. Read-only ideally in production.
- Use PIM (AAD P5) to limit access but require rights escalation for admins. Consider approval.
- Use MFA. Less than 8% of Azure tenants have MFA enabled.
RBAC applied to applications
- Teams only get access to necessary RGs/subscriptions.
- Admin owner credentials are different than application credentials
- Deployments are encouraged to be automated from source code.
Number 8 – Monitoring responsibilities change as application owners take more responsibility
- Corp IT is responsible for “cloud IT”.
- Standards policies, connectity – not just things that go bump in the night
- Ensures governance is applied, monitors for aggregate issues
- Security might be a separate group
- Measuring security compliance, reacting to incidents
- Runs against playbooks but moving declaratively
- Application teams
- Own operational monitoring and reacting to their services
- DevOps teams operating stuff
Azure Monitor/Logs provides data access via resources now that reflects RBAC to resources.
Number 9 – What do I do with my CMDB and how does it change?
- Original function of the CMDB was to contain configuration data
- Modern environment is quarriable platform, declarative config, DevOps
Resource Graph and DevOps can be your living always correct CMDB.
Number 10 – Building a methodology for cost reviews and organizational discipline
- Tags are critical to cost analysis
- Use policy enforced tagging regimes
- Apply tags as needed for accounting purposes
- Be able to judge costs on:
- Business unit
- Azure Cost Management
- Custom PowerBI
- Setting budgets
- Analysis and improvement
- Limit high spenders
- Optimize sizing
- Cost management team should pay for itself.