devopsy.kinsta.cloud

Category: Enterprise DevOps

  • Security Debt: Speed vs. Common Sense

    Security Debt: Speed vs. Common Sense

    A couple years ago, we had some spectacular security events that involved DevOps and Kubernetes, where the managing team simply redeployed containers whenever one crashed. It turned out that many organizations were doing the same thing, and, what’s worse, they were not talking about it because they knew it was not a long-term solution to crashing issues.

    At the time, I thought these high-profile lessons would teach people to actually fix code issues, even in high-throughput Agile-meets-DevOps shops. I admit I also laughed, yet again, at The Phoenix Project’s expense, thinking, “Yeah, but the CISO isn’t holding things up by demanding that get fixed!” I wish that would ever get old, but it won’t.

    It seems I was wrong. Or at least partially so. Some—perhaps many—shops seem to have missed the message that these issues sent. Anecdotally, we heard this was still happening, so we started asking questions. Yep. There are shops out there (since we started with ‘anecdotally,’ I won’t pretend to put numbers around it) that still take an “If it isn’t causing disruption in core systems, don’t fix it” mentality.

    Ouch. We’ll be revisiting some of those in the future, I’m sure—when it’s listed as a vulnerability or breach somewhere.

    I’m not a security professional. Because the vast majority of enterprises do not have dedicated security and even more don’t have anything close to enough security staff, I have done security as a part of almost every job I’ve taken—because it was what needed doing the most. Many, if not most of you, are in the same boat.

    That said, I can tell when you are blatantly asking for a security incident. And running code known to be faulty or misconfigured to the point that it repeatedly crashes is deliberately asking for a security incident. “But it isn’t exposed to the Internet!” is only a valid rebuttal until an attacker gets inside the perimeter and uses your fault for something like privilege escalation. Then no one cares if it’s connected to the internet or not; they want to know how the attacker did it. And that’s on you.

    So for those organizations in which speed has overridden common sense, let’s be very clear and to the point.

    It is a best practice not to run crash-level faulty software.

    Since you must not have one, write a policy that explains this and lays out a process and/or timeline to fix these problems. Then drive it home. Make certain it is known that this policy will be enforced. For that huge majority of my readers that don’t have the level of authority that “create and promulgate a policy” implies, convince those who do. Point out the issues to them in writing. “Notified in writing of faulty practices that could bite the company in the rear,” tends to get even the most unfriendly management to click into CYA mode and do something about it.

    When we all watched those spectacular failures back in the day, I assumed that this was all about growing pains; you can do so much more with Agile/DevOps/cloud and/or Kubernetes that this type of thing would crop up and, eventually, get addressed. I still believe that. You all are still testing the boundaries and pushing the limits and making all of IT look good. It’s just going to hurt getting there sometimes. Fix the apps, make the policy, keep kicking butt and know you are killing it (as an industry. If you aren’t, stop laughing at my blanket compliment and fix yourself).

  • IBM z16 Delivers AI and Quantum-Safe Levels of Security

    IBM z16 Delivers AI and Quantum-Safe Levels of Security

    Business transformation and disruption is all about data. But it’s not just about collecting huge amounts of data, it’s what you do with that data and how it can enable you to create powerful insights.

    While many people focus on the cloud unicorns, the reality is that industry incumbents have a huge advantage. These businesses have decades of experience which translates into massive amounts of data and business logic. Where do many of these businesses host their most important workloads and data? IBM zSystems—the system that is best known as “the mainframe.” 

    Today, IBM is announcing its latest IBM zSystem—IBM z16. Two weeks ago, IBM spent time briefing the industry analyst community on the business strategy and technical underpinnings of the IBM z16. We met with a variety of IBM business leaders including executives from the IBM Systems division, Distinguished Engineers and IBM cloud leaders. The most significant updates to the platform are the inclusion of a dedicated on-chip AI accelerator and the addition of quantum-safe cryptography.

    It’s important to understand the size of the IBM zSystems ecosystem. The platform is used by 45 of the 50 largest banks in the world, four of the top five airlines and eight of the top 10 insurers, among others. Likewise, the partner ecosystem is huge, ranging from the largest system integrators to small DevOps- and AI-focused technology vendors. Suffice it to say, some of the world’s largest businesses and governments run on IBM zSystems.

    In this article, I will briefly cover the five biggest takeaways from the pre-announcement industry analyst briefings.

    IBM is Bringing AI to the Mainframe

    Many cloud data warehouse and analytics vendors say “Bring me the data.” IBM is flipping the script, because IBM zSystems already houses clients’ most critical customer and operational data. IBM z16 will be shipped with an on-chip integrated accelerator for AI.

    Everyone knows that AI creates a competitive advantage, so why should you care about the on-chip AI accelerator? The last mile of deploying machine learning/artificial intelligence (ML/AI) models is still a huge challenge. Businesses are investing large amounts of money and skills in developing models; however, latency often kills. The difficulty is that ML/AI models need to be built into applications so that the model can be executed at the point of transaction with virtually no delay. This also must be done at a massive scale! Think about the latency and security concerns if near-real-time banking transactions needed to go from a back-end system to a cloud AI platform to check for fraudulent transactions.

    For those of you who have been following the IBM zSystems platform, IBM’s z14 unveiled a pervasive encryption capability. This encrypt-by-default approach without traditional encryption overhead was enabled through an encryption-dedicated chip. Similarly, AI workloads will be performed by the integrated AI accelerator.

    Your AI Infrastructure is Only as Powerful as Your Software Ecosystem

    Developers and data scientists want to use data, ML and AI tools that they know and trust. AI success requires an open stack of software options, not a walled garden. While IBM has a wide range of AI technologies, including Watson Machine Learning for z/os, IBM Cloud Pak for Data and IBM Cloud Pak for Watson AIOps, just to name a few, an IBM-only approach would be a non-starter for many data scientists.

    The IBM z16 AI accelerator supports a wide selection of ML libraries and compilers. Clients can build and train models in a variety of popular frameworks including TensorFlow, SAS, Microsoft CognitiveToolkit (Microsoft CNTK), PyTorch and Keras, along with others.

    The system uses ONNX, an open source tool to enable interoperability of ML/AI models to prepare and deploy the model on the dedicated AI accelerator.

    What does this mean? You can bring your existing data models to IBM z16. In addition, your teams can use their existing preferred vendors while also working with IBM zSystem’s integrated accelerator chip.

    Cybersecurity Arms Race: Quantum-Safe Cryptography is a Growing Need

    Cybercrime is a multibillion-dollar business. Although fairly routine exploits like phishing remain the number-one money generator for cybercriminals, these gangs and nation-state-sponsored organizations are getting more sophisticated. For example, cybercriminals are investing in AI and ML just like traditional businesses. In some cases, cybercrime syndicate engineering employees believe they’re working for a legitimate company.

    What is quantum-safe cryptography? The research is focused on identifying algorithms that are resistant to attacks by both classical and quantum computers. 

    Why is this a growing area of concern? IBM, along with Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP) all offer quantum computing-as-a-service. While quantum computing has massive potential for applications across a wide range of industries including drug discovery, chemical engineering and combating climate change, keep in mind that cybercriminals are looking at this technology to unlock complex cryptography algorithms. 

    IBM claims that IBM z16 is a “quantum-safe system.” The company uses a variety of different hardware, software and business process approaches to assure data security. For example, the system includes a new crypto express card with quantum-safe APIs to upgrade existing application security. At a firmware level, IBM z16 has a built-in dual signature scheme.

    In addition, for a number of years, the IBM zSystems platform has taken a zero-trust approach to security which includes a bring-your-own-key (BYOK) framework. IBM can never access the keys to your encrypted data–and neither can cybercriminals and/or governmental organizations—instead, those encryption keys remain inside your firewall.

    IBM zSystems Tech Goes to the Cloud; Mainframe Remains On-Premises

    What a difference a nine can make! Five nines mean 99.999% availability while four nines (99.99% availability) result in more than 47 minutes of downtime per year.

    When I work with C-level executives that have a mainframe within their environment, the role of IBM zSystems is always discussed. In many cases, businesses have explored the possibility of transitioning off of the mainframe, but resilience, predictability and security are the reasons why businesses remain on the platform.

    IBM mainframe services are increasingly being offered in the cloud. Most recently, IBM announced IBM Z testing in the cloud. Likewise, IBM’s Cloud Hyper Protect Crypto Services, a key management approach using a specific security chip module, is enabled by IBM zSystems technology.

    However, you shouldn’t expect mainframe-as-a-service. Between latency, security, resilience, governance and compliance, it’s going to be a long time until you migrate and/or send your mainframe workloads to the cloud.

    As the author of Hybrid Cloud for Dummies and Cloud for Dummies 2nd Ed. (among other books and articles) I can confidently say that the cloud is not a panacea. The business case for moving many mainframe workloads to the cloud doesn’t exist. 

    Digital Transformation Means More Than Slick Apps–Plumbing Matters!

    Don’t get me wrong, mobile check deposits, airline ticketing and contactless hotel check-ins are great, but in many cases, they rely on older systems that have not been updated. 

    A few weeks ago while traveling for work, my flights were delayed for hours. I saw that another flight was leaving within the hour. I was already at the airport and figured I could rebook it via the airline’s app. Of course, it wasn’t that easy—I finally went to the ticketing desk and told the agent that I’d like to book a different flight. The agent then went to work; they spent a long time entering information into their system, talking to a colleague, asking for help and asking me several questions. After about ten minutes my flight was finally rebooked.

    This airline has a great app experience when things are running smoothly (so great, in fact, that I prefer to book my travel on the app rather than the computer). However, even a slight disruption caused everything to go off the rails. It’s clear to me that the company still relies on old, broken processes and outdated technology.

    My Perspective

    Moving AI closer to the data just makes sense. The last mile of AI—moving models into transactions—continues to be a huge challenge. I work with many businesses that have tons of data and do an excellent job retrospectively analyzing that data. However, real-time data-driven decision-making remains a challenge because of latency and the fact that moving data between on-premises and cloud systems raises security and governance risks (in addition to costs).

    Quantum-safe security is a growing concern for highly regulated organizations in the banking, insurance and governmental segments. Over the last several years, financial industry CIOs and CISOs/CSOs at large financial services organizations were focused on establishing a zero-trust approach to security. However, as attacks become more sophisticated, security teams are starting to perform risk assessments on their approach to cryptography. The inclusion of quantum-safe cryptography is important for IBM zSystems customers.

  • The Missing Link in Continuous DevOps Cycles

    The Missing Link in Continuous DevOps Cycles

    Delivering software quickly, reliably and safely is at the heart of technology transformation and organizational performance regardless of industry. As part of overall technology transformation, many companies are recognizing the benefits of applying DevOps methodologies to areas outside of software development, such as general product development, IT expansion and scaling and new business processes. However, some organizations—and even software development teams—may be missing a crucial step in the product development life cycle. 

    The Missing DevOps Link

    DevOps methodologies are nothing new. In fact, part of the reason organizations are adopting DevOps practices for initiatives outside of software development is because of its tested and proven success when it comes to developing and deploying new processes and features. The exact steps involved in DevOps processes can be debated by reasonable people, but there are three generally agreed-upon factors involved: Continuous integration (CI), continuous deployment (CD) and continuous release (CR). 

    Continuous Integration

    CI refers to a strategy of constantly updating products with new features and code on a regular basis. The cadence of the updates varies from weekly to monthly, but the strategy remains the same: Detect problems early before they can snowball and impact further development down the line. 

    Continuous Delivery

    CD is related to continuous integration but is focused on the delivery stage. CD is executed when new features and development updates are deployed to production. The most critical factor of CD is consistent management of the product’s end environment. To maintain the consistent functionality of a product in the end-user environment, it must be regularly deployed and tested to ensure performance doesn’t suffer as a result of product updates and new features.

    Continuous Release

    CR is the final step before the product development life cycle starts over again. CR refers to the practice of continually releasing new product updates, features and capabilities to end users. The tricky part of CR is that you must execute CI and CD flawlessly to ensure the end user doesn’t experience any bugs or issues caused by an update. 

    But what’s missing? The answer lies in continuous exploration (CE). 

    Why CE is Critical to Product Development Success

    CI, CD and CR are often-discussed product development strategies, but they don’t tell organizations where to start with the DevOps life cycle. To begin developing new products or features, organizations must first identify what exactly they’re building and for whom. As I often say to my product team, you need to get the kitchen ready before you can cook a great meal, but you need to know what meal you’re making before you start cooking the wrong thing.

    CE refers to the continuous exploration of a company’s markets, target audiences and customers to understand their requirements and preferences. This may sound like the job of a marketing department, not product developers, but the two should work together in a coordinated fashion that helps to achieve both teams’ goals. For example, product development teams don’t know what new product features their customers love, which ones they hate or which ones they really need. On the other hand, marketing teams don’t know how to market products if they don’t understand the ins and outs of the new features and how they can be of service to customers. 

    Even departments within an organization that don’t develop products can benefit from CE. For example, if an organization is pursuing a cloud migration of on-premises software, they will likely hire an expert consultant or vendor to help them execute their cloud vision rather than developing their own cloud environment.

    However, simply moving all of the on-premises systems and data to the cloud at once could be a catastrophe. What if you migrate systems and processes to the cloud and they suddenly stop working? Unless you’ve performed the migration at a gradual pace by following CI, CD, CR and CE strategies, you don’t know what, specifically, is causing the system error in the cloud.

    In the same vein, by performing CE internally, organizations can determine which processes and on-premises systems would benefit most from cloud capabilities and execute the migration accordingly. This not only prioritizes technology transformation initiatives based on the needs of the business but may also let the business know which on-premises systems may no longer be needed in a cloud environment.

    Many organizations interested in improving customer experience (CX) and internal processes by leveraging DevOps strategies would benefit greatly from leveraging CE. Products and businesses processes should be designed to meet the needs of customers and drive bottom-line revenue. So, it stands to reason that the first step in meeting the needs of customers is understanding those needs. This cannot be done without CE as the foundational building block of product development life cycles. 

  • Positioning ML Devs and Teams for Success

    Positioning ML Devs and Teams for Success

    Intelligent applications are (by their very nature) complex. While conventional software basically consists of one thing (code), intelligent software involves code, models and data. As previously discussed, three distinct fields—DevOps, MLOps and DataOps—have evolved to govern each of these interconnected disciplines. 

    Moving through the ML life cycle quickly and efficiently requires collaboration between teams in each of the above disciplines. Organizations should strive to make this collaboration as frictionless as possible to position their ML efforts for success. What follows are four places where we believe organizations should focus: 

    • Infrastructure
    • Team structure
    • Tools 
    • Project ownership and KPIs

    Build Dedicated Infrastructure for Each Pillar

    Infrastructure software is not one-size-fits-all across the three pillars of code, model and data. For example, DevOps teams have historically played the infrastructure role in software development, supporting application or product services. Think of regular software engineering teams who are supported by DevOps, producing different kinds of application services. App infrastructure is so baked-in to software development that most of us take it for granted.

    Just as regular software services require DevOps, data and model services require corresponding infrastructure. Data infrastructure is typically concerned with managing tools (such as Airflow installations, Spark clusters and feature stores), building data pipelines and ensuring that data services remain smooth and operational for data consumers. 

    On the other hand, model services are chiefly concerned with creating, running and organizing models in such a way that others can use them efficiently. Since the AI/ML life cycle is incredibly complex, a host of factors need to be considered (e.g., hardware, parallelization libraries, model packaging formats, etc.) to help data scientists and engineers do their jobs efficiently. Robust ML infrastructure along with a dedicated ML infrastructure team goes a long way in helping organizations scale their AI.

    Optimize Team Structure

    Best practices for ML and AI are continuously evolving, and organizations have tried a host of team structures over the years. We have noticed two popular structures for intelligent application development teams emerged in recent years:

    • Pods

    Pod structures involve smaller teams—usually a data scientist, a data engineer and an application software engineer—working together closely to deliver an intelligent feature or product. Due to their tight-knit nature, these teams are positioned to iterate extremely quickly, which often leads to better products and features. However, the closely-knit nature of pods also comes with a downside, as knowledge sharing between pods with different objectives can be difficult.

     

    • Center of Excellence

    In a center of excellence (or COE) structure, all data scientists or data engineers are “pooled” and then assigned to different products or features depending on project requirements and circumstances. In contrast to pods, COE structures tend to share knowledge very easily. However, this arrangement can lead to slower iteration cycles because team members are not dedicated to particular products or features. 

    In our opinion, both pod and COE arrangements can be effective depending on the realities of an organization. Choosing an optimal team structure depends on how the rest of the organization is structured and how reporting relationships are set up. 

    Select Appropriate Tools

    To select the best possible tools for your organization, choose those that foster collaboration and uphold safety across code, model and data teams. 

    The right tools help teams work quickly and efficiently. Teams should be able to discover pertinent information for themselves without having to pull others off of whatever they are working on. For example, a data science team should be able to discover what data access or learn what features exist. Similarly, application teams should be able to discover what models exist, what versions are the latest or how and when to use models. The more that you can make your code, model and data self-serve, the faster teams will be able to build products that are ready to be put into production. 

    Furthermore, proper tools make debugging faster and easier. If you’ve been around ML-enabled features or products for any length of time, you’ve probably been bitten by undeclared dependencies and apps breaking due to upstream changes. In an intelligent app, finding the root of a problem can be extremely difficult because the root cause can exist in any of the three pillars or any combination of the three. Robust tools provide logs and information to help discover what went wrong more easily.

    Finally, governance should play a key role in tool selection, as safety should be a chief concern for ML teams. For example, consider a model that predicts the demographics of a user based on their app usage. While these predictions might be considered acceptable in certain applications, if a model is being used to make financial recommendations or approve credit applications, use of certain demographics may violate various consumer protection laws. Since a software engineer using this model might not be aware of the nuances related to its use, baking in safety checks on model and data use becomes vitally important. 

    Establish Ownership and Determine Appropriate KPIs

    Whether we are working at a company or in an academic lab, our goal always remains the same: build the best product. 

    But “best product” can mean a lot of different things depending on the use case. For example, sometimes teams may be willing to trade a bit of accuracy if a model fails in predictable ways (e.g., in health care applications.) By contrast, an e-commerce recommendation system can optimize for overall model accuracy even if a model isn’t quite as stable. As a result, choosing the appropriate KPIs for model optimization requires careful attention.  

    Similarly, choosing appropriate metrics that make sense for the product and business usually requires a high-level view of a number of factors — user expectations, revenues, user complaints, etc. In our experience, product owners are usually in the best position to make these decisions. KPIs for each of the pillars supporting the intelligent app should be based on key metrics determined by product owners. While these can range, we’ve seen the following KPIs work well:

    • Code — Number of releases, number of bug fixes, number of features that have shipped, mean time to resolution
    • Model — number of model iterations shipped, model quality in production, model performance SLAs 
    • Data — frequency of data refreshes (e.g., every day or every month?), number of data quality issues, speed of access to data

    The key point here is to drive all of these based on the product KPIs and to focus on the agile principle, which is how quickly are you moving and how many deploys are happening. 

    Know what metrics your team is looking to optimize so that you can invest your resources in the right spot. 

  • Designing Your DevOps Ecosystem for Multi-Cloud

    Designing Your DevOps Ecosystem for Multi-Cloud

    As companies grow and expand to become global enterprises, IT infrastructure inevitably becomes more complex. When it comes to cloud computing, that usually means maintaining multiple clouds. There are many reasons for using different cloud service providers (CSPs)—some by choice and others by mandate. 

    For instance, a large enterprise with operations around the world may choose to use an in-country cloud vendor to be closer to the customer, therefore reducing latency and increasing application performance for operations in that country. Alternately, in some countries, data residency laws require that certain kinds of data reside on cloud providers within the country’s borders, which means companies with local operations can only use a cloud provider in that country. Both circumstances lead companies to maintain multiple clouds to facilitate operations at scale. Additionally, a company may decide to use two or more cloud providers as part of a fallback strategy to automatically reroute network traffic to another provider if a major outage occurs.   

    Regardless of whether the use of multiple CSPs is a choice or a mandate, enterprise IT leaders—and DevOps teams in particular—need to think strategically about multi-cloud environments and design their software delivery ecosystem from the outset to accommodate a multi-cloud strategy. 

    Best Practices for Multi-Cloud Environments

    An effective multi-cloud DevOps strategy is essential for allowing businesses to easily scale application delivery across many different cloud assets and is therefore vital for enterprises operating globally. To create an effective strategy, consider these best practices.

    Use a Centralized Software Delivery Platform

    With many CSPs—each with different requirements and tools—companies too often create siloed software development and delivery teams by vendor (AWS, Azure, GCP, etc.) or functional role (security, compliance, etc.). To avoid this pitfall and maintain control and visibility across all cloud providers, it’s important to implement a centralized software delivery platform, ideally one that’s environment agnostic. This will give your DevOps leaders the intelligence and insight they need to manage the entire software delivery ecosystem across multiple clouds anywhere in the world. At the same time, automated delivery processes can ensure quality checks and other milestones aren’t missed regardless of the cloud destination and that reporting, analytics and metrics from a centralized platform can identify and eliminate bottlenecks across different clouds. 

    Use Cloud-Agnostic Tools

    Most cloud vendors have their own tools. However, maintaining a multi-cloud environment using vendor-specific tools can lead to lock-in and which can be costly and time-consuming to remediate. Too often, when companies move to the cloud, they use a set of vendor-specific tools for their software delivery processes. That works well initially, but as the company scales and requires a multi-cloud approach, the teams either find themselves heavily siloed without visibility across the whole ecosystem or there is significant technical debt that needs to be overcome. To avoid this, companies need to plan for the use of cloud-agnostic development and deployment tools from the outset so you can easily shift applications to different cloud providers as necessary to keep pace with changing business needs.

    Create Cloud-Agnostic Templates

    As developers assess and use tools and applications for different clouds, environments and use cases, they can create templates and abstracts to share lessons learned across teams, increase productivity and speed development cycles regardless of the destination CSP. For enterprises with more advanced DevOps practices, self-service capabilities—like a shared module catalog—can further speed development processes. 

    Make the Most of a Multi-Cloud Environment

    Once your enterprise has embraced a multi-cloud approach and the DevOps systems and processes are in place to efficiently deploy applications across different CSPs, a multi-cloud environment can be used to your strategic advantage—to increase flexibility, speed software delivery and reduce costs. Here’s how:

    Align Application Destinations to Specific Clouds

    When you’re not dealing with the confines of country-specific cloud providers, IT and DevOps leaders can strategically align applications to specific cloud providers by region or country to reduce latency, optimize workloads or take advantage of specific service offerings from a particular CSP.

    Use Application Features in Different Clouds

    This concept is a great way for DevOps to leverage a multi-cloud architecture. If an application is run in one cloud and you want to add a feature that uses an application from a different cloud in your IT footprint, you can create a multi-cloud cluster using the same underlying cloud database to support both workloads. In this scenario, a production node resides in cloud A and runs in parallel to the read-only node in cloud B. This helps developers avoid the headaches that come with custom scripting as well as the costs of maintaining a backup and restore scenario.

    Reduce Costs and Improve Performance with Cloud Arbitrage

    This strategy is somewhat new, but it’s becoming more and more mainstream as competition increases among cloud providers. Here, you use a multi-cloud cluster to shift your workloads among several cloud providers to optimize your cloud environment and take advantage of negotiated discounts, specialized support, higher availability, lower latency or other unique features offered by a specific CSP.

    To keep pace with our rapidly changing world, enterprise-scale organizations must be able to manage software delivery across multiple clouds. If your DevOps systems and processes aren’t designed for flexible development and delivery across different CSPs, you could limit your ability to adjust and successfully manage major disruptions or scale to take advantage of new opportunities.

  • What We Don’t Know is Dangerous

    What We Don’t Know is Dangerous

    Pop quiz: How many database management systems (be they RDBMS or NoSQL or even flat file) do you have running in your overall organization? Not actual databases, but management systems?

    How many containers do you have that are exposed to the internet, directly or indirectly? Not container management systems, because you’re only running a couple of those and they’re all relatively new, but actual containers?

    The questions could go on and on. Not too long ago, because there was an identifiable cost associated with it, cloud inventory management became a popular thing – finding and removing cloud instances, services and storage that were no longer necessary became a part of normal operations for organizations that had even a mid-sized cloud presence.

    But now, we have sprawl all over the place. So let’s extend inventory management to all software, and get rid of what isn’t needed on a regular basis … because it does indeed build up quickly.

    Yes, there are a few companies out there trying to do just this, and I encourage you to check them out. I have not, because our inventory at Ingrained Tech is manageable without that level of overhead. Our development and ops time is limited, so we keep a tight rein on what is out there and the maintenance it requires.

    But for larger organizations, the more you have out there, the larger attack surface and potential data sieves you have in place. So make sure if it isn’t needed, it’s gone. In the age of containers, this actually requires a fair amount of investigation; first, a list of all containers part of an ongoing project (and in even a mid-sized company, “They’re all together for each app,” won’t create this list because random containers are out there, too). And then a list of all containers not associated with a known project that can be gone through and usage determined.

    It’s not glamorous. It’s a bit of a slog. It’s in the organization’s best interests, though, and the slog should motivate your teams to put a policy in place to manage container life cycles. Like notes in Docker files that say when the container is no longer needed, or what it is needed for, so future you can easily get rid of it without stress.

    If you are in a containerized environment, this problem is growing almost by the day. Seriously. On our last project, we had 12 active containers before we pared it down to the five we needed long-term. The others were R&D along the way or tools we were using before focusing on a different method of achieving the same goals. Since we’re a small team, we just cleaned up when the project was coming into focus, but a larger org needs to be more focused on cleaning things up as they go.

    Meanwhile, those assets are letting customers get to your org, and allowing employees to manage the systems. Keep rocking it, and just remember to pick up, particularly after cutting-edge new projects, but also occasionally as just a normal cleanup step.

  • Lapsus$ Shames Okta/Sitel | Bitcoin Nukes Climate | EU DMA E2EE FAIL

    Lapsus$ Shames Okta/Sitel | Bitcoin Nukes Climate | EU DMA E2EE FAIL

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Okta and Sitel under fire over Lapsus$ hack, Greenpeace and others call for bitcoin change, and Europe still hates encryption. (more…)

  • Rocket Software Extends DevOps Reach to IBM I Platforms

    Rocket Software Extends DevOps Reach to IBM I Platforms

    Rocket Software has added support for the IBM I platform as part of its relaunch of a DevOps platform that also runs on IBM mainframes.

    Chris Wey, president of the data modernization business unit at Rocket Software, said the Rocket DevOps continuous integration/continuous delivery (CI/CD) platform will make it possible for organizations that employ both IBM I midrange platforms and mainframes to modernize application development and deployment using a common framework.

    Modernization of application development on mainframes has been occurring for some time. A survey of more than 500 U.S. IT professionals conducted by Rocket Software found 44% of respondents employ multiple DevOps tools, but slightly less than a quarter (24%) have a comprehensive DevOps platform in place.

    Rocket Software is expanding its DevOps reach to include the IBM I platform because organizations that rely on this platform have the same pressing need as other organizations to more quickly build applications, said Wey.

    It’s not clear to what degree organizations are still building new applications for what have become venerable IBM platforms. A Rocket Software survey found that while 82% of respondents are migrating workloads to the cloud, only 4% reported they are migrating completely to the cloud. The bulk of most mission-critical applications running on mainframes are online transaction processing (OLTP) applications that require a level of processing capability that still can’t be easily matched using any other platform. There are plenty of instances where certain classes of workloads have been migrated off the mainframe to run on lower-cost platforms. However, there are still many enterprise applications that continue to run faster on mainframes than they could on any other platform.

    In most cases, Wey noted, organizations will be deploying and updating applications across hybrid cloud computing environments for years to come. The immediate challenge they face is a lack of DevOps skills among the IT teams that manage IBM I systems and mainframes, he added.

    Rocket Software also provides access to a set of application development tools for building modern applications on IBM platforms. Most recently, the company added support for an open source Python software development (SDK) that IBM created for the Python programming language to the Rocket Open AppDev for Z framework for building mainframe applications.

    The overarching goal is to make IBM platforms more accessible to a wider range of application developers and DevOps professionals that today mainly work on distributed computing platforms, noted Wey.

    One way or another, the divide that has existed between legacy platforms and distributed computing systems is continuing to narrow. Many organizations are trying to lower the total cost of IT by centralizing management of both these classes of systems versus continuing to hire and retain separate IT teams.

    The IBM I platform traces its lineage back to AS/400 systems that were first launched in 1988 as an integrated midrange minicomputer rival to VAX/VMS systems from Digital Equipment Corporation (DEC). Fast-forward more than 30 years later and there still are many IBM I platforms running long after VAX/VMS systems have all but disappeared.

  • Why Your Business Needs DevOps

    Why Your Business Needs DevOps

    One of the biggest headaches IT leaders face today is managing cross-functional teams to develop and deploy high-quality software faster. Not only does their work have to be continuous to stay productive, but there’s the need to save the business money, time and improve end user and customer satisfaction while fixing a seemingly endless parade of bugs.

    Without a robust DevOps process in place that benefits the entire organization, IT management and tech leaders often feel like they are chasing the impossible.   

    What is DevOps?

    DevOps is a set of practices that help you plan how both development (Dev) and operations (Ops) teams can work cohesively to deliver your company’s products and services, meet customer needs and stay ahead of your competitors. In short, it is a set of tools that leverages people, processes and technology to enable safer, faster handling of any IT software delivery initiative.  

    Yet, according to Gartner, as of the beginning of 2022, 75% of DevOps initiatives have not met these expectations because of inefficient collaboration, lack of buy-in from employees, trying to do too much too quickly and unrealistic expectations. For a methodology that is so critical to businesses today, it’s still surrounded by uncertainty and doubt. Let’s look at how you can make DevOps work for you and why it’s so important that you do so.

    Addressing Bugs

    Because detecting and addressing software bugs is a major priority of any IT department, disruptions need to be handled quickly and efficiently. This can only be done through immediate action and a tried-and-testing workflow in which all departments involved can act fast. The beauty of DevOps is that the process can be continuous rather than reactive and thus improve the quality of your software when deploying new features, as DevOps allows you to make changes rapidly. 

    Without DevOps, productivity is slowed or even brought to a halt which leads to an often-damaging customer experience.  

     Improving Customer Satisfaction

    A significant benefit of adopting DevOps practices is that it lowers the failure rate of new features while improving recovery time. The continuous deployment, testing and feedback loops ensure faster service delivery and happier customers. The development team can focus on creating superior products by automating the software pipeline while the operations team can improve business delivery. 

    Faster delivery of your products and services should not be a pipe dream. Those who understand and implement DevOps should feel confident they can stay ahead of the competition. 

    Improving the Security of Your Software

    DevSecOps builds on the DevOps pipeline to integrate security from the very beginning of the development cycle rather than at the deployment stage when flaws and vulnerabilities are more difficult and costlier to fix. Combining development, security and operations across your products and services will improve quality, security and your ability to meet client expectations. Building security into your pipeline seamlessly means bugs and other issues can be addressed more easily and remain almost unnoticed to the end users.

    DevOps and DevSecOps make this possible so that outdated security practices are not integrated into your software and don’t interfere with customer demand. So, if increasing customer satisfaction and positively impacting your bottom line by delivering high-quality, secure and effective software is on your business priority list, then implementing a DevOps process can not only save IT headaches but deliver better business outcomes.

  • 3 Must-Haves When Implementing DevSecOps

    3 Must-Haves When Implementing DevSecOps

    The term DevSecOps is already more than a dozen years old. DevOps—the practice of combining software development with IT operations to deploy applications faster—was first coined in 2008 and refined in a historic conference presentation in 2009. DevSecOps—the concept of baking in security at every stage of Agile development, rather than tackling it at the end—followed soon after. 

    Despite a huge amount of industry conversation and activity around DevSecOps, it has been hard to tell just how much traction the movement has been gaining.

    In a 2020 survey of 1,500 IT professionals around the world by the Synopsys Cybersecurity Research Center, 63% reported that they are incorporating at least some DevSecOps activities into their development pipelines. “At least some” indicates, however, that a portion of the adopters have yet to fully embrace DevSecOps. And what about the other 37% who haven’t incorporated it at all?

    Nevertheless, two factors suggest that DevSecOps is starting to pass a tipping point on the way to mainstream adoption.

    One, the prodigious number of cyberattacks that have been hitting companies and government agencies demand aggressive and proactive approaches to address security, which is exactly what DevSecOps does.

    Two, the pandemic has been a powerful accelerant for digital initiatives. For example, global spending on public cloud services was predicted to grow slightly more than 23% in 2021, to $332.3 billion from $270 billion in 2020, according to a forecast from Gartner. In addition to the greater reliance on technology driven by COVID-19, increasing use of emerging technologies such as containerization and edge computing are fueling higher cloud spending. All of this points to the need for organizations to take security risk into account throughout the modern software development life cycle.

    The logic behind DevSecOps is undeniable. Viewing security as a shared, collaborative responsibility among development, operations and security functions starting at the earlier possible stage—the methodology known as shifting left—rather than in silos enables the deployment of secure software at the speed and responsiveness that today’s business conditions require.

    Companies that have successfully meshed the three functions under the broader DevOps paradigm enjoy radically reduced friction in software development and production. These organizations can deploy software faster and more safely with fewer design flaws, misconfigurations and other missteps that can lead to security issues.

    Companies not as far along in their DevSecOps journeys tend to have espoused some of its practices but not consistently. Clunky, linear waterfall approaches persist here and there. Vulnerability management remains a reactive box-checking effort later in the life cycle, forcing developers to backtrack and fix the code rather than a proactive, preventative process seamlessly integrated from design to production.

    The more advanced organizations typically focus on three key ingredients to assure success.

    1. Education. DevSecOps is a cultural shift as much as a technological one. It requires a new mindset that empowers developers to take ownership for creating secure code at the beginning of the software development life cycle. Thus, IT leaders can’t simply snap their fingers and expect DevSecOps to take hold without educating team members on why it is so critical and how it drives rather than disrupts great work.

    “Organizational learning and change are key to allowing DevOps to flourish,” senior Gartner analyst George Spafford wrote. “In other words, people-related factors tend to be the greatest challenges, not technology.”

    This means that before introducing DevSecOps into an organization, it is important to connect the endeavor with the value it will bring and explain why it will allow the business to deliver more value to customers and improve its competitiveness.

    2. Process. The right DevSecOps policies and processes can spell the difference between a nimble software development machine and one still bogged down by inefficiency.

    For instance, many organizations that rely heavily on scanning tools to detect vulnerabilities assign nonsensical policies to their use. Let’s say that vulnerabilities of a particular score or type need to be eliminated before code is deployed to production. But what if the flaw resides in an unimportant section of the code and is unexploitable?

    The best DevSecOps initiatives include policies and processes that seek to understand the entire context of a project, from design to production and handle everything in a way that reflects the context of true risk to security and compliance requirements rather than merely running all code through the same pipeline.

    3. Tooling. Fact: Without the right automated tools that provide deep visibility into code, a DevSecOps implementation doesn’t stand a chance.

    To carry out the qualities of collaboration and agility that DevSecOps promises, organizations should gravitate toward tools that give developers all the relevant information they need to make more informed decisions.

    These tools must truly simplify the addition of security into DevOps methodologies by automating various manual processes that traditionally have slowed everything down—threat models, security and compliance reviews, pentests and risk assessments and the like. The tools can’t just aggregate data from silos — which fails to provide enough contextual information and generates too many false positives —they need to provide holistic relief to overburdened teams in securing applications at the feature request, commit, pull request and CI/CD stage.

    By keeping these three elements in mind, organizations can fulfill DevSecOps’ potential as a true game-changer. As DevSecOps continues to cross the chasm to more universal adoption, organizations can look to earlier adopters for guidance on how to do DevSecOps right.