staging-devopsy.kinsta.cloud

Category: DevOps Toolbox

  • Atlassian Extends Jira’s Reach Into DevOps Workflows

    Atlassian Extends Jira’s Reach Into DevOps Workflows

    Atlassian today added a range of capabilities to its Jira project management application that make it easier to manage software development projects, including a toolchain page that simplifies tool discovery for any given project.

    In addition, Atlassian is including a Discover tab on that page that makes it possible to track activities and set priorities by providing more context around the goals for any given project.

    Atlassian said it also plans to add scope change insights later this month and, in the first quarter of 2023, auto-detection of stuck issues will be added to an existing ability to predict when application development projects will be completed.

    The company has also added a pull request activities feed to the Code tab in Jira to make it easier to compare and contrast issues, identify anomalies and discover opportunities to move work forward along with a Code insights view for tracking branch, commit, pull request and deploy activities.

    The Releases tab in Jira now surfaces feature flag status alongside development, build and deployment statuses. There’s also an ability to automatically generate release notes in the Confluence wiki application provided by Atlassian. Finally, in 2023, Atlassian is committing to making available a dark mode option for running Jira that some DevOps teams prefer.

    Suzie Prince, head of product for DevOps at Atlassian, said all these Jira updates are extensions of an Open DevOps initiative the company launched earlier this year that integrated Jira with a wide range of DevOps tools. The goal is to make it simpler for DevOps teams to track project progress without necessarily having to deploy, for example, a separate analytics application. As part of that effort, Atlassian also revealed Jira has been integrated with Compass, an extensible catalog launched earlier this year for tracking software components and is available in beta.

    In effect, Atlassian is making a case for Jira to become a software development project tracking hub by automatically pulling data from various other DevOps tools. Rather than requiring a project manager to send multiple requests for updates to individual developers and manually enter data, Jira’s integrations with various tools can both pull relevant data and apply analytics in a way that makes it simpler to identify issues that are adversely impacting deadlines.

    Those insights can then be shared more easily with both development teams and other stakeholders in the business that have a vested interest in making sure project deadlines are met. It can also make it simpler for application development teams to justify the need for additional resources.

    Project management is, of course, one of those thankless tasks that doesn’t always get the appreciation it deserves. However, as it becomes easier to automatically collect data about the status of any given project, the task itself should become less intrusive. Hopefully, as those tasks become more automated, the friction that often exists between application development teams and project managers will also subside.

  • SAP Adds Low-Code Platform to Build Custom Apps Faster

    SAP Adds Low-Code Platform to Build Custom Apps Faster

    At the SAP TechEd 2022 conference, SAP SE today announced it has added a low-code platform, dubbed SAP Build, to its portfolio to make it simpler for organizations to build custom applications.

    Sebastian Schrötel, vice president and head of low-code/no-code solutions for SAP, said SAP Build is designed to make the company’s low-code tools more accessible to a wider range of developers, including so-called citizen developers that generally don’t have a lot of programming expertise.

    The goal is to make it possible to monitor, analyze and automate processes by leveraging more than 500 templates available within SAP Build. The goal is to make it possible to not only build applications faster but also deploy them via a single click, said Schrötel.

    The company’s approach to building custom applications separates its core applications from code developed by others by running pristine instances of SAP enterprise resource planning (ERP) applications in a separate cloud, known as the SAP digital core. A custom application is then deployed in a separate cloud and accesses SAP data via application programming interface (API). That approach enables SAP to update its ERP environment without worrying about breaking custom extensions.

    Of course, not every organization has transitioned to that model, so there are still plenty of instances of SAP software running in on-premises IT environments extended using code written in Java or the proprietary ABAP programming language. Over time, SAP is hoping that custom code will either be retired in favor of a process it has added to its ERP platform or by a more modern instance of that process running with a custom application deployed on a separate SAP cloud platform.

    SAP also has partnerships with providers of low-code platforms like Mendix and OutSystems that organizations can employ to build applications, but with the launch of SAP Build, the company is making a more concerted effort to encourage organizations to adopt the low-code platform it developed.

    While it’s not clear how eagerly low-code tools are embraced by citizen developers versus professional developers, the one thing that is certain is the pace of application development is accelerating. In many instances, professional developers are embracing low-code platforms as an alternative to procedural code to reduce expanding application development backlogs brought on by digital business transformation initiatives. In other instances, professional developers are employing low-code tools to collaborate more easily with end users as they build and deploy the applications that drive those processes.

    Regardless of the motivation, the impact this accelerated rate of application development will have on DevOps teams is profound. Not only do these applications have to be deployed in production environments, but DevOps teams must also secure and maintain a much larger application portfolio. As a result, the need to automate DevOps workflows will become more pronounced than it already is.

  • HPE Adds VMware Cloud Platform to Managed GreenLake Service

    HPE Adds VMware Cloud Platform to Managed GreenLake Service

    At the VMware Explore 2022 Europe conference, Hewlett Packard Enterprise and VMware, Inc. this week extended their alliance to integrate instances of the VMware Cloud platform into the managed HPE GreenLake service.

    Hang Tan, chief strategy officer for HPE, said for the first time HPE is managing the entire VMware Cloud stack in addition to its servers and storage platforms via a service that is based on a consumption pricing model. The goal is to reduce the total cost of IT by not requiring IT teams to overprovision IT infrastructure resources to run VMware Cloud, he said.

    Previously, IT teams could have deployed VMware Cloud on the HPE GreenLake service in a more disaggregated fashion, but that would have required separate billing processes, added Tan.

    Many organizations are currently revisiting their IT strategies during increasingly challenging economic times, noted Tan. The managed HPE GreenLake service enables IT teams to devote more of their internal IT resources to building and deploying applications rather than managing IT infrastructure, he added.

    It’s not clear how many organizations are transitioning toward a subscription model for consuming on-premises IT infrastructure, but in the cloud era it’s apparent that more of them are comfortable consuming IT as a service. HPE reported that the HPE GreenLake service supports more than 120,000 users accessing more than one exabyte of data worldwide. Among the top 100 HPE customers, nearly 80% have already adopted the HPE GreenLake platform, the company claims.

    The challenge many organizations face is they still need to deploy and update application workloads in on-premises IT environments for both performance reasons and to meet various compliance mandates. The HPE GreenLake service is an effort to bring a cloud operating model to on-premises IT environments running not just VMware Cloud but also a wide range of other rival software stacks that HPE already supports.

    Naturally, organizations that have embraced DevOps workflows would need to align the way they build and deploy applications to a managed service. IT teams that find that challenging, however, could opt for a self-service edition of the HPE GreenLake service that provides IT teams with more control over the underlying infrastructure being consumed as a service, noted Tan.

    Regardless of approach, it’s apparent that some type of as-a-service approach to consuming IT infrastructure is being more widely employed across what are becoming highly distributed computing environments. Each organization will need to determine for itself to what degree treating IT more as an operating versus capital expense makes the most economic sense.

    However, there’s no doubt that infrastructure cycles are generally going to be less disruptive when they are included as part of a multi-year services agreement. IT teams may also find it easier to take advantage of ongoing artificial intelligence (AI) advances when IT environments are managed on their behalf by a vendor.

    One way or another, the way IT infrastructure is managed is continuing to evolve at a time when organizations are starting to focus more of their efforts on applications that are becoming more difficult to build, deploy, secure and maintain.

  • Open Banking Shouldn’t Be Open Season on Your APIs

    Open Banking Shouldn’t Be Open Season on Your APIs

    Open banking has become the latest technological advancement for financial services applications that’s modernizing the industry. For instance, Mastercard recently began its Start Path Open Banking program, which provides select startups the opportunity to use Mastercard’s expertise while learning how to apply open banking to their own business. Open banking is creating new opportunities for revenue sharing and reducing data licensing and transaction fees between financial institutions and their partners. 

    Customers who take advantage of open banking also gain a more comprehensive, holistic view of their finances so they can be in a stronger position to manage their wealth. Just as importantly, open banking will provide more opportunities to use data for products and loyalty programs across the full spectrum of their organization’s offerings. Financial services companies like Mastercard also believe that open banking programs improve inclusiveness and financial literacy. With greater financial literacy, customers can work to lessen the chances of fraud in their accounts. 

    This follows an overall trend of breaking down barriers when it comes to connecting financial organizations with consumers through new, innovative financial technologies. In fact, 96% of consumers globally are aware of fintech services, including at least one money transfer and payment. Additionally, U.S. consumers are steadily adopting new fintech, including peer-to-peer payments. 

    While open banking has the potential to shake up the foundations of the banking industry, there is also the possibility of it becoming a target for threat actors and cybercriminals alike. The reason: application programming interfaces (APIs) that power open banking are being targeted.

    Hazards Associated With Open Banking 

    Open banking uses APIs to connect financial institutions with third-party applications. The Open Banking Project is one of the leaders in providing open source APIs for banking and relies on an open source system for financial services providers to access consumer banking and financial data.

    Yet, the more financial services organizations rely on APIs, the greater their attack surface becomes. APIs, as the building blocks of today’s modern web applications, are already a big target for threat actors and a primary attack vector. Banks, and the financial services industry as a whole, are also targets for cybercriminals. 

    IBM’s X-Force Threat Intelligence Index 2022 noted that finance and insurance organizations were the second-most targeted industries. Further, IBM also found that among those attacks, 70% were against banks and 14% were against other financial organizations. This tells us that while other organizations might make the data breach headlines,  banks and financial institutions are most often under attack by threat actors and cybercriminals. While one of the major drivers for this is financial gain, there is also a wealth of data in banking, including personal identifiable information (PII), payment card industry (PCI) data, account and payment information. Much of this can be leveraged on the dark web for financial gain. 

    Unfortunately, attacks on financial institutions and the APIs that drive much of our engagement won’t change anytime soon. The problem associated with APIs is that, if left unsecured, they can provide threat actors a foothold into sensitive data that can be  exploited. Additionally, many organizations don’t have a true understanding of how many APIs they have (many are interconnected) or how these vulnerable endpoints are being protected. It is incredibly difficult to protect something that you don’t even know exists! Adding an additional layer of complexity to the API conundrum is how third-party APIs are often relied upon. Using these sources, while potentially a time-saving strategy, can leave your networks open to attack. 

    Secure Open Banking Means Protected APIs

    If you’re a company that plans to start taking advantage of open banking, it’s important to mitigate some of these threats by establishing sound API protection strategies. First, gain visibility into your entire attack surface. After all, knowing yourself, including your APIs and web apps, along with understanding your enemy, will lead to success on the battlefield (to paraphrase Sun Tzu). Once you have a comprehensive view of your endpoints, including those older and deprovisioned APIs, you can be in a better position to protect against the multitude of threats that they face. Ideally, you will be able to get real-time analysis of traffic hitting your endpoints so you can get a more holistic view of a surface that is always changing. 

    It should also be emphasized that sophisticated attacks consist of bot armies generating API traffic and attacks. Malicious bots are being leveraged on an ever-growing basis in attacks, including DDoS attacks and account takeovers. While many bot attacks are automated, being able to detect and block them in real-time, when combined with continuous monitoring, can help to lessen the threat posed by bots.  

    A future with open banking is an exciting prospect due to the fact that it will put financial control back in the hands of businesses and consumers. While there should be a reasonable amount of caution placed in many of the API-centric open banking solutions, there are ways to alleviate these concerns. Strong API security, along with bot blocking and detection, can go a long way toward protecting against modern threats.

  • Fastly Adds Observability Tools for Edge Computing Environments

    Fastly Adds Observability Tools for Edge Computing Environments

    Fastly, Inc. this week added a set of observability tools to its portfolio that are optimized for edge computing platforms connected to its content delivery network (CDN).

    Laura Thomson, senior vice president of engineering at Fastly, said the company is now providing a set of tools that enable DevOps teams to capture logging data and metrics in real-time via a single console.

    The first two available tools are Origin Inspector—to observe network traffic flows including HTTPS response codes—and Domain Inspector—to access metrics based on both historical and real-time data. In total, Fastly is now providing access to more than 200 metrics spanning client, origin, cache, web application firewall (WAF), Compute@Edge, Image Optimization services and others that cover 100% of the data generated since the service was spun up.

    There is no sampling of data, and the company is also providing integrations with 33 storage and analysis services provided by either Fastly or a third party, noted Thomson. IT teams can now log any aspect of HTTP requests and responses through a large variety of logging formats, including the Common Log Format, JSON or as a key/value store. IT teams can also store their own logs to make sure they retain complete control over access.

    Over the next several months, Fastly will continue to expand this portfolio of observability tools, including an Edge Observer dashboard it is providing to customers that are deploying applications at the edge, added Thomson.

    In general, observability tools are being used to not only improve processes and overall customer experience but also identify and block suspicious activity. Fastly is making a case for observability tools that enable DevOps teams to achieve those goals without necessarily having to deploy a separate observability platform.

    Of course, most DevOps teams have been continuously tracking various pre-defined metrics for years. Observability tools, in contrast, are designed to make it feasible to interrogate logs, metrics and traces so that IT teams can discover issues before there is a disruption to services. The challenge, of course, is that not every IT team necessarily knows how to shape the queries required to discover the root cause of a potential issue.

    One way or another, DevOps teams will need to be able to remotely diagnose edge computing issues as the number of workloads deployed on these platforms expands. IT teams are not going to be able to travel to the physical location of every edge computing platform every time an issue arises. In many ways, the rise of edge computing will force a transition to observability tools that will enable IT teams to more proactively manage IT environments rather than respond after a metric has already exceeded its threshold.

    It’s not clear to what degree that approach will prevent IT issues from occurring, but the amount of time required to detect and remediate issues should dramatically decline as more visibility into IT environments, including edge computing platforms, is gained.

  • Rust Momentum Intensifies | Elon Says No WFH

    Rust Momentum Intensifies | Elon Says No WFH

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

    This week: People won’t shut up about Rustlang, and Musk mandates Twitter teams return to the office. (more…)

  • CloudBees Demos Orchestration Capabilities of ReleaseIQ Platform

    CloudBees Demos Orchestration Capabilities of ReleaseIQ Platform

    At the online DevOps World 2022 event today, CloudBees demonstrated for the first time the capabilities of the application release management platform it gained last month through the acquisition of ReleaseIQ.

    Shawn Ahmed, chief marketing officer and interim chief product officer at CloudBees, told conference attendees that the ReleaseIQ platform will provide application development teams with visibility into precisely how their code is making it into production environments.

    Armed with those insights, it then becomes possible to understand exactly how the way commits are made during a build process are, for example, creating a workflow bottleneck, he added.

    The ReleaseIQ platform is designed to enable DevOps teams to both create and maintain pipelines using a no-code tool. That enables greater transparency into workflows via dashboards that also provide optimization recommendations.

    CloudBees already provides a Flow orchestration engine within its continuous delivery platform. However, ReleaseIQ provides a similar capability across multiple continuous integration/continuous delivery (CI/CD) platforms using a SaaS platform that is more accessible. ReleaseIQ can also be integrated with multiple platforms including CloudBees CI, Jenkins, CircleCI, GitLab, Bamboo, ArgoCD and others.

    Naturally, the current level of DevOps maturity varies widely by organization. However, as more organizations realize how much they depend on software to drive digital business transformation processes, the need to further automate application development and delivery becomes more apparent. While CI is widely used today, the number of organizations that have consistently implemented CD to automate application release management is still fairly limited. The underlying infrastructure that software is deployed on typically has a unique set of application programming interfaces (APIs) that each CD platform needs to support. Platforms such as ReleaseIQ provide a higher level of abstraction that simplifies managing the pipelines that deliver software.

    CloudBees is essentially positioning ReleaseIQ as the orchestration engine for both unifying pipeline management and, ultimately, enabling value stream management across increasingly complex application development environments. It may take a while to fully realize that ambition, but with the acquisition of ReleaseIQ, the company is now pursuing a more cloud-centric approach toward enabling DevOps teams to, for example, more easily reuse pipelines.

    DevOps teams, of course, have created a lot of scripts over the years to provide orchestration capabilities. The issue is that those scripts tend to be brittle in the sense they don’t scale especially well over time. They also tend to be poorly documented and challenging to maintain if the script writer leaves the organization. It’s not uncommon for new members of a DevOps team to replace a script with one they wrote simply because they’re more familiar with how it’s constructed.

    More than a decade after the launch of the Jenkins CI/CD platform, there are still plenty of manual DevOps processes that should be more automated. A no-code orchestration platform may prove to be a significant step toward automating a wide range of tasks that consume more time than they should.

  • OpenSSL Fiasco: What can DevOps Learn? | Elon Fires ‘50%’ of Twitter

    OpenSSL Fiasco: What can DevOps Learn? | Elon Fires ‘50%’ of Twitter

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

    This week: The OpenSSL project has egg on its face, and half of Twitter’s staff are for the chop tomorrow. (more…)

  • Gitpod Looks to Drive Application Development Into the Cloud

    Gitpod Looks to Drive Application Development Into the Cloud

    Gitpod today revealed it will add an application programming interface (API) to make cloud development environments (CDEs) more extensible. Gitpod also said Johannes Landgraf assumed the role of single CEO for Gitpod, as the previous co-CEO, Sven Efftinge, becomes the company’s first technical fellow.

    Fresh from raising an additional $25 million in funding, Gitpod’s Landgraf said that API will make it easier to build plug-ins for CDEs. In time, Landgraf said, CDEs will become as accessible as any development environment running on a local desktop.

    Software engineers typically waste five hours a week maintaining application environments, noted Landgraf. Via an open source development platform, Gitpod automates the provisioning of secure workspaces in the cloud that provide the added benefit of making it easier for multiple developers to collaborate, he added.

    Capabilities added to the GitPod product roadmap include dramatically faster startup times, improved resiliency and a Gitpod Cloud offering for larger companies as well as a preview environment and workflows that foster collaboration. Gitpod also announced it passed a SOC2 Type II security audit.

    Today, the Gitpod platform is being used by more than 750,000 developers at organizations such as Shopify, Stripe and Slack, noted Landgraf.

    One of the longstanding issues that has always been problematic when building software is that code that runs on a local desktop doesn’t always work when deployed in a production environment. The Gitpod API will make it simpler to spin up various platforms and tools whenever a developer accesses a CDE. The goal is to make it possible to more closely replicate the production environments on which developers will ultimately deploy their applications, noted Landgraf.

    In addition, a CDE should reduce the amount of data that developers routinely move between laptops and cloud computing environments as they build more complex applications, he added.

    In the wake of the economic downturn, there is a lot more focus on developer productivity these days, especially as organizations look to accelerate their of digital business transformations. DevOps teams are also keen to find ways to centrally manage developer experience at a time when many of those developers continue to work from home, said Landgraf.

    It’s not clear to what degree CDE will replace integrated development environments (IDEs) running on a local machine, but all the major cloud service providers are encouraging developers to build applications in the cloud where their applications will run. The challenge is that many of those offerings tend to lock developers into a specific cloud platform, noted Landgraf. Most developers today are building applications that need to be deployed across multiple clouds, he added.

    One way or another, software development is increasingly shifting to the cloud. Most organizations will likely try to find a balance between the amount of code developed on a local machine that developers can just fire up when the mood strikes and the amount of code developed in the cloud. The most immediate challenge is to make sure the CDE experience is every bit as good as the existing local IDE.

  • Pulumi Adds Deployment Capability to IaC Platform

    Pulumi Adds Deployment Capability to IaC Platform

    At the Pulumi Cloud Engineering Days event, Pulumi announced today it has added a code deployment capability to its Pulumi Cloud platform for managing infrastructure-as-code (IaC).

    Pulumi CEO Joe Duffy said Pulumi Deployments will make it possible for DevOps teams to provision infrastructure and deploy applications via a single Git commit that can be invoked via an application programming interface (API) or graphical tool.

    A Git Push to Deploy capability allows DevOps teams to connect to any Git repository to drive deployments for a given project path, push to any given branch and set up GitOps workflows such as pull request reviews. Deployment actions include both updates and destroys in addition to providing drift detection and remediation capabilities.

    The Deployments and Automation API Pulumi developed also enables ephemeral code review environments, automatic cleanup and deployment orchestrations across multiple cloud platforms using a library of templates Pulumi provides. In effect, Pulumi is now providing a GitOps workflow out of the box, said Duffy.

    Pulumi has already integrated these capabilities with GitHub and plans to add support for GitLab, Atlassian Bitbucket and other DevOps platforms. The goal is to make it possible for DevOps teams to effectively manage ten times the amount of cloud infrastructure resources per engineer using GitOps workflows than is currently possible relying on IaC tools such as Terraform, said Duffy.

    As an alternative to Terraform, the Pulumi platform has been gaining traction because it makes it possible to more easily centralize the management and provisioning of infrastructure using a set of embedded guardrails. One of the major issues enterprise IT organizations are encountering these days is the number of misconfigurations created when developers use tools like Terraform to provision infrastructure on their own. Those misconfigurations often lead to, for example, ports being left open and cybercriminals exfiltrating data. In the wake of a series of high-profile breaches, more organizations are now reviewing the security of their software supply chains including how infrastructure is provisioned by embedding policy-as-code into DevOps workflows.

    At the same, organizations are also keenly interested in increasing the productivity of DevOps teams during an economic downturn that limits the number of IT professionals an organization can afford to hire, added Duffy.

    Pulumi claims there are now more than 5 million users of its platform spanning more than 1,000 organizations. Less clear is the degree to which organizations are embracing GitOps workflows to unify deployments on IaC and application code. As platforms make it easier to make that transition, the number of organizations using a more opinionated approach to DevOps should steadily increase.

    In the meantime, DevOps teams are going to be required to find ways to build and deploy safer applications faster. Much of the focus in recent years has been on accelerating application deployments with little regard for cybersecurity. Those days are clearly now coming to an end.