Tag: ai

  • Logz.io Integrates ChatGPT With Observability Platform

    Logz.io Integrates ChatGPT With Observability Platform

    Logz.io has integrated the ChatGPT generative artificial intelligence (AI) platform with its Open 360 observability platform to extend its automated recommendation capabilities to reduce mean-time-to-remediation.

    ChatGPT, developed by OpenAI, is based on a large language model that Logz.io uses to enrich crowdsourced data. That approach enables ChatGPT to surface links to related information and best practices for resolving IT issues.

    Logz.io CTO Asaf Yigal said the company has integrated ChatGPT with its existing AI engine, dubbed Cognitive Insights, that applies machine learning algorithms to identify anomalies indicative of potentially critical IT issues. The company expects to be able to add other generative AI capabilities as additional advances are made, he added.

    The Logz.io Open 360 platform is based on open source OpenSearch, Prometheus and Jaeger software that the company has infused with machine learning algorithms. The integration with ChatGPT is enabled via an application programming interface (API) that OpenAI has provided.

    The overall goal is to employ AI to surface the most relevant issues a DevOps team needs to focus on without having to search huge volume of logs, tracing and metrics data, said Yigal. Generative AI platforms solve a fundamental cognitive load problem created today as DevOps teams collect more data, noted Yial. The more data a DevOps team collects, the harder it becomes to determine what’s going on in an IT environment, said Yigal. He added that generative AI platforms make it possible to analyze massive amounts of data at a scale that isn’t otherwise achievable.

    AI tools should make it possible to manage IT at a level of scale that eliminates many of the low-level data engineering and analytics tasks that previously required manual effort from a DevOps engineering team. It’s not clear how many other DevOps tools and platforms will be invoking generative AI capabilities in the months ahead, but DevOps teams should assume that large language models will soon be augmenting DevOps teams in ways that previously would have been thought unlikely.

    For example, discovering vulnerabilities in software running in production environments is about to become trivial as artificial intelligence (AI) platforms such as ChatGPT evolve. A generative AI platform can identify code vulnerabilities in much the same way as a traditional scanning tool. An AI platform, however, could theoretically monitor code repositories and scan them for vulnerabilities as updates and commits are being made in real-time. DevOps teams should be able to use generative AI platforms to discover and remediate these issues before code is deployed in a production environment.

    It’s just as probable bad actors will use the same platform to achieve the same goal, so from that perspective, many DevOps teams will now find themselves in an AI arms race to improve DevSecOps workflows.

    There are still lots of issues to be worked out in terms of the overall accuracy of generative AI platforms, but they will only become more intelligent as processors continue to advance. The issue now will be determining precisely where the man-machine interface for DevOps teams is today and in the future.

  • Graduating From DevOps to MLOps? 5 Tools to Help

    Graduating From DevOps to MLOps? 5 Tools to Help

    DevOps is a set of practices that aims to bridge the gap between software development and operations. It aims to improve collaboration and communication between these two teams and to automate the process of software delivery so that changes can be made and deployed more quickly and easily. This can include continuous integration, continuous delivery and infrastructure-as-code. The goal is to enable faster delivery of new features and improvements to customers while also improving the reliability and stability of the software.

    What is MLOps?

    Machine learning operations (MLOps) is the practice of applying DevOps principles and practices to machine learning projects. It involves the collaboration of data scientists, machine learning engineers and operations teams to streamline the process of building, testing, deploying and maintaining machine learning models in a production environment. 

    The goal of MLOps is to increase the speed and reliability of deploying ML models while also improving the overall quality of the models. This can be done by using tools such as version control, continuous integration and automation of the model deployment process.

    Why DevOps is Not Enough: The Benefits of MLOps

    Machine learning models have unique requirements, such as data privacy, version control and model deployment that are not addressed by traditional DevOps practices. MLOps is specifically designed to address these unique requirements and to ensure that machine learning models are deployed and managed in a production environment in a way that is consistent with other software components. 

    There are several benefits to implementing MLOps in a machine learning project, above and beyond the benefits of DevOps:

    • Improved collaboration: MLOps promotes collaboration between data scientists, machine learning engineers and operations teams, which helps to ensure that models are deployed quickly and efficiently.
    • Faster deployment: By automating the model deployment process and using continuous integration and continuous delivery (CI/CD) practices, MLOps can help to speed up the time it takes to deploy a model to production.
    • Improved model quality: By using version control and automated testing, MLOps can help to ensure that models are thoroughly tested and of high quality before they are deployed to production.
    • Better monitoring and maintenance: MLOps can help to improve the monitoring and maintenance of deployed models by providing better visibility into the performance of models and enabling easy rollbacks if necessary.
    • Better model governance: MLOps can help to improve model governance by providing a clear process for the management of models, including versioning, testing, and deployment.

    5 MLOps Tools to Help Transition From DevOps to MLOps

    Making the move from DevOps to MLOps typically requires dedicated tools that can help manage the complexity of machine learning models and datasets. Here are a few tools, some open source and some commercial, that can help.

    MLflow

    MLflow is an open source platform for managing the machine learning life cycle. It aims to make it easier for data scientists and machine learning engineers to develop, deploy and track machine learning models. MLflow provides several capabilities that can help streamline the machine learning development process, such as:

    • Experiment tracking: MLflow allows data scientists to track and compare different versions of their models, including the code, parameters and metrics associated with each run.
    • Model packaging: MLflow allows data scientists to package their models in a format that can be easily deployed to a variety of environments, such as a local machine or a cloud platform.
    • Model deployment: MLflow provides tools for deploying models to a variety of environments, such as a REST API or a container.
    • Project management: MLflow allows data scientists to organize their work into projects, including multiple models and associated files.
    • Model registry: MLflow provides a centralized model registry that allows data scientists to store and manage models.

    Pachyderm

    Pachyderm is an open source platform that provides data versioning and pipeline management for machine learning and big data workloads. It allows data scientists and engineers to manage, version and collaborate on large datasets and create reproducible and reusable data pipelines.

    Pachyderm uses a version control system (VCS) like git to version data, which allows data scientists to track and collaborate on data sets and enables reproducibility and rollbacks. This allows tracking the changes in the data, seeing who made the changes and when they were made and rollback to previous versions if needed.

    It also provides a powerful pipeline management system, which allows engineers to create, test and deploy data processing pipelines. The pipeline management system is designed to work with containerized workloads, which makes it easy to deploy and manage pipelines.

    Pachyderm is built on top of Kubernetes, which allows for easy scalability and can be run on-premises or on any cloud provider. It also supports data processing frameworks like Apache Spark and Apache Flink, as well as machine learning frameworks like TensorFlow and scikit-learn.

    Amazon SageMaker

    Amazon SageMaker is a fully-managed cloud-based machine learning platform. It provides a suite of tools for building, deploying and managing machine learning models. It is designed to make it easy for data scientists and developers to quickly and efficiently build, train and deploy machine learning models in a production environment.

    Some of the key features of Amazon SageMaker include:

    • Model building: Amazon SageMaker provides a variety of tools for building machine learning models, including pre-built algorithms and frameworks for popular libraries such as TensorFlow, Apache MXNet and scikit-learn.
    • Model training: Amazon SageMaker allows data scientists and developers to train machine learning models on large-scale datasets, using distributed training and automatic scaling to improve performance and reduce training time.
    • Model deployment: Amazon SageMaker makes it easy to deploy machine learning models to production, with a variety of options for hosting models, including Amazon SageMaker hosted endpoints and Amazon Elastic Container Service (ECS) and Kubernetes.
    • Model management: Amazon SageMaker provides tools for monitoring, updating, and maintaining deployed machine learning models, including automatic A/B testing, canary deployments and automatic model rollbacks.
    • Experiment management: SageMaker experiment management is a feature that allows data scientists to keep track of the different versions of their models, the parameters and the metrics associated with each run.
    • AutoML: SageMaker AutoML is a feature that allows data scientists to automatically explore different algorithms and hyperparameters to find the best model for a given dataset.

    H2O MLOps

    H2O.ai’s MLOps is a platform that allows data scientists and engineers to collaborate and deploy machine learning models in production. It provides a set of tools for model development, management, and deployment, as well as monitoring and governance capabilities. 

    It aims to streamline the process of taking machine learning models from development to production while maintaining high standards of model quality and performance. Some of the main features include:

    • Model Development: It provides a set of tools for developing and testing machine learning models, including support for popular frameworks such as TensorFlow, PyTorch and H2O.
    • Model Management: It allows users to organize and manage models in a central repository, making it easy to track versions and collaborate with other team members.
    • Deployment: It provides an easy way to deploy machine learning models in a variety of environments, including on-premises, in the cloud or at the edge.
    • Monitoring: It offers monitoring capabilities that allow users to track the performance and quality of deployed models in real-time and automatically detect and diagnose issues.
    • Governance: It provides governance capabilities to help ensure compliance with regulatory requirements, such as data privacy, and to help manage the risks associated with deploying machine learning models in production.

    Neptune.AI

    Neptune.ai is an open source platform that provides a suite of tools for organizing, tracking and reproducing machine learning experiments. It is designed to help data scientists and machine learning engineers to keep track of their work, collaborate more effectively and improve reproducibility.

    Some of the key features of Neptune.AI include:

    • Experiment tracking: Neptune allows data scientists to track and compare different versions of their models, including the code, parameters and metrics associated with each run.
    • Experiment management: Neptune provides a user-friendly web interface for organizing and managing experiments, which makes it easy to keep track of progress and share results with others.
    • Reproducibility: Neptune provides a way to reproduce experiments by tracking the code, data, environment and dependencies used in each run.
    • Collaboration: Neptune allows data scientists to share and collaborate on experiments with others and provides a way to track who made changes and when they were made.
    • Model management: Neptune provides a centralized model management system that allows data scientists to store and manage their models, including versioning, testing and deployment.

    Conclusion

    In conclusion, MLOps is a practice that applies DevOps principles and practices to machine learning projects to streamline the process of building, testing, deploying and maintaining machine learning models in a production environment. The goal of MLOps is to increase the speed and reliability of deploying ML models while also improving the overall quality of the models. 

    There are several tools available that can help organizations to implement MLOps, including MLflow, Pachyderm, Amazon SageMaker, H2O MLOps and Neptune.AI. Each of these tools provides a different set of features and capabilities, but all aim to make it easier for data scientists and machine learning engineers to develop, deploy and track machine learning models.

    Image Source 

  • 3 Performance Challenges as Chatbot Adoption Grows

    3 Performance Challenges as Chatbot Adoption Grows

    Today, many organizations are starting to use voice or text-enabled chatbots for the first time or already have chatbot systems in place. In fact, Gartner said 25% of organizations are predicted to make chatbots their primary customer communication channel by 2027. This is because consumer behavior has shifted to primarily digital interactions and away from traditional customer support channels.

    As a result of today’s digital landscape, consumers are now accustomed to immediate gratification and expect instant responses and resolution from customer support, which makes chatbots an ideal solution for brands to rapidly serve customers. Due to this rising demand for instant customer service, chatbot systems have become more sophisticated and consumers’ reliance on them is increasing. This increase in adoption has led to higher performance expectations for bots and if those expectations are not met, customer satisfaction and brand loyalty will suffer.

    Below, we’ll look at three major challenges tied to the growing popularity of chatbots as they handle larger and more diverse groups of customers, and how business leaders developers and DevOps and customer experience (CX) teams can tackle these common challenges with a continuous testing approach.

    The Pain Points of Adoption: 3 Key Challenges as Chatbot Usage Grows

    As the popularity of chatbots explodes for customers around the world, the underlying systems that handle natural language processing (NLP), latency, data security and other functions need to be stronger. This is due to a growing and increasingly diverse demographic of users, many of whom are sharing more of their personal information to address a wider range of customer needs. Common chatbot pain points can be summarized by three overarching challenges.

    Challenge #1: Chatbots must contend with a larger and more diverse base of customers

    Chatbots that are voice or text-enabled must be smart enough to operate securely while navigating countless variations in spelling, a wide range of spoken accents and vernacular, background noise, static from bad connections and more. Even in a single language, there may typically be only four or five “intents” from most customers in engaging a chatbot, but those intents may be phrased in hundreds of different ways. Now, the global growth in adoption raises the chance of poor connections and exponentially increases the number of languages and variations in phrasing that a chatbot must understand and interpret.

    Challenge #2: Customers are trusting chatbots with more personal and sensitive data

    As chatbots become smarter and more trusted by customers to meet their needs, people are getting more comfortable giving their personal data to chatbots. That increases the number of situations where chatbots are working with personally identifiable information (PII) or other highly sensitive data. Especially given GDPR and other data privacy regulations being enacted worldwide, there’s added pressure to ensure a chatbot system’s handling of this data remains secure and compliant across all use cases and geographic regions.

    Challenge #3: Modern chatbots require 24/7 availability and reliability

    In an era of flexible work and millennial and Gen Z audiences interacting with bots after business hours and on weekends, chatbots can’t afford to work in shifts. Users may be spread across many time zones or around the world, meaning there’s always a sizable portion of customers awake, online and looking for fast and efficient service. Because of this, chatbots must be able to handle spikes and heavy traffic 24/7.

    The executive takeaway from these challenges is that modern chatbot investments must be built around dynamic systems capable of adjusting to shifting customer usage and performance requirements.

    A Continuous Testing Mindset is Required for Top Chatbot Performance

    Fortunately, by honoring a few best practices and making the right strategic technology investments in automated artificial intelligence (AI) and machine learning (ML)-driven systems, C-suite leaders responsible for CX and the teams they manage can deploy chatbots capable of keeping up with the above challenges. Perhaps the most central element for success is to embrace a continuous testing approach.

    For example, when a company is undergoing digital transformation and shifting its contact centers and supporting systems to the cloud, they are moving a significant amount of data, reimagining complex integrations and rearchitecting processes. In order to maintain application stability and existing integrations in the contact center, continuous testing is critical to ensure that an organization’s systems still operate effectively throughout the cloud migration process. With continuous testing, development and testing aren’t separate processes. The testing is automated and quality assurance is involved as developers submit code.

    The most effective approach to continuous testing includes end-to-end analysis across all channels. Testing chatbot behaviors should mimic real-time customer interactions. This should include challenging scenarios such as unexpected user inputs and usage spikes at random times of the day and night. Automation is critical, especially in peak demand scenarios such as Black Friday, Cyber Monday, open enrollment, etc. Load testing up to 1,000-100,000 bot requests per second, or more, can help ensure companies will be able to handle the increased traffic. Ideally, the testing approach should be comprehensive to include automated NLP score testing, conversational flow testing and security testing and performance testing and monitoring.

    By promoting the continuous testing approach across contact center operations, executives can empower their teams to build and maintain chatbots that remain optimized on an ongoing basis and that form an essential part of providing exceptional CX. This will make a huge difference in performance and reliability as systems scale and adapt to the evolving demands of a growing customer base.

    Continuous Testing Elevates Chatbot Reliability and Value

    High-performing chatbots and the continuous testing that keeps them optimized at those performance levels can benefit any company by lowering risks and enhancing revenue. Organizations that become adept at applying continuous testing avoid 90% of the downtime from high-severity (SEV 1) errors, which can result in saving $2.2 million in costs over a three-year period. When continuous testing touches every stage of the development process, it identifies issues earlier and helps strengthen an organization’s ability to innovate faster and service its customers effectively and profitably.

  • Looking Ahead, 2023 Edition

    Looking Ahead, 2023 Edition

    DevOps is in a perpetual state of change that keeps all of us engaged and busy, but makes a mess of things overall. Do you cloud-first? Are your APIs GraphQL yet? Are you doing SDN to connect to the VPN so you can put files on the CDN and build closer to the market? Sorry, had to do it. You get the point.

    The point is that the ground is forever changing under us, and often things that seem straightforward are not. Like “cloud-native,” including Kubernetes. Yeah, I get it, you mean software-defined infrastructure that works well with infrastructure-as-code (IaC); this field is confusing enough—calling it cloud is dumb when, these days, cloud has a specific meaning in the minds of IT.

    In our current round of change, a few patterns are showing up. Automation is king. Sometimes it is sold as AI/ML because those are the buzzwords of the day, but it is just continuing the trend of automation to make IT more responsive and predictable. We are rapidly approaching a point where the entirety of the application development/deployment process can be automated reliably and configured to create predictable results. By that I mean that development has more assistance writing code, test has more assistance running tests and processing results, deployment environments can be grabbed from application release automation/orchestration tooling and the final product all of that means that builds can be deployed with very little human interaction unless something breaks.

    Highly automated systems are a prerequisite of high-volume output, though – automobile factories are the easiest example of that statement. My problem is that we don’t seem to be asking “Should we be high-volume producers?” Does the average enterprise require non-stop development? I think that the initial answer is yes, and the more considered answer is “Only because the business wants more, consistently.”

    At some point, the gains we received from DevOps need to be looked at from the “What value is added?” perspective. And that is a business function with IT input. Before SaaS and DevOps made IT easier (to get something running; not minimizing our work here), the business had to consider carefully if it needed that application or that change to an existing one. Today, that consideration is pretty much “Because we want it, put it on the backlog.” But all of our new development adds to our technical debt. While the wave of automation we have been living through since “The Pheonix Project” was first published is keeping us ahead of the curve, we will inevitably need to consider flattening the curve. I suggest that the time is now.

    Getting started with this is actually pretty easy. For many organizations, simply stating, “We do not need two ways to do that” will yield benefits quickly. Other organizations will have to ask “Why can’t we use the functionality of existing tools/apps to do that?” and yet others will need to ask the business, “Do we even need to do that?” Prioritization still exists, and management does an okay job of pushing back at all of the organizations I talk to. Still, at some point it goes beyond “prioritize your wishlist,” and IT managers will have to start asking if a project is even necessary–even if doing so makes waves.

    Continue to rock it, but we’re past time to look for redundancy, synergy and misdirection. There is more complexity coming, and more sweet solutions to problems (both known and unknown) are right around the corner. But, as I’ve said before, simplify as you go because you need to be able to handle the next wave, and eventually, automation won’t cover the gap.

  • Let the Machines Do It: AI-Directed Mobile App Testing

    Let the Machines Do It: AI-Directed Mobile App Testing

    AI has been in the news a lot lately. We’ve all heard a lot about ChatGPT and you’ve no doubt encountered the end result of a variety of other advances in AI technology of late, such as Lensa. But there’s also a much quieter and less visible shift happening behind the scenes during the development of your favorite apps—AI-directed mobile app testing. Let’s take a look.

    Behind the Scenes

    It’s no secret that every product, no matter the industry, goes through a gauntlet of tests before it’s unleashed on the general public. This goes for everything from a simple object like a cardboard box, for example, to a far more complex product, such as the latest electric vehicle.

    The same goes for the mobile apps on your phone. And if you haven’t given that much thought, then good! It means that the QA team behind the app’s functionality did its job, producing a seamless experience that functioned without a hitch, exactly as you wanted and expected.

    But that’s not always the way it goes, and mobile app testing is only growing more complex. That’s a growing problem that AI will eventually resolve.

    If your app didn’t perform as expected, you—and many other users like you—may delete it and move on to the next app that promises to do the same thing. While this may not seem like a big deal to you as the user, it’s a total disaster for the tireless teams working behind the scenes to ensure a successful app launch or update.

    The adage ‘You only get one chance to make a first impression’ is very true in the mobile app market. It’s a big, crowded and cutthroat mobile app world out there, and users simply have no incentive to put up with an app that doesn’t do exactly what it’s supposed to do. After all, for every single app, there are often several others standing by to scoop up your unhappy (former) users.

    This issue is by no means restricted to small development teams strapped for resources. I’m sure you can think of some high-profile software releases from major companies that have launched in a disastrous state over the past few years (particularly in the tremendously profitable arena of video games).

    So why is it that some teams cut corners when it’s time for testing, only to dearly wish they hadn’t?

    Well, the answer is pretty simple: Up until very recently, mobile app testing has traditionally been time-consuming, complex and bewildering, all too frequently delaying releases and flabbergasting QA teams.

    To understand this ongoing problem, let’s take a look at what this kind of mobile app testing entails and how this landscape has recently started to shift, as well as what’s on the horizon to make it all more efficient.

    Cutting Corners = Consequences

    Once upon a time—in an era that seems like it was really just yesterday—software testing was performed manually, entirely by hand. This was possible because quality assurance personnel only needed to consider a very limited set of variables: There were only so many use cases and form factors to consider, and programs were only expected to do so much.

    It’s hard to imagine testing a modern app manually and having the result be effective. The approach is only reasonable under very limited circumstances. Nowadays, teams use automated tests, which save them a tremendous amount of time, effort and resources.

    Yet these automated tests come with their own problems. Most of these automated tests are hand-coded, meaning that they must be set up and adjusted by specialists with a background in computer programming. Such specialists are not only costly and in demand, but they’re also needed for later aspects of the software development cycle, such as developing new product features and overseeing other aspects of production.

    And this is where companies start to cut corners and miss problems and issues, both large and small. Instead of what is known as shifting left (that is, testing as early in the cycle as possible), many teams, unfortunately, view testing as a burden or afterthought. Only when things go haywire and they have a full-blown crisis on their hands does the need for rigorous app testing become apparent.

    Testing, Machine-Made

    This is where machine learning and artificial intelligence enter the picture. For several years, we’ve known that testing performed by machines will be more and more necessary to handle increasingly complex apps, and it won’t be long before the cost associated with the complex testing scenarios will simply become too much for many developers.

    Fortunately, advances continue to appear on the horizon. These include the much-discussed no-code revolution, which abstracts away much of the noise associated with software development and opens the door to a much wider testing base.

    AI- and machine-learning-based testing is also on the horizon, yet there’s a significant challenge that must be overcome before this can happen at speed and scale. To develop mobile app tests with true intelligence and maximum efficiency, machines must be capable of autonomously completing the following steps:

    1. Comprehension: Draw from the ability to understand what’s changing in an app. For example, the machine must be able to detect differences and issues in a signup sequence or a checkout screen change.
    2. Impact analysis: The machine must know what test cases can cover that change. This sort of identification can be quite tricky.
    3. Test case generation: Next, the machine must possess the ability to generate test cases related to steps one and two. To do this, the machine must draw from several data sets. These include:
      1. Extent test collateral/test cases with product code
      2. Data from actual customer usage so that numbers one and two above may be identified
      3. What user environments look like, including information like how many users are active in the United States and in Europe
      4. Automatic execution: Perhaps the most crucial need is that the machine can perform testing entirely by itself. With the ability to self-execute tests, we’ll have reached a new era in testing.
      5. Reports: Before the testing cycle can begin again, the machine must be able to produce detailed reports that make sense to its human handlers. When it comes to test results, the more detail the machine can provide in as approachable a manner as possible, the better.

    Problems and Solutions

    Some testing platforms are now capable of many of the tasks I highlight above, and quality assurance teams that move away from self-coding tests and toward the future of testing stand to benefit from these solutions (particularly when their competitors do not).

    Partially enabled by AI and ML, no-code solutions provide a stopgap solution until machines can really get a handle on the above five steps. At this point, it’s really just a matter of time: We can already see glimpses of a wholly automated testing cycle where human input is limited and machines do the heavy lifting.

    It’s easier than ever to imagine a world where there’s no need for testing to be an afterthought and software disasters have become a thing of the past.

  • What DevOps Needs to Know About ChatGPT

    What DevOps Needs to Know About ChatGPT

    OpenAI’s generative pre-trained transformers (GPTs) bring powerful AI language models to every IT community. Within the past few months, ChatGPT has become an incredibly popular derivative of GPT. GPT also has the potential to shake up the DevOps and DevSecOps communities. This article will provide an overview of GPT, its history, current status and future effects on IT, especially DevOps. 

    Learning Overview

    Understanding the difference between supervised and unsupervised learning is essential before understanding GPT. Machine learning and artificial intelligence (AI) use unsupervised and supervised learning approaches. A supervised model uses labeled data to predict outcomes, while an unsupervised model does not. In general, supervised models have some limitations. They need a large amount of annotated data to learn a particular task, which is often unavailable, and they also need to generalize beyond the task for which they were trained. 

    A generative language model is a class of statistical models that differ from discriminative models. You can, for example, generate photos of animals that look like real ones using a generative model. Whereas with a discriminative model, you can determine whether an animal is a dog or a cat. Generative models can assign probabilities to a series of words, such as those that predict the next word or sentence. A generative pre-trained transformer is unique because it uses both unsupervised and supervised learning from unsupervised unlabeled text and follows up with discriminative supervised fine-tuning. 

    GPT-based models—ChatGPT, for example—always return the text “I am” when asked, “I think, therefore …” On the other hand, if you ask ChatGPT, “Why did the rabbit cross the road?” it may respond thusly: 

    “The age-old riddle still awaits an answer: Why did the rabbit cross the road? It’s a mystery that has stumped people for centuries and will likely remain an enigma for years to come.” 

    In this way, we can better understand how GPT-3 works. When asked, “Why did the rabbit cross the road?” most humans will answer, “To get to the other side.” A Google search for “Why did the rabbit cross the road?” mainly yields joke punchlines on the first page of the results. GPT doesn’t differentiate between humorous or cynical answers or specific matter-of-fact answers. The model makes only guesses based on the data. Since, in this example, most of the highest-ranked answers are jokes, GPT’s answer is enigmatic at best. GPT is not pixie dust; it doesn’t have a sense of humor, is not sentient, doesn’t understand juxtapositions and, most importantly, doesn’t evaluate context. As another example, I asked a GPT-3 tool to provide biographical information about two individuals. Abraham Lincon was the first. Approximately ten paragraphs of accurate facts were generated by the GPT-3 tool. Second, I used Gene Kim, the author of The Phoenix Project and The DevOps Handbook. GPT-3 began inventing facts about the companies he worked for by the second paragraph. Additionally, it suggested that he had spoken at TEDx. While a Dr. Gene Kim has spoken at TEDx, that Dr. Kim is an opthamologist.

    History of GPT

    GPT was released for the first time on June 11, 2018. Sometimes it is referred to as the  GPT-1 model. A large dataset of online books was used to train it. A database called BookCorpus also was used for training. There were 7,000 unpublished books in the original BookCorpus dataset at the time of training. 

    OpenAI’s GPT-2 model was created in 2019 as a direct scale-up of the original GPT model. There were ten times as many parameters and ten times as much data in that training set. The GPT-2 dataset was based on an internal OpenAI dataset called WebText. A focus was placed on the quality of the documents when scraping web pages for this tool. The authors scraped all Reddit outbound links receiving at least three upvotes. GPT-2 used about 40GB of Internet text, 8 million web pages, and 1.5 billion parameters. In neural networks, parameters are often used as synonyms for weights (found more often in statistics literature). Parameters in GPT are the weights and biases of the dataset and generally indicate the power. 

    As the third-generation language model, GPT-3 was introduced in May 2020. It has 175 billion parameters, making it more accurate than its predecessors—an increase of tenfold in capacity over the next largest NLP model available. Sixty percent of GPT-3’s weighted pre-training dataset is filtered Common Crawl. Common Crawl is a nonprofit organization that crawls the web and makes its archives and datasets freely available. Since 2011, Common Crawl has collected petabytes of data. About 37% of the GPT-3 sources were WebText2 and other sources, while about 3% came from Wikipedia. OpenAI Codex was also included with GPT-3, which generated code and served as the basis for GitHub’s Copilot. 

    As part of its training, GPT-3 used data available until November 2019. Thus, GPT-3 was unaware of events beyond January 2020. COVID-19, for instance, was unknown to it. Even so, it did have extensive knowledge of coronaviruses, pandemics, Wuhan and SARS. As of September 22, 2020, Microsoft, through a considerable investment, received exclusive permission to use GPT-3; others can still access GPT-3’s public API, but Microsoft is the only one with access to the underlying model. OpenAI developed DALL-E in January 2021, which generated images using GPT-3. OpenAI introduced models in the “GPT-3.5” series on November 30, 2022, including the now-famous ChatGPT, derived from a model from the GPT-3.5 series. Unlike GPT-3, GPT-3.5 includes data up until November 2022.

    Current Status

    I have used several AI language model tools in the past few years based on GPT-3. It is used by Grammarly and by some useful writing tools like Jasper.ai and Wordtune. I also have had great success with GPT-3 research tools like Frase.io and Genei.io. One of my more recent go-to tools is called QuillBot. In my experience, these tools are aids, not replacements for writing. When I first started using these tools, I was writing a book about Dr. W. Edwards Deming. I would get inaccurate information about Dr. Deming’s childhood from a GPT-3-based tool. One time, it said he had six siblings. In fact-checking, GPT-3 confused Dr. Edwards Deming with Dr. Richard Deming. With surgically precise input, the results could be more accurate. One of my findings was that if I used a GPT-3 on a well-known subject, the information was primarily precise; however, lesser-known topics produce fewer facts. Furthermore, I learned from the documentation that when people talk about training GPT-3 models, what they really mean is that you can input a maximum of 2,048 linguistic tokens, which is about 1,500 words. In GPT-3, content is predicted by analyzing past context, one word at a time. The content you input to GPT-3 significantly impacts its output. As a result, it pulls words from a shortlist and calculates their probability of being used. A great set of tutorials on using GPT-3 can be found on Jasper.ai. This figure shows how Jasper (which is based on GPT-3) word prediction works.

    Image source

    People have accomplished some remarkable things by using the 2,048 tokens creatively, but complex training still needs to be improved. Due to the Microsoft deal, the original GPT models were close sourced, and robust training of GPT-3 models is unlikely to happen any time soon. 

    Future Effects on IT

    Where does all the hype come from? Despite its limitations, GPT-3 has created some unique industry artifacts. DALL-E and Copilot by Github are excellent tools. On September 8, 2020, the Guardian published an article titled, “A robot wrote this entire article. Are you scared yet, human?” This article was written by GPT-3. Using GPT-3, some full-blown novels have also been written; they’re not horrible, but they could have been better. According to a study conducted by Drexel University in 2022, systems based on GPT-3 could be used to screen for Alzheimer’s disease at an early stage. Just five days after its launch, ChatGPT surpassed one million users. It took 41 months for Netflix to reach one million users and 10 months for Facebook to reach one million users. By the end of the first quarter of 2023, ChatGPT will have over one billion users. Based on GPT-3.5, ChatGPT is more robust and up-to-date. 

    How smart is ChatGPT? Using a verbal-linguistic IQ test and Raven’s ability test, ChatGPT has an IQ of 147. GPT-3.5 has passed the United States bar exam, CPA exam and U.S. medical licensing exam. People often ask if it is plagiarism to use GPT-3. Technically, the answer is no. The GPT datasets are estimated to represent 300 years of pre-training with a connection of trillions of words. However, using these tools for rewriting other people’s work is, from an ethical viewpoint, plain and straightforward plagiarism. A recent set of tweets by Greg Brockman, president and co-founder of OpenAI and Sam Altman, CEO of OpenAI, sums up the current status of ChatGPT.

    What Does This Mean for DevOps Practitioners?

    AI learning models based on GPT-3 are here to stay. From grammar correction to proposal writing to code generation, GPT-3 has revolutionized everything. In my opinion, GPT-3 still needs to solve some challenges before it is of actual value to DevOps and DevSecOps patterns and practices. For example, a great use case for GPT-3 is training it to deal with organizational incidents. If a GPT model could be trained this way, it would become an excellent tool for providing adaptive diagnostics. Based on the current GPT implementation, this is very difficult or impossible. Another example would be to train the model with the organization’s IT risk policies and enable predictive solutions. The opportunities are endless. 

    An alternative to GPT-3 is InstructGPT, which OpenAI describes as more truthful and less toxic. It has also been noted that GPT-3 can generate untruthful outputs. GPT models aren’t generally aligned with their users. InstructGPT models follow instructions much better than GPT-3. Furthermore, InstructGPT produces more truthful and less toxic outputs. Therefore, they generate fewer harmful outputs and more facts.  The InstructGPT models use human feedback as part of the training model. Some of the real power behind ChatGPT is that it uses InstructGPT along with GPT-3.5. Some of my upcoming research will focus on prototyping some of the complex opportunities DevOps and DevSecOps practitioners currently face using InstructGPT. 

     

  • 8-Bit Floating Point for AI/ML? | Amazon and Microsoft Shed Tech Jobs

    8-Bit Floating Point for AI/ML? | Amazon and Microsoft Shed Tech Jobs

    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: New ideas bring low-power ML inference, and more big-tech jobs are going. (more…)

  • A DevOps Thanksgiving: What Are You Thankful For?

    A DevOps Thanksgiving: What Are You Thankful For?

    As crazy as it seems, here we are on the cusp of another Thanksgiving. This year has gone by so quickly, and as we enter the holiday season and the end of 2022, those of us in the DevOps community have much to be thankful for. First and foremost, I’m so happy to once again see my colleagues and friends in-person at conferences and events around the world. I’m looking forward to resuming travel not just in the U.S. but the rest of the world and seeing DevOps enthusiasts share their knowledge, their experiences and further the state of DevOps.

    While we are thankful for the resumption of a more normal lifestyle, we also need to pause to acknowledge and mourn for those we’ve lost during this terrible pandemic. Their lives and the time taken from all of us during these past years can never be replaced.

    They say every dark cloud has a silver lining; if there was a silver lining for DevOps during the COVID-19 pandemic, it was the unprecedented pace of digital transformation. Make no mistake—digital transformation is powered by software development and DevOps powers software development. It wasn’t just the sheer number of applications or lines of code that were developed and deployed during these past few years, but the accelerated maturity of software supply chain software pipelines that became the de facto standard for how software is developed and deployed; that was greatly accelerated as a result of the push to digital transformation.

    It was not just software development that was accelerated, software supply chain attacks gave rise to an entirely new subset of security. Software supply chain security and SBOMs are now everyday words in the security lexicon. While I’m not happy about an entirely new class of attacks, I’m grateful for the response the White House and the U.S. government gave to our industry as a whole to address software supply chain attacks. I’m also grateful for the continued evolution of tools and techniques, people and processes around DevOps.

    While some look to make marketing hay by proclaiming that DevOps is dead and other such nonsense, the truth is that DevOps is thriving. It is the way software is developed today. In fact, in conjunction with cloud-native, it would seem that we have a whole new stack and an entirely new way that software is created.

    Looking forward, on the horizon we continue to see the development of AI that is making a real impact on observability, testing and application management. I think we’re also on the verge of AI having a profound impact on software development, as well. Low-code/no-code development tools paired with AI promise to take some of the most mundane software development tasks and automate them. This will free up overworked software developers to focus on higher-value software development tasks.

    Despite macroeconomic conditions putting a damper on the entire tech space (if not the entire world economy), I remain enthusiastically bullish about the continued growth and maturation of DevOps and I am excited to see what the weeks, months and years ahead bring. I am grateful to be involved in our industry during these heady times, and I’m grateful to you, our readers, supporters and the community for your continued support of our company.

    To that end, I wanted to announce that we’re trying something new this year at Techstrong Group, and we hope you’ll join us. We want to know what you believe makes tech strong—and we’re asking people to record a quick TikTok video or LinkedIn video with the hashtag #Techstrong. We’ll select the winners and are giving away two (2) Sony PlayStation5 game consoles to the best two entries as selected by our judges. You can get all the details on our social media channels on Twitter, Facebook and LinkedIn.

    So, now you know what I’m grateful for—we really want to hear what you’re grateful for and what you think makes tech strong! Throughout the holidays and the new year, we wish you health and happiness—and know that tech will remain strong!

  • OpsVerse Adds Backstage Catalogue to Managed DevOps Service

    OpsVerse Adds Backstage Catalogue to Managed DevOps Service

    OpsVerse this week added an open source Backstage catalogue software for building developer portals to its managed DevOps service.

    Originally developed by Spotify, Backstage makes it possible to centralize the management of multiple services that are being built and maintained by multiple developer teams. Backstage is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    OpsVerse CEO Arul Francis said the company is now employing Backstage to create a centralized control plane dubbed OpsVerse ONE through which organizations can more easily centralize the management of a DevOps toolchain. Every applications team can see all the services and related resources they own and then via a single click launch a project, he noted.

    The managed OpsVerse platform is based on curated editions of open source software such as Argo continuous delivery (CD) and Prometheus monitoring software that OpsVerse enables organizations to access as a set of software-as-a-service (SaaS) applications. Those applications can then either be deployed in cloud platforms made available by Amazon Web Services (AWS), Microsoft or Google or in an on-premises IT environment.

    The addition of OpsVerse ONE will also make it simpler to extend the OpsVerse toolchain via more than 80 plugins that are currently available for Backstage catalogue software, noted Francis.

    It’s not clear what degree organizations are embracing managed DevOps platforms but at the very least smaller organizations should find it simpler to embrace best DevOps practices by relying on a managed service. There are also plenty of larger organizations that may determine that continuing to manage DevOps toolchains has become problematic after years of integrating various tools and platforms in ways that now are both challenging to maintain and secure. OpsVerse claims to have in the last six months already tripled the number of customers it supports.

    As application development becomes more complex to manage in the age of microservices, many organizations are at a crossroads. They need to decide to what degree it makes sense to continue to devote resources to managing DevOps platforms versus consuming them as a cloud service. Many of the resources that are now allocated to managing DevOps platforms could theoretically be shifted toward building and deploying more applications. In some cases, organizations may decide to continue to rely on legacy DevOps platforms to maintain existing applications while employing a cloud service to build modern cloud-native applications that have many more dependencies than monolithic applications.

    Regardless of the degree to which organizations decide to rely on managed services, platforms such as Backstage as it continues to evolve will make it simpler to extend open source toolchains. Spotify developed Backstage to bring some order to its own internal application development and deployment processes before deciding to contribute Backstage to the open source community. While Backstage is still an incubation-level project within the CNCF, it’s already being used across multiple DevOps production environments to make it easier to integrate additional tools without having to sacrifice their ability to centrally manage a DevOps environment.