devopsy.kinsta.cloud

Author: Louis Vistola

  • Connecting Your Cloud & DevOps Tools to Enable CI/CD

    Connecting Your Cloud & DevOps Tools to Enable CI/CD

    An effective continuous integration/continuous delivery (CI/CD) pipeline must integrate cloud and DevOps tools seamlessly to ensure the build, compile, test and release of applications is accomplished efficiently and without friction.

    Application architectures, internal processes and personal preferences mean organizations and teams set up the CI/CD pipeline differently, resulting in a diversity of infrastructure and tooling throughout software delivery pipelines. While innovation demands the freedom to use whatever is needed to deliver applications, the resulting diversity can be a significant integration challenge. What’s needed is a platform built for DevOps that seamlessly connects a DevOps ecosystem and CI/CD pipeline tools.

    There are two ways to do this.

    One is to use REST APIs. REST is a popular choice due to its simplicity and the fact that it builds upon existing systems and features of HTTP. It avoids the need to create new standards, frameworks and technologies. Another benefit of using an integrated approach based on REST is that many developers are familiar with key elements of the REST architecture, such as Secure Sockets Layer (SSL) encryption and Transport Layer Security (TLS). Additionally, REST is language-independent. As such, developers can employ any language that uses HTTP when creating REST APIs so developers can choose technologies they are familiar with and that best suit their needs.

    Another approach is to look for a platform that supports out-of-the-box integration with commonly used cloud and DevOps tools. Naturally, each company and DevOps team uses a specific set of tools. But it is safe to assume there are widely used tools that should be included in any list. Some useful plug-in integrations to look for include ones for Amazon S3, Azure DevOps, Bamboo, CircleCI, Github, Jenkins, TeamCity, Terraform and more.

    Integration benefits and how to amplify them

    Integrating cloud and DevOps tools into a CI/CD pipeline offers several benefits.

    Built-in integration will help developers get the most value out of the pipeline. For example, out-of-the-box integration can be leveraged to help provide more automated testing and a quicker time to release. Why? If tools are not integrated, developers need to go through a slow, manual process to deploy, configure and optimize tools for their development environment. That is a time-consuming process. Those involved in the process lose time on their real work. Lacking integration, multiple teams throughout an organization may waste time doing the same processes to get the tools to work. And perhaps most troubling, manually integrating tools can introduce errors and potential security vulnerabilities.

    Highly-integrated tools help encourage collaboration. In many companies, it is easy for different projects and different development teams to fall into siloed patterns of work. Different groups will use different tools. Having cloud and DevOps tools integrated into the CI/CD pipeline allows a de facto standardization of processes. And from that, best practices typically emerge from the familiarity of using the same tools. Smart companies will take advantage of the lessons learned and be sure to share that institutional knowledge amongst teams. Once a basic level of sharing is achieved, different groups are likely to work directly querying each other and working together to get the most out of the tools.

    What’s needed?

    To realize the benefits of integrating cloud and DevOps tools in a CI/CD pipeline requires a suitable platform. The right platform should effortlessly deliver the infrastructure and application resources to the development teams.

    A solution that provides self-serve access to infrastructure needs more than simply provisioning automation. A solution must help a company monitor resources utilization and costs. And specifically provide a way to tie costs back to business units, projects and individual developers.

    With such an offering, a company gets the full benefits that arise when cloud and DevOps tools are integrated into a CI/CD pipeline.

  • Enabling Developers with Infrastructure Automation

    Enabling Developers with Infrastructure Automation

    Enabling developers with infrastructure automation

    Being first to market with new and improved applications and services is how successful organizations grow and differentiate business offerings.  Continuous software delivery means everything is fluid and constantly changed to enable the speed and agility required to ensure applications deliver on increasingly higher consumer satisfaction expectations.

    Everything released and rolled out needs to be evaluated and updated frequently with new capabilities and features added as requirements change. DevOps, continuous integration and delivery practices play a growing part in the streamlining of software pipelines and accelerating software releases, however for enterprises, the infrastructure supporting the pipelines remains siloed, provisioned (potentially, multiple times) at each stage of the software delivery pipeline.

    While infrastructure remains a skill intensive, stage based practice, there is no greater inhibitor to pipeline execution speed and agility and the requirement to scale DevOps to meet the needs of the business.

    The result is that IT organizations cannot keep pace and struggle to provide development and testing teams with the infrastructure environments they need, while maintaining security, compliance and efficiency. To help achieve speed and control, many DevOps-focused companies are turning to infrastructure automation. The goal of such an approach is to give DevOps teams access to the environments they need in a timely manner, all while maintaining control and oversight of costs and governance.

    The way businesses operate today, DevOps needs production environments available immediately. Developers cannot afford to wait days or longer when starting new projects. Some businesses try to address the challenge by building automated scripts to set up environments.

    The problem is that automated scripts are typically custom, hand-coded and require increasingly scarce skills. When changes to environments are needed, custom scripts need the same high level of skills to understand, evaluate, change, and test environments taking crucial time from pipeline execution.

    DevOps teams need instant access to infrastructure. The solution must be, application pipeline centric, automated, on-demand and self-service. It must be a platform that not only delivers and manages environments throughout the pipelines but integrate with existing infrastructure tools, subsuming what they create to ensure enterprises meet the demands of the business without inhibiting application software development innovation.

    The role of immutable infrastructure

    Enabling developers with infrastructure automation is the concept of reusable automation and immutable infrastructure. The concept for immutable infrastructure is to build the infrastructure components to an exact set of specifications. If a change to a specification is required, then a whole new set of infrastructure is provisioned based on the updated requirements, and the previous infrastructure is taken out of service as it is obsolete.

    How does that play into automating infrastructure for DevOps teams? Continuous delivery uses automation to make deployments routine and repeatable. To achieve this, delivery is built on the concept of versioning and automation to push deployments to variable environments on a development pipeline.

    Immutable infrastructure comes into play in that IT-heavy infrastructure chores, such as implementing updates and installing patches, are eliminated. If an infrastructure element needs an update or must be replaced, the old elements are replaced by new entities that have already made these changes and been incorporated, tested and verified.

    Bottom line: Reusable immutable building blocks make it easier to deliver the resources developers really need.

    Addressing governance

    Infrastructure automation should be used to ensure governance. However, traditional cloud governance approaches are limited by features, with infrastructure automation achieved through complex scripting. This results in the automation becoming a major maintenance challenge and a time commitment. With multi-cloud environments, complexity multiples.

    The smart approach is to focus infrastructure automation on managing governance across common cloud resources.  Putting infrastructure automation in the hands of DevOps practitioners does not mean relinquishing governance control, but ensures corporate compliance is maintained and enforced with policies controlling usage, security and cost. This prevents cloud sprawl without slowing down development cycles.

    Summing up

    Meeting todays growing DevOps infrastructure needs is a time-consuming task for IT organizations. It slows down every stage of the application development pipeline. The need is for a solution that provides developers and DevOps practitioners access to the cloud infrastructure and application environments they need on demand. This is accomplished using an Environments as a service (EaaS) platform, accessible through a GUI portal, command line interface and existing CI/CD tools.

    A modern environment automation platform must be designed for all team members of a DevOps practice to automate the requesting, provisioning and lifecycle management of infrastructure environments. The platform must integrate without impacting efficiency or limiting innovation. It must deliver environments on-demand with self-service automation capabilities and oversee and enforce governance compliance. This solution is the answer to organizations seeking to streamline the continuous software delivery pipeline for application development, testing and release to production.

     

  • Understanding and Controlling Cloud Costs

    Understanding and Controlling Cloud Costs

    The widescale migration to cloud and the embracement of cloud-native application architectures has been a blessing to developers and those responsible for deploying and maintaining modern applications. Container-based apps allow fast changes compared to monolithic apps. And cloud services let DevOps teams quickly launch instances and acquire resources for all stages of their work. The downside is that cloud costs are often overlooked.

    What many businesses are finding is that cloud costs are out of control. And worse, there is very little insight into how much is being spent. Instances fired up for one project may never be deleted. Increasing capacity to support a burst in compute demand may never be throttled back. Lack of detailed billing and the complexity of distributed applications can simply mask costs from stakeholders. Looking at monthly bills from multiple providers offers no easy way to tie costs back to specific projects, applications or business units.

    Cloud costs on the rise globally

    Overspending on cloud is easy to accomplish and quite common, especially if activities are not measured and tracked.

    A report from the Cloud Native Computing Foundation (CNCF), in association with the FinOps Foundation, put the rise in spending into perspective. It found that spending on Kubernetes, the primary means of orchestrating containerized applications, was up year-to-year from 2020 to 2021. Of those surveyed, 67 percent reported an increase of 20 percent or more over the last 12 months, and 10 percent spent more than $1m per month on their deployments.

    Most startling, less than 25 percent of those surveyed said they could accurately predict how much they’d spend to within 5 percent of the actual cost. And over 20 percent stated that they did not predict their cloud bill. That’s no way to run an operation.

    Other recent studies have found comparable results. For example, Gartner predicts that almost two in three infrastructure and operations leaders through 2024 will experience public cloud migration cost overruns.

    Best practices for managing cloud costs

    What’s needed to rein in spending is visibility into cloud expenses and governance policies to control those expenses. In particular, organizations must gain visibility into their cloud resource usage to control costs. Organizations looking to do such things need a solution that helps them:

    Tie expenses back to the business: Businesses need a way to understand how much money they are paying for different environments and connect cloud costs back to business applications. This will allow a business to allocate resources more accurately for future needs.

    Spot trends: While some tools can provide visibility into cloud expenses, most only do so at the infrastructure level. What’s needed is the ability to view from a single-pane-of-glass view the cloud expenses at the environment level. A suitable solution should act as the cloud orchestrator, so users can apply run-time policies beforehand to manage costs, track environment changes by the business characteristics, and dig deep to identify the purpose, owner, size, project, and more to identify usage trends.

    Optimize efficiency: When trying to optimize the use of cloud resources, identifying changes that will provide the most value is almost impossible with traditional billing reports. The reason is because the cost of using cloud resources varies depending on the environment’s scale and frequency. What’s needed is a way to track the use of each aspect of cloud use and the related costs. This information allows a business to focus on optimizing cost without impacting performance or operations.

    Achieving results

    Controlling cloud costs is challenging and requires deep insights into resource usage. An ideal solution provides real-time information in a single viewing plane that can eliminate uncertainty and avoid over-spending. To work, such a solution must make use of certain capabilities, including the ability to automatically tag and de-commission resources, embed policy management and provide Role-Based Access Control to resources. And most critically, any cloud cost management solution must be implemented in such a way as to not slow down application development and delivery.

     

     

  • Beyond IaaS: The Benefits of Using EaaS

    Beyond IaaS: The Benefits of Using EaaS

    Beyond IaaS: The Benefits of Using EaaS

    The market for cloud infrastructure is growing at a rapid clip. Driving factors include IT’s need to cut costs, provide more services, respond faster to business needs, and enable innovation and digital transformation. For many years, Infrastructure-as-a-Service (IaaS) offerings have been both the first and most used cloud services consumed by businesses. But increasingly, more is needed. That has opened the door for Environment-as-a-Service (EaaS), what some call IaaS Plus.

    To put the demand for such services into perspective, consider cloud spending. While most organizations were already executing on their cloud migration strategies pre-COVID, the pandemic was a serious wake-up call for those lagging behind. Gartner predicts public cloud services global spending will grow to $332.3B this year, up from $270B in 2020. Gartner also anticipates that by 2024 almost half of all IT spending on software, system infrastructure, and process outsourcing will have pivoted from traditional solutions to the cloud.

    Within those numbers, the IaaS segment is predicted to have the largest growth (percentage-wise) over the next few years. The IaaS market will nearly double from roughly $60,000 in 2020 to about $107,000 in 2022. Looking beyond next year, ResearchAndMarkets.com predicts the IaaS market will reach $74.63 billion in 2025 with a compound annual growth rate (CAGR) of 13.8%.

    Why the big jump? Cloud-based service models can provide significant financial advantages for businesses, allowing them to quickly access new functionalities without requiring heavy upfront investments. Cloud services rotate some capital expenditure costs into operational costs, with infrastructure-as-a-service (IaaS) enabling organizations to move fundamental storage and networking functions to the cloud and away from on-premises hardware.

    Enter EaaS

    One of the greatest fundamental changes companies have encountered in the last few years is that business demands for new applications and services have rapidly grown, causing a need to accelerate application development.

    And most importantly, development is no longer a one-time effort, and applications must continuously be patched, updated, and enhanced. Each change or addition requires one or more development environments, plus infrastructure and applications for performance testing, quality assurance and deployment.

    That’s where EaaS helps. EaaS extends the capabilities and benefits of IaaS into the development environment. It offers the infrastructure, applications, and data that DevOps teams need to develop, deploy and maintain their applications.

    An ideal EaaS solution will offer certain features to increase the efficiency of the DevOps staff, reduce costs and help businesses maintain control over fast-paced development environments.

    For example, a well-suited EaaS would use automation to configure servers for a specific application. It would be a self-service offering that integrated with normal DevOps workflows, tools, and methodologies. For example, a business might look for an EaaS offering that gives users a choice in how they access the services. That might include access via a web portal, command-line interface, or directly through a developer’s CI/CD tools.

    That last capability is particularly important today, given the way applications are developed and maintained. An EaaS must integrate into the existing DevOps ecosystem and CI/CD pipeline to support today’s demand for complete, ready-to-run environments delivered on demand. The way to ensure this is to look for an EaaS provider that supports out-of-the-box plugins and an extensive REST API for common CI/CD and DevOps tools.

    One additional issue that businesses need to address is cost control. Costs can quickly add up with the use of cloud services being so easy and with some providers offering self-service options. In many situations, cloud service users have no insights into their cloud spending until after the monthly bill arrives. And even then, there is often no granular view into where the costs were incurred.

    What’s needed is an EaaS offering that incorporates cloud cost management capabilities that are implemented in such a way as to not slow down application development and delivery. In particular, cost visibility and control are required but cannot be implemented in a way that adds friction to the process. Many cost management approaches fail in this regard. A good EaaS solution will provide the needed visibility and control while not hindering development and deployment.

    Last word

    Modern applications development must be based on CI/CD to deliver new applications, services and updates in a timely manner to match fast-changing business opportunities and requirements.

    While IaaS platforms satisfy many of the core infrastructure requirements, EaaS complements these capabilities by offering the complete environments delivered on-demand needed for DevOps to work. EaaS also offers tight integration into DevOps workflows and CI/CD pipelines.

     

  • Securing Open-Source Apps

    Securing Open-Source Apps

    Securing Open-Source Apps with API Scans and Observability

    Businesses building applications have always made great use of open-source software. The move to cloud-native applications, use of low code development, and embracement of composable architectures have made open-source use even more pervasive. As such, businesses need a way to ensure the composite apps are reliable, perform well, and meet robust security requirements.

    Testing and ensuring that open-source applications have these enterprise-class characteristics requires a shift in thinking. Traditional tools often only evaluate characteristics of specific programs, or produce so much telemetric, log, and traces that it is hard to spot problems. Compounding the difficulties with traditional approaches is the fact that modern apps, which are frequently built by connecting loosely-coupled elements, mask interdependencies that might lead to performance or security problems.

    Start with API scanning and discovery

    Modern businesses are operating in an API-centric world. Whether using microservices, composable elements, or low-code platforms, open-source applications are built by exposing data and processes to other elements via APIs.

    One problem is that in the past, APIs were designed so that applications and application components could communicate with each other over a secure private (company-owned and managed) network. Now, the trend is to make company-built applications and services available via APIs to third parties (e.g., customers, partners, and suppliers) over public networks.

    Subsequently, the APIs offer outsiders a direct entry point to a company’s applications and data if they are not properly secured. While it may seem a straightforward matter to simply secure all APIs, problems can easily arise. First, companies are likely dealing with hundreds or thousands of different APIs, all developed over many years. Each was built with a specific purpose in mind, and each was secured for the environment in which it was intended to run. Using the same APIs in open environments on public networks opens up different security issues.

    The best way to keep on top of matters is for a company to first know what it is dealing with. That can be accomplished by using tools or a solution that discovers all APIs in a complex distributed application. Next, developers need insights into how those APIs are working. They must routinely conduct API scans at every stage of an open-source application’s development lifecycle. So, a suitable solution will both help discover APIs, know when they change and provide insights into which services talk to each other.

    Gaining insights into API interactions

    Developers and IT staff have relied on monitoring for years as a common way to deal with application performance and security problems. However, monitoring can sometimes be a bit passive for modern business environments.

    When employing monitoring, DevOps collects and analyzes data to keep applications running smoothly. Monitoring basically finds problems after they have happened. In a typical setup, a monitoring solution would send alerts when a problem has occurred. For example, when an application passes a low-performance threshold or there is suspicious activity such as a large volume of data being shared.

    In contrast, observability uses logs, metrics, and distributed traces collected by monitoring an application to help understand what is happening. Observability focuses more on understanding why problems occur versus monitoring, which identifies the existence of the problems.

    Observability solutions most often use sophisticated analytics and, in some cases, artificial intelligence to make inferences about the data they collect. Ideally, an observability solution for open-source applications would help explain what’s happening within the system and offer actionable insights to maintain or improve the application’s performance or security.

    Another prong in the arsenal to help bulletproof open-source applications is traceability, a critical part of observability. And specifically, what’s needed is distributed tracing, which is a way to monitor applications. Distributed tracing lets DevOps follow the results of transactions or requests as they work their way through an application’s elements.

    An ideal solution would enable distributed tracing that collects all application communications across API gateways, load balancers, proxies, Kubernetes clusters, service meshes, VM’s, and containers, and within application components too. Such capabilities can significantly reduce the time IT or DevOps spends troubleshooting issues within applications and systems.

    An API-centric approach to open-source app security

    In today’s API-centric open-source application world, developers need to understand how the various elements of their applications work together. From a security aspect, that means focusing on the APIs themselves. What’s needed is a solution that helps a developer discover all APIs, including shadow APIs. Such information can help developers be aware of changes and risks. And ideally, developers will use this knowledge of the treats in their applications to improve code and API security.

  • Dependencies in Cloud-Native Apps can Amplify Risks

    Dependencies in Cloud-Native Apps can Amplify Risks

    Hidden Dependencies in Cloud-Native Apps can Amplify Security Risks

    Cloud-native applications and modern development practices result in applications that are highly distributed and loosely coupled. In many cases, organizations have no control over or little insight into the different elements and software entities they use in their applications. The result often is hidden dependencies that can impact performance and add to security risks.

    The New York Times noted an example of the consequences of hidden dependencies. The article cited the work of researchers who observed that the quality of weather forecasting models declined as air travel dropped off during the pandemic. One might easily conjecture there was a physical cause and effect. Jet engine exhaust includes water vapor, soot, carbon dioxide, unburned fuel, and several oxides. Perhaps the diminished amounts of these particulates due to fewer commercial flights had some impact on lower stratospheric dynamics.

    It turns out that was not the case. The article reported that researchers found “that when a short-term forecasting model received less data on temperature, wind, and humidity from aircraft, the forecast skill (the difference between predicted meteorological conditions and what actually occurred) was worse.”

    Atmospheric observations made by instruments on commercial and cargo planes are “among the most important data used in forecasting models,” according to the article. The measurements are transmitted in real-time to forecasting organizations around the world, including the National Weather Service.

    The pandemic resulted in fewer flights. So, there was less or no data. A prediction’s degradation due to this data disruption not only impacted the primary forecasting application but had many downstream implications. For example, these short-term forecasts are used by many industries (logistics, agriculture, entertainment, public safety, and more) to make business decisions. Hence, the degradation of performance in that one application due to previously unknown dependencies could propagate to third-party apps that simply relied on the output of this one app as input for theirs. In a sense, this particular dependency (fewer observations leading to poorer quality forecasts) becomes yet a different hidden dependency in many other applications.

    Security implications

    As this example illustrates, small changes in complex systems can have unexpected application performance impacts. They also can impart unintended security problems.

    At the heart of the issue is the fact that today’s cloud-native applications are complex systems. And security in cloud-native systems can be impacted by small changes.

    It might be something as simple as reusing a component whose original permission setting gave a development team broad access to certain data for testing purposes only. With software component reuse being quite common, that point may be forgotten at some point, and the code might be made available to other groups. Those groups may just want anonymized records in that database or a subset of data that did not include records that should remain private. Use of that code in a larger cloud-native app for such purposes would not necessarily expose the data. But someone might discover the mistake later and exploit it.

    Another aspect of cloud-native application security is that many modular elements are linked together via APIs and microservice calls to form a larger application. Those software elements (be they open-source or commercial) often have security flaws.

    A report last year by the Laboratory for Innovation Science at Harvard and The Linux Foundation highlighted this issue, noting the need for an “understanding and addressing of the security complexities in the modern-day software supply chain.” With frequent reuse of components, even if a known vulnerability is taken care of with a patch, the problem may not be eliminated. Someone needs to know that piece of code is in a distributed cloud-native app, that there is a patch for the vulnerability, and that the patch was applied.

    Any small flaws like this can have a larger negative effect on the security of the entire cloud-native system.

    What’s needed

    The reliance on open source and third-party code in cloud-native applications requires that security be entrenched throughout an application’s lifecycle. It is no longer enough to test for vulnerabilities after the fact. Third-party or open-source code used in any one element of a larger application might be changed at any time. If a vulnerability is introduced, a developer might not know of it.

    The inter-dependent nature of discrete code working together in a vast cloud-native app thus requires a new take on security. The constant refreshing, updating, and replacement of applications dictate that security must be an integral part of the entire lifecycle of an application. As such, companies must bring security into the application lifecycle just as DevOps does for development and deployment.

    To find these impacts, stay ahead of them, and react effectively and efficiently when they show up, developers and companies need a deep understanding of the context of their systems and how all the parts work together. Just as the pandemic-related downturn in commercial flights impacted the accuracy of forecasting models, so to can a seemingly unrelated (or unknows) security flaw in one part of a cloud-native application impact the entire application.

    To avoid such problems, a DevSecOps approach is increasingly needed to find weaknesses and vulnerabilities due to hidden dependencies in today’s applications comprised of many interconnected parts.

  • The Move Away from Monolithic Application Development

    The Move Away from Monolithic Application Development

    Shifting from monolithic application development

    Businesses need agility to deliver better services, meet changing requirements, and seize new opportunities as they arise. At the heart of many efforts are applications based on modern development strategies and techniques. Specifically, many businesses are moving away from monolithic applications of the past that are hard to modify and take a long time to bring to market.

    Why the shift and why now? Over 80% of organizations expect to compete mainly based on customer experience (CX). As a result, businesses in the most competitive markets like retail, banking, insurance, financial services, and travel/hospitality cannot afford to wait months or years to release new services, applications, or features.

    The bottom line is that software development teams are under pressure to deliver more of everything (new applications, enhanced features, more access options) in shorter time frames. A widely cited past industry study put the issues into perspective. Leading companies routinely perform multiple deployments daily. By comparison, low performers reported deploying only once a month at best. (At the extreme end of the spectrum, companies like Amazon and Google do deployments thousands of times a day.)

    Monolithic application development does not work in this fast-paced environment. A simple change in an existing application, such as incorporating a new dataset, adding new features in a front-end app, or using a different analytics method, requires that the entire application be revised, retested, and redeployed. That all takes time. Lots of time.

    A better approach is to use modern applications development methodologies. In particular, there is a shift underway to using cloud-native architectures based on loosely connected microservices and elements.

    A cloud-native approach is particularly well-suited for modern applications for several reasons. For example, a cloud-native approach helps organizations address the customer experience drivers that require constant updates and new services. Each component of a cloud-native application can be deployed and maintained as a self-contained microservice. If any element of a broad application needs to be updated or changed, only that element needs to be touched. The rest of the conglomerate application remains the same.

    z/OS plays well with cloud-native

    Many industries under the greatest pressure to speed development and deliver ever-more customized, personalized customer experiences use z/OS systems. As noted, these are retail, banking, insurance, financial services, and travel/hospitality. Government also can be added to the list. It is a large user of z/OS systems and is constantly trying to improve access to its services via new or improved web, mobile, chat, social, and phone applications.

    There are two ways to enhance and develop applications for these systems that use modern development methods. One is to make data, applications, and services that run on z/OS systems available as APIs and as microservices to be used by larger cloud-native applications.

    The other method that is gaining more favor is to provide the modern development tools for the z/OS systems themselves. Specifically, modern application development approaches that move away from monolithic architectures need certain essential elements. Many rely on open-source development techniques, workflow automation, and continuous integration and continuous delivery (CI/CD) tools.

    Bringing such commonly used tools to the z/OS environment helps businesses speed the development of new applications to meet changing demands of their customers. It allows a business to leverage the data and applications on its z/OS systems and create innovative new applications.

    In an age when it is getting harder to find developers with expertise in native z/OS programming, bringing familiar DevOps tools to the z/OS environment offers several benefits. Those who have the native z/OS skills can focus on core applications and leave the tasks like supporting a new front end or enhancing a web interface to others. After all, there are many more developers available with modern development skills.

    Bringing the DevOps tools into the z/OS environment also lets businesses retain all the pluses of those systems. Namely, businesses are assured that the same reliability, superior performance, tightly controlled security, and massive scalability are retained and can be leveraged with integrated with a broader cloud-native application.

     

     

  • Integrating z/OS Systems for Cross-channel Experiences

    Integrating z/OS Systems for Cross-channel Experiences

    Integrating z/OS Systems to Enable a Seamless Cross-channel Customer Experience

    Many industries where customer experience is the critical differentiator run on z/OS systems. That includes retail, financial services, transportation, hospitality, government, and more. As a result, integration of z/OS systems into any customer-oriented application or with front-end applications is essential.

    Just how important is the issue? More than two-thirds of companies now primarily compete based on customer experience.  That’s up from 36% ten years ago. Companies like Jet Blue and The Ritz-Carlton Hotel Company have historically been known for their exceptional customer service. And eyewear provider Warby Parker, widely appreciated for its customer experience, is known for a legendary example of above and beyond service when an executive returned a pair of glasses to the home of a customer who had left the glasses on an Acela train ride.

    Beyond multi-channel to omni-channel

    Many businesses offer multiple ways for customers to interact with their company. It is not unusual for a company to support interactions via the web, in-person, mobile, voice, text, and chat. That way, every customer can use their preferred method to ask questions, review account information, check on an order status, get information, search, place orders, and more.

    What differentiates one company from another is when a business offers a seamless cross-channel customer experience. Often called omni-channel, a seamless cross-channel experience is a multi-channel approach to serving customers that offers an integrated and cohesive customer experience no matter how or where a customer reaches out.

    We’ve all experienced the siloed approach that treats each channel separately. You’re doing something online such as placing an order, checking the status of a service request, or inquiring about your account. An issue occurs such as a phone line dropping, your mobile phone’s screen is too small to carry out the task, or you simply want to talk to someone in person. You switch from mobile to Web, or phone to in-store, and there is no connection or carryover between what you have already done and now. You need to reenter information, answer the same questions, and walk through the same steps.

    In contrast, the interaction with a business that delivers a seamless cross-channel experience is much different. An agent on the phone knows you’ve had trouble placing an order online, the in-store representative is expecting you to drop off an item for repair, and when you log into your account online, you are taken to the part of the process you were at on your mobile device.

    Integration is the key

    Omni-channel customer experience seamlessly integrates the different communication channels that businesses use to communicate with customers. Customer demand for a seamless cross-channel experience is pushing businesses to change. The number of companies investing in an omni-channel customer experience has jumped from 20% in 2010 to more than 80% in 2020.

    As a result, z/OS users are racing to adapt to the new realities of the omni-channel customer experience. Users expect that data and applications will be as readily available on mobile devices, the web, or via phones as they are on desktop clients.

    Developing a seamless cross-channel user experience can mean a significant amount of new application coding. What’s needed is a way to easily transform proven applications and system-of-record data using modern APIs to accelerate the delivery of new services and meet changing customer expectations.

    To tightly integrate z/OS systems for such efforts requires the embracement of modern application development methodologies. That includes providing developers with solutions that let them retain the decades of efforts that went into the core applications running on their z/OS systems while building new applications that tap into these systems.

    Businesses must make available to their developers the commonly used open-source development, workflow automation, and CI/CD tools to the z/OS environment to accomplish this. Such a strategy will help businesses speed the development of new applications to meet changing demands of their customers. It allows a business to leverage the data and applications on its z/OS systems and create innovative new applications.

    Developing new customer applications while retaining the core business functions, processes, and data on the z/OS systems ensures that all front-end access makes use of a single source of truth about the customer. There is only one record associated with each customer. Such integration of z/OS systems thus makes it much easier to keep all the channels aligned and lets businesses deliver the prized and highly desired seamless cross-channel customer experience.

  • The New Norm for Modern Apps: Security Observability

    The New Norm for Modern Apps: Security Observability

    Observability has burst onto the scene across all types of operational and security-focused activities. Its need is being driven by increased demands for businesses to be more responsive to changes and more proactive when dealing with potential problems. In particular, security observability holds the promise to help reduce the time to detect a cyberattack. And going a step further, it can help detect security vulnerabilities before an attack even occurs.

    What is security observability?

    In the past, most operations relied on visibility into their systems and applications to manage security. Visibility would be achieved via monitoring applications, systems, and their logs. Monitoring solutions would collect and analyze information to detect suspicious behavior or unauthorized system changes. And having defined which types of behavior should trigger alerts, solutions would take action as needed.

    Perhaps more to the point, monitoring lets you detect a known set of problems or conditions. Thus, it is essential for alerting and analyzing long-term trends. Simply put, monitoring lets users know how their systems and applications are functioning and being used.

    However, the problem with security monitoring of complex distributed applications is that it is a passive approach to highly dynamic operations. And it often does not provide any insights into root cause problems or anomalies that might be precursors to problems in the making.

    Security observability expands on monitoring by enabling correlation and inspection of the data to provide much deeper insights. Observability typically requires logs, metrics, and deep tracing. All data is used for modeling and analytics. Companies can mine the data, look for patterns, use artificial intelligence and machine learning to remediate problems and proactively defend against problems.

    Why security observability is needed now

    The need for security observability is growing due to the way applications are developed.

    The general industry trend is a move to cloud-native architectures based on microservices. Such an approach brings many benefits. Applications can scale quickly. Companies can easily change or update a small aspect of a larger application without impacting the rest of the app. And businesses can make use of new technologies. For example, a business can add a new front-end or implement more sophisticated AI or machine learning modeling.

    Such a development approach can introduce potential blind spots and complexity. In particular, modern applications built using cloud-native architectures and microservices introduce new challenges. The loose coupling of such applications, their distributed nature, and increased complexity makes it harder to understand vulnerabilities. As a result, traditional cybersecurity approaches break down. They miss the interactions and inter-dependencies of the many elements that comprise modern applications.

    Furthermore, traditional security monitoring solutions can be limited. For example, visibility often must be split across tools resulting in insecure platforms or situations where relevant data is not even used in monitoring.

    Adding to the security challenges is the widescale embracement of low-code/no-code development methodologies. Such technologies open development up to business units and citizen developers. These groups can build sophisticated applications, often with little oversight or guidance. As a result, apps may be created by assembling building blocks that may be outdated, unpatched, or simply have vulnerabilities.

    DevSecOps needs security observability

    With all these trends, it is not surprising that businesses are exploring new approaches to security. Just as quality assurance was melded into development processes using automated testing, security ops are being meshed with development. Hence, the rapid implementation of DevSecOps methodologies in organizations today.

    While security issues can grow when using cloud-native development methodologies, there is a lesser-known security benefit. Applications and services constructed using APIs and microservices have an advantage over other systems because developers and security staff can more easily observe what’s happening inside them. In addition, businesses can add links to the APIs and microservices and use tools to collect the details of such operations.

    Given this wealth of data, security observability expands on monitoring. Rather than just detecting vulnerabilities and incidents that raise compliance issues in the development process, DevSecOps using security observability, seeks to identify issues and automatically take corrective actions.

    Moving forward, businesses should expect more adoption of DevSecOps and more automation based on security observability. This will only serve to strengthen security and compliance across systems and applications.

  • Bringing z/OS Systems into Today’s Modern Application Development

    Bringing z/OS Systems into Today’s Modern Application Development

    Bringing z/OS Systems into Today’s Modern App Development

    Modern application development is all about automation, addressing the concerns of developers and the operational side of the house, and supporting the common CI/CD (continuous integration/continuous delivery) approach needed to keep apps up to date.

    Developers typically make use of a variety of open source and other tools to aid in their work. While most of these tools were created for traditional server or cloud-native environments. Some of the most powerful tools are available to run natively in z/OS environments.

    One example is Ansible, an open source community project for app deployment, configuration management and orchestration. It is available for z/OS.

    The IT automation engine works by connecting to your nodes and pushing out small programs called “Ansible modules” to them. These programs are written to be resource models of the desired state of the system. Ansible then executes these modules and removes them when finished.

    Simply put, Ansible allows developers to automate z/OS applications. With Ansible, developers can use existing JCL, REXX and z/OSMF to automate z/OS-based software. This lets the developer take a common approach to hybrid applications and integrate z/OS into an enterprise automation strategy consistently.

    A great advantage is that developers can work in Ansible and Python. These are readily available skills in the marketplace and they can be applied to z/OS applications.

    Another common tool is Jenkins, an open source, server-based tool that builds and tests software continuously, supporting CI/CD. Jenkins integrates with a broad range of source code management systems such as Git and Subversion. Jenkins’ capabilities can be extended to different platforms and systems using plugins. One such z/OS connector is the IBM z/OS Connector, a plugin for connection of Jenkins CI to IBM z/OS, including integration of IBM SCLM as SCM.

    With tools such as these, developers can build a CI/CD pipeline that, for example, calls open source scripting that you have running on Z. It might move some files from A to B, or it might call a compiler. It helps someone familiar with these tools carry out these tasks and incorporate them into their processes. If they are running on the z/OS platform, developers can interface and make calls right on the platform. For example, an app may take advantage of existing mainframe Rex scripting without having to rewrite it.

    Accounting for Cultural Differences

    In today’s always-on, instant-access-to-everything world, employees and customers demand frequent updates and new features to existing applications and services, as well as new and better offerings all the time. Meeting these demands is a competitive differentiator.

    Bringing commonly used open source development, workflow automation and CI/CD tools to the z/OS environment helps businesses speed the development of new applications to meet changing demands of their customers. It allows a business to leverage the data and applications on its z/OS systems and create innovative new applications.

    It’s also about providing the tooling to DevOps that they are familiar with and providing tools to build z/OS applications in the same way they build other applications. Many are building their applications off-platform with the same tools. Having tools that run on z/OS is helpful. It makes it easier. Businesses can make fewer application changes. So, there’s less risk.

    If a business has 20, 30 or even 40 years’ of legacy applications running on z/OS, those applications have proven to be secure, stable and reliable. An open source application development tool for z/OS offers a way to retain those qualities and modernize application development for building pipelines and instituting DevOps principles and practices that are well-known to the new generation of developers.