everything as a code abdelmajid aneddame

Editor's Notes

• #2: So the subject of this presentation is EaC, so it is a bit of a mixture of Cloud & Devops technologies
• #4: If you’re confused when you read about “[some software term] as code” or “everything as code,” all you really need to know is that we’re talking about automation: The thing we use to do tedious tasks for us, or orchestrate tasks when they become too large and complex for manual methods. Everything as code (EaC) refers to the idea of managing all aspects of software development, delivery and management by implementing very quickly new architectures, re using design patterns that are already deployed within an organization, or within your client’s Environments, then by defining and codifying the infrastructure, then by configuring the schema and pipelines used to create, maintain, iterate or expand app development, automating network & infrastructure provisioning, and implementing security best practices within your pipelines as we call it DevSecOps or Rugged Devops (Microsoft vocabulory). In other words, when you take an everything-as-code approach to development and IT, you use policy files to govern the way software is built, deployed, monitored and so on. It’s a bit of a metaphor extension – applying the application development approach to other components of IT (including DevOps) to ensure that best practices get defined and followed with a minimum of effort. The everything as code approach also offers the benefit of reducing the risk of human error: When all of your workflows are defined as code, you no longer have to worry about an engineer forgetting to do something or clicking the wrong button by mistake. EaC makes auditing easier, too, because you can use your EaC configurations to determine what was done to your systems.
• #5: As I always say for my clients and teams with whom I work, Today’s world technologies should be Business Enabler First, which means you will need to control every aspect of the Cloud infrastructure hosting your business.For example, when you have a new business in demand with specific security guidelines or new compliancy rules, you should be able to migrate in one click and be compliant. Architecture as code is about patterns. The patterns automate the creation and lifecycle management of 95 percent to 99 percent of an application’s topology. For example, a Highly Available Web Application would contain the automation scripts needed to create a clustered web tier, a clustered app server tier, a clustered database tier, and the network configurations necessary to connect those tiers together. Lifecycle management operations executed against the pattern drive operations against each of the tiers as needed. A centralized function, like enterprise architecture, can create a pattern library that contains authoritative, hardened, tuned application topologies that are secure by design. With that pattern library, operations no longer needs to manually create the dev, test, and production topologies for Web Apps, Mobile Apps, Entreprise internal Apps… Application developers select the type of pattern needed, including the desired quality of service (QoS) eg. Single-instance dev or highly available, provide the final configuration elements needed.
• #6: Let’s take this simple archticture, where we have the following assets: Generally a Web application that is under ASP.NET which could be monolithic in our example, Azure App service Web Apps are the best native solution for deploying it into the Cloud => This could be an example of patterns to re use. Another example, would be applications that are running on Docker and containers, Azure Web apps for containers as it supports today both Windows and linux could be a very tempting solution as a target architecture on the cloud. An important benefit that comes from creating a pattern library and embracing architecture as code is that application developers no longer need to care about the underlying plumbing. There is no need to worry about whether the application is running in a container or a VM or is it on-prem or off-prem. Instead, developers can focus on shipping code that drives business value and can trust that their apps are in fact providing the as advertised QoS. There is a huge cost benefit as well. A large chunk of the IT costs for creating an enterprise application comes from building the underlying plumbing. With patterns, that cost is freed up and can be redirected to focus on higher-value work. By decoupling the application from the plumbing details, IT Operations has the flexibility to optimize workloads with little fear of breaking applications.
• #9: Each of these tools presents advantages and inconvenients, and every client/Entrperise has its own compliancy rules, context, security guidelines.. That would restrict the usage of one or many of the tools available today.
• #10: “Network as Code” (NaC) is the application of the “Infrastructure as Code” concepts to the full network domain, inclusive of traditional data centers, campus networks, WANs, and of course cloud environments.  The successful implementation of NaC is part of the wider NetDevOps adoption within an enterprise.  It will involve significant changes in the way we think about network design and operations, the culture around network change, and of course the tooling and technology used to build and manage configurations.  I propose three principles for Network as Code within NetDevOps. Principles of Network as Code Store Network Configurations in Source Control Source Control is the Single Source of Truth Deploy Configurations with Programmatic APIs
• #11: https://harness.io/blog/continuous-delivery/policy-as-code/ Every business tests its products before releasing them to its consumers. Software services are no different, and every organization has its practices, tools, and processes that verify the health, readiness, performance, and accuracy of an application. These allow us to make guarantees to consumers and users of our product. This helps ensure that all changes are in compliance and adhere to a set of standards. There are 2 ways to go about making a decision while testing a service. An individual or team can manually decide if a decision is correct or automate the decision-making process. One scales better than the other. Treating policy as code allows for automated decision-making, giving developers and engineers the independence to manage feature defining work without sacrificing compliance. Some common use cases which policies include: Authorization Control for application services: Implementing fine grained access control for an application is one of the most common use cases for policy as code. To check authorization a service makes an API call to the policy engine to output whether the request is authorized or not. (Here is some policy as code which you can use to implement API Authorization in OPA: https://github.com/open-policy-agent/opa#example-api-authorization) Infrastructure Provisioning within the cloud: Enforcing specific requirements on Public Cloud resources such as mandatory tags on instances, firewall and networking settings, and provisioned machine or instance types. (How to apply this use case using Hashicorp’s Policy Engine Sentinel: https://www.terraform.io/docs/cloud/sentinel/examples.html). For Kubernetes control: you can manage Kubernetes by writing policies against different kubernetes resources like pods, namespaces, and nodes. You can ensure container images come from trusted registries. I recommend looking at OPA Gatekeeper (and we describe in another Harness blog post how to deploy Gatekeeper as part of your continuous delivery process: https://harness.io/2020/04/open-policy-agent-primer/).
• #12: Each of these tools presents advantages and inconvenients, and every client/Entrperise has its own compliancy rules, context, security guidelines.. That would restrict the usage of one or many of the tools available today. If you’re interested in trying policy as code I recommend looking at Open Policy Agent Github public repository for examples. If you’d also like to try OPA with Harness as part of your CI/CD pipeline, Harness offers a great way to achieve this.
• #13: The Secure DevOps Kit for Azure (AzSK) was created by the Core Services Engineering & Operations (CSEO) division at Microsoft, to help accelerate Microsoft IT's adoption of Azure. We have shared AzSK and its documentation with the community to provide guidance for rapidly scanning, deploying and operationalizing cloud resources, across the different stages of DevOps, while maintaining controls on security and governance.AzSK is not an official Microsoft product – rather an attempt to share Microsoft CSEO's best practices with the community.. The CICD extensions feature of AzSK makes automated security configuration enforcement possible by making SVTs(=Security Verification Tests) available as a Visual Studio Extension in the Marketplace so that engineering teams can run them within build/release pipeline. Once the build/release task is configured, SVTs run against a target deployment in an Azure subscription. Upon completion, SVTs will report the pass/fail status for controls along with aggregate control results. Hereafter, all the different 'out-of-box' build/release workflow options from the CICD engine (e.g., VSTS) can be used as 'next steps' based on the outcomes of SVTs. (For instance, one can decide whether to fail the release outright or to continue despite failures while sending an email to the build/release owners or to hold progress until someone manually approves, etc. Furthermore, if all SVTs pass in the pre-prod environment, then a release can be 'promoted' to prod.) Outcomes of the SVT execution can also be routed to a Log Analytics workspace configured to receive various events generated by the AzSK.
• #14: I hope this presentation helped you understand the basic concepts around Automation as a service in the Everything as a Code Approach ! For any questions, feel free.