Tag: sandboxing

  • CNCF Looks to Increase Open Source Sandbox Projects

    CNCF Looks to Increase Open Source Sandbox Projects

    The Cloud Native Computing Foundation (CNCF) today announced it has simplified the process it employs to enable open source software to become a sandbox project managed under its auspices.

    Priyanka Sharma, general manager for the CNCF, said the organization is looking to increase the number of open source projects that make up the cloud-native ecosystem. While the CNCF is best known for its efforts to govern the development of Kubernetes, the organization’s mission spans a wide range of cloud-native technologies. Many of those projects are now applicable to both microservices-based and monolithic applications that can be deployed in the cloud or in an on-premises IT environment.

    Key changes to the sandbox process include a simplified submission process using an application that asks the project owners how their project fits as part of the cloud-native ecosystem. Applications are listed in a spreadsheet available publicly for comment, with review by the Technical Oversight Committee (TOC) scheduled on a bi-monthly cadence. The existing Special Interest Group (SIG) recommendation and TOC sponsorship requirements for sandbox projects have been replaced by a simple vote for acceptance by the TOC.

    There are currently 31 sandbox projects being developed under the auspices of the CNCF. The new process for approving sandbox projects has already been applied to 11 of them. Each sandbox project has signed over the rights to the intellectual property for that project to the CNCF, which then attempts to attract more developers to participate in the ongoing effort to increase the adoption of that project.

    In some cases, CNCF projects will compete with one another for acceptance. The CNCF is committed to not becoming a “king maker,” said Sharma.

    Obviously, the CNCF is not the only organization trying to advance the adoption of open source software. In addition to The Linux Foundation, of which the CNCF is a part, there are older organizations such as the OpenStack Foundation and the Eclipse Foundation, which, to varying degrees, compete with one another to become the entity through which open source projects are governed.

    The number of open source projects being launched has increased exponentially in recent years as IT vendors transform their business models. Many now contribute their core software to an open source project in the expectation that increased adoption will lead to demand for commercial support services.

    That shift in many ways has led to a change in terms of how innovative software is brought to market. Not too long ago open source software was viewed primarily as a way to create the free equivalent of an existing operating system or database. Today, the bulk of emerging software in the enterprise starts out as open source projects.

    Much of that transition began when more IT organizations adopted “open source first” approaches to IT in the wake of the economic downturn that began in 2008. As the current downturn brought on by the COVID-19 pandemic deepens, it’s probable the preference for open source software is only going to increase in the months and years ahead.

  • How to Ensure DevOps Success in a Distributed Network Environment

    How to Ensure DevOps Success in a Distributed Network Environment

    Data-centric applications are not typical, and the environment where they’re deployed are also not typical. Most often, they’re deployed into large, distributed network of machines, which compels the question of whether DevOps practices and tools can be applied to distributed applications.

    To be successful, DevOps practices for data-centric applications must work smoothly even when production environment is a distributed network. For that to happen, developers and testers must define best practices for DevOps as well as continuous deployment into these distributed network environments.

    Can DevOps Work in Distributed Environments?

    Let’s say you’ve adopted a distributed network environment for your data-centric application production environment. Unless you’re able to successfully and rapidly develop your application for such an environment, it’s a wasted effort. Although DevOps is the solution, how many DevOps tools allow you to develop applications in distributed network environments?

    Here are three critical steps to ensure DevOps success in a distributed network environment:

    1. Containerize applications
    2. Use DevOps tools to enable a continuous DevOps life cycle
    3. Use sandboxes throughout the DevOps life cycle

    Why are they important? The above three steps help you address the what, how and where aspects of your data-centric DevOps problem:

    1. The What (Containers) —A distributed network environment, most likely, is heterogenous and consists of different types of systems and applications. Putting your application within containers will make them look uniform and allow you to easily move them from non-production to production environments, as well as from on-premises systems to cloud.
    2. The How (DevOps Tools) — To rapidly develop your application you’ll need to quickly iterate through the program-test-deploy cycle. DevOps tools help automate these steps.
    3. The Where (Sandboxes) — Sandboxes help you decide where you develop your application so that its infrastructure and environment looks the same whether you access it from development lab, or testing lab, or production data center or anywhere else.

    Of these, two steps are common to both data-centric and non-data-centric environments. Containerizing applications is definitely important to data-centric applications whose requirements don’t seem to affect DevOps tools much. Nevertheless, the DevOps practices still apply fully.

    However, the data-centric environment is quite different from a typical application environment. This makes sandboxing for distributed network environment all the more essential for data-centric applications.

    Playing in the Sandbox

    Sandboxes (also called uber containers) are basically self-contained infrastructure environments that can be not only configured to look identical to your final target deployment but also created and run from anywhere.

    Developers, for example, can create a sandbox that looks exactly like their production environment—hardware, network, OS versions, software and even cloud APIs. Sandboxes can be spun up so developers can do their development and then torn down when they are done.

    Similarly, testers can create a sandbox that looks like their internal IT environment to run a bunch of tests and then re-configure it on the fly to look like their external cloud environment so they can run some more tests. This will enable them to test all possible environments that the application could run in, without actually disrupting the production infrastructure.

    So, what, technically, is a sandbox?

    A physical sandbox is a protected space where you have complete control and others are allowed only by your invitation. You can build whatever you want with the sand and even bring your own toys into it. If you don’t like it, you can always start over.

    Similarly, a technological sandbox provides a controlled environment where you can build and test what you want without disrupting what’s outside the environment. You can even install your own software (bring your own toys) to create the desired environment for your application.

    In fact, a number of vendors are now offering sandbox solutions (also called “environment as a service”) that provide a simple interface for creating any target infrastructure environment and configuring it with any control you want. You can bring applications, tests, tools and automated processes to your sandbox. User access to your sandbox is highly controlled so no one can mess up the infrastructure that you are currently using in your sandbox.

    You can even reserve and schedule sandboxes so that whole teams of developers and testers can share the infrastructure for hours, days and even weeks at a time. These sandboxes can be triggered even from the outside, right from your DevOps tools.

    If you’re developing a data-centric application such as an internet of things (IoT) application, it needs to be deployable on distributed network infrastructure. Sandboxes provide a great way to mimic these complex, large-scale environments and allow developers to build applications that can run in this type of environment.

    Wrapping Up

    Ideally, it is possible to combine containers, DevOps tools and sandboxes to enable continuous deployment in a distributed network environment. The key is to package your application in containers, use DevOps tools to automate the process of moving through the various stages of your development cycle and create sandboxes to mimic the target product environment required to run those applications.

    About the Author / Sreeram Sreenivasan

    For more than eight years, Sreeram Sreenivasan has worked with various Fortune 500 companies in areas of business intelligence and sales and marketing strategy. He’s the Founder of Ubiq BI, a cloud-based BI platform for SMBs and enterprises. He’s also the editor of Fedingo blog, which covers a wide range of business growth topics.

  • Testing: Mind the DevOps Gap

    Testing: Mind the DevOps Gap

    If DevOps is a continuum, it starts with planning and development, and ends with deployment into operations. Much of the focus in DevOps and within the DevOps toolchain has been on application build automation (development) and deployment of apps into operations. But, for DevOps to pay off, there must be a continuous flow and automation from development all the way through to operations, and that means providing automation for the steps in between these two.

    What is in the gap between development and production delivery? Testing. Not surprisingly, when Gartner surveyed its clients in 2015, more than 50 percent of them ranked the need for test automation as one of their top priorities for DevOps success. This really illustrates the recognition that DevOps cannot succeed if only one part of the DevOps continuum is automated. Companies that have started to focus on DevOps recognize that they must “Mind the Gap.”

    Closing the Testing Gap

    Why is automating the various testing steps (regression, performance, stress, GUI, QA, interoperability and security testing) so difficult? There are five key components that must be automated successfully:

    1. The infrastructure – It starts with one very important characteristic critical to testing that is not automated – the ability to mimic the infrastructure in which the software (or hardware) being tested is expected to run in when it gets to production. Having the ability to give each tester (or set of automated tests) their own personal replica of the target production infrastructure—a “sandbox”—is critical to ensuring the software coming out of test can be deployed into production automatically and continuously. Automating tests is not nearly as difficult as automating the underlying infrastructure in which those tests run.
    2. The production environment workload – Often overlooked in automating testing is mimicking the workloads that would be common in production. This includes the network traffic, other application workloads and network security profiles. These activities need to be automated within the sandbox to create a more realistic environment for testing.
    3. Test automation – Of course, the tests themselves also must be automated and there are a variety of tools to assist in this process. As software gets more complex, automation continues to be a challenge, with mobile testing replacing GUI testing as the most challenging type of testing to automate.
    4. Reporting and result analysis – To provide continuous automation from development through testing to delivery, it is important to see and analyze test results automatically.
    5. Tool Integration – Finally, automation into and out of testing needs to be enabled. This means that sandboxes and test automation suites need to be API-driven so they can be started by a previous tool in the DevOps tool chain and can also initiate a tool that follows testing in the tool chain.

    DevOps projects tend to start in one part of the continuum from development to operations. There is nothing wrong with taking this approach. However, it is also important to “Mind the Gap” and work to expand automation across the continuum continuously. One way to ensure that automation can expand easily is to deploy sandbox technology across the continuum, beginning with development and continuing through configuration and release management. The sandbox ensures that at each step, the production configuration and workload is being replicated.

    Sandboxing technology has been used in development in the past, but is relatively new to the entire DevOps process. As more companies move to continuous integration and continuous deployment, however, the need for sandboxes is growing.

    The sandbox should provide the following:

    • The ability to create an accurate replica of the real production environment that deployment is intended for. This can include the physical, virtual and cloud infrastructure as well as applications, network traffic and load.
    • The ability to initiate a sandbox via APIs so that the sandbox can be triggered by DevOps tools as an integral part of a complete end-to-end DevOps automation.
    • The ability to automate DevOps processes inside of the sandbox (e.g. automated regression testing), as well as to automate the teardown of the sandbox and trigger the next step in the DevOps cycle when those processes complete.
    • Business intelligence about everything that happens inside of sandboxes so that DevOps processes can focus on continuous improvement.
    • The ability for many people to have their own sandboxes running simultaneously with isolation in shared labs.

    DevOps depends on continuous automation from development, through test and QA, to configuration management and production deployment. Sandboxes provide a common automation environment that can be used at each step of the DevOps cycle to close the gap between development and deployment.

    About the Author/Joan Wrabetz

    Joan's image croppedJoan Wrabetz is the CTO for QualiSystems. Most recently, she was theVP and CTO for the Emerging Product Division of EMC. Joan received her MBA at the University of California, Berkley, and MSEE at Stanford, and a BSEE at Yale. She has held teaching positions at the University of St. Thomas, St. Mary’s University and the University of St. Thomas, St. Mary’s University. Joan holds patents in load balancing, distributed systems, and machine learning classification and analytics. Her experience inclues: founder and CEO of Aumni Data, CEO of Tricord Systems, Vice President and General Manager for SAN operations at StorageTek, Founder and CEO of Aggregate Computing, Management and senior technical positions at Control Data Corporation and SRI International, Partner with BlueStream Ventures.