devopsy.kinsta.cloud

Category: Containers

  • DevOps: The Glue of Workflow

    DevOps: The Glue of Workflow

    The best tool in the DevOps continuum is the sticky wrapper that holds it all together. It is the workflow that binds it and makes sense out of the term “continuous.”  CIOs often are enamored with a build or deploy tool, but it is the workflow tool in every DevOps strategy encapsulating more than one function that is the real hero. Imagine having the perfect test automation scripts but no way to execute them outside of constructing a new build. Or imagine having the perfect CMDB integration scripts but no way to call them outside of the build process. Or even worse, imagine having the need for human approval before a deployment takes place (or is promoted), and no way to integrate it outside of a custom deployment process.

    Lean DevOps Construction

    Attempting to make very few tools perform these functions without a workflow engine ultimately forces automation engineers to create functionality within a tool it was never designed to perform. Conversely, when a workflow wrapper is available, build and deployment processes can remain small, elegant and consistent, allowing the workflow engine to integrate extended functionality into the continuous delivery cycle.  Size of the automation constructs you create does matter: the smaller the better.

    Using Lean methodologies in your DevOps services, it is better to break down automation constructs into the logical functions they are intended to provide. Build automation, for example, should not have to include extensions to turn monitoring functions on or off. Build automation also should not have to worry about the deployment process; its primary singular purpose is to construct a new build. Where that new build is then deployed becomes the single purpose of the deployment process.  Attempting to automate the entire cycle of an application into one automation construct from end to end (instead of smaller blocks that work together) increases both size and risk (as well as length of time to execute) of that one event.

    Dealing with Humans in the Automation

    Human integration is the bane of DevOps processes. Every time you have to pause automation to obtain a human approval, you introduce time delays that cannot be predicted or occur with consistency. Imagine a deployment process that requires a human to press “yes” before continuing. The introduction of a human approval can sit idle on a tooling screen for hours during lunch, or unexpected days off, or vacations (when others are afraid to take responsibility for passing a substandard build, even for further testing). Deployment tools can integrate human responses, but this is not their forte. They are generally ill-equipped to use multiple contact methods, go up the management chain when needed or ping a mobile device when preferred by the user listed as responsible. Workflow tools are ideal for all of these human-contact logistics.

    The challenge during DevOps service construction in utilizing a workflow wrapper is keeping human interaction to the absolute minimum required by outside regulating agencies and still achieve compliance. The alternative is to automate processes with such quality and consistency so that human interaction would merely become redundant and unnecessary. The workflow wrapper is not an excuse to simply automate what human interaction you have today. Instead, it is a highly functioning tool to allow you to redesign more-effective automation processes, limiting human interaction where possible. The goal is to build small, independent automation constructs that work together in a highly efficient manner.

    Hold the Presses

    Communication or notifications also can be handled in a workflow wrapper much better than in individual DevOps toolings. Imagine for a moment that I am a release manager, wanting to know the progress (or rather obstructions to progress) for my new application. To accomplish this notification process, it would have to be embedded within my build process (to know if it passed or failed). The alternative is that my workflow wrapper checks the build logs and can send me notification in the method I prefer (email, text message, an Instagram pic of Thelma and Louise over the cliff, etc.) In addition, I may not actually want to check the status of every build submitted, as that becomes noise after a while. I may want to know only when a build candidate has passed and is ready for promotion to a further testing environment. Since my workflow wrapper would be aware of this, it could automate the notification to me quite easily.

    Now add the consideration of management chain to this notification process. If I am out on vacation (which I expect to be able to do, since DevOps enables my personal life), my manager or my sponsoring executive may want to be notified if my application is not going to production for some reason during my absence. This is a level of automation that most build or deploy tools are simply not designed for. They have no idea who I report to and who that person reports to. But that departmental notification escalation chains can be incorporated easily into a workflow wrapper, and execute as expected while I am away (including pinging my cell phone just in case I need to jump in and fix something).

    Release Management Solutions

    Most release management (RM) or release orchestration (RO) tools have at least minimal workflow capabilities built into their offerings. Whether this capability is enough for your organization or whether you need a more capable workflow engine to wrap around it is a decision only you can make. Most release management tooling is designed to put an elegant wrapper around build automation and deployment automation. It usually contains the ability to segment by line of business or product, as well as role-based access controls (RBAC) for permissions and auditory compliance. And it usually contains at least elementary notification capabilities. What RM excels at are human interaction and tracking progress, and so it does meet the needs of many companies.

    When RM is not enough is usually when the DevOps services you provide begins to extend into ancillary services and secondary automation integration capabilities. Examples include monitoring systems integration, multiple testing tooling integration/evaluation, configuration management database (CMDB) integration and capacity-on-demand environment provisioning.  Highly evolved notification systems tend to require an external workflow wrapper beyond the normal capabilities an RM tool offers. A solid workflow wrapper acts as the glue that can hold disparate DevOps tooling (either from different vendors or performing different functions) together with further super-automation processes above them like an overarching umbrella.

    Impacts to the Bottom Line

    Choosing to offer DevOps services without any form of a workflow wrapper is like going hunting with an excellent rifle and no bullets: a lot of capability that can never reach the potential it was intended for. On the other hand, obsessing about replicating current processes within a workflow tool is like hunting a bunny rabbit with a bazooka: way too much damage caused when trying to keep things small and elegant. The key is to balance the use of a powerful tool (workflow), with Lean thinking in automation processes and constructs. Keep the building blocks small and functionally oriented; limit human interaction; and use workflow for the functions it is best-suited for—connection and communication.

    The technical capabilities a workflow wrapper will add to your DevOps solutions are substantial. Your services will be far more efficient and far more powerful. However, to truly assess the financial impact of a highly functioning workflow system, one must determine the value of time and decision-making. An elegant notification system can keep you informed without sending you countless emails you learn to ignore or flooding your text inbox with data that exceeds your cellular plan. In this way, notifications are meaningful, and you can begin to make meaningful business decisions based on the information you receive, only at the times you need to see it. What is that worth to you and your organization? Only you could really assess that.

    To continue the conversation, feel free to contact me.

     

  • DevOps: Commoditizing Infrastructure

    DevOps: Commoditizing Infrastructure

    Hardware vendors face a quandary. How do you distinguish yourself as superior from your competitors if you are unable to continue to grow a distinct architecture as your competitive advantage? But this dilemma does not begin and end with only hardware vendors; operating system vendors and virtual machine vendors are on the same horizon. In an effort to “uncomplicate” hardware idiosyncrasies, our industry evolves efforts from open standards to least-common-denominator functionality for a “common” language or set of features, and over time technologies such as containers emerge. If I can abstract my application from the “uniqueness” of hardware vendors, from the complexity of configuration settings, and make only assumptions about basics such as CPU, disk, memory, etc., then I am free to focus on the application and allow my “hardware mitigation technology” to perform its function.

    The Relationship Between App and Storage

    But to accomplish this feat, I must agree to a basic set of features or functions I intend to call, such as making “x” amount of machine memory available to my application. Whether disk or RAM, I am looking to define what my application needs and then expect the container (or hardware mitigation/abstraction manager of my choice) to manage the actual allocation. Then the quandary begins. Asking for 1TB of disk space as an example is generic enough. But does my request include the ability to specify I am looking only for disks that spin at more than 7,500 revolutions per minute, or will I be saddled with 5,000 rpm disks? There is a clear implication in speed for my app.

    Ultimately, as I sit and tune my code because my app has become “slow,” it could be something as innocuous as having its actual execution occurring in a cloud provider who uses the slower disk revolutions as opposed to the faster ones. Worse, it simply could be that the same cloud provider has a batch of the slower ones in one of its data centers where I wind up executing (only on a temporary basis), and I am never fully able to figure out why my app got “slow” for a while. That kind of random bad ju-ju requires the execution of a chicken to fix (I prefer Popeye’s, myself).

    Different storage vendors might have additional peculiarities that make one or the other superior in speed, reliability or performance over their respective competitors. But the container’s main functionality is to provide “disk” to my app. Specifications of specific disk vendors or providers are the problem of the cloud provider, not the app developer, in theory. But hardware refresh can be pricey, and to make a claim that “all our disks” have rpm specifications above 10,000 will be meaningful only for about 10 minutes when the 12,000 rpm models come out. And of course, there are many more architectural designs in the engineering that are intended to boost speed and reliability. If these are not to be ignored, a decision must be made as to “who” has the responsibility to manage their usage (usually the cloud provider), and “who” will complain when things get slow (usually you the customer).

    And what happens when “breakthroughs” occur in a specific technology? Solid-state hard drives, for example, are not exactly new now, but they once were. When you move your app from operating on a high-speed hard drive that spins to a chip-based hard drive the operates at the speed of the RAM it is based on, the difference in speed is an order of magnitude better. The inevitable question emerges, Will my container have the ability to specify RAM-based disks instead of traditional spinning disks, as part of the disk commodity it is providing to my app?

    Since the difference in speed is so great, you would think it would come up with a way. You would equally expect that providing offline storage such as tape (from the age of the dinosaur) would have its own designation in my container structure (not be equated with offline spinning drives due to the speed differential). When you go to make a backup or restore, the difference between tape and hard drive becomes as apparent as the difference between solid-state and spinning drives on app execution. So when a platform evolves, my container mitigation must evolve with it. But to offer the uniqueness of vendor superiority requires my programmers to learn who to request (or what level of hardware specs they must know), which is the whole point of wanting a commodity in the first place: I don’t have to know.

    Impact of Commodity on Other Components

    This same dilemma can be exhibited in CPU vendors. Intel touts its superiority, AMD would disagree, and there may always be an upstart who wants to rival the current leader in any space. Lest we think Intel-based computing is the undisputed champion, quantum computing may upset that assumption (unless, of course, Intel corners that market as well). The point here is simply to ask: how many features, how many specifications, how much do we the programming team need to know about our platform provider to understand why and where our application runs better and worse? In the days before container-style ideology, hardware vendors touted their differences and their uniqueness as the reason they were better. Now what?

    Then comes our virtual machine providers, and eventually our operating systems. If I want to truly abstract from my hardware layer, I must not call an OS-unique command that only Linux or only Windows can do. I must stick to functionality that both OS instances can reasonably understand and accommodate. While this least common denominator is great for extending where my app can run (on multiple types of hardware, in multiple types of OS installations), it has the same effect on uniqueness and potentially on competitive advantage. If the intent is to come up with a one-world OS, I am generally in favor, but our journey there is sure to have certain casualties in innovation that a single OS is suited for and its competitors are not.

    The inevitable question becomes, How far down, or how far up, do we want to form commodity provisioning of computing capabilities? One could argue that the simplicity of the iPhone platform is a user-centric expression of commodity provisioning at the top of the stack. Drag-and-drop programming languages are yet another expression of bucketing computing capabilities into more simplistic expressions (that more people can understand and, therefore, utilize). Commonality and simplicity do increase audience. In many segments of our industry, this is the nirvana of sales to the public.

    Impacts to the Bottom Line

    DevOps focuses on enabling innovation. At its core DevOps is focused on software innovation. Let’s face it—changes to hardware platforms are generally less frequent. If those hardware platforms are married to a particular app (not serving a large number of apps on the same box, same virtual instance, etc.) then at least provisioning can be tuned one to one with the app. But with the desire to turn infrastructure into a generic commodity that application programmers don’t have to think about comes the fact that they stop thinking about them. Over time they will understand less and less about why things become slow, or work better, as the knowledge of uniqueness goes away.

    Depending on your market focus, ubiquity is either your friend (as it touches consumers) or your enemy (if you are the hardware vendor attempting to maintain relevance over your competitors in an increasingly commoditized market). The questions I raise in this article are designed to focus on how to keep our trend toward hardware mitigation from stifling innovation in the very hardware platforms we depend upon. In any case, I welcome your thoughts on the topic.

    To continue the conversation, feel free to contact me.

  • NodeSource Announces Containerized N|Solid Deployment for Kubernetes

    Developers can now deploy enterprise-grade Node.js on Kubernetes

    San Francisco, CA – July 26, 2016 – NodeSource, the Enterprise Node Company™, today announced at Node Summit 2016 the beta launch of its containerized N|Solid™ deployment for Kubernetes. With this release, NodeSource is offering the first version of Node.js with production-ready continuous performance and security monitoring within a Kubernetes cluster.

    A recent Node.js Foundation survey found that 45 percent of developers use Node.js with container technologies such as Docker. As companies look to build out their next-generation architectures, Node.js and containerization are emerging as two key components for powering rapid technical innovation.

    Kubernetes makes deploying, scaling and managing containerized services fast and simple. With an N|Solid deployment for Kubernetes, developers get real-time performance monitoring and vulnerability scanning of Node.js applications running in a Kubernetes cluster.

    “Node.js is ideal for containers because it allows developers to quickly build, iterate and scale cloud-native APIs, apps and microservices,” says Aparna Sinha, Product Manager, Kubernetes & Google Container Engine. “It is great to see NodeSource offering a Kubernetes deployment for Node-specific monitoring and security, allowing companies to scale with confidence.”

    N|Solid combined with Kubernetes orchestration provides developer and operations teams with:

    • Efficient scaling of microservice/distributed architectures

    • Node-specific performance insights and analyses

    • Continuous Node.js package security vulnerability scanning

    • Expedited deployment of new Node applications

    • Automated rollouts and rollbacks

    • Service discovery and load balancing

    • Horizontal application scaling

    “We are seeing a popular trend emerging among our enterprise customers with the adoption of containerization for Node.js and Kubernetes for cloud orchestration,” says Joe McCann, CEO and co-founder of NodeSource. “Adding the powerful monitoring and security features of N|Solid, we are creating the trifecta for high-performance Node.js services.”

    N|Solid is available for download as a native package (Linux and Mac), Docker images and now as a pre-configured Kubernetes deployment. For more information, visit <landing page>.

    About NodeSource:

    NodeSource is a technology company dedicated to delivering enterprise-grade solutions in support of a sustainable ecosystem for the open source Node.js project. We aim to drive and expand the Node.js ecosystem by providing best of breed solutions that specifically target the needs of the enterprise. Customers include NASA, HomeAway, Condé Nast, Craftsy,  and other progressive Node.js adopters who are leading the charge in microservices via server-side JavaScript instead of maintaining legacy monolithic applications like Java. We are a Distributed by Design organization – our teammates report to work from all corners of the world: Asia, Australia, Europe, South America, as well as NY, SF and Austin. NodeSource is backed by RRE Ventures, Crosslink Capital and Resolute.vc and our AngelList Open Source Syndicate. For more information visit www.nodesource.com and follow @nodesource.

  • Red Hat Launches Ansible-Native Container Workflow Project

    RALEIGH, N.C.–(Business Wire)–Red Hat, Inc. (NYSE: RHT), the world’s leading provider of open source solutions, today announced the launch of Ansible Container under the Ansible project, which provides the leading simple, powerful, and agentless open source IT automation framework. Available now as a technology preview, Ansible Container allows for the complete creation of Docker-formatted Linux containers within Ansible Playbooks, eliminating the need to use external tools like Dockerfile or docker-compose.While standardization is emerging for container formats in the form of the Open Container Initiative, the tooling space is still fragmented, with developers often forced to work outside of the enterprise workstream to create and deploy containerized applications. Ansible Container changes this dynamic, by bringing Linux container development into the existing workstream through the easy-to-consume Ansible Playbook, adding cloud-native application development side-by-side with traditional application building.

    Alongside Ansible Container, the Ansible project has also launched new Kubernetes modules which allow for the production of Kubernetes templates directly from an Ansible playbook. Combining the two new offerings, IT teams can now build Linux containers directly from a playbook and deploy to a Kubernetes-based container application platform, like Red Hat OpenShift, in a more streamlined and efficient manner.

    Ansible enables developers and IT operators to more easily and quickly deploy IT applications and environments, empowering them to remove barriers between IT teams by automating routine activities such as network configuration, cloud deployments, and creation of development environments. Ansible’s modular code base, combined with ease of contribution, and a community of contributors in GitHub, enables the powerful IT automation platform to manage today’s infrastructure, but also adapt to new IT needs and DevOps workflows.

    With the capabilities of Ansible Container, users will be able to automate their existing infrastructure and networks with Ansible playbooks, while using additional playbooks to containerize their applications and deploy them on a container application platform. This allows for continuity of operations by preserving existing IT investments and critical applications/systems without sacrificing innovation in the form of cloud-native applications and container orchestration at scale.

    The automated container creation and deployment offered by Ansible factor into Red Hat’s existing container infrastructure stack, which now includes:

    • A stable, container-centric operating system in Red Hat Enterprise Linux Atomic Host.
    • An enterprise-grade, Kubernetes- and Docker-native container application platform through Red Hat OpenShift and the recently announced next-generationOpenShift Online public cloud service.
    • Infrastructure management, automation and monitoring across hybrid environments with Red Hat CloudForms, Red Hat Insights, Red Hat Satelliteand Ansible Tower by Red Hat.
    • Massively-scalable private and hybrid cloud architecture for large-scale container deployments through Red Hat OpenStack Platform and Red Hat Cloud Suite, which also includes Red Hat OpenShift.

    Red Hat’s container stack provides a fully-open, enterprise-grade experience, from developers building cloud native applications to operations teams managing and monitoring a diverse set of hybrid applications and environments. Built entirely from upstream, community-driven projects, Red Hat’s container portfolio provides the innovation to drive the next-generation of enterprise IT while also allowing for the retention of mission-critical modern and legacy systems.

    For more details or to try it in its current form, visit the Ansible Container project.

    Supporting Quote

    Greg DeKoenigsberg, director, Ansible community
    “Many users in our community have already grown accustomed to using Ansible to deploy and manage their containers, and the Ansible Container project is an encapsulation of many of the community’s best ideas, brought together into a single tool. The user traction we’ve received in a fairly short period of time indicates to us that we’re targeting a critical need in the container tooling space.”

    Additional Resources

    Connect with Red Hat

    About Red Hat, Inc.

    Red Hat is the world’s leading provider of open source software solutions, using a community-powered approach to provide reliable and high-performing cloud, Linux, middleware, storage and virtualization technologies. Red Hat also offers award-winning support, training, and consulting services. As a connective hub in a global network of enterprises, partners, and open source communities, Red Hat helps create relevant, innovative technologies that liberate resources for growth and prepare customers for the future of IT. Learn more at http://www.redhat.com.

    Forward-Looking Statements

    Certain statements contained in this press release may constitute “forward-looking statements” within the meaning of the Private Securities Litigation Reform Act of 1995. Forward-looking statements provide current expectations of future events based on certain assumptions and include any statement that does not directly relate to any historical or current fact. Actual results may differ materially from those indicated by such forward-looking statements as a result of various important factors, including: risks related to the ability of the Company to compete effectively; the ability to deliver and stimulate demand for new products and technological innovations on a timely basis; delays or reductions in information technology spending; the integration of acquisitions and the ability to market successfully acquired technologies and products; the effects of industry consolidation; uncertainty and adverse results in litigation and related settlements; the inability to adequately protect Company intellectual property and the potential for infringement or breach of license claims of or relating to third party intellectual property; risks related to data and information security vulnerabilities; ineffective management of, and control over, the Company’s growth and international operations; fluctuations in exchange rates; and changes in and a dependence on key personnel, as well as other factors contained in our most recent Annual Report on Form 10-K (copies of which may be accessed through the Securities and Exchange Commission’s website at http://www.sec.gov), including those found therein under the captions “Risk Factors” and “Management’s Discussion and Analysis of Financial Condition and Results of Operations”. In addition to these factors, actual future performance, outcomes, and results may differ materially because of more general factors including (without limitation) general industry and market conditions and growth rates, economic and political conditions, governmental and public policy changes and the impact of natural disasters such as earthquakes and floods. The forward-looking statements included in this press release represent the Company’s views as of the date of this press release and these views could change. However, while the Company may elect to update these forward-looking statements at some point in the future, the Company specifically disclaims any obligation to do so. These forward-looking statements should not be relied upon as representing the Company’s views as of any date subsequent to the date of this press release.

    Red Hat, the Shadowman logo and Ansible are trademarks or registered trademarks of Red Hat, Inc.or its subsidiaries in the U.S. and other countries. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

    Red Hat, Inc.
    Anna Eusebio, +1-919-754-4519
    aeusebio@redhat.com

  • Docker Automates and Democratizes Container Orchestration

    SEATTLE–(Business Wire)–DockerCon – Docker today announced Docker Engine 1.12 with built-in orchestration, a powerful combination that provides Developers and IT Operations with a simplified and automated experience to deploy and manage Dockerized distributed applications – both traditional apps and microservices – at scale in production. By adding this additional intelligence to Docker Engine, it becomes the orchestration building block, creating a model for engines to form a self-organizing, self-healing pool of machines on which to run multi-container distributed applications. When integrated into Docker Engine, these new capabilities optimize ease of use, resiliency, performance-at-scale and security – all key requirements that are missing in other orchestration systems. As a result, organizations can be assured that their dev and ops teams are aligned on unifying the software supply chain to release applications into production more rapidly and frequently.“Orchestration is at the same stage today as containerization was before Docker. You either need an army of experts to build it, or you lock yourself to a monolithic platform which will drastically reduce your choice of suppliers,” said Solomon Hykes, founder and CTO at Docker. “Three years ago we brought containerization into the mainstream by making it usable for non-experts, without lock-in. We think it’s time to do the same for orchestration. This is a necessary step for the industry to move forward, and as the leaders of the containerization market it’s our responsibility to lead this change.”

    As with all Docker tooling, this integration is always about choice and flexibility for users. “Swarm mode” is an optional feature that users can select to “turn on” built-in orchestration, or they can also elect to use either their own custom tooling or third-party orchestrators that run on Docker Engine. This approach aligns with the Docker platform’s batteries included but swappable architecture, which has spurred the growth of a vibrant and collaborative ecosystem.

    “As the adoption curve for Docker continues to grow, developers have encountered growing pains with orchestration at scale,” said Fintan Ryan, industry analyst with RedMonk. “With the inclusion of secure built-in orchestration in the 1.12 release, Docker is providing developers with a simple-to-use, yet extremely powerful, orchestration tool while further investing in a consistent, easy-to-manage experience for operations.”

    As organizations begin to make increasing investments in containerization, and with more than 60 percent of them running Docker in production, they are seeking more sophisticated orchestration tooling to expand their deployments across both applications and teams. Docker 1.12 addresses these requirements with functionality that spans the entire application stack across compute, network and storage.

    Ease of Use

    Docker 1.12 dramatically simplifies the process of creating groups of Docker Engines, also known as swarms. The self-organizing, self-healing capabilities of swarms are now backed by automated service discovery and a built-in distributed datastore. As a result, it takes just one command to add a Docker Engine and horizontally scale a swarm.

    Resilient

    The new service deployment API describes all the resources and components with a single command that allows operations teams to run and scale a service. Through the API, the swarm is aware of the application defined and will continuously check and reconcile the environment against the requirements of the application when something adverse happens. Unlike other systems, the swarm itself has no single point of failure. The state of all services is replicated in real time across a group of managers so containers can be rescheduled after any node failure.

    Performance at Scale

    Docker orchestration includes a unique in-memory caching layer that maintains state of the entire swarm, providing a non-blocking architecture which assures scheduling performance even during peak times. Additionally, the system has a built-in routing mesh technology that addresses the challenge of how to provide container-aware load balancing. The routing mesh ensures that requests are made to the right containers regardless of where they have been scheduled within the swarm.

    Secure By Default

    Each Engine is automatically assigned a cryptographic identity which ensures that only validated Engines can be accepted into a swarm. Moreover, Docker Engine comes with mutually authenticated TLS, providing authentication, authorization and end-to-end encrypted communications among every node participating in the swarm, without the operator having to take any steps to enable it.

    Availability

    There are three ways that users can get Docker 1.12, which is currently a release candidate with general availability planned for July 2016. First, it is available now as part of the newly opened public beta of Docker for Mac and Docker for Windows athttps://www.docker.com/getdocker. Second, it is available through cloud-optimized experiences that bundle custom plugins that provide deep integration between Docker and the target platform capabilities including networking, load balancing and SSH key management. Docker for AWS and Docker for Azure are the best ways to deploy Docker Engine on these platforms and are available in private beta at https://beta.docker.com. Last, Docker 1.12 is also available as a binary download or a package for all major Linux distributions at https://docs.docker.com/engine/installation/linux.

    For more information:

    About Docker, Inc.

    Docker, Inc. is the company behind the Docker open source platform, and is the chief sponsor of the Docker ecosystem. Docker is an open platform for developers and system administrators to build, ship and run distributed applications. With Docker, IT organizations shrink application delivery from months to minutes, frictionlessly move workloads between data centers and the cloud and can achieve up to 20X greater efficiency in their use of computing resources. Inspired by an active community and by transparent, open source innovation, Docker containers have been downloaded more than 4.1 billion times and Docker is used by millions of developers across thousands of the world’s most innovative organizations, including ADP, Baidu, the BBC, Goldman Sachs, Groupon, ING, Yelp, and Spotify. Docker’s rapid adoption has catalyzed an active ecosystem, resulting in more than 4,300,000 “Dockerized” applications, over 100 Docker-related startups and integration partnerships with AWS, Cloud Foundry, Google, IBM, Microsoft, OpenStack, Rackspace, Red Hat and VMware.

    Mindshare PR
    Heather Fitzsimmons, 650-279-4360
    press@docker.com

  • 5 Development Trends Reshaping Testing

    5 Development Trends Reshaping Testing

    There’s no shortage of new development trends, but virtual reality, containers, big data, hyperconnected apps and IoT are affecting testing the most today.

    If you like change and challenge, it’s a fun time to work in software. Some technology developments, such as cloud computing, have been gaining speed slowly over many years. That steady progression has meant that developers can stay on top of trends easily and be informed about market changes. Other areas, such as containers, have come to fruition much faster without as much notice. Development teams have had to scramble to stay ahead of these trends, hoping to capitalize on a their efficiency gains while staying ahead of the curve. Here’s a look at five important software trends which are having a profound effect on testing.

    Containers

    Docker made containerization cool and exciting in 2013, even though containers have arguably been around for many years, if not decades. Developers love containers because the technology makes it much easier to set up and install software in different environments, such as in the public cloud or in a private data center. Containers wrap up all of the infrastructure components that otherwise would be installed separately into one easily portable package with a common standard. And since multiple containers can run on the same hardware without creating problems, you can do more with less infrastructure. Typically, containers can move between different environments with relative ease—a nice benefit for multicloud infrastructures. Containers have evolved quickly from an experimental platform to a mainstream infrastructure technology, with many major businesses taking advantage of containers to deliver their product at scale.

    Testing considerations: It’s hard to find much at fault for containers when it comes to facilitating software testing. Because of the ease in setting up test environments and moving code from one environment to another during the production cycle, testers can work much faster. Before containers, there was a lot more waiting around by both developers and testers. When it takes two weeks to set up an environment for a testing cycle that took two hours, teams would tend toward less frequent releases or would do less testing. Now, it is a matter of minutes to set up a testing environment. This is great for companies and development teams that value testing and want to test more frequently with greater access to a variety of environments.

    Another boon with containers is stability. In the past, bugs sometimes appeared due to configuration errors from setting up dev/test environments. Given the plug-and-play nature of containers, there’s little if any concern about the proper configurations being completed before a testing environment can be used. Security has been an ongoing concern with containers, especially in highly regulated sectors such as health care, government and financial services. In those cases, companies may have to support two versions of the code—one in a containerized platform and one in a more traditional virtual or bare-metal environment. We believe this will be a short-term situation as containerization technology matures and becomes adopted across all industries.

    Big Data

    Whether you want to use this vague and overhyped term or not, big data is simply a new way to refer to larger than normal data sets. Big data became a big trend as the hardware and software to store and manage it got a lot more powerful and cheaper, and the cloud shift helped to centralize data sets into one location. Some large companies and research organizations are seeing interesting results from big data projects already, whether in more targeted drug development (precision medicine) or just-in-time environmental data for farmers. Now, every Tom, Dick and Harry is trying to get into the big data market, which means there are too many solutions to count. A natural weeding-out process will occur over the next few years, as the prominent big data players and NoSQL standards converge into two or three leading providers.

    Testing considerations: Big data applications bring value through the way they manage and/or analyze data, not so much through the user interface. Therefore, testing for big data applications is going to require more technical, database-oriented skills. Those skills are also different from the typical relational database skills of the past, given the fact that big data platforms typically are designed to manage structured and unstructured data. These are open source tools and systems such as NoSQL and Hadoop, along with large vendor systems such as SAP HANA. Testers in this field will need to be constantly adapting learning these new technologies.

    Virtual Reality

    Investors have funneled $8.8 billion into the sector since 2012, according to SuperData Research. Google, Facebook, Microsoft, Samsung and HTC are all in the game. The market is segmented between VR, augmented reality (AR) and mixed reality (MR) and consists of both traditional (PC/console) and mobile device applications. VR is a fully immersive, fully virtual experience that mimics reality, while AR and MR are different variations of blending real and virtual environments together. VR applications aren’t just for gaming anymore: We now are seeing the technology being used for product design and collaboration, tourism/travel and entertainment, including film.

    Testing considerations: VR is an emerging technology still, with many different types of platforms, no clear leaders and no real standards in place. That makes it more difficult for developers and testers to make strategic decisions around technology. As well, there aren’t any great tools for automated testing in these environments yet. Therefore, the need for manual and real-world testing will add time and cost to the project. Yet, investing in doing this right is critical for ensuring optimal user experience. In virtual reality environments, it’s difficult to simulate experiences, such as testing for motion sickness, without actually playing with the real devices. This is especially challenging with the newer mobile platforms, such as Google Cardboard, which incorporate a viewing device that transforms the mobile phone into a VR headset. That experience simply can’t be simulated accurately on a PC, a common testing strategy for other mobile apps. Companies testing mobile VR apps may need to invest in the purchase of dozens or hundreds of different mobile devices to gain an accurate picture of how the application performs for most users.

    Hyperconnected Apps

    Web-based and consumer apps comprise the bulk of hyperconnected apps, characterized by having deep, often real-time integration with other applications. Instagram and Facebook, Gmail and Google Calendar, Salesforce and their wealth of apps—these are just a few examples of hyperconnectivity. The advent of REST APIs has facilitated far easier and cheaper integration so any company can build a platform of third-party software in ways they couldn’t have imagined five or 10 years ago. Similarly, with the explosion of the app economy, including open source software, it doesn’t make good economic sense to write 100 percent of code in your application any longer. Product value is increasing the result of how developers can patch together different technologies in innovative ways.

    Testing considerations: Given the importance of APIs in hyperconnected applications, a primary testing consideration will be ensuring the performance validity of those connection points. It’s imperative for both developers and testers to be aware of API update schedules and to test those updates immediately for any negative impact on the application. Beyond API testing, load and performance testing are also important considerations for hyperconnected applications, which typically involve heavy and/or unpredictable transaction processing. Overall, these types of testing are much more technical in nature than manual UI testing and will require testers to expand their skill set to optimize value.

    Internet of Things (IoT)

    The interest in (and hype) for the IoT sector rivals the largest IT trends, such as big data. Initial applications have focused on connecting devices, such as home lighting and thermostat systems, which use sensors to stream data to smartphones. Over time, we will see more device-to-device connections such as a thermostat collecting data from a smoke detector to ensure that the house isn’t on fire if the temperature rises dramatically. Products such as Amazon Echo and Google Nest might be at the heart of many new consumer-based IoT applications, but there is also ample potential in sectors such as utilities, health care, industrial equipment and government (a.k.a. smart city initiatives).

    Testing considerations: As IoT applications mature, connectivity complexity will grow. IoT applications can involve many components: the hardware of the smart device or product and the software that controls it, along with the user applications that interact with the product. When troubleshooting an issue or vulnerability, a tester must investigate the applications that collect, analyze and display the IoT data, the various network connections across which that data travels, the IoT appliance’s hardware and its software. Hardware testing must incorporate typical scenarios such as what happens to the user experience when a device starts to run low on battery or goes offline. Testers will be most valuable when they have experience in both hardware and software testing; alternatively, an organization can have two teams of testers but they must be in very close contact. IoT apps should also be configured to collect and deliver more alerts and logging data than mobile apps, due to the higher number of components involved. This will make it easier to prevent, troubleshoot and fix problems when they arise.

    About the author/Kevin Dunne

    Kevin Dunne picKevin Dunne is VP of Strategy and Business Development at QASymphony.

     

  • Booz Allen Helps the GSA Put Your DevOps to Shame

    Booz Allen Helps the GSA Put Your DevOps to Shame

    Production Docker, automated workflows, open source projects and microservices are just some of the ways that Booz Allen is helping the General Services Administration (GSA) modernize its IT operations. And frankly, after talking to Nirmal Mehta, the lead architect on its recent project, I became a little embarrassed for you DevOps-born startups.

    In my circle of friends, the frustration and sarcasm used to describe government processes is a common pastime. And it’s totally fair. Even without being an insider, you can still easily approximate the magnitude of wasted money due to bad business processes and dated IT operations.

    But things are turning around. Beyond the early negative press, the issues with healthcare.gov made very clear that the gap between large enterprise and government IT and the modern development shop is massive. And even more recently, the use of private sector hackers to unlock phones, and the continued efforts to recruit from and partner with Silicon Valley show that the government needs the best and the brightest technical help.

    One government institution, the GSA, took the modernization challenge head-on. It selected Booz Allen Hamilton to lead the charge and build a new development platform—one that will ensure dev projects deliver results faster, at higher quality and are more systematic.

    The GSA is an arm of the government responsible for managing the contracts and processes for vendors that wish to do work with the government. If you have sold to the government in any fashion, you are familiar with it. The administration oversees more than $1 trillion in transactions and more than 300,000 vendors and contractors. To manage the processes across a wide range of categories, it requires many web and mobile applications, with new ones coming on board every year.

    Before working with Booz, GSA’s IT ops were about what you would expect—big, slow and risky. New projects took months to get started, with solutions that could take more than a year to complete, and they were ultimately subject to dreadfully low sub-30 percent success rates. (Watch this video and pay attention from the 8:30 point on).

    The GSA came to a point where it fully recognized the hard cost of this way of operating, and the indirect cost of maintenance, tech support and unhappy customers on both the vendor and government-consumer sides. It knew something had to change.

    Booz’s solution was not 100 percent unique, but its implementation was above and beyond. The firm decided to build a unified platform as a service (PaaS) that served as a portal for all new development projects. In some organizations, this is called “shared services.” But with Booz’s platform, it went beyond just application components.

    The users of the solution would be development teams who were awarded projects. Once awarded, they would access the platform and create a service that consisted of applications and microservices. They would be given immediate access to a private repo via GitHub Enterprise, which would also include Docker Compose files.

    Then, the teams were off and running. As soon as they made their first commit, the system—already wired up and driven by Jenkins—would pull, run tests and deploy containers to dedicated nodes in a continuous integration (CI) environment, run on FedRAMP-compliant AWS regions. Then the instances were automatically given IPs, where the development team could begin testing.

    In addition to a prebaked development and deployment system, the platform provided the development team an entire DevOps stack, giving them “the entire application and lifecycle environment to build their application,” explains Mehta. That included everything from identity management and infrastructure-as-code to business intelligence (BI) and even release automation, so that after the applications were deployed, the teams had what they needed to run updates, measure and learn.

    The idea is that a development team with this platform only needs to think about the logic of the application, not process. And now, at the organizational level, there is oversight, continuity and reliability—something which the GSA had never seen before. After the changes, instead of dealing with long contracts and RFP processes, the CTO could approve bids and get development up and running in days, and create solutions in months, not years.

    Mehta’s team was responsible for architecting the system, putting it all together and vetting the “marketplace” of tools made available to developers. By doing so, people were able to make sure the proper security considerations were—and are—made, and that the tool configurations, Chef scripts and Docker images stay consistent.

    The whole thing was built based on a set of principles. Cloud-first, secure foundation and, to my surprise, open standards and open source. The U.S. government, which fought cloud and open source for so long, is now one of its biggest champions. “I think 2015 was a huge tipping point in gov open source adoption. I think we have hit an inflection point for sure, and I’ve realized that DevOps really implies open source,” Mehta says.

    If this is too hard to believe, just check out Booz Allen’s Jellyfish project (which has become part of the ManageIQ project), and this open source policy document in the GSA’s own public 18F repo, which encourages entities to use open source technologies it has developed.

    This does not mean the GSA won’t spend money—that is not the driver of open source tools. The driver is cross-pollination, giving back and building better code through standards. Where warranted, such as with wanting full Jenkins support via CloudBees, the GSA will invest in technology. Jenkins is the heart of the system, and basically the home of all of the platform’s workflows and automation. Having the backing of CloudBees is important. Plus, CloudBees is a GSA vendor. It also has become one of Docker’s early customers. I can’t imagine the love it gets from those kids.

    Often when I do these case studies, the solutions are too new to validate long-term success. But the platform has been up for six months now, with several development teams and beta applications deployed, which means the system works! The path to prod is still manual and belongs to a separate team, but there are goals to automate that as well.

    A government agency is finally more focused on results than process. (If you have ever been through the RFP process, you know what I mean.) “The government is realizing that it is not sufficient to give the modern user, who expects technology that works [to stay with] legacy applications,” Mehta says. The platform also allows the GSA to have smaller contracts, and in theory, smaller and better development teams who don’t have to worry about development operations overhead.

    When I asked Mehta if his project is the norm or just a fluke, he said “more and more companies are asking us about DevOps, not just cloud migration. We know that if they just do a cloud migration, they are going to create more problems faster.” He believes that even if DevOps is not explicitly stated, federal and local governments do care about modern IT ops—if not because they want to, but because they have to.

    So, can you say you have a fully automated full-stack container-driven platform that spans multiple applications and multiple development teams? Chances are no, but you could, and you should. Mehta and team have proven that even the government can have a Ferrari of a development environment and stay on the cutting edge.

    To learn more about Mehta’s project, watch his session at DockerCon2015 here. And check out this presentation from Navin Vembar.

  • RightScale Releases New DevOps and Docker Trends in Follow-Up to State of the Cloud Report

    SANTA BARBARA, CA — (Marketwired) — 05/11/16 — RightScale® Inc., a demonstrated leader in enterprise universal cloud management,today announced the results of the RightScale 2016 State of the Cloud Survey: DevOps Trends. The fifth annual RightScale State of the Cloud Survey was announced in February. This follow-up report provides new data and analysis in a deep dive on DevOps, Docker, and container trends. The RightScale 2016 State of the Cloud Report series is the result of a survey to 1,060 technology professionals at large and small enterprises across a broad cross-section of industries.

    The survey results are available in the RightScale 2016 State of the Cloud Report: DevOps Trends, which can be downloaded at www.rightscale.com/2016-devops-trends-report.

    “The survey shows that the vast majority of enterprises are adopting DevOps and this usage is being driven from the bottom up by projects, teams, business units, and divisions,” said Kim Weins, vice president of marketing at RightScale. “Companies are using a portfolio of DevOps technologies that include configuration management tools as well as containers. While Chef and Puppet are still the most widely used DevOps tools, Docker has seen extraordinary growth, more than doubling in the past year. Companies report a lack of experience with containers and have made educating themselves a top priority in the coming year.”

    Highlights of the RightScale 2016 State of the Cloud Report: DevOps Trends include:

    • DevOps is growing, especially in the enterprise: DevOps adoption increased from 66 percent in 2015 to 74 percent in 2016. DevOps adoption is strongest in the enterprise (81 percent of enterprises adopting DevOps compared to 70 percent in SMBs). Enterprises are adopting DevOps from the bottom up: Adoption of DevOps by projects or teams (29 percent) and business units or divisions (31 percent) is more common than company-wide adoption (21 percent).
    • Docker usage doubles while Chef and Puppet are neck and neck: Overall, Chef, Puppet, and Docker are the top three DevOps tools used by respondents (32 percent, 32 percent, and 27 percent, respectively). Among enterprises, more use Puppet (42 percent) vs. Chef (37 percent) and Docker (29 percent). Docker is the fastest growing DevOps tool, with adoption more than doubling year-over-year from 13 percent in 2015 to 27 percent in 2016. In the enterprise, Docker also saw more than 2x growth (from 14 percent to 29 percent) while Ansible nearly tripled (from 8 percent to 23 percent). Docker could soon be the most used DevOps tool in the enterprise as 38 percent of enterprises have plans to use it. This compares to 20 percent who plan to use Chef and 19 percent who plan to use Puppet.
    • DevOps users use multiple tools: Less than half (43 percent) of companies are using a configuration tool such as Chef, Puppet, Ansible, or Salt. Use of multiple configuration tools is more common (25 percent) than a single configuration tool (18 percent) and 67 percent of companies using Chef or Puppet also use the other tool. Configuration tools are also often used with Docker; 80 percent of Docker users also leverage at least one configuration tool.
    • Container adoption is maturing, especially in enterprises: Overall, 26 percent of respondents have workloads already running in containers (8 percent in development, 18 percent in production). 36 percent of respondents are experimenting with containers, while 25 percent are learning about containers. Enterprises are using containers more than SMBs. 29 percent of enterprises have workloads running in containers versus 24 percent of SMBs, and 41 percent of enterprises are experimenting as compared to 33 percent of SMBs.
    • Docker seeing greatest adoption in Europe, with tech companies, and with enterprises: Evaluating Docker adoption across different geographies, industries, and roles, RightScale found that current use of Docker is heaviest among tech organizations (32 percent), enterprises (29 percent), and developers (28 percent). Use of Docker in Europe (34 percent) is also well above average.
    • Significant interest in containers on bare metal. Containers are currently being deployed primarily on virtual machines (29 percent) versus bare metal (12 percent). There is significant interest in deploying containers on bare metal with 24 percent of respondents having plans to do so in the future. Most containers are built using traditional Linux distributions such as Ubuntu (43 percent), CentOS (39 percent), and Red Hat (37 percent). CoreOS (12 percent) is the most widely adopted of the minimalist operating systems, which are designed specifically for containers.
    • Biggest challenge with containers is lack of experience for newbies: For respondents who are not currently using containers, lack of experience was by far the top challenge (39 percent). The top challenges cited by respondents who are already using containers were security (29 percent) and immature technology (29 percent).
    • Container focus in 2016 is education and experience: The top container initiative in 2016 will be getting more educated (62 percent), followed by conducting more experiments with containers in dev/test (44 percent) and production (28 percent), as well as expanding container use in dev/test (28 percent).

    Survey Methodology

    RightScale conducted its annual State of the Cloud Survey and RightScale State of the Cloud Report: DevOps Trends in January 2016. The survey questioned technical professionals across a broad cross-section of organizations about their adoption of cloud computing. The 1,060 respondents range from technical executives to managers and practitioners and represent organizations of varying sizes across many industries. Their answers provide a comprehensive perspective on the state of the cloud today. The margin of error is 3.07 percent.

    About RightScale

    RightScale Universal Cloud Management enables leading enterprises to accelerate delivery of cloud-based applications that engage customers and drive top-line revenue while optimizing cloud usage to reduce risk and costs. With RightScale, IT organizations can deliver instant access to a portfolio of public, private, and hybrid cloud services across business units and development teams while maintaining enterprise control. RightScale Consulting Services help companies develop cloud strategies, deliver cloud projects, and optimize cloud usage. RightScale was named a “100 Best Places to Work in 2015” by Outside Magazine and was listed in “The Best Enterprise Cloud Computing Startups to Work For in 2015” by Forbes. Since 2007, leading enterprises including Audi, Pinterest, and Yellow Pages Group have launched millions of servers through RightScale.

    Contact:
    Bret Clement
    Email Contact

  • Rancher Labs Secures Series B Funding of $20M for Container Management Platform

    Led by new investor GRC SinoGreen, with participation from existing investors, funding will help Rancher Labs maintain momentum, and meet sales and marketing goals

    Cupertino, Calif. – May 10, 2016 – Rancher Labs, a provider of container management software, today announced $20M in Series B funding led by new investor GRC SinoGreen, with participation from existing investors, Mayfield and Nexus Venture Partners. As the container market continues to experience significant growth, Rancher Labs’ open source platform for managing containers is seeing demand grow exponentially. Last month the company announced the general availability of Rancher, a container management platform that supports both Kubernetes and Docker Swarm, making it possible for hundreds of organizations to run containers in production. This funding will be used in support of sales and marketing initiatives to keep pace with demand for the product.

    “We are seeing a lot of attention and demand for our Rancher platform and feel it is due to our unique approach to container management,” said Sheng Liang, CEO of Rancher Labs. “Containerization has enabled organizations to do amazing things to improve application performance, availability and cost. The next piece of this puzzle, which will really help to perfect container technologies, are the tools around the management of containers. We are excited to continue efforts in furthering our goal of providing users with the right tools to take advantage of container technologies, and the financial and organizational benefits they promise.”

    Unlike other container management platforms, Rancher is open source, easy to use and designed to make it simple for users to harness the power of containers. Rancher’s unique ability to rapidly spin up and manage Kubernetes and Docker Swarm environments, while maintaining a single management experience, makes it ideal for enterprise deployments. Rancher is the only container management platform to implement a cloud-agnostic infrastructure services layer that works across any public or private cloud, or traditional data center.

    “Containers are rapidly disrupting software development and IT operations,” said Dr. James Zhang, partner at GRC SinoGreen. “Rancher Labs has shown through its amazing open-source adoption, that organizations see container management as critical to accelerating software development, and running applications reliably and efficiently in production.”

    DevOps teams use Rancher to automate all aspects of running containers throughout the application lifecycle. From developers writing code on their laptops, to building and packaging software, deploying test environments, and deploying and upgrading applications in production, Rancher allows DevOps teams to improve development velocity and reliability.

    “We are thrilled to continue our support of Sheng and the team at Rancher as they enable enterprises to truly unlock the potential of software containerization and transform IT infrastructure,” said Jishnu Bhattacharjee, managing director at Nexus Venture Partners.

    “The success Rancher Labs has experienced since launch is incredible, and we look forward to our continued partnership,” said Ursheet Parikh, Mayfield partner and former CEO of StorSimple, which was acquired by Microsoft. “Their dedication and level of innovation is second to none.”

    Product Information and Availability

    For additional information on Rancher and to learn more about Rancher Labs and the company’s suite of open source products, please visit http://www.rancher.com.

    Supporting Resources

    About Rancher Labs

    Rancher Labs builds innovative, open-source container management software for enterprises leveraging containers to accelerate software development and improve IT operations. With native support for Docker Swarm and Kubernetes orchestration, our flagship Rancher platform allows users to manage all aspects of running containers in development and production environments. For additional information, please visit www.rancher.com.

    #

    Contact

    Mindshare PR
    Eleni Laughlin, 510-406-0798

    eleni@mindsharepr.com

     

  • Container Usage and Adoption, Here is Your Chance to Tell Us What You Think

    Container Usage and Adoption, Here is Your Chance to Tell Us What You Think

    We are teaming up once again with ClusterHQ for an update on Container usage and adoption. Our new survey is available and shouldn’t take more than 5-7 minutes of your time. We are looking to see if the container adoption and usage has changed since our last survey last summer. Please take a moment to fill out the survey. If you fill out contact info at the end, you are eligible to win a $50 dollar Amazon gift card. One in 50 wins a card. If you don’t want to give any contact information, you don’t have to but we can’t contact you if you were to win a gift card. Either way we would love your input!

    While containers are capturing lots of buzz and attention, many still doubt their impact in real world procurements. However, we are hearing enough subjective feedback to think that this is not the case. We think containers are catching on quickly, perhaps even quicker than cloud adoption did at similar time frames. But that is subjective. We are looking for numbers that prove or disprove it. So even if you are not using containers now, we want to know that too.

    The standard line is that containers are being tested in dev and test environments, but are not ready for prime time. Yet Docker, CoreOS, Kubernetes and the entire container ecosystem point to more and more customer references. Can everyone be just playing with containers in their labs? We don’t think so.

    On the other hand, there are questions about security, scalability, networking. Should you lock in to one vendors complete stack? How open should the ecosystem be? What about data, databases, OS, etc. Lots of questions and we really don’t have a lot of objective data points. Help us change this by giving us your own thoughts, experiences and ideas.

    We will share the full report with analysis with our readers when complete. But don’t miss this chance to be heard and make a difference.