Category: Containers

  • DevOps Predictions for the Future

    DevOps Predictions for the Future

     Among the few powerful trends we had experienced in the recent times, one is undoubtedly the adoption of DevOps practices. As we are move closer to 2018, it is becoming more obvious that DevOps is becoming mainstream, with many large organizations getting on board with DevOps.

    DevOps Within Enterprises

    DevOps is becoming the standard way of working for businesses. Adoption of DevOps within the organization is rising on a broader scale, and businesses are trending toward it.

    Enterprises of today are well-aware of the trending technology services in modernizing environments. DevOps is growing its recognition due to changes in complexities of today’s software that lies more in the diverse set of operation systems and platforms. It is less about doing things a particular way and more about moving the business forward and turning technology into a strategic advantage.

    DevOps builds upon best practices to help drive enterprise performance in the modern digital economy. It offers organizations a new way to deliver value to their customers quickly. An increasing number of businesses are recognizing the power that DevOps can bring for operational efficiency and overall performance.

    DevOps Key Trends

    As businesses are trending toward DevOps adoption, let’s look at the changing landscape and key trends in DevOps, along with its trajectory.

    Some of the DevOps trends include:

    • Many organizations will challenge agile and recognize DevOps as the new ALM methodology.
    • Many DevOps automation tools are going to roll up.
    • Automation and testing would gain their prominence.
    • DevOps Engineers are highest paid IT practitioners today.
    • Testing and deployment are done more frequently as Ops people are getting their DevOps knowledge in production for testing and automation operations.

    DevOps Predictions

    Based on the market so far, here are my predictions for the future of DevOps.

    Adoption of Microservices and Containers

    Several software enterprises are pushing toward microservices infrastructure. Microservices architect an enterprise solution, independently, over a set of services.

    Microservices are best-suited for DevOps due to its features including:

    • Isolated nature
    • Improvised cycle times
    • Well-defined interfaces
    • Aligned architecture

    Containerization also is growing in popularity. Containers are designed to run one process at a time with minimal deployment, serving as an ideal deployment model. According to one study, 50 percent of enterprises are expected to run containers in production by the end of 2018.

    If an enterprise has decided to leverage microservices and containers, it is highly essential to incorporate solutions that support microservices and containers along with traditional application model.

    Culture, the Top Prerequisite

    Culture is the key differentiator for DevOps. Culture and process are the principal paths for the successful DevOps journey. Culture breaks down the organizational silos and encourages integration across all the groups that need to work together to achieve a great business outcome. Implementing DevOps culture makes an organization achieve success easier. It even enables continuous learning environment that will see bigger benefits.

    Notion of Shifting Left

    DevOps tools and solutions always prefer to shift left. DevOps orchestration tools automate from end to end, making traceability easier. Activities that are performed traditionally, at the later stages of development and release process, are making a shift to the left of the pipeline. The ultimate goal of it is to recognize issues earlier, along with performance and disaster recovery testing.

    Downtime   

    Adopting DevOps holds a lot of benefits. For one, it enables enterprises to ensure uptime and enhance cadence and quality. High-performing IT organizations employing DevOps practices deploy 200 times more frequently than the low-performing enterprises. Similarly, they also enjoy faster recovery from failure and minimize downtime.

    Collaboration of Big Data and DevOps

    Big Data and DevOps are together taking a step forward toward the design of predictive analytics. DevOps has now become an expert in automating the process and automating configuration.

    Consolidation is Critical

    Large and complex organizations are focusing on consolidation and standardization of DevOps processes so as to scale DevOps within the enterprise. A shared and self-service DevOps automation enables end-to-end pipelines. Eventually, consolidation allows reusability, visibility, auditability and security.

    Supporting Hybrid

    “Hybrid-everything” makes DevOps solutions future-ready to support any tool, application and process in the hyper-hybrid state. “Hybrid” state of existence is achieved for infrastructure, architecture, release pipelines and more. 

    DevOps Monitoring                       

    Until now, the focus has been on pre-production provisioning. However, more attention is being given to the post-deploy feedback loop. With the application of new architectures including microservices, new monitoring technologies and pricing models are effectively introduced.

    Expansion of DevOps Across IT

    DevOps is maturing in other areas such as database management, security and testing, all with the goal of application release.

    Business-centric Agile

    The development methodology approach is becoming more critical to the continuous integration and continuous delivery process.

    DevOps Skills 

    People with DevOps skills are in demand in the industry and expected to proliferate as businesses are witnessing great results from DevOps. Organizations incorporating DevOps training practices are extremely high-functioning. If you aim to build your career in DevOps, below are certain notable skills.

    Most common DevOps positions include:

    • Site reliability engineer
    • DevOps engineer

    The core skills of DevOps are:

    • Coding skills
    • Knowledge of automation tools
    • Communication skills

    Roles of a DevOps Engineer

    Many DevOps developers find interest in deployment and network operations. A core set of DevOps skills includes:

    • Ability to code and script using various technologies and tools.
    • Close relation with Systems and IT operations.
    • Strong base of automation tools and its skills.
    • Incremental code testing and deployment.
    • Strong focus on data management skills and business outcomes.

    Final Words…

    DevOps skills will only continue to grow and DevOps is here to stay. Dev and Ops teams are increasingly moving to rapid development and reliable, high-performance services delivery.

    DevOps is being adopted by more and more companies, particularly smaller enterprises. Many industries today are keen on incorporating DevOps and its key points into their respective departments. It will continue to evolve for the foreseeable future, by incorporating executives and other business units into it. Companies that utilize DevOps effectively will experience higher innovation and quality and easier adoption to other changing conditions.

    Adoption of DevOps enables applications and technology solutions. It power businesses with faster and better quality. Investing in DevOps helps organizations better develop and release software.

    About the Author / Sirisha Paladhi

    Sirisha Paladhi is a content writer at TekSlate. During her career, she has written many articles on technology innovations.

     

    LinkedIn URL: https://www.linkedin.com/in/paladhi-sirisha-74987881/

     

  • 5 C’s That Changed the Future – Webinar Series  CI, CD, Containers, Cloud & Culture

    5 C’s That Changed the Future – Webinar Series
    CI, CD, Containers, Cloud & Culture

    Join us for case studies of innovation and success with continuous integration (CI), continuous delivery (CD), containers, cloud (infrastructure & migration), and culture (the DevOps kind).

    If you’re on the same mission – to create sustainable systems that empower your business to deliver innovation faster and predictably – then you’ll gain incredible insights from this series. We’ll share the journeys of some very cool companies, joined by a few of the experts who are making it happen.

    Why 5 C’s?

    The consistent theme in these successes is DevOps – culture, process and technology. And when we looked at the results that had the most notable impact on the business, they related to implementations of some or all of the 5 C’s. Results such as:

    • 10x faster new product delivery.
    • Internal & client confidence in iterative development, driven by innovation in quality & feedback.
    • Modernized traditional apps by adding self-healing, auto-scaling, and rolling deployment capabilities.
    • Blameless culture, enabled by feedback and consistency across dev, test & prod environments.
    • Security integrated across the stack and not simply a checkbox.

    The series:

    • Tuesday, Oct. 3 – CI/CD, Containers & Culture
    • Tuesday, Dec. 5 – Cloud Infrastructure & Culture
    • Tuesday, May. 15 – Cloud Migration & Containers

    View On-Demand Webinar (Oct. 3):
    Faster Innovation with Confidence – How CI/CD & Containers Help Arrayent Go Faster

    View On-Demand Webinar (Dec. 5):
    Scaling Cloud Infrastructure for Millions of Devices

    View On-Demand Webinar (May 15)
    Cloud Migration: Solving for Growth with Containers & DevOps on AWS

  • Characterizing and Contrasting Container Orchestrators

    Characterizing and Contrasting Container Orchestrators

    Admiral Calcote, also known as Lee Calcote (@lcalcote) or the Ginger Geek to his friends, gave a presentation titled, “Characterizing and Contrasting Container Orchestrators,” at the 2016 All Day DevOps conference.

    Okay, he isn’t really an admiral—nor does anyone call him that—but he used the title “admiral” to describe what container orchestrators do, relating it to an admiral directing a fleet of container ships. You could also say that they are like the conductor of an orchestra, directing the individuals to work together as a group toward a common goal while each musician is still able to play their own instrument.

    lee1.png

    Lee is the head of Technology Strategy at SolarWinds, and for his talk, he discussed four open-source container orchestrators: Nomad, Swarm, Kubernetes and Mesos-Marathon.

    He emphasized the obvious: There is no one perfect solution. Each organization is different, so for each solution, he looked at:

    • Genesis and purpose
    • Support and momentum
    • Host and service discovery
    • Scheduling
    • Modularity and extensibility
    • Updates and maintenance
    • Health monitoring
    • Networking and load balancing
    • Secrets management
    • High availability and scale

    Lee noted that while there are many core capabilities, any orchestrator must have cluster management and scheduling.

    lee2.png

    He then dove deeper into the four solutions. Below are summaries (the full talk is chock full of information and is online here):

    Nomad

    • Designed for both long-lived and short-lived batch processing workloads
    • Cluster manager with declarative job specifications
    • Ensures constraints are satisfied and resource utilization is optimized by efficient task packing
    • Supports all major OSs and workloads
    • Written in Go and with a Unix philosophy
    • Host discovery: Gossip protocol – Serf is used; servers advertise full set of Nomad servers to clients; creating federated clusters is simple
    • Service discovery: Integrates with Consul
    • Scheduling: two distinct phases – feasibility checking and ranking; optimistically concurrent; three scheduler types when creating jobs
    • Uses task drivers to execute a task and provide resource isolation, but it does not support pluggable task drivers
    • Built for managing multiple clusters/cluster federation

    lee3.png

    Docker Swarm 1.12

    • Simple and easy to set up
    • Architecture is not as complex as Kubernetes and Mesos
    • Written in Go – lightweight, modular and extensible
    • Strong community support
    • Host discovery: used in the formation of clusters by the Manager to discover Nodes (hosts); pull model – worker checks in with the Manager
    • Service discovery: Embedded DNS and round-robin load balancing
    • Scheduler is pluggable and is a combination of strategies and filters/constraints
    • Ability to remove “batteries”
    • Rolling updates are supported
    • Managers may be deployed in a highly available configuration, but does not support multiple failure isolation regions or federation

    lee4.png

    Kubernetes

    • An opinionated framework for building distributed systems
    • Written in Go and is lightweight, modular and extensible
    • Led by Google, Red Hat and others
    • Young – about 2 years old
    • Robust documentation and community
    • Scheduling is handled by kube-scheduler
    • Pluggable architecture and an extensible platform
    • Choice of database for service discovery or network driver and container runtime
    • Supports rolling back deployments, automating deployments and rolling updating applications
    • Inherent load balancing
    • Uses Pods, an atomic unit of scheduling. Each pod has its own IP address, no NAT required and intra-pod communication via localhost

    lee5.png

    Mesos-Marathon

    • Mesos is a distributed systems kernel
    • Mesos has been around the longest (since 2009)
    • Mesos is written in C++
    • Marathon is a framework that runs on top of Mesos
    • Mesos is used by Twitter, AirBnB, eBay, Apple, Cisco, and Yodle
    • Marathon is used by Verizon and Samsung
    • Mesos-DNS generates an SRV record for each Mesos task
    • Marathon ensures that all dynamically assigned ports are unique

    lee6.png

    Wrapping up, Lee provided the following overview comparing the different container orchestration solutions.

    lee7.png

    Lee packed a tremendous amount of information into his talk. If you use containers, his talk is worth your time and is available online here. If you missed any of the other 30-minute long presentations from All Day DevOps, they are easy to find and available free of charge here. Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here. This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed).  It’s all free and online Oct. 24.

    — Derek E. Weeks

  • Speaking for the Dead: Are ‘Agile’ and ‘Monolithic’ Actually Good?

    Speaking for the Dead: Are ‘Agile’ and ‘Monolithic’ Actually Good?

    What if Agile is the product of getting bored at work, microservices are the result of us needing a challenge and scrums are the result of an obsessive project manager? Do we all think waterfall development is a dinosaur whose extinction is deserved because of what we have been told and not because of reality? Do we think Agile is better because it simply sounds desirable?

    Michael DeHann (@laserllama), creator of Ansible, spoke at the 2016 All Day DevOps conference, which espouses the benefits of DevOps, and, by association, Agile and microservices. It essentially says, “Let’s step back and evaluate the past. Maybe waterfall development and monolithic architectures are actually a good thing?”

    Michael has been a software engineer and created a key tool in the IT automation toolbox: Ansible. His arguments deserve a look, because re-evaluation can keep you from making mistakes and improve processes going forward.

    Michael started his talk by making the point that in this day and age, it is waterfall versus Agile and monolithic architecture versus microservices. The assumption is that if you are still developing software with the waterfall method and/or developing monolithic applications, you might as well be riding a horse and buggy to work and dialing up coworkers on your rotary phone.

    Throughout his talk, he asked questions to make his points, beginning with, “Is big design up front bad?” with the conclusion, “I don’t think so.” His argument is that design and requirements at the beginning of the process enable a better production. Marketing and engineers hammered out requirements based on needs, abilities and budgets. There was plenty of time to research and design solutions. Both sides worked together, raising questions and comments and documenting mutual agreement. This presented an accurate view of the strengths of various team members and dependencies between tasks and task orders. And, perhaps most important, engineering was engineering—the engineers had greater responsibility and less hand-holding.

    Contrasting that with his view of Agile, big design up front is labeled as bad or counterproductive, engineers are viewed as interchangeable and scope is more unpredictable. Estimates are encouraged to not be time-based, which often results in a constant crunch time. Finally, meetings can consume a significant portion of team members’ time and often include “games reminiscent of Kindergarten, such as Fist of Five or Planning Poker.” Even in lightweight Agile systems, testing can suffer, requirements are more vague and there is no mutual sign-off.

    Michael argues that there can, in fact, be a middle ground where teams:

    • Do share design
    • Have an accessible, effective product owner
    • Know hard requirements versus soft requirements
    • See test-driven development and test automation as super important
    • Understand that Agile and iterative development can be closer than we think

    Agile and DevOps are also often associated with microservices versus monolithic applications, but according to Michael, “What’s so bad about a monolith?”

    Sample Monolithic Diagram

    dehann1.png

    Sample Microservices Diagram

    dehann2.png

    An example microservices shop has 150 services, many thousands of Jenkins builds per day, eight Amazon regions including dev, staging and production and thousands of EC2 instances. This can result in Jenkins configuration and security enforcement drifts, suboptimal code sharing and DevOps writing lots of custom code to manage it.

    Michael contrasts that with monoliths, which have:

    • Increased ability to develop on one laptop
    • Interfaces that benefit from static typing versus design-by-contract
    • Very small numbers of different server/image types in production
    • Local function calls that are much faster than RPC
    • Few instances sitting around with 5 percent utilization
    • No need for “containers” to get around above utilization problem
    • Greatly simplified debugging
    • Easy code-sharing
    • Very simple version upgrades

    Rather than argue that all applications should be monolithic, he makes the point that many of the concerns that resulted in microservices could be solved with improved communications. He contends that microservices are a tech solution to a people problem.

    Michael concludes that:

    • Labels cloud true meanings,
    • Monolithic architectures are more efficient,
    • Agile can be less efficient,
    • Microservices attempt to solve people problems but introduce new technical and people problems, and
    • We should try and separate the labels from the true meaning of things.

    Most importantly, though, is the fact that there is something to learn from everything. So, even if you don’t agree with Michael’s conclusion, you should listen to his talk online here. You might learn an unexpected lesson.

    If you missed any of the other 30-minute long presentations from 2016 All Day DevOps, they are easy to find and available free of charge here.  Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here.  This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed).  It’s all free and online Oct. 24.

    — Derek E. Weeks

  • VMware Ties Desktop Virtualization to DevOps Productivity

    VMware Ties Desktop Virtualization to DevOps Productivity

    It’s no secret that when it comes to building applications, many developers prefer to use the Apple Macintosh. However, that preference can create multiple DevOps challenges. VMware is moving to reduce the friction with the release of VMware Fusion Pro 10, a desktop virtualization offering for Apple Macs that now supports REST application programming interfaces (APIs) to more easily programmatically invoke virtual machines on Macs.

    In addition, VMware has significantly improved support for graphical processors units (GPUs) and 3D graphics within VMware Fusion Pro 10 that are now more commonly being invoked by developers.

    At the same time, VMware is also updating VMware Workstation 14 and Workstation Player, which adds support for Windows 10 and Windows Server 2016 along with updated Linux support for Fedora 26 and Ubuntu 17.04 guest operating systems to the desktop virtualization software. Workstation Player is a subset of VMware Workstation 14 that IT organizations can employ to limit the size of a virtual machine running on a local workstation.

    Other new capabilities include support for Microsoft’s Virtualization Based Security (VBS) features of Windows 10 Enterprise and Windows Server 2016 guests, enhanced virtual networking and new support and controls for working with vSphere and the vCenter Server Appliance software.

    Michael Roy, product line marketing manager for VMware Fusion, says more organizations are making GPUs available to developers as part of an effort to build more robust applications. Support for GPUs make it easier for developers to build compute-intensive applications for multiple operating system environments within the context of a DevOps environment managed by an IT organization, he notes.

    Other new capabilities include a revamped user interface and support for the Apple Touch Bar to simplify moving between native applications and virtual machine environments, including applications hosted on the VMware PhotonOS distribution of Linux optimized for hosting container applications.

    In this release of Fusion Pro, VMware is also adding support for Microsoft’s VBS features—which include Credential Guard for Windows 10 virtual machines, unified extensible firmware interface (UEFI) Secure Boot and a virtual Trusted Platform Module—in the same way it supports them on VMware Workstation 14.

    Finally, VMware is providing access to enhanced networking controls to enable management of network address translation (NAT) rules, network packet loss and latency simulation and renaming of VM networks.

    The updates were announced ahead of VMware’s VMWorld annual conference, being held Aug. 27-31 in Las Vegas.

    Developers typically require more access to more IT environments than almost any other employee, so maximizing the number of operating systems that can be deployed on their systems is in the best financial interests of the organization. Even when an organization can afford multiple machines most developers don’t want to have to move files between physical machines. Desktop virtualization software provides a means to not only increase productivity but also reduce the amount of machine overhead associated with developing applications across multiple operating environments.

    — Mike Vizard

  • SecOps: The Next Stride for DevOps

    SecOps: The Next Stride for DevOps

    Global IT spending is now touching a figure of $4 trillion. In today’s technology-intensive environment, data is the biggest commodity, more valuable and powerful than ever. And like Peter Parker’s uncle Ben noted, “With great power comes great responsibility.”

    Security has always been a big concern for valuable things and IT is no exception. IT as a whole is trying to push security left in the development cycle—trying to involve it in every step of the development cycle. And just when development and operations teams are getting used to the “esprit de corps” we call DevOps, I think it’s time we add the third musketeer: security.

    What is SecOps?

    SecOps is a collaboration between security and operations teams, just like development and operations teams collaborate on DevOps front. SecOps is a set of practices organizations need to follow, processes they need to execute and tools they need to use to ensure the security of their application environment. SecOps is making sure organizations do not sacrifice security to attain set performance and uptime indexes.

    In a typical development cycle—requirements gathering, design, development, testing, implementation or deployment and maintenance—security normally is introduced in the later stages, somewhere between testing and deployment or even later. But SecOps is all about making sure to introduce aspects around security much earlier or at each stage of the software development life cycle (SDLC).

    I know what you are thinking: This is going to complicate things and increase the time to delivery. This is where operations and development teams need to join forces to uncomplicate the things and make it time efficient practice. Next thing you must be thinking of is, Why so much hassle? Think of it the other way. Wouldn’t it save more time when you address the security concerns at much earlier stages than at the time of delivery or implementation? All it takes is an amalgamation of the security group, development team and operations team; a little bit of planning; and a whole lot of execution.

    SecOps + Containers

    Containerization is slowly but steadily moving from an alternative to full virtualization to a serious platform for running your applications. Containers have some obvious advantages including scalability and flexibility, and this solves most of the problems related to resources in case of application development. Reduced size; reduced time to provision application environment and testing; platforms including Docker, Solaris Zones, BSD Jails; and orchestration platforms including Kubernetes, CoreOS Fleet, Amazon ECS and OpenShift make containers a more preferred option for application development environments.

    This increased traction toward containerization points to the increased need to concentrate on security aspects. Here are some best SecOps practices for container environment you and your organizational teams can follow:

    • Authentic sources and images: Always check for authenticity of container images. There are various tools such as Docker’s security scan. With Docker Cloud and Docker Hub you can scan images to check for potential security vulnerabilities. Most images are built from some base image and not built from scratch, so there is always a threat with the used images.
    • Vulnerability management tool: There are tools available in the market to analyze container image formats and libraries for threats before you actually start using them.
    • Follow benchmarks and hardening guidelines: Always make sure you do the checks and follow hardening guidelines for containers, images, hosts and platforms before you start with production. There are few standards and benchmark checks for containers such as CIS’s Docker security benchmark, PCI compliance checklist, etc.
    • Periodic auditing: Regular auditing of your application environment can help you save yourself from the future troubles. Moreover, automation of auditing process can help in detection of unused images and containers.
    • Use of management frameworks: Use frameworks that can automate behavior profiling and control all the users, authorize the access to the containers, images and hosts.
    • Security built in to container engine systems and third-party security solutions: Third-party vendors have a number of applications for container security in addition to security systems of container management platforms.

    Dev + Sec + Ops

    With the continuously increasing business demands for new applications and software, and new practices and development trends such as DevOps, Agile, cloud, automation, CI/CD and others, traditional security needs to upgraded in the new paradigm. Thankfully, some of these practices facilitate the security. Consider CI/CD as an example: Continuous integration requires continuous integration tools, or what we call build servers. Some popular examples are Jenkins, TeamCity, GitLab CI, Travis CI, Bamboo, Go CD, CircleCI and Codeship. The best SecOps practice is to check and fix vulnerabilities at early stages as a part of CI/CD workflow. Integration between authentication, scanning, management tools and CI/CD pipeline tools could be the best possible solution to your security-related problems. Some easy-to-implement solutions can include automated security testing, static code analysis, authentication checks and login tracking.

    SecOps enable organizations in lifecycle management, analysis of security threats, incident management, optimizing and measuring the effectiveness of security controls, reduced breach response time, reduced security risks and increased business security. The basic principle on which SecOps works is Avoid, Analyze, Respond, Review, Repeat. By analyzing the security events and data, you can build incident response plans to avoid future unwanted events.

    Frameworks and Tools

    Now that you have a clear understanding of why you need your security, development and operations teams to work together, let’s see what tools and frameworks you can use.

    • Docker-native tools: If you are using Docker as a platform then you can use few security tools provided by Docker itself for the security of production environment: Docker Bench and Docker Notary. Docker Bench is a script that checks common best practices around deploying Docker containers in production. Docker Notary enables you to check whether content is from a trusted publisher.
    • Chef: Chef provides different tools including Inspec to automate security testing.
    • Puppet: Puppet provides security compliance and policy defining frameworks.
    • Ansible: Ansible provides system tracking, setting up firewall rules, user lockdown and compliance automation solutions.
    • CoreOS Clair: CoreOS Clair is an open-source project for vulnerability analysis in applications and Docker containers.
    • SaltStack: SaltStack can help in orchestration and automation of security practices solutions for containers.

    This is just a look at some of the most popular ones. If you want, there are a number of others that can look after the security of your application environment.

    The main motive behind implying SecOps practices in any organization is involving security team at all possible stages to remove any ambiguity in any stage of development rather than security team providing analysis reports to the operations team and then sitting back and enjoying the show. When these teams perform in a synergistic manner, the business focus can be shifted to other important things.

    About the Author / Chaitanya Jawale

    Chaitanya Jawale is founder and CEO of Opcito Technologies, a leader in microservice-based product engineering and automation. Chaitanya comes with strong background in product engineering, data center automation, DevOps and multi-cloud orchestration and management.

  • Sonatype Report Spotlights Software Supply Chain Issues

    Sonatype Report Spotlights Software Supply Chain Issues

    Most application developers today don’t write much raw code. Rather, applications developed today are created mostly by combing various modules and widgets to create a custom application. But currently there is little oversight being applied to the provenance of application components, especially when it comes to open-source software.

    The third annual State of the Software Supply Chain Report published by Sonatype, a provider of tools for managing software supply chains, finds that the amount of time it takes for open-source projects to address vulnerabilities is considerable. The report states that only 15.8 percent of open-source software projects actively fix vulnerabilities, resulting in an average mean time to remediation of 233 days. In effect, that gives cybercriminals the better part of a year to exploit a known vulnerability. Of course, that’s usually longer simply because most IT organizations are not especially efficient when it comes to regularly updating all the components that make up an application once it’s been deployed in production.

    Based on an analysis of more than 17,000 applications, the Sonatype report estimates downloads of Java components grew 68 percent (52 billion) year over year in 2016, while JavaScript downloads (59 billion) grew 262 percent.

    Matt Howard, chief marketing officer for Sonatype, says managing all the components that make up an application will only become more challenging as developers increasingly start to leverage Docker containers. The Sonatype report estimates there will be 12 billion downloads of Docker containers in 2017, a 100 percent increase over 2016.

    The good news is that more awareness of DevSecOps issues appears to be having an impact. The report finds the percent of Java components downloaded from the Sonatype Central Repository that contained known security vulnerabilities fell to 5.5 percent (1 in 18), down from 6.1 percent the year prior. Of course, that improvement needs to weigh against the 68 percent increase in downloads, which would suggest that the total number of components with known vulnerabilities finding their way into production applications has never been higher.

    By way of contrast, the report claims that applications built by teams employing automated governance tools reduced the percentage of defective components in their application by 63 percent. The report also says organizations that are actively managing the quality of open-source components flowing into production applications are realizing a 28 percent improvement in developer productivity, a 30 percent reduction in overall development costs and a 48 percent increase in application quality.

    The report makes clear that DevOps processes are not being extended far enough to the proverbial left. Instead of focusing on only on the application release cycle organizations need to apply structured processes to the components that are being aggregated together during the application development process. In fact, Howard notes that application development is moving away from being an art to more of a manufacturing process. As that shift continues to occur, it’s only a matter of time before a much greater emphasis gets placed on quality control all the way down that manufacturing line to not only limit liability but also generally improve the overall application experience.

    — Mike Vizard

  • Q&A: Michael Beckley, CTO/CCO, Appian

    Q&A: Michael Beckley, CTO/CCO, Appian

    Recently I had the chance to speak with Michael Beckley, chief technical officer and chief customer officer at Appian, about his company’s move to go public and the DevOps space in general. For those of you who don’t know Michael, he is a founder of Appian and leads the company’s technology vision and oversees customer initiatives worldwide. He also serves on the Industrial Advisory Board for the University of Virginia’s Computer Science Department and is a member of the University of Maryland Advisory Board in Computing. He has an interesting take on the IT space and DevOps in particular. Read on for our discussion.

    Alan Shimel: Michael, what do you think has been the “special sauce” that has led to Appian’s success to date?

    Michael Beckley: With Appian, companies build unique business applications up to 20x faster and mobile-enable and modernize existing systems. For example, a company like Ryder was able to build a web and native Android tablet application that cut the time it took to rent a truck in half.

    But the “special sauce”? That’s Appian’s culture of innovation. Our engineers think long-term and invest in breakthrough tech like our patented SAIL UI technology for zero code native mobile apps. Thanks to SAIL, the web apps you configure in Appian automatically deploy to iOS and Android as native, full-featured apps or specialized micro apps we call “Sites.” As long as we get the culture right, we expect to continue to deliver enduring value for our clients.

    Shimel: With becoming a publicly traded entity, some companies have found “managing to the street” does not match their own long-term business plans and their customers needs, how does Appian avoid this?

    Beckley: Companies, like people, are an aggregation of their habits. Appian’s habit has always been to hold to our long-term vision of enabling every company to be a software company. We are not your typical Silicon Valley tech company. Our roots are in DC, we largely bootstrapped this business, and learned to be good stewards of capital while helping to support the core missions of federal agencies and some of the world’s largest brands. The proceeds following this IPO will be invested back into our business to benefit our customers.

    Shimel: What do you see post-IPO being the biggest areas for growth as it relates to new products and services?

    Beckley: We  plan to invest in innovating and enhancing our platform. While our platform is industry-agnostic, we have recently made, and plan to continue to make, investments to enhance the expertise of our sales and marketing organization within our key industry verticals of financial services, health care and government. We have made, and will continue to make, investments in research and development to strengthen our platform and expand the number of features available to our customers. As we continue to increase the functionality of our platform and further reduce the amount of developer skill that is required to build robust applications on our platform, we believe that we have the potential to expand the use of our platform.

    Shimel: Digital transformation is a term that is being used a lot these days. How far along the adoption curve are we on digital transformation?

    Beckley: While many speculate that digital transformation is just a tech industry buzz word, in reality, digital transformation is a living, breathing effort. According to a recent survey, digital transformation is a C-level priority and is considered a top focus for almost 50 percent of all companies this year.  From Appian’s perspective, we believe that the utilization of low-code software to drive digital transformation is still relatively new and our customers will be able to succeed in their digital transformation efforts by incorporating low-code development.

    Shimel: Where does the DevOps market intersect with the Appian business model?

    Beckley: Organizations are turning to DevOps to accelerate development and bring an application’s capabilities to a user quicker. The Appian low-code development platform fits into the DevOps model and supports the seven major DevOps categories including code, build, test, package, release, configure and monitor.

    Overall, our business model supports the DevOps market; we’re living in a world where citizen developers are playing such an important role in the enterprise and our platform empowers the citizen developer while alleviating developer resources to focus on the more challenging, business-critical developer work.

     Shimel: What about containerization and microservices? How do these technologies affect Appian?

    Beckley: Appian already uses containers and microservices. Appian’s enterprise customers often require a mix of cloud, hybrid cloud, and on-premise installations. We view containers and microservices as enabling technologies to support the diverse workloads and deployment models required by our enterprise clients.

    Shimel: What about security? What challenges does cybersec pose to Appian’s development of their platform?

    Beckley: Appian works with some of the nation’s most important and highly regulated industries, therefore we have built a comprehensive security and compliance structure that meets several industry standards. We frequently undergo third-party audits to ensure that we are always operating effectively to protect our customer data.

    — Alan Shimel

  • Container Considerations on Your DevOps Journey

    Container Considerations on Your DevOps Journey

    Containers are things for your things. That is true in the development world, too—containers are things for your software, and, like containers for your things, software containers can help you be organized, efficient and secure.

    Chris Morgan (@cmorgan_cloud), the Technical Director, OpenShift Partner Ecosystem at Red Hat, delivered a keynote at the 2016 All Day DevOps conference. Chris lives and breathes containers and recently discussed how they are transforming DevOps pipelines.

    Chris started with an encouraging figure: DevOps has a 74 percent adoption rate (at least on a path toward full adoption) at the enterprise level. The reason is that DevOps helps solve issues around:

    • Slow service delivery
    • Poor service quality
    • Frequent down times

    However, the needs of development and the desires of IT can often hamper full DevOps adoption, which is where containers can help. Containers allow apps to be easily shared and deployed with:

    • Consistent environment and tools
    • Predictable building tools
    • Faster deployment

    In short, containers can act as a common language between development and IT operations. And when configured properly, the operations team can utilize containers to assemble environments without compromising security.

    The survey that revealed a 74 percent adoption rate for DevOps in the enterprise also shows an 18 percent adoption rate of containers in the enterprise. Why the difference? Containers sometimes can be difficult to implement across multiple hosts.

    If you are gearing up to consider the use of containers across your IT environment, Chris offered up some things to consider:

    • Where do you store the container image?
    • Which container on which host? Which has enough capacity?
    • How do you monitor the health of the containers?
    • What do you do if a container crashes?
    • How can I address scale?

    When you have large apps that span multiple containers?

    • Which containers can access others?
    • Which containers should be deployed together?
    • How do I limit certain containers?
    • How do they find each other?
    • Is there malicious software on any containers?
    • How do I handle persistent storage?

    The bottom line is that you need more than just containers. You need a host, a platform, management and persistent storage.

    Is your organization ready to at least consider containers for DevOps? Chris reminded us, “Technology should not dictate the process. Identify the ideal process first, and then ensure the technology is flexible enough.” Start by finding some low-hanging fruit, assess skills and capabilities on your team and engage in a discovery session.

    Chris’ full keynote went into more detail, notably some solutions to implementing containers at the enterprise. You can watch Chris’ full All Day DevOps conference session (just 40 minutes) or you can view the other 56 presentations from the 2016 conference online and free of charge here.  This blog series is reviewing sessions from the 2016 All Day DevOps, which hosted over 13,500 registered attendees. Next week, look for “Ops Happens: DevOps Beyond Deployment” with Damon Edwards.

    Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here. This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed).  It’s all free, online Oct. 24.

    — Derek E. Weeks

  • 5 Common Misconceptions of Serverless Technology

    5 Common Misconceptions of Serverless Technology

    The rapid growth in serverless technology affords companies opportunities to save money on server costs and allows developers to save time and focus on coding rather than back-end operations. A challenge with such swift adoption is the difficulty in maintaining a standard understanding. In anticipation of the Serverless Conference, which was held last week in Austin, Texas, we asked experts in Heavybit’s community about common misconceptions.

    Myth #1: Serverless is a Revolutionary New Direction for Software

    “A common misconception is that it’s a revolutionary new direction for software,” says Nick Martin, co-founder and CTO at Meteor. “Really, it’s just the next step in the evolution of making software development faster and easier. Like the compiler, the database and cloud computing did in previous eras, serverless further abstracts away the complexities of modern app development and is part of an ongoing trend to free developers from entire classes of concerns.”

    As for the benefits for developers, Martin notes that developers can now “focus on their application logic and avoid undifferentiated work like provisioning, server management, or load-balancing.” Serverless ultimately “promises to let developers ship apps faster and at a lower cost,” he says.

    Myth #2: Serverless is a Gadget Technology for Hobbyists

    Nick Gottlieb, head of Growth at Serverless Inc. believes that one of the biggest myths is that it’s a ‘gadget’ technology that’s not mature or only for a hobbyist. “While serverless compute is still a very early technology, it’s built on the same core infrastructure that providers like AWS, Google, and Microsoft have been investing in and selling to enterprises for years,” says Gottlieb. Furthermore, “because the underlying infrastructure is battle tested, and the value it provides around cost savings and faster time to market are so great, there is already huge amounts of mission-critical enterprise workloads being done on serverless compute.”

    Myth #3: Serverless Will Hurt the Movement Toward Containers

    “Containers will continue to be front and center in terms of the underlying infrastructure, but that doesn’t mean they will be the primary unit of deployment for developers,” says Lawrence Hecht, author at The New Stack. “Take, for example, a cloud provider that may build its FaaS (function as a service) on top of containers and use Kubernetes to manage that deployment,” he says. “Individual developers would then deploy application components to functions instead of to container images.”

    Hecht notes that this will not happen right away and in the meantime, “We’re seeing emerging companies build dashboards that allow developers to choose which VM, container or function they want to deploy to. Those dashboards are becoming the gateway to the CI/CD pipeline.”

    Myth #4: Serverless is Free of Security Vulnerabilities

    “The biggest security misconception is thinking you no longer need to worry about known vulnerabilities,” says Guy Podjarny, co-founder and CEO at Snyk. While serverless addresses the risk of known vulnerabilities in OS dependencies, such as OpenSSL’s Heartbleed vulnerabilities, “These ‘unpatched servers’ account for the vast majority of successful attacks today. Serverless applications still contain a large and growing number of application dependencies, pulled from npm, Maven, PyPI and more. These components often carry known vulnerabilities, and require diligent monitoring and preventative tools.”

    Myth #5: Serverless Means No More DevOps

    “A common misperception is that it completely absolves development teams from the harsh realities of operating software,” says Joe Ruscio, partner at Heavybit. “While it does promise to almost completely do away with the ‘undifferentiated heavy lifting’ of provisioning and managing infrastructure, understanding how your application code performs in production remains of paramount importance.”

    — Malia Powers