devopsy.kinsta.cloud

Tag: IaC

  • Accurics Makes Infrastructure as Code More Secure

    Accurics Makes Infrastructure as Code More Secure

    Fresh off raising $5 million in funding, Accurics today launched a platform that analyzes the code employed to manage infrastructure as code for vulnerabilities as well as indicators of drift to create a threat model for cloud application workloads and then, if necessary, automatically roll back cloud settings to their last known approved state.

    Accurics CEO Sachin Aggarwal said rather than simply focusing on cloud infrastructure, the startup company’s platform analyzes vulnerability feeds, identity access management (IAM) privileges and other data to detect potential cloud security issues. That analysis can then be shared with third-party security tools to automate remediation, he said.

    Once the model is constructed, Accurics then monitors the application workload for changes that introduce risks and generates a topology for each workload in real-time to identify any potential indicators of drift away from the initial deployment settings. If the drift is due to a legitimate change, the code can be updated. If it introduces risks, IT teams can roll their code back to the last known secure posture using a “time machine” capability that Accurics has baked into its platform, he said.

    AccuricsThe Accurics platform takes a different approach to cybersecurity—rather than focusing solely on application programming interfaces (APIs) exposed by cloud infrastructure providers, it analyzes everything from the Terraform code used to programmatically install workloads to the container and serverless computing frameworks employed. In the future, Aggarwal said Accurics plans to add integrations with other infrastructure commonly employed in cloud environments, including Jenkins, Bitbucket and GitLab continuous integration/continuous delivery (CI/CD) platforms.

    That analysis surfaces violations of common compliance and cybersecurity practices based on Security Operation Center (SOC) 2, General Data Protection Rule (GDPR), Payment Card Industry (PCI), Healthcare Information Portability and Accountability (HIPAA), International Organization of Standardization (ISO), Center for Internet Security (CIS) Benchmark, Amazon Web Services (AWS) Best Practices and the AWS well-architected framework.

    Aggarwal said Accurics advances DevSecOps by making it possible for organizations to continuously assess changes within their cloud application environments. Most of the issues involving cloud security today can be traced back to errors made while using tools to programmatically provision cloud infrastructure. The Accurics platform helps developers and cybersecurity teams to collaboratively discover those issues, he noted, adding the overarching goal is to enable both teams to reduce risks by eliminating the most common mistakes that are made in cloud computing environments.

    As the relationship between DevOps and cybersecurity teams continues to evolve, it’s become apparent the first issue most organizations need to address when it comes to cloud security is visibility. Most IT teams are concerned about cloud security not because the platforms are less secure than on-premises infrastructure. In general, cloud infrastructure is more secure. However, because of a lack of visibility, it’s not as easy for cybersecurity teams to discover when misconfigurations create a known vulnerability. If that issue gets resolved, much of the resistance to cloud computing generated by security concerns will fade away.

  • Comparing Three Approaches to Multi-Cloud Security Management

    Comparing Three Approaches to Multi-Cloud Security Management

    Moving to a multi-cloud environment can bring many advantages, but it also brings huge challenges in managing both the everyday operations and security of multi-cloud infrastructures.

    To meet these challenges, several approaches to multi-cloud management have arisen. The most common can be roughly grouped into three categories: Cloud Management Platforms (CMPs), Infrastructure as Code (IaC) and cloud-native abstraction. The differences between these approaches reflect the differences between top-down and bottom-up cloud management, as each management process suits a different set of companies.

    In this article, we’ll take a look at all three approaches, explain what the advantages and disadvantages of each are and then explore whether new approaches to multi-cloud management are required.

    CMPs

    CMPs are the highest level approach to cloud management—the approach that is furthest away from the native code that your clouds run on. The rise of CMPs has come as the result of a simple observation: public cloud services are redundant and overlapping, and can therefore be managed through an abstraction layer that hides the complexities of what is happening at a cloud-native level.

    By using a CMP, admins do not need to understand the differences between AWS and Microsoft public clouds (for instance), but instead use a consistent interface to manage both.

    This has some huge advantages, primarily when it comes to improving cloud security. CMPs allow IT operations teams to implement a common security layer within multi-cloud environments, and apply the same identity and access management (IAM) processes across all the clouds they are working with. 

    This is particularly useful with cross-cutting applications that interfaces with multiple, critical portions of your cloud storage to help simplify, and which requires highly complex user access policies. This is ultimately one of many reasons why security breaches of cloud-based data are so rare, as 99% of businesses in the UK that rely on cloud-based software have never experienced a security breach. 

    IaC

    IaC is a second approach to multi-cloud management. This approach arose in response to utility computing and second-generation web frameworks, which gave rise to widespread scaling problems for small businesses.

    Administrators took a pragmatic approach: they modeled their multi-cloud infrastructures with code, and were therefore able to write management tools that operated in a similar way to standard software.

    IaC sits in between the other approaches on this list, and represents a compromise solution. It gives more fine-grained control over cloud management and security processes than a CMP, especially when used in conjunction with SaaS security vendors whose software can apply a consistent security layer to a software model of your cloud infrastructure. This is important because SaaS is growing rapidly in popularity, with 86% of organizations expected to have SaaS meeting the vast majority of their software needs within two years. 

    On the other hand, IaC requires a greater level of knowledge and vigilance than either CMP—or cloud-native approaches. If admins are knowledgeable enough to write code that can accurately (and reliably) model multi-cloud infrastructures, IaC can be a powerful way to improve DevOps security. These software models, however, will require constant monitoring to ensure that changes in the cloud-native layer do not introduce vulnerabilities into management tools.

    Finally, IaC can be significantly more efficient, when it comes to computing and network resources, than a CMP. Because IaC software runs closer to the cloud-native layer than (most) CMPs, it can execute common tasks much more quickly.

    Cloud-Native Abstraction

    The final approach to multi-cloud management is to manage your environment using only cloud-native tools. This approach has grown in popularity recently, as developers grew increasingly comfortable with working with containers and Kubernetes directly. Cloud storage providers have responded by offering increasingly complex tools designed to work directly on the cloud-native layer, and the storage provider you use should come with these tools.

    Cloud native application management has several advantages, and several disadvantages. The most obvious advantage is that cloud-native tools give admins a much greater level of control over their multi-cloud environments than the other approaches on this list. Because these tools run natively, they are also typically faster and more efficient than the other approaches we’ve mentioned above.

    On the other hand, saving computing time comes at the cost of increasing the workload for administrators. If you are working across a large number of clouds, managing each separately using each cloud’s native applications can quickly turn into a full-time job. In addition, managing multiple and complex access and usage policies at a cloud-native level can make it difficult for admins to keep on top of how their IAM processes are running, and increases the risk of mistakes. 

    Is It Time For a New Approach?

    All of the approaches above are a different solution to solve the same problem, namely the challenges caused by rapid adoption of multi-cloud technologies. Each, as we’ve seen, has a primary advantage when compared to the others. But in truth, none of the approaches above represents a completely adequate solution to managing security in multi-cloud environments.

    The choice of which approach to take must therefore be a pragmatic one. For companies who are blessed with the knowledge, talent and time to manage multi-cloud infrastructures at a cloud-native level, this is likely to be the best solution, especially at a time when cloud waste is booming. If you take this approach, however, you should also be aware that implementing it will require putting in place thorough and rigorous code auditing processes in order to ensure that any small IaC elements that run on top of cloud-native tools do not introduce common security vulnerabilities into your network.

    For small to medium size businesses, or those running hugely complex multi-cloud systems, CMPs will be a safer bet. The reduced efficiency of these services–both in terms of computing resources and capital investment–is likely to be more than made up for by the reduced load on the admins who spend their days working with them, and the reduction in the number of mistakes that are made.

    Ultimately, it’s apparent that a new approach to multi-cloud management is required. One that combines the flexibility and speed of cloud-native with the ease of CMPs. But at the moment, it’s difficult to ascertain what that will look like.

    — Gary Stevens

  • Infrastructure as Code and Six Key Automation Concepts

    Infrastructure as Code and Six Key Automation Concepts

    This summer, I walked into an Infrastructure as Code (IaC) flame war because I was blissfully unaware of just how broadly IaC had been reinterpreted. Reviewing the comments, it’s clear that thinking has evolved since Kief Morris’ 2016 Infrastructure as Code tomb. So, after strapping on my asbestos suit, I decided to dig into what is creating such a wide range of opinions and see if I can share some 2019 insights.

    Why does IaC provoke such passion? The reason is simple: As an industry, we aspire to something that delivers on our collective vision of fully-automated, self-governing infrastructure. In the 00s we called it autonomic computing, then software defined data center (SDDC) and, now, IaC. Sadly, IaC is not it—or, more specifically, it’s not it alone.

    The actual definition of IaC is way smaller than what people want it to be.

    My take-away from IaC discussions is they are built around six key automation themes. Let’s take a few minutes to examine each of the themes. Then we’ll have a basis for answering “If that’s not IaC, then what is it?”

    Programmatic Configuration (IaC)

    Programmatic configuration captures the idea that we can define our infrastructure in a machine readable format. For example, you describe a planned cluster build in YAML to execution by a tool such as Terraform that requests the resources from your dynamic infrastructure and, hopefully, tracks that resource descriptors you get back from that request. Basically, it’s just your IaaS input format.

    Dynamic Infrastructure (or IaaS)

    It describes a system that allows operators to change the resource allocations via an API. It’s a critical part of the discussion because there must be a dependable way to pragmatically change the infrastructure. Some would consider this cloud; however, we should not assumes either managed services or VMs because dynamic infrastructure is much broader.

    Desired State (or State Reconciler)

    Desired state actively compares dynamic infrastructure to programmatic manifest and makes automatic adjustments to keep them synchronized. Typically, the idea of maintaining state is separated from configuring systems. Kubernetes and other Autoscaling cluster managers perform this role.

    Deployment from Source Control (or Immutability)

    It implies that all of the configuration components of the system can be stored as versioned artifacts and deployed from source. A Dockerfile that builds a container is a good example of an immutable process and the generated artifact. The repeatability offered by deploying from source control is transformative compared to past generations of operations that relied on either manual or scripted changes to production systems. Immutability is not IaC: We are focused on an generated deployment artifact rather than managing the infrastructure.

    Composable (or Modular) Automation

    It allows us to manage complex structures through layers of abstraction. In concept, composability is as simple as using platform plugin to script against an API.

    CI/CD Pipeline

    CI/CD pipeline is the glue that pulls all these pieces together to create a resilient environment by continuously adjusting the system components based on the operators’ IaC descriptions. The pipeline relies on having dynamic infrastructure managed to desired state as a target; however, it adds the critical concepts of staged changes over time to the system. Since we need to create systems that can adapt and improve over time, the CI/CD pipeline provides mechanism for controlled implementation change over time.

    Together, these six concepts reflect an integrated new way to think about the infrastructure that is beyond IaC. They allow us to maintain and control our systems over time in a way that is resilient and automatic. More importantly, they bring complex infrastructure problems back into terms that people can comprehend by creating more deterministic and predictable chains of change. That allows us to keep our hands out of the infrastructure and our minds focused on what we are delivering: a continuously integrated data center.

    Since all six concepts are interdependent, continuously integrated data center (CI DC) completely captures our aspirations for IaC. The term intuitively builds from source code into a fully operational infrastructure. More importantly, CI DC demands that we acknowledge the ongoing maintenance required. For that reason, I’ve embraced CI DC to replace IaC.

    Does the term work for you? How do you see IaC or CI DC being delivered in 2020? I’d like to hear your thoughts.

    — Rob Hirschfeld

  • Why Your Test Automation Is Failing

    Why Your Test Automation Is Failing

    If you have been investing in test automation, but it’s not getting you where you think it should, it could be that you approached it superficially.

    One of the most common issues is that the test part of test automation is rather straightforward to automate, especially with today’s abundance of great automation tools. But jumping straight into automated testing leaves you with a big heap of automation scripts, and often not the best ROI. Understanding why requires looking into the automation process.

    When an engineer builds an automated test, they do it in a test environment that they (or someone in the organization) set up. Usually, this is the same way manual testers get access to test environments.

    Before the engineers start automating, they have a working copy of the product they are testing, with relevant data on it. They have a good idea of the test they want to write. Everything looks promising.

    They write the test and give it a few runs. Everything is looking nice and stable. Now, to provide the ROI we were hoping for, the test must run a million times. Or, at least, a few thousand times, right?

    To reap the benefits of automation, it needs to happen frequently enough. However, the bottleneck is often discovered after creating a bunch of tests. Because the tests must run on a similar test environment to the one used to create them, with the new versions of the product or with any introduced changes that are being tested, you need access to hundreds of environments. This requirement makes it difficult to test effectively.

    Below are three test environment approaches that inhibit test automation.

    Manually Setting Up an Environment Each Time to Run Automated Tests

    For tests that don’t need to run as frequently, such as security testing and performance testing, it’s common to set up an environment for automated tests every time the test needs to be executed. As a result, testers must wait for the environment to be ready, perhaps do some additional configurations and then run a suite of tests. And, if they’re trying to optimize utilization, the environment is left to run overnight or weekend.

    The problem with this approach is it takes the “auto” out of automated testing. When automation depends on a manual step, the test is only as efficient as this manual step.

    If the manual step isn’t very efficient, automation may not be helping at all. I’ve seen companies take so long to get an environment to work that running automated tests on it didn’t make any difference from a time perspective.

    Setting Up a Static Environment That Automation Always Runs On

    When setting up an environment takes a long time, it’s natural to assume it’s worth leaving an environment running so test automation can run on it. The preparations were made, the infrastructure is all in place, the product is configured and the data is ready, so let the automation party begin.

    While complex, static test environments may seem ideal, but the party doesn’t last long. First, since it usually takes some time to put the environment together (same as the previous case), it often becomes high-maintenance. It can be scary to make changes that could ruin things, and you can end up needing someone to manage change full-time. Much like chocolate cake in the office kitchen, an environment that mimics production with good data on it tends to attract everyone. Soon, these nice environments become shared assets and tests start conflicting for the same resources. The natural next step is to set up another static environment. This loop usually ends with an angry manager saying something about cutting CAPEX.

    Automating the Environment and Cutting Ourselves Some Slack

    With the rise of infrastructure as code (IaC) and immutable infrastructure, there are more ways to spin up a test environment. Resourceful test teams will try to automate the environment creation or use built-in test tool or CI system capabilities to run tests on a public cloud instance or a container, if the product they test allows that. This is cheap and useful—and could work for some simple tests. The challenge usually starts with everything this approach doesn’t cover. It can be difficult to use IaC to spin up a test environment and handle all aspects of it—from security and isolation to dependencies, data, third-party integration and more. This is where this approach is often blocked and sends us back to the previous two approaches for a big part of the testing load—which again makes test automation investment less fruitful.

    The Right Way to Set Up Test Environments: Test Automation on Dynamic Environments

    The test automation world needs a game changer. You can make your car faster, but if the road is full of potholes, you won’t be able to get that fast or far. Test automation is similarly limited by the pace of environment creation, with its infrastructure, application, data and all.

    This challenge becomes critical when adopting DevOps and testing stops being a stage in the pipeline, instead becoming an overall pipeline service. QA is no longer about being the gate between development to operations. It’s about overseeing the quality of the product during its entire life cycle. This means automated tests should always be able to run, and the environment they run on must be dynamic.

    The solution to this challenge is environments as a service (EaaS). EaaS is all about packaging the environment, including the application, infrastructure and data, as an entity that can be provided as a service to a business process. Once defined, it can be provided on-demand for manual or automated users. Since it’s a well-defined entity, it also can be decommissioned when the process finishes using it. Playing an important role in making infrastructure horizontal, EaaS is also the key for paving the road for brilliant test automation.

    If you think you should get more from your test automation initiative, it may be a good time to make EaaS part of your automation strategy.

    — Maya Ber Lerner

  • Accelerating MVP Development Performance Through DevOps

    Accelerating MVP Development Performance Through DevOps

    The core concept of minimum viable product (MVP) is to get maximum learning and understanding regarding what customers want about a product. Learning and understanding is a continuous process requiring a development process that is incremental in nature. That makes DevOps a favorite for CIOs and everyone else who dabbles with MVP development.

    How can DevOps help in accelerating MVP development?

    Continuous Updates

    Any MVP is built with assumptions about customer preferences in mind. Developers may have a deep understanding of what customers want, but they have no solid proof. The MVP “tests the waters” and measures the depth of the customer reaction. Developers then can develop and refine the application further, depending on the customer responses.

    Building an MVP that can be easily updated is no easy task, however, especially if the MVP juggles too many APIs that collect data from heavy databases. Traditional application development tactics may not work here. It is here that DevOps makes a difference. Its continuous integration and continuous delivery (CICD) tools ensure that any application or MVP can be easily updated according to dynamically changing scenarios.

    In other words, DevOps can help accelerate MVP development.

    Microservices

    Microservices is a concept in DevOps where the application is broken down into several loosely held parts. For instance, when a social media app is being built, its various components such as a newsfeed, stories, chabot, etc., are built separately as microservices.

    The prime benefit of microservices is that the updating, maintenance and bug-fixing process is simplified and easy to manage. For MVP, this translates into easier editing of feature sets to meet changing customer preferences. Also, it breeds an organizational culture of collaboration in which developers as well as applications have to mingle with each other to perform better. Such a collaborative environment is key to accelerated development of MVP.

    Extensive Automation

    DevOps and automation go hand in hand. In fact, zero-touch automation is deemed to be the future of DevOps. Right from continuous business planning to feedback optimization, there is plenty of scope in MVP for automation.

    Needless to say, automation drives operational agility. It also quickens the pace at which routine tasks are done. DevOps adoption for MVP development means developers can make more features and deployments faster within a short span of time.

    A Scalable Foundation

    Infrastructure as code, or IAC, is a key DevOps practice. It works by configuring servers automatically, especially cloud-based servers. IAC works by creating a single configuration file for all the servers. It is like a single template of configuration that can be cloned easily for several servers.

    As a result, DevOps allows applications to quickly ramp up their server capacity in a flash. The same goes for MVP: When the MVP gets the nod of consent and is mature for advanced development, the same server setup can be used as a foundation for upscaling the resources. Also, the same configuration file can be used to set up as many as servers as you want. What is the result? Cloud servers up and ready to use without loss of time.

    DevOps and MVP Development — A Formidable Combination

    Deploying a MVP is an integral part of the development process. DevOps, with its microservices and IAC approach, can help accelerate the pace at which applications are developed and deployed. Additionally, CI/CD tools ensure wide-scale collaboration among teams.

    Integrating a DevOps culture right from the MVP stage of an application will help in the development of a final product that is bespoke to customer requirements. Even if the customer requirements are different, microservices help to quickly modify them and update the application without significant downtime. To sum it up, DevOps is the perfect approach to accelerate MVP development.

    — Dhaval Sarvaiya

  • Why DevOps Should Care About SDN

    Why DevOps Should Care About SDN

    Software-defined networking (SDN) and DevOps are not mutually exclusive. Actually, DevOps wants SDN, whether it knows it yet or not.

    Why?

    If software is going to eat the world, then SDN is going to eat networking.

    Networks are becoming more complex, and one way to manage them more effectively is through SDN. Also, organizations are demanding faster changes, yet networking changes traditionally have been a manual process.

    In a profession where network engineers typically work in seclusion and use significant manual processes, it can provide a set of tools to align with DevOps. This is why DevOps needs to care about it.

    Software-defined networking leads to infrastructure as code (IaC), which makes network automation possible.

    Software-Defined Networking and Infrastructure as Code

    SDN, in its simplest form, is controlling networking hardware with software. But there is more to it: Software-defined networking means networking switches and routers no longer need to be controlled with proprietary software. This creates an opening for innovation and is how we now have OpenFlow.

    This implies that networking now can culturally align itself with DevOps. The question will become whether it wants to. IaC is where networking will find its home with the DevOps team—it is like SDN for Ops.

    Why Does SDN Matter for DevOps?

    Software-defined networking will open communication and make automation possible—two ideas that are fundamental to an effective DevOps team.

    Open communication between networking can be easier when the mindset and tools are enabling a similar process. For DevOps, the current stack is providing tools to do exactly this. We see this with the Ansible and Red Hat DevOps networking partnership.

    What’s more, SDN enables network automation. Automation is an important goal for DevOps, which before SDN was not workable. Network automation can mean a better integration of DevOps and networking, as networking comprises many manual processes and, as such, is a bit isolationist. Aligning goals can provide better communication and collaboration.

    The Power of Network Automation

    SDN, IaC and DevOps networking are providing a set of tools and ideas that can push widespread adoption of network automation.

    Network automation is not a new topic, but implementation has been difficult. Technology had to catch up with demand: Before OpenFlow, networking infrastructure ran on proprietary software, which meant manual changes and configurations were commonplace and one-off scripts are the norm.

    With SDN and a technological environment conducive to network automation, we can begin to test different network automation strategies. Currently, however, organizations using automation only use it for segmenting their firewalls. We are in the early stages of what network automation can do.

    Just as DevOps is still finding ways to use automation in testing and development, networking is on its own discovery path to automation. The only difference is DevOps has a goal to automate and networking still views automation as a “nice to have.”

    Using NetDevOps to Bridge the Gap

    We have the conversation about SDN, IaC and network automation because networking does not have its functions accurately defined within the DevOps framework. That is why NetDevOps is a topic of discussion.

    The fact that SDN is still in its infancy stages and network automation is being discussed as “how to implement” shows there is a need for a cultural shift in networking that aligns with DevOps. This will help DevOps with communication and collaboration.

    DevOps wants automation and NetDevOps shares this goal. SDN is what makes this possible, and is exactly why DevOps should care.

  • 5 Reasons DevOps Needs NetDevOps

    5 Reasons DevOps Needs NetDevOps

    Networking’s role in DevOps is not accurately defined.

    Up to this point, networking has been integrated into DevOps through infrastructure as code (IaC), which has been around since the beginning of the DevOps movement. Although important, this does not quite encompass all of what networking needs within DevOps.

    A few of the current terms being used for networking in DevOps are:

    • Infrastructure as code (IaC)
    • DevOps networking
    • NetOps

    We have not agreed upon a universal, concrete philosophy to determine how to effectively bring networking into the DevOps conversation.

    This is why we need NetDevOps.

    NetDevOps is a construct of principles that aligns the networking team more closing with DevOps in your organization. It takes what traditionally are manual procedures in network infrastructure and applies the principles of automation and scalability.

    Why do you need yet another term or concept? This isn’t a new term; it just needs to be widely adopted.

    Therefore, here are five reasons you need NetDevOps.

    Networking + DevOps = NetDevOps

    DevOps needs networking and networking needs DevOps. The two may not admit this, but the open communication is essential. Networking’s biggest concern is network uptime, while DevOps’ ultimate goal is continuous delivery. The result is DevOps having a high interest in network availability to ensure updates can be delivered.

    Adopting a NetDevOps approach promotes networking to apply the same principles as DevOps. The goal of replicating and automating tasks—not automating for the sake of automation, but to take the processes that work effectively on one server and apply them to multiple servers.

    Remote Deployment for Cloud Adoption

    As cloud adoption increases, the need to deploy updates and changes remotely is essential. Cloud computing provides the necessary environment to implement the NetDevOps approach, which installing a hardware infrastructure allows for code deployment.

    In a cloud environment, such as AWS, infrastructure needed to implement this approach is available already. For example, AWS CloudFormation provides the necessary infrastructure for IaC.

    Infrastructure as Code

    IaC has been fundamental to the DevOps movement, and this is the foundation for NetDevOps: The ability to take network hardware and apply a set of code to the environment. The code allows you to automate an environment, which typically has needed to be updated manually.

    Automation is one of the core principles DevOps and NetDevOps share. Automation results in predictable network uptime, which provides an environment to better assist DevOps in achieving continuous delivery.

    Software-Defined Networks

    Software-defined networks (SDN) are a subset of the IaC discussion. It is the enterprise network version of cloud architecture. NetDevOps works in this environment through the use of white-box switches.

    Implementing white-box switches and installing Linux will create an SDN environment, which is conducive to NetDevOps. It is the necessary infrastructure for NetDevOps.

    Current Stack is Providing the Tools

    Once the above is implemented, a NetDevOps environment is ready to integrate with your current Ops stack. Ansible, Red Hat, Puppet and Chef already are providing the tools necessary to create a NetDevOps environment. Now you and your team need to implement it.

    NetDevOps is taking the traditional manual nature of networking and applying a set of DevOps principles. It is an environment of automation that brings networking full circle with DevOps.

  • Infrastructure as Code is SDN for Ops

    Infrastructure as Code is SDN for Ops

    As we continue to recognize the importance of DevOps—particularly its automation and orchestration aspects—to achieve the agility necessary for continuous deployment of apps, the question of how the term “Infrastructure as Code” (IaC) applies to traditionally network-bound systems and services is bound to crop up more frequently. After all, in addition to core IP-based networking characteristics required for an app to communicate and serve up content, an entire ecosystem of app services that support, secure and scale it must be considered.

    IaC is driven by the application of development principles to network infrastructure. Configuration, scripts, templates, profiles and the like are treated as code, in that they should be reviewed, versioned and provisioned from a centralized repository (one hopes on-premises) rather than managed as discrete network elements.

    In a recent article in TechBeacon, Boyd Hemphill, director of evangelism at StackEngine, noted, “The basic principle is that operators (admins, system engineers, etc.) should not log in to a new machine and configure it from documentation.”

    Christopher Null, CEO of Null Media and author of the article, then wrote, ” … But IaC is a concept that extends beyond simple infrastructure automation. IaC requires applying DevOps practices to automation scripts to ensure they’re free of errors, are able to be redeployed on multiple servers, can be rolled back in case of problems, and can be engaged by both operations and development teams.”

    The idea is that you can describe any given service as a set of artifacts and deploy (and redeploy) them at will. So rather than set up a system and configure it directly, its configuration any associated artifacts (such as profiles or templates) are treated as code and stored in a common repository. A controller—the orchestrator—is responsible for distributing those artifacts when necessary. The controller uses an API (or protocol such as OpenFlow) to manage the configuration of services across a distributed infrastructure. It’s decoupling the service definition from the service and its platform.infra as code

    Read that again. It decouples the service definition from the service and its platform and assigns responsibility for provisioning and configuration to a controller. Kind of like decoupling the control plane from the actual forwarding and switching actions (the data plane) and assigning operational responsibility to an external controller.

    At its simplest, treating infrastructure as code is separating configuration from the platform and enabling a software-driven or software-defined approach to provisioning, configuring and managing infrastructure. It’s applying the principles of software-defined networking (SDN) to operations, rather than to devices and systems.

    But as Null makes clear in his article, IaC goes beyond just automation and orchestration, adopting the best practices of development with respect to code reviews, versioning and management of that “code” to ensure consistent, predictable and repeatable deployments.

    It’s all driven by software, ultimately, and deployed by software, and defined by software but always under the auspices of the operational experts: the engineers and architects.

    Treating infrastructure as code is basically applying the architectural principles of SDN to operations itself. It’s SDN for ops.