Tag: infrastructure as code

  • Serverless Computing: Taking DevOps to the Next Level

    Serverless Computing: Taking DevOps to the Next Level

    Serverless computing enables you to outsource information, thus freeing teams to focus on front-end work. Organizations choose serverless when they look for faster and easier ways to release updates and patches. DevOps teams often use serverless when they are looking to automate infrastructure tasks. However, each provider offers different capabilities, and each service does require a level of training pre-adoption.

    What Is Serverless Computing?

    Serverless computing is a method that outsources infrastructure and infrastructure tasks to external providers. Organizations choose serverless computing because it enables development and operations teams to focus on the front-end of products and services.

    There are a few traits that distinguish serverless infrastructures from traditional cloud automation models:

    • Serverless computing services eliminate user responsibility for the management or operation of infrastructure.
    • Serverless computing services enable users to run code on-demand according to requests or event triggers. Infrastructure use scales transparently based on how many requests or events occur.
    • Serverless computing is pay-for-use and can be used to ensure that users pay only for actively used resources.

    The benefits of serverless in enterprise environments include:

    • Better control over production deployments.
    • Faster and easier updates or patches.
    • Increased productivity and easier release rollouts.

    Popular Serverless Computing Services

    All three major cloud providers offer serverless computing services. Below you can learn about these services and how each operates.

    AWS Lambda

    AWS Lambda is a service for serverless computing with other AWS services or via API. It can be connected to applications or run as standalone code. When using Lambda, users pay for active compute time although instances can be reserved to ensure their code runs with menial latency.

    Lambda can be triggered by a variety of AWS services, including Kinesis and DynamoDB. It can be monitored through Amazon Cloud Watch. Common use cases for Lambda include data processing, stream processing, machine learning and application backends.

    Azure Functions

    Azure Functions is Microsoft’s serverless service. You can use it for end-to-end development, including building, testing and deploying code. Functions can be used with a variety of Azure services and integrate with Visual Studio and Visual Studio Code for easy use.

    In addition to Functions, Azure offers Logic Apps, a service for creating visual design workflows and orchestrating Functions activities, and Event Grid, a message routing service to integrate Functions with other Azure services.

    Google Cloud Functions

    Cloud Functions is Google Cloud Platform’s functions as a service (FaaS) (i.e. serverless) offering. It can be used in the cloud or with hybrid deployments and it includes built-in monitoring, logging and debugging features.

    Cloud Functions supports a variety of environments including Cloud Run, Kubernetes and other Knative-based environments. Use cases for Cloud Functions include integration with third-party services, application backends, real-time processing, virtual assistants and machine learning.

    Why Serverless for DevOps

    If you are already using a DevOps approach or are considering adopting one, serverless can be a good option. Many DevOps teams, especially those operating in the cloud, are already working with modular components managed via a pipeline. Moving these modular services to serverless can enable teams to eliminate some of the tasks related to pipeline management and focus on development and deployment.

    This capability is especially valuable for teams that are just getting started or are looking to switch to DevOps practices. Serverless systems can enable teams to get started with development and testing right away on a comfortable scale. Then, as productivity increases, the serverless infrastructure can smoothly scale with minimal to no effort on the part of operations.

    Another benefit of serverless infrastructures is the ability to easily enable DevOps automation. With serverless, you can deploy your pipeline without hosted solutions. You are only responsible for “glue code.” This infrastructure is flexible and you can easily modify it as needed using infrastructure as code (IaC) solutions and automated events.

    Despite these benefits, there is a potential downside to serverless. Your DevOps team does not have the same visibility into or control of the functioning of the infrastructure. While you can integrate monitoring, teams are limited in how much of the infrastructure can be customized or manually affected.

    How Serverless Can Take DevOps to the Next Level

    There are several ways serverless deployments can be leveraged to improve DevOps productivity. Below are a few examples to consider.

    Infrastructure as Code

    Provisioning infrastructure is often a significant portion of deployment processes. Many applications use a variety of serverless services as building blocks through all stages of development and release. Making sure that these services are correctly connected and configured is key to a successful deployment.

    IaC can help users accomplish these tasks smoothly by leveraging declarative languages and tools such as Terraform. With these solutions, users can version your infrastructure along with their code, keeping tasks in sync and deployments consistent.

    Flexible Deployments

    With serverless services, infrastructure is immutable. Any changes result in new instances being spun up and activated. This means both old and new versions can run simultaneously.

    This immutability can be used to perform flexible deployments that are not possible or are much more difficult with traditional infrastructures; for example, canary or blue-green deployments. With serverless infrastructure, users can switch from one version to another with minimal fear of service interruptions and the ability to easily rollback updates.

    Distributed DevOps

    Serverless services can enable DevOps teams to work across a variety of environments and locations with minimal impact on others. These services allow the distribution of workloads at scale and can ensure that infrastructure is always available.

    The catch is that greater distribution and the ephemeral nature of serverless can make infrastructure much more difficult to monitor effectively. To account for this, teams need to ensure centralized monitoring with real-time alerts. Teams should also periodically audit infrastructure availability and performance to ensure that resources are functioning as expected.

    Conclusion

    Serverless computing enables DevOps teams to eliminate time and cost on the back end. Each serverless provider offers different services that can help achieve different capabilities. The main capabilities are provided via the use of functions, which enable the automation of infrastructure. However, in most cases, teams do need to learn how to use functions to properly configure customized IaC workflows. Once teams understand how to use the software, they can create flexible deployments and a distributed DevOps pipeline.

  • IaC and Kubernetes: A Natural Pairing

    IaC and Kubernetes: A Natural Pairing

    Using IaC with Kubernetes helps standardize Kubernetes cluster configuration and manage add-ons

    Infrastructure as code (IaC) is the ability to provision and manage infrastructure using a configuration language. It offers repeatability, transparency and the application of modern software development practices to the management of infrastructure including networks, load balancers, virtual machines, Kubernetes clusters and monitoring.

    IaC helps to reduce error and configuration drift while allowing engineers to spend time on higher-value tasks. IaC defines what the end state of infrastructure should look like, instead of defining a process to be executed.

    So Why Aren’t All Companies Using IaC?

    There are three main reasons why companies may not yet be embracing IaC.

    Many industries and engineers have not fully embraced or adapted to the paradigm shift of infrastructure APIs and code

    A lot of us think about infrastructure as touchable, involving physical installation and cabling. It’s only relatively recently in enterprise IT years that the industry has adopted APIs that allow borrowing and configuring infrastructure on-demand without the physicality. Engineers are good at standing up infrastructure using a time-tested, battle-hardened process. Incremental learning and integrating IaC into processes and culture helps to digest an otherwise daunting and challenging project.

    Industries are hard at work adapting security controls and regulations to incorporate the opportunity of cloud and automation without compromising high standards for privacy, safety and security. Engineers using IaC to improve their own efficiency can help champion its use in wider circles. One such example of this success is the 18F office which helps improve how the government serves the public through technology.

    IaC may feel like a loss of security or control

    Increasing the awareness of how and why infrastructure is configured can invite questions or feedback that initially may feel uncomfortable to those who have made infrastructure decisions. The ease with which others can make changes to infrastructure may feel dangerous or devaluing to engineers who have always pushed those buttons.

    IaC provides an opportunity for improving single human points of failure and knowledge bottlenecks without jeopardizing necessary controls. Access to infrastructure code and IaC tools can still match organizational structure, culture and approval processes. Infrastructure engineers remain integral to its evolution and success, and they are more available to tackle next-level problem-solving.

    ‘We move too quickly to take the time to ramp up with IaC, and we’re fast at clicking in user interfaces’

    The repeatability achieved by IaC means artisanally created infrastructure does not need to be kept around because it may be needed next month and parallel infrastructure can be created for testing and destroyed tomorrow. Start using IaC for something small such as spinning up that occasional temporary VM, then create a limited-access service account that someone else can use along with your IaC when they need that VM. Your IaC efficiency will grow with your organization’s body of IaC knowledge and code.

    Kubernetes and IaC

    Using IaC with Kubernetes helps standardize Kubernetes cluster configuration and manage add-ons. Infrastructure now can be versioned and committed to a Git repository, and it can more easily be “stood up” elsewhere when the company needs to expand to new regions or clouds. IaC benefits are vast and include:

    • Reduced human error and increased predictability: Create new test environments without impacting production and make changes across multiple environments using code review processes. Focus and attention to detail are less impacted by repetitive manual work.
    • Consistency: The repeatability of IaC with Kubernetes allows for the rapid creation of consistent infrastructure. This frees up time to address other challenges.
    • Improved changed tracking and auditability: When infrastructure is represented in a versioned repository such as Git, commits to the Git repository can reflect who, when and why changes were made. The code provides a record of how environments were built and evolved.
    • Faster speed to recovery: The reliability of an application is impacted by the ability to pivot and the speed to redeploy. Infrastructure as code can help you know what the recovery process looks like and practice that process more often.

    Start Using IaC and Kubernetes

    As a company moves into the world of containers, cloud-native apps and Kubernetes, IaC will help teams improve application reliability and stability, streamline development and operations and support a better user experience.

    In a Kubernetes environment, reliability becomes much easier to achieve with IaC because teams are deploying standard configurations. DevOps teams can use IaC to embrace the ephemeral nature of containers and Kubernetes pods, as well as avoid single points of failure.

  • How IaC Bridges the Divide Between DevOps, Security

    How IaC Bridges the Divide Between DevOps, Security

    IaC provides a connection between security and DevOps teams in a subtle, non-intrusive manner

    Companies often choose DevOps as means to provide value and responsiveness through rapid, high-quality service delivery. Instead of traditional siloed development and operations teams, DevOps embraces multidisciplinary teams that share efficient practices and tools. Essential DevOps practices include agile planning, continuous integration, continuous delivery and application monitoring. But how does security fit within this framework?

    Traditional models of product development have explicitly defined processes and people dedicated to security assessments, analysis, testing and maintenance. While this doesn’t offer the efficiency and agility of DevOps, many organizations find comfort in having a set place and time for security.

    In DevOps, with the absence of strictly defined and linear processes, there is perhaps a less explicit definition of where and how security fits in. But sometimes there is power in the less obvious aspects of life. In fact, just because there aren’t dedicated, standalone security processes as there are in traditional product/project management models doesn’t mean that security isn’t there.

    Some could argue that the less apparent security is, the higher its efficacy. This is particularly true in the DevOps world, where security teams are sometimes perceived as impeding the speed and agility of DevOps teams. This perception is unjust because, quite often, it is not the security team that is necessarily impeding the progress of the DevOps team. The root of the problem is a fundamental disconnect between the security and DevOps teams.

    So, how can teams overcome this divide? By evolving their DevOps team into a DevSecOps team. Every company’s goal should be to make security part of the development workflow. Again, DevSecOps is the natural evolution of DevOps. The process can either take the benefits that DevOps gives to the development and operations branches of your IT department and extend them to the security team, or it can integrate the security processes into the DevOps team. With the latter approach, the bridge is then built by shifting cloud security left using infrastructure as code (IaC) plans and templates. Security teams can build these plans and templates for developers as a way of guiding them toward security and compliance and preventing policy violations and cloud misconfigurations from the very beginning. Shifting much of the security team’s work earlier in the development life cycle, long before runtime, is a smart and efficient approach.

    Through the use of IaC templates and plans, DevSecOps teams are engaged in security from the very start. And, for the most part, the layer of security in the form of an IaC template or plan is silent. It is a noninvasive way for security to participate in DevOps, without the friction that sometimes arises in the midst of chaotic runtime security fixes. Though its presence may be subtle, the benefits of hard-coding cloud security through IaC are pronounced.

    Most conspicuously, it prevents the need for security to intervene in recurring problems. The same security issues, policy violations and misconfigurations that took time and resources to resolve can be addressed at a global level through IaC plans and templates. Secondly, the efficiency of the security team grows exponentially. Time previously spent tracking down the right developers to fix ephemeral security issues and misconfigurations is redirected and refocused. Security teams are able to spend their time more wisely, creating thoughtful, holistic approaches delivered through IaC plans and templates. Another benefit of creating DevSecOps teams and using IaC is that it can empower individual teams to use the tools of their choice.

    While some companies mandate the use of specific cloud service providers or third-party tools, others do not. When used correctly, security achieved through the use of IaC templates provide the flexibility of incorporating variables from any cloud environment. DevSecOps teams that have the opportunity to use the cloud service providers and tools of their choice will work more efficiently and effectively. The final and most significant benefit is the connection that IaC provides between security and DevOps teams. Not only does it broaden participation in security, it does so in a gentle, non-invasive manner.

  • 5 Capabilities Network Infrastructure Must Have to Support DevOps

    5 Capabilities Network Infrastructure Must Have to Support DevOps

    According to the Accelerate 2019 State of DevOps report, high-performing DevOps organizations achieve over 200 times more frequent deployments and over 2,600 times faster recovery times than low performers. These outcomes have been realized by both forward-leaning organizations such as Amazon, which deploys code every 11.6 seconds, and more traditional enterprises that have been in existence for a long time. For instance, Nordstrom, a well-known American retailer, increased the release frequency for its mobile app from twice per year to monthly.

    Embracing DevOps results in significant advantages, including improved team collaboration, cooperation and productivity. Companies can get digital products, applications and services to market faster because of the higher deployment and release frequency. Because development and operations teams are not operating in silos, unaware of each other’s constraints, there are lower failure rates within production environments. Cooperation leads to faster recovery times when there are issues with deployment.

    To achieve DevOps success, teams must engage in a new approach to network infrastructure, and the network infrastructure must have the following five attributes.

    Automation

    Automating repetitive tasks, such as configuring DNS or a firewall, saves a lot of time and effort. It eliminates manual errors by standardizing deployment and configuration of network infrastructure. Automation can be achieved by using Infrastructure as Code (IaC), which entails using an application programming interface (API) to create, modify and shut down infrastructure. This ensures that a repeatable, consistent configuration can be created. This code can be version-controlled, which serves as a form of documentation—it’s easy to detect what changes were made by whom in case there’s an issue—and rollback to a stable state is quick and easy.

    Standardization puts an end to “It worked in my environment” or “It worked on my machine” as any issues can be easily reproduced, resulting in faster resolution times. Support for IaC tools, such as Terraform, is essential for network infrastructure to advance DevOps practices.

    Continuous Integration/Continuous Delivery (CI/CD)

    CI is a coding best practice wherein code is checked into version control repositories frequently. It provides a consistent and automated way to build, package and test applications. CD picks up where CI ends and deploys applications in an automated fashion in a variety of environments, including production, development, test and sandbox.

    There are a variety of tools, such as Jenkins and Ansible, that DevOps teams use for CI/CD integration. It is imperative for network infrastructure to integrate with these tools to accelerate deployment velocity.

    Elasticity

    DevOps teams spin up and spin down test/development/sandbox environments routinely. Infrastructure may also be needed for short periods to account for seasonality or for handling sudden surges in traffic and demand. DevOps-friendly network infrastructure must be elastic to support these activities.

    Appliance-based vendors who provide network services are not scalable as they impose artificial limits on their usage (such as queries per second or leases per second) and require organizations to anticipate their needs in advance. When there is a need, organizations have to spend time procuring these appliances, waiting to receive them and, finally, deploying and managing them—a very inefficient way to manage demand.

    Support for Containers

    Containers are the foundation for developing cloud-native applications. Containers allow developers to package up application code and all its dependencies, including libraries and other binaries, as well as configuration files needed for running the application. This enables applications to be executed quickly and reliably across a variety of environments.

    Containers provide flexibility and portability of applications across public, private, hybrid cloud and even bare-metal environments. They are lightweight, as all containers share the underlying machine’s OS system kernel. They also lend themselves to greater modularity, which is essential for developing microservices-based applications.

    Instead of a monolithic application consisting of a three-tiered architecture, a microservices-based application consists of several smaller services that perform one function and one function only. It’s easier to scale, easier to manage and faster to develop such applications. Because containers have a small footprint, they are most suited for microservices architecture.

    In order to support containerized applications, network infrastructure must first be compatible with containers. Network infrastructure must be able to configure DNS, allocate IP addresses for containerized applications, route traffic intelligently between containers and balance loads for optimal performance. Network infrastructure must also support Kubernetes, the most widely deployed orchestration platform. To ensure that the needs of DevOps teams are met, it is important to inquire with network services vendors about compatibility with containers and Kubernetes, as many legacy, appliance-based solutions cannot support this technology. 

    Self-Service Access

    To move quickly, development teams may need to configure network infrastructure for test/development/sandbox environments. Having to submit tickets to network operations teams that use legacy appliances for delivering network services significantly slows down application development and deployment. Providing self-service access to network infrastructure, such as firewalls, load balancers, DNS and DHCP for development teams, eliminates the reliance of these teams on network operations teams. Self-service with robust role-based access controls reduces the deployment time and increases efficiency while freeing up network teams for more strategic projects.

    Conclusion

    DevOps attempts to minimize friction in application deployment by providing autonomy to development teams so that they don’t have to rely on network administrators to provide the necessary infrastructure needed for development and testing. But, the move to DevOps requires more than a consolidation of teams.

    Success requires best practices such as automation, CI/CD and self-service access to infrastructure, as well as support for containers and Kubernetes, which are key to building modern, cloud-native applications. Teams that incorporate these capabilities will see increased agility and speed that lead to shorter delivery time, higher-quality applications and improved communication and collaboration throughout a product’s lifecycle.

  • 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.

  • Chef Updates Tool for Managing IT Infrastructure as Code

    Chef Updates Tool for Managing IT Infrastructure as Code

    Chef today updated its tool for automating the management of IT infrastructure as part of an effort to further eliminate the need to rely on manual processes that generally fail to scale.

    John Wyss, vice president of product for Chef, said Chef Infra 16 adds a Unified Mode that provides a more streamlined means of executing policies and adds support for YAML, which means IT teams can now employ Chef to automate the management of infrastructure without having to write code.


    In addition, Chef has made it easier to update legacy instances of cookbooks built using Chef and added support for Arm processors.

    Interest in automating the management of IT infrastructure is expected to accelerate considerably in the wake of the economic downturn brought on by the COVID-19 pandemic. Many IT teams are likely to be considerably reduced in size. The remaining IT staff will need to automate the management of IT at much greater degrees than ever before. Much of that infrastructure soon may also be residing in a public cloud rather than in an on-premises IT environment.

    Of course, Chef is not the only way to automate the management of IT infrastructure. However, IT professionals who master Chef typically are able to create workflows that automate a wider range of tasks.

    As an early pioneer of using code to manage infrastructure, Chef has been making a case for employing the Ruby programming language to make it easier to manage IT infrastructure at scale. While adoption of Chef largely has been limited to IT professionals who could master Ruby, Wyss noted those individuals who have mastered Chef will be in much higher demand as organizations look for IT professionals who have the skills required to manage tasks that otherwise would have required a much larger staff.

    It remains to be seen to what degree IT professionals might embrace IT automation frameworks further. Many have developed their own scripts to automate a task. The challenge IT organizations have encountered is that those scripts are usually poorly documented and generally fail to scale. Automation frameworks provide a means to consistently manage IT infrastructure at scale in a way that is easily repeatable.

    In the meantime, the debate of who inside the IT organization will automate the management of infrastructure continues to rage. Some IT organizations want developers to be responsible for the entire stack as part of an effort to reduce headcount, while other organizations prefer to have developers for a variety of reasons focus all their energies on writing application code. Regardless of who automates the management of infrastructure, the one thing that just about everyone agrees on is that legacy processes for managing IT infrastructure that typically involve many rote mundane tasks are no longer the way to work.

    In fact, increased reliance on IT automation might accelerate the adoption of best DevOps practices because the frameworks required to automate the management of the underlying infrastructure might have been put in place already by the IT operations team, noted Wyss. Otherwise, the DevOps team itself has to put those IT automation frameworks in place with or without the help of the rest of the IT operations staff, which is a current state of affairs that many DevOps teams would just assume live without.

  • 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

  • Rackn Extends Reach of IT-as-Code Framework

    Rackn Extends Reach of IT-as-Code Framework

    Rackn announced the Digital Rebar platform it created to automate the provisioning of bare-metal infrastructure now can be applied simultaneously across multiple physical sites.

    Company CEO Rob Hirschfeld said Digital Rebar 4.3 makes it possible to manage IT infrastructure as code across highly distributed computing environments. Previously, IT organizations would have needed additional versions of Digital Rebar for each physical data center.

    Hirschfeld also noted IT teams can also set up mirrors of data centers, now that Digital Rebar can be employed across multiple sites.

    IT teams that adopt Digital Rebar can define workflows through which, for example, instances of virtual machines or Kubernetes can automatically be deployed on hundreds of thousands of servers in about an hour, said Hirschfeld.
    Accomplishing that same task using manual processes would take most IT teams six months, he noted, adding IT teams can even use Digital Rebar to deploy instances Kubernetes on virtual machines at scale.

    Hirschfeld noted many IT teams assume they need to have a layer of virtualization in place before they can start automating the management of their IT environment. Digital Rebar provides a framework around a common set of application programming interfaces (APIs) through which servers, storage and networking resources can be provisioned consistently. In addition, IT teams can set up a to manage IT infrastructure on an ongoing basis, including firmware and operating system updates and cluster configurations.

    Digital Rebar doesn’t necessarily replace the need for frameworks such as OpenStack or VMware vSphere. However, it does provide a simpler mechanism for installing them. Alternatively, IT teams can employ Digital Rebar to deploy software such as Kubernetes on a bare-metal server.

    Hirschfeld said Digital Rebar is designed to be deployed on-premises or in a public cloud rather than be accessed as a software-as-a-service (SaaS) application. That approach means IT teams operating in highly regulated industries can still take advantage of the framework, he said.

    While the concept of IT as code has been around for a while, IT teams that are being asked to now manage IT at an unprecedented scale are turning to IT automation frameworks in larger numbers. Hirschfeld said Digital Rebar is now designed to replace other frameworks as much as it is to provide a complementary framework for specifically managing bare-metal infrastructure. In fact, Digital Rebar can be access vis Terraform or Ansible using a plug-in that Rackn makes available.

    Rackn also plans to extend the reach of Digital Rebar out to edge computing platforms as well as endpoints based on, for example, Raspberry Pi platforms, he added.

    Most IT teams will eventually wind up employing multiple IT automation frameworks in place of thousands of custom scripts that many IT professionals have developed themselves. The issue with most of those scripts is they don’t tend to scale especially well. In addition, they are usually poorly documented so when the author of the script leaves the organization the remaining IT staff wind up having to write another custom script because no one is quite sure how the script in place works. Whatever the path forward, the one thing that is certain is the days of being able to get by manually provisioning platforms is finally coming to a merciful end.

    — Mike Vizard

  • 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

  • From Pets to X-as-Code: Enabling Control and Predictability for ITOps at Scale

    From Pets to X-as-Code: Enabling Control and Predictability for ITOps at Scale

    Amy Wheelus, vice president of network cloud at AT&T, recently spoke about declarative predictability at the Open Networking Summit in Antwerp. AT&T is the world’s largest telecommunications company providing mission critical communication services where people’s jobs–and lives–can be on the line. As they move away from labor-intensive IT operations toward cloud-native automation, there is a need to trust the declared IT infrastructure state can be predictably controlled and reproduced. This requirement to build predictability, reproducibility and trust into IT systems is not new but has grown in both scale and complexity as IT departments went from a few servers blinking in the basement to the core around which every business rotates. 

    With every customer interaction and business function becoming more digital, companies must be able to rely upon their IT departments if they hope to continue to keep pace in today’s rapidly changing world. This article traces the evolution of IT operations from Pets towards X-as-code with each improvement bringing companies closer to declarative predictability. These best practices enable enterprises to reliably deliver core business value through their IT department and keep pace in the cloud native era.

    Yesterday: Pets Versus Cattle and Infrastructure as Code

    Back when the IT department was just servers in the back room, it was all hands on deck when anything went wrong because work ground to a halt. The CEO couldn’t get their emails and the sales department couldn’t book new orders. From these early days, it was learned that in order to trust IT with critical business services, high availability and reliability needed to be built into the system. This lead to the creation of the Pets vs. Cattle analogy where each infrastructure component is interchangeable and can quickly be replaced when anything goes wrong. This allows companies to quickly recover from or even avoid outages.  

    While treating servers as cattle solves some problems, as any rancher can tell you, handling a whole heard brings its own set of challenges. As the size of managed infrastructure grows, it can be difficult to keep track of where, when and how it is actually deployed. In addition, changes to production systems to keep them healthy can lead to configuration drift creating unique snowflake servers which are pets rather than cattle. It becomes a difficult task to predict how a system will react or rely upon it in critical situations when its actual state is unknown.

    To help eliminate this problem and control how infrastructure is configured and deployed, ITOps teams moved to infrastructure-as-code. In this way of working, applications and servers are never modified once deployed. If something needs to be changed, a new version is created and the old one is decommissioned. Each deployment can be versioned to create an overview of what is in production and how it is deployed.

    Managing cattle rather than pets and using infrastructure-as-code has helped companies move from ticket-based operations with long lived machines to more scalable and dynamic infrastructure. These practices build reusability, scalability, automation and versioning into IT systems to create a simpler, more predictable deployment and management process. By being able to declare the state of its infrastructure, companies are able to predict and trust the outcome.

    Today: Cloud-Native Infrastructure

    Looking at the definition of cloud native from the Cloud Native Computing Foundation, it quickly becomes clear why many companies are turning toward these best practices. They help companies build and run resilient and manageable infrastructure that–combined with robust automation–creates dynamic, yet predictable systems. Declarative APIs and immutable infrastructure will be used as two examples to understand how cloud native builds upon and expands the techniques covered above.

    Declarative APIs make infrastructure as code and automation possible. For example, with Kubernetes, operations teams are able to declare the desired state of the system and automate the reconciliation with the actual state until they match. It originally began with just container orchestration but has since expanded to cover many other types of cloud resources including the physical infrastructure itself through Custom Resources and Cluster API respectively. Declarative APIs make infrastructure management simpler and more reproducible by automating operations and eliminating errors in production. Declarative APIs can be leveraged to create immutable infrastructure.

    Immutable infrastructure goes beyond just servers as cattle and only treating the infrastructure as code. Immutable infrastructure covers every higher layer of the stack until each one is codified and managed like cattle. Only exact copies are deployed and they can be completely replaced at any time. If anything needs to be changed, a new deployment is made and the old ones are decommissioned. Immutable infrastructure works for the whole stack to eliminate variations leading to fewer deployment failures, consistency across environments, easy horizontal scaling and a simple rollback and recovery process.

    As these two examples show, cloud native enables companies to reliably scale out dynamic IT services without having to simultaneously scale out their operations team. Building declarative predictability into systems engenders trust in automatic processes, even when critical services are running on them.

    Tomorrow: X-as-Code

    While cloud-native best practices provide many benefits, applications and infrastructure are just the beginning of the story for enterprise IT teams. In today’s world, they are presented with the Herculean tasks to manage a dynamic and sprawling environment while still keeping in compliance with internal policy along with national and international laws. This challenge moves far beyond mere servers and treating them like cattle to compliance and governance across multiple clouds and hundreds or thousands of developers. With these challenges in mind, the question still remains on how to best deliver on these demands at the enterprise scale.

    Looking across architecture, configuration, blueprinting, policy and governance, if each of these is simply viewed as another layer of the stack above the application, their operations can be radically simplified. By applying the principles of immutable infrastructure and cattle to this further layer of the stack, each of these can be defined and managed using an X-as-code model. These types of management models can already be seen taking root across the cloud-native ecosystem.

    Kubernetes creates blueprints-as-code through the use of Admission Controllers while policy-as-code can be defined in Pod Security Policies and Network Policies. The CNCF even has a policy engine, OPA, as a sandbox project that gives operators fine-grained yet flexible policy control across their entire stack. By using code to decouple policy and other layers from the actual implementation, the resulting stack is easier to understand, flexible enough to handle future requirements and less expensive to maintain.

    At Loodse, our customers were struggling to manage configuration, services and policy across their clusters. Leveraging the Kubernetes controller paradigm in Kubermatic, we are able to automate the deployment and lifecycle of each of these add-ons. This gives users the ability to declare, enforce and automate the required state of not only the infrastructure but the configuration and policy, too. Kubernetes controllers bring predictability and control to dynamic and scalable cloud-native IT even as it begins to handle more and more mission critical services.

    Cloud Native in Production: Declarative Predictability

    With IT becoming the core of every business, bringing cloud-native best practices into production enables operators to predictably declare, run and manage their infrastructure at the enterprise scale. Being able to trust in these automated operations frees up resources and opens up many new possibilities. Developers can be given guardrails and become empowered to do their job rather than waiting in a ticket queue. Operators can easily create highly available self-healing infrastructure that meets governance standards allowing them to focus on delivering a platform with differentiated business value.

    At each step of the development of modern IT practices, from cattle to X-as-code, operational processes have become more streamlined allowing both developers and operators to drive more value to the bottom line. The future of IT infrastructure and operations will be a trusted platform that automates undifferentiated heavy lifting, allowing the whole business to focus on customer value.

    To learn more about containerized infrastructure and cloud native technologies, consider coming to KubeCon + CloudNativeCon NA, November 18-21 in San Diego.

    — Bill Mulligan