Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

  • Observability Matters. But Are You Observing the Right Things? 

    Observability Matters. But Are You Observing the Right Things? 

    It’s like clockwork. Every few months, a new buzzword descends on the tech industry, and soon it’s on everyone’s lips. Take your pick from the graveyard of buzzwords past: “Big data,” “internet of everything,” “hacktivism,” “gamification.” It’s not that these terms are meaningless—just that they go from relatively obscure to ubiquitous seemingly overnight. We can add a new one to the list in the digital monitoring space: “Observability.”

    Unlike some trendy buzzwords, observability captures something that’s actually quite important about how we monitor digital systems and how current approaches differ from those of the past. So, it’s a good and useful concept. But where I take issue is with the way many analysts, technologists and vendors seem to use it. Whether or not they mean to, they often paint a far too narrow a picture of what observability is or ought to be, and that linguistic oversight can have real-world consequences. If enterprises invest in observability without understanding what, exactly, they’re observing—and what they’re not—they risk leaving themselves vulnerable to some serious blind spots. 

    What is Observability and Why Does it Matter?

    Technically, observability is an approach with the goal of understanding how a system is doing. The distinction lies in what the system is and how it is being observed. The monitoring tools of yesterday typically focused on one or more domains to identify typical and known problems. Usually, that entailed collecting metrics directly from those domains and measuring them against predefined thresholds. For example, storage levels shouldn’t exceed a certain threshold; if they do, send me an alert so I can investigate what’s happening. 

    On the other hand, observability takes a more holistic approach, examining multiple outputs of the system to infer system health. For example, suppose you were trying to gauge a car’s condition. In that case, traditional monitoring might track engine temperature or idle speed RPMs, while observability would examine things like power output, engine leaks, transmission noise, emissions and fuel efficiency to infer the car’s overall health. 

    This output or outcome-focused approach to managing performance maps well to today’s complex and distributed digital systems. Even if you wanted to, you couldn’t pull real-time metrics from every relevant component of a system when those components consist of thousands of microservices running in any number of physical servers across multiple clouds. However, the bigger problem with more antiquated monitoring models is that they only capture the specific metrics they’re designed to track. If you’re encountering a problem you’ve never seen before, your monitoring dashboard might look perfectly healthy while actual system performance is terrible. 

    Observability and APM 

    So then, observability should give you everything you need to track the health of a modern digital business, right? Well, not so fast. Because for today, people seem to use “system observability” interchangeably with “application performance monitoring,” or APM. And they are not at all the same. 

    Yes, you want an observability-based approach to tracking your application environment, and modern APM tools provide a great way to do it. But knowing the health of your application environment is not the same as knowing the health of your overall digital systems as experienced by users. And at the end of the day, if you’re not gauging performance from your users’ perspective—whether that’s customers, employees or other devices relying on your systems—then what’s the point? It’s unfortunately not uncommon to forget that the most important key performance indicator (KPI) of any digital system is the quality of its intended output or outcome. In the case of any application, the most important KPI is the user experience.

    The outputs that APM tools track do contribute to the user experience—and you want to be monitoring them. But so do many, many other things. There’s the user access itself (browsers, virtual or physical user devices loading the application). There are local, regional and global networks connecting those users to your application environment. And then, of course, there are the dozens, sometimes hundreds of third-party digital services running between and among users and applications. Problems in any link of that digital chain can seriously impact the user experience—even if your application environment itself looks healthy. 

    Observing End-to-End, from User to App and Everything in Between 

    To get the full picture of the health and performance of your digital assets, you should be tracking outputs from across the end-to-end digital service chain. That includes telemetry (logs, infra metrics, traces) from your application hosting environment. It should include actively and passively observing at the point of consumption—that is, outputs from customer browsers and worker devices. It must include active and passive monitoring of network connectivity. And it should include continuous active monitoring of all the disparate services—APIs, content delivery networks (CDNs), DNS services, cloud-based security services and every other cloud and web service that contributes to what the user is experiencing. (And by the way, you should look for independent, objective telemetry whenever possible rather than taking what your various service providers report at face value.) 

    When you approach observability from this outcome-based, holistic perspective, you can capture a real and truthful picture of the performance of your full digital business, not just pieces of it. Just as important, when you do identify a problem, you’re in a much better position to do something about it. Because now you have outputs to measure from all the many systems and services that contribute to the user’s application experience instead of just a subset of them, which means it’s much easier to zero in on which piece of the puzzle isn’t behaving the way it should. 

    A Smarter Approach to Observability

    So, should you take all the hype about observability seriously? Yes. As tech buzzwords go, you could do a lot worse. This one actually means something important. But make sure you’re keeping the big picture in mind as you do. 

    Observability that ignores the outcome begins and ends with the application environment and is nowhere near sufficient. We need to expand our sense of observability, begin with the user experience and encompass every link in the chain of the end-to-end digital business. When we do, we create a much more holistic, useful and actionable picture of the health of our digital systems. And we can make sure we’re continually monitoring digital performance in the way that matters most: As experienced by users. 

  • Dynatrace Adds Security Gates to Advance DevSecOps Adoption

    Dynatrace Adds Security Gates to Advance DevSecOps Adoption

    Dynatrace today added a security gates capability to its observability platform to make it easier to automatically embrace DevSecOps best practices within an application delivery pipeline.

    Steve Tack, senior vice president for product management at Dynatrace, said the security gates function much the same as the quality gates that Dynatrace previously added to that platform in that each release is now also automatically assessed to ensure only secure code is being deployed.

    The Dynatrace platform now uses a Davis artificial intelligence (AI) engine to scan for vulnerabilities in application workloads in real-time and then prioritizes them based on the risk they pose, noted Tack. The goal is to make it simpler for organizations to incorporate security reviews in application development processes in a way that doesn’t necessarily require developers to become security experts, he added.

    Instead, the core DevOps platforms should be capable of identifying issues that can be remediated before an application is ever deployed in a production environment, said Tack.

    Dynatrace earlier added an ability to automatically identify the software libraries and open source packages that present the greatest security risk. The security gates capability now extends the scope of that effort to include applications as they are constructed using custom code.

    In general, most organizations are looking for ways to embrace DevSecOps best practices. The challenge is achieving that goal without unduly slowing down the rate at which applications are developed. In fact, a recent survey commissioned by Dynatrace found, on average, organizations expect to increase the frequency of their software releases by 58% over the next two years. However, nearly a quarter (22%) of respondents admit they’re often under so much pressure to meet the demand for application deployments that they must sacrifice code quality, which broadly includes security issues.

    It’s not clear to what degree security reviews will automatically be included within a quality assurance process, but Tack said the goal should be to limit human involvement in the application deployment process as much as possible. The issue many development teams encounter today is that applications are being rejected by cybersecurity teams that are reviewing applications just before they are deployed, noted Tack. As a result, developers are racing to build applications faster only to see them rejected and returned to them at the last possible moment, he added.

    In the wake of a series of high-profile software supply chain breaches, the focus on DevSecOps has increased substantially within most organizations. It’s often not precisely clear who is responsible for application security, but as DevOps platforms continue to evolve, there may come a day when security issues are routinely addressed within every DevOps workflow.

    In the meantime, there needs to be a lot more focus on bridging the divide between DevOps and security teams. Given the chronic shortage of security professionals, there’s no doubt DevOps teams need to assume more responsibility for application security. The challenge and the opportunity is finding a way to achieve that goal with the least amount of friction possible.

  • Allstacks Adds Free Dashboard to Track Software Dev Benchmarks

    Allstacks Adds Free Dashboard to Track Software Dev Benchmarks

    Value stream intelligence platform provider Allstacks today added a free live dashboard populated with anonymized data that DevOps teams can use to benchmark their own progress.

    Hersh Tapadia, Allstacks co-founder and CEO, said the company is making this data available to make it easier for DevOps teams to uncover bottlenecks in their software development processes.

    As part of that effort, the dashboard includes pre-configured benchmarks for the following:

    How many days per week do benchmark teams write code?
    What percentage of issues are planned versus unplanned for benchmark teams?
    What are the cycle times per issue type for benchmark teams?
    What types of code do benchmark companies produce?
    What is the average commit size for benchmark customers?

    Allstacks

    Allstacks has committed to making 12 months of data publicly available on the dashboard and said it will update that data on an ongoing basis. Allstacks customers, however, can also access five years of data to compare historical trends.

    Tapadia said Allstacks plans to add additional benchmarks to a dashboard that can collect data via the various application programming interfaces (APIs) that most DevOps tools now routinely provide. The overall goal is to increase transparency into software development processes, he said.

    Allstacks’ value stream intelligence platform uses machine learning algorithms and artificial intelligence (AI) models to identify projects that are at risk of not meeting delivery goals. That data is then used to analyze the impact those missed deadlines are likely to have on various business objectives.

    Value stream management platforms automatically take technical metrics, gathered via a DevOps process, and match them to a set of key performance indicators (KPIs) defined by business leaders. The challenge many organizations still face is making sure they have the tools in place to collect the appropriate technical metrics and then define the KPIs that truly matter to the business. Once those metrics are gathered and KPIs established, organizations are then able to apply advanced analytics to the massive amounts of DevOps data they collect.

    The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to a process that is highly automated using DevOps best practices, an appreciation for the value of monitoring the impact of missed software development deadlines on the business has grown as organizations realize how dependent they are on software.

    As a result, more organizations realize there is a clear disconnect between their business goals and development processes, noted Tapadia. Business leaders are especially anxious to understand how a software development project delay might impact future revenue projections. Rather than being a set of tools employed mainly by IT leaders to track software development projects, value stream management platforms make it possible for other stakeholders to track KPIs spanning multiple software development projects. It then becomes easier to make informed decisions about how to reassign resources across various projects as different bottlenecks are encountered.

    It may be a while before organizations achieve that level of transparency into their software development processes, but as software continues to ‘eat the world,’ it’s only a matter of time before value stream management becomes a required set of DevOps tools for every organization.

  • Grafana Labs Expands into Incident Management Realm

    Grafana Labs Expands into Incident Management Realm

    During its online ObservabilityCON 2021 conference, Grafana Labs this week previewed an incident management platform in addition to making available an on-premises edition of its distributed tracing tool.

    Tom Wilkie, vice president of product for Grafana Labs, said the Grafana OnCall incident management platform is a natural extension of the observability tools the company already provides using the widely employed open source Grafana dashboard. The platform, which is expected to be generally available in 2022, is based on software Grafana Labs gained by acquiring Amixr earlier this year.

    Grafana OnCall unifies all the alerts created by Grafana, Prometheus and the Alertmanager tool the Prometheus community created to streamline the number of alerts generated by the platform. The goal is to reduce the alert fatigue a DevOps team might experience when dealing with an IT issue that can be traced back to a single root cause, noted Wilkie.

    Grafana

    At the same time, Grafana Labs made Grafana Enterprise Traces available for on-premises IT environments. It is based on Grafana Tempo, a cloud service that makes it possible to store and then analyze distributed traces using inexpensive object storage resources. The latest version of the core open source Tempo project has also been updated to add service graphs and the ability to search recent traces.

    Grafana Labs this week also updated Loki, an open source log management platform, to add support for out-of-order log lines, custom log retention policies per log stream and per tenant and a deletion API that makes it easy to scrub log data. Version 2.4 of Loki also adds additional high-availability capabilities.

    Other updates to the Grafana Labs platform include support for recorded queries, a set of pre-built dashboards that enable users to quickly drill into their Prometheus metrics data, the ability to consume metrics from the AWS CloudWatch service provided by Amazon Web Services (AWS), improvements to its ability to monitor Kubernetes clusters and updates to the open source load testing tool the company gained by acquiring k6 last year.

    Grafana Labs is also committing to expanding its integration with Microsoft Azure cloud service alongside its integrations with AWS, noted Wilkie.

    While competition among providers of observability platforms is already fierce, Wilkie said an observability platform based on an open source dashboard that can already collect data from more than 100 sources provides a unique advantage. At the core of the Grafana Labs platform is a centralized framework for collecting data generated primarily by the open source Prometheus monitoring platform being developed under the auspices of the Cloud Native Computing Foundation (CNCF).

    While Prometheus is used most often in Kubernetes environments, it is starting to gain traction in monolithic application environments as well; it provides an open source approach to defining a de facto standard for collecting metrics and other data that can be consumed by an observability platform.

    It’s not clear yet to what degree IT teams are distinguishing between monitoring and observability. Monitoring focuses on predefined metrics to identify when a specific platform or application is performing within expectations. Observability combines metrics, logs and traces to instrument applications in a way that makes it simpler to troubleshoot issues without relying solely on a limited set of metrics that are pre-defined and monitor a specific process or function.

    Regardless of whether IT teams view observability as being distinct from monitoring, it’s clear that the ability to manage IT environments is improving at a rapid rate. The challenge, of course, is the IT environment itself is becoming more complex with each passing day.

  • Automated Refactoring with Moderne

    Automated Refactoring with Moderne

    Jonathan Schneider and Olga Kundzich are co-founders of Moderne, a Seattle-based startup. Moderne received $4.7 million in seed funding in July 2021 to commercialize OpenRewrite, an open source automated refactoring tool for code (initially Java) that Schneider started while at Netflix. Moderne’s technology reduces the tedium and time it takes for software remediation; a big problem in today’s world of cloud-native development. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Alan Shimel: Hey, everyone. Welcome to another segment of TechStrong TV. We have a new company to detail for you, and we have two cofounders here to tell you all about it. It’s a great open source story as well. Let me introduce you to – and I’m gonna do my best not to mess it up – Olga Kundzich, Kundzich, Kundzich – three times the charm – and Jonathan Schneider. I think I got that one on the first try. Olga, Jonathan, welcome to TechStrong TV. 

    Olga Kundzich: Great to be here. 

    Jonathan Schneider: Thanks. It’s good to be here. 

    Alan Shimel: Thank you. So the only rules is only one of you can talk at a time, but both of you can talk as much as you’d like. But why don’t we start off with maybe a little bit about each of you. Olga, if you don’t mind, why don’t you go first and maybe share with the audience a little bit of your background and how you came to be here today. 

    Olga Kundzich: Great. So my background, I was working at Pivotal on a Spinnaker continuous delivery solution, and that’s where Jonathan and I had met. We worked together there for about a year and a half. Prior to that, I worked at EMC in engineering for, in different functions for a number of years. So when we were working together on Spinnaker, we talked to a lot of people in the industry. There was a lot of interest around that product, and kind of we realized that everyone had sort of the same problem. We would start a conversation about some old feature, and it will come back to, well, all my application is still stuck on this old, aging framework, and let me talk to you in a year when I migrate all of this back.

    So and the problems were highly repeatable and kind of same framework, same third-party vulnerabilities, same libraries, APIs, so after reflecting on this we realized that this is really not a coincidence. It’s a consequence of modern application development practices. Our software right now is 90 percent third-party dependencies, open source, APIs, so the problem’s kind of highly repeatable. And that’s kind of led, what led us to, back to technology that Jonathan developed earlier at his time with Netflix and kind of take it, develop a lot of more functionality into that sort of large-scale distributive factoring that will help us solve these type of problems, the framework migrations, API migrations, CVE patching that cross all of these open-source and third-party dependencies. 

    And I will let Jonathan speak about his background and a little bit on the open-source framework.

    Jonathan Schneider: Yeah, so Netflix had this engineering culture called freedom and responsibility, so product engineers were sort of, had the freedom to do whatever they wanted really. They could use their, a different build tool, they could use their particular Java style, they could use whatever libraries they wanted, and so forth. And so as a central team, if you’re on an engineering productivity team or you’re on a platform team and you’re trying to effect some change inside the organization, we couldn’t put up gates in front of product engineers that would, say, break their build if they didn’t comply with a certain thing. Instead, you tried to build tools that would help bring them along on a journey with you, and I kept hearing the same thing over and over again from engineers which is, hey, I got a lot on my plate. Happy to move forward to this new pattern that you want to see, if you do it for me. If you just do the work for me, I’m happy to commit it. 

    Alan Shimel: Nice of them. 

    Jonathan Schneider: And of course, you know, you think there’s two of us and 700 of them, and that doesn’t scale super well. Right? So that’s where we started working on a way of actually automating the source code transformation. When we developed that technology, one of the consequences of that freedom and responsibility is that there was not a consistent style of the code or consistent patterns, necessarily. So that refactorization we built had to make transformations that were, looked like they were a developer writing in that code base stylistically consistent, hundred percent accurate changes. And so we got some interesting results out of that, so when Olga and I were working together and you would hear, “Oh, I’m still stuck on Spring Boot 1 and I’m trying to get to Spring Boot 2,” or, “I’m stuck on JUnit 4. I’m trying to get to 5,” we just found another application of this at a larger level in a highly repeatable problem space. 

    Alan Shimel: Fair enough. You know what, I’ve spent the last 20 plus years talking to founders. I’ve founded my own companies. This is what happens. You see a real problem. Right? See a real-world problem. There’s got to be a better way we could solve it. Sometimes you find out solving that problem is not as easy as you thought. Sometimes it is, very rarely. But you work through it and that’s what startups are all about. In your case, though, I mean, look, Spinnaker, which is now part of CDF, right, was managed by CDF, but Google, Netflix were instrumental in the development of Spinnaker. But Spinnaker is an open source tool, and you guys went with an open source route in what you’ve developed. Why don’t we talk about that a little bit? 

    Jonathan Schneider: Sure, yeah. There’s really two parts to our product offering. There’s OpenRewrite, which is GitHub slash OpenRewrite. OpenRewrite is that core refactoring technology we’ve been talking about that can make stylistic automatic and consistent changes to a code base. On OpenRewrite we built recipes, so we have a recipe to migrate you from Spring Boot 1 to 2, from JUnit 4 to 5, to do code cleanup things, to do security vulnerability fixes. We want those recipes to always be Apache licensed and open source. Framework authors are going to develop the recipe, so the Spring team will develop the recipe that will move you from Spring Boot 2 to 3, or the Quarkus team at IBM or Red Hat would develop the recipe that’d move you from one version to another.

    What Moderne does commercially is we take those recipes and we run them at massive scale, so I could take that recipe and run them against tens or hundreds of millions of lines of code, and you can see that, the impact of that recipe running against your whole organization’s code base. 

    Alan Shimel: Fair. And so you mention – how did – it’s not Modern. It’s Moderne. Correct? 

    Jonathan Schneider: Yeah, we call it Moderne. Yeah.

    Alan Shimel: Moderne. So that’s the name of the company.

    Jonathan Schneider: It’s the name of the company, yeah. 

    Alan Shimel: And OpenRewrite is the open source aspect of it or –

    Jonathan Schneider: That’s right. 

    Alan Shimel: – owner of the solution. So let’s get into the mind of the entrepreneur here a little bit, Olga. Having worked at Pivotal and EMC for years before this, you saw this issue. You saw this problem. There’s got to be a solution. When did you say, you know what, this is something worthy of starting a company, right? When I was starting companies, one of the big questions is, is this a feature or a product? Right? Is it just a feature of someone else’s product, or is it truly a product in and of itself? And that makes a big difference in, obviously in what you’re building and what your aims and all of that. Olga, I’d like to hear from you. Feature, product, how did – what was kind of your thought process in saying, you know what, this could be its own company?

    Olga Kundzich: I think this, something like this is essential for managing modern cloud-native applications. These are becoming, the applications sort of become a glue code teaching all of these third-party components. They evolve and change at their own pace, and developers really right now are just restitching those things back together, upgrading CVs, upgrading versions, and it takes a really significant amount of time just to – sort of anecdotally we hear from people that 20 to 30 percent of their time, engineering time, is just now dedicated to these tedious migrations. So if we can automate this, we can unlock innovation, productivity of engineering organizations, and help a lot of businesses actually innovate.

    Alan Shimel: Got it. Jonathan, what about from your end? Well, let me ask you both. Is this your first time starting a company? 

    Jonathan Schneider: It’s first time starting a company, yeah. I think it’s real special to me. I think one thing I love about this business is that we’re really after helping organizations fix their code, and our outcome and our future success is tied directly to how much code we’re able to fix, how much help we’re able to provide. We’re not about reporting and saying like, you know, here’s the problems that you, engineering team, need to fix. When we partner with an organization, we’re kind of in the trenches with them getting these issues off their plate.

    We talked to one organization recently – and this is why I think it’s a product and not a feature. We talked to one organization recently and they say we just look at our top ten issues reported by a series of static analysis tools they have in-house, and it says, well, it’s gonna, these tools estimate it’ll take 1,700 developer days to fix these top ten issues. So that’s like 4.8 years’ worth of developer time to fix those top ten issues that they have, and those aren’t false positives. Those are just literally top ten critical problems they have right now. So we developed recipes for a lot of those, and their engineers said, you know, “We estimate it would take us five days with these recipes to apply that change and be done with it.”

    When I think about 1,700 developer days or 4.8 years of time, what that really means to me is infinity, or like it means that the engineering team is never going to get through that backlog of issues. Five days seems like it is possible, and that’s, there’s this line we have, the, basically software grows until it can no longer be maintained, and I think our business is in keeping that software in a maintainable state so that the business can continue to innovate and thrive. 

    Alan Shimel: Absolutely. So companies launch now – we didn’t even mention the website. Shame on –

    Jonathan Schneider: Yeah.

    Alan Shimel: What’s the website? 

    Jonathan Schneider: Yeah, so the website is moderne.io, so it’s modern with an E.

    Alan Shimel: Can you spell that, Jonathan? M-O- –

    Jonathan Schneider: Yeah, it’s M-O-D-E-R-N-E, so modern with an E, dot I-O.

    Alan Shimel: Dot I-O.

    Jonathan Schneider: Yep, that’s right. We do have a restricted beta going on right now that you can just sign up for that on that website, and we’ll do an invite to you and you can see how we can apply these recipes across tens of millions of lines of code. 

    Alan Shimel: Absolutely. Are you working with CDF and the Spinnaker community?

    Jonathan Schneider: We’re really in an adjacent product space now. I think there’s a lot of value to operational automation, what Spinnaker is doing, what different APM vendors are doing. I think we were working in that and we saw just an adjacent pain point that we just decided to go after instead. 

    Alan Shimel: Good stuff. Well, guys, I want to wish you nothing but a lot of success with this. It’s always, you know, I gotta be honest with you. I always enjoy interviewing new companies coming out of stealth and beta, first-time entrepreneurs, ’cause you make the world go around. And good luck. Keep us posted. Come back on and tell us more as you, as the story continues to unfold here. 

    Jonathan Schneider: Yeah, look forward to talking again soon. 

    Alan Shimel: All right. 

    Olga Kundzich: Thank you.

    Alan Shimel: Jonathan and Olga from Moderne, M-O-D-E-R-N-E, dot I-O, here on TechStrong TV. We’re gonna take a break. We’ll be right back.

    [End of Audio] 

  • The Need for Agile, Adaptable IT Infrastructure

    The Need for Agile, Adaptable IT Infrastructure

    Through the adoption of Agile concepts and new best practices such as automated testing, organizations can move beyond the innovation curve and bolster their IT infrastructure. In fact, the need to build agile and resilient IT infrastructure has become increasingly pertinent over the past 18 months. 

    From remote working and managing the diverse needs of employees in remote locations to the growing rates of cybercrime, the move from the physical world to the virtual one has seriously impacted the ability of organizations to operate. It comes as no surprise that business leaders are increasingly investing more in new tools and technologies to improve their IT infrastructure, transform operations and drive business value. 

    That said, it still remains relatively rare for enterprises to wholly adopt Agile approaches and techniques, despite the fact that doing so can help improve the efficiency at which goods and services hit the market. The fact is that many technology companies still do not use Agile as it is difficult to implement at scale. In addition, Agile transformation demands a cultural change, which can often take time. 

    Nevertheless, sooner or later, Agile IT will need to be implemented across businesses in various industry sectors, as well as across all branches of an organization. Our experience has been that Agile transformation will help your business grow and succeed. 

    What is Agile IT? 

    Agile is a philosophy—a mindset that can be applied to improve the provisioning, management and operation of digital infrastructure. Agile promotes business-led development, whereby a product owner and software development team collaborate as a single entity to deliver tasks that are prioritized based on business value. These tasks are also delivered over a short timeframe, such as via two-week sprints. 

    Essentially, your infrastructure is far more likely to be both secure and resilient if Agile concepts are implemented throughout the software engineering process. As a result, new digital products can be delivered to customers more quickly. For example, Agile ways of working include making small, iterative changes to deliver high-quality results with speed. You can also spin up infrastructure when needed, which keeps the cost of innovation down. 

    The Differences Between Agile and Traditional IT Infrastructure? 

    Infrastructure agility is best achieved using modern solutions such as cloud technology. This significantly differs from the traditional approach of having on-premises infrastructure, which cannot be scaled up or down as needed. In fact, on-premises solutions often require extensive upfront capital, while investing in cloud resources works on a pay-as-you-go model to deliver flexibility and elasticity for strategic needs. 

    The conflict between adaptive software methods and predictive methods is another significant difference between these approaches. Development teams follow a comprehensive plan in traditional waterfall approaches, and any changes must go through stringent change control management. Agile requirements, on the other hand, require flexibility, allowing teams to adjust to changes as soon as they occur. This method is suitable for smaller projects that must be performed quickly and efficiently. 

    Benefits of Implementing Flexible IT Infrastructure

    The advantages of having Agile IT infrastructure are numerous. In fact, the adoption of Agile methods not only promotes business growth but is also a great way to reduce costs and improve team performance. By working in sprints, teams can turn around features more often and nurture their value throughout the business. Agile transformation also enables organizations to offer new products or solutions to customers faster, gain early feedback and make changes if necessary, thus avoiding error from the very beginning. 

    Cost optimization is another benefit to consider. With Agile infrastructure housed in the public cloud, IT leaders can expand or decommission resources based on consumer demand. Cloud companies’ pay-as-you-go strategy also ensures that costs are kept to a minimum viable level. For example, maximum limitations can be set for the scaling out of resources. Most importantly, agile working methods eliminate the need for substantial upfront investments, resulting in a higher return on investment (ROI). 

    How to Achieve Agility

    The benefits of Agile transformation are clear; however, the journey to achieving this can take time. First and foremost, becoming Agile requires a clear understanding of what it means and why it is important for your business’ competitive context. Once the ‘what’ and ‘why’ are defined, the ‘how’ becomes easy. The three core steps to achieving this agility are: 

    1. Implementing new methods
      Instead of trying to rework existing IT management tasks and procedures, it is often better to think of new ones as part of the Agile journey. This will ensure that your system’s performance and availability are in line with your core goals. 
    2. Investing in the right tools
      Agile is all about delivering smaller outcomes quickly. To achieve this speed, automating key stages of the software development process is key. There are a host of tools available to undertake this automation, including hybrid cloud solutions that can seamlessly switch between the public and private cloud. A careful selection of the tools that best fit your needs and the correct implementation of these throughout the organization is paramount to achieving success. 
    3. Changing the culture
      To become an agile business, the entire organization requires a cultural change—from how the business discovers a problem to how that problem is resolved by technology teams and monitored in production to enable a faster feedback loop. At every stage of the process, team members need to perform tasks differently, which often requires training, buy-in from the wider team and a collaborative approach. 

    Investment in Agile IT is a smart decision for business leaders hoping to transform their operations, ensure resilience and drive business value. By choosing infrastructure that caters to these needs, you can save money and ensure confidence at critical moments. 

  • Driving Software Delivery Automation With AI/ML

    Driving Software Delivery Automation With AI/ML

    What if we could use an artificial intelligence (AI) engine to predict the next lines of software code to build? What if machine learning (ML) could trigger the creation of automated test cases to validate our solutions?

    Automation has been a focus for the information and communications technology (ICT) industry for years, and there are some lessons that could apply to the software developer community, too, as well as other verticals. Today, more streamlined execution of operational and software delivery processes, such as continuous integration, continuous delivery and continuous deployment (CI/CD) in app development, continue to drive new levels of cost reductions, allowing products to get to market and update faster. 

    However, with the increased amount of data comes more complex ecosystems and the need for the next level of automation. Hyperautomation, or the use of AI/ML to further streamline processes, could build on these CI/CD processes, revolutionize the way multiple industries deliver software and optimize operational processes.

    Today’s Network Complexities and Challenges

    In the telecommunications industry, disruptions from hyperscalers and other innovative players, as well as increasing levels of investment in 5G technology, are forcing the hand of communications service providers (CSPs). This is causing them to turn to automation to improve their levels of operational efficiency and innovation to keep up with the need to push frequent updates. 

    However, challenges remain in the form of:

    • Total cost of ownership and operating costs: With more frequent needs for upgrading existing networks, additional levels of automation including AI/ML and hyperautomation are required to manage and maintain today’s complex networks. 
    • Time to market: In an increasingly competitive market, the CSP’s ability to react to market needs and/or new marketing ideas and to rapidly launch those needs and ideas to their end users and enterprise customers is a key competitive differentiator. 
    • Customer experience: Digitalizing business processes, providing an increased level of self-service and seeking ways to optimize customers’ overall journey remains an important need.
    • Employee productivity: In an effort to increase revenue, more efficiently drive their networks and improve end user customer experience, CSPs also need to increase employee productivity. They can do this by engaging their employees to solve bigger problems. As a result, the simplest and most repetitive low-level tasks can be automated.

    The Power of AI and ML

    The automation journey started with breaking down complex processes into smaller parts and automating discrete parts using scripts, runbook automation (RBA) and/or robotic process automation (RPA). 

    With the introduction of AI emulating human intelligence through mechanical and computational processes and ML using algorithms that learn from data to make predictions and decisions, CSPs can now bring automation and hyperautomation to the next level. 

    The potential use cases for the delivery and maintenance of telco software solutions are unlimited, and many of these lessons can be applied to other sectors. Some examples include:

    Autonomous Fault and Anomaly Detection for Cloud-Native Solutions

    Today’s network solutions are deployed on containers and microservices. The identification of issues and assurance of service quality becomes increasingly challenging with thousands of workloads running in parallel. Container failure can cause severe service disruptions. In fact, a single service failure or abnormal behavior could have a butterfly effect on the overall system and negatively affect customer satisfaction. 

    A proactive, AI-based monitoring solution can continuously search for anomalous behavior in the environment. Different container metrics and logs can automatically analyze and detect problems proactively and help find the right corrective actions for the application workflows. This is based on identifying anomalies in the container orchestration metrics related to pods, workloads and namespace. These techniques enable a more reliable and predictable application runtime environment with higher service quality and faster identification and resolution of system faults and, ultimately, a better overall customer experience

    Machine Learning-Triggered Closed-Loop Automation

    Large clusters of compute, storage and networking resources are managed throughout a data center to enable the deployment of custom workloads. Due to the inherent nature of applications running on the virtualized and cloud infrastructure, there are usage highs and lows which need constant infrastructure component deployment or reconfiguration of the cluster to ensure cost-efficient service availability. 

    A machine learning-based solution can detect anomalies in the infrastructure. Specifically, with closed-loop automation, enterprises can bring in a layer of intelligence over the current setup to monitor application performance and infrastructure metrics and identify anomalies that require immediate system attention. If those are found, they can trigger the automated addition of capacity to the infrastructure. When anomalies have subsided and once the utilization is capable of being handled by the original capacity, the solution can consistently monitor metrics to roll back the virtual or cloud-native functions. This allows for an efficient and fully automated use of network capacity, minimizing human oversight.

    Smart Code Recommendations

    One of the most clear-cut ways tools can reduce the effort of software development for programmers is through code completion. AI-powered code completion is a convenient way to access descriptions of functions and their parameter lists. These solutions also speed up software development by reducing keyboard input and the necessity of name memorization. They also allow users to refer less frequently to external documentation, as interactive documentation appears dynamically in the form of tooltips. AI-powered code completion can also use an automatically generated in-memory database of classes, variable names and other constructs or references based on machine learning to open code repositories.

    AI-Driven Test Recommendation

    Significant time is spent understanding solution requirements and identifying critical scenarios for testing. This is usually followed by a manual test plan creation and execution. To solve this, AI/ML techniques can be applied to identify what tests will need to be done during each cycle of the software development stage, including automating the analysis of required documentation. This can be used to increase overall test-cycle time and improve productivity. 

    AI-Enabled Test Automation

    API testing is critical for validating application logic and needs to go beyond the GUI layer to validate the core of an application. This implies complexity because the protocols are usually difficult to understand, the API inventory is usually large and sequencing of the API calls is critical to a successful test specification and execution. With AI/ML and natural language processing techniques, the analysis of the solution test plan can be automated to obtain recommendations on what test frameworks to utilize, identify and suggest the parameters for each test case, identify the API call sequence and automate the development of test cases based on reusable functions. This can increase overall quality of service, simplify change management, improve the productivity of the testing team and offer more reliable test cases.

    Test Failure Analytics

    During execution of automated test cases, multiple failures can be observed in various logs. Manually analyzing the logs and correlating them with the application issues can be time-consuming. Also, the identification of unreliable tests impacting system stability is complex. 

    AI/ML techniques such as vectorization, K-means clustering or topic modeling can be applied to automate the collection of test logs across applications and label failures including the type of cluster failed tests. The test subject matter expert (SME) is provided with a failure analysis report summarizing issues and problems automatically from many logs across applications, simplifying the identification of issues in test automation areas or scripts. These techniques can significantly increase test productivity and overall troubleshooting time.

    Accelerated Root Cause Identification and Analysis (RCI&A)

    When a problem occurs in a telco network, it tends to cause a ripple effect, affecting other integrated services and creating an alert storm. In such scenarios, root cause identification can become complex and cumbersome. Event aggregation and synchronization are needed to reduce environment complexity and variance. 

    Machine learning weighted analysis techniques can be used to determine the influence individual IT metrics have in affecting the overall health and performance of hosted applications and services so that pinpointing the root cause of any service impact in real-time can become easier for the team operating the network. Efficient AI/ML techniques for accelerated RCI&A can lead to significant timeline reductions. 

    AI/ML Driving Operational Innovation and Market Agility

    In telco, there is great potential for AI/ML-driven use cases to further improve the cloud-native journey and enable an IT-like software life cycle management process for the solutions of the future.

    More broadly, highly automated and self-healing networks will drive higher levels of efficiency and customer satisfaction. This includes faster testing with less resources; more efficient utilization of network resources and cloud infrastructure; faster time-to-market with more software releases per year with similar capacity as well as an increased quality for faster and more agile monetization of the CSPs capabilities.

  • Oxeye Platform Helps Fix Code Vulnerabilities

    Oxeye Platform Helps Fix Code Vulnerabilities

    Fresh from raising $5.3 million in seed funding, Oxeye emerged this week from stealth to launch a namesake application security testing platform that, in addition to pinpointing issues in code, also provides advice to best remediate the issues it found.

    The Oxeye platform requires developers to download an observer tool that scans code for vulnerabilities. Once pinpointed, the Oxeye platform guides developers through the remediation process without requiring them to inject agent software into every application.

    Oxeye CEO Dean Agron noted developers don’t typically have a lot of cybersecurity expertise. As application environments become more complex—thanks to the rise of microservices-based applications—it only becomes more likely that mistakes will be made. The only way to resolve security issues before applications are deployed in a production environment is to augment developers using a platform that finds vulnerabilities all the way down to specific lines of code, he said.

    In theory, responsibility for application security is being pushed further left toward developers as organizations embrace DevSecOps best practices. However, making developers more accountable for security without providing them the tools required to achieve that goal is not going to improve the overall state of application security.

    The challenge organizations face today is finding a way to empower developers to address security issues without slowing down the rate at which applications are built and deployed. The best way to achieve that goal is to give developers access to a security tool designed to both analyze code for vulnerabilities and explain how to avoid encountering that issue again, said Agron.

    Left unaddressed, the current software supply chain crises will only deepen, added Agron. According to International Data Corp. (IDC), more than 500 million digital applications and services will be developed and deployed using cloud-native platforms by 2023. That’s roughly equal to the total number of applications and services deployed over the last 40 years, according to IDC.

    It’s not clear to what degree the rise of digital applications might force the DevSecOps issue within more organizations. It’s is clear that a new generation of more complex applications based on microservices is being rolled out to drive a wide range of mission-critical applications. The more business value an application has the more attention it inevitably attracts from cybercriminals.

    Regardless of the type of application, it’s apparent that there is a pressing need for a way to better secure applications. The further left that process starts the less costly it becomes to achieve and maintain security. Cybersecurity teams have a vested interest in helping developers do the right security thing as early as possible if no other reason than to reduce the number of vulnerabilities they will inevitably discover later.

    Making developers more aware of security issues is, of course, only the first step. However, in the absence of any tools that can be easily incorporated within an application development workflow, the concerns being raised will amount to little more than yet another sermon that will be ignored as developers once again rush to meet yet another application delivery deadline.

  • NextArch Foundation Launched to Focus on Microservices

    NextArch Foundation Launched to Focus on Microservices

    The Linux Foundation this week launched the NextArch Foundation to define frameworks and specifications that promote interoperability between microservices that span multiple cloud computing environments.

    More than 40 organizations, including Tencent, Arm, Kong and Ampere, have committed to contributing to 10 technology projects in 2022 in addition to frameworks for three vertical industries.

    Mark Shan, chairman of Tencent Open Source Alliance, said within the next five years the NextArch Foundation expects to have defined a set of standards and best practices that will have been widely adopted.

    The NextArch Foundation’s mission is to provide a home for a set of emerging technologies that would otherwise not get the attention they deserve within the confines of an existing consortium, said Shan.

    NextArch Foundation’s areas of focus will include how continuous integration/continuous delivery (CI/CD) platforms are employed to build microservices and reducing latency between microservices residing in highly distributed computing environments, added Shan.

    It’s not clear where the efforts of NextArch will begin and end as compared to the Cloud Native Computing Foundation (CNCF), another arm of the Linux Foundation that focuses on platforms such as Kubernetes that are widely used to build and deploy microservices-based applications based on containers.

    In general, however, it’s already apparent that microservices are at the core of most digital business transformation initiatives that span everything from artificial intelligence (AI) projects to edge computing environments. The global digital transformation market size was valued at $336.14 billion in 2020 and is expected to grow at a compound annual growth rate (CAGR) of 23.6% from 2021 to 2028, according to market research firm Grand View Research.

    As organizations embrace microservices to build and deploy software, the need to establish a set of DevOps best practices to manage them given the level of dependency that exists between multiple microservices within any application.

    Challenges associated with managing microservices are not likely to deter organizations from adopting them, but they do slow down the transition. Most new applications are intended to run on mobile devices that access cloud services, and typically run more efficiently when constructed as a set of microservices that scale up and down based on usage. The levels of agility and resilience that microservices have are crucial to any digital business transformation initiative, so the general expectation is that the percentage of microservices-based applications that will be running in production environments will increase sharply.

    The challenge, of course, is that, over time, microservices-based applications are more challenging for developers to build and maintain than a traditional monolithic application, though they are easier to update. It’s not likely microservices-based applications will replace existing monolithic applications overnight, but many existing monolithic applications are being converted into a set of microservices that makes it easier for developers to reuse the core functionality of that application.

    Of course, it’s still early days as far as microservices in the enterprise are concerned, but as developers shift toward a new way to build software, the need for a wider range of de facto standards should become more apparent.

  • Apollo GraphQL to Provide More Control Over APIs

    Apollo GraphQL to Provide More Control Over APIs

    Apollo GraphQL today previewed an update to its Federation platform for tracking and managing application programming interfaces (APIs) based on the GraphQL query language to give organizations more control over how APIs are reviewed and ultimately approved.

    Matt DeBergalis, founder and CTO, Apollo, said the alpha edition of the Federation 2 platform provides a unified view of distributed APIs based on GraphQL so they can be more easily governed.

    Federation is based on a unified graph created by Apollo GraphQL to initially provide more visibility into how APIs based on GraphQL are employed within an organization. That capability makes it simpler to increase collaboration among development teams that typically build APIs in isolation from one another, noted DeBergalis.

    The latest version of Federation also adds a shared ownership model that empowers teams to evolve unified graphs across smaller teams, he noted.

    In general, DeBergalis noted that Federation reduces the chances developers are going to create redundant APIs because they can more easily discover existing ones. They can then either employ those APIs as-is or modify them to suit their requirements as they increasingly compose an application using tools such as Apollo GraphQL Studio versus building every capability from the ground up themselves.

    GraphQL

    Overall, Apollo GraphQL claims that Federation is currently being downloaded more than one million times a week, with more than 30% of Fortune 500 companies such as Netflix, PayPal, Zillow, Walmart, Peloton and Priceline already using its tools.

    The company is also now making Federation and the rest of its tool portfolio available under the Elastic License 2.0 which provides the right to use, copy, distribute, make available and prepare derivative works of the software, but prevents organizations from offering a managed service, circumventing license key functionality or removing/obscuring features protected by license keys or remove or obscure any licensing, copyright or other notices.

    GraphQL, originally created by Facebook, is gaining traction as an alternative to REST APIs because it gives developers more control over how data is accessed via an API using a set of query capabilities. That capability is especially appealing when constructing digital business processes that require access by specific classes to large volumes of data. In fact, DeBergalis notes that, in many cases, it’s the existence of a rich set of APIs that enables organizations to construct digital processes that bridge the various isolated processes organizations previously had in place.

    Most IT teams will not be replacing REST APIs with GraphQL-based APIs overnight. However, there will soon be enough APIs based on GraphQL to have a significant impact on how applications are built and deployed. Many applications may wind up invoking external services via both REST and GraphQL-based APIs for many years to come.

    In the meantime, the rate at which applications are being built should substantially increase as tools such as Federation make development teams more productive. The challenge many DevOps teams will soon face is managing a large volume of deployments and associated application updates as more applications are deployed in production environments.