devopsy.kinsta.cloud

Category: Features

Modular Makes a Case for Mojo Programming Language, Based on Python

Modular has made the core modules of the standard library for a Mojo programming language based on Python available under an Apache 2 license.

Mojo is emerging as a programming language that provides application developers with an alternative that adds additional capabilities to build higher-performing applications.

Applications written in Mojo will run faster than applications built using the C programming language, Modular CEO Chris Lattner said, making Mojo a better option for building, for example, artificial intelligence (AI) applications.

The overall goal is to build a developer ecosystem around Mojo by opening up revision history for the standard library, releasing nightly builds of the Mojo compiler, providing public continuous integration (CI) tools and allowing external contributions through GitHub pull requests, Lattner added.

Python is popular because it is easy to learn. However, applications written in Python don’t run nearly as fast as applications written in C or Java. Modular created Mojo to provide Python developers with a programming language that used the same familiar syntax to build high-performance applications.

That approach provides the added benefit of providing an alternative to building AI applications using the open source Compute Unified Device Architecture (CUDA) model being advanced by NVIDIA that is optimized for a narrow range of processors, said Lattner. The development of AI applications should be based on a programming language that is being advanced by a broad ecosystem of developers in much the same way other programming languages are maintained, he added.

Lattner, who previously spearheaded the development of the Swift programming language for iOS platforms, said that as processors other than graphical processor units and existing general-purpose CPUs are developed to specifically run AI workloads, a programming language that is not overly tied to a specific hardware platform will prove to be crucial.

It’s not clear when processors optimized for AI workloads will become widely available, but a concerted effort is underway to reduce the current level of dominance NVIDIA has over AI. GPUs are widely used to train AI models because they provide more advanced parallel processing capabilities. However, they were originally developed for graphics workloads. Providers of processors optimized for AI are making a case for an approach designed specifically for AI workloads that are more efficient.

Of course, regardless of processors, the concern is NVIDIA would still maintain its dominance if AI applications continued to be predominantly built using the CUDA framework, said Lattner.

It’s still early days, so far as development of AI applications is concerned, but many data science teams have already shown a clear preference for Python. In addition, developers need to build high-performance Python applications for use cases beyond AI, noted Lattner.

As more AI models are built, the next major challenge will be integrating them into DevOps workflows alongside all the other software artifacts that organizations are building and deploying. The one thing that is certain, however, is that DevOps teams are going to be asked to deploy and maintain even more diverse types of software artifacts.

Image source: Shahadat Rahman on Unsplash

April 5, 2024
Modern Application Management Requires Deeper Internet Visibility

Most IT teams regularly employ a range of tools to monitor application performance. But in an era where applications are running everywhere from the cloud to the network edge, the visibility being provided is limited. The metrics and analysis being surfaced are roughly akin to only being able to see a few yards ahead when driving a vehicle on a rainy night. Managing modern applications instead requires platforms that provide the equivalent of radar and sonar capabilities, so that IT teams have better visibility into application environments that today remain far too shrouded to effectively manage.

Achieving that goal requires a deeper insight into how various Internet services impact application performance. Just about every application depends on the quality of one or more of those services. The more application services that depend on the Internet, the more probable it becomes that someone will encounter issues intermittently impacting performance in ways that are difficult to understand, much less predict.

Unfortunately, most IT teams today have limited ability to discern how the performance of Internet services is impacting their applications. There are, of course, Internet performance monitoring (IPM) tools capable of surfacing network performance metrics. The challenge and opportunity now is to surface those metrics in context with all the other telemetry data that DevOps teams collect from the various application performance management (APM) and observability platforms they rely on to monitor and troubleshoot application environments.

Why Applications Are Becoming More Distributed

First, with the rise of cloud computing followed by the proliferation of software-as-a-service (SaaS) applications and now the rise of edge computing, applications are becoming more distributed with each passing day. The challenge is that each application is invoked across a network that adds latency, and existing APM and observability platforms cannot effectively analyze it.

The pace at which applications are becoming more distributed is only going to increase. More data is being processed and analyzed at the network edge as organizations deploy near real-time applications. Instead of transferring raw data to the cloud, these applications process and analyze data at the point where it is created and consumed. It’s only then that an application either streams or passes the aggregated results to a cloud service or to an on-premises IT environment for further analysis.

Most DevOps teams, however, lack visibility into how Internet services impact more highly distributed applications, beyond the cloud service or on-premises IT environment where they historically deployed their applications.

Internet Blind Spots

Broadly, there are three major classes of blind spots that impact distributed application performance. The first and arguably most opaque are the services provided by third-party vendors. Ranging from content delivery networks (CDNs) to software-as-a-service (SaaS) application, each of these services is controlled by an external service provider that typically doesn’t allows a DevOps team to collect telemetry data by deploying agent software in their IT environments. At best, they may expose an application programming interface (API) to enable an agentless approach to collecting data, but that method doesn’t typically provide the level of control required to optimize application performance.

The second major blind spot is at the device level. Configuration errors in browsers can have a significant impact on loading times that adversely impacts application performance, for example.

Finally, various platforms and protocols ranging Domain Name Servers (DNS) to publish-and-subscribe services can impact applications in way that an APM or observability platform isn’t going to detect.

The only way to provide the level of visibility required is to leverage an IPM platform that collect telemetry data from a global network, made up of thousands of points-of-presence (PoPs) to determine precisely what level of Internet service is delivered to any given end point.

Context and Control

Integrating the telemetry data collected via an IPM provided DevOps teams with a context to better troubleshoot distributed applications. Instead of wondering if a certain piece of code is to blame, a DevOps team can immediately determine whether Internet traffic moving through a specific location is either creating additional latency or blocking access altogether.

Armed with those insights, the team can contact then Internet services provider to address the issue or, if necessary, reroute via another service to ensure application availability.

Regardless of approach, the days when DevOps teams found themselves subject to the vagaries of network services, over which they had little to no influence, are coming to an end.

DevOps Meets Netops

The integration of IPM and APM or observability platforms creates a foundation upon which best practices for managing network operations (NetOps) and DevOps can finally be melded. Instead of having to convene “war rooms” to uncover the root cause of an issue, both teams will instantly be able to visualize to what degree networking services might be adversely impacting networking services. All that time spent guessing what the cause of a problem might be can now be allocated to remediating the issue.

In an era where applications have never been more dependent on networking services, the need to converge the management of NetOps and DevOps workflows has never been more critical.

Conclusion

Most DevOps teams know all too well there are often major discrepancies between what DevOps teams relying on APM and observability platforms believe and what is actually occurring in a distributed computing environment. The challenge is that they typically lacked the visibility required to determine what best course of action to address the issue. As IPMs become more integrated with APM and observability platforms, network blind spots that previously made discovering the root cause of an issue will soon be all but eliminated.

Of course, each DevOps team needs to determine to what degree gaining those insights is a priority. However, given the number of issues DevOps teams are trying to resolve that can be traced back to an Internet service, it’s clear the overall level of stress and toil DevOps teams regularly encounter could be greatly reduced by simply providing more networking visibility into those services.

April 5, 2024
Why GraphQL is a Better Choice for Building Microservices
There’s been a long debate about whether it’s better to use REST or GraphQL for building microservices. Both technologies have their proponents and critics, but when it comes to the specific needs of microservices architectures, GraphQL emerges as the clear front-runner. Here’s why.

Understanding the RESTful Concerns

While REST has been the go-to API style for many years, lauded for its simplicity and general applicability, its limitations become glaringly apparent in the context of microservices. These limitations include:
- Over-fetching of data
- Multiple HTTP requests for related data
- Complex versioning strategies
Such issues can impede microservices architectures’ performance and scalability.

Over-fetching of data: REST APIs are designed to return a fixed set of data, which often results in over-fetching. This redundancy is particularly problematic in mobile networks, where every extra byte of data can lead to slower applications and degraded user experiences.

For example, imagine we have a REST API endpoint /api/user/{userId}, which returns the following data for a user:

In scenarios where mobile apps only require specific user details like name and email for a profile overview, fetching comprehensive user data means over-fetching.

This excess data usage can be costly for users with limited data plans and result in slower app performance and degradation of user experience.

Latency and the N+1 problem: Microservices often require data spread across multiple services.

Suppose you have an ecommerce application where the order domain handles product, customer, order and return entities, and the stock domain manages product, stock, warehouse and delivery entities. A common operation might be to display order details along with the current stock status for each product.

Let’s say we have an order microservice and a stock microservice to handle orders and stocks.

In our scenario, a customer places three orders (N=3) and each order contains four different products. To display the order details with the stock status for each product, the application initially makes one request to fetch the orders. Then, for each product in each order, it makes additional requests to the stock microservice to retrieve stock information. This results in one initial request, plus 12 subsequent requests (three orders times four products per order), summing up to 13 API calls. This multiplicative increase in requests leads to higher latency due to multiple round-trip times (RTT) and increased load on the network and servers, embodying the N+1 problem.

Versioning challenges: Maintaining REST APIs over time involves complex versioning strategies, such as introducing new endpoints or embedding version numbers in the API path. This can lead to bloat and confusion, complicating API development and consumption.

The GraphQL Advantage

GraphQL addresses many REST weaknesses.

Domain-Driven Design: Microservices thrive on a domain-driven design, where each service is built around a specific business capability. GraphQL’s schema-centric approach aligns perfectly with this, enabling a more organized and coherent structure for microservices.

Unified schema: In a microservices architecture, each service may have its schema, representing a portion of the business domain. GraphQL stands out by allowing these schemas to be combined or stitched together, presenting a unified interface to clients. This means that clients can query data from multiple services in a single request, drastically reducing the complexity and number of network calls.

Solving the N+1 problem: GraphQL’s ability to fetch data with a single request, regardless of how many underlying services need to be called, directly addresses the N+1 problem inherent in REST architectures. This not only improves performance but also simplifies client-side data fetching logic.

For the N + 1 problem described earlier, if the services support GraphQL, it can be used to fetch nested data in a single query, effectively solving the N+1 problem.

Efficiency and performance: By allowing clients to specify exactly what data they need, GraphQL eliminates over-fetching and under-fetching issues common in REST APIs. This leads to more efficient data retrieval, reduced bandwidth usage, and faster applications, particularly noticeable in mobile environments.

In the earlier scenario where mobile apps only require specific user details like name and email for a profile overview, clients can request name and email alone.

Simplified versioning: Unlike REST, GraphQL reduces the need for versioning by allowing new fields and types to be added to the schema without impacting existing queries. This forward compatibility means that clients and servers can evolve more smoothly over time. GraphQL stands today as a mature technology that addresses specific needs in modern web development that are not fully met by traditional REST APIs. Its design promotes efficiency, flexibility, and developer productivity.

Looking ahead, the future of GraphQL is bright, with community-driven efforts focused on addressing its current limitations, particularly around security, performance and standardization. As these efforts bear fruit, GraphQL’s adoption is expected to widen, consolidating its position as a key technology in the API landscape.
April 4, 2024
Bringing DevOps Automation to Legacy Systems

A critical step toward adopting automation for legacy applications is to change your organization’s mindset about legacy systems.

Applying automation to operations isn’t always straightforward, especially with older systems that don’t easily fit into typical DevOps automation tools and strategies. However, legacy systems don’t have to sit on the sidelines of your DevOps automation strategy. Using the right tools and methodologies, it’s possible to integrate legacy system requirements with modern automation techniques.

Most organizations that adopt DevOps for conventional applications use automation tools and techniques, including Infrastructure-as-Code (IaC) and Configuration-as-Code (CaC), automated testing, release automation and application orchestration. If you’ve been paying attention to DevOps for any length of time, you probably are familiar with the concepts.

However, those DevOps automation solutions aren’t always straightforward to implement with legacy systems made up of hardware or software deployed long before modern, DevOps-friendly application architectures and deployment strategies existed.

For example, IaC tools may not support the configuration languages or management tools that the systems require. Most current systems are configured using languages like YAML, but legacy systems may depend on proprietary configuration languages and frameworks.

For similar reasons, test automation can be cumbersome. Today’s automation frameworks are designed for browser-based or mobile apps. Legacy systems may run locally and often use proprietary user interfaces, making automating testing using standard frameworks more difficult.

Likewise, many release automation and application orchestration platforms are designed for applications deployed using containers. Because containers didn’t become popular until the release of Docker in 2013, most legacy systems have limited native support for application containerization.

Bringing Automation to Legacy Systems

Fortunately, these obstacles are possible to overcome. Addressing these challenges requires adopting innovative practices that enable the integration of automation with legacy systems:
• Migrate to the cloud: Legacy system vendors now offer cloud-based hosting platforms. While transferring legacy workloads from on-premises to the Cloud doesn’t automatically enable all DevOps automation features, it does significantly facilitate the use of automatically scalable infrastructure. Organizations can move workloads between cloud data centers to mitigate failures in a single location.
• Containerize legacy workloads: In certain situations, it’s possible to get a legacy application to run in a container. That allows businesses to manage the older software using orchestration solutions like Kubernetes, bringing much greater agility and scalability to legacy application management.
• Use machine learning: Incorporating machine learning into monitoring and management operations for legacy systems helps to detect issues effectively in contexts where conventional automation is not feasible. For example, if you can’t run automated tests for a legacy application because Selenium won’t support it, advanced ML techniques might help you identify bugs based on how the application behaves.
• Change your mindset: Instead of classifying legacy systems as outdated and inefficient environments, treat them with equal respect to all the other applications within your IT estate. When your team approaches legacy systems from a perspective that values them, it becomes much easier to refine a corporate culture toward collaboration and innovation that extends to those legacy systems as well.

To Optimize DevOps Automation, Don’t Ignore Legacy Environments

There’s no denying that automating the management of legacy apps for DevOps teams is often more challenging than implementing automation for modern apps. However, this doesn’t mean that it’s impossible. Many organizations successfully adopt automation as a strategy for improving the flexibility and quality of legacy apps, while also reducing the costs of building and deploying them. But to achieve this, it’s necessary to think beyond the conventional approaches of DevOps.

April 3, 2024
Hasura Adds “Supergraph” to Platform for Managing APIs

Hasura, whose product helps compose GraphQL APIs backed by databases and services, today made available in beta an update to its platform. The company is adding a graph modeling framework that makes it simpler to manage application programming interfaces (APIs) at scale.

The goal is to make it easier for IT teams to declaratively create APIs and then manage them at scale, said Hasura CEO Tanmai Gopal. As application environments made up of multiple backend services and databases become the enterprise norm, there is a pressing need to simplify the management of what has become thousands of APIs in an enterprise IT environment using query compilers and routing capabilities built into the platform, he added.

In version 3.0 of the Hasura Data Delivery Network (DDN), the “supergraph” execution engine is based on a serverless runtime engine that, the company says, will replace its previous graph technologies to manage both GraphQL and REST APIs.

In addition, all connectors provided by Hasura have been rebuilt using an open specification and are now available as open source software on the Hasura Connector Hub. Hasura is also making available a software development kit (SDK) to enable IT teams to build custom connectors.

Written in the Rust programming language, the supergraph framework eliminates the need to create and manage GraphQL servers or services to deploy a graph. Additional data domains as a result can be added or replaced without breaking the graph used to manage other APIs.

The update to the Hasura DDN also adds new build system to provide instant API previews and support for rollbacks, a redesigned console featuring a graphical supergraph viewer, API analytics, observability, and auto-generated API documentation capabilities. Every iteration of the Hasura supergraph is instantly available as an immutable build that can be tested in preview. Every change to the supergraph is also validated before build, letting users identify potential bugs, stylistic issues, syntax, and type errors.

In addition, Hasusa has added a sub-millisecond cold start capability to enable rapid autoscaling and plane to shortly add caching to improve API performance in edge computing environments.

Longer term, the company plans to add additional a range of artificial intelligence (AI) capabilities to enable IT teams to identify issues requiring troubleshooting earlier and generate reports, Gopal added.

While REST APIs are still more commonly used than GraphQL, more IT teams are employing the latter. That’s because GraphQL provides more control over how data is accessed and consumed. Most organizations will soon be using a mix of REST and GrapgQL APIs, but it might be years before REST is supplanted as the dominant format simply because those APIs are more familiar to developers and easier to create.

Regardless of the type of API used, however, their numbers continue to steadily increase with each microservice added to an IT environment. It’s not always clear which teams within an IT organization are managing those APIs but increasingly best DevOps practices are being used to deploy, manage, secure and update them alongside every other type of software artifact. The challenge, of course, is making it simple to manage those API workflows in a way that doesn’t require yet another specialist to be added to the DevOps team.

April 2, 2024
Tabnine Extends Gen AI Platform for Writing Code to Multiple LLMs

Tabnine today revealed that it is giving DevOps teams the ability to switch between multiple large language models (LLMs) when they use its generative artificial intelligence (AI) platform to write code.

Application development teams can continue to use the LLM that Tabnine originally developed for its Tabnine Chat tool for generating code using a natural language interface. Alternatively, they can invoke either an instance of open source Mistral LLM jointly developed with Mistral AI or version 3.5 or 4.0 of the ChatGPT LLM (created by Open AI).

Tabnine president and chief marketing officer Peter Guagenti said the company will continue to add support for other LLMs, given the pace at which multiple LLMs advancements continues to accelerate.

As part of that effort, Tabnine will surface insights into LLM behaviors and their performance, privacy and protection behaviors, so development teams can identify which LLM is best for a specific use case, Guagenti added

Tabnine created an AI agent optimized for software development that optimizes prompts, provides contextual awareness of local and global code bases, and fine tunes LLM output.

There is, of course, no shortage of platforms for generating code, but the LLMs that Tabnine created are trained using a narrower base of code to reduce errors and hallucinations. However, development teams sometimes prefer to use LLMs that can support more parameters. Of course, the more parameters an LLM has, the more expensive it becomes, as the IT infrastructure resource requirement increases.

Regardless of the LLM type, the secret sauce is how they are invoked rather than in the LLMs that are rapidly becoming commodity services, noted Guagenti. Last month, for example, Tabnine made it possible for application development teams to better personalize output by exposing an LLM to both Tabnine’s code base and development environments.

It’s now only a matter of time before generative AI is applied across the entire software development life cycle (SDLC). In the short term, though, the pace at which code is being written should accelerate. The quality of that code will vary depending on the ways those LLMs were trained. A general-purpose LLM such as ChatGPT typically was trained using code examples of varying quality collected from across the Web. As such, that LLM is more likely to convincingly present code that doesn’t actually work, might run inefficiently, or contain vulnerabilities that could be exploited by cybercriminals.

The expectation is the output from LLMs that were been trained using vetted code will provide more reliable results. The challenge and the opportunity then becomes determining how best to apply AI to DevOps workflows before those teams are overwhelmed by the volume of code being generated by machines.

It may still be a while before AI is pervasively applied across the entire SDLC but the genie is out of the proverbial bottle. Eventually the overall code quality that makes it into production environments will improve steadily. In the meantime, DevOps teams should put guardrails in place to make sure the code AI is generating in the short term actually meets their requirements.

April 2, 2024
Five Great DevOps Job Opportunities

DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals are highlighted. Our goal in these challenging economic times is to make it just that much easier for DevOps professionals to advance their careers.

Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

The five job postings shared this week are selected based on the hiring company, the vertical industry segment and naturally, the pay scale being offered.

We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

Indeed.com

SAP
Bellevue, WA
DevOps Engineer
$182,312

CareerBuilder.com

HRL Laboratories
Malibu, CA
Senior DevOps Engineer
$145,745 to $186,688

LinkedIn

Visa
Atlanta
DevOps Data Engineer
$142,000 to $179,900

SimplyHired.com

Amazon Web Services (AWS)
Seattle
Senior Software Development Engineer
$134,500

Dice.com

Travelers
Hartford, CT
DevOps/Machine Learning Operations (MLOps) Engineer
$94,900 to $156,600

April 1, 2024
Survey Sees AI Playing Larger Role in Test Automation

A survey of 1,028 senior IT professionals and application developers in the United Kingdom, U.S., Germany and Singapore finds nearly half (47%) still use manual testing for mobile applications. More than a third (38%) noted that their organization could save between half and three-quarters (51-75%) of funding allocated to testing per year by fully automating mobile application testing.

Conducted by the market research firm Censuswide on behalf of Tricentis, a provider of a test automation platform, the survey also found that just under half of respondents (49%) reported their organization is already applying artificial intelligence (AI) to application testing. Another 21% plan to apply AI in the next six months. Almost three-quarters (74%) said their organization’s general sentiment toward AI in mobile software development testing is positive.

Respondents also expected AI to improve mobile application quality (37%), increase productivity (36%) enhance end-user experience (34%) and to reduce the number of vulnerabilities and/or bugs (32%) in their applications.

Mav Turner, chief product and strategy officer at Tricentis, said that rather than continuing to rely on expensive testing services, more organizations are looking to reduce costs by automating a wider range of testing workflows within the context of a DevOps workflow. In fact, the survey finds just under a third of respondents (32%) expect their organizations will invest more than $1 million to further automate testing.

As modernization of testing processes continues, the return on investment in mobile application development will only continue to improve, noted Turner.

The survey identifies the primary benefits of investing in test automation, which are increased productivity (32%), increased revenue (31%), increased user retention (28%) and increased compatibility across devices (28%).

The primary obstacles organizations encounter as they strive to achieve that goal are competing priorities (28%), lack of technology and talent (25%), time (25%) and cost (24%), the survey finds.

A full 87% said the quality of mobile applications is critical to their business, with 90% noting that poor mobile application quality costs their business as much as $2.49 million in lost revenue per year. However, just over a quarter (27%) said they believe their organization’s current mobile application development and testing strategy exceeds expectations.

As part of efforts to automate testing, it’s not clear just how far responsibility for testing is shifting left toward developers, but there is no doubt many more are being exposed to the results earlier in the software development life cycle. The goal is to provide continuous testing capabilities without overly disrupting code writing. It’s also becoming simpler for developers to leverage generative AI tools to provide summaries of tests along with recommendations to improve code. The end result should be higher-quality applications that require less troubleshooting once deployed in a production environment.

In the meantime, as organizations continue to become more dependent on mobile applications to drive a wide range of digital transformation initiatives, the cost of testing will continue to pale in comparison to the potential amount of lost revenue that might occur when end users either don’t invoke a specific feature or capability or, more commonly, simply abandon the application altogether.

March 29, 2024
To Devin or Not to Devin?
Devin.ai is an impressive generative AI solution that claims to be a new kind of AI engineer designed to perform software engineering tasks autonomously. Cognition Labs, Devin’s creator, said Devin is capable of responding to text commands and can be assigned tasks such as assessing the benchmark performance of an application. It will then build a plan and configure the required tools using its own command line interface (CLI), code editor and browser through which it can access, read and, for example, comprehend documentation using a reasoning engine and long-term planning capability based on advances in reinforcement learning.

Those capabilities make it possible for Devin to, for example, build a website, autonomously identify and fix bugs in codebases, deploy applications and even train other AI models. But there are a number of questions yet to be answered before Devin is ready for wider adoption.

For instance, whether or not every question from an organization will be used to train Devin.ai remains to be determined. Many experts believe that some large language model implementations, with almost 2 trillion parameters, cannot be comprehended even by their creators. There are 86 billion neurons in the human brain. Now, there’s not a one-to-one comparison to the human brain, but the point is they are both complex systems. GPT-4’s neural network contains 1.7 trillion parameters. The main point is that, regardless of what anyone says about their LLM implementation, it’s reasonable to assume they don’t know how it works internally. OpenAI states in their license agreement that they do not train on client data, but it is noteworthy that they didn’t have this policy early on.

Thoughts on Devin.ai

One of Devin’s most intriguing aspects is its autonomous operation through its shell code editor and web browser. Devin AI claims to set a new benchmark in software coding, boasting the ability to pass practical engineering interviews and complete real jobs on platforms like Upwork. However, as a software engineer with 45 years of experience, I take these claims with a hefty chaser of skepticism. Devin.ai may introduce many security concerns, especially when dealing with sensitive information or performing actions on services, databases and APIs, as well as the handling of sensitive information and the potential for unintended actions. This emphasizes the importance of developing robust security measures to mitigate these risks introduced by tools like Devin.ai. While I’m not against AI, I am cautious about Devin’s potential to replace human full-stack software engineers.

Back in the Day

One of the biggest obstacles in selling hosted Chef to regulated companies in the early days was the concern that ten young kids out of Seattle would have access to systems that create billions of dollars worth of infrastructure. Are these same institutions going to trust ten kids out of Silicon Valley with Devin, which may present similar risks?

Let’s set aside the infrastructure issues for a moment. What are your opinions on the robotic process automation (RPA) revolution that has taken place in the last decade? For one, consider that it has caused a technical debt nightmare. RPAs create many one-off technical problems that can be difficult to solve. One of the great things about the DevOps movement was that it formed a bottleneck between novel ideation and managed scale while consistently proving speed and flow. I’m a huge fan of development tools like Microsoft’s Copilot for development and operations. However, like RPA, I’m deeply concerned about a tool that does both. Consider the implications of Devin.ai-generated solutions and their impact on secure software supply chains and automated governance. Organizations are spending billions of dollars trying to figure this out, and we are still in very early days as far as coming up with solutions.

Conclusion

Devin.ai is a fascinating generative AI tool that is generating a lot of well-deserved buzz in the industry. However, I recommend large organizations be cautious when using it. While monitoring ChatGPT is always a good practice in highly-regulated organizations, I suggest being extra careful when using a tool like Devin.ai. Following Devin.ai’s ideas and progress is a great idea; however, until or unless they create a bring-your-own model implementation, I would proceed cautiously. Organizations should look at useful examples to help understand how you might build your own “Devin.” Here are some resources to check out:
Devin represents a significant leap forward in the realm of AI and software development, and it is a stepping stone toward a future where AI can act as a true collaborator or co-worker rather than a replacement for human engineers. I look forward to advancements that will allow generative AI to tackle more complex, integrated systems and contribute meaningfully to the software development process.
March 28, 2024
Survey Surfaces Substantial Platform Engineering Gains

A global survey of 500 application development and deployment professionals finds that while 43% work for organizations that have had a platform team in place for three to five years, there doesn’t appear to be much consistency regarding where that team reports within an organization.

The survey, conducted by Puppet by Perforce, a provider of an automation framework, found that among organizations that have platform teams, well over half (58%) operate within the context of a larger DevOps or infrastructure management organization, compared to 40% that have their own dedicated leadership.

David Sandilands, a principal solutions architect for Puppet by Perforce, said the survey makes it clear that platform engineering, in general, is not a new concept, but it’s clear more organizations are trying to reduce the level of toil currently associated with building and deploying applications.

Regardless of where platform teams reside in an organization, nearly two-thirds of respondents (65%) said they are important to their organizations and would receive continued funding. The primary purpose for forming these teams is to increase productivity (58%) and automate standardized processes (51%), the survey finds. Top goals for platform engineering teams are to solve problems (30%), enforce security processes (27%) and accelerate transitions to cloud-native computing environments (26%). A full 70% said security was built into their platforms from the start.

That suggests that, in addition to assuming responsibility for traditional DevOps workflows, many platform teams are now also being asked to ensure DevSecOps best practices are followed at a time when application security requirements are becoming more stringent, noted Sandilands.

More than three quarters (76%) also reported that they had deployed two or more self-service portals, with 27% having deployed five or more.

Only 22%, however, said they have deployed applications on Kubernetes in a production environment, with just under half (46%) reporting they have no current plans to deploy a cloud-native computing platform, which are widely seen to be challenging to deploy and maintain.

Overall, the survey makes it clear the primary focus is to ensure platforms continue to evolve as developer requirements continue to evolve, said Sandilands. Platform teams are not necessarily trying to dictate what tools should be used; instead, they are finding ways to automate processes that are increasing the level of friction developers encounter, he added.

In the longer term, advances in artificial intelligence (AI) will make it simpler to achieve that goal using natural language interfaces that DevOps teams can more easily invoke, noted Sandilands.

Each organization will need to decide for itself whether platform engineering makes sense as a methodology for managing DevOps at scale, but as application development and deployment continues to evolve, more nuanced approaches will be required. In general, organizations are trying to strike a balance between empowering developers and the need to streamline backend processes to increase productivity while also simplifying compliance and improving security.

The challenge, of course, is enticing developers to buy into that concept rather than using their expertise to resist platform teams that might, from their perspective, limit their prerogatives in ways that ultimately stifle innovation.

March 27, 2024