devopsy.kinsta.cloud

Tag: devops

  • Steps on the Journey to DevOps

    Steps on the Journey to DevOps

    There was a time when people thought DevOps was a simple movement that didn’t need to be defined. I have always been told that big leaps won’t get you to your destination immediately, but little steps will get you there one day. For DevOps, the day has come, gaining mindshare among organizations and given importance like never before. However, certain companies are unable to understand what’s going on in their respective industries or how one they make their digital operations more productive.

    The Evolution of DevOps

    In 2007, Patrick Debois, a Belgian engineer, saw a growing friction between developer and operation teams. As a developer, he understood really well that development and operations can never go hand in hand, but he saw a golden opportunity to make the most of agile methodologies to manage infrastructure management processes in the similar way developers do. Initially being described as agile infrastructure, the concept was later coined as DevOps—a portmanteau of development and operations.

    A year later, in 2008, O’Reilly Media ran the very first Velocity conference, founded on the same insight: software developers and web operators never being on the same page even after sharing the same goals and language. The effort was meant to gather the tribe into one room, to talk with each other and share insights. It is said that much of the DevOps movement grew out of the Velocity conference.

    With the internet growing rapidly and sites such as Amazon, Google, Flickr, Facebook and YouTube becoming monstrous entities, those in IT witnessed seeing websites grow from one server to a dozen and even thousands. As a result, the business consequences of downtime, or of poor performance, skyrocketed.

    The need for DevOps grew with the growth of websites. And to blur the boundaries between development and operations, DevOps came into existence. Today DevOps became more than an idea. But unfortunately, the shift hasn’t been easy for everyone. DevOps has been focused too heavily on development and operations hasn’t enjoyed an equal share of improvements.

    5 Stages of DevOps Evolution

    Normalize the technology stack: The process starts from here. Several teams have started adopting true agile methods and are implementing proper version control as they seek to provide continuous integration and delivery. In fact, this is when redundant technologies are eliminated and the stack is normalized, which means practitioners must build on a standard set of technologies and place application configurations in version control.

    Standardize and reduce variability: As noted, development and operations teams are working toward one goal. This means teams must work to make sure their technology is further consolidated to a single OS or OS family, process complexity is reduced and early collaboration opportunities are explored. This is also when system configurations should be placed in version control and applications should be rearchitected to fit business needs.

    Expand DevOps practices: At this point, all the foundational pieces should be in place. This phase is a cleanup phase for discrepancies created by previous changes. For instance, the output of the application development team must match that of the delivery for true effectiveness. At this point, individual contributors can do work without approval from outside the team and changes can be made without as much wait time.

    Automate infrastructure delivery: At this stage, a company can help lessen the discrepancies between development output and operations delivery times. As a result, everyone gets closer to being one on the same page. And things such as security configurations, system configurations and provisioning are automated, which means the DevOps team can deliver faster and is better set up for future self-service.

    Provide self-service capabilities: DevOps deployments are created here. Developers can deploy testing environments on their own, and success metrics are clearly visible to the entire team.

    Helpful Resources:

    — Jaymin Vyas

  • Using Open Source Languages Effectively in the Enterprise

    Using Open Source Languages Effectively in the Enterprise

    Open source languages are part of almost every business these days. In fact, according to Opensource.com, open source will be the driving force behind a great number of technology innovations due to its pervasive use. From development to quality assurance (QA) to DevOps, all kinds of coders have embraced open source languages. In doing so, though, enterprises have given up easier-to-adopt, general-purpose languages in favor of more niche-oriented languages.

    Those who are enthusiastic about open source languages have been contributing to open source language projects and building versions of languages including Perl, JavaScript, Go, Tcl, Ruby and Python. There has been a massive shift in the adoption of open source languages and genesis of new ones in the last 20 years. Even large corporations such as Microsoft, Google and IBM contribute to open source projects that are hosted on GitHub, and Spotify, Dropbox and Reddit are among the big names that use Python.

    This mainstream adoption speaks to the enormous popularity of open source languages. This has brought about the proliferation of new languages co-existing with older languages, which creates more and more challenges for various stakeholders in the software development life cycle (SDLC)—and more tension.

    The tension between these two groups exists because of the gap between their needs. Addressing this tension requires a convergence of the needs of two specific stakeholder groups: coders and the enterprises for which they work. There are ways to fulfill what both coders and enterprises need, create better experiences for coders and make things easier for all stakeholders in the SDLC.

    Enterprises require security, control and compliance. Coders need speed, want to create and crave a frictionless environment. Roadblocks and restrictions need to be removed for coders while ensuring the needs of the enterprise are being met.

    Strength in Uniformity

    What would it look like if you could gain all of the potential benefits of open source languages while still fulfilling coder needs and resolving your enterprise requirements? What if uniform tooling could be provided across open source languages? And what if enterprises could use a single uniform tooling set regardless of open source language? It would solve needs for the coder and the requirements of the enterprise.

    Using uniform tooling, an enterprise’s open source languages can be compiled and installed; dependencies found and installed; and code written, tested and updated complete with security and license compliance needs being addressed. However, tooling currently isn’t uniform across open source languages. And the maturity and best practices of tooling wildly vary. Enterprises create a workaround by creating policies to mitigate for deficiencies in tooling. This workaround is sub-par because it happens too late in the SDLC after threats and issues are introduced into your code.

    Establishing a Single Ecosystem

    The quality that makes open source so useful—its openness—and its lack of controls makes it something of a digital wild west. Fewer restrictions enable faster innovation, but they come at the cost of quality and cohesion for the enterprise. Many of your installed libraries have holes and security threats. Enterprises are faced with time-consuming license reviews to ensure adherence to third-party license rules as well as internal policies restricting certain types of licenses. In addition, license reviews happen at one point in your code’s life cycle versus in an ongoing, automated way. Enterprises are burdened with high administrative overhead and stale information.

    However, there is a different scenario possible. What would it look like for a company to have a uniform and high-standard ecosystem for their package management, with no vendor lock-in, all based on open source? What if a company could be guaranteed the same quality and types of packages for every language they use? What if a company could easily have visibility for what is being used across all of their environments, from concept to development to testing to production? It would be easier for the coder and fulfill the requirements of the enterprise.

    The wild west quality of open source language ecosystems makes them somewhat unreliable; updates and deletions can occur. And there are different package management solutions with differing degrees of sophistication, complexities and required expertise to use. Today an enterprise can easily end up with multiple package management solutions and have different packages of the same open source programming language. There is no single or consistent source of truth. 

    Working with a technology provider is an effective way to mitigate your open source language risks and solve your coder need for speed. A provider can offer more than just support, inlcuding:

    • The appropriate licenses based on usage and policy requirements
    • The right packages for each specific application
    • The best notification and remediation based on Common Vulnerabilities and Exposures (CVE) security threats
    • The indemnification that fits, based on usage
    • The expertise to build you the language distros you need based on usage, environment, security and compliance requirements and applications.
    • The right builds, standardized for all of your teams and ready to go out of the box

    Thriving in the Wild

    Sometimes, using the “right tools” for the job involves coders building many programming languages in an environment. The resulting “polyglot” situation creates benefits as well as challenges. Better products are made, and products are shipped faster, but it’s difficult to build a core competency in a particular programming language. And it’s impossible to centralize support and difficult maintenance requirements.

    What’s needed is a single, uniform tooling set that can work across multiple languages. This makes open source languages easier to use and implement in the enterprise, addressing the needs of developers as well as those of the enterprise. Working with an expert advisor will help you not just survive but thrive in the wild and woolly world of open source.

    — Bart Copeland

  • Collaboration: The Glue for Test Automation Maturity

    Collaboration: The Glue for Test Automation Maturity

    QA’s role in DevOps continues to evolve in positive ways. In a recent survey on test automation conducted by QASymphony and TechWell, nearly one-third of organizations reported that among organizations where testers and developers share testing responsibilities, about a third of test cases are automated. This survey and others show that on average, fewer than 20 percent of organizations have adopted test automation.

    What we can discern here is that when testers and developers work closely together, organizations can achieve greater levels of test automation maturity. This is important, because test automation ties in closely with the primary goal of DevOps, which is to develop high quality software, rapidly and reliably. There’s no way to reach velocity at scale without test automation maturity—and QA teams play a critical role in getting there.

    Let’s break this down a bit further. How does developer-tester collaboration contribute to test automation maturity, and what exactly do we mean by that?

    Once developers complete unit testing, their job is to communicate the findings of those first level tests and code verifications to the testing team. If they don’t, testers are somewhat in the dark when determining what other tests—whether functional, API or performance—to build from there. Developers have the first line of vision on problem areas in their builds. It’s not enough for testers to look at a dashboard to see that a code branch has passed a test. Test automation requires speed and accuracy, so the more detailed information testers receive upfront the more successful they will be in writing automated tests and in determining manual testing needs.

    Developers should also automate unit-level testing. DevOps requires more tests, more often; everyone should take advantage of the efficiencies that test automation brings.

    Making Collaboration Work

    How to exchange information is less important than just doing it. There are lots of options these days: Developers and testers can share information back and forth within DevOps code repositories and pipeline tools systems, such as GitHub and Jenkins, or by using collaboration tools such as Slack. Geographically-dispersed teams may prefer web conferencing systems to facilitate live discussions on the fly.

    Team members can sit side by side, doing what’s called paired development. It’s powerful for testers to watch the code as developers write it so they can ask questions during the process. That gives the tester more knowledge about the product and in turn, developers understand the tester’s objectives. The point here is that achieving a high level of test automation coverage isn’t easy; testers and developers are both learning new skills and processes. Through frequent exchange of information, they can make progress faster and always be on the same page.

    Clearly though, with such low average test automation adoption levels, we need to work on closing the collaboration gap.  Here’s how I see the barriers:

    • Developers are fiercely independent. While that’s not a surprise, it requires incentives and education to help developers understand the need to get out of their silos. Developers must adopt test automation and talk to the testers. If they don’t adapt, they won’t last—at least that’s what a CIO told me recently.
    • Testers and developers have been in opposition for too long. It’s time to get rid of this “us versus them” mentality. Developers sometimes think testers are just trying to break their code and criticize their work. Testers sometimes complain that developers could care less about writing buggy software. This is a cultural problem and leadership can help resolve it by promoting software quality as an organization-wide priority for which everyone shares responsibility.
    • Testers and developers don’t always speak the same language. The thinking behind how developer writes code is not the same as how the tester writes automated scripts. Developers don’t consider all the scenarios a tester might when they write code. As a result, they may not write clear object identifiers in the code which help testers write scripts.

    Overcoming these barriers comes back to collaboration. Developers and testers need to find ways to understand each other’s world view. Begin by obtaining a joint understanding of completion. If developers and testers can agree on the release criteria, meaning that testers are comfortable with the level of automation in place to support future releases, it avoids a huge backlog of tests to automate later. Backlogs lead to delays and frustrations all around. Using a common development language for coding and test automation is also helpful; otherwise, it’s more difficult for both sides to speak the same language when working together. In the same vein, testers should have access to all the tools that developers use: source code repositories, continuous integration, project management and so on.

    We live in a digital world and have endless instant communication options, but even on a software development team, there’s nothing that replaces the value of a face-to-face conversation. It’s going to take more than one tactic to make collaboration work in your organization. Keeping the lines of communication open should be a central goal to increase test automation coverage and streamline the DevOps release process.

    — Ryan Yackel

  • The Hybrid Cloud and Why DevOps Teams Need Unified Stack Observability

    The Hybrid Cloud and Why DevOps Teams Need Unified Stack Observability

    The modern data center is constantly evolving to keep up with the demands of always-on, anywhere computing. Long gone are the days of monolithic, on-premises data centers. Today, the computing modus operandi is that of the hybrid cloud, which, according to Statista, will be worth close to $50 billion in 2018—just about double what it was in 2014—and will grow to almost $92 billion by 2021.

    As more and more DevOps and security teams are integrating hybrid cloud environments and serverless architectures, they need to gain visibility and insight into the increasingly distributed workloads provisioning and supporting their applications. Without a single pane of glass across their hybrid clouds, Dev, Sec and Ops teams cannot quickly discover vulnerabilities or identify and respond to attacks.

    The emerging best practice to the cross-cloud visibility conundrum is unified stack observability. Unified observability is the ability for Dev, Sec and Ops to share the same application-aware monitoring environment for vulnerabilities, threats or attacks across all workloads supporting their applications. The idea behind unified observability is that each team can look at the different stack layers as one—with an app-aware, single-pane, top-down view. For Dev teams, unified observability means that they can see and define all the third-party services connected to their applications; for Ops, it means they can see and monitor all workloads. And for Sec teams, it means the ability to set security policies for detecting and blocking attacks at each layer of the app stack by enforcing policies uniformly. There are a few recent trends accelerating the need for unified stack observability.

    The Accelerated Need for Unified Stack Observability

    Recent computing and application development trends are changing the way Dev, Sec and Ops teams develop and manage their distributed applications across hybrid cloud infrastructures. These changes include the increased use of third-party services, an overabundance of purpose-built security tools and the increasing need to address the shared cloud responsibility model, among others.

    An Uptick in Third-Party Code Use

    Third-party code increasingly is being used in apps and is one of the critical attack vectors exploited by hackers. SafeCode research notes that 78 percent of companies are running part or all of its operations on open source software, while 66 percent create software for customers built with open source. These stats have nearly doubled since 2010. The very practice of code-lifting, or pulling open source code from different repositories, which has enabled developers to share innovation and collaborate across architectures and levels, is turning to be one of the biggest attack vectors for hackers to exploit. Running on many different functions, open source applications and code borrowed from third-party services increasingly are becoming more vulnerable and therefore require a need for constant observability and monitoring.

    Even though such code is usually vigorously tested for vulnerabilities during the build and deploy stages, it can—and in some cases is—compromised in production. The global Magecart credit card skimming incident is an indicator of this: The hackers were able to infiltrate the third-party components and exploited them to gain credit card information, resulting in 800 e-commerce sites being compromised. To avoid such distributed vulnerabilities, Dev, Sec and Ops teams need to constantly index third-party functions and services, and scan for possible vulnerabilities or attacks. Such monitoring requires unified observability at the app code level.

    The Growing Overabundance of Purpose-Built Security Tools

    Increasingly enterprises are leveraging multiple cloud providers while still running their own data centers, either on-premises or as private clouds. A 2017 report from Forrester Research points to 89 percent of enterprises using at least two clouds, while 74 percent use three or more public clouds. Despite a wide industry effort lead by global leaders such as VMware to provide seamless cross-cloud orchestration and management, most clouds remain in their own environments with a set of purpose-built management and security tools.

    Then there is the traditional security approach, which can get in the way. According to Cybersecurity Insider’s “2018 Cloud Security Report,” only 16 percent of organizations believe the capabilities of traditional security tools are sufficient to manage security across the cloud. Eighty-four percent said traditional security solutions either don’t work at all in cloud environments or have only limited functionality, meaning that more tools with specific functionality must be integrated within the cloud. On-premises, private and public clouds remain siloed for most team, stressing an overtaxed security resources across organizations.

    Shared Responsibility Can Be a Shared Burden

    Even though the shared responsibility model has been well-documented, securing public cloud environments can be a burden to security and IT teams as their responsibilities continue to grow, while available talent is short to find. The traditional shared responsibility model assumes that the cloud vendor secures the hardware and software of the cloud itself, while the customer is responsible for the security of their assets within the cloud.

    With the shared responsibility model, most security teams are unsure about how to do their part. Gartner reports that through 2022, at least 95 percent of cloud security failures will be the customer’s fault. This can include anything from a failure to monitor to a failure to adequately secure the correct elements. This can also include customer misconfiguration, mismanaged credentials or insider theft. Additionally,  The “2017 IBM X-Force Report” noted a 424 percent jump in breaches related to misconfigured cloud infrastructure, largely due to human error. These gaps in security leave security teams with their organization, data and apps vulnerable.

    App-Aware Stack Observability: The New Modern Security Mandate

    The biggest distributed security blind spot facing modern Dev, Sec and Ops teams today is for them to monitor for vulnerabilities or attacks at each layer of the stack—at the application/third-party code-use level, their distributed workloads and the network each in isolation. Unified application-aware stack visibility and observability is becoming the only way to fully see and understand potential risks in today’s increasingly distributed environments, effectively addressing some of the biggest security challenges faced by modern Dev, Sec and Ops teams.

    — Gadi Naor

  • GitLab Joins Unicorn Club With $100m Raise

    GitLab Joins Unicorn Club With $100m Raise

    GitLabGitLab has become the latest member of the Unicorn club after announcing a $100m round of funding led by ICONIQ Capital.  This latest round, a series D brings the total capital raise for GitLab to $145m over 3 years. According to the company it also raised their market valuation to over the magical $1B mark.

    Some of GitLab’s success in raising this latest round of capital can be attributed  to a raising tide lifting all boats. Microsoft’s acquisition of GitHub for $7.5B continues to make ripples in the software developer tools space. But while they share Git in their name, GitLab is not just another Git or GitHub imitator. No, GitLab has a far more ambitious mission. They actually want to be a one stop shop for a complete end to end DevOps solution. Using GitLab you can replace 6 to 9 different DevOps related tools. Or at least that is the vision.

    I have always thought this was a tall order that would require a different way of building software to succeed. GitLab’s CEO Sid Sijbrandij thinks he has found this new method. Using open source, GitLab has an army of software contributors that donate their software to GitLab everyday. With monthly releases you can see the results of this philosophy with constant progress on all fronts at once.

    While Sid realizes that every component or area of GitLab may not be best of breed today, it is his vision that it will be. So what does $100m buy you today to recognize this vision? Well you can hear it right from the horse’s unicorn’s mouth. I sat down with Sid to discuss the raise, the future of GitLab and the market in general.

    I have had the pleasure of interviewing Sid before. He has some very good ideas on where the market is and where it is heading. Below is our conversation, enjoy!

    [wpvideo lvF0Ey0B]

    — Alan Shimel

  • CloudBees Extends CI/CD Scope, Reach

    CloudBees Extends CI/CD Scope, Reach

    CloudBees, at its DevOps World | Jenkins World 2018 conference this week, unveiled a broad strategy to extend the reach and scope of continuous integration/continuous deployment (CI/CD) platforms based on the open source Jenkins software.

    Company CEO Sascha Labourey said CloudBees Suite will provide the equivalent of a customer relationship management (CRM) application for software delivery. That approach will not only accelerate application development processes, but also provide application stakeholders across the enterprise with more visibility into DevOps processes. For example, business executives are demanding more visibility into DevOps processes as the organization begins to appreciate how dependent it is on the timely delivery of software, Labourey said.

    Rather than buying isolated components of a CI/CD platform, the CloudBees suite provides a single pane of glass through which all the elements of the platform can be managed. That capability is critical because it enables an organization to start with one element of a CI/CD platform that, over time, can be expanded frictionlessly as the organization becomes more comfortable with DevOps processes.

    Labourey said it’s clear the CI/CD platform is the hub around which those DevOps process revolve. The CloudBees Suite includes CloudBees Core to unify the management and governance of pipelines, which includes limited availability of the Kube CD for extending the CloudBees platform to Kubernetes clusters. In fact, Labourey noted that Kubernetes is rapidly emerging as the foundational element of a federated approach to CI/CD in the age of microservices.

    CloudBees also announced an alliance through which Lenovo will provide IT organizations a turnkey set of servers running instances of CloudBees Core on the Red Hat OpenShift application development platform. As DevOps continues to evolve, Labourey said, organizations want to reduce the amount of time it takes their IT teams to deploy the infrastructure required for a modern application development platform.

    Another core element of CloudBees Suite is CloudBees DevOptics, a software-as-a-service (SaaS) application that provides visibility and insights into value streams and operations as well as continuous reports on the four key DevOps metrics. CloudBees DevOptics will provide the raw data the company will rely on to apply artificial intelligence (AI) in the form of machine and deep learning algorithms to the CloudBees CI/CD platform, Labourey said.

    The two remaining core modules of CloudBees Suite are CloudBees CodeShip, which enables organizations to jump start projects using a CI/CD as a Service offering, and CloudBees Jenkins Support, which provides users of the open source Jenkins platform full support. CloudBees is also making support for instances of Jenkins available as a standalone subscription service.

    It’s clear that CloudBees is trying to extend the reach of its widely employed CI/CD environment not only to new platforms, but also to new users. As digital business processes continue to proliferate across the enterprise, there is now a lot more at stake whenever an application development project is delayed. While such delays may be inevitable, the degree to which organizations might be surprised by those delays can be reduced sharply when everyone in the organization is operating on the same DevOps page.

    — Mike Vizard

  • Fusing iPaaS with DevOps: Synergistic Potential of Continuous Zero Code Integration

    Fusing iPaaS with DevOps: Synergistic Potential of Continuous Zero Code Integration

    DevOps and integration platform as a service (iPaaS) are two dominant trends that together have cutting-edge use cases. Zero code integration could bring significant improvements to the DevOps life cycle, enabling efficient movement of applications from development to production. Implemented in the right way, both technologies can rewrite the way applications are developed.

    DevOps is a Paradigm Shift 

    DevOps is a development approach based on continuous development and continuous integration to unify development and operations. The power of this approach has enabled behemoths such as Amazon and Netflix to leapfrog other players in their domains and set up an entirely new industry.

    DevOps enables enterprises to manage the complete life cycle of applications from development to production in a faster and efficient way. In this way, teams can significantly accelerate the speed of application development life cycle.

    In traditional ways of software development, IT and operations teams work in silos. To develop something, development needs to build codes, package everything and hand them over to a release manager. In the next stage, the release manager delivers the developed code to a test environment, where QA teams test the code and report the errors back to the development team. Developers again make changes and process them to the test environment. Then, again, the project is handed over to the development environment. This process entails a lot of handovers across organizational departments. Teams show resistance to changes coming down the road. Red-tape administration and the overhead involved in these activities slow down the development process.

    All these hassles can be circumvented with the help of DevOps. In DevOps methodology, the development and testing teams work as one single team for the development of assets. The combined Development and Operations team achieves a balance to ensure that no efficiency is lost during the development process. All aspects of development testing, unit testing, integration testing, acceptance testing and production happen in a single environment. Small iterations are used to deliver usable products at the end of each sprint.

    iPaaS for Transforming Monolithic Applications 

    iPaaS is an ingenious innovation for breaking down silos and ensuring operational efficiency and agility. It is a modern-day approach to automating integration between applications and marshaling them in an order. iPaas platforms bundle connectors, maps, and transformations to enable zero code integrations that are thrice more durable and efficient than conventional integrations. This unique advantage enables business teams to build integrations and lets IT teams to assume the governance role.

    iPaaS solves a critical IT problem holding back organizations from leveraging their digital technologies: IT complexity. This problem was not present 15 or 20 years back, when enterprises had only three or four business systems. Enterprises used developer tools to combine applications and move data between source and target systems. They hand-coded connections for electronic data interchange. However, this method is not ideal for a scenario in which thousands of cloud and on-premises applications run in parallel. A lot of coding is required to build these integrations between these applications. Developers don’t have visibility to what other team members are building, and they create independent “islands of automation” and silos. Another relevant problem is updating integrations that remain in a constant flux.

    All these challenges can be circumvented if integration becomes codeless and manageable by everyone involved. iPaaS provides custom development kits and pre-built accelerators to build ground-to-cloud integrations or cloud-to-ground integrations in a hybrid environment. Without writing a single line of code, teams can build integrations and establish a smoother symbiosis between differentiated applications. Zero code integration of iPaaS helps on four fronts: Integrate, Design, Monitor and Govern.

    Harnessing the Vantage Point: Continuous Zero Code Integration

    Real-time integration resides at the heart of both iPaaS platforms and DevOps methodologies. IPaaS can further strengthen the continuous integration muscle of DevOps. Teams can fuse iPaaS with DevOps for a transformative technological advancement called continuous zero code integration. This step can take continuous integration even one step closer to continuous integration.

    IT and business teams can break down IT silos down the road and turbocharge the development process. Start-to-end integration between DevOps tools for other developers can fast forward the process of code development and code testing. A single intelligent mesh enables developers to integrate codes of developers and run them on a common build. Automated reporting ensures that developers are not stepping on each other’s code. Teams are able to make code updates or deliver things right into production hundreds or thousands of times a day.

    Version control integration can be updated with the command center to provide fully automated provisioning. It further can be used to automate the entire standing. Development can be connected seamlessly with the version control system for a shared development environment in which shippable products can be developed. Individuals get a better look at their assets while working on them. This allows automation to run automation test units for frictionless development.

    A microservices-based DevOps architecture is the most interesting part of DevOps and iPaaS fusion. This model has the potential to accelerate productivity significantly. Teams can deliver solutions much more quickly and access many business benefits downstream. Shorter build and deploy cycles improve deployability. It delivers the scalability to incorporate service-specific security, replication and monitoring in the build process.  Fault-tolerant systems can be set up in which an error in one service affects only that respective system and not all services. Developers don’t have to use brute computational force for releasing new versions of a service. Loosely coupled microservices provide a greater degree of elasticity in the cloud. New frameworks, libraries, data sources and modular components support dynamic discovery and binding.

    Any type of DevOps model can be driven by an iPaaS and their fusion should not be perceived as an enigma. Surely, there can be many more use cases out there. Melding the two for power and positive force is worth a closer look. This fusion can transcend application development in ways that are hard to imagine right now.

    — Jitesh Banga

  • DevSecOps: Critical in Building the Bank of the Future

    DevSecOps: Critical in Building the Bank of the Future

    It is no secret that change in a large organization can be difficult. This is often true within banking, an industry that often has sought predictably instead of agility in software delivery. However, with the right tools, guidance and teams, creating a bank that can be both complaint and responsive may be more attainable than initially it may seem. For a digital bank of the future to emerge from a heritage of independent application, information security and operations departments, an organization should embrace new technologies that can unify these groups and improve the ability to respond to change more quickly.

    Read on to learn why the inclusion of information security within DevOps practices can play a key role in establishing a bank of the future, and why it is important.

    Digital-Only Banks Gaining Ground

    One of the shifts in the distribution of banking products is the movement from primarily branch-based banks to digital-only banks. In fact, Citizens Financial Group launched a digital-only bank in July of 2018 to appeal to a growing number of digital-first customers. JPMorgan Chase also has a new digital banking offering, Finn, aimed at millennial customers.

    While digital-only is meant to simplify the end user experience, it complicates security because it increases the number of attack vectors within the digital channel. In effect, bank security is judged not by how well physical transactions are protected within the branch (think bank notes and checks), but how well digital transactions are protected over the internet. This can require a commitment of applying security controls while also honoring agile delivery practices. In turn, this developmental agility can be more effective when it is part of a responsive organization—one that is willing to adapt and adjust quickly, often requiring institutional culture change to an organization that is more transparent, open and ultimately innovative.

    Incorporating Security from the Get-Go

    To be more responsive while at the same time hardening security, adapting to DevSecOps methods is becoming important in the journey to be a bank of the future. DevOps should never be only about the development (Dev) build and operations (Ops) implementation—it should have security in the middle (Sec). Information security should play an integrated role in the full life cycle of apps. DevSecOps can remove the isolation and boundaries that previously existed between the security team and the rest of the organization, and it brings security smack dab into the conversation, rather than as a part of a deployment checklist. With service level expectations from release cycles going faster—from months to weeks or even days—integrating and automated security into the delivery process can be even more critical. In a DevSecOps application methodology, digital bank initiatives would build security into every touch point from the very start.

    How is Information Security Evolving in Banking?

    Banking, like all other aspects of our lives, seems, to be  transitioning to a smartphone transaction. Deposit and savings accounts can now be fully opened and closed through the digital channel. Information is exchanged digitally and the process is often painless. Information security becomes even more critical to help make  information safe and secure from potential fraudsters.  So while these types of transactions are often expected by consumers, it is important to have proper security measures in place and that can be fully automated and throughout the development process.

    The Organizational Change to Embrace the Future of Banking

    The future of banking will not happen exclusively just by changing technology and tools. It can often be successful when it is adapting organizational change at the same pace as technology and Agile best practices, such as DevSecOps, can also be applied to cultural transitions. To prepare organizations to be successful, there should be clear commitment by leadership across applications, operations and information security; otherwise, the change may never be fully absorbed into the organization. The bank of the future will be more likely to be successful if it functions as part of an ecosystem of interdependent and more securely connected people, processes and technology to have the structural support in place to successfully engage.

    — Eric Marts

  • OpsRamp Extends AIOps Visibility

    OpsRamp Extends AIOps Visibility

    OpsRamp has advanced its case for AIOps via a Fall update to its software-as-a-service (SaaS) applications that adds a Topology Explorer alongside an enhanced set of Service Maps.

    In addition, OpsRamp added a cloud database monitoring capabilities for relational databases deployed on public clouds including Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP).

    Mahesh Ramachandran, vice president of product management for OpsRamp, said the Topology Explorer makes it possible to automate network and application discovery to accelerate impact analysis and troubleshooting. An existing Service Map capability, meanwhile, has been enhanced to allow DevOps teams to invoke visualizations within an alert to better prioritize responses.

    OpsRamp has also added a pause capability for alerts, intended to be used during maintenance windows to prevent alert floods. Alert filters now include text-based search that, when combined with the AI Inference Engine, helps resolve issues faster. DevOps teams also can create policies to notify them of alert state changes.

    Finally, OpsRamp has added reporting tools that enable DevOps teams to determine not just the amount of resources being consumed on a public cloud, but also which public cloud or on-premises environment is generating the most trouble for the IT organization.

    In general, Ramachandran said most organizations have very little way in the way of tools that enable them to realistically compare how one platform performs over another when running specific classes of workloads. By leveraging the machine learning algorithms that OpsRamp includes in its SaaS applications, enough data becomes available to provide DevOps teams with actionable insights, he said.

    AI tools typically require access to massive amounts of data. By making available IT operations tools available as a cloud service, OpsRamp is trying to make it practical for DevOps teams to employ AI on both tactical and strategic levels without requiring an IT team to acquire special data science skills, Ramachandran said, adding such an approach also provides the added benefit of making it possible to holistically manage IT silos across multiple classes of infrastructure and applications.

    IT organizations are still in the early stages of coming to terms with AIOps and its potential impact on DevOps processes. Many of the manual processes that tend to inhibit widespread adoption of DevOps are clearly going to be automated. In fact, many of those tasks will be accomplished using voice commands that bots will be able to understand. In other cases, the bots will inform DevOps teams when an issue needs to be addressed long before they would otherwise be aware of it. Less clear is how job roles within DevOps teams will evolve as it becomes easier to manage applications and infrastructure comprehensively.

    Of course, the rate that transition will occur will vary widely by organization. But rather than debating the right approach to automation, it’s becoming increasingly apparent that many of those decisions will be made by machines. The unspoken assumption being made is that humans responsible for managing IT will be comfortable that the right decisions are being made on their behalf.

    — Mike Vizard

  • How to Fix ‘Dark Debt’ in Your IT Organization’s Culture

    How to Fix ‘Dark Debt’ in Your IT Organization’s Culture

    Poor decisions, bad metrics, lack of communication can accrue dark debt in any company

    Buying a low-quality microwave meal from a gas station, kicking a sock under the bed before guests arrive, jaywalking … We all take shortcuts. But unlike enterprise software delivery, these decisions rarely cause any collateral damage. The ramifications of taking shortcuts in IT, however, are much more serious.

    These decisions—i.e. “technical debt,” the “rework” debt owed after opting for a convenient solution instead of a better approach that takes longer—has implications on your company’s ability to grow and adapt to change. Fortunately, since the 1990s, when the term was coined by Ward Cunningham, we’ve learned how to identify and manage most forms of technical debt, understanding how to limit its impact and manage the interest.

    Your organizational culture can accrue debt, too. For example, a company that finds it easier to hire a homogeneous team up front might discover the costly cultural trade-off of hiring diversity later. When it comes to this “cultural debt,” we are much less disciplined. We often make decisions in the dark, without understanding how they are going to play out over the long term. “Dark debt” builds up over time and creates a toxic work environment in which people are not set up for success.

    Common issues indicating dark debt include:

    • Failures lead to finger-pointing.
    • Metrics incentivize undesirable behavior.
    • Lack of candor.

    Ways to Combat Dark Debt

    Call Out Psychological Safety Indicators

    Failures are inevitable, whether we are discussing power outages, data breaches or false missile alerts. A “safe to fail” mentality promotes learning and support adaptability. If employees don’t feel safe telling the boss bad news, the latter might be the last person to know what’s going on—not a good situation for a company working to disrupt an industry, or one expecting to stay listed on the Dow Jones.

    A Net Promoter Score-like survey can help identify areas where employees experience dissatisfaction. Here are some sample statements for your NPS survey that are based on Westrum’s organizational culture model as introduced in the “2014 State of DevOps Report.”

    • On my team, failure causes inquiry and not blame.
    • Our leadership is open to hearing bad news.
    • In my organization, failures are learning opportunities and messengers are not punished.
    • People on our team trust one another.

    The survey results will shine a light on the forces shaping your culture. Instead of finger-pointing, you can learn to address issues earlier and ask questions such as, “Why did it make sense for someone to do that at that time?”

    Measure Thoughtfully

    Tell me how you’ll measure me and I’ll tell you how I’ll behave. Gaming metrics are fairly easy to do, especially when an employee is incentivized to hit an unrealistic target or avoid embarrassment. Take activity metrics, for example (lines of code, number of bugs): These metrics focus on keeping people busy. But busyness does not equal business value delivered. People can be 100 percent utilized sprinting from meeting to meeting while making scant progress on business goals.

    Instead, consider metrics that reveal progress toward important business objectives or ones that help you make better business decisions. Flow metrics such as flow load, flow time, flow efficiency, and flow velocity reveal trends that measure four key areas: workload, speed, waste and throughput (respectively). These metrics are helpful in numerous ways, such as:

    • When others imply that things take too long, teams work inefficiently or people aren’t fully utilized, it’s useful to test their opinion against the data.
    • Having a balanced set of metrics allows you to see how changes in one area impact other areas. If the amount of work-in-progress (flow load) goes up, things will take longer to do (because of context switching and conflicting priorities), which results in slower speeds (longer flow times).

    Think about the behaviors that occur in your organization by how metrics incentivize people. What we measure impacts people because people value what is measured. Think twice before automatically defaulting to free and easy metrics available in your existing toolset.

    Build Social Capital

    Ideas start out flawed and incomplete. High levels of social capital, debate and discussion are the means by which ideas flourish. Social capital is what enables people to collaborate more effectively. The absence of social capital makes it impossible for people to speak openly (due to the lack of trust), resulting in withheld feedback and invisible work.

    Not much happens without discussion. When we engage in debate, our capacity to see each other’s perspectives is realized. TED talk speaker Margaret Heffernan’s insight on social capital is compelling: “Time compounds social capital.” The longer teams work together, the more trust, helpfulness and candor they accrue. Longstanding teams, therefore, benefit from increased productivity and reduced risk.

    Unlike the costly and time-consuming transitions observed in project-managed work, where people disband after dumping their work on the operations team before starting another project, organizing teams around a product allows the people who developed, tested and delivered the functionality to not only stay in their area of expertise, but also grow and gain from social capital.

    — Dominica DeGrandis