devopsy.kinsta.cloud

Category: Features

  • Digital Customer Experiences: The Future is Modular

    Digital Customer Experiences: The Future is Modular

    With the proliferation of microservices and APIs, will UIs go modular too? Some technologists note a rising trend around smaller, intent-based customer experiences that more directly mirror API endpoints.

    I recently met with Adam Evans, co-founder and CTO of Airkit, to better understand what’s broken with today’s digital customer journeys and how they need to evolve. He predicted that single-purpose experiences will become more pervasive in the future. In the process, we’ll likely encounter fewer native apps and fewer downloads. To enable all this, he’s putting faith in low-code to bring easier integration and automation patterns to more developers.

    The State of Digital Experiences

    Digital customer experiences are becoming increasingly connected and web-based, and at times, disconnected from the core service. In headless environments, end users are engaging with companies through more and more abstraction layers, such as chat, SMS, voice or email notifications. These interactions are increasingly modular and event-driven, noted Evans.

    Increasingly, user encounters are the result of trigger-based patterns activated when user action is required. Not only is the communication style changing, but new devices and platforms have emerged, further making a case for a decoupled development approach. B2C apps become more modular in this transition, presenting experiences built around specific tasks and closely reflecting the specialized microservices or APIs that drive them. Consider the rise of the single page application (SPA) style or AWS Lambda as evidence.

    As more automation and subscription models enable a “set and forget” attitude to commercial software, Evans predicted we’ll likely see more intent- and event-driven workflows emerge. He said these reimagined UIs would shroud platform complexity and, instead, focus on single, specialized actions, like submitting an insurance claim, checking the status of a package or updating your coffee subscription.

    A Broken Customer Journey

    So why would end user digital experiences evolve into more intent-driven applications? Well, complex digital platforms can get feature-bloated very quickly. Bulky applications with many menus are difficult to navigate, thus impacting user experience.

    As Evans describes, generic interfaces often display tons of information irrelevant to the task at hand. “Don’t make me go through generic interfaces to help me do something specific,” he said.

    Clunky interfaces are at odds with small digital tasks that involve an attention span of 20 seconds or less. Evans describes these as “micro touchpoints in our daily lives where you don’t need traditional, large applications.” These actions could be, for instance, looking up COVID-19 infection rates, checking your credit card balance or updating a streaming subscription, he said.

    Organizations have other imperatives to improve user experience, too. For example, if a platform isn’t self-service, it can increase support calls, which can cost a company significant resources. Plus, if the service isn’t event-driven, users must routinely check in of their own accord, which could waste time and encourage tech anxiety.

    Single Page Applications

    In the age of modular microservices, the days of bulky apps and “manual polling” may be limited. To Evans, the solution lies in expressing the “minimum way to represent the transaction of that interface.”

    “How do we keep moving smaller divisions from the back end to the way interfaces are built?” Evans asked. Similar to the way microservices architecture separates domains, Evans noticed UIs segmenting attention along API endpoints. He envisioned more single-purpose experiences being constructed that extend APIs and microservices with a user interface.

    Technically, this may result in more single page applications being developed. Niche UI layers that map APIs would likely carry a data model, Evans described, so that micro apps are delivered with data for entering fields into API calls. As they are web-based, asynchronous single-purpose experiences could also transcend the barriers of app stores and third-party marketplaces.

    Potential Benefits of Modularity

    More intent-based workflows mean less overhead for the user, bringing quicker, more convenient access to the problems they want solved. Sure, users still register with a core service, such as their bank, coffee subscription service or insurance agency for centralized account management. But, users frequent account centers less often, as the periphery of interactions around them continues to grow.

    “The future of apps will look more like individual, intent-based micro apps,” Evans reiterated. These would reflect a metronome of touchpoints Evans called “little moments of delight.”

    Pinging users only when action is required could reduce check-ins, thus reducing digital anxiety. Aside from the user benefits, deployment and maintenance for small applications may be easier to support, said Evans. Lastly, more isolated intentional customer experiences increase engagement, response rates and sales, he added.

    Using Low-Code For Customer Experiences

    Connected digital experiences are relying more and more on APIs. Yet, API integration can be difficult, even for experienced programmers. So, how do we make it easier for people to build interfaces to hit these APIs? Building user-facing layers on top of APIs will require great developer experience, says Evans.

    Lately, low-code has been dominating these discussions. With greater emphasis on visual-driven development, low-code is empowering non-technical employees. To Evans, low-code capabilities will be essential to influence how future customer journeys are constructed.

    Evans noted how low-code “changes the whole game around how apps are built.” For example, branded experiences often require reusable code and common libraries, all of which low-code platforms excel at. In addition, when working with APIs, a “layer over REST design is essential to maintain state and enable long-term processing,” he said.

    Will The New Digital Journey Go Micro?

    Complex interfaces seem to work for conglomerate giants like Amazon. But other scenarios may benefit from more single-purpose workflows. As platforms become more extensive, the user interactions need to become leaner to avoid added stress. As a result, Evans predicts that micro, trigger-based B2C touchpoints will become more common in the coming years. In this paradigm, better UI extensions of common APIs could help bring people into the equation.

    “We’ll see a lot of cool stuff in the next decade,” he said. “Future apps won’t look like what past ones looked like.” As IT moves to support new, multiple channels, such as chat, voice, web and VR/AR, our perception of what an application is also will inevitably alter.

    In tomorrow’s “great unbundling of apps,” as Evans called it, “if you don’t use it every day, there’s a pretty good chance it doesn’t need to be there.”

    There are many schools of thought on the best methods to retain quality user experiences. Do you think modularity is the answer? What do you think tomorrow’s digital experiences will look like? Feel free to let us know in the comments below.

  • GitLab Acquires UnReview to Further AI Ambitions

    GitLab Acquires UnReview to Further AI Ambitions

    GitLab announced this week it has acquired UnReview, a provider of a tool that employs machine learning algorithms to identify which expert code reviewers to assign to a project based on both the quality of their previous efforts and current workloads.

    David DeSanto, senior director for product management at GitLab, said the acquisition of UnReview is the latest step in an AI strategy that, in addition to optimizing DevOps processes, will eventually unify machine learning operations (MLOps) and DevOps workflows.

    Accessed via the Dev section of the GitLab platform, UnReview will also be employed to manage the overall code review process.

    GitLab

    DeSanto said GitLab is committed to employing AI technologies to automate workflows and compressing cycle times across all stages of the DevSecOps life cycle. The goal is to not eliminate the need for DevOps teams, but rather eliminate low-level tasks that conspire to hamper productivity while at the same time improving application security, noted DeSanto.

    Providers of DevOps platforms are now locked into an AI arms race on two separate fronts. Each of them clearly sees the opportunity to leverage machine learning algorithms and other forms of AI to automate a wide range of processes. At the same time, it’s apparent providers of MLOps platforms are borrowing heavily from DevOps best practices to manage the development of AI models. However, from the perspective of a DevOps team, an AI model is just another type of software artifact. Rather than deploying two distinct platforms, the goal should be to bring the data scientists that build AI models into the larger DevOps community, said DeSanto.

    The current challenge, of course, is the pace at which DevOps and data science teams work. It may take six months or more for a data science team to construct and validate an AI model that needs to be embedded within an application. Aligning the timetable for an AI model with the application development life cycle is difficult to accomplish if neither team has any meaningful visibility into each other’s workflows. As the rate at which AI models can be developed steadily improves, that alignment issue will only become all the more pressing.

    Going forward, it’s hard to envision any application that won’t have some sort of AI model embedded within it. The issue is that, just like any other software artifact, an AI model needs to be updated. As new data sources become available, an AI model is likely to drift beyond the parameters intended. A rapid change in business conditions may also require the replacement of an entire AI model. The same processes that DevOps teams apply to update any software artifact can also be applied to an AI model.

    It’s unclear how long it will take before some type of convergence of DevOps and MLOps inevitably occurs, as organizations look for more efficient ways to manage what will become thousands of AI models. The one certain thing is the longer it takes to make the effort, the more difficult it will become to overcome the organizational inertia that has been allowed to set in.

  • Cribl Automates Observability Efforts

    Cribl Automates Observability Efforts

    Cribl today announced it has updated the Cribl LogStream observability tool in addition to generally making available a software-as-a-service (SaaS) offering dubbed LogStream Cloud.

    Nick Heudecker, senior director for market strategy and competitive intelligence at Cribl, said Cribl LogStream provides the means to aggregate log data collected from multiple platforms and applications in a format any observability or monitoring tool can access.

    The challenge with observability platforms today is they leave it up to IT organization to copy and paste data into the platform. LogStream automates that process via a log router that collects and optimizes data streams from existing installed agent software and then shapes and routes that data on to analytics platform.

    Version 3.0 adds LogStream Packs, a framework for accelerating deployments of the log router. Alternatively, DevOps teams can employ LogStream Cloud to build and share LogStream configuration models.

    Heudecker said the goal is to reduce the cost of achieving observability by reducing the time and effort required to set up and manage data pipelines. No customization effort on the part of a DevOps team is required to collect and send data from hundreds of sources to any number of destinations, noted Heudecker.

    While observability is a core DevOps tenet, achieving it has been a major challenge. In addition to deploying and managing agent software to instrument IT environments, there’s a significant amount of time and data engineering effort needed to set up the pipelines employed to transfer data to a platform where it can be analyzed. Cribl is making a case for automating those data engineering tasks using a tier of software that abstracts data into a format that can be consumed by multiple observability and monitoring platforms.

    It’s not clear yet to what degree IT organizations perceive observability to be an evolution of monitoring, or simply the next logical evolution of monitoring. One way or another, IT teams need a lot more context than they have historically been able to attain using legacy monitoring tools. Each platform employed within an enterprise typically comes with its own monitoring tools that are used by the IT teams tasked with managing it. Whenever there is an issue, however, IT teams will spend hours correlating data from multiple tools to ascertain the root cause of a problem.

    Observability platforms promise to reduce that time and effort by applying analytics to data collected from multiple platforms. The challenge now is finding a way to efficiently collect all that data.

    It may be a while before IT organizations start to abandon all the monitoring tools they have in place in favor of observability platforms. However, as IT environments continue to become more complex (thanks, in part, to the rise of cloud-native computing platform based on microservices) the need for those platforms becomes more acute. The issue is enabling DevOps teams to achieve that goal without having to wait for an overworked data engineer to find the time to build a pipeline.

  • 10 Actions IT Can Take to Curb Climate Impact

    10 Actions IT Can Take to Curb Climate Impact

    Digital technology is responsible for 3.7% of total CO emissions, according to estimates from The Shift Project. This could increase, as cryptocurrency mining is leaving a massive carbon footprint. With the world’s climate at stake, every percentage point matters.

    Thankfully, many tech companies have announced significant climate pledges to reduce emissions or offset their carbon footprint. For example, Microsoft states they will be carbon neutral by 2030. Amazon has committed to a deadline of 2040, and other companies such as Infosys have co-signed. Netflix’s climate commitment states they will reach net-zero greenhouse gas emissions by the end of 2022.

    Sustainability goals are vital long-term benchmarks, but on-the-ground technologists must make immediate optimizations to realize them. So, what exact steps can enterprise IT take to reduce their energy consumption and thereby reduce greenhouse gas emissions?

    I recently met with Anant Adya, Infosys, to explore the overall energy footprint of enterprise technology. Below, I’ll cover 10 ways IT can reduce its impact on the environment, including actions like auditing legacy infrastructure, optimizing cloud operations and moving toward renewable energy sources. Many of these energy optimizations bring the added benefits of cost savings and code consolidation.

    1. Reduce Resource-Heavy Legacy Infrastructure

    One potential cause of unnecessary energy consumption is legacy infrastructure. To reduce power consumption, Adya recommends going straight to a network compute storage setup. You may find energy consumption savings by porting resource-heavy legacy systems to the cloud. This will be especially effective if you’re running older end-of-life machines with less efficient processing.

    2. Reduce the Number of Clouds

    Next, look at the number of clouds your organization has adopted, Adya recommended. In recent years, companies have moved to multi-cloud setups for reasons like performance, cost or features. However, these movements could cause unnecessary duplication. For a large enterprise, refactoring your multi-cloud usage could mean reducing from five or six clouds to two or three, said Adya. With the right combination, you could very likely reach equivalent benefits with less reliance on multiple clouds.

    3. Reduce the Number of Core Data Centers

    Look at the number of sites in your core data centers and reduce the footprint, if possible. In his digital transformation work, Adya described working with a client to consolidate six large data centers into three essential locations — one for disaster recovery and two others to support American and European zones.

    4. Move Edge Locations to the Cloud

    Large organizations may be supporting a lot of edge infrastructure. Yet some locations, such as offices, don’t require that kind of infrastructure, Adya suggested. He recommended reducing local servers and embracing more cloud-based computing solutions, overall. He described one case in which an organization consolidated 600 edge sites to 350, thus reducing power consumption by 40%. Adya credited the cloud for delivering lower costs and greater scalability and resiliency.

    5. Embrace Cloud-Native Administrative Operations

    Cloud computing is arguably more energy efficient than traditional on-premises arrangements with its pay-per-use model and multi-tenant approach. To get the most out of the cloud, Adya recommended moving to the cloud, along with adopting cloud-native software. Most operational and administrative work can be processed in the cloud, he noted.

    6. Consolidate and Rationalize Resource Utilization

    Another way to stem energy consumption is to check for underused or forgotten assets. While the cloud can help optimize software, there is a good deal of unnecessary cloud spending on underused resources. In 2020, companies wasted $17.6 billion paying for idle resources and overprovisioned computing instances, reported ParkMyCloud. Adya thus recommended looking at the entire server and storage estate to calculate the server utilization and slimming down wherever possible.

    7. Increase Power Usage Effectiveness (PUE)

    Hardware is much more efficient these days — sometimes by as much as 10X more powerful with 10X less energy consumed. As storage technologies also are always improving, it could make sense to upgrade to new hardware to reduce overall power usage. It’s important to monitor power usage effectiveness (PUE) and check power ratings before and after migrations. Adapting your information life cycle management tiering practices for storage could also help optimize to reduce wasted power, Adya added.

    8. Meet Sustainability Goals on Campus

    Have you ever driven by an office park at night and seen thousands of empty rooms with all the lights on? This has got to change. Another way to reduce power is to limit a campus’s energy consumption, described Adya. Smart automation and remote monitoring could be used to manage power efficiency by turning off lights and heating and cooling to meeting rooms when empty, for example.

    9. Power the Business With Renewable Energy

    Run your campus with solar power. Adya described how Infosys is doing this by mounting 40MW solar panels at their corporate centers, in effect sourcing 43% of its energy from renewable sources. Another more passive way to invest in renewables is to choose a data center provider that commits, under contract, to using a high percentage of renewable energy.

    10. Purchase Carbon Offsets

    The previous goals are all active steps to reduce energy requirements. However, once an organization has attempted these optimizations, another option is carbon offsetting. This indirect method effectively cancels out a company’s emissions by funding green activities, such as tree planting.

    However, there is debate over the effectiveness of carbon offsetting, as trees take decades to become effective carbon consumers, and the practice doesn’t advocate for immediate change to harmful practices. “To be serious about tackling climate change, [organizations] need to stop carbon emissions from getting into the atmosphere in the first place,” wrote Alia al Ghussan for Greenpeace.

    IT’s Role In Curbing Climate Change

    Dire climate circumstances require quick action from all business units. In the process, organizations will likely consider many initiatives simultaneously to address their climate impact. However, as more companies become digital-first businesses, the onus falls on IT to support these changes.

    In addition to the above actions, there are undoubtedly other ways enterprise software architects can stimulate sustainability initiatives within their organization. This could include refactoring code into more lean iterations or eliminating unnecessary records storage. Tech leaders could also vocalize their support for global pledges, such as the Paris Climate Agreement, RE100 or Global Optimism.

    It would take a solar power plant covering 115,625 square miles, roughly the size of New Mexico, to power the world with solar energy! As you can see, it will take a lot of work to reverse our reliance on fossil fuels. But with scalable cloud computing and more intelligent infrastructure optimizations, IT can do its part to contribute to curbing climate change.

  • Atlassian Delivers on Forge App Dev Platform Promise

    Atlassian Delivers on Forge App Dev Platform Promise

    Atlassian this week made available a Forge platform for building applications that complements its existing portfolio.

    Mike Tria, head of platform engineering for Atlassian, said Forge is intended to provide an application development environment to both IT organizations and third-party partners. It provides developers with access to an integrated Atlassian DevOps toolchain to accelerate testing, deployment, debugging and to capture log data, added Tria. Forge also presents developers with a command line interface through which they can be onboarded to the Atlassian cloud where Forge runs to access documentation and application samples. It uses OAuth 2.0 to ensure applications deployed on the Atlassian cloud only access data they have permission to access.

    The overall goal is to provide developers with a more modern application development environment as an alternative to the application development platform the company previously made available.

    Once an application is built, developers can then publish their applications on the Atlassian Marketplace as free or commercial offerings. There are already more than 3,500 Forge apps that were created during a beta process that began late last year. Forge will soon be extended to the rest of the Atlassian portfolio, noted Tria.

    Forge is intended to complement an Open DevOps initiative launched earlier this month that tightens integration between the Jira project tracking and management tools provided by Atlassian and a wide range of other tools commonly employed by DevOps teams. The goal is to not only make it easier to correlate issues that are listed in Jira with artifacts found in various software platforms, but also to collect data from DevOps tools to automatically update Jira.

    That data will then be employed to inform key performance indicators (KPIs), based on graphs that Atlassian provides within Jira, to keep track of value streams. Rather than having to acquire a separate value stream management (VSM) platform to track software development progress, the insights needed to understand the impact of, for example, a delay to one project becomes a dividend of using Jira.

    Like most providers of software-as-a-service (SaaS) applications, Atlassian has been making available a platform for building applications on top of the same platform it employs to build its own applications. Atlassian claims there are more than 1,200 partners building applications in addition to internal IT that teams that have built custom extensions to its applications. Atlassian has already shown a proclivity for acquiring independent software vendors (ISVs) that build applications on its platform. As part of the overall Forge initiative, Tria said Atlassian will be working more closely to identify the white space that won’t be addressed by the Atlassian product roadmap at some future date.

    In the meantime, independent software vendors and internal IT teams will need to determine to what degree they will prefer to stand up their own application development environment versus opting to be dependent on Atlassian. In theory at least, applications built on Forge should be more tightly integrated with the rest of the Atlassian portfolio. The only potential downside is, of course, any potential conflict that might emerge with a provider of an application development platform that also happens to sell application software.

  • Unifying Partner Ecosystems With a Distributed Ledger

    Unifying Partner Ecosystems With a Distributed Ledger

    Blockchain has become famous in recent years for powering the cryptocurrency craze. But the fundamentals behind blockchain could prove helpful in other areas of the data economy, too. Because, as the value of data rises, so does the need for accurate, real-time data sharing across multiple partners.

    As we saw recently, global trade is surprisingly fickle. If a 1,300 ft long cargo ship can end up blocking the Suez Canal for an entire week, imagine how many data record incongruities the shipping and logistics industries have to sort out each day. Similarly, other partner networks, such as food distribution or airline affiliates, for example, must constantly share data back and forth to remain in business.

    Since a distributed ledger is external yet sharable with partners, it opens some interesting data-sharing possibilities. Similar to merges for collaborative software, partners would retrieve and manipulate the distributed ledger, which would act as a source of truth for status on a physical object or a piece of data. Essentially, this process could reduce manual reconciliation efforts and avoid disputes when something goes wrong.

    I recently spoke with “father of serverless” and AWS Lambda inventor Tim Wagner. Wagner, now heading Vendia, shared with me why he foresees distributed ledgers as the future for real-time, business-to-business data sharing. “Supply chains are surprisingly brittle,” Wagner said. To solve this problem, we need an “automation of that workflow that isn’t centralized any longer,” he said.

    Role of a Distributed Ledger

    A distributed ledger could be especially relevant for a multi-party supply chain. Within multi-partner agreements, data tracking is complex, and many partners struggle to come together. “Companies are struggling for a lack of truth,” said Wagner. “Everyone wants their own copy of the data, but they want it to be locked to what everyone is seeing at the same time.”

    For example, take supply chain management. Suppose an automotive parts manufacturer produces a chassis. They send it to a shipping logistics provider, who then sends it to an automaker to complete assembly of an automobile. If the chassis breaks at some point during these handoffs, whose fault is it? Without a system of record, you open a big problem of distrust, Wagner explained.

    Or, consider an airline ecosystem. Partner airlines must often coordinate multi-carrier flight plans, apply discounts or settle unused travel vouchers. Often, it’s difficult to track the journey of these transactions between organizations. An externalized ledger could help partner airlines follow the route of a single passenger, helping to ease financial settlements.

    “It’s not just about sharing, which is hard enough, but it’s really about sharing with control,” said Wagner. These days, tracing the lineage of data is critical, as is having real-time visibility into an object’s state. A distributed ledger could help these partner ecosystems have a record they can all trust. Wagner describes this as a tamper-proof, immutable record — an “unassailable source of truth.”

    Would This Replace Partner APIs?

    What’s especially interesting to the integration-minded is that the distributed ledger concept could supplant established business-to-business communication models. Over the last couple of decades, most partner integrations have moved to RESTful API connections. One company opens up data access, and another authenticated partner makes HTTP API calls to integrate data into their own application.

    Yet, the issue here is that the API is only a layer on top of a private database owned by the provider. Located behind closed doors, there’s no industry-wide real-time data synchronization. API calls are good for data retrieval and manipulation, but stringing a sequence of thousands of transactions together is difficult, described Wagner. Retaining the time-series integrity of a complex database is a little too much for synchronous calls to handle.

    Instead of opening access to an internal platform via API, Wagner believes that a distributed ledger is a better fit for certain business-to-business machine automation. “Any place where you see API-level protocols developed to maturity is a good sign; there is a good chance distributed ledgers will find greater speed,” he said. “Trying to pull that information through APIs and pray you’re finding the right data is difficult to manage.”

    For example, Wagner referred to how some animal shelters are creating a global repository to avoid siloed records. In doing so, they are making a global animal rescue schema for a unified database that could hopefully help every pet find a home.

    Communicating with the ledger would still involve calls, but likely not your typical RESTful requests. Wagner advocates for the use of GraphQL as a better method to involve clients around changes. With a GraphQL API, stakeholders can query, mutate and subscribe against changes in a distributed system. GraphQL isn’t perfect, but its easy data mechanics make it a Goldilocks-style middle ground between REST and SQL, said Wagner.

    Getting Buy-In

    A synchronized distributed ledger could help resolve disputes and reduce manual checks. But, how do we get buy-in? How can you convince an entire partner ecosystem to align around a distributed ledger as a source of truth?

    Wagner says there is usually a leader or single manufacturer leading the charge. This figure is likely a more prominent, well-respected player in the process. But for a digital ledger system to be successful, it must also satisfy other criteria too, Wagner said:

    • Data schema forethought: Agreeing upon a shared data schema may be a challenge. Ecosystems will require forethought when designing a data model for the long haul.
    • Compliance: There are many new data regulations to consider, such as GDPR, CCPA and PCI. “You can’t blindly copy data the way you used to,” said Wagner.
    • Governance: As enterprises deal with data crossing boundaries, they must apply governance measures to satisfy compliance and maintain security. This governance needs to be tightly associated with data and offer fine-grained control.
    • High performance: A distributed ledger requires operational flexibility for large objects, such as a 5 TB file, noted Wagner.
    • Redaction capabilities: Whereas some partners must see all fields, others may, by law, be limited in what they can view. Thus, a ledger must include the ability to redact fields. Wagner described this as “intentional redaction or visibility control of individual customer records.”

    Of course, different industries are at very different points along their digital journey, some more advanced than others. Change may be easier for, say, financial services supporting ACH payment technology, which Wagner described as being “ripe for natural organic expansion into a data-centric methodology.”

    The Poor Man’s Blockchain

    Tapped into the same feed, an extensive partner ecosystem could use a blockchain-esque arrangement to stay on the same page. This could help reduce manual reconciliation typically handled through email or over the phone.

    Yet, as distributed systems experts are few and far between, implementing such technologies will most likely involve a cloud platform solution, said Wagner. He jokingly calls this the “poor man’s blockchain.” Such a solution must be cloud-friendly, enterprise-focused and easy to integrate and deploy.

    As more and more critical data begins to reside outside company walls, “organizations have to reconstitute that data to work with partners,” said Wagner. A distributed ledger could, in effect, act as a sort of outsourced centralized IT, enabling a data model for serverless environments.

  • Digital.ai Deepens Value Stream Management Integration

    Digital.ai Deepens Value Stream Management Integration

    Digital.ai announced today it has expanded usage of machine learning algorithms within its namesake value stream management (VSM) platform to include modules to optimize flow and improve application quality in addition to enhancing its risk prediction and process optimization modules.

    In addition, Digital.ai has expanded the number of pre-built integrations it now provides for hundreds of DevOps tools and platforms.

    Derek Holt, general manager of agile and DevOps for Digital.ai, said the goal is to expand the bi-directional flow of data between the core Digital.ai platform and modules and tools provided by the company and its third-party DevOps partners.

    Digital.ai was formed from the merger of XebiaLabs and CollabNet VersionOne. The combined company has rolled up Numerify, a provider of analytics tools infused with artificial intelligence (AI), Experitest, a set of testing tools and Arxan, a provider of an application security platform. With the latest release, these capabilities have been integrated into the core Digital.ai platform in a way that goes well beyond merely providing access via a common user interface, said Holt.

    The goal is to provide organizations with a VSM platform through which better decisions can be made to optimize software development and delivery by first collecting data from all the DevOps tools employed and then using machine learning algorithms to surface optimization recommendations, noted Holt. As application development environments become more complex to manage, it’s already apparent that most IT teams will require AI capabilities embedded in a VSM platform to manage interdependent projects, noted Holt.

    Armed with those recommendations, it becomes simpler to reallocate resources in the event a critical project is going to be completed later than planned or shift resources to make sure that project is completed on time. A VSM platform also enables IT organizations to assess the impact those decisions will have on the rest of the business at a time when organizations have never been more financially dependent on the timely delivery of software. The late delivery of a single application module can wind up having a profound impact on revenue projections for organizations that increasingly rely on digital processes to engage customers.

    A recent survey conducted by Digital.ai found that many digital transformation initiatives are struggling, to some degree. Nearly half of respondents (49%) said they are not seeing the results they expected from their digital transformation efforts, and 54% admitted they were worried about their ability to compete. Over 90% need to see a better return on their digital transformation investments.

    Digital.ai claims it currently has more than 1,200 customers, including Allianz, Commerzbank, eBay, Janus Henderson and Levi’s that are using elements of the Digital.ai platform to better manage software development projects. Many of the users of those tools now include business executives and other application stakeholders that are employing a VSM platform to track the progress of application development projects. Digital.ai Analytics Lenses that are domain-specific make it simpler for different classes of end users to access pre-built dashboards and metrics, noted Holt.

    The market research firm Gartner has predicted that 70% of organizations will employ a value stream management platform by 2023 to improve flows across their DevOps pipelines. However, as DevOps platforms and project management applications continue to evolve, many are also adding many of the analytics capabilities found in a VSM platform. Each IT organization will need to decide which approach makes the most sense for them, but Digital.ai is clearly betting that as application development becomes more challenging, the need for an integrated VSM platform will become much more apparent.

  • JFrog Adds Private Distribution Network for App Binaries

    JFrog Adds Private Distribution Network for App Binaries

    At its online swampUP conference today, JFrog launched a Private Distribution Network (PDN) that makes it simpler and faster to distribute application binaries across an extended enterprise.

    Yoav Landman, JFrog CTO, said the PDN provides the equivalent of a content delivery network (CDN) designed specifically for distributing application binaries using a peer-to-peer network managed by JFrog. Each binary distributed is an immutable signed release that provides visibility and traceability to validate the source destination as well as the integrity of the binary, added Landman. That approach essentially applies concepts from a blockchain network to the distribution of application binaries, noted Landman.

    The PDN is based on patent-pending network optimization technology that employs caching, distribution nodes and lightweight accelerators that enable IT teams to distribute binaries through inbound-only firewalls or to environments that have limited connectivity, said Landman.

    Finally, the PDN also comes with tools to analyze binaries for open source security vulnerabilities and compliance with license policies in addition to role-based access controls (RBAC).

    Landman said the goal is to provide a way to distribute binaries via a single click all the way to edge computing platforms in a way that is tightly integrated with the continuous integration/continuous delivery (CI/CD) pipelines and software development life cycle (SDLC) processes a DevOps team already employs.

    Currently available via a private beta, PDN is scheduled to become available in the third quarter 2021 with pricing based on a per-use model that requires no upfront costs.

    JFrog

    For years now, JFrog has been making a case for applying DevOps best practices to the deployment of binaries rather than just managing source code. As enterprise IT environments become more distributed, the need to manage the deployment of binaries at scale becomes more acute. IT teams are not going to be able to dispatch software engineers to manually install binaries on every edge computing platform employed. The goal is to provide IT teams with complete transparency into software distribution in a way that makes it simple to address compliance requirements, said Landman.

    Most organizations already find deploying software to be a major challenge. CI processes are generally well understood as part of any application development process. CD has proven to be a more elusive goal, because each target platform on which software is destined to run tends to be unique, which makes automating the delivery process challenging. That issue is only going to be more difficult to address as organizations attempt to install software across hundreds, or even thousands, of edge computing platforms that might be based on a wide range of types of platforms. A PDN alleviates many of these issues by providing IT teams with a network to centrally manage the process, noted Landman.

    At this point it’s now only a matter of time before most organizations confront this next major DevOps challenge. As organizations look to process and analyze data at the edge to drive any number of digital processes in near real-time, the amount of software deployed outside of a cloud or traditional data center is about to explode. The challenge now, of course, is finding the most efficient way to secure delivery of all that code.

  • Oracle and Allies Launch ARM-Based Cloud Service

    Oracle and Allies Launch ARM-Based Cloud Service

    Oracle announced today it will make available for the first time ARM-based processors on the Oracle Cloud Infrastructure (OCI) that will also be supported as targets for deploying applications using GitHub, GitLab or Jenkins platforms. The latest Oracle service is based on processors from Ampere Computing.

    The company also revealed today it has joined the Continuous Delivery Foundation (CDF), an arm of the Linux Foundation that oversees the development of open source DevOps platforms and tools such as Jenkins and Spinnaker.

    Matt Leonard, vice president of compute for OCI, said the OCI Ampere A1 Compute provides an alternative to existing support for the x86-based processors that Oracle provides. That service will be offered at a cost of one cent per core hour with virtual machine sizes ranging from one to 80 OCPUs configured with one to 64 GB of memory per core or as a bare-metal service with 160 core and 1 TB of memory. Pricing per GB of RAM per hour is $0.0015. At that price point, Leonard said Oracle is now offering the lowest price per core of any cloud service provider.

    The growing availability of ARM-based processors is starting to have an impact on cloud economics at a time when organizations are significantly increasing the number of applications being built and deployed on public clouds. Many of those organizations, to reduce overall costs, are now actively evaluating ARM-based services, noted Leonard.

    To help jumpstart application development on the platform, Oracle is providing organizations with three classes of OCI Ampere A1 Compute services. An Oracle Cloud Free Tier gives developers $300 in free credits for 30 days. The Always Free ARM option gives developers four A1 cores and 24 GB memory, while an ARM Accelerator option provides open source developers, independent software vendors (ISV) partners, customers and universities with ARM-based development projects that need additional resources beyond what the Oracle Cloud Free Tier provides with credits for a 12-month period.

    Oracle Linux, Java, MySQL, GraalVM and the Oracle Container Engine for Kubernetes (OKE) service are also all available on the OCI Ampere A1 Compute along with integrations with DevOps platforms from GitHub, GitLab and/or Jenkins. Other vendors providing support for OCI Ampere A1 Compute include SUSE, Datadog, OnSpecta, NGINX and Genymobile.

    Oracle has also made available an Oracle Linux Cloud Developer image that enables DevOps teams to install, configure and launch a development environment via an OCI console that includes OCI client tools, utilities and common programming languages such as Java, GraalVM, Python, PHP, Node.js, Go and C/C++.

    Finally, each Ampere core is single threaded by design with its own 64 KB L1 I-cache, 64 KB L1 D-cache and a huge one MB L2 D-cache to eliminate any ‘noisy neighbor’ issues that IT organizations might otherwise encounter.

    Oracle is clearly betting that ARM-based processors will present the company with an opportunity to gain share at the expense of larger infrastructure-as-a-service (IaaS) rivals such as Amazon Web Services (AWS) and Microsoft Azure. It’s not clear to what degree IT teams might employ a different cloud service just to access ARM-based processors. However, in a world where IT teams now routinely employ multiple clouds, as far as Oracle is concerned, the playing field has never been more level.

  • API Security by Design

    API Security by Design

    “APIs are nothing new,” said Secure Code Warrior co-founder and CTO Matias Madou, but they have recently become more widely used.

    And where they were once a local mechanism, they are increasingly used in a distributed manner, partly because of changes to application architectures. Another reason is that users are increasingly likely to access systems from outside the organization, whether they are customers, suppliers or employees working at home.

    Potentially anyone and anything can access an API, so developers and architects should therefore assume that APIs are exposed, and treat requests accordingly.

    This means addressing issues such as authentication and authorization, and generally ensuring that the only data exposed by the API is the data that’s supposed to be exposed.

    So assume every API call is malicious, suggested Madou.

    Start at the Beginning

    Achieving API security starts with the design and architecture, so jumping in and writing code immediately is a mistake. Unfortunately, starting with a completely blank slate is unusual, and some code will likely already exist. In that case, it is especially important that the design makes provisions for possible weaknesses.

    If you want secure APIs, then ensure that everyone working on the project – architects, developers, testers and so on – are “very security savvy,” said Madou.

    The need to improve skills is often triggered when the company or one of its competitors experiences a problem.

    So teams should work to identify any existing problems, realize they need to proactively avoid the underlying issues, and undergo appropriate training, he says.

    The trouble is, “security and developers are not often the best of friends,” Madou said. So, developers tend to think that security is the responsibility of their security colleagues. But there should be a common goal: making reliable and secure software.

    “Security needs to help developers,” he said. One way of achieving this is to appoint a ‘security champion’ to act as a bridge between the security and development teams. An embedded security person can help developers realize that security is an enabler, not a blocker.

    Help When Help’s Needed

    Embedding communication from the security team into developers’ workflows is another part of the process. Slack is one possible conduit. Security people need to be wherever developers discuss issues. Then, they can take advantage of opportunities to say things like, “it looks like you’re having problems with SQL injection. Here’s some training material that might help.”

    Developers live in their IDE, so that’s where integration should occur. But design such systems to help developers, not to control them. “Developers are people, not robots controlled by machines,” Madou warned.

    Another consideration is that it’s important to avoid unnecessarily interrupting developers. Such systems should therefore predict what a developer is about to do and deliver appropriate guidance.

    For example, if someone codes a database connection, the system could offer the statements that securely retrieve information. Then, the developer can copy and paste them instead of starting from scratch each time. Using new code every time carries the risk of introducing vulnerabilities.

    “It’s tricky to make these systems,” Madou admited, but he predicted they will become increasingly common in the coming years.