devopsy.kinsta.cloud

Tag: application development

  • VMware Streamlines IT Management via Cloud Foundation Update

    VMware Streamlines IT Management via Cloud Foundation Update

    VMware this week updated its Cloud Foundation platform and rolled up recent updates to the company’s virtualization portfolio all at once.

    Version 5.0 of VMware Cloud Foundation (VCF) encompasses the latest versions of VMware vSphere 8.0u1 for workload management, VMware vSAN 8.0u1 for scale-out storage, VMware NSX 4.1 for networking and VMware vRealize LifeCycle Manager 8.10 (Aria) for cloud management.

    In addition, VMware has added a single sign-on (SSO) capability, dubbed Isolated SSO Workload Domains, that enables administrators to configure new workload domains using SSO instances from different providers or platforms via NSX.

    Rick Walsworth, director of product marketing for the Cloud Infrastructure Business Group at VMware, said that as the management of IT continues to evolve in VMware environments, more organizations are opting to update their entire VMware software stack simultaneously rather than attempting to update components individually.

    The primary reason for that shift is that the company ensures that all the latest VCF component releases have been thoroughly stress-tested from an integration perspective, he noted.

    During uncertain economic times, VMware is seeing an increased focus on simplifying IT environments as IT teams are asked to do more with less, said Walsworth. As such, more organizations are looking to standardize on a stack of infrastructure software that can be managed more consistently, he added.

    More organizations are also looking to reduce the total cost of IT by employing the same stack of infrastructure software across hybrid cloud computing environments where workloads are deployed both in on-premises IT environments and public cloud, said Walsworth.

    The company is also seeing increased adoption of DevOps best practices to programmatically manage IT environments that need to respond to rapidly changing requirements, he noted. IT teams are looking to work more collaboratively rather than relying solely on specialists to manage specific functions, said Walsworth.

    Some of that shift is also being driven by Tanzu, a distribution of Kubernetes that the company makes available as part of VCF, he noted. Most application developers don’t have a preference for a specific Kubernetes distribution, so many organizations view Tanzu as an opportunity to extend their existing management framework to a de facto standard for building the next generation of cloud-native applications, said Walsworth.

    VMware is in the midst of being acquired by Broadcom. Nevertheless, VMware this week reported revenues for the first quarter 2023 of $3.28 billion, a 6% year-over-year increase. Subscription and software-as-a-service (SaaS) revenue for the first quarter was $1.22 billion, an increase of 35% year-over-year. That increase in revenue suggests any concerns about the future direction of the company are not impacting the willingness of IT organizations to continue to rely on VMware.

    It may be a while before all the dust settles around Broadcom’s acquisition of VMware. In the meantime, however, it’s clear that the way IT is managed in the cloud era is continuing to rapidly evolve regardless of who owns VMware.

  • 8 Hot Takes: Will We See a Monolithic Renaissance?

    8 Hot Takes: Will We See a Monolithic Renaissance?

    Is the DevOps world slowly backing away from microservices and to a monolithic renaissance? After years of proselytization about the benefits (Flexibility! Resilience! Support faster release speeds!) of microservices and serverless architecture, there are signs of a potential backlash against the singularly fragmented microservices architectural approach.

    The argument in favor of rolling back to monolithic architectures feels similar to the cloud repatriation debate. Just as with a lot of cloud-first transformations—often in lockstep with them, actually—many organizations moved headlong toward microservices without a case-by-case business or technical rationalization for the change. As the shiny newness of microservices has dulled under that approach’s daily exposure to real-world deployment and business challenges, the monolith isn’t looking so bad in a lot of situations.

    The monolithic versus microservices debate boiled over the last few weeks in the wake of the publication of a case study earlier this month from the Amazon Prime Video team. The analysis from Marcin Kolny, senior software development engineer for Prime Video, reported that his team was experiencing scaling bottlenecks in its audio/video quality inspection tooling, which was architected as a distributed system using serverless components. By rearchitecting the tool as a monolith, they were not only able to increase scaling capabilities but drastically reduced the infrastructure costs around that tool.

    “Moving our service to a monolith reduced our infrastructure cost by over 90%,” Kolny wrote.

    The announcement elicited a fair degree of hyperbole on the topic, but it also spurred a very organic airing of the pros and cons of monolithic, microservices and serverless architectures.

    The following are 10 different perspectives spurred on by this online debate from a range of CTO and engineering experts. Some of them are diametrically opposed to one another, many are overlapping in their opinions. But as a body, they point to the general (and very pragmatic) consensus that there simply will never be a one-size-fits-all approach to software architectures.

    Microservices a Siren Song for Complication

    “It’s clear that in practice, microservices pose perhaps the biggest siren song for needlessly complicating your system. And serverless only makes it worse. Replacing method calls and module separations with network invocations and service partitioning within a single, coherent team and application is madness in almost all cases.”

    —David Heinemeier Hansson, creator of Ruby on Rails and CTO at 37signals (maker of Basecamp and HEY)

    Architectures Aren’t Good or Bad

    “Application architectures are neither good nor bad, nor are they appropriate for every use case. Organizations need to step back and consider carefully what it is they’re trying to achieve and which architecture might best serve that need instead of choosing the most “modern” architecture because, well, it’s in vogue.”

    —Lori MacVittie, distinguished engineer in office of CTO at F5Networks

    Distributed Architectures Will Suit AI-Driven Future

    “In the ongoing debate between monolithic and serverless architectures, it is important to acknowledge that both approaches have their merits and considerations. Monolithic architectures have been prevalent in large human-centric organizations due to their management advantages and historical use cases. However, as the world continues its rapid progression towards a more AI-driven future, the landscape is shifting towards architectures that embrace fluidity, autonomy, and distribution.”

    — Reuven Cohen, veteran CTO and entrepreneur, mentor for TechStars

    Monolithic and Serverless Each Have Pros And Cons

    “Over the last 15 years, everyone has wanted to move to serverless microservices-based horizontally-scaled architecture – but it is not ideal for every application’s specific needs.  As with any choice in life and in business, there are always tradeoffs;  you must evaluate and choose the appropriate architecture based on your business and technology needs. Another important dimension to this is workforce skills for application architecture.

    —Hemang Davé, client technical leader and CTO at Kyndryl

    The Amazon Rearchitect Wasn’t Even Truly a Monolith

    “The problem is that they called this refactoring a microservice to monolith transition when it’s clearly a microservice refactoring step, and it is exactly what I recommend people do in my talks about serverless first. I don’t advocate “serverless only”, and I recommended that if you need sustained high traffic, low latency and higher efficiency, then you should re-implement your rapid prototype as a continuously running autoscaled container as part of a larger serverless event-driven architecture, which is what they did. If you built it as a microservice to start with, it would probably take longer (especially as you have to make lots of decisions about how to build and run it) and be less able to iterate as you figure out exactly what you are trying to build.”

    —Adrian Cockcroft, longtime DevOps advocate and veteran architect with stints at eBay, Netflix, Amazon, and Battery Ventures, among others

    One Tool as a Monolith, Maybe, But Not All of Amazon

    “Microservices, while duplicative and inefficient from a compute standpoint, allow you to release stuff really quickly, which is a tradeoff that most organizations at scale are willing to make.

    Microservices exist to reduce communication pathways—not to solve technical scaling challenges. At a certain point, teams stop functioning due to the communication overhead. A seven-person team has 21 communication pathways, whereas a 100-person team has 4,950. I work with large retailers selling billions of dollars a year online, and putting everything into a single monolith just doesn’t work. Could the entirety of Amazon.com be deployed as a single monolith? No way.”

    —Kelly Goetsch, chief strategy officer at commercetools

    Architectural Tension Always Exists Between Speed and Maintainability

    “Speed to market and speed to develop does not always equate to long-term scalability and maintainability. You must actively balance your investments across these two critical pillars to build a viable product. Active rebalancing and reconsideration of the stack and technology mix for your FinOps and BizOps context is both art and science.

    Cloud-native distributed systems paradigms are here to stay. The Prime Video folks have mistakenly labeled a properly factored, highly coupled data-intensive processing step a monolith—it’s at best a rocky outcropping in their distributed microservices forest. “

    —Ajish George, managing director of cyber data & analytics for State Street

    The Shiny Thing is Not Always the Best Thing

    “The news that AWS discovered that serverless and microservices aren’t for everything is surprising. Not because it didn’t work out for that use case; but because the wrong use cases have been so well-known for the serverless/microservices pattern and should have been obvious to Prime Video. It’s worth remembering: That shiny new thing isn’t necessarily a better way of trapping mice. Right tool for the right job.”

    —Doug Vanderweide, director of cloud architecture for Avanade

  • Improving DevX Gives Your Business a Boost

    Improving DevX Gives Your Business a Boost

    As organizations transform and grow, different methodologies and development tools can come together, creating an extra level of complexity for your mainframe application development teams. In a perfect world, developers would be able to focus on delivering solutions without worrying about all the infrastructure necessary to make that happen. Building a better developer experience, or DevX, can make that a reality.

    DevX is about meeting developers where they are, at every stage of their career, delivering compatibility with and connectivity to the tools and devices that they want to use so they can focus on what they do best: Coding and releasing high-quality mainframe applications faster and more frequently and fostering better productivity and more innovation.

    Automation is integral to removing friction for developers. A modern integrated development environment (IDE) with built-in automation allows developers to find and manage code more efficiently and with greater quality and move quickly and easily from coding to editing to debugging to testing.

    Modern tooling can simplify and accelerate how developers work by giving them a visual representation of their code layout in a single-pane-of-glass view. They can move quickly in a natural, easy way with more information at their fingertips while built-in automation offers assistance at the right moment without getting in the way.

    This can seem difficult when dealing with mainframe application development and longtime mainframe developers who are still working with tools from the 1980s haven’t directly benefitted from the intervening decades of improvements. What they might not realize is that the improvements made for other platforms are available to mainframe developers, too. By engaging them in your DevX modernization efforts, you can improve their experience—and that of their team members.

    Elements of a Productive Mainframe Developer Experience

    • A modern DevX adopts flexible agile processes that give developers predictable capabilities and enable smaller, iterative changes with faster feedback. It also syncs distributed and mainframe development teams to foster greater collaboration for additional process improvements.
    • A better DevX is platform-agnostic, creating a development environment where developers can focus on the functionality of the applications they’re building instead of the deployment mechanism, leveling the playing field for every generation of developer.
    • With an improved DevX, developers can achieve the full potential of DevOps. Implementing DevOps for source code management (SCM) functions allows developers to understand the scope of any changes needed before they start coding, which helps speed approvals through concurrent work streams.
    • The single biggest boost to productivity—and an integral component of DevX—is shift left automated testing that enables developers at all skill levels to test new code immediately and find and fix bugs earlier in the development cycle when they’re easier to fix—and before they reach the end user. Continuous testing also automatically prepares test data within the DevOps toolchain.
    • An improved DevX delivers operational insights, so developers aren’t just catching issues but also understanding and prioritizing them, working hand in hand with the operations team to make the overall system better. It also empowers newer developers to address and correct any issues that arise in legacy code without poring over hundreds of modules to find what they need to improve. DevX tools work together to give developers an opportunity to leverage operational data in a whole new way.

    Once you have the tools, your mainframe developers need to be supported by a culture and education that teaches them how to use them and understand the benefits they offer. If you implement new tooling that nobody will use, the transformation is for naught. It’s important to start with the user experience and find the right tools to address it rather than starting with a tool and forcing its use just because it’s new. Continuous improvement is an important part of this; otherwise, you could bring the mainframe developer experience from the 1980s up to today’s standards only to have it freeze in place. This is why metrics and analytics are so important.

    As you speed up delivery, you also want to make sure the quality improves. With an improved DevX, you’re consistently finding defects earlier in the life cycle, which results in safer, more efficient delivery of better-quality code. By tracking velocity with metrics such as user stories delivered in one sprint, you can gauge how those changes are making a difference. You can also demonstrate how automation helps eliminate human error, increases code drops, and improves business agility.

    If you’re giving your mainframe developers everything they need to do their jobs easily and more efficiently, they’re exponentially more likely to adopt the tool and advocate for it—because a better DevX improves the day-to-day employee experience for longstanding and next-generation developers. By removing the drudgery of tasks that take developers away from writing code, you’re unleashing their creative and enabling them to achieve even greater levels of innovation—and you’re also improving your hiring and retention practices.

    Improving the mainframe DevX pays dividends across your business, from your developers to your customers to your stakeholders, so you can bring more new features to market faster and enable a competitive response for revenue-generating solutions. The mainframe is here to stay. Make sure you’re building a modern development environment that empowers your developers to respond nimbly in the face of change and make change your advantage.

  • DevOps Security: Your Complete Checklist

    DevOps Security: Your Complete Checklist

    In a fast-paced environment like DevOps, your security strategy needs to be even more agile. While moving fast is great for delivering application features and functionality, speed shouldn’t come at the cost of security.

    DevOps security incorporates security strategies directly into your DevOps pipeline, creating a culture of pre-secured software deployments that work seamlessly for the end user. However, this requires a complete shift in your operational policies and security mindset. You need to start viewing security as an integral part of your DevOps lifecycle instead of a separate department.

    Here’s a checklist of DevOps security strategies for your development teams to deliver secure and reliable applications faster:

    Your Complete DevOps Security Checklist

    1. Analyze your development process for security hazards.
    The first step in implementing a DevOps security strategy is finding and fixing loopholes in your existing development process.

    For instance, continuous delivery and development are key in a DevOps environment. However, if each change doesn’t go through a code review, it has the potential to break your application.

    Deploying changes without passing them through a security checkpoint is like driving at high speed on a road with many curves. Each curve (change) is a potential hazard, and the danger increases when the driver does not know a car is coming from the other side (bug).

    Therefore, you must turn the spotlight on your development process and find those curves.

    2. Create a common goal between development and security teams.
    Traditional roles of developers and security teams might look like they are at crossroads — Developers write code, and security teams find fault with their code. However, in a collaborative environment such as DevOps, security and development must work hand-in-hand to deliver a secure and seamless experience to end users.

    Your organization should have a common goal of integrating security directly into the development process. Therefore, encourage open and regular communication between development and security teams. Further, establish joint milestones and review them to ensure there are no silos between both teams.

    Once these teams get used to this collaborative approach, your deployments will become faster because fewer things will break.

    3. Integrate security procedures in the development phase.
    Automation is the lifeblood of DevOps security. Integrating scanning tools into development workflows is critical to your entire process.

    For example, automated tools can scan the code, network and infrastructure to identify security vulnerabilities and provide recommendations for remediation. With this, development teams can fix a few security concerns themselves before passing them on to the security team for a final check.

    4. Add observability to your pipeline.
    One of the biggest challenges of the distributed nature of DevOps operations is visibility. How do you efficiently monitor a large number of operation nodes spread across several different locations?

    Observability helps you do this by using logs, metrics and traces—i.e., the outputs of your application to determine internal application health. With observability tools, you can see much deeper into the operations of your systems and identify the exact details of any security concerns. You can also easily identify potential bugs and fix them before they cause problems.

    5. Make changes in small, incremental units.
    It is infinitely easier to test code in small units and deploy them as minor but incremental changes than handling large, unwieldy blocks of monolithic code. Deploying gradual changes means you can resolve vulnerabilities faster.

    6. Scan and secure your entire DevOps pipeline.
    A large part of the security hazards in your DevOps process comes from unsecured containers and operations nodes. According to a study from ThreatStack, 94% of organizations say containers represent a security risk.

    However, the risk is not limited to containers.

    Other services like APIs, third-party tools like Docker and imported code pose a potential security risk to your processes. This makes it necessary to scan all your operations nodes periodically for vulnerabilities. And once you’ve cleared them, remember to lock the door behind you by requiring strict credentials for access to your administrative dashboards.

    Ticking Items Off Your DevOps Security Checklist

    If you implement most of the security guidelines on this checklist, your organization will have a solid security foundation. However, DevOps security is not a one-time process.

    You will need to continuously integrate security protocols into each part of your DevOps life cycle. Furthermore, you will need to re-train your employees and invest in new technology that makes your security pipeline smoother, such as observability.

    However, since this entire process makes your applications more secure and compliant while shipping them to market faster, investing in DevOps security is well worth it!

  • State of Developer Experience Report Finds Growing API Reliance

    State of Developer Experience Report Finds Growing API Reliance

    Web APIs continue to grow in interest among developer users. APIs can empower new customer experiences and help engineers avoid rebuilding common functions. The technology is also powering microservices and headless architectures that we’ve seen gain more traction in recent years as enterprises become more composable.

    On the provider side, a web API strategy can enable co-creation in partner ecosystems and even open new revenue opportunities for the business. Yet, like any software-as-a-service (SaaS), APIs require great developer experiences to create quick onboarding journeys and easy ongoing maintenance.

    Nylas recently released its inaugural State of Developer Experience Report, detailing the key trends, technologies and priorities that are molding the modern developer experience. The study found increasing reliance on APIs and hopes to increase investment in API-driven technologies. I also met with Isaac Nassimi, SVP of product, Nylas, to explore the reasons behind some of these findings and to get his perspective on the API economy at large.

    Rising Importance of APIs

    As I’ve covered before, the number of APIs in the market has ballooned as more development teams have come to rely upon APIs to power new application functions. The largest companies, those with 10,000 or more employees, have more than 250 internal APIs, according to Rapid’s 2022 State of APIs report.

    Similarly, the Nylas study underlined the growing reliance on APIs. A full 98% of developers said they view APIs as a key contributor to helping them and their team get their work done. And 86% of developers said they expected their use of APIs to increase in 2023.

    According to Nassimi, APIs are something that’s become more and more prevalent over time. For example, in 1998, setting up a web server was pretty cumbersome. But nowadays, a junior developer can accomplish the task (and much more) with a few lines of code, he said. APIs abstract complexity and help leverage external infrastructure so you aren’t constantly reinventing the wheel. “They add more functionality and help outsource labor, thought and cognitive load,” explained Nassimi.

    APIs Bring Developer Experience Benefits

    Another possible reason to shift toward APIs is to handle escalating tool usage. Almost half (48%) of developers said they are either always or often overwhelmed by the number of tools they use daily. Simultaneously, 98% of developers said APIs would lessen the number of workplace tools they use daily. The study indicates that investment in APIs can increase automation and reduce the manual headaches of crafting new features by hand.

    For example, Nassimi describes creating a video transcoding service from scratch in a previous company. The entire engineering team had to dedicate months and months to the process, using muscles they hadn’t ever exercised. After much effort, they ditched their work and ended up just using an API. “It was a really good feeling to delete 200 lines of code,” said Nassimi. “If you do that five times, you reduce all these esoteric things you have to learn how to do in your company by an order of magnitude.”

    In addition to reducing headaches, APIs can also enable speed. For example, it can take over a year for three senior engineers to build an email or calendar integration without the help of an API, the report found. With an API, this integration timeline can be minuscule, said Nassimi. As a result, 95% of all respondents said they would like to see their company invest more heavily in APIs within the next year.

    Developer Experience Improvements

    Developers find speed to be the number one benefit when working with APIs. And to grant this speed, API providers must create a streamlined developer experience (DX). The speed of implementation can make the difference between a good DX and one that is not so good, and a significant contributor to this speed is familiarity. One DX hangup is that the API you use must function like the code you use in your own environment, said Nassimi.

    Although solid documentation and naming conventions should exist in the background, Nassimi shared that forcing developers to learn terminology about the thing the technology is abstracting is a lousy developer experience. Instead, installing SDKs in the unique language of choice, like TypeScript bindings, and using autocompletes to understand the SDK can grant a much better experience.

    Workflow automation and AI can also enhance developer experience, as it frees up time for engineers to be more productive. In fact, two out of three developers would like their company to invest in AI for workflow automation and to curate better user and customer experiences. And 72% of developers said they or their organization are currently using AI for data analytics and making sense of their data.

    However, when it comes to generative AI like ChatGPT and Bard, developers are less enthused—only 14% of developers reported it as a useful area that their companies should invest in over the next year. Although the headlines proclaim that generative AI will disrupt most aspects of modern work, the technology is still new and can produce errors and introduce potential security repercussions.

    Looking Through the Micro Lens

    Developers integrating with APIs will have various backgrounds and priorities. And although speed is an important consideration, providers should also understand where their workloads lie and what particular features they should be driving, said Nassimi. “You want to show off all endpoints and features, but if you narrow down to show users what they need to get started, you will close more deals,” he said.

    For more details, you can download a copy of Nylas’ State of Developer Experience 2023 behind an email gate here.

  • New Relic Report Surfaces Spike in Amazon JDK Usage

    New Relic Report Surfaces Spike in Amazon JDK Usage

    An analysis of the Java applications observed by New Relic showed nearly one-third of organizations (31%) are using the Amazon Java development kit (JDK) compared to 28% using the Oracle JDK as more Java applications are built and deployed in the cloud.

    The report also found the number of Java applications running in containers is remaining steady year-over-year at 70%.

    Overall, the report published last week found more than 56% of applications are now using Java 11 in production, followed by Java 8 at nearly 33%. However, more than 9% of applications are now based on Java 17, representing a 430% growth rate.

    Jemiah Sius, director of developer relations for New Relic, said it’s clear that Java 17 is starting to gain traction in production environments. This is happening at a faster rate than previous releases of the venerable programming language as more cloud-native applications based on containers are being built and deployed, noted Sius.

    Regardless of the version of Java, it doesn’t appear developers are moving away from Java as they build cloud-native applications, noted Sius. Rather than requiring developers to learn a new programming language, it’s simply been more cost-effective to enable them to continue building applications using a programming language they already know.

    Java, meanwhile, has been experiencing a renaissance after more organizations began contributing to projects once the core platform became available under open source licenses. In fact, the Java community is now adopting many concepts pioneered in other programming languages to enable organizations to, for example, drive digital business transformation initiatives that are dependent on legacy applications being modernized. As a result, most organizations will continue to deploy Java applications everywhere from the network edge to the cloud.

    New Relic, of course, is betting that as more cloud-native applications are deployed, the need for an observability platform that addresses the needs of developers and IT operations teams alike will become more apparent.

    In general, most organizations are still in the early stages of achieving full-stack observability. A recent New Relic survey found only 27% of respondents have achieved full-stack observability and only 5% claimed they have a mature observability practice in place. A third (33%) of respondents also said they still primarily detect outages manually or based on complaints, the survey found.

    On the plus side, the survey also found nearly three-quarters of respondents said C-suite executives in their organization are advocates of observability and more than three-quarters of respondents (78%) saw observability as a key enabler for achieving core business goals. However, more than half (52%) of respondents said they experienced high-business-impact outages once per week or more and 29% said they take more than an hour to resolve those outages.

    The expectation is that that augmenting DevOps teams with observability tools and platforms that are increasingly being infused with artificial intelligence (AI) will reduce outages, even as cloud-native applications make IT environments even more complex than they already are. The issue is, however, those application environments are becoming more complex at a rate that is far exceeding the pace at which observability platforms are currently being adopted.

  • Sendbird Adds API to Invoke ChatGPT From Mobile Apps

    Sendbird Adds API to Invoke ChatGPT From Mobile Apps

    Sendbird today added an application programming interface (API) to its low-code platform for building mobile applications that enables developers to add bots that communicate with OpenAI’s ChatGPT.

    Shailesh Nalawadi, head of product for Sendbird, said this API makes it possible to add the ability to communicate directly with the generative artificial intelligence (AI) platform from within both new and existing applications in just a few minutes.

    Most developers will add natural language processing (NLP) interfaces to complement the graphical user interfaces that most mobile applications today surface, added Nalawadi. It will be up to each development team to determine how best to employ that capability, but Sendbird envisions, for example, a health care application being able to invoke ChatGPT to answer queries, he noted.

    In the longer term, Sendbird will provide APIs to enable mobile app developers to invoke a wide range of large language models (LLMs). LLMs are increasingly being developed for generative AI platforms and are being optimized for a range of use cases.

    While OpenAI’s generative AI model is being widely used thanks mainly to Microsoft, there are already LLMs that are being created for a narrower range of use cases using much less data. DevOps teams should expect APIs invoking any number of generative AI platforms from within applications to become commonplace in the weeks and months ahead as more end user come to expect to be able to engage these platforms from within almost every application Sendbird’s chatbot API can now be invoked by more 1,300 existing mobile applications alone.

    In general, developers have tended to employ chatbots sparingly because they are often too scripted and inflexible. ChatGPT, conversely, provides a much more open-ended user experience. Organizations can also feed historical conversations or customer relationship management (CRM) data to ChatGPT to drive more personalized and accurate responses, given the veracity of some of the data used to train ChatGPT.

    A recent survey of digital quality testing professionals conducted by Applause, a provider of a platform for accessing a networking of independent testers, found nearly one-third (30%) of respondents are dissatisfied with their current chatbot, IVR and conversational assistant experiences, with wrong answers (29%) and a lack of understanding (24%) as the top two reasons cited. The results indicate there is plenty of opportunity for improvement.

    Nearly three-quarters (74%) said they had a positive experience with the ChatGPT generative artificial intelligence (AI) platform, with more than two-thirds (67%) reporting the platform provided helpful answers to questions. In terms of work-related tasks, most said ChatGPT would either be “very” (43%) or “somewhat” (37%) helpful.

    It’s apparent now that generative AI platforms are about to change the way humans engage with machines. Instead of always creating an abstraction to interface with a machine it’s now feasible for interactions to occur between them using language humans readily understand. As such, the way applications are built and employed is about to fundamentally change in ways that are difficult to predict.

  • CodeSee Extends Reach of Code Visualization Platform

    CodeSee Extends Reach of Code Visualization Platform

    CodeSee updated its code visibility platform to enable instant mapping of application services, directories, file dependencies and code changes.

    CodeSee CEO Shanea Leven said CodeSee Enterprise 2.0 should extend the appeal of the platform beyond developers to include software engineers managing DevOps workflows.

    CodeSee Enterprise 2.0 provides real-time visibility across multiple repositories regardless of whether the application is a monolith or based on a microservices architecture, she noted.

    In addition, a Code Automations module enables developers to set granular conditions and actions down to the function level, requiring checklists to be complete before allowing developers to move on.

    CodeSee Maps now includes the ability to click to view code directly, while a streamlined Review Maps module has decreased code review time by 30%. Developers can easily share maps to discuss proposed changes or keep necessary code changes as automatic permanent artifacts.

    Additional languages including C#, VB.NET, ASP.NET, Blazor, Java, JavaScript, Go, Python and TypeScript are now supported.

    Finally, CodeSee is making available a dedicated solutions engineering team that provides guidance to connect an organization’s Datadog or OpenTelemetry trace data to CodeSee in less than an hour without storing code or having to first dive deep into traces, noted Leven.

    The core open source CodeSee tool was created because it takes too long today for most developers to pore over a codebase to understand where they might contribute. The larger a codebase becomes, the longer it takes for a developer or software engineer to be onboarded to a new project.

    The overall goal is to improve developer productivity, noted Leven. That’s become a critical issue because many organizations are hesitant to hire additional developers during uncertain economic times; they first want to ensure they maximize the utilization of the teams they already have.

    Application development, of course, is now a team sport. The days when a lone developer cared for an entire application are long over. The issue is finding a way for teams of developers to collaborate more easily in an era where many of them may never have met in person.

    In the longer term, Leven said she also expects that generative artificial intelligence (AI) platforms such as ChatGPT will supplement code visualization tools. Many developers are already starting to use these tools to help generate code faster. That code should, in theory, have fewer errors because it has essentially been copied from other previously validated sources. CodeSee provides a means to visualize that code before deploying it to ensure it will function as promised in increasingly complex application environments.

    One way or another, the tools being provided to developers to boost productivity are advancing. It’s not clear what metrics should be employed to track developer productivity, but the amount of code simultaneously moving through DevOps workflows is going to increase. The challenge DevOps teams face now is keeping track of all the dependencies that exist in that code as application environments are continuously updated.

  • Postman Releases Tool for Building Apps Using APIs

    Postman Releases Tool for Building Apps Using APIs

    Postman today made generally available a visual tool infused with artificial intelligence (AI) that makes it simpler to build software by invoking application programming interfaces (APIs) found on its network.

    Shamasis Bhattacharya, chief software architect for Postman API, said Postman Flows makes it possible to use a low-code tool to build software using tens of thousands of APIs that can be found on the Postman API network.

    The goal is to reduce the amount of toil required to build applications of moderate to medium complexity in a way that doesn’t require developers to have deep programming expertise, he added.

    Instead, developers are presented with “blocks” that they can drag and drop to create an application and deploy the associated workflows. Postman Flows leverages AI to manipulate data returned by APIs using a natural language interface that reduces the level of technical acumen required to create those workflows.

    That approach provides developers with a reactive experience that is embedded within a visual tool, noted Bhattacharya.

    Many developers still have a natural bias toward writing code, but as demand for applications continues to increase, Postman Flows provides a means to significantly increase developer productivity, said Bhattacharya. There may still be instances where writing code is required, but as developers save more time using Postman Flows, many of them will switch over to a visual tool to build software faster by essentially gluing blocks together, he added.

    There’s naturally a lot of focus these days on developer productivity during uncertain economic times. More organizations than ever are dependent on software, but their ability to hire armies of developers is limited. Low-code tools have emerged to provide a means for accelerating application development, but Postman is now looking to apply that concept directly to the network of curated APIs that it provides to application developers.

    The one thing that is certain is that as the pace at which applications are being built increases, the number of them running in production environments will steadily increase. DevOps teams will find themselves maintaining a wide range of applications that were constructed using both procedural code and low-code platforms.

    In the meantime, IT organizations may want to start evaluating which types of applications lend themselves to being built by development teams that may not require as much experience writing actual code. Much of the application development backlog organizations are struggling with today could be reduced using tools that automate a wide range of development tasks. That should free up developers with more advanced skills to work on more complex applications. That approach might also reduce developer turnover as much of the fatigue associated with building more routine applications is reduced.

    Regardless of how applications are built, there will be a need to manage them in production environments. DevOps teams may soon be able to focus more of their time and expertise on optimizing application performance in production environments versus continuing to shepherd massive amounts of code through continuous integration/continuous delivery (CI/CD) pipelines.

  • Oracle Makes Java 20 Platform Generally Available

    Oracle Makes Java 20 Platform Generally Available

    At an Oracle DevLive Level Up event, Oracle today announced the availability of a Java 20 update that makes a range of innovations more accessible to application development teams.

    Georges Saab, senior vice president of development for the Java Platform and chair of the OpenJDK Governing Board for Oracle, said the latest version of the venerable programming language builds on previous extensions made to the Java development kit (JDK) that exemplify how the pace of Java innovation is now increasing.

    Specifically, seven JDK Enhancement Proposals (JEPs) are now supported in Java 20, including OpenJDK project Amber for record patterns and pattern matching for switch expressions and statements; enhancements from OpenJDK Project Panama to interconnect Java Virtual Machines (JVMs), features related to Project Loom that streamline the process of writing, maintaining and observing high-throughput, concurrent applications and a Function & Memory application programming interface (API) and Vector API.

    Oracle also revealed Java 20 is supported by Java Management Service, an Oracle Cloud Infrastructure (OCI) native service that provides a single pane of glass to help organizations manage Java runtimes and applications on-premises or on any cloud.

    Finally, Oracle is making available an Oracle Java Universal SE Subscription that provides access to a pay-as-you-go offering that includes entitlement to GraalVM Enterprise, the Java SE Subscription Enterprise Performance Pack, access to the advanced features of the Java Management Service and the flexibility to upgrade at any pace an organization prefers.

    Oracle Java Standard Edition (SE), GraalVM Enterprise and the Java SE Subscription Enterprise Performance Pack are also now available free of charge on OCI.

    Despite the number of programming language alternatives that exist, many enterprise IT organizations remain committed to Java. Rather than opting to retrain developers, it’s simply been more cost-effective to enable developers to continue to build applications using a programming language they already know.

    Java itself, meanwhile, has been experiencing a renaissance after more organizations began contributing to projects once the core platform became available under an open source OpenJDK license. In fact, the Java community is now adopting many concepts pioneered in other programming languages to enable organizations to, for example, drive digital business transformation initiatives that are dependent on legacy applications that are being modernized. As part of those efforts, the rate at which Java applications are being deployed in the cloud has substantially increased.

    As part of those efforts, many organizations are currently in the process of shifting to Java 17. It’s not clear how many organizations will skip Java 17 and jump to Java 20 from previous versions of Java, but DevOps teams should expect to be supporting a wide range of versions of Java for years to come.

    In fact, most organizations will deploy Java applications everywhere from the network edge to the cloud. The one thing all these applications will have in common is they will be written in a programming language that has persevered through two decades and appears to have enough staying power to stick around well into the next.