devopsy.kinsta.cloud

Tag: developers

  • The Executive’s Guide to Microservices Chapter 2: The Business Challenge

    The Executive’s Guide to Microservices Chapter 2: The Business Challenge

    Steve and team have been working diligently to analyze the intricate web of code that has been organically developed over the past 12 years to design a program to modernize the application. Application is actually a poor name for all that Steve and his team manages. Steve’s team manages a complex custom supply-chain system that manages inventory, warehouse, picking, packing, shipping and order management. A hiccup in any module could lead to a serious financial impact to the business.

    The business has discussed multiple times over the years switching to a commercial product, such as Manhattan or SAP, but the costs and challenges of doing so without interruption to the business resulted in a decision to keep maintaining the current system. The business has been judicious in its requests to update the system, understanding that changes take a long time to implement and test due to the design. However, competition from major online retailers are starting to seriously impact profitability, forcing the business to make a considerable investment.

    The supply-chain system is comprised of multiple modules mostly written in the Java programming language, but some of the older modules are in C++ and require a Windows Server operating system. This combination of technology has been a source of strife for Steve’s team. They have tried multiple technologies over the years to make the system more stable and to isolate the older C++ modules in a way that reduces risk of downtime should they crash. The Java modules were written to run inside of a web application server, which provides some linear scalability, but it’s still an issue to scale the C++ modules in a relative manner. Now, increased demands from the online channel is stressing the system in ways that it was never designed to handle.

    The business has asked Steve to provide a comparison of costs and resources needed to migrate to a commercial system versus modernize the current system. However, there is one constraint that is limiting the business moving to a commercial version at this time: There are five months until the winter shopping season freeze, when all changes must be completed with no further changes to the systems until February of the following year. Most of the time estimates from integrators for the commercial version are more than 12 months in duration.

    Steve’s company is really between a rock and hard place. If it doesn’t fix the system Steve is managing, it may not be able to scale to the volumes the company needs to be profitable this holiday season, but the company has waited so long to decide to move to a commercial package that it won’t be ready in time for the holiday buying season regardless.

    Likewise, Steve and team are in a similar difficult position. Their efforts around a modernization program have yielded some potential wins that could allow the business to achieve many of their desired outcomes before the winter shopping system freeze. However, there is a culture of fear that permeates Steve’s team. Whenever this system has failed in the past, there were significant reprisals from the business in the form of multi-day “all hands on deck” sessions, where the entire team was expected to be there from 7 a.m. until 8 p.m. until the system was operational again, not to mention letting go those who introduced bugs into production releases.

    Stacey is Steve’s head of development. She brings the modernization plan to Steve for review, but makes it clear that the team believes there are some potentially high risks associated with the approach. While the Stacey and team believe they will be successful, they want assurances from the business that they have the leeway and support to take the risks without reprisal. In return, Stacey tells Steve that there ares certain changes that the team will implement to limit downtime if something should occur:

    1. They will adopt a strategy that developers are responsible for fixing anything they break.
    2. They will be implementing a new continuous integration and deployment tooling that will automate the integration build, unit testing and review of any code changes speeding release of updates and fixes into production.
    3. They will be adopting the Agile Scrum software development life cycle to deliver functional changes every two to three weeks.
    4. They will set up a Kanban board online that will allow the business to track and understand where the proposed capabilities are and when they will be completed.
    5. Before each sprint the business will have a chance to reprioritize any features or capabilities so as to ensure that the most important features get completed prior to the system freeze.

    Steve likes Stacey’s plan and agrees to take it to the business. He explains to Stacey that there will be a natural tendency to push back, but given the urgency and lack of options, this may very well be the best time to push for these changes in their company. In the past, there has not been a lot of tolerance where IT systems impacted financial performance. It’s now Steve’s job to help the business understand that, with the growing dependency on software in business, its expectations need to change for the business to successfully compete.

    — JP Morgenthal

  • DevOps Challenges in C/C++ Projects

    DevOps Challenges in C/C++ Projects

    “C++ is not only the most powerful language in terms of performance, but it’s also a great language! It has true generics, it is expressive, and one of the most loved languages out there by programmers.”

    — Diego Rodriguez-Losada, SW Engineer at JFrog and creator of Conan.io

    This very powerful language that has unbeatable performance continues to be used and favored in all industries. However, while DevOps has become pervasive in other major domains of software development such as Java, implementing modern C and C++ DevOps hasn’t been easy, despite solutions out there that can actually help.

    Let’s take a look at the challenges C/C++ developers face, and then see how they can be solved.

    tl;dr

    C and C++ are are favored by many developers for many great reasons. However, implementing modern DevOps and continuous integration in C and C++ projects isn’t easy. It is still challenging due to the nature of the C/C++ programming languages and ecosystem. Today, we have the knowledge and experience to identify the requirements we need to meet today’s DevOps needs for C and C++. And I’ll demonstrate with the below case study that this is possible.

    Building C and C++ Projects

    Ideally, we want the CI/CD flow from the developer changes to production to be as smooth and fast as possible. However, when compared to other development languages, C/C++ developers face greater challenges:

    • Long build times: This is not because C and C++ compilers are slow. In fact, they are blazing fast and some of the most advanced and brilliant pieces of technology in the whole IT world. But, C/C++ have the problem of headers and the preprocessor basically copying every included file again and again in each translation unit, bloating the lines of code that they have to compile. There are some mechanisms as pre-compiled headers that can partly alleviate the issue for second and subsequent rebuilds. Also, C/C++ languages are used many times for huge projects compared with other languages, with millions lines of code (MLoc)—a typical AAA game has 20 MLoc.
    • Diverse platforms and ecosystems, different build systems: C and C++ are ubiquitous. They are used in computers, embedded devices, mobile devices and more. But in every platform they will use different compilers (such as MSVC cl.exe in Windows, GCC in Linux, apple-clang on OSX) and with many different build systems. CMake, MSBuild and Makefiles or autotools are widely used, but companies are also using many other build systems, even developing their own custom solutions.
    • Binary compatibility: C and C++ are built to native/binary code, but binaries compiled with a certain compiler version are not compatible with other compilers, or even with the same compiler of a different version. This problem is known as ABI (Application Binary Interface) incompatibility, which other languages don’t have to deal with. ABI incompatibilities can result in link errors, which are easy to catch at build time, but oftentimes can produce runtime errors.
    • Code inlining and embedding: Shared libraries directly embed native code of static libraries they are linking. But not only that, even static libraries might embed code declared in headers from another library. This means it might be necessary to rebuild binary artifacts from source code libraries that have not been modified at all, just because some of its dependencies have changed.
    • Lack of standard for OSS: OSS libraries can host their source code in GitHub, GitLab or Bitbucket, but that doesn’t make them ready to use. Users need to build binaries from sources (which can be painful), retrieve prebuilt binaries from a system package manager (which may be obsolete and in any case different for each platform) or by using other installers or precompiled modules (which must be downloaded from a website). After that, they typically also require different tweaks to the consumer build system, which is also different for each platform.

    Modern DevOps Requirements for C and C++

    Given the above list of challenges, what are the modern DevOps practices and tool requirements for C and C++ projects?

    • Manage and reuse binaries: Building from sources every time is very expensive, error-prone and doesn’t scale for large projects. Reusing binaries should be consistent for different platforms, and deal with the ABI compatibility issues.
    • Manage all binaries in a single repository or server: Creating and maintaining packages in several systems (such as apt in Debian, rpm in RH, nuget/choco in Windows and pkg in OSX) is very costly for developers or DevOps engineers. Being able to store, manage and retrieve binaries from the same location is a great simplifier of infrastructure and flows, thus a big time saver.
    • Adapt to any build system, platform and tool, from legacy to latest: Creating good CI and package management would be much simpler if everyone was using a single build system. But thinking projects can migrate to a build system is plainly naive. The cost of migrating some libraries or projects to a new build system is a huge investment that can take months. Processes and tools must be able to adapt to to deal with any build system and existing legacy tool.
    • Have good integrations with other tools: Not only build systems, but tools must integrate as simply as possible with other kinds of tools. For example, continuous integration platforms such as Travis and Appveyor cloud services for Linux/OSX and Windows, popular for being free for OSS projects, as well as Jenkins, which is the de facto standard in the industry for proprietary code. Also tools must integrate well with popular IDEs such as Visual Studio or XCode and testing, coverage, static analysis, multiple control version systems, etc.

    Conan C/C++ Package Manager Case Study

    Conan is a free OSS C/C++ package manager. It is decentralized, portable, and multi-platform, running on many operating systems, such as Windows, Linux, Mac, BSD and Solaris, but targeting any possible target of C/C++ applications.

    Here’s how Conan addresses the above requirements:

    • Conan is able to build, upload, and share binaries for any number of different configurations. It manages binaries, retrieving the correct one for each corresponding platform as needed, and is also able to build from sources when necessary, minimizing ABI incompatibility issues.
    • Conan packages and pre-built binaries can be uploaded to a server and shared within They can be shared privately within a team or companywide, using the OSS conan_server or JFrog Artifactory Pro. If desired, Conan packages can be distributed worldwide using JFrog Bintray either with private or public repositories, completely free for OSS projects. All different binaries for all supported platforms can be uploaded and managed in the same server with exactly the same interface.
    • Conan works with any build system. It includes built-in integrations with CMake, Visual Studio, Makefiles, SCons, QMake and more. It also has good user-side extensibility to support any other build system, using “generators.” This means extensions can be developed to translate the Conan dependencies model to any build system format and generate files that can be read by those build systems.
    • Conan integrates well with different CI systems, with specific tools and helpers for Travis, Appveyor and GitLab, and also features custom DSLs in the Jenkins Artifactory Plug-in.

    Conan package recipes are written in Python, so they can be used to easily customize behavior to a great extent with standard Python syntax, allowing users to easily plug-in many different tools that were previously mentioned in this article: static analysis, testing, code coverage, and more.

    Let’s take a look at a typical flow, from a DevOps perspective, to illustrate how Conan works. First, a developer makes some source code changes to a specific library (LibB), committing and pushing these changes to the shared version control system server (Git Repo).

    Diagram: CI Cycle example for C/C++ with Conan, Artifactory and Jenkins (build systems: CMake, VS, MakeFile)

    Then the CI system will listen to the Git repository, ideally with Git hooks since polling is not recommended, and fire a job for it (Jenkins). Below is an example of how this would be defined with a Jenkins pipeline:

    The first stage in the above example is straightforward. The second stage invokes the package creation that is internally split into the two subtasks:

    1. The LibB dependencies are retrieved in binary form, to avoid rebuilding them from sources and wasting time.
    2. The dependency graph for all transitive dependencies is built and one or more files are written. In this example, LibB uses CMake as the build system and Conan generates a “conanbuildinfo.cmake” file that includes all of the dependencies information to enable LibB find and correctly link to them. Conan will then call the LibB build system to generate a binary package for it. And finally, in the last Jenkinsfile stage “Upload packages,” the generated binary is uploaded to the Conan package server (JFrog Artifactory). The LibB binary package is immediately available for consumption by developers or other CI jobs.

    This example illustrates a build configuration for a 32-bit architecture as specified in the  “conan create” command with the “-s arch=x86” argument. Note that many additional configurations can be built in parallel using parallel tasks and jobs for different compilers, OS, architectures and more.

    Conclusion

    C and C++ have extra challenges compared to other programming languages in development. This also makes it more challenging when trying to implement modern DevOps, but not impossible. C/C++ has been overlooked and it’s time we update the tools to meet the needs of developers. What DevOps principles and practices are you implementing with your C/C++ projects?

    About the Author / Baruch Sadogursky

    Baruch Sadogursky is the Developer Advocate at JFrog. For a living he hangs out with JFrog’s tech leaders, writes code around the JFrog platform and its ecosystem, and then speaks and blogs about it all. He has been doing this for the last dozen years or so, and enjoys every minute of it. He also is a professional conference speaker on DevOps, Java and Groovy topics, and is a regular at the industry’s most prestigious events including JavaOne (where he was awarded a Rock Star award), DockerCon, Devoxx, DevOps Days, OSCON, Qcon and many others.  His full speaker history is available on Lanyrd. Follow him on Twitter @jbaruch on Twitter, or read his blogs here and here.

  • What Developers Want, and How to Give It to Them

    What Developers Want, and How to Give It to Them

    Software is at the core of every modern business, and software-driven companies are disrupting most traditional industries. As the demand for rapid delivery in digital services grows, companies are looking for ways to release products and upgrades in weeks instead of months, or in days instead of weeks. Many DevOps groups are adopting the continuous integration/continuous delivery/continuous deployment cycle of Agile software development to address the high velocity of releases and faster time-to-market requirements. In the CI/CD/CD cycle, developers and testers continuously integrate and test new code, deliver applications and upgrades to production, and from there, deploy them to customers through cloud- or web-based venues.

    But in most companies, dev/test teams are dependent on IT and operations (IT Ops) teams to provide the physical and software stacks they need, and IT Ops teams can’t provide developers and testers with infrastructure and applications fast enough to meet the ongoing and relentless pace of the CI/CD/CD cycle.

    DevOps Challenges

    The most common IT Ops obstacles are long procurement and provisioning cycles, lack of automation and organizational silos.

    Long Procurement and Provisioning Cycles: In many software companies, the IT Ops team has a lengthy procurement and provisioning cycle, and developers may have to wait anywhere from several days to a few weeks for IT Ops to handle each request.

    Lack of Automation: Developers may be using an outdated IT ticketing system to request infrastructure and software. Each time a developer issues a ticket request, an IT Ops person must follow a certain workflow to fulfill that request, and must complete each step before sending the ticket on to the next IT Ops person in the chain. These workflows often consist of time-consuming manual steps. For example, an IT admin may spend hours manually copying database software from a file server over to the hardware using command line interface (CLI) scripting. The admin must then install and configure the database software and connect it to the network.

    Organizational Silos: In large enterprises, individuals or sub-teams fulfill certain tasks for a dev/test request separately from the others. These silos turn IT Ops procurement into a long series of handoffs, where each team member must complete their assigned tasks before handing the job off to another team member.

    What’s a company to do? The answer is to implement a self-service, automated private or hybrid cloud. Here are some of the reasons for this approach.

    On-Demand, Self-Service Provisioning

    Every developer is different, and each should have the power to create their own workspace. A self-service cloud automates the provisioning process by letting developers and testers manage their own initial deployments and configurations. The cloud platform should offer a set of automated provisioning tools to allow developers and testers to create their own dev/test environments. The cloud solution should include both a self-service user interface and an API-driven infrastructure-as-code that lets developers create VMs and databases, access storage, set up network connections, etc., using RESTful API coding.

    An Intelligent, Well-Organized User Interface

    A self-service cloud should have an intelligent user interface (UI) that gives developers access to a set of common infrastructure tools and applications. Ideally, a self-service UI should allow IT Ops administrators to assign resources in an organized manner. Admins should be able to designate business units (BUs) on the UI (i.e. “AppDevTeam1,” “WebDevTeam1”) based on units within the company, assign team members to BUs, and designate current projects (i.e. “AppDevProject1”) on the UI according to BU. They should also be able to assign quotas to each BU (i.e. AppDevTeam1 gets 100 VMs, 25 vCPU cores, 100GB memory and 400GB storage), and to each individual project (i.e. AppDevProject1 gets 10 VMs, 5 vCPU cores, 8GB memory and 40GB storage).

    An Application Store

    A self-service private cloud should have an online “application store” that provides single-click access to common tools and services for CI/CD, workload management, middleware and storage back-ends.

    Seamless, Two-Way Hybrid Cloud Migration

    A self-service hybrid could should have seamless, two-way migration to allow developers and testers who have public cloud access to easily move applications and workloads back and forth between public and private clouds.

    Administrative Dashboards

    A self-service cloud should have a set of administrative dashboards that allow the IT Ops team to control access to resources on the UI. These dashboards should deliver complete visibility into which teams and team members are using which resources, and allow the IT Ops team to perform admin tasks such as:

    • Creating user accounts and passwords on the UI
    • Creating BUs, and projects for each BU, on the UI
    • Assigning developers and testers as “members” of a certain BU or project
    • Assigning self-service infrastructure tools (compute, storage, network) on the UI, and set quotas for those tools according to BU or project
    • Importing new applications to the application store or the UI.

    A Software-as-a-Service Platform

    A software-as-a-service (SaaS) platform with portal-based access is the best venue for a self-service cloud solution. A SaaS platform offers the flexibility to do upgrades and customization to the various features of the UI, application store and administrative dashboards. The flexibility of the SaaS private-cloud solution gives it the potential to become the de facto standardized platform for CI/CD/CD in Agile software development.

    In short, DevOps teams need to keep up the CI/CD/CD pace in a modern enterprise, and self-service cloud platforms offer the self-provisioning and customized workspaces that keep developers productive and happy.

    About the Author / Kamesh Pemmaraju

    Kamesh Pemmaraju leads product management, product marketing, and technology partnerships at ZeroStack. Kamesh is a seasoned product management/marketing leader with a strong engineering and consulting background. In his most recent product roles at Mirantis and Dell, he focused on delivering private and hybrid cloud solutions to enterprises. He holds a Master of Science in Computer Science from Indian Institute of Science. Connect with him on LinkedIn and Twitter.

  • Logz.io Extends Scope of Log Analytics Service

    Logz.io Extends Scope of Log Analytics Service

    Log analytics is all the rage these days among IT and security professionals trying to discover the root cause of any performance issue or security breach. But there’s little consensus about how best to go about analyzing logs. Many IT organizations have made major investments in commercial platforms such as Splunk, while others prefer to rely on the less expensive, open-source tools Elasticsearch, Logstash and Kibana, collectively known as the ELK stack.

    As a provider of a cloud service based on the ELK stack, Logz.io has been providing organizations that prefer to rely on open-source software an alternative to deploying and maintaining their own ELK stack. Now Logz.io is extending that service to include Logz.io Application Insights, which employs machine learning algorithms to create a model of normal IT operations that can be used to more easily identify anomalies, and Logz.io Data Optimizer, which helps identify which logs are worth keeping long-term.

    Fresh off raising an additional $23 million in capital, Logz.io CEO Tomer Levy says his company is building up a pool of machine data to drive advanced analytics fueled by machine learning algorithms. Those insights then can be shared proactively with other Logz.io customers to head off production issues before they even occur. At present, Logz.io has more than 400 customers.

    Levy says the Logz.io Data Optimizer should enable IT organizations to substantially reduce their costs. Most providers of log management tools charge based on the amount of data collected. By helping organizations identify extraneous log data, the cost of implementing analytics of machine data drops considerably, Levy says.

    Logz.io Application Insights, meanwhile, provides a simple way to identify the last changes made to the environment that might have created a performance issue or introduced a security vulnerability.

    Levy says Logz.io, via application programming interfaces (APIs), can be integrated with multiple continuous integration/continuous development (CI/CD) platforms, including Jenkins. In fact, log analytics is now a fundamental element of any mature set of DevOps processes, he notes.

    Platforms for analyzing machine data is one of the fastest growing sectors of enterprise IT. New research from Zion Market Research forecasts that the IT operations analytics market is expected to grow on a 23.7 percent compound annual basis to reach $9.2 billion by 2020.

    Most DevOps issues only take a few minutes to resolve. But identifying the root cause of an issue can take weeks, sometimes even months, to identify. In more advanced IT organizations, centers of excellence around log analytics are now being created to identify not only potential IT and security problems, but also issues impacting, for example, the amount of revenue being generated via a specific application.

    It still may be a while before log analytics become pervasive across the enterprise. But every event in the IT environment generates a log, so the real challenge and opportunity is correlating all those log events into something that manifests itself as a truly actionable intelligence.

    — Mike Vizard

  • Axway Extends API Management Reach

    Axway Extends API Management Reach

    With application programming interfaces playing a larger role in the DevOps environment, Axway has added to its API toolkit for developers. The company expanded its AMPLIFY API management platform to include a visual tool for composing and integrating APIs and enhanced its API Manager tool so that it now can be invoked to scale resources up or down as needed. In addition, Axway unveiled API Central Service that makes it easier to integrate APIs across an ecosystem of organizations that make their services available via the AMPLIFY marketplace.

    Other new capabilities include an open-source MQTT connector for building internet of things (IoT) applications, a connector to the Microsoft Azure Cloud and tighter integration between Axway’s MFT file transfer software and the Syncplicity file synchronization software it acquired earlier this year.

    Axway also merged the Titantium SDK for building native mobile applications using JavaScript into the Core SDK for developers and is previewing the Query Builder Analytics tool, which enables users to do ad hoc query of mobile statistics. The Titanium code is based on technology developed by Appcelerator, which Axway acquired early last year.

    The announcements were made at the recent Axway SPARK 2017 conference. Vince Padua, vice president of platform and products for Axway, says these and other enhancements to the Axway API portfolio are intended to make it easier for organizations to craft microservices spanning multiple platforms. In some instances, those microservices will be crafted by developers, but Axway believes more advanced users will be stitching together microservices on their own using visual tools, says Padua.

    While most early use of APIs was driven by web-based applications facing external users, using APIs to interconnect services inside the enterprise now dwarfs the number of instances of published external APIs, he notes. The proliferation of those APIs has created a significant DevOps challenge for organizations and requires an API management platform to streamline the management of various back-end service. At the same time, Padua notes that DevOps teams working in collaboration with line-of-business units have taken over much of the API management, which previously was left up to individual developers. Now, IT organizations are trying to strike a balance between maintaining control and developer productivity, he says.

    The shift in API management responsibilities has also driven a wave of mergers and acquisitions over the last two years as API management has become embedded in mainstream application development platforms. But there’s also a fierce debate over the degree to which legacy API management platforms can support microservices. As microservices based on emerging technologies such as containers or more mature Java programming tools continue to evolve, API management is becoming more critically important. Each microservice generates its own API that needs to be maintained as each microservice gets continually updated. That requires an API management platform that can support all levels of API call activity that once would have been assumed to be unimaginable.

    — Mike Vizard

  • Trend Micro Expands DevSecOps Portfolio

    Trend Micro Expands DevSecOps Portfolio

    At the AWS re:Invent 2017 conference today, Trend Micro significantly expanded its reach into DevSecOps by announcing it has acquired Immunio, a provider of agent software that can be employed on a central platform engine to execute security policies on a granular level.

    In addition, Trend Micro announced it is adding support for container image scanning to its portfolio of security products as well by the spring of 2018.

    Mark Nunnikhoven, vice president of cloud research for Trend Micro, says both the Immunio policy engine and the container image scanning technology are now part of the Trend Micro Hybrid Cloud Security family of offerings that the company plans to expand for developers. Those capabilities, in turn, are exposed to developers deploying applications on-premises or in a public cloud primarily through its Trend Micro Deep Security cloud service, a suite of security technologies and threat detection services exposed by application programming interfaces (APIs).

    Nunnikhoven notes Trend Micro has seen a significant increase over the last several years in the use of programmatic approaches to managing security. Most of the shift has been driven by developers who have driven security to the left as part of the rise of DevSecOps. But he says security professionals are also starting to develop programming skills to advance IT security both in the cloud and on-premises.

    Nunnikhoven says the rise of containers is making DevSecOps more challenging. Too many developers are still grabbing containers from registries without checking them for vulnerabilities. As many as one-third of containers may contain known vulnerabilities, he says. To address that issue, Gartner estimates that by 2019 more than 70 percent of enterprise DevSecOps initiatives will have incorporated automated security vulnerability and configuration scanning for open-source components and commercial packages. That compares to less than 10 percent in 2016.

    IT organizations, however, don’t just want to be able to scan container images. Nunnikhoven says it’s clear they want a set of integrated security tools that can be employed to secure both the containers and the hosts they are deployed on. In the case of Immunio, Trend Micro is adding a security technology that can be embedded in applications running on virtual machines or bare-metal servers, as well as containers making up a microservice.

    While Trend Micro has a long history of providing security products to IT and cybersecurity professionals, it and virtually every other security vendor are competing against a host of startups that have embraced DevSecOps to change how security technologies are consumed. In its effort to remain relevant, Trend Micro is expanding its portfolio of products to focus more on developers. Over time, however, Nunnikhoven expects there will be increased collaboration between developers and IT security professionals, as the lines of responsibility for various aspects of security are better drawn.

    In the meantime, however, Trend Micro—like most of the vendors in the IT security industry—is now clearly making a hard shift to the DevOps left.

    — Mike Vizard

  • Core Factors Influencing Java Memory Consumption

    Core Factors Influencing Java Memory Consumption

    Java is known for having an insatiable appetite for resources, requiring strict controls to not exceed budget limits. However, the latest JDK updates and other developments have helped to make Java runtime extremely flexible in terms of memory usage. When configured smartly, Java can be cost-effective for different types of applications—cloud-native or legacy, microservice or monoliths. Today, it’s possible to make Java very slim from the start and scale it up gradually without consuming unnecessary resources.

    Here we’ll take a closer look at the factors influencing resource usage inside JVMs, see what tools can help and how processes can be tuned to gain more elasticity and scalability, ultimately reducing TCO.

    Scaling Possibilities: Virtualization vs. Containerization

    Within JVMs there are several scaling options: vertical, horizontal and a combination of both. To maximize results, it is important to start with a vertical scaling configuration that optimizes RAM and CPU usage inside every instance, based on current load levels. As a next step, these settings will be replicated across all instances while scaling horizontally.

    VMs Scaling

    While starting to run a project inside a VM, it is important to pick the right size machine, as too small an instance can lead to performance issues or even downtimes during load spikes. However, over-allocating will result in wasted unused resources during normal load or idle periods that still must be paid for. This can be a tough choice.

    Start with a smaller VM and scale it as the project grows. When just a bit more resources are required, the cloud vendor can offer you to double the size, as this is the most commonly used scaling step (e.g. see AWS offer below).

    During such scaling, the current VM normally is paused to migrate and redeploy the application. This inevitably causes some downtime and requires manual intervention.

    Memory ballooning provides a possible way (although rather complicated) to modify the amount of resources inside VMs on the fly without incurring downtime. However, this process is not fully automated and requires special tools to monitor the memory pressure in the host and guest OS and then activate vertical scaling based on the needs. As a result, memory ballooning doesn’t work well in practice, as the memory sharing should be automatic to present the expected advantages.

    Unfortunately, lack of VM elasticity and efficiency in terms of resource usage often leads to overpaying.

    Containers Scaling

    Containerization presents a new way of application packaging that makes resource consumption more granular and flexible, by automatic resource sharing among containers on the same host using cgroups. Unlike VMs, containers’ boundaries can be easily scaled up and down without the need to pause and reboot running instances.

    There are two types of containers: application and system containers. Both use the same scaling approach but they are intended for different purposes. An application container (such as Docker or rkt) typically is more lightweight, runs a single process and is used mainly for creating new projects, as it is easy to build them from pre-existing Docker image templates.

    A system container (LXD, OpenVZ) behaves like a full OS and can run full-featured init systems. This type of container is preferable for monolithic and legacy applications, as it can reuse the originally created design and important “old school” settings.

    Even system containers are much thinner compared to virtual machines, so scaling up and down takes much less time. And the horizontal scaling process is very granular and smooth, as a container can be easily provisioned from scratch or cloned.

    Garbage Collector Choice

    To maximize the efficiency of the above mentioned vertical scaling inside a Java-based container, it is important to select the appropriate garbage collector (GC) and tune it according to the project needs.

    Let’s review five widely used garbage collector solutions:

    • G1: From JDK 9, this modern shrinking garbage collector is enabled by default. One of its main benefits is the ability to compact free memory space without lengthy pause times and uncommit unused heaps. This GC is considered the best production-ready option for vertical scaling.
    • Parallel: A default GC in JDK8, it is a good option for low pauses but not for memory shrinking. This makes it inappropriate for flexible vertical scaling.
    • Serial, ConcMarkSweep (CMS): Both of these are shrinking garbage collectors with the ability to scale memory usage in JVMs vertically. But in comparison to G1, they require four Full GC cycles to release all unused resources. A new JVM option (-XX:-ShrinkHeapInSteps) in JDK 9 can  speed up memory release by bringing down committed RAM right after the first Full GC cycle.
    • Shenandoah: Shenandoah is a rising star among garbage collectors which promises to be the best solution for JVM vertical scaling. Its main benefit over the others is the ability to shrink in live mode without necessity to call Full GC, which helps eliminate significant performance degradation.

    Let’s compare memory behavior with shrinking G1 and non-shrinking Parallel:

    With Parallel, the unused RAM is not released back to OS. JVM keeps it forever, even disregarding the explicit Full GC calls. So even if your application has low RAM consumption, the unused resources cannot be shared with other processes or other containers as it’s fully allocated to the JVM.

    The modern shrinking G1 garbage collector significantly improves resource utilization compared to the previous example. The reserved RAM increases slowly according to the real usage growth. And all unused resources within the Max Heap limits are not wasted by standing idle, but made available to other containers or processes running in the same host.

    To summarize, Java applications with non-shrinking GC or non-optimal JVM start options hold all allocated RAM. For scaling Java vertically, the garbage collector should provide memory shrinking in runtime. In other words, it has to package all the live objects together, remove garbage objects, uncommit and release unused memory back to the operation system.

    Charging Model of Cloud Providers

    Nowadays, most of the cloud vendors offer a “pay as you go” billing model. This means that it is possible to start with a smaller machine and then add more servers or migrate to a twice-bigger instance as the project grows. But as described above, usually you reserve more than the application actually consumes to avoid the risk of downtime during the load spikes. As a result, many organizations overpay because the account is charged per VM but not based on the consumed resources inside.

    At the same time, there are providers offering  “pay as you use” billing approaches that became possible with the help of containerization, resource granularity and automatic vertical scaling. The payment is based on the resource units inside container. And the required capacity is provided and reclaimed on the fly in accordance with the load at the current moment. As a result, you are charged based on actual consumption and are not required to make complex reconfigurations to scale up or down.

    Taking into consideration all these factors and implementing the right settings can significantly reduce the costs for Java hosting resources, as well as positively influence application performance as a whole. Cloud and container technologies continue eliminating barriers and offering new opportunities for projects with different architectures and budgets.

    About the Author / Ruslan Synytsky

    Ruslan Synytsky is CEO and co-founder of Jelastic. He designed the core technology of the multilingual cloud platform that runs thousands of containers in a wide range of data centers worldwide. Ruslan worked on building highly available clustered solutions, as well as enhancements of automatic vertical scaling and horizontal scaling methods for legacy and microservice applications in the cloud. Ruslan is actively involved in various conferences for developers, hosting providers, integrators and enterprises. Follow him on Twitter.

     

  • Micro Focus Unfurls Functional Testing Service

    Micro Focus Unfurls Functional Testing Service

    The merging of software assets from Micro Focus and Hewlett-Packard Enterprise (HPE) that occurred earlier this year included StormRunner, a series of load- and performance-testing tools. Micro Focus recently extended that portfolio with the introduction of Micro Focus StormRunner Functional, a suite of functional testing tools delivered as service that can be employed to test applications running on any browser, operating system or mobile device.

    Shane Evans, director of product management for application delivery management for Micro Focus, says StormRunner Functional spans a variety of automated tests addressing unified functional testing (UFT), UFT Pro and Selenium browser testing tools that include elements developed by both HPE and Micro Focus. The Micro Focus StormRunner Functional Testing service also includes pre-built integration with Google Analytics, Micro Focus Octane, GIT and Jenkins to streamline the testing process.

    Interest in automated testing has increased substantially in the last few years, says Evans, because developers are under more pressure than ever to roll out new applications and associated updates faster. Unfortunately, most developers don’t have the time required to test applications themselves, or there is simply not enough money in the budget to hire quality assurance teams to test every element of an application. Micro Focus StromRunnner Functional provides an alternative approach using a set of testing tools that have been widely employed across the enterprise for decades, says Evans.

    Evans notes Micro Focus is pursuing a comprehensive approach to application delivery management spanning everything from testing tools to application lifecycle management. Micro Focus is making the contention that most DevOps teams are a lot more interested in getting access to the results of a test than managing the actual testing technologies themselves, says Evans. In addition, advanced analytics and machine learning algorithms, which now are standard elements of testing process, require access to massive amounts of data to be effective. That data is a lot easier to aggregate in the cloud using SaaS applications than in an on-premises environment. In fact, Evans says, those requirements are among the factors driving a wave of recent acquisition across the application testing sector.

    Arguably, the biggest testing challenge organizations now face is moving away from processes based on IT Information Library (ITIL) guidelines to a more DevOps-centric process, under which continuous testing is more embedded within the application development process, Evans says. Functional testing is only one element of the testing process, but it has become more critical as end users become less forgiving of substandard digital experiences inside and out of enterprise IT environments. Regardless of who inside the organization is responsible for testing applications, the expectation now is that every application experience inside the enterprise will be on par with a consumer application experience.

    — Mike Vizard

  • DevSecOps: Security Needn’t be Sacrificed for Speed

    DevSecOps: Security Needn’t be Sacrificed for Speed

    With the right practices, security needn’t be an impediment to continuous development and rapid improvement.

    The same cycle keeps repeating, according to IT security and risk management consultancy Sense of Security co-founder and CTO Murray Goldschmidt. A new technology is hyped, leading to rapid adoption, but security is left as an afterthought. It happened with WiFi and voice over IP (VoIP), he says, and is currently happening with the internet of things (IoT). But it doesn’t have to be that way.

    DevSecOps: DevOps + Security

    DevOps is good for making things better, faster. But there tends to be a culture clash between those talking about speed, velocity or agility and those concerned with issues such as control points.

    So Goldschmidt and his colleagues are showing their clients how security can be integrated into DevOps (DevSecOps) in an automated manner without affecting velocity.

    Most people with development, operations or cloud backgrounds aren’t well-versed in security, he suggests, so Sense of Security shows clients how DevSecOps means security and DevOps can run in parallel.

    “It’s not that complicated,” he says, but it’s something most people don’t think about.

    Organizations often have a vulnerability management life cycle to identify and treat issues. After all, that’s part of various industry standards.

    The typical approach is an annual penetration test to find issues, which can then be addressed.

    A better way is to move to automated testing, and there are various commercial and open-source products to do that job. Goldschmidt says he sees little resistance to this idea.

    The next step is to go from scheduling these vulnerability scans on a quarterly basis to weekly or daily—or even to run them continuously.

    Citing the Struts vulnerability that caused a big problem for Equifax, he notes the challenge is to identify vulnerabilities in your systems before an attacker does. Continuous automated scanning means the window of vulnerability is very narrow.

    This idea is simple enough, he says, but for some reason it doesn’t occur to most people until someone brings it to their attention.

    When a scan reveals a vulnerability, its significance (severe, medium, etc.) is used to prioritize remediation.

    “DevOps guys understand those triggers,” he observes: If you give them the data, they can take the necessary actions. For example, that might mean shutting down the servers in a small web farm one at a time, applying the patch, restarting and moving on to the next. They could all be patched and running by the end of the day.

    Patching Isn’t Everything

    However, “it is unfair to assume organizations can patch things quickly” every time, he says. For example, the Struts vulnerability required more than just a patch—the code running on it had to be recompiled and tested, and that process could take months in a large organization.

    So organizations should not rely on the idea that patching is the fix for a vulnerability. While patches will be applied eventually, if you can make it difficult to actually take advantage of any exploits, the risk of data breaches is very low.

    One very easy-to-implement example of these measures is using a stateful firewall to ensure inbound-only access to web servers. By disallowing outbound access—”the channel through which data is lost”—there is no path for data to leave.

    Goldschmidt also recommends using tools to examine in-house code and the open-source and commercial code that is used with it. Such tools can detect most common problems, including openings for SQL injection, cross-site scripting and token misuse.

    He describes these tools as being the equivalent of “spellcheck for developers,” and says it reduces the likelihood of putting insecure code into production.

    The market includes products from Veracode (now part of CA), Sonatype and Qualys.

    Qualys, he notes, provides differential reporting. This makes it obvious that something has changed, and “that is the key to automation.” Whether the system itself has changed or new information has been discovered about vulnerabilities or configuration issues, action is required.

    Furthermore, the ease of making configuration changes that could have security implications makes continuous scanning even more important.

    These checks should not be limited to individual modules. Rather, they should be repeated—preferably automatically—as modules are assembled to help developers avoid poor code and to check the overall product.

    RASP Away Some Attacks

    Runtime application self-protection (RASP) is another technology Goldschmidt advocates. The idea is to detect abnormal and possibly malicious activity. One example is that normal operation would see an application communicating with its application server, and the application server communicating with the database. If the application suddenly makes a direct request to the database—as happens in an SQL injection attack—action is clearly required.

    Depending on the situation, RASP might raise an alert or immediately terminate the application, among other possibilities.

    The use of these and other technologies and techniques should allow organizations to run at the pace implied by DevOps without sacrificing security.

    — Stephen Withers

  • Gene Kim, DOES17 Speakers Discuss the Deployment Age

    Gene Kim, DOES17 Speakers Discuss the Deployment Age

    In a special episode of Electric Cloud’s Continuous Discussions (#c9d9), Gene Kim and speakers from the upcoming DevOps Enterprise Summit San Francisco (DOES17) discussed the deployment age, and how DevOps practices and automation can unburden teams and boost productivity.

    The panel included: Mik Kersten, CEO of Tasktop; Robin Yeman, fellow at Lockheed Martin; Courtney Kissler, VP of digital platform engineering at Nike; and, our very own Sam Fell and Anders Wallgren.
    Continue reading for some of their top takeaways:

    Kersten discusses the importance of spreading the word about DevOps tooling: “I think the best thing we can do is accelerate this turning point by giving the rest of those 15 million developers working in all of those other companies the tools that they need to apply these technical practice and to reorient their organizations to actually leverage them.”

    Yeman on the multiplier effect of automation: “DevOps is definitely all about the people, but the automation enables people to have such a higher outcome and better business results. It’s almost like a force multiplier for companies.”

    It’s crucial to look at the bigger picture of software delivery, advises Wallgren: “If you don’t have a big picture of what your value stream is from one end to the other, it’s hard to convince people that the problem they’re looking at is in fact not the right problem to be focusing on, or whether that is the right or wrong problem.”

    Organizations that employ transformational leaders succeed, claims Kim: “We see people driving DevOps transformations in large complex organizations, specifically the DevOps enterprise community, and my claim would be that these people are being promoted at a rate far higher than the population at large. My interpretation of this is that the value that’s being created by these leaders is appreciated and they’re being put into roles where they’re being asked to make an even greater contribution across even a broader portion of the organization.”

    You can’t just optimize for cost and efficiency anymore, explains Kissler: “There’s this realization that we’re all shipping software and really embracing that and understanding that organizations that have typically optimized for cost and efficiency are not going to win. And so, optimizing for speed to value, the value stream is a huge shift as well.”

    Yeman explains the awesome leadership structure at Lockheed Martin: “At Lockheed, most business leaders were engineers at one point in time. So, if you’re looking at the President or the Vice President, they started out in software, or systems, or as a tester. They have to have depth in their area because then they can really empathize with what we’re building and with, you know, the people that are building it.”

    More on the wonders of automation, per Kersten: “Agile has scaled up, but it kind of hit a brick wall until automation came into play and organizations realized that they needed reliable, predictable, and safe ways to deploy. I think one of the most interesting things that happened when the technical practice matured around that automation layer is all of the other gaps it uncovered.”

    Wallgren on the ironic manual nature of the software delivery industry: “I think that one of the paradoxes of what we do in software teams is we don’t use software at all, most of the time, to help us produce our own software. We use people.”

    Kim reflects on revelations after reading “Disrupt or Die” by Jedediah Yueh: “The real value that DevOps will create is not going to be in the FAANGs, the Facebook’s, Amazon’s, Apple’s, Netflix’s, and Google’s of the world, but it really is in the large brands in every industry vertical as they either disrupt, get digitally disrupted, or digitally disrupt themselves.”

    Kissler on how to respond to the exponential growth of digital disruption: “I think the acknowledgement of where we’re at and where we need to go and how fast we can get there is a huge component of responding to the digital disruption.”

    Watch the full episode:

    Want more Continuous Discussions (#c9d9)? We hold our #c9d9 podcast every other Tuesday at 10 a.m. Pacific. Each episode features expert panelists talking about DevOps, Continuous Delivery, Agile and more.

    Check out all past episodes and panelists here.

    About the Author / Anders Wallgren

    Anders Wallgren is chief technology officer at Electric Cloud. Anders has over 25 years’ experience designing and building commercial software. Prior to joining Electric Cloud, he held executive positions at Aceva, Archistra, and Impresse and management positions at Macromedia (MACR), Common Ground Software, and Verity (VRTY), where he played critical technical leadership roles in delivering award winning technologies such as Macromedia’s Director 7. Anders holds a B.SC from MIT.