Category: DevOps Practice

  • COBOL Is Taking Heat, but These Other Legacy Languages Could Burn You

    COBOL Is Taking Heat, but These Other Legacy Languages Could Burn You

    COBOL is under fire, and as states such as New Jersey make headlines following vital system crashes that its citizens depend on—such as unemployment benefits—organizations are pointing fingers at the programming language as the source of their technological woes. However, while COBOL is a 50+-year-old programming language, there are still many use cases for it today. In fact, systems programmed in COBOL can modernize and continue to thrive in today’s business environment, even without transitioning to a new language or platform.

    While COBOL itself isn’t the problem child that most IT leaders and government entities say it is, there are a variety of other legacy languages—such as CA Gen, CA Telon and Natural—that pose a far greater threat to an organization’s overall functioning and long-term success. That said, there is still hope for organizations utilizing systems coded in legacy languages.

    Get on the CASE

    Two of the top languages that enterprises should be alert to—CA Gen and CA Telon—are Computer Aided Software Engineering (CASE) application development environments that were developed in the late 1970s and early 1980s and offer code generation, enabling the power of abstraction on the mainframe, essentially serving as an early stage ancestor of the “low-code” concept. This approach offered significantly more agility to developers at the time, but these programming languages have since fallen from the spotlight and, similar to COBOL’s limited pool of talent, have an even smaller pool of skilled developers that can assist with updating and maintaining these systems. This challenge traps many organizations in long-term contracts that they can’t seem to escape from.

    A major selling point of the CA Telon and CA Gen product lines was that its services were often offered within bundles—granting users with access to other mainframe utilities and services within a single licensing contract—but as time goes on and new technologies emerge, the advantages of this approach have fallen by the wayside. However, many organizations are trapped within expensive licensing fees and complicated bundling programs that make it difficult to sever ties with the legacy platform entirely.

    CA Gen and CA Telon act as generators of COBOL code, meaning that developers utilize tools in a language like CA-Gen but when it runs on the mainframe the system is running on COBOL. The COBOL within the mainframe then references CA-Gen and CA-Telon libraries, which makes it easy for developers to reference specific functions but ultimately produces code that is unable to be read by a human person. This creates significant complications for doing anything outside of the CASE environment—even tasks as simple as routine updates—but especially for digital transformation initiatives.

    While few organizations are purchasing CASE development solutions as new products, those that utilize these tools are constantly renegotiating the terms of their agreements to keep costs down, enable easy updates to their own unique systems and meet the emerging demands of today’s market. If they can successfully pull it off, they have another challenge: finding the talent who understands these obscure languages to implement necessary system changes. That said, the best solution for these organizations is to break away from these languages entirely—and this can be achieved relatively easily with automation through carefully selected modernization solutions.

    Why Natural Isn’t a Natural Choice

    In addition to CA-Gen and CA-Telon, one legacy language that all organizations should be alert to is Natural. Similar to the look and feel of COBOL but more abstract and powerful, Natural is a fourth-generation language (4GL) that was originally designed to enable agility and efficiency—but today, there are fewer than 100 companies utilizing this language. As a result, there is a scarce number of developers who can address and assist with any issues that arise within systems utilizing Natural. What’s more, most of these organizations don’t know they have a way out. This puts organizations at risk any time that a change to their operational systems is made, as the limited availability of specialized developers can make it especially difficult to achieve these updates.

    In most cases, Natural is utilized in tandem with the Adabas database, which can exacerbate the maintenance and extensibility issues that come from a shrinking talent pool—and when it comes to modernizing these environments, they’re often peppered with other programming languages such as COBOL and assembler, adding complexity to the job.

    Beyond COBOL: Choosing the Right Modernization Strategy

    For organizations looking to break away from obscure languages and mainframes, the best option for both their immediate and long-term goals is to pursue some form of modernization—and in most cases, the best result is to translate these languages into cloud-ready languages such as Java or C# via an automated refactoring initiative. Automated refactoring can also be utilized to consolidate these applications to a single language such as COBOL while remaining on the mainframe—although moving from an abstract language to a more procedural alternative can present challenges.

    By pursuing an automated refactoring strategy, organizations can move mountains of information, records and personalized code away from their mainframe and translate their system into a modern architecture. This allows organizations to untangle the “black box” of personalized code that exists within their systems and replace them with languages such as Java, C# or even COBOL, which unshackle companies from high licensing costs and have a much broader talent pool of developers. The resulting modernized system is easier to maintain, escapes high licensing costs and moves the business closer to cloud readiness, opening the door to modern development practices and tools. What’s more, in addition to saving significant funds by eliminating the costs associated with maintaining these legacy systems, an automated refactoring solution can help an organization to save years on its overall modernization process.

    While languages such as CA Gen, CA Telon and Natural are less common in the industry, these archaic languages can present significant challenges for businesses as they work to meet the demands of customers and partners. In the world of information technology, the only constant is disruption—and organizations need to get started on their modernization journey before it’s too late.

  • Twilio Expands Scope of Cloud Services Portfolio

    Twilio Expands Scope of Cloud Services Portfolio

    Twilio today at its online SIGNAL 2020 conference launched Twilio Video Web RTC Go, a free toolkit that makes it easier to embed video within an application, and exposed an Event Streams application programming interface (API) through which the management of streams of messaging and voice can be centralized using the Amazon Kinesis platform.

    At the same time, Twilio debuted Twilio Frontline, a mobile application that enables all incoming and outgoing customer conversations occurring over any channel or medium to be sent to a single application running on an IoS or Google Android device.

    Finally, Twilio also launched Microvisor, a turnkey connectivity and device management platform for developers building and updating internet of things (IoT) applications.

    Quinton Wall, senior director of developer marketing at Twilio, said Twilio Video Web RTC Go will play a critical role in enabling organizations to take control of digital business applications that now typically include a video stream. Rather than having to rely on a video service provided by Zoom, for example, an organization can provide an interactive video experience under their own brand by invoking application programming interfaces (APIs) that connect applications to Twilio Video running on the Amazon Web Services (AWS) cloud.

    In a similar vein, Twilio Frontline enables organizations to also take control of the communications channels that end customers are likely to employ. It may not be feasible to require every customer to employ a specific communications channel but at the very least all communications occurring over WhatsApp, SMS/MMS, webchat and other channels can be centralized, noted Wall. The Events Stream API, which will be expanded to include other processing engines other than Amazon Kinesis, enables developers to apply that same capability within their own applications.

    Twilio is also making it easier to build and deploy applications in IoT environments via a Microvisor platform through which Twilio provides constant monitoring of vulnerabilities and applies security patches to both IoT devices and any associated cloud components. Developers can also debug and update devices remotely and push out code updates as often as they see fit.

    Developers can also reuse any existing embedded code and develop IoT applications in the language and embedded OS of their choice using the TrustZone hardware isolation technology made available by Arm on processors that are widely employed in IoT devices.

    Collectively, Twilio is making a concerted effort to convince developers to programmatically invoke a range of cloud services that are exposed via an API. Rather than employing separate services for each video, audio, text or in the case of IoT application an IT management function, Wall said the goal is to enable developers to spend more time on writing code versus integrating external services.

    In general, the point where applications that don’t include embedded collaboration tools, including video, are considered antiquated has arrived. End users that have become accustomed to using services such as Zoom expect to be able to instantly communicate with the owner of that application or other end users. Twilio provides those capabilities in a way that doesn’t require developers to rely on a service such as Zoom that introduces yet another brand into the application environment, noted Wall.

    It’s too early to say just how capabilities such as video will be surfaced within applications. However, the one thing that is certain is video is now expected to be pervasive both inside and out of application environments.

  • Help Us Low-Code, You’re Our Only Hope

    Help Us Low-Code, You’re Our Only Hope

    Will low-code solve 2020’s most pressing issues?

    2020 is a challenging year. IT timelines are accelerating. The global pandemic pushes more online interaction, and digital transformations slated for years are shortening down to months or even days. As many departments face a nationwide developer shortage, companies have turned to low-code tools to keep pace.

    Naturally, interest in low-code is booming. Gartner estimates that by 2024, low-code will be behind at least 65% of application development initiatives. Today, low-code is already at the heart of many digital transformation initiatives—some vital to human life.

    I recently met with Ryan Ellis, SVP, Product Management, Platform at Salesforce. He shared how low-code is at the forefront of some very critical areas, such as COVID–19 testing, PPP loan processing, remote meal delivery, workplace safety and more. In this article, we’ll see how low-code tools are helping organizations quickly respond to these unprecedented issues.

    Low-Code Solves 5 Top Issues of 2020

    1. Meal Delivery

    Sun Basket uses low-code to scale omnichannel support rapidly

    What does digital transformation mean nowadays? It used to refer to new ways of meeting your customers online—i.e. brick and mortar business adopting eCommerce. Now, digital transformation is about providing omnichannel support for customers: phone-in, email, chat, social message and more, noted Ellis.

    Since the COVID-19 lockdown began, Sun Basket, a meal kit delivery platform, has experienced a massive increase in demand. To answer the surge in customer support, Sun Basket used a low-code platform to build a chatbot to enable users to track or edit their orders using natural language. Since investing in low-code, Sun Basket has increased the number of customer support cases handled simultaneously by 50%. This “ability to pivot to the surge in demand” is what gives low-code platforms an edge, he said.

    2. COVID-19 Testing

    UC Berkley adopts low-code to facilitate rapid COVID-19 testing

    To help underserved communities in the fight against COVID–19, researchers at UC Berkeley’s Innovative Genomics Institute recently rapidly transformed a CRISPR study lab into a pop-up COVID testing facility with the help of low-code tooling.

    The lab constructed a web portal for remote diagnosis and automated patient test scheduling. The system needed to catalog samples by barcode, synchronize the flow of information between researchers and doctors, and automatically deliver test results to patients—all while using regulatory-compliant code.

    This is one area where low-code shines: The researchers could quickly utilize pre-built components with the right data privacy measures to become operational in three weeks. “HIPPA compliance and security are built-in advantages,” said Ellis. IGI is an inspiring model for how science and technology can unite amid a global crisis.

    3. CARES Act And PPP

    Banks adopt low-code to automate loan approval processes

    With the passing of the CARES act, 70% of small U.S. businesses impacted by coronavirus quickly applied for federal loans. “Banks had to respond to a huge influx of demand and process these loans,” Ellis said. At many banks, the sheer number of applications became unmanageable.

    To handle the volume at Academy Bank, a savvy employee realized the need to automate some tedious, repetitive tasks. They used a low-code platform to build a tool for tracking application statuses and generating reports. This created an end-to-end loan approval process, which helped process more Paycheck Protection Program (PPP) applications, reduced manual repetition and improved visibility.

    Another financial service that relies heavily on low-code is nCino, a cloud-based bank operating system. nCino, which recently had one of the highest U.S. tech IPOs in recent times, built an entire automated business on top of Salesforce using a combination of some-code and cloud-first strategy.

    As banks behave more like tech companies, they need to evaluate their DevOps approach. “Leverage scale from low-code and cloud combined,” recommends Ellis. “Use the power of the cloud to push solutions to a broad base of customers all over the world.”

    4. Workplace Safety

    Low-code helps build corporate social distancing applications

    Many companies are considering their post-pandemic return to the workplace. Purpose-built low-code applications could be utilized to keep a log of fever checks and enable limited-exposure collaboration.

    Work.com, for example, offers employee health tracking, contract-tracing and workplace-planning applications to reduce risk and enforce social distancing guidelines. For example, elevator use could be optimized to avoid crowding a tight space, Ellis said.

    5. Distance Learning

    COVID has forced many schools online. Some, like Case Western, are getting creative with augmented reality HoloLens. Other schools are implementing things such as financial aid chatbots or updating their old ERP systems.

    Low-code could assist these distance learning initiatives or complement the EdTech platforms already in use. Over 100 universities worldwide already use low-code platforms within their online education curriculum.

    Digital Transformation 2.0 Is All About Automation

    Digital transformation initiatives have been brewing for years. But now, greater forces are driving immediate change—and this time, we’re all in on automation.

    The emphasis is now on optimizing and refining digital processes. “Utilizing low-code, businesses are taking processes that were very manual, error-prone, simplistic or repetitive, and automating it into a process that ensures consistency,” said Ellis.

    The above case studies demonstrate how low-code, in practice, is not only reshaping brick and mortal and traditional IT but ushering a new focus on automation and event-triggering for digital organizations, helping them adapt to turbulent times.

    The need to automate business processes pervades all companies. Ellis positively identifies an “uptick in low-code momentum these days across all customers.” For example, over two months, Salesforce noticed an increase from 160 million screen flow executions (automated workflows) to 200 million screen flows per month.

    Low-Code In Our Desperate Hour

    2020 is a challenging year. Now in the thick of a global pandemic, economies have been severely affected. However, citizen development technologies offer solutions. According to Ellis, low-code is truly “saving people—in terms of lives, businesses and livelihoods.”

    Of course, low-code platforms are no silver bullet and present a trade-off. Companies gain speed and agility, yet they move infrastructure dependencies to a third party. If not well-adopted or governed properly, low-code could enable shadow IT to proliferate. Ellis believes these concerns are negligible. “The value you bring is expertise and industry knowledge,” he said. The abstraction layer is worth it to “to move away from having to reinvent the wheel.”

    For Ellis, broader low-code adoption is on the horizon. “We’ve seen huge increases and inbound interest and use of low-code technologies. More and more people are opening up to it,” he said. Though low-code is certainly in vogue amid the pandemic, low-code tools leveraged today could be here to stay for the long-term.

  • Survey Surfaces High Reliance on DevOps to Build and Deploy APIs

    A survey of 13,586 IT professionals who work with application programming interfaces (APIs) published today by Postman, provider of an API development platform, finds best DevOps practices are now widely employed to both produce and consume APIs.

    The primary method through which teams working on APIs collaborate is by sharing URLs (42%). However, publishing API artifacts to GitLab, GitHub, Bitbucket or other repositories came in a close second at 40%, followed by publishing API documentation to an API portal (39%) and instant messaging (28%).

    When queried about change management practices specifically, Git repositories topped the list at 63%, followed by versioning APIs (59%), versioning server code (34.6%), versioning client code (27.8%) and semantic versioning (21%).

    Respondents said when it comes to deploying APIs, the most widely used option was continuous integration/continuous delivery (CI/CD) pipelines (53%).

    A total of 77% of respondents listed their functional area as engineering/development, followed by DevOps/API Ops at 34% and developer relations/evangelism (13%).

    Among DevOps practitioners that participated in the survey, Jenkins is the most widely employed platform (41%), followed by AWS DevOps (30.7%) and Azure DevOps (26.1%).

    Overall, the survey finds REST is still the dominant architectural style for APIs (93%), followed by webhooks (34%), SOAP (33%) and GraphQL (23%). JSON Schema is the dominant API specification (76%), followed by Swagger 2.0 (44%), OpenAPI 3.0 (28%) and GraphQL (23 %).

    When asked to rate the percentage of their organization’s development effort spent working with APIs, 41% said more than half of the effort is spent on APIs.

    Kin Lane, chief evangelist for Postman, said the survey also makes it clear that more organizations have adopted an API-first philosophy to application development. Over 60% of respondents rated themselves as 5 or better out of 10 in terms of embracing an API-first philosophy.

    Nearly half of respondents said investment of time and resources into APIs will increase over the next 12 months, while another third stated that investments into APIs will stay the same. Eighty-five percent said APIs are playing a significant role in their digital business transformation initiatives, while nearly a third (31%) also noted APIs played a role in their organization’s ability to respond to COVID-19 by, for example, enabling customer communications or remote work options.

    APIs appear to have become a lot more stable in recent years, with more than half of respondents reporting APIs do not break, stop working or materially change specification often enough to matter.

    When it comes to producing APIs, the No. 1 obstacle by a wide margin is lack of time, while the No. 1 obstacle cited for consuming API is lack of documentation.

    The four most important factors individuals consider before integration with an API are reliability (72%), security (71%), performance (71%) and documentation (70%).

    Looking to future technologies, respondents appear to be most interested in microservices (49%), Kubernetes (44%) and containers (42%). Given the cloud-native attributes of those technologies, it appears all but certain the number of APIs strewn across the extended enterprise is about to increase exponentially.

  • 3 Ways Traceability Boosts Decision-Making, Accountability

    3 Ways Traceability Boosts Decision-Making, Accountability

    Traceability can be a key tool to allow for a streamlined process of complex decision-making

    New software is being developed at an incredible pace to help make our lives easier. This doesn’t change the fact that humans are still held accountable for product development decisions, whether these are made with or without advanced analysis tools. To make informed choices, product development professionals need tools that allow them to see comprehensible information in real-time as change is happening, both within the team’s structure and throughout the system in which their product exists.

    Modern traceability makes it possible to both manage and respond to change in a systematic, auditable and confidence-enhancing way. Below, we will discuss three ways traceability has evolved to support key decision-makers in a number of industries.

    Modern traceability captures when you make a decision

    Decisions often have varying levels of durability. Sometimes, when you make a decision, you know then and there it’s final. Other times, you make what seems to be a minor choice and you end up dealing with the repercussions for years to come. With this level of uncertainty, it is essential to have mechanisms that allow you to see when decisions are made. As I discussed in a previous article, “5 Ways Traceability is Changing to Bolster the Remote Workforce,” this process can be compared to a map. By leading a team through every step of their processes, modern traceability helps product developers reach their goals without any surprises.

    Often, products are expected to be maintained for years. This is significantly more challenging when you can’t properly track where a ruling originated or a change was made. While the team may move quickly in the development process, the record should always live on to provide future context where it’s needed.

    Modern traceability provides people the context of what they’re working on as they go, not after the fact

    Rather than rely on sharing often lengthy and disparate documents or running time-consuming general meetings, traceability allows teams to streamline their collaboration. Mapping out work items, including owners and contributors, gives people a reason to care and to trace those items carefully. It helps everyone know why they’re there, what they are discussing and how to address it.

    Many smaller companies are fortunate to get by using Word documents and other legacy tools for their traceability measures. However, as these companies grow, so do the complexities. That’s why traceability has been evolving to account for the multi-dimensional nature of requirement, test and risk management. For a company that is seeing major growth to be truly successful, all related variables must work together continuously, at scale and across teams. Legacy tools simply do not provide the agile capabilities that modern traceability does.

    Traceability captures and tracks past decisions and allows users to access them

    Traceability is all about relationships. Each product in development has its own particular set of customers, stakeholders and internal team members associated with it. Therefore, traceability is only possible if these individuals can be accurately connected to the items for which they are responsible.

    Knowing who made a decision and what information they accessed is equally as important as the information itself. If you can’t quickly piece that together, your traceability is incomplete. The responsible thing to do is to ease the process by keeping useful records. It doesn’t need to be forced behavior if it’s captured along the way as a byproduct of doing your job.

    Overall, accountability is incomplete and past decisions can’t easily be seen, learned from or built upon without robust, modern traceability tools. It’s much harder to legitimately hold someone accountable when they’re working in the dark. However, when done correctly, traceability can be used as a key tool to support genuine liability and allow for a streamlined process of complex decision-making.

  • 5 Steps to Avoid Shadow IT Around Low-Code

    5 Steps to Avoid Shadow IT Around Low-Code

    Shadow IT is far more pervasive than most CIOs think. Cisco Systems estimates that a typical firm has 15 to 22 times more cloud applications than authorized by the IT department.

    While shadow IT solves problems in the short-term for a select few, undocumented software ultimately encourages tribal thinking and siloed departments. This can stunt reusability, slow down new developer onboarding and lead to insecure points of failure—all antitheses to a DevOps culture.

    Simultaneously, new low-code tools are emerging that promise to reduce the programming burden from developers and enable citizen developers to create business applications on their own. But what happens when advanced users know better? Perhaps they’d rather code a quick function in Python or use another framework they’re more familiar with. If not properly governed, low-code platforms could easily be circumvented and lead to shadow IT.

    As many tech leaders can attest to, enforcing companywide standards can be tricky. I recently chatted with Jay Jamison of Quick Base to see what tactics organizations should take to avoid shadow IT when introducing low-code tooling. Here are five general tips CIOs can apply to reap low-code benefits while curbing shadow IT.

    1. Earn Developer Trust

    Focus on integration and open backends to earn developer respect

    Want to win the hearts of developers? Focus on integration. Many engineers don’t care about a shiny user interface and would rather interact with data models programmatically. As I’ve covered before, open API access is the secret sauce for low-code platforms.

    Choose a low-code platform that provides high-performant and secure RESTful APIs that use JSON. With open access to data models and low-level mechanics, advanced developers will feel less inclined to subvert the platform. What’s great about HTTP APIs is that they’re agnostic, so developers can interact with them from whatever language or environment they’re comfortable with.

    2. Govern and Set Permissions

    Establish access management policies with fine-grained permissions

    To avoid the emergence of shadow IT, software leaders must apply governance over data models, users and application privileges. These permissions should be fine-grained, to the field level. To do so, managers require an application lifecycle management functionality to edit these permissions. Such a governance layer would grant “tremendous power and control to IT and the business,” said Jamison.

    On low-code governance patterns, Jamison notices companies often lean toward one of two extremes:

    1. IT-centric: IT is leading the software models and only IT users can make changes.
    2. Operation-centric: IT acts as a governance body and building is pushed into business domains.

    Selecting which model to use is often based on the organizational culture and individual team member capabilities, noted Jamison.

    3. Encourage Collaboration and Knowledge-Sharing

    Build an easy path from mock-up to production

    Companies adopt low-code tools because they require something “quick and adaptable.” Yet, getting different operating teams at the same table can be difficult. Without high-quality collaboration, low-code could introduce a bottleneck.

    “Many teams must come together,” Jamison said. “How will this be productized; how will the workflow be tracked?” Companies truly require an effective collaboration model if they are ever to regularize their data models and assign access roles.

    To get everyone on the same page, Jamison recommended starting with a mock-up everyone can use as a reference: “Create an online chart to map out workflows and stitch it together in a collaboration space.” Business strategies can create detailed plans, and then builders can transform this into a prototype.

    4. Document and Reuse

    Encourage departments to document processes and expose reusable tools

    If users are sharing documentation via Excel and email, you know something’s wrong. Undocumented software is unmanageable software. Jamison reinforced the need for a “control layer” to localize documentation and encourage platform-wide governance standards.

    “Like buildings in a cityscape, some apps are more significant than others,” Jamison said. CRM applications may be entirely purpose-built for niche settings, while others, such as a team registry application, could be reused across an entire corporation. Increasing tooling reusability, he noted, requires teaching and training of documentation and change management practices.

    5. Adopt a Platform-Based View

    Standardize on a single platform and embrace a low-code culture

    The more teams use low-code, the more they think on low-code terms. As teams become more proficient in low-code, their mindset becomes: “How can low-code solve that problem?”

    By adopting a platform-based view, low-code becomes a utility to drive consistent data flows and workflows. To achieve this, it’s probably best to standardize around a single, companywide low-code platform. Otherwise, you risk inviting more unstandardized practices.

    For example, Jamison described how a large-scale manufacturer operating hundreds of plants worldwide uses a low-code platform to audit all plants’ quality in real-time. Other traditional non-IT businesses with a global footprint could similarly return a net value from consolidation on a single low-code platform.

    Will Low-Code Increase Shadow IT?

    It’s difficult to enforce any new tool, and some users will inevitably circumvent standard processes. However, by demonstrating the benefits of shared collaboration and low-code creative potential, leaders could stem shadow IT and the adverse side effects therein.

    By talking their language and saving time, low-code tools could win developer faith and encourage platform use. In review, here are some other ways to avoid shadow IT side-stepping around low-code:

    • Show some-code: Win developer’s hearts by talking on their terms and opening up the hood.
    • Govern: Use a common data model and apply fine-grained security constraints.
    • Ignite discussion: Bring groups together for open knowledge forums.
    • Unite business and IT: Enable citizen developers to design mockups and builders to execute quickly.
    • Use the platform: With more low-code use comes more creative sparks.

    Ultimately, low-code won’t replace 100% of your programming needs (especially at software-oriented companies). Low-code should be viewed as a time-saver, not a talent replacer, Jamison said. Low-code enables developers to quickly assemble simple business applications, freeing them to devote more time to core competencies or advanced processes that are far more interesting, such as building machine learning models.

    Final Thoughts on Low-Code Transformation

    There are many forces driving the current low-code revolution. Major tech hubs lack developer talent and COVID-19 has accelerated digital disruption. In this economy, requirements for business processes are changing “by the hour,” said Jamison. “The awareness around low-code is increasing because the need for automation and more digital solutions is increasing.”

    As Jamison noted, many enterprises are undergoing a “dual-track digital transformation.” Companies are investing in expensive, broad-scope cloud technologies while still digitizing many manual processes. To Jamison, low-code is now imperative to meet both needs. Thus, it should be adopted with forethought for all potential use cases (and shadowy non-uses).

  • TechStrong TV: How strongDM Helps Fintech MANTL With Access Management

    TechStrong TV: How strongDM Helps Fintech MANTL With Access Management

    The fintech space is growing by leaps and bounds, as more consumers shift their financial transactions online for both convenience and necessity during the COVID-19 pandemic. MANTL is a fintech startup providing banks and credit unions with the technology they need to meet the demands of their customers who want to do their banking from anywhere and on any device.

    In this TechStrong TV interview, we speak with Ben Conant and James Qualls of MANTL and Elizabeth Zalman of strongDM to understand how strongDM’s technology is helping MANTL with access management for its backend systems to enable a strong user experience.

    Check out the interview below and follow along with the transcript to find out more.

    Transcript

    Alan Shimel: Hey, everyone. Thanks for joining us for another episode of TechStrong TV. In this segment, we’ve got three people, as you can see, and let me introduce them to you. I’m gonna start with the lady, Elizabeth, Liz Zalman of strongDM. Hey, Liz—welcome back.

    Elizabeth Zalman: Thanks, Alan. Great to be here.

    Shimel: Okay, and then we’ve got two guys. The guy up in space there is Ben Conant—he’s not really up in space, he’s in Tenafly, New Jersey, but hey, you know, with the magic of Zoom, he could be anywhere. Hey, Ben, welcome to TechStrong TV.

    Ben Conant: Hey, Alan, thanks for having me.

    Shimel: My pleasure. And then last but not least, we have James Qualls. James, I didn’t even ask you pre-hand—where are you from? Where are you coming in from today?

    James Qualls: I’m in Harrison, New Jersey.

    Shimel: Okay, so, we’ve got a bunch of Northeast—Liz is up in New York and I probably have the biggest New York accent of all of you guys, so, there you go.

    But anyway, so, we have not—I don’t think we’ve ever covered MANTL on our show or even in any of our DevOps.com, Security Boulevard, Container Journal, I don’t think we’ve covered MANTL before. So, let’s start off with a little bit about who MANTL is and then, as part of that, James and Ben, tell us what your roles are at MANTL.

    Conant: Sure. So, I’ll start. I’m Ben Conant, I’m the CTO and co-founder of MANTL, and MANTL is a fintech startup that provides banks and credit unions with the technology they need to meet the demands of modern customers. So, you can kinda think of us like Shopify, but instead of helping sort of medium-sized retailers have an online store without an engineering department, we do the same thing for American banks and credit unions.

    So, like, there’s actually 13,000 financial institutions in America, and 96% of those financial institutions are not Chase or Bank of America or SoFi that pump millions if not billions of dollars into technology. And these financial institutions really don’t have access to technology vendors that they like, want to work with, or provide them with what they need.

    So, that’s why MANTL exists. We are trying to reimagine what it can be to be a small bank, medium-sized bank in America or a credit union by providing technology that meets what they need.

    Shimel: Very cool. James, do you wanna—what’s your role at MANTL?

    Qualls: Yeah, so I’m the Director of Engineering here at MANTL and primarily responsible for infrastructure or liability engineering. I have the pleasure of architecting everything that MANTL runs on and we have the opportunity to run on a very modern cloud infrastructure. So, we use Kubernetes, everything’s configuration as code, running as Terraform. You know, we take advantage of as many cloud products as we can.

    Shimel: Excellent. And then Liz, we’ve had strongDM before, but for people who may not be familiar, give us the strongDM story.

    Zalman: The strongDM story is that the way people manage access to infrastructure has fundamentally changed since cloud. You’ve got an explosion of servers, database management systems, cloud providers. Kubernetes came into existence, and so doing it by hand or relying only on Active Directory, it doesn’t work anymore, and so strong creates a single control plane for you to both manage and audit the access of anybody who works for you—a contractor, an employee, service account to any infrastructure that is yours.

    Shimel: Cool. So, for purposes of setting up the discussion of how strongDM works with MANTL, Ben, I’m gonna ask to give us an example of some of this technology and apps that you guys are creating or helping maintain and power for your fintech clients, for your small and medium banks, credit unions, stuff like that.

    Conant: Yeah, so, the first product that we decided to develop for this market of sort of medium-sized banks and credit unions is a way for those banks to have a kind of open an account dot bank dot com website that was completely white-labeled and personalized to their brand, but really felt like signing up for Robinhood or Acorns or one of the sort of big fintechs that have a really slick sign up ________. Because a lot of these banks, you know, they don’t—in order to achieve the kinda deposit growth that they want to achieve, they have to go online, but they’re really suffering from not having a website that anyone would want to sign up for a bank account on, right? So, that was a very specific product, but there’s a huge market for it, so we decided to start with that.

    And then, you know, from a technical perspective, what does that mean? It means, for us, we have node microservices running in a Kubernetes cluster. We’re also talking to post press data stores in GCP, and then we need to control access and have firewalls and UAT environments for the banks to test stuff out using Cloudflare.

    So, you know, strongDM kind of ties into that, because as we grew and as we scaled, we needed to manage internal access to different pieces of our infrastructure, and we were actually thinking about building out our own little app to do this and have SQL access provisioning stored up in a database, but then, you know, through looking at vendors and finding strongDM, it seemed way better to sort of go with a company that was dedicated to providing that.

    Shimel: Very cool. Now, it would seem to me and, you know, I’m not the expert here, you guys are, but Liz, you know, when they’re setting up this sort of account opening app or online account opening app, that seems like something that strongDM would definitely be of much help to, no?

    Zalman: I think it was. I remember, James, I think, in our first conversation, you had very, I think the interesting thing about the MANTL team—whatever, it’s interesting about all my customers, but MANTL has a very clear point of view on the way that they want to do something in order to honor what their customers need. And so, James has always had a very clear point of view of, “We need something implemented like this, for these business reasons. I’ve tried on these other solutions. They don’t work for reasons X, Y, and Z, and so actually, MANTL is one of our most sort of forward-thinking, pushing the boundary customers that exist.

    I remember, James, when it came to setting up HTTP access for your internal employees and talking about header redaction and—I think it was Vault?

    Qualls: Vault.

    Zalman: The hosting of Vault, yeah. I was like, “Alright!”

    Shimel: Secrets.

    Zalman: “Gotta upgrade that.” [Laughter]

    Shimel: Yeah, no—Vault’s huge, right? I mean, you know, Vault is a little-known power—not little-known, but to those in the industry, it’s little-known, but outside of it? I mean, Vault may be HashiCorp’s biggest, you know, product, and they have some great products.

    But so, James, you know, Elizabeth’s kinda thrown you under the bus here, a little bit—it all comes to you. [Laughter] So, you know, how did the mission—you know, what else did you look at? What are the kinds of things, right, and how did you come on strongDM?

    Qualls: Yeah, so, I would say that we have, I would say the top three resources that we needed to gain access to—one, obviously, Vault, which, you know, it’s an HTTP based product, but you know, we could’ve gone with Cloudflare Access, ______ we could’ve gone with Google’s Identity-Aware Proxy. But the bottom line is that it’s much easier to manage and provision access if the system that you’re using is consolidated into one product, and I don’t want to have to manage access to these resources across three or four different products.

    So, we continued to look around and when we found strongDM, the first thing that we provisioned access for was databases. That’s something that no other product on the market does better than strongDM. strongDM covers a number of database protocols, we happen to be obsessed with Post Press. But strongDM supports things like Cassandra, things like BigQuery—so, you’re not necessarily limited in terms of protocol.

    There was an alpha that they were running where we got immediate access to the ability to not only proxy to databases through strongDM but also to proxy to HTTP based workloads. Vault happened to be the use case, and the e-mail that Liz is referring to is when I was talking about the audit logs and strongDM actually logging the Vault tokens in the early alpha and I requested that we have some kind of header redaction. And her team took our feedback immediately and within a very short period of time, they had implemented a fix or that. And to be honest, even in the alpha, the product was very usable. We were able to use it immediately and no one really knew that we were in an alpha, the product just worked. So, essentially, we were able to consolidate access to resources that we had actually been using private tunnel, a Pritunl, to run a VPN to those resources.

    After migrating to strongDM and after finally providing access to all of our resources, we use Post Press, Kubernetes, Vault, and there are some other internal resources that we provide access to all through strongDM, we were finally able to kill that VPN. So, we are an entirely identity-aware system at this point, purely because of strongDM. And then we have an added benefit when COVID hit, we were able to entirely go remote, because we didn’t have to scale a VPN. And this product is super high performance. We haven’t run into any bottlenecks, either, so you know, we’ve quickly grown over the last two years from 11 to almost 50 people now. And we’re all—all of us are presently remote, and all of us are using strongDM.

    Shimel: Very cool, very cool. And I don’t know the answer to this, and I hate asking questions I don’t know the answer to, but is there an application to use strongDM outside of MANTL’s own internal workforce for some of these banks, credit unions, you know, small to medium banks and credit unions as they—because, you know, there’s all kinds of financial regulations that you’ve gotta deal with here from q compliance standpoint and everything else. So, do you use strongDM beyond the internal MANTL team?

    Qualls: Liz and I have had a conversation about that, about potential applications for strongDM’s technology. I would say that probably MANTL’s biggest technical hurdle, when we’re integrating with a new bank is setting up network connectivity. And traditionally, that is, it’s by and large, it is usually an ________ VPN that we’re connecting to. And I see a potential application for strongDM there, although we haven’t attempted to see if it would work, or if one of our customers would actually be—or find that acceptable. [Laughter]

    Shimel: Ben, I’m curious what you think about that.

    Conant: Yeah, I think there is a huge market of banks that, you know, beyond just connecting to MANTL and allowing MANTL to operate with their sort of legacy systems, there is a huge market within banks where they have exactly the same problem, right? Like, people who are analysts at banks need to access lots of different data that’s all siloed in different data sources and different sort of network resources. We’ve heard a lot of our customers really struggling to set up or scale their own VPN solutions. And we’ve also worked with them to kind of, like, try and help mitigate those issues.

    But I think that strongDM is definitely a product that banks themselves should consider adopting, right? Because in the same way that it helps MANTL employees have highly compliant and secure and easy to manage access to the resources they need to do their jobs, banks have that problem but almost way larger than MANTL because they are 500 person organizations or 1,000 person organizations instead of a 50 person, you know, software company.

    Shimel: Yeah. I mean, because that was my thought on it, too, is these banks—I mean, the kinds of issues you’re talking about, James, that you guys are dealing with at MANTL and why you would use a strongDM kind of solution, you know, the small banks, community banks, credit unions—they got this, they have the same issues, right? Maybe some of them still are, you know, on legacy infrastructure, but if anything, I would imagine this whole COVID thing is accelerating their transformation there as well.

    Qualls: Absolutely. When COVID initially hit, you know, we had several banks, you know, just scrambling to scale their VPN infrastructure or bank—you know, some people were not actually even able to go beyond a certain point and they had to reconfigure their entire network topology as everyone was forced to go remote.

    In terms of, you know, in terms of how strongDM can be applied, I think that with COVID being a driving force behind that, I think that there’s definitely an opening for banks to start adopting newer technology, and strongDM is so easy to operate. It’s literally a don’t even think about it product. When we deploy it, we have the pleasure of deploying it on Kubernetes, so, we literally don’t even think about it. Scheduling and everything happen automatically. But strongDM is very well packaged. It’s a small binary, you give it a token, and you start it on any server you want. Yeah.

    Shimel: You know what, Liz, it sounds to me like James is giving you your new sales channel.

    Zalman: I actually just wrote that down. “Kubernetes—we literally don’t think about deploying it.” [Laughter]

    Qualls: Yeah. [Laughter]

    Zalman: No, customers have the best way—customers are the best from a product marketing perspective because they perceive the industry as they perceive it as a practitioner, and I’m—well, we’re practitioners, we’re also vendors. And so, their language is always the best. And they always know the right way to do things, I think.

    So, I can actually think of two product changes that James had requested. One was the header redaction in Vault, but the other thing was when strongDM deployed support for Terraform. The very first thing that James asked for was, “So, it’s great that you have a provider, but I need to be able to read in all of my configurations before I go and add strongDM to it, so when are you gonna support Terraform import?”

    And so, it’s very similar, right? You have practitioners, you have very forward thinkers for, like, “This is the right way to do things, and can you help me align to that?”

    Shimel: Excellent. Hey, Ben, I got a question for you. You know what? I love doing interviews with people like James and Elizabeth and we knock around things like, you know, Kubernetes and Terraform and Istio and maybe Cloudflare and stuff like that.

    But Ben, you know, you’re CTO and co-founder, you’re going to talk to these small community banks and credit unions, and even their IT departments, do they, you know, when you start bandying about stuff like this and this is—you know, does that resonate with them, or do they just say, “Hey, that’s why we have you here. You deal with that stuff. We’re not interested in what Kubernetes and strongDM is”?

    Conant: I think that there’s a very real sense in which the banks that are our customers are really purchasing as a service a large part of their company’s technology stack, right? So, if I’m the CTO or the CIO of the bank, you know, I’m trying to figure out, how do I move to the cloud in a way that is gonna make sense, right? And one big way to do that is to simply purchase MANTL. Because now your entire account opening stack is actually hosted on GCP, and you get all of the security benefits of that. And in the same way, you know, your—you want to be very involved with the decisions of, like, “Well, what technology is my vendor actually running?” Right?

    So, I think that the forward-thinking banks really do take it seriously and ask a lot of questions about our stack. I think maybe more importantly, you know, there is a very intense vendor due diligence process that even the smallest banks in America go through before allowing themselves to work with a technology vendor, right?

    And so, one thing that strongDM really helps us do is, you know, maintain a state of what we call perpetual compliance, right? So, we have an amazing Director of Security at MANTL, and we undergo SOC 2 audits, PCI audits, and other types of security audits every year. And, you know, having the capabilities that strongDM comes with out of the box allows us to, at a moment’s notice, produce the documentation that’s required for a SOC 2 audit for a lot of the stuff that we do. And that keeps our customers very happy. Because not only are they concerned with, “Oh, wow, you guys are on GCP, you’re using Kubernetes, you’re way ahead of the curve relative to the other vendors that we could go with,” but they also like the fact that we sort of breeze through these audits and are able to provide them with answers to the tough vendor due diligence questions that they do ask in the sales process.

    Shimel: Excellent stuff, man. Liz, I’m wondering if what Ben says he’s seeing kinda is parallel to what you guys see as well that, you know, especially dealing within the financial industry and fintech, there is sort of a high bar of due diligence in terms of is strongDM really secure, compliant, no back doors or—you know, I’m not creating a bigger problem by solving, trying to solve another problem.

    Zalman: Certainly. I think it’s twofold. So, companies get to a certain size where—and we’ve experienced this in fintech where they’ve rolled their own for some time, and then it gets to the threshold with respect to security RFIs they need to answer or they’ve hit a threshold in terms of employee base where they say, “Okay, I actually don’t wanna develop a core competency in identity and access management, and I want to offload that to a service provider.” Similar to how MANTL solves, essentially, a hosted web app and flow for credit unions to come into the 21st Century.

    And then, certainly, as part of any diligence process with us, we get asked, “What are your security—you know, what do you attest to? What are the results of your pen tests?” We did SOC 2 type 1 when we were eight people large, because it was such a core part of the sales process. I think customers want to be able to buy something that they have confidence in every aspect—that it provides the services, that it’s high availability and doesn’t go down and that it is as secure and people do what they say. So, certainly, that’s been a big part of the software since 2016.

    Shimel: Wow. That’s a while. Alright. Guys, we’re about out of time, but I realize MANTL, for people who want to get more information on a hot fintech startup out of Jersey there, where can they go on the web?

    Conant: Well, MANTL.com, M-A-N-T-L dot com, and you can actually see on James’ shirt it has the correct spelling of our name. But that—

    Shimel: Nice billboarding, James—good work.

    Conant: [Laughter] If we were both wearing that shirt, then it would’ve been a little bit weird, but I’m glad that it’s James and not both of us.

    Shimel: It wouldn’t go on the ISS anyway, so you know, you’re dressed appropriately, Ben—we’ll let it go.

    Conant: MANTL.com is a great place, there’s also been a number of industry publications about us, talking about how we’re helping in American Banker and others, helping community banks really become fintech companies, which we believe is their future, right? We think that all these fintech companies are trying to become banks. If you look at SoFi or you look at Simple Bank or any of these up and comers—really, you’ve got these small banks that, if they just had a platform to move and really innovate from a technology perspective, they are going to become the fintech, you know, [Cross talk] of the future.

    Shimel: It’s funny, they just, from both sides of the spectrum, converging on a common market is what you’ve got there. But Elizabeth, strongDM, for people who may not know, where do we go to get more information?

    Zalman: strongDM—S-T-R-O-N-G-D-M. Here at strongDM, the DM stands for Dragon Matrix. [Laughter]

    Shimel: Okay.

    Conant: I did not know that. That’s awesome.

    Zalman: Yeah, it came up at our last on-site—although, I gotta say, everybody wants T-shirts, and I’m like, “No, no, no. No T-shirts, I want a trucker hat.” But then that would look weird on camera—James’ shirt is much more effective on camera, so.

    Conant: [Laughter]

    Shimel: Yeah, no—the shirt works, James. Good work. Hey, guys, we’re gonna call it a wrap on this segment here for TechStrong TV. James Qualls, Ben Conant—did I mispronounce it? yeah okay—from MANTL, and of course, Liz Zalman, from strongDM. Thanks for joining us. This is Alan Shimel—we’ll be right back with our next guest.

  • How Logs Can Empower Your CI/CD Delivery Pipeline

    How Logs Can Empower Your CI/CD Delivery Pipeline

    Change is the currency of software success. This need to change and grow is the basis for continuous integration and continuous delivery (CI/CD). Each year, new industries embrace this philosophy of constant change, but without the necessary data underpinning their decisions, every deployment is a risk. When you enrich your software delivery with log data coupled with best practice log management, you mitigate this risk and enable rapid, safe change in your organization.

    Logs are often the most common source of information about an application’s behavior. They provide context as well as result, opening up far more information than a simple count metric will. Despite the immense insight that they can offer, organizations regularly overlook them. Many leave their logs in files on servers, far away from the CI/CD pipeline that needs them. It doesn’t have to be this way; with some best practices, every part of your business can collect, analyze and utilize the hidden knowledge within your logs.

    Add Life to Log Data With JSON

    Logging in an unstructured format dramatically increases the complexity of detecting patterns in your logs. By logging your application output in JSON, you open up the possibility of analysis of all of your logs. This gives you a top-down view of your entire system while still maintaining readability. This empowers your CI/CD pipeline by allowing you to query and filter your logs, which then enables you to focus in on the problem and precisely diagnose any unwanted side effects of your latest change.

    Create Actionable Alerts

    If alerts are defined and channeled correctly, have context and can be interpreted easily, they will be actionable, add context and offer greater value. It is difficult to provide context when a single metric exceeds a threshold, but log lines are more sophisticated. They can include additional information to provide context and allow us to pinpoint the source of the issue fast. This is an essential capability for a company embracing CI/CD.

    Prioritize Your Logs

    Structured logs often come attached with a severity, which indicates how seriously we should investigate an event. An INFO level log signals business as usual, but an ERROR demands immediate attention. Once your logs have these tags, you can make intelligent, automated decisions that will automatically respond to unwanted changes in your system.

    Benchmark Each Version to Understand ‘Normal’

    “Normal” is a complicated idea when working in a microservices architecture. It may be safe to ignore a minor slowdown of a single service, but an unfortunate combination of events can lead to disaster. Benchmarking enables us to see these disasters well before our users. Benchmarking is the act of recording what the normal behavior of an application is. After each deployment from your CI/CD pipeline, compare your new behavior with your previous benchmark. If something is out of the ordinary, logs provide the information you need to act decisively. They provide an outstanding baseline signal for your benchmark.

    Analyzed Logs Can Level up Your CI/CD Pipeline

    Building a CI/CD pipeline is not the most difficult part. Neither is the deployment of new features. In fact, the greatest challenge facing any organization wanting to deliver their changes via a CI/CD pipeline is observability. With a best-practice approach to the preparation, curation and analysis of application and system logs, we can overcome this challenge and confidently change at a pace that propels us to the forefront of our market.

  • DevOps World 2020: 5 Sessions to Put on Your Schedule

    DevOps World 2020: 5 Sessions to Put on Your Schedule

    DevOps World has established a reputation for delivering compelling, high-quality sessions that challenge and inform its audiences year after year, conference after conference. DevOps World 2020 is continuing that pattern, offering what could be the best program yet.

    The conference, to be held virtually this year Sept. 22-24, is rolling out more than 100 keynotes, workshops, panels, breakout sessions and “lightning talks.” Topics range from high-level themes such as promoting diversity in the workplace to on-the-ground technical discussions about automated testing in CI/CD pipelines.

    If you have unlimited time and boundless energy, you can experience it all, without leaving your home office. Just sign up for the conference and join at the appointed time to ensure that you take advantage of the back-and-forth discussions each session will enable.

    This year, you can do it all. Or, if you’re like most of us, you’ll probably want to cherry-pick the best of the best—the sessions that engage you the most and offer you the best perspective on issues that are important to you.

    For those who are looking for a great DevOps World experience, here are five sessions that you won’t want to miss.

    “Data-Driven DevOps: The Key to Improving Speed & Scale,” Kohsuke Kawaguchi, Launchable

    What better place to start than with one of the most respected, most influential programmers in the history of computing? Kohsuke Kawaguchi, founder of Jenkins and former CTO at CloudBees, will deliver a session focusing on how development teams can be more successful.

    Kawaguchi, who is now heading a new software testing startup called Launchable, will focus his talk on how a software delivery initiative can rise or fall based on the organization’s ability to use available data. Automation produces tons of data, but most of it gets thrown away. At the same time, leaders don’t have a good handle on how to make their delivery projects successful because they’re not mining the right insights from their data. Kawaguchi will draw on his own experiences and specific user stories to share how organizations can leverage their data to move at a faster speed and make developers feel great.

    “Automated Testing as a Part of Pipelines,” Rosalind Radcliffe, IBM

    Anybody who’s developed software for a long time knows just how important—and how big a headache—testing is. Without a dependable, effective, automated testing capability, teams end up spending way too much time documenting progress and re-doing work.

    Automated testing is critical but organizations often struggle to do it when they have a large number of back end applications running on the mainframe. Rosalind Radcliff, IBM’s chief architect for DevOps, will discuss actual use cases for how unit testing and automated regression testing can be added into software pipelines, even for those COBOL and PL/I applications organizations have running. This session is great for web and application developers and system architect designers. Radcliff will drill into test automation approaches and go over CI/CD and DevOps for classic tools and tech stacks.

    “Five Reasons Value Stream Thinking Is the Future of DevOps,” Steve Pereira, Visible

    DevOps World attendees come to the conference not just to hear about what teams are doing today. They also want to know what the standards are going to be in the future, so they can help their organizations get a leg up on the competition.

    One of those futuristic concepts that’s embedding itself into organizations’ DevOps strategies is “Value Stream Thinking.” The value stream, in and of itself, isn’t brand new. Corporate leaders starting with Henry Ford built processes around delivering value. But the emphasis on thinking, managing and mapping their DevOps strategies around the concept of a value stream is taking hold today at companies including Nationwide, Walmart, Barclays, BMW, Verizon, Liberty Mutual, AT&T, John Deere and Adidas.

    Steve Pereira, a consultant who describes himself on Twitter as a “value stream whisperer,” will present real-world transformation stories and results achieved with this new form of management.

    “Bad Code Kills: Five Essential Quality Gates You Need in Your CloudBees Core Pipeline,” Eric Mizell, OverOps

    You can have the greatest ideas, the greatest team and the most well-designed software in the world. But if your code isn’t up to the required standard, your whole software delivery initiative is going to struggle.

    Eric Mizell, vice president of solution engineering at development consulting firm OverOps, will discuss ways organizations can improve the quality of their code while continuing to deliver at a high velocity. The session will delve into common challenges and problems with current QA methods, then define and walk through each of the five quality gates teams can build into their pipelines: Dealing with static analysis, new errors, critical exceptions, resurface errors and unique error counts. Attendees can learn how to fill quality and testing gaps left by existing tools and processes and the open source resources available to build these gates into their own CI/CD tooling.

    “Successfully Implementing DevSecOps at Scale At a Large Financial Services Organization,” Nagaraju Kakarla, Fidelity Investments

    Many organizations with the size and scope of Fidelity Investments struggle to create a functional DevSecOps practice across the organization. They often get trapped into implementing waves of tools or end up doing it in a piecemeal fashion, leading to inefficiency and frustration.

    Nagaraju Kakarla, senior director and chapter leader at Fidelity, will present a session detailing how Fidelity scaled its continuous delivery component and integrated security functions earlier in the delivery process. He will share some challenges he faced as an engineer and as a leader in implementing DevOps and SRE at various large organizations.

    To take advantage of these and other sessions at DevOps World 2020, register today!

  • ServiceNow Extends Reach Into DevOps Ecosystem

    ServiceNow Extends Reach Into DevOps Ecosystem

    ServiceNow this week, as part of a massive Paris update to its core software-as-a-service (SaaS) platform for managing IT operations, has extended its DevOps integration efforts by adding connectors for Microsoft Azure DevOps (ADO) and Atlassian Jira platforms.

    Pablo Stern, senior vice president for IT workflow products at ServiceNow, said those connectors are the latest in a series of moves that ServiceNow is making available to bridge the divide between traditional IT service management (ITSM) and DevOps processes.

    ServiceNow this week also announced it adding a Process Automation Designer tool to its App Engine platform for building applications on the ServiceNow platform. IT teams will be able to use that tool to create workflows spanning ITSM and DevOps processes, noted Stern.

    In addition, ServiceNow announced enhancements to its Flow Designer and IntegrationHub tools to simplify the building of workflows, and unlocked a Source Control function across its application portfolio.

    Finally, Service Now is now bringing third-party data into the ServiceNow Service Graph and Configuration Management Database to make it easier to integrate ServiceNow tools with those from partners such as SolarWinds.

    Stern said the ServiceNow strategy is not to build a DevOps platform, but rather to foster interoperability across what has become a broad DevOps ecosystem. Most IT teams are now trying to create workflows that span traditional ticket-based approaches to manage IT processes and DevOps teams that routinely leverage programming tools to automate those processes, so the goal is to enable each organization to strike a balance between those approaches as they best see fit, said Stern, citing JP Morgan as a customer using ServiceNow connectors to DevOps platforms to achieve that goal.

    Very few IT organizations are relying on DevOps processes end to end to manage IT. Organizations have been managing IT using processes based on the ITIL framework for several decades. The challenge they face is ITIL-based processes are not often agile enough to support digital business initiatives that typically require rapid responses to any event, especially when the application involved generates revenue for the business. Every second of downtime or sub-optimal performance impacts the bottom line. Minimizing disruptions to those applications requires more reliance on both automated DevOps and DevSecOps processes.

    Naturally, the arguments over the merits of DevOps versus ITIL approaches to managing IT will remain unabated for years to come. Proponents of ITIL approaches often note there are applications that are so critical to the business that a more deliberate approach to rolling them out and updating them is an absolute requirement.

    Regardless of IT philosophy, it’s clear IT and DevOps processes will be employed side-by-side for many years come. The number of IT operations professionals who have the programming skills required to automate IT processes is still fairly limited compared to the total population of IT administrators. As such, IT teams might want to focus less on the debate itself in favor of determining where they are on the maturity curve when it comes to managing IT. Once that’s determined, it then becomes a lot easier to discern the next step in their IT journey.