devopsy.kinsta.cloud

Tag: DevOps

  • Agile Planning With Generative AI

    Agile Planning With Generative AI

    Generative AI will eventually impact the entire DevOps life cycle from plan to operate. I started as a developer but have been a product manager for most of my career; for me, the ‘Holy Grail of DevOps’ would be one where product managers (PMs) and business analysts (BAs) were able to define a future state of a business process and press a button to deliver it without any developers, designers or testers involved.

    This dream is not practical in the near term and is not really desirable in the long term, either. PMs and BAs are good at understanding the needs of users and translating them into features but aren’t interaction designers. AI may be able to generate code and tests, but the software architecture for both will still require a deep understanding of the system to structure the solution properly, especially in enterprise SaaS development. So my dream is to build a team where the BAs can define the changes and a small team of very talented architects and interaction designers can realize those changes in 10% of the time it takes today without requiring a large team to implement the details. This is similar to what has happened in manufacturing where robots and numerically controlled machines are able to do the heavy lifting with the help of operators.

    Planning is Key

    When generative AI is actually building the solution, proper planning will be the entire key to success. A well-documented, well-thought-out plan will enable the AI to finish most of the heavy lifting. So the majority of the focus for the dream team should be to get the plan right and to document it at just the right level of detail. Just like I was taught by my first Agile coach 20 years ago, when it comes to documentation, you need just enough just in time.

    In enterprise SaaS platforms like Salesforce.com and ServiceNow, the business starts with a newly implemented system in some initial implementation and then incrementally customizes this software to better meet their needs over time. So, instead of thinking about building a system from scratch, we must think of digital transformation as the continuous improvement of an existing system over time. That means the AI must start with a good model of the

    ● Existing business processes,
    ● Metadata configuration of the system and
    ● Dependencies between the settings.

    Development in the New World

    What does this mean in practice? Let’s look at a day in the life of the dream team.

    The BA will start by telling the AI what changes are desired at a high level. The AI will help refine the requirements by filling in missing details. This will happen through an iterative process of expanding, refining and summarizing until the requirements are clearly defined. Just as lint tools check source code today, the AI will examine the requirements to ensure the user stories are complete, with acceptance criteria well defined. During this process, the AI will do a detailed dependency and impact analysis to provide a heads-up to the BA when there are any unwanted side effects.

    This refinement session will be more of a conversation between the BA and the AI than a one-sided writing session. After several iterations, a complete set of user stories will be created with all of the necessary details spelled out.

    Once the requirements are complete, the BA will be joined by a user interaction designer and software architect.

    The interaction designer will define the interaction spec through a combination of natural language description of the new processes and a functional prototype. Both of these elements will be created and refined through interactions with the generative AI. Prototypes will no longer be simple graphic artifacts to be coded by front-end engineers. The AI will generate a working prototype in the framework of your choice on demand through a combination of verbal requests and traditional point-and-click.

    They will review the plan and begin designing the solution’s architecture which will result in a natural language software spec that documents the data model changes and high-level specifications for the classes that make up the solution. It is likely that the data model changes will be created in a dev environment on demand, with the ERD updated to reflect the new model.

    Depending on the type of changes, the architect and interaction designer may collaborate and iterate on the specs until the “how” is well defined. When the design is ready, the dream team will meet to review the design and sign off on the approach.

    Generate and Iterate

    Once the plan is approved, it’s time for the AI to generate a first-pass solution. We hope and expect that generating the solution will be something that happens in minutes. In this scenario, the dream team will take a coffee break and then come back to the meeting room to review the working solution.

    There is nothing like playing with the actual solution to remind you of the edge cases you forgot or to realize how tedious it is to actually use a new feature. But that’s okay because the team can quickly update the requirements to account for these changes and push the generate button again.

    In fact, they can tinker to their heart’s content. But like all great artists, they must decide when it is good enough to ship.

    In the near term, we will not be able to blindly rely on generative AI, so the architects will have to do code reviews, just as they do today with junior developers. Likewise, the AI may not understand all of the possible dependencies in a system. So there will be a transition period where the process is semi-automatic.

    Eventually, the notion of a two-week sprint will seem anachronistic and a daily cycle of define and release to production will be commonplace. Members of the dream team will spend more time worrying about the high-level usability and effectiveness of their designs and less time struggling with actual implementation, which should make their jobs much more rewarding and the work product much better. I am looking forward to it.

  • The DevOps Pendulum: Agility Vs. Control

    The DevOps Pendulum: Agility Vs. Control

    Managing changes to cloud assets is a universal pain felt by many engineering leaders today, despite all of the advancements in tooling and practices like GitOps. This is because, in reality, it is simply impossible to always have everything completely locked down—we don’t live in a utopia with zero incidents. If your engineering organization prevents any changes from being made through the cloud console or to your infrastructure-as-code (IaC) without complying with strict GitOps practices or change management processes via CI/CD, then it’s likely you have very frustrated developers—developers who can’t troubleshoot or debug in real-time and who have little control in a real-world incident.

    Engineering, like everything else in life, is all about balance.

    The Pendulum Swings

    The pandemic created a whole new mindset and practice for managing distributed and high velocity engineering and operations. Overnight, companies that were not built for remote ways of working had to continue their operations in a global, distributed and asynchronous way that they weren’t completely familiar with. This required a new way to think about software delivery—and it accelerated the DevOps practices that support that delivery. Self-service infrastructure removed barriers for developers to ensure continued performance and velocity.

    At the same time, your cloud cannot be the wild west with everyone creating bespoke infrastructure. It becomes impossible to manage, and misconfigurations can be risky. Guardrails and policy automation have become a hot topic. Today, with tech markets depressed and cloud costs escalating, there seems to be a growing trend toward locking things down again, even at the risk of frustrating developers.

    This begs the question: How can you achieve unencumbered infrastructure for your developers while simultaneously following policies and best practices for compliance, risk and cost? There is a way to find balance.

    Like many aspects of security, we’ve learned that when constraints and barriers are too high, users ultimately find ways to bypass them. This is true for operations, as well. While sometimes it might seem easier to lock everything down than design a better and more balanced way to enable developers to move fast, eventually this approach backfires. This is the exact same evolution the application and cloud-native security industry are undergoing right now.  All the guardrails and controls applied have created too much friction in development processes and developers ultimately bypass them.

    Real-Time Insight is Key

    CloudOps can learn a lot from the disruption the security industry is going through today. In the same way that point-in-time security has been rendered completely useless, non-real-time alerting or eventual alerting to infrastructure drift just won’t cut it when managing an ephemeral cloud. What is really needed is the same kind of real-time and continuous scanning of cloud assets and IaC, similar to what we apply to our systems through monitoring and observability. These solutions became an essential backbone of our business to ensure continuous operations and availability of cloud services.

    As we embrace IaC and the benefits it brings, everything-as-code unlocks greater agility and visibility, enabling you to automatically remediate without locking everything down. As DevOps says, “fail forward and fail fast.” Rather than focusing on never making a mistake, focus on how to fix it immediately. 

    The Solution

    By providing a continuous comparison of actual cloud assets with their desired state through IaC and GitOps, it’s possible to surface configuration drift and policy violations immediately, much like any other kind of breach or major system failure. Failures and incidents are inevitable. It’s unrealistic, and even dangerous, to build systems with an inherent underlying design that prevents you from changing something at the cloud console at 2:00 A.M. during an outage.

    With a locked-down approach, a developer would need to wait for the change management approval during a high-pressure production incident, oftentimes at 3:00 A.M. (because the incident gods of always make them happen in the middle of the night) or on a weekend. We don’t need to look much further than the catastrophic 40-minute and $440 million Knight Capital incident to understand that sometimes time is not on our side and that a delay can have severe consequences.

    Cloud drift has become equally troubling as uptime or any other mission-critical aspect of continuous business operations, and that’s why we need to apply the same principles for monitoring drift in real-time as we do to our CPU and load. This will make it possible to be alerted when your cloud and your IaC are no longer aligned and even flag issues that can be prevented in real-time. You can automate ticket creation and escalation and also triage whether this is something that needs to be fixed in real-time with remediation suggestions provided or open a ticket to fix it later. The choice should be yours, not made by an administrator who has a lot less context about the systems and the ultimate business impact.

    It is Not ‘One and Done’

    Some vendors preach codifying your cloud into IaC and then locking it down so that you’ll never have to do it again. This feels like deja vu; we’ve definitely heard this before. It sounds a lot like the ‘write once, deploy anywhere’ JVM promise that never quite panned out. 

    By going down this path, you’re resigning yourself to never adding new cloud assets or changing your cloud configurations. If there’s one thing we’ve learned about the cloud, it’s that it’s a constantly moving target.  (Read what cloud asset management can learn from the world of finance—another industry in constant flux). If this didn’t work decades ago with the JVM, it certainly won’t work in a dynamic and constantly changing environment like the cloud. That’s a fool’s journey.

    Continuous Cloud Up to Code

    There are major downsides of locking down agility and velocity. This is hard-earned advice, witnessed firsthand from tools like legacy CMDB and startups who have forgotten that cloud is ephemeral—and possibly the reason why we all use it in the first place! So if our cloud is constantly changing and is a continuously moving target, then shouldn’t our tools be built in just the same way to keep up? Solutions built for the rapidly evolving cloud-native era must continuously look for new, unmanaged and changed assets and ensure their cloud infrastructure always follows policies and regulatory standards.  

    Once we are able to find the balance between agility and control, we’ll be able to tap into the benefits of speed and safety (as DORA research shows time and again) that are the benchmark of high-performing teams. Automating cloud asset management can provide governance, policies and control while still enabling the velocity and agility engineering organizations today require. 

    Agility Versus Control

    There’s a minority of people who claim they don’t worry about cloud asset configuration drift because they have everything completely locked down. Zero changes can be done at the cloud console or to IaC without going through GitOps for strict change management processes via CI/CD. I bet they have happy developers—not!

    Life is All About Balance

    Throughout the pandemic, organizations had to make developers happy for fear they would leave. So DevOps went full tilt aiming for self-serve infrastructure for developers to remove barriers to speed and velocity. Now, with tech markets depressed, maybe it’s easier to lock things down even if that risks losing engineers.

    As we embrace IaC and its benefits, you need not live in the stone age of locking everything down. How can you achieve unencumbered infrastructure for your developers while following policies and best practices for compliance, risk and cost? There is a way. 

    The solution? Real-time continuous scanning of your cloud assets and your IaC with continuous comparison can surface configuration drift and policy violations immediately. Emergencies are inevitable. It’s bold/stupid/foolish to think you’ll never need to change something at the cloud console during an emergency or that a developer will wait for change management when production is down at 3:00 A.M. on a weekend. It happens, and you must deal with it. 

  • 4 Things Engineering Leaders are Thinking About Right Now

    4 Things Engineering Leaders are Thinking About Right Now

    Spiderman and engineering leaders have something in common: They both have great power and great responsibility. Engineering leadership is more critical than ever, with more than 4.4 million software developers in the United States building our experiences daily.

    Leaders do more than just manage the day-to-day. They are called to influence, empower and motivate their teams. For engineering leaders, this means grappling with new challenges and opportunities as the technology landscape changes and evolves. This shift impacts how humans work, where we work, what our work looks like and how we need to be supported and seen in our roles across the board.

    Let’s dive into four challenges and opportunities that engineering leaders face and how they shape the future of software engineering.

    Communication in Remote & Hybrid Work

    It has been over three years since the way that we work shifted dramatically. Choosing the right fit between remote, hybrid and in-office is a challenge that companies across industries are still wrestling with. The hardest part? Communication.

    There’s no doubt that the flexibility of remote work is beneficial for workers’ mental health. The 2022 State of Remote Engineering Report found that developers reported better work-life balance (64%) and less stress (48%) from working remotely. However, they also reported that collaboration and inclusion took much more effort. Although flexibility is good for mental health, it may hinder spontaneous interactions. And although in-office work fosters face-to-face collaboration, it may limit geographical diversity. Striking a balance is top of mind.

    No matter what the office structure is, engineering leaders must establish clear communication channels, guidelines and regular check-ins with their teams. Engineering metrics are a great way to identify and address the wins, challenges, solutions and bottlenecks. They help leaders foster an environment that encourages collaboration, cross-functional teamwork, and knowledge sharing through regular team meetings, brainstorming sessions and collaborative projects to promote engagement and a sense of collective ownership no matter where teams and team members work.

    Generative AI

    Generative AI is top-of-mind for the whole world right now. It’s an exciting and potentially stressful time for engineering leaders to consider how generative AI may reshape the way we work. While there is a fear of AI replacing human roles, a more positive (and realistic) way to look at AI is by asking: What will this revolutionize, evolve, and enhance and what are the risks?

    Developers are thinking primarily about the emergence of large language models (LLMs) for code creation. Leaders should consider how AI can integrate into workflows to increase development speed, accuracy and efficiency. This is also an opportunity to enhance and leverage AI for tedious tasks so developers can focus on creative projects.

    Leaders must also consider the risks of generative AI. AI simply cannot replicate the complexity of the human experience, which will call for a layered approach to integrating AI into engineering teams. It also begs the question: What responsibilities do engineers have when working with AI? The benefits of streamlining, speed and accuracy may also alter what quality control and testing look like. It’s an exciting time for engineering leaders to embrace the future of work mindfully and strategically.

    Meaningful Metrics and Outcomes

    Engineering metrics are vital for measuring impact and outcomes to drive progress and inform decision-making. Engineering leaders must carefully evaluate and select metrics that align with their team’s objectives and adapt measurement practices accordingly. DevOps Research and Assessment (DORA) metrics are popular, serving as a jumping-off point for engineering leaders. When leaders carefully evaluate DORA metrics as applied to their team’s specific objectives and complement them with other relevant metrics, they can ensure that they capture the desired outcomes and provide a complete picture of engineering health to drive meaningful purpose.

    The added pressure to deliver results while upholding developer morale and efficiency underscores the significance of choosing appropriate evaluation methods that capture the desired outcomes. But most importantly, leaders need to consider what metric visibility means and how best to offer support.

    Fostering Engineering Team Health

    Besides technical aspects, engineering leaders are increasingly concerned about the health and well-being of their teams. Balancing meetings, focused work time and creating a positive work environment are vital factors that contribute to developer health and productivity. Engineering leaders should consider the individuals and team when encouraging breaks, time off and flexible working hours to prevent burnout and promote overall well-being. Some teams have implemented “No Meeting Wednesdays” and similar strategies to provide dedicated time for deep work and to minimize interruptions.

    Leaders should be focused on creating a culture that prioritizes psychological safety where team members feel comfortable expressing their ideas, concerns and feedback without fear of judgment or reprisal. In this fast-paced world, a leader must remember to be human first and encourage open communication, active listening and empathy within the team. Prioritizing collaboration, work-life balance and a healthy team dynamic is critical for engineering leaders aiming to foster long-term success.

    Engineering Leaders Have Great Responsibility

    Engineering leaders are at the forefront of shaping the future of software engineering. Balancing communication in remote and hybrid work environments, leveraging the potential of generative AI, choosing meaningful metrics and outcomes and fostering team health and well-being are critical areas they must address. By embracing these challenges and opportunities head-on, engineering leaders have the power to drive success and create thriving, innovative teams. So, let’s step up to the plate, embrace the evolving landscape of software engineering, and lead with purpose, empathy and strategic vision. Together, we have the power to shape a brighter future for the world of technology. With great responsibility comes great opportunity. Are you ready to don your leadership cape and web-sling your way to success?

  • Considering Scriptless Automation: iOS App Dev in 2023

    Considering Scriptless Automation: iOS App Dev in 2023

    According to Statista, over 31,000 apps were released on Apple’s App Store in March 2023. As impressive as that is, it’s considerably smaller than the number of apps submitted to the Apple store during the same month.

    And it’s probably less than the number of apps removed from the App Store.

    Why?

    According to Apple, most submissions fail because of common issues like bugs, crashes, incompleteness, placeholder data and broken links.

    But getting app approval is just one of many challenges faced by iOS developers today.

    Contemporary iOS App User Expectations

    The truth is, even if you slip by Apple, there’s an even greater critic to be concerned about: Your audience. Users are much less forgiving and have high expectations. If your app isn’t perfect, you’ll lose your chance at meaningful adoption and your users will just go elsewhere.

    For iOS users, perfect is simply the status quo, and users have grown to expect it. In practice, this means that apps must be stable across devices and versions, see regular improvements. and provide a great user experience at all times.

    Seamless experience between devices, versions and iterations
    iOS users expect the same experience across multiple devices. From one iPhone to the next, from version to version and from screen size to screen size. It’s the responsibility of developers to prioritize a consistent experience across devices.

    Fast release cycles and regular updates
    Contemporary app users demand feature-rich applications that go above and beyond the simple functions they expect from an app. Given the statistics above, chances are that the competition is fierce. Achieving success usually requires an efficient and speedy release cycle with more planning, more deployments and more testing.

    Easy and frictionless user experience
    User experience (UX) and functionality are one of the big reasons iOS adoption is so strong. People have come to expect high quality from anything under the Apple banner: Users expect an intuitive and trouble-free user experience on every app with which they interact. Every user’s experience needs to be intuitive, issue free and consistent with other iOS applications.

    Challenges Abound

    Meeting those escalating user expectations comes with a wide variety of challenges. For example:

    Device landscape fragmentation
    With so many device types and form factors in circulation, how do you test across all of them? With dozens of iterations of the iPhone combined with an array of versions, screen sizes and configurations, app developers need a way to test on enough devices to cover the majority of their user bases.

    This leads many developers to turn to simulators and emulators to cover devices they lack access to.

    This poses another problem. Simulators aren’t perfect. A simulator doesn’t replicate the functions of the actual device; it can only mimic certain aspects of an iOS device. And it simply can’t effectively mimic hardware, component functionality or network.

    Using a simulator, you can’t test how an application will respond to factors like low battery, a rising network spike, or limited memory, not to mention GPS and camera functionality. You also can’t monitor usage metrics or run meaningful performance tests.

    Real devices present their own challenge. The vast majority of the time, developers will have to worry about the cost of acquiring, storing, maintaining and updating devices. In addition, they’ll have to centralize and control access to them. In an increasingly remote workforce, it’s not a great strategy.

    Manual tests
    Today, most organizations are over-reliant on manual testing. The result? Running test cases becomes the bottleneck that holds up releases. Sure, manual testing is unavoidable in some cases, but their ad-hoc, inconsistent nature leaves room for error. No matter how detailed the instructions may be, people test differently, and that’s a disaster waiting to happen in today’s complex software world.

    Maintaining complex test scripts
    If you’re automating test cases, you’ve experienced the pain of maintaining code-based test scripts. Every release requires coinciding updates to countless unit tests, integration tests and UI tests. The smallest changes can break test cases, causing false negatives and more deployment delays.

    On top of that, you’ve also got to worry about retaining talent that understands your language-specific testing framework. Given the economic uncertainties of today, that’s certainly not a good situation to be in.

    Constant iOS updates
    Each year sees Apple deliver iOS major releases and a variety of minor releases, patches and bug fixes. Organizations have to test after two release cycles: Their own and Apple’s. Failure to do so can lead to compatibility and App Store compliance issues.

    App store guidelines
    As I mentioned above, Apple maintains strict guidelines for any apps published on the App Store. Excellent testing can mean the difference between releasing an app or waiting another few weeks for the next approval. When time is money, this adds up fast.

    Security at scale
    As requirements change, scope increases and features add up, it’s easy to see how it can become more and more challenging to monitor for potential security flaws. In turn, testing needs to be continually updated to reflect the latest security risks.

    A Shift Toward Scriptless Solutions

    Scriptless automation is part of a growing industry of no-code automation tools, often dubbed the no-code revolution. It’s everything test automation is without the reliance on code-based frameworks.

    Scriptless test automation involves recording user interactions with app elements, asserting expected outcomes and assessing the results. The test is then automated, templatized and extended to test other scenarios.

    With scriptless test automation, you can walk through test cases step by step. Some tools even allow you to test on live devices and choose from real iOS devices that are hosted in the cloud.

    Scriptless testing allows you to:

    ● Easily reuse and templatize test scripts. Scriptless automation makes it easier to reuse test cases, create templates and compose new test cases.

    ● Enable faster time to value. Write test cases quicker, make changes without knowing how to write code and integrate directly with your CI/CD tool. As soon as you make changes to your application, your testing team is right there. Some no-code testing tools can analyze your source code and identify testing gaps so that you can address them right away.

    ● Untangle the web of code-based dependencies. With scriptless iOS test automation, testers don’t have to lift and shift their code every time they make a big change. Instead, the no-code framework provides a visual, easily-navigated UI that tells you simply what’s passing, what’s failing and what needs to be updated.

    ● Improve collaboration between teams. Scriptless iOS test automation improves collaboration between testers and developers by making it easy for all teams to visualize test cases.

    Real Device Testing

    When the pain points of fragmentation meet the shortcomings of simulation, developers are wise to test on real devices. At the end of the day, live device testing is the only way to accurately capture an end user’s experience.

    Yet it’s no secret that managing your own device lab is expensive and unrealistic for modern remote work environments. A real device cloud setup solves this problem: A device cloud hosts devices for you that you can access from your desktop, from anywhere.

    Given the ever-increasing complications of today’s mobile app landscape and the incredibly cut-throat mobile app landscape, it’s worth keeping in mind that you may only get one chance at making the right impression on your audience. Getting testing right is the key.

    Into the Future

    Everyone expects more. As a competitive organization, you have to do more with less: Fewer resources, less time and less room for error. Scriptless automation and real device testing won’t guarantee that your app stands out from the crowd, but it will certainly help.

  • Automation in DevOps: Advancements, Platforms and Examples

    Automation in DevOps: Advancements, Platforms and Examples

    Automation is the backbone of DevOps. By facilitating seamless integration and continuous delivery, it revolutionizes the ways organizations deliver software, products and services. When applied correctly, automation can significantly enhance productivity, reduce time-to-market, improve software quality and minimize the risk of human error.

    A range of automation tools support these goals, each tailored to a specific aspect of the software development life cycle (SDLC).

    From code integration to testing and deployment, these tools optimize processes and enable the rapid and reliable release of software. In this article, we will explore the role of automation in the DevOps landscape.

    The Importance of Automation in DevOps

    Automation in DevOps is the process of designing, developing and deploying software and systems with minimal human intervention. The goal is to streamline the software development life cycle from design, development and testing to deployment and management.

    Automation provides several benefits:

    1. Speed and efficiency: Automation enables quick development and deployment of software, which results in faster delivery of features and fixes to customers.
    2. Reliability: Automated systems are less prone to human error, resulting in more reliable code deployment and management.
    3. Consistency: Automation guarantees that routine tasks are performed the same way every time, ensuring consistent results.
    4. Reduced cost: Automation eliminates the need for manual intervention in routine tasks, leading to a reduction in operating costs.
    5. Increased productivity: By taking over routine tasks, automation frees up the team to focus on more critical, high-level tasks.

    Automation in DevOps: An Overview

    Automation in DevOps encapsulates various stages, from development and testing to integration, deployment, and monitoring. The process is often referred to as a DevOps pipeline, a set of practices aimed at reducing development times and improving software quality.

    ● Development: Automation begins at the development phase with tools for source control (like Git), which help developers manage and track code changes.
    ● Integration: The next step is continuous integration, where tools like Jenkins automate the build process, allowing teams to identify issues early in the development life cycle.
    ● Testing: Automated testing tools (like Selenium) streamline the testing process, ensuring that the code is error-free and ready for deployment.
    ● Deployment: Continuous deployment tools (like Kubernetes) automate the deployment process, providing fast, consistent and repeatable deployments.
    ● Documenting: Technical documentation is automated with tools like Scriversi to ensure updated, error-free documentation through each version and release.
    ● Monitoring: Finally, automated monitoring tools (like Prometheus) offer real-time insights into the application’s performance, facilitating proactive troubleshooting.

    Automation’s main objective is to minimize manual intervention, thus reducing the risk of errors, improving efficiency and fostering a culture of shared responsibility.

    Examples of Automation in DevOps

    1. Continuous Integration/Continuous Deployment (CI/CD): CI/CD is a critical element of DevOps automation. With CI, developers merge their changes back to the main branch as often as possible. The CI/CD server automatically builds and tests every change. For example, Jenkins, a popular open source automation server, allows developers to automate various stages of their build pipeline.

    2. Infrastructure-as-Code (IaC): This practice involves managing and provisioning computing infrastructure with machine-readable script files rather than physical hardware configuration or interactive configuration tools. For instance, Terraform, an open source IaC software tool, provides a consistent CLI workflow to manage hundreds of cloud services.

    3. Configuration Management: This is the process of maintaining a system’s configuration in a known, consistent state. For example, Ansible, a configuration management tool, helps to automate software provisioning, configuration management and application deployment.

    4. Monitoring and Logging: Automated monitoring and logging systems gather data on how software and hardware are performing and alert the team to any problems. One example is Prometheus, a popular open source monitoring and alerting toolkit.

    5. Technical Documentation: Proper documentation is crucial in the software development process. Yet, it is often overlooked or not updated frequently due to time constraints or the tedious nature of the work. When automated, it simplifies and automates the process of creating and maintaining technical documents.

    Final Thoughts

    In the world of DevOps, automation is not a luxury but a necessity. By automating repetitive and error-prone tasks, teams can focus on what they do best: creating innovative solutions that meet customer needs. From CI/CD, IaC and configuration management to monitoring and logging, automation simplifies the software development process, reduces human error and enhances speed and efficiency. Tools like Jenkins, Terraform, Ansible, Prometheus and Scriversi support this trend, providing various automation capabilities that make the DevOps approach more efficient and effective.

  • Platform Engineering and DevOps – Dotan Horovits, Logz.io

    Platform Engineering and DevOps – Dotan Horovits, Logz.io

    Dotan Horovits, principal developer advocate for Logz.io, explains why platform engineering represents the latest effort to centrally manage DevOps platforms at scale without compromising flexibility in a way developers will resist.

  • Breaking Boundaries: Integrating Generative AI for Developers

    Breaking Boundaries: Integrating Generative AI for Developers

    Many organizations are experiencing deficits in technical skills and gaps in productivity that ultimately harm their bottom line. To overcome those obstacles and drive growth, businesses can use generative AI tools like ChatGPT and Bard to handle large volumes of data and increase the speed and output of basic tasks without draining valuable human capital. Already, businesses are finding that saving time is one of the most valuable benefits generative AI can deliver. However, there must be oversight of deployments to avoid recurring pitfalls, as the technology contains just as much risk as it does opportunity.

    Generative AI provides developers with helpful task automation while simultaneously creating new challenges. Security, bias and IP questions have DevOps teams scratching their heads at how to best ethically and operationally implement generative AI. Developers must embrace these challenges to remain competitive in an increasingly automated and technologically-driven world.

    Maintaining Confidentiality of Company Code

    Generative AI’s ability to understand and solve code-related issues makes it an ideal tool to help software developers optimize code for faster feature development and quicker releases. By identifying where it can contribute to tasks, like legacy code conversion or automation of processes, companies can free up valuable developer time for building the tools that can grow the business or drive new initiatives. An added benefit is that development teams can automate the coding of new applications or systems by updating old code or re-using existing examples.

    ChatGPT, for example, can also turbocharge development time by scouring swathes of information on GitHub and other forums to find examples of whatever a coder is trying to build. A 2022 study published in the Proceedings of the Association for Computing Machinery on Programming Languages (PACMPL) found that developers could code faster and work more efficiently thanks to generative AI. Tedious searches in tech forums and manual copy-and-paste procedures are replaced by simply asking the right questions (via prompts).

    However, generative AI tools are not closed systems. As users enter data into ChatGPT, it is saved and aggregated to continuously train the language model, opening the door for potential leaks of sensitive company information. There is a serious, potential risk of employees using AI tools as sensitive data already makes up 11% of what employees paste into ChatGPT.

    As a third-party system, AI tools absorb every query, comment and question without any privacy guardrails for users. If an AI bot’s security is compromised, businesses can unintentionally hand over data to bad actors. Even without a hacker’s involvement, sharing confidential customer or partner information may violate contractual agreements and create long legal battles. Developer teams must remain conscious of AI’s security risks.

    Avoiding Bias Creeping Into Results

    It is of utmost importance that businesses make reliable, fair and traceable decisions based on the latest facts. Currently, ChatGPT-4 hasn’t reached the maturity level necessary to be trusted by most companies without significant verification measures. Already, testers have persuaded ChatGPT to make statements that are either inaccurate, biased or both.

    One key concern in generative AI is the ingrained and accidental bias in answers due to the human-generated content used to train large language models. ChatGPT works by searching for textual content relating to the question and recombining it for a distillation. In an almost democratic way, the majority opinion will dominate. For instance, if most people believe that the Swedish are hard drinkers, ChatGPT will say so. While the technology provides remarkably accurate responses in an alarmingly convincing way, it’s important to remember that it’s not always the most reliable or balanced source that wins.

    Furthermore, OpenAI, the creator of ChatGPT, has explicitly stated that its goal is to create a system where queries can be pre-processed before they are fed to the neural net. Answers can then be post-processed before being shown to users. But this safeguard lacks clarity around its objectives and opens the door for ideological or political manipulation.

    Companies considering implementing AI tools must carefully examine their potential applications to ensure they avoid scenarios where bias can result in insights and output that could end up harming the company and its reputation.

    Minimizing Developer Function

    Enterprises are looking for tools to integrate generative AI into existing business processes to enhance numerous functions and deliver greater value to their customers. While the technology still isn’t capable of replacing human developers responsible for updating and maintaining largescale software, updates to generative AI tools and integrations are occurring at a rapid pace, leaving businesses to determine which programs are most viable for developer function.

    As the economy continues to tumble closer to a recession, companies seek ways to minimize costs. And those looking to use generative AI to work with the source code and technical documentation the company uses to run its own operations—rather than the open source code tools like ChatGPT provide—face budgetary decisions. Implementing generative AI programs into the business model can be extremely costly if done wrong, leaving executives to weigh the benefits of adopting the tech versus the cost of trying to hire a full team of developers.

    Connecting the Enterprise to Avoid AI Pitfalls

    For businesses looking to build the connected experiences their employees, partners and customers desire, generative AI is a great resource to accomplish this. However, it’s just one piece of the puzzle that is a modern enterprise. These tools can only deliver smart answers if they get smart questions and businesses connect their internal processes and applications to enable machine learning on accurate and holistic datasets.

    Although AI poses many benefits for developers, such as increased efficiency, accuracy and the ability to handle large amounts of data, they must be wary of the potential security, ethical and budgetary concerns that impact employees, customers and the enterprise as a whole.

    However, once the concerns are overcome or managed, the power of large language models will be leveraged in all kinds of technology and business use cases. Certainly a truly transformational shift and a step change towards a world where technology and software play an unprecedented role in business and society.

  • Universal Infrastructure – Aaron Kao, Pulumi

    Universal Infrastructure – Aaron Kao, Pulumi

    From the second annual PulumiUP conference, Pulumi announced they are providing universal infrastructure as code to all cloud builders, developers and infrastructure experts. Pulumi CrossCode is a language and cloud agnostic infrastructure as code engine that enables development and operations teams to build infrastructure in the industry’s most popular and powerful programming languages.

  • Automation or Concatenation?

    Automation or Concatenation?

    We’ve been in a period of mergers and acquisitions for a while in the DevOps and DevSecOps spaces, and it seems to be heating up even more. Combined with products expanding to cover a more broad segment of the software development life cycle (SDLC) and strategic partnerships to cover more of the SDLC, it is starting to look like our automation efforts are going to be increasingly driven by vendors. Those efforts will be more concatenation than automation–though technically the same in perception, they vary wildly in implementation, and we should be planning for it.

    Build Versus Buy

    We have always struggled with build versus buy, and we have always struggled with best-of-breed versus overarching solution set. The entire hype of Every. Single. Vendor. Claiming to be a platform is partially driven by the latter argument. Putting “platform” in your marketing does not make a vendor better at those things outside its historical strengths, though, so that movement is doomed to fail for most organizations. Some were already moving to be a platform and had assembled–by M&A or by internal development–an impressive platform already, and those were successful because they were good at a breadth of things. The best of them are continuing this trend. I try to avoid plugging vendors here, but I think an example is in order in this case.

    Akamai’s recent purchase of NeoSec is the poster child for vendors doing the platform thing super well but not resting on their laurels. I’ve followed Akamai’s security offerings for years, and the platform has impressive functionality, but NeoSec is exactly what they needed. It plugs a couple of holes in their security offerings and brings a whole customer base into the Akamai fold. That’s what I’m talking about when I refer to the good ones.

    The problem is the acquisition and expansion of offerings trend is starting to gain a lot of steam, and not every vendor jumping on the bandwagon does the job as well as Akamai does.

    This leaves enterprise IT staff responsible for DevOps and DevSecOps – even straight security staff – with a new set of issues. Best-of-breed is taking a hit again, and overarching solutions are on the rise. The difference is the breadth that some of these new “platforms” offer is massive. And we know that even the good ones will have better and worse parts of the overall solution. So IT now has to start considering what vendors call a feature and how it individually compares to the competition. This will require more up-front work for evaluators. Now, a larger (and growing) list of “features” that were once “products” has to be considered piece-by-piece against the competition, and organizations must evaluate the feasibility (and cost) of implementing two (or even multiple) massive platforms to get the most critical functionality needed.

    As of this writing, point solutions that do one thing extremely well are holding up, but the trend is obvious. Those markets will be subsumed into larger offerings that may not do as well at other parts of the overall problem. Evaluators will have to be more careful and consider their options with an eye to the larger infrastructure and problem domain. Do you want a single vendor doing all of the steps of DevOps or responsible for every aspect of application security? That will be an individual decision and, if not, how the final solution/architecture looks will be a more complex discussion.

    Integration and Automation

    In our quest for integration and automation, many vendors are responding with the concatenation of tools to solve the automation part. You’ll be stuck figuring out if they’re doing it well enough for the org.

    But that’s not a problem you can’t resolve. You’ve been rocking it through staffing issues, lockdowns, growth and shrinking… Just keep rocking it. Choose the solution that makes the overall best sense for your organization, get it running and take a break; head to the beach for some relaxation time. Or whatever you do to clear your head – because the next problem will still be there when you get back, and it’s better to be relaxed when you tackle it.

  • Software Bill of Materials API – Chris Wysopal, Veracode

    Software Bill of Materials API – Chris Wysopal, Veracode

    Chris and Alan discuss Veracode’s Software Bill of Materials (SBOM) API that makes it easier to provide visibility for developers when using third party components.