devopsy.kinsta.cloud

Author: David Geer

  • TASC Powers Up DevOps Pipeline

    TASC Powers Up DevOps Pipeline

    Technology team members at TASC, a leading administrator of employee health benefits, were feeling the chains of manual processes that kept them from moving software out at more than a snail’s pace. Development, operations, quality assurance (QA), project managers (PMs) and business analysts who were pushing code to test, staging and production environments or performing user accepted testing (UAT) tests needed to forward features through the pipeline much more quickly.

    “We were doing one release a month, shutting down the entire website for six to eight hours on a Saturday morning to complete deployments,” says John Gildenzoph, DevOps engineer at TASC.

    The company took to orchestrating its pipeline using Automic Release Automation (ARA) to onboard DevOps and catapult software innovations into production.

    Manual Challenges

    Before ARA, TASC used Jenkins—that was pretty much its first step into DevOps-style automation. Before that, the company’s processes were, for the most part, all manual, implemented with a source code repository.

    “For anyone to deploy the application for development on their workstation, or to a test environment or even to production, they had to go out to the server, check out the source code, build the source code and deploy the artifact,” says Gildenzoph.

    TASC was doing that on up to 30 JBoss servers—which were its main web servers—using only two developers. One developer started on the first node and the other started on the last node as they worked toward the middle, updating each server individually and manually, he says. “We came from the Dark Ages where there were really no other products we were using other than the servers and our version control software. Jenkins was the first iteration where we figured out that we needed to be running builds all the time,” Gildenzoph notes.

    Uniting DevOps Tools, Filling Gaps

    TASC uses ARA to unite a variety of DevOps tools into the pipeline and to fill gaps where there isn’t a specific tool. “ARA is platform-agnostic. You can use it like an assembly line and you can plug the worker applications in along the assembly line as you like,” Gildenzoph says. In one example, TASC uses Jenkins as one of those “worker applications,” i.e., as its build tool: ARA tells Jenkins to build the software, then moves the software along itself to the next tool to do the next job.

    According to Gildenzoph, all a company needs to add best-in-class tools at each step in the development process along the pipeline is a command line interface (CLI) or API that enables them to script that tool in to integrate with ARA. That way, if the company decides to use a new tool for any part of the process, it can simply script that tool into the ARA at that point, rather than replace the entire pipeline with one new tool for everything.

    TASC also uses ARA to orchestrate in its use of Amazon EC2 and the ECS products. At the same time, TASC is working to add the management of Docker containers into ARA in the same way.

    TASC IaaS

    TASC uses ARA to create the entire dev, test, staging and production environments where the company will deploy the software. Using the ARA and its automation engine, which is a sort of complex chron that develops the workflows, TASC interacts with its Amazon cloud presence to create the entire application stack.

    “We see that Automic is working on its next evolution of the ARA product, which is a provisioning product that will interact with various cloud technologies such as Amazon or OpenStack so we will be able to create that environment in less of a homegrown manner. It will be more of a drag-and-drop capability with run books to interact with your cloud,” Gildenzoph says.

    These cloud technologies also will be like the applications/worker setups in Gildenzoph’s ARA assembly-line analogy.

    Revving Up Results

    “We moved from our original manual scenario to the point where in some cases we don’t need downtime to deploy the software. We have the orchestration in place and it manages to bleed off part of the cluster, update that cluster, and then bring those portions back online so that our customer doesn’t notice,” says Gildenzoph. This benefits internal and external customers who use the site for call center processes and submitting flex claims, respectively.

    TASC is more agile since the adoption of Automic, releasing software typically on a weekly timetable. This enables the business to respond to requests from customers for new features, innovations and enhancements to the site more quickly and efficiently.

    When TASC purchases another company to add its products to TASC’s, an accelerated pipeline enables the company to onboard that company and products more swiftly and seamlessly.

  • SimplyHealth Uses DevOps to Manage Mobile Testing

    SimplyHealth Uses DevOps to Manage Mobile Testing

    SimplyHealth, a private company health insurance plan provider in the United Kingdom, saw its mobile web traffic trending upward with no end in sight. “While this was good news, there was concern whether the customer experience and the company’s ability to provide continuous application delivery on mobile devices might erode as a result,” said Chris Dale, information technology test and release manager at SimplyHealth,

    A good half-dozen challenges in mobile testing and development stood at the crossroads between mobile customer demand and SimplyHealth’s mobile development speed and ability to respond to needs for improvement.

    With some help from Mobile Labs, a provider of internal cloud mobile device testing for software, SimplyHealth allayed its fears of customer dissatisfaction.

    Mobile Web Test, Dev Challenges

    Dale noted SimplyHealth’s challenges to mobile web test and development were many. Among them:

    • Testing came late in development, causing the testing team to find issues at later in the development process and leading to costly rework for developers.
    • The vast array of mobile handsets that needed to be tested against, which affected productivity and increased expenses because of the time spent searching for, ordering and waiting for devices to be shipped to SimplyHealth for testing.
    • The development team’s use of mobile device simulators for testing mobile software on different device platforms—a process that did not represent accurately the behavior of actual devices.
    • The differing behaviors of Apple and Android devices in some functional areas, which made it impossible to do cross-platform testing with a single script.
    • Testing eventually  became a bottleneck, jeopardizing SimplyHealth’s award-winning customer service levels for its mobile customers.
    • The digital marketing team had difficulties in verifying customer experience on mobile devices.

    An all-encompassing solution for the SimplyHealth mobile web testing team would enable early testing and cross compatibility with the needs of all affected departments, including marketing.

    Dale said the tool would have to meet 34 requirements, including:

    • Allow for the highest levels of security and compliance with the Data Protection Act (similar to HIPAA regulations in the United States)
    • Provide the ability to use the existing automation framework and toolset and hook into SimplyHealth’s continuous integration solution for automatic test execution
    • Offer a way to swap devices in and out quickly and easily
    • Provide easy accessibility from any location
    • Have a simple user interface
    • Maintain high levels of performance
    • Offer scalability for future growth
    • Come with backing by dependable, knowledgeable support and a solid development road map

    The Solution

    After looking at four possible testing solutions based on products listed in Gartner’s Magic Quadrant, SimplyHealth decided on Mobile Labs deviceConnect to manage mobile devices for testing software. This on-premises cloud solution provides the accessibility and flexibility of the cloud and the security of on-premises technology, protected by the security measures available to the enterprise for its other assets, such as firewalls.

    The physical installation largely amounts to a mobile cart and rack for plugging in many different mobile devices for testing. “DeviceConnect enabled SimplyHealth to have a product-agnostic virtual lab so we could all easily test software on the devices using our own in-house testing scripts,” Dale said.

    Mobile Labs was willing to configure and demonstrate a proof of concept mobile device web application test setup using deviceConnect to show the SimplyHealth team how it worked to manage apps and devices for testing. “After we thoroughly evaluated this configuration, we concluded that Mobile Labs deviceConnect was the best choice,” Dale said.

    Implementation

    Mobile Labs implemented the entire solution for SimplyHealth, from setup to installation to ensuring it integrated well with SimplyHealth’s existing Hewlett Packard Enterprise testing tools, Dale noted. “We were immediately writing automation scripts to use with it. We had it working in production the next day.”

    All affected teams and departments have fully adopted and use the Mobile Labs tool, including testing, development, branding, user experience and support teams, he said.

  • Scania: Adopting DevOps for Auto Production

    Scania: Adopting DevOps for Auto Production

    When you think of large vehicles, chances are you think heavy-duty front and rear axles, suspensions and cab parts. When you think of large engines, chances are you think crankshafts, cylinder heads, pistons and injectors. When you think of the brains behind a company that produces all this, you should think software and the processes that create it.

    Swedish automotive company Scania was building its software intelligence using large, legacy development approaches, coding entire software packages as a single project. The organization’s teams were couched in silos. Releases were highly infrequent.

    Everything changed when Scania scaled and conquered the partitions and divisions that separated teams and adopted agile practices and DevOps.

    Scania and its Software

    Scania, a large global maker of heavy transport buses and trucks and marine and industrial engines, runs many software departments. Its Connected Services department creates web-based portals, APIs and embedded software that transmits live and historical data transmitted to and from drivers and vehicles for logistics including positioning, tracking, service planning, geofencing and messaging.

    Scania’s move toward DevOps accelerated in the 2012-2013 time frame, when the company combined developers and testers into feature teams and molded its first DevOps practices. The company had a host of development issues before that.

    “Before 2012, we were organized around traditional big software projects, which slowed progress and hindered communication. We had long lived branches and a product release cycle of about three releases a year. Silos existed between Dev, Ops, Test and Marketing,” said Anders Lundsgard, technical architect at Scania Connected Services. By 2013, he added, feature teams were adopting processed based on a strict adherence to Scrum.

    Scania’s Dev and Ops teams were housed in different locations and working separate goals that were not aligned or cohesive. These teams suffered from confused communications and increasing stress as development worked only on new features while operations tried to use the new software in a stable way in production.

    Pivotal Changes

    Everything started coming together when Scania formed feature teams that progressively shouldered more of the responsibility for forwarding code to all environments and making it work. “There was no involvement in this from operations or infrastructure as they supported tooling and automation for on-premise infrastructure and shifted software to a cloud platform,” Lundsgard said.

    Scania ultimately added Perforce Helix, a software configuration management tool. As long as software engineers know that the focal point of their work is checking in their code, the Perforce product can be the single point of storage of any one software component for all projects in the deployment pipelines. This way there are no multiple, correct current versions of any piece of code that could cause confusion. “Perforce has a number of capabilities that help engineers collocate software for reviews and even shelve files as they pass between developers,” says Lundsgard.

    Scania uses Perforce Helix in combination with its continuous integration (CI) environment and processes to improve quality beyond what manual testing could ever accomplish. “The goal is that software engineers check code into Perforce Helix at least daily,” Lundsgard said.

    Scania DevOps Processes Today

    Scania now versions every change and automates builds, tests and deployments, with CI as a central development practice. The company no longer uses feature branches, with everyone adding code directly to the mainline. “We use a microservice-oriented architecture in order that each feature team can manage and own certain services,” Lundsgard said.

    Different teams approach development with varying degrees of DevOps maturity. Some teams deploy software continuously, sometimes many times per day. Other teams benefit from using some manual testing and may not deploy software for a few weeks. “The tooling has enabled all teams to have a fully automated process for pushing their code into all environments if they choose—automatically or via a click of a button,” Lundsgard said.

    Remaining Challenges

    Scania next plans to fully automate every component of infrastructure from the network to the servers. “Some of our infrastructure and operations people have started to adopt infrastructure as code and they version that code in Perforce Helix as well,” Lundsgard said.

  • Q&A: Full City Tech’s Higbee on Culture, Part 2

    Q&A: Full City Tech’s Higbee on Culture, Part 2

    In part one of this two-part Q&A we dug into Wes Higbee’s position on instilling a DevOps culture. Higbee, a developer and business consultant, continues his separation of wheat from chaff in the field of DevOps dreams.

    devopsy.kinsta.cloud: How is automation, which is a focal point for DevOps, also a trap?

    Higbee: Focusing on the automation can become problematic if you forget about other things. Something like automation will distract you and you’ll end up having great turnaround times on new features that don’t mean anything to your customers.

    devopsy.kinsta.cloud: Doesn’t failing fast fix that?

    Higbee: Failing fast could help, assuming you have metrics in place that tell you that you’re failing in a way that matters.

    devopsy.kinsta.cloud: Could you please illustrate an example of isolated devs and ops that serve the given purpose better than combining them would?

    Higbee: I have a history of doing projects in the software development space where we had tight collaboration with everybody that’s involved in the process. Users, stakeholders, developers, testers, managers … you name whatever role, people worked closely together. I also have a history of examples where there was no collaboration at all.

    A lot of smaller projects end up in this latter bucket where you really just need one person to create a software system for a very specific purpose. They create the system, they deploy it, and then it just has to be supported at that point because it’s not going to be changed thereafter. It serves its purpose. People are happy with it. It’s probably never going to be changed ever again, so the separation there between dev and ops is perfectly acceptable and if you tried to bring together a whole team of people and synchronize them, it would just be a waste of time because the effort isn’t big enough to justify it.

    Another example would be pretty much any company that has ops staff but doesn’t do their own development. They outsource their development. Sure, there are situations where a project would necessitate everybody working closely together, but I’m sure there are a lot development efforts that happen in this regard where the dev team is outside the organization so there’s going to be functional separation. They developed software, it’s deployed, and maybe it’s never changed again, so there’s really no need for some tight-knit collaboration.

    devopsy.kinsta.cloud: How do recommend helping organizations produce rapid results such that they can rapidly move to a DevOps approach successfully?

    Higbee: First and foremost, I don’t extol any methodology, so I’m not a DevOps consultant. I’m not an agile coach. I think it’s ludicrous when people put these fads in front of their titles. The thing that I do that makes the difference, that produces rapid results is to make sure that we have a common goal, make sure it’s crystal clear and make sure everybody understands it. It’s like hiking to the top of a mountain. Everybody knows how far along we are. They can measure their own progress. They can flag things if we’re headed in the wrong direction like down the mountain. They can always see the goal. It’s always in sight.

    In another example, if you’ve ever gone to an Escape the Room Adventure, everybody is dumped into a room. It’s a group of people who oftentimes are strangers. About 10 people get dumped into a room and the goal in the duration of an hour is to get out of the room. The challenge is set up so it would be pretty difficult to get out in that hour, so if people don’t focus on that goal, then people aren’t getting out of the room.

    I’m not interested in how fast we solve each of the individual puzzles, so we don’t measure those things. We just get to work on getting out of the room. That’s my approach to doing business with people and that’s how people get rapid results. Because if you have a crystal clear goal, then you can go to the last hundred years of management philosophy to find the ways you need to get to your final destination. You aren’t worried about the right way of doing things; you’re just worried about the way that works for your specific situation.

  • Q&A: Full City Tech’s Higbee on Culture, Part 1

    Q&A: Full City Tech’s Higbee on Culture, Part 1

    Every day, more people are hopping on the DevOps magic bus, drinking the spiked punch and singing “Kumbaya.” I imagined everyone I interviewed would offer tales of instilling this undefeatable, undeniable, brand-spanking-new rapid development culture.

    It was refreshing to discover that I was mistaken. Apparently, DevOps is just another methodology for accelerating business success—one for software development.

    In part one of our latest Q&A, we chat with Wes Higbee, software developer, business consultant and president of Full City Tech Co. Higbee ably defends his stance on how special DevOps and instilling a DevOps culture is or isn’t in the grand scheme of things.

    devopsy.kinsta.cloud: So you say that DevOps is nothing new; that you have books collecting dust from the mid- to late-20th century describing similar organizational and management philosophies. What are some examples from those books you have collecting dust?

    Higbee: DevOps is the latest reincarnation of a lot of management philosophies that have been around for a long time. There are a couple of examples to reference. Alan Weiss, author of the book, “Best Laid Plans: Turning Strategy Into Action Throughout Your Organization,” wrote about functional organization at an insurance company that employed him. They had a functional department of typists and a functional department of people that would check the typist’s work.

    Underwriters sent requests to the typists to type up contracts. Typists would type up those contracts and then someone collected those for a separate group of checkers. The checkers would then check them and there was a lot of back and forth correcting errors. This led to a lot of inefficiencies.

    The solution was to take the checkers and pair them up with teams of typists. So a checker could review the work of several typists. That group of people worked together, and it turned out to be much more efficient, productive and effective.

    This is the heart of a cross-functional team, which is a fancy word for teamwork. This is one of the many ideas in the DevOps space, specifically taking developers and ops and putting these two groups of people together instead of having them as completely separate functional units inside the organization.

    Another reference is to pretty much everything Peter Drucker wrote. Specifically with regards to the people who are talking about focusing on the big picture. This is one thing that some people in the DevOps space are getting right. They’re talking about the big picture and not making optimizations to small parts of the picture that then jeopardized the whole, so optimize the whole. This comes from the work of Peter Drucker, “Managing for Results: Economic Tasks and Risk-Taking Decisions.”

    devopsy.kinsta.cloud: You say the danger is in the term DevOps itself; that as with agile, people slap a new name on what they’re already doing and think everything is better. If it’s not the terminology that needs to change to ensure a DevOps cultural transformation, then what is it?

    Higbee: I can’t tell you how many times I’ve encountered DevOps where devs and ops were still siloed. If you want to be successful—and this applies to any methodology—you have to start with real problems and real opportunities, because somebody else’s best practice is your own worst practice. If your customers are happy and your company is successful, you are seeing great profit margins and great growth, why would you change anything?

    Automated tests are something that people extol a lot in the DevOps space. You should have automation of your entire test suite and it should be part of your release process that’s also automated. But if you have no bugs in production, there’s no reason to go adding a bunch of tests to your release process.

    However, if your users routinely experience bugs in their production environment, then it would make sense to start talking about some testing and maybe even some automated testing during your release process. But don’t start with blindly writing tests of everything in the system. Start with the specific parts that are buggy, and you might be surprised how fast you can get those parts covered with some good tests. And then once you’ve done that, stop there.

  • Q&A: CNCF on Instilling a DevOps Culture, Part 2

    Q&A: CNCF on Instilling a DevOps Culture, Part 2

    In part one of this two-part series, devopsy.kinsta.cloud introduced the Cloud Native Computing Foundation (CNCF), a nonprofit organization with 49 members engaged in promoting the development of cloud native applications. Let’s continue with the CNCF’s thoughts on instilling a DevOps culture.

    devopsy.kinsta.cloud: Why do developers need the freedom to choose how they build software? What kinds and levels of freedom? Is this about approaches, development tools or something else?

    Brian Grant: All of the above: approaches, tools, languages … Different solutions work better for different workloads, scenarios, environments and people. Even new applications developed from scratch to be cloud-native aren’t typically developed in a vacuum—their developers may be familiar with particular languages or tools, the new application may need to interact with legacy applications; it may need to be built with and/or deployed onto existing infrastructure, etc. Often developers need to be able to adopt new technologies or approaches incrementally.

    devopsy.kinsta.cloud: How do you recommend providing this freedom to developers? How do you help provide it?

    Grant: Containers provide an ideal mechanism for providing this freedom, since they can be used to deploy both new and legacy applications, written in any language, built by any tool, into any environment. It’s a goal of the CNCF to foster an ecosystem of composable technologies, such as Kubernetes that facilitate the management of container-packaged applications.

    devopsy.kinsta.cloud: How does this align with instilling a DevOps culture?

    Grant: Because containers are small and fast, one application can be packed in each container image. Consequently, immutable container images can be created at build/release time rather than deployment time, since each application doesn’t need to be composed with the rest of the application stack nor integrated into the production infrastructure environment. This empowers developers to deliver deployable artifacts to operations.

    devopsy.kinsta.cloud: How is code reuse a need of the developer?

    Craig McLuckie: The vast majority of the actual code that is run in any given deployment is written by others. Only a tiny fraction of code in any given instance is actually written by the developer. The rest is everything from common libraries, to full OSS subsystems, to commercial software that systems, to adjacent software projects that provide some business functions. Developers need a common way to integrate with existing systems (when it makes sense) or to find and reuse existing code in a way that is controlled and operations-friendly.

    devopsy.kinsta.cloud: How do you recommend giving developers the ability to reuse code? How does your organization help with this?

    McLuckie: CNCF stands behind two technologies that are critical to code reuse. The first is the use of containers, which represent an intrinsically easy and predictable way to reuse even a relatively complex piece of software. The second is microservices-based architecture that make it easy to wire together systems and reuse existing services versus having to build their own.

    devopsy.kinsta.cloud: How does this align with instilling a DevOps culture?

    McLuckie: Containers make operations far more predictable and reduce possible avenues of error when deploying and updating systems. Rather than run potentially error prone imperative configuration systems to reuse code, containers are simple, lightweight and predictable, and reduce the potential for errors.

    Microservices allow for better operations specialization and create systems that are more intrinsically agile and easy to evolve. They allow for smaller teams that are focused on delivering a specific function versus having to align around large system boundaries. This creates a more productive and operationally viable environment.

    devopsy.kinsta.cloud: What is cloud-native? What does that mean?

    McLuckie: For CNCF, ‘cloud native’ is about a new pattern of application development that was pioneered by the internet companies, but that is equally applicable to developers and operators running more traditional workloads.

    We see three common attributes that make systems ‘cloud-native’:

    Container-packaged: Applications and processes are run in software containers as a unit of application deployment, which facilitates reproducibility, transparency and resource isolation. This improves overall developer experience, fosters code and component reuse, and simplifies operations.

    Dynamically managed: Applications are actively scheduled and managed. This radically improves machine efficiency and resource utilization while reducing the costs associated with maintenance and operations.

    Microservices-oriented: Applications are loosely coupled, with dependencies explicitly specified. This significantly increases the overall agility and maintainability of applications.

    Together, these three capabilities allow developers to build systems that are intrinsically agile and scale well. They significantly reduce the operational complexity of running an application, allowing operators to be more focused on application-level concerns and relying heavily on smart systems to do the operations heavy lifting.

  • Continuous Delivery Dependent on Who, What, Where

    Continuous Delivery Dependent on Who, What, Where

    Without the right people, positions and talents, it is difficult for a business to engender a DevOps culture. It is even more frustrating to facilitate a continuous delivery pipeline successfully producing quick bursts of innovative genius, without a full complement of qualified souls harmonizing on the same DevOps theme song as they toil away on the company’s next release.

    Some enterprises have a handle on the go-to people or hired guns they need to help spread a DevOps mindset—and exactly where to plug them into the organizational hierarchy. Other organizations have progressed to cloning these folks across Dev, Ops and the rest of the business. Some of those have laid some pipe as they extend a conduit from build to production. Those that are, by now, the “old guard” of DevOps have well-run pipelines brimming with fresh, robust software goodness.

    No one company has a “secret sauce” that works across all industries and organizations. How your company should connect the dots depends on who you ask. This time devopsy.kinsta.cloud has asked Renato Quedas, vice president of Solutions and Enablement at Micro Focus.

    Wrong People, Wrong Result

    The right people will produce significant changes to code, creating new value that is worthy of promotion to production. The right people will ensure that the release is ready, reliable and fit to go live anytime the business wants to give its blessing.

    “If a continuous feedback loop doesn’t exist between everyone involved in defining, building, testing, releasing and operating an application, the right people will not understand or feel enabled to pull the trigger in a release. Essentially that ‘any time’ will turn into ‘sometimes,’” says Quedas.

    The company must maintain business continuity/disaster recovery (BC/DR) while accelerating continuous delivery; if continuous delivery moves too fast, it will push BC/DR off the rails and into disaster. Testing is an important ingredient in ensuring BC/DR remains once the software reaches the end of the development pipeline. “Customers will not care if applications are delivered faster if they don’t perform or function properly on their platform and devices of choice. Not having the right people involved will turn continuous delivery into an unreliable minefield and create an uncertain application delivery pipeline, which businesses will never accept as part of any improvement initiative,” he says.

    The Right Stuff

    According to Quedas, the following positions or profiles are examples of people who would have the communications skills, ruthless negotiation tactics, sound decision-making processes and customer-first mentality—with little tolerance for poor quality—that are necessary to make a DevOps culture and continuous delivery work:

    • Product Managers who own responsibility for product quality can keep software product focus and development on track. They can communicate the business needs for the software, the capabilities it must have, and mediate the sometimes chaotic process that comes with continuous delivery. “Product Managers are used to prioritizing the work based on market trends, competitive landscape, customer requests and other internal/external pressures. Product Managers are accustomed to making decisions based on trade-offs, which helps CD focus in delivering the right outcomes to the business faster,” says Quedas.
    • QA Managers who readily communicate to test, development and operations teams as well as nontechnical folks about what is necessary to maintain software reliability. They also can bring development to a halt and send innovations back to the drawing board when validity and reliability are at risk.

    Creating the DevOps Culture

    A thriving DevOps culture will build a software delivery pipeline that can duplicate quality results—as any truly repeatable business endeavor should be able to do. To bring this culture to life, the company must demolish team and departmental silos to get everyone on the same page regarding what the organization must do and when it should do it. “Companies will need to streamline production via automation in order to make decisions faster,” says Quedas.

    A working, vibrant DevOps culture should give everyone a voice and ownership of a certain amount of control of their part of the process. “There is always pressure on information technology but there needs to be an understanding that it should be acceptable to put pressure back on the business,” says Quedas. “The business expectations need to be realistic or it won’t work. All sides need to be responsive.”

    A healthy DevOps culture and mindset includes a shared understanding that scope with value must be achievable in a reasonable amount of time. “The faster you demonstrate value, the easier it becomes to earn the right to continue in the journey and on to the next phase of development,” he says.

    Right People + Right Careers + Right Culture = Continuous Delivery

    Having the right people in positions such as the aforementioned product manager and QA Manager gives an organization the ability to hone its continuous delivery pipeline. The right culture ensures that everyone will follow these and other leaders and stakeholders so that each new innovation comes as quickly and smoothly as it can.

  • Q&A: CNCF on Instilling a DevOps Culture, Part 1

    Q&A: CNCF on Instilling a DevOps Culture, Part 1

    The Cloud Native Computing Foundation (CNCF) is a non-profit comprised of some 49 industry participants that have come together to drive development and adoption of cloud-native applications and services. The CNCF is uniting such giants as Google, IBM, Intel and Cisco Systems to distill a collection of container technologies that end-user companies deem praiseworthy to reach its goal.

    The CNCF intends its membership to represent end users (the CNCF website lists one end user, Goldman Sachs), cloud and container technologies, online and IT services, and academic institutions.

    On behalf of the CNCF, Craig McLuckie, its Governing Board chair, and Brian Grant, its Technical Oversight Committee representative, weigh in on leading the DevOps transformation and instilling a DevOps culture in this two-part Q&A.

    devopsy.kinsta.cloud: How is the CNCF specifically involved in leading the DevOps transformation by instilling the DevOps culture, in the industry or in member companies, for example?

    McLuckie: We believe that at the heart of the DevOps culture is the need to reduce the friction and, indeed, the barriers between teams that build an application and the teams that run an application. Developers learn to think about an application as a living service that evolves continuously and rapidly to meet the evolving business needs. Operations is there to deliver the tools and environment needed for them to successfully drive their application.

    devopsy.kinsta.cloud: Why do developers need an environment that is safe to change? What kind of change? Safe how?

    McLuckie: Safe change has many potential meanings: The first kind of “safe” is about creating deterministic behavior in operations. Does the system handle a change correctly every time? If I make a change to two systems, will they have the same state? How about to 1,000 systems? It’s important to focus on creating strong determinism by removing the moving parts in a production deployment.

    The second kind of “safe” is about being able to validate that a change is good—not just in pre-production environments, but in the actual production environment—with a simple and deterministic rollback. It is important to make it trivial to replicate environments, and offer a way to run a simple experiment in production (e.g. route 1 percent of my traffic to this new version) with the option to deterministically roll forward or backward without effort.

    A third kind of “safe” is about being able to ensure that every change is deliberate. One of the problems we often see in production systems is “configuration drift” that isn’t driven through any kind of formal process. This should be addressed by creating a strongly declarative toolset that makes every change deliberate and trackable.

    devopsy.kinsta.cloud: How do you recommend providing these things that developers need? How do you help provide them?

    McLuckie: There are multiple issues like data, security governance and applications that need to be addressed. Additionally, companies want to deliver apps with high velocity. How do you solve all of this? A vendor-neutral organization that can harmonize emerging technologies is important for facilitating cloud-native. Given the large number of players in the marketplace with competing approaches, having an open source way to solve this is also important.

    Grant: Cloud-native infrastructure enables self-service and “hands-off” operation, including provisioning, deployment, scaling, healing, discovery, monitoring and more, with relatively little marginal effort for specific applications. By supporting open source projects such as Kubernetes and Prometheus that provide such functionality, the CNCF hopes to democratize high-velocity application delivery, which was previously achievable mainly by web-scale companies.

    devopsy.kinsta.cloud: How does this align with instilling a DevOps culture?

    Grant: In a DevOps culture, operators are both partners and customers of the developers. Developers take responsibility for meeting operational requirements: security, reliability, availability, scalability, efficiency, actionable monitoring and logging output, necessary configurability, compatibility with the production environment, etc. Cloud-native infrastructure provides mechanisms developers and operators need to facilitate and capitalize on those capabilities.

    Stay tuned for part two of the CNCF interview.

  • Q&A: Quali’s Wrabetz on Security Testing

    Q&A: Quali’s Wrabetz on Security Testing

    DevOps is the perfect storm of automated testing and development that should make secure software commonplace. Yet, there are hurdles to testing for security. devopsy.kinsta.cloud asked Joan Wrabetz, CTO of Quali, about security, DevOps and her laundry list of those testing challenges.

    David Geer: Isn’t secure software important to DevOps?

    Wrabetz: DevOps is a practice of continuously deploying applications into production clouds. In order to automate the deployment of applications into production, it would seem essential for security testing to be a part of that automated process. In fact, when talking with one financial services firm, they said that they don’t deploy continuously into production because they are concerned that to do so would break the law. They are required by law to ensure that applications comply with their regulatory and privacy requirements before they are deployed into production. The only way to do that is to perform security testing. Thus, in order to achieve continuous deployment, they would have to integrate security testing into their DevOps flow.

    Geer: So, why isn’t security testing a core part of DevOps already?

    Wrabetz: The reasons are both technical and organizational. Organizationally, security testing is usually handled separately from development or product release-oriented testing, often by a completely separate group. As a result, it is not necessarily associated with the application release process.

    The technical reasons are related. Historically, security testing has involved reproducing the production infrastructure and network configuration as accurately as possible so that security vulnerabilities can be identified. Often, development and test teams working on DevOps do not invest in creating accurate reproductions of production infrastructure for their normal development and testing. So, they are not prepared to perform security testing as part of their normal DevOps flow.

    Security testing at many financial services firms exemplifies both of these issues. These firms typically outsource their security testing to one of a number of service firms who perform that testing on their own networks or in the cloud. The outsourcing of the security testing process is a big inhibitor to incorporating security testing into a continuous and automated DevOps process. In addition, when we asked these financial services firms how well their outsourced security testing represents their real production information technology infrastructure, they really have no idea. Clearly, any testing that does not match the production environment is not helping to reduce the security risk that the organization faces.

    Geer: What kinds of security testing do you feel is most relevant to DevOps?

    Wrabetz: The type of security testing that is most relevant to the DevOps flow is application compliance testing. For this type of testing, new applications are inserted into a network that emulates the information technology production network as accurately as possible. Testing with load, traffic and disruptive events is performed to determine whether the new application or upgrade might open up a vulnerability in the production environment. That includes privacy and data protection regulations, security requirements and any other business compliance standards that the organization is subject to. This testing is performed before pushing any new upgrade or application into production to ensure that compliance requirements will be maintained.

    Geer: What are some common problems with security testing as part of DevOps?

    Wrabetz: There are some common problems that make this type of testing uniquely difficult as part of a DevOps process, and in many cases, much harder to perform than other hardware and software testing. For example:

    • The tests must run in a configuration that exactly matches the current production configurations.
    • Security tests are systemwide tests, not tests of a single piece of hardware or software.
    • The tests must run with realistic traffic that simulates typical production traffic.
    • Security testing must allow automation of setup, configuration and testing processes in order for it to be incorporated into a DevOps flow.
    • Networks are large-scale and difficult to reproduce in a test.

    Security Testing Critical

    DevOps is in its infancy, but it won’t be forever. Now is the perfect time to surmount these obstacles, test for security and feed the results back into coding for security early and often.

  • Echidna Takes DevOps to E-Commerce Site Creation

    Echidna Takes DevOps to E-Commerce Site Creation

    The Echidna e-commerce firm installs and evolves e-commerce platforms, providing ongoing development so its clients can leverage e-commerce experiences to the satisfaction of their customers. “We apply carefully selected user experience technology, marketing and analytics abilities to our clients’ strategic goals to do this,” taking what it calls an “anti-Big Bang” approach to continuous deployment, says Mike Pierce, CTO of Echidna.

    “Traditional e-commerce deployments were often Big Bang deployments that people developed on the basis that they had to pressure the business leaders into feeling like they had only one chance to pack as much scope as possible into a large software development project. That approach voids any practical innovation,” says Pierce. With that mindset, it can take years to finish e-commerce sites, and e-commerce companies can go out of business by the time they actually finish such a site, since it would be far out of date by then.

    Echidna sees continuous deployment as one piece in a much larger agility play designed to ensure that businesses compete in digital economies, now and in the future. Continuous deployment is the ultimate goal of DevOps, an approach that enables the business to innovate fast enough to maintain the business’ sharp marketplace edge through acute, turn-on-a-dime competitive dexterity. “In order to do this, continuous deployment helps companies learn to develop high-quality software and deploy it on a rapid, reliable and repeatable schedule,” says Pierce.

    Continuous Deployment Timelines and Challenges

    Depending on the client, its needs and the features in the pipeline, Echidna deploys software to each e-commerce platform from monthly to daily, and at intervals in between those extremes. Echidna seeks to increase the degree of automation of each deployment over time. The challenge is that with so many different clients and platforms, Echidna must achieve its automation victories for each customer individually, solving similar and unique issues. “We are finding our greatest success using PaaS (platform-as-a-service) e-commerce platforms like Four51 because it eliminates a lot of the administrative overhead that is typical with deployments to on-premise platforms,” says Pierce.

    The development model Echidna follows to deploy e-commerce sites affects each software component, even though components deploy at different times. “Payment system modifications require significantly different testing—more testing—and we must deploy them much less often than other components. Marketing components don’t need as much regression testing as other software modules and so we can deploy them much more quickly,” he says.

    The most difficult software to move into continuous deployment in an e-commerce platform are the components that integrate deeply into enterprise systems. That is why Echidna advises business customers to use DevOps methodologies to deploy their enterprise production software at accelerated rates. When they do this, Echidna potentially can speed its deployment of the e-commerce platform components that are enmeshed with those production systems.

    The Four51 Path, Through Jitterbit

    Echidna connects Four51’s OrderCloud to the Jitterbit iPaaS integration server platform, a point-and-click integration tool. “This enables us to streamline further integrations and data exchanges with many of the disparate systems in an ecosystem,” says Pierce. Echidna sees increasing continuous deployment orchestration opportunities as more and more third-party application vendors become compatible with these kinds of integration tools.

    Four51 enables an ecosystem of connected digital services and applications where e-commerce uses numerous disparate systems that exchange data and facilitate work streams in the enterprise in question, Pierce says. “As these systems eliminate disparities and we align them on the central integration and deployment standards that we use, there will be increasing opportunities to introduce clients to lean development practices like continuous delivery and continuous deployment.”

    Conclusion

    Continuous deployment is miles apart from what information technology is used to, especially where manual change management and change control are concerned. But once Echidna exposes its customers to continuous deployment, their managers, C-levels and boards soon begin to witness the accelerated software innovation continuous deployment provides and how this makes information technology—and the business—more nimble, both technologically and competitively.