devopsy.kinsta.cloud

Category: DevOps Practice

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
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
The Ruby on Rails Resurgence
Ruby combines functional and imperative programming to create an easy-to-use, powerful language where everything is an object. Introduced in 1995, the open source programming language became popular in the 2000s during the dot-com era, when developers at startups and established companies were under pressure to rapidly launch new web applications.

Ruby on Rails, released in 2004, is a framework for Ruby that provides foundational structures for building and deploying web applications. Ruby on Rails enabled even faster development because it provided most of the nuts and bolts. Thanks to Rails, Ruby’s popularity continued to soar through the early 2010s. Among the many applications built with Ruby on Rails are Airbnb, Basecamp, Github, Hulu and Shopify.

Ruby on Rails took a backseat to JavaScript in the late 2010s, as rich front-end clients and single-page applications became more common. But even in these use cases, many developers continued to use it to rapidly build out an API layer built for Javascript front ends, in large part because Rails makes development so simple. While Ruby on Rails eased development, it also created issues, such as logic appearing in both layers, especially with functions like authentication.

Yet, Ruby on Rails’ popularity has resurged in recent years. Hired’s 2023 State of Software Engineers report found Ruby on Rails was the most in-demand skill for software engineering roles. Proficiency with Ruby on Rails resulted in 1.64 times more interviews than those without it.

This resurgence has been significantly bolstered by innovations like Hotwire and the sorting out of its JavaScript integration. JavaScript’s dominance in creating interactive, client-side applications challenged Ruby on Rails, particularly as single-page applications grew in popularity. Hotwire, a modern tool designed to streamline the use of HTML over the wire, allows developers to create highly interactive applications in Ruby on Rails with minimal JavaScript. This integration simplifies the development process by keeping Ruby on Rails at the forefront of both backend and frontend developments, which enables more seamless, full-stack development experiences. By resolving complexities associated with using JavaScript, Ruby on Rails has enhanced its appeal, enabling quicker development cycles and reducing the need for extensive cross-disciplinary expertise among development teams. This dual-front optimization is crucial for Ruby on Rails’ continued relevance and competitiveness in a fast-evolving tech landscape.

Another reason Ruby on Rails is resurging is its ability to encourage speed of development — an important element in business innovation.

One reason is that Ruby on Rails encourages speed of development — an important element in business innovation. Organizations always want technology innovation, but particularly so when they need to cope with the challenges of doing business in the 2020s. They need resilience, flexibility and scale to remain competitive and grow. Disruption, and not in a good way, has become the norm for business. According to a 2023 IDC report, three in four organizations say their business functions are dependent on innovation, and nearly half (49%) feel keeping pace with technology innovation is a major risk for 2024. That’s exacerbated by uncertainties in business supply chains and other financial uncertainties.

In short, development teams are being asked to produce more with the same or fewer resources, and that’s precisely where Rails shines.

Another driver is the recognition of the importance of developer happiness. The contentedness of professional developers is critical to productivity, as well as attracting and retaining top talent. According to Spiceworks, in 2023, recruiting qualified talent was the software industry’s primary challenge.

Further, in the Hired report, the top two draws for software engineers to their careers were:
- New challenges and continuous learning (69%)
- Building products and problem-solving (66%)
Ruby on Rails enables developers to indulge in exactly these pursuits. They spend much more time on the challenging, creative aspects of projects because the framework takes care of the components that are a part of nearly every web application.

Ruby on Rails is having a much-deserved resurgence because it enables teams to rapidly develop innovative web apps for clients who need to see them deployed quickly. Just as important, it improves developer happiness. And, as a free, open-source project, it’s available to all. So, while it may not be the right framework and language for every project, in many cases, it can be the secret sauce that enables faster-than-expected delivery and more developers to make it home in time for dinner after the arduous commute from the back bedroom office.
April 2, 2024
Five Great DevOps Job Opportunities

devopsy.kinsta.cloud 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
How Live Team Coaching Can Solve Tech’s Skills Problem

Tech has a skills issue – and it’s one that’s not going away in 2024. Live team coaching can be an important part of the solution.

‘The skills gap has become somewhat of a fixture in the tech industry, and after a turbulent year, rapid tech hiring is no longer a viable option for the many companies pursuing more productivity or innovation at lower cost.

With VC funding less forthcoming in 2023, teams slimmed down to make ends meet. Leaders are being pushed to do more with what they already have. That’s not helped by the rapid pace of technological change – it’s estimated that the half-life of technical skills is already less than 2.5 years. That means that skills gaps are opening up within teams all the time, and competition is fierce for software engineers with the right niche of skills (e.g., deep expertise in AI and data science). After all, non-tech companies, such as those in retail and finance, now want those developers, too. And remote working has meant local talent is being pursued by the whole world.

It’s a crisis that has the potential to severely curb business ambitions. A 2023 Gartner survey found technology executives see the talent shortage as the most significant adoption barrier to 64% of emerging technologies that enable innovation versus 4% in 2020. Not being able to utilize the best technology is leading to delays, low productivity, more errors and the release of inadequate products.

The tech sector is between a rock and a hard place, and something needs to change. By considering how skills are nurtured internally, startups and scaleups can begin to overcome the barriers holding them back.

Coaching Can be the Fast Track to Team Success

The tech industry has been addicted to hiring as a means of improving a team’s abilities and an organization’s output. That’s no longer a viable option. The sector needs a marked shift in favor of developing its current people so they’re agile, resilient and rapidly able to achieve expertise in technologies with ease.

This is important for software developers, too. Learning and growth are a developer’s second priorities when choosing a job – higher than their compensation. Historically, this need has been half-solved by giving people access to resources – books, videos, lunch and learns, etc. These kinds of perks have become the standard, and they remain nothing more than perks. Few leaders have invested in meaningful learning and real growth in their existing developers’ capabilities toward a strategic goal. What would that look like? Adopting technologies, increasing abilities, and improving outputs through learning rather than hiring.

Live team coaching taps into the potential of a company’s people. It focuses on the specific needs and goals of an organization and the skills gaps that exist within the individuals on a team. With regular coaching from a live expert, software engineers can build a deep understanding and develop new capabilities through problem-solving and feedback. More innovative features are built faster, with higher-quality code and fewer bugs. And the confidence and resilience of the team as a whole is improved. Technologies and targets that once seemed out of reach become achievable.

That has clear business benefits. With next-generation technologies, developers can work more productively and innovatively. AI, for example, can automate large parts of coding and debugging, leaving software engineers with more capacity for higher-level work. Research by GitHub, which polled 90,000 developers in its most recent survey, found a third of developers said AI has increased their productivity, and one in four are achieving greater efficiency.

Targeted learning can also help developers work smarter, removing bottlenecks and streamlining workflows. Almost two-thirds (63%) of the developers GitHub surveyed spent more than 30 minutes a day searching for answers or solutions to problems, and 53% agreed they’re slowed down at work by waiting for answers. Imagine the boost in productivity if they had access to targeted learning, which would bring solutions to those problems well within reach.

Confidence and Resilience

That’s what happened at Datamaran. The company has created a software analytics platform that identifies and monitors the risks and opportunities of ESG strategies, and they have been using live team coaching with its 20 developers for just over a year, with a particular focus on developing their skills in Python and JavaScript.

Datamaran’s CTO and co-founder Jérôme Basdevant has noted that it’s already had a big impact. Efficiency has improved significantly, and the team can now appropriately use more advanced coding patterns and practices in their work. Basdevant says they’re more autonomous now because he can trust them to write code correctly. Plus, the team has improved their understanding of the complexity of estimation, which has resulted in a more predictable workflow. He’s also been able to hire people from more diverse backgrounds and use live coaching to upskill them on the job.

Constantly Bridging the Gap

In some respects, the industry must become comfortable with the fact that the skills gap is here to stay–with rapidly changing technology, then the skill set of a perfect team will be a moving target. However, if organizational leadership—and that means the whole C-suite, not just the CTO—finds an ongoing continual solution, then teams will reach their potential and achieve more. If managers change their mindset and adopt long-term and continuous learning, which is built into the working day, then their teams will have the ability to not just keep moving forward but to accelerate.

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
A Brief History of DevOps and the Link to Cloud Development Environments

The history of DevOps is worth reading about, and “The Phoenix Project,” self-characterized as “a novel of IT and DevOps,” is often mentioned as a must-read. Yet for practitioners like myself, a more hands-on account is “The DevOps Handbook” (by the same author, Gene Kim, and others), which recounts some of the watershed moments around the evolution of software engineering and illustrates it with technology that provides good references around implementation. This book describes how to replicate the transformation explained in the Phoenix Project and provides case studies.

In this brief article, I will use my notes on that book to outline a concise history of DevOps, add my personal experience and opinion and establish a link to cloud development environments (CDEs), i.e., the technology category at the center of the platform that we have been developing at my company, Strong Network.

In particular, I explain how a cloud development environment finalizes the effort of bringing DevOps “fully online.” This notion of completeness, i.e., how CDEs mark the end of moving software development online, is my main contribution to this brief article. To clarify the link between DevOps and CDEs, let’s first dig into the chain of events and technical contributions that led to today’s main methodology for delivering software.

The Agile Manifesto

The creation of the Agile Manifesto in 2001 sets forth values and principles as a response to more cumbersome software development methodologies like Waterfall and the Rational Unified Process (RUP).

One of the manifesto’s core principles emphasizes the importance of delivering working software frequently, ranging from a few weeks to a couple of months, with a preference for shorter timescales. The Agile movement’s influence expanded in 2008 during the Agile Conference in Toronto, where Andrew Shafer suggested applying Agile principles to IT infrastructure rather than just application code.

This idea was further propelled by a 2009 presentation at the Velocity Conference, where a paper from Flickr demonstrated the impressive feat of “10 deployments a day” using Dev and Ops collaboration. Inspired by these developments, Patrick Debois organized the first DevOps Days in Belgium, effectively coining “DevOps.” This marked a significant milestone in the evolution of software development and operational practices, blending Agile’s swift adaptability with a more inclusive approach to the entire IT infrastructure.

The Three Ways of DevOps and the Principles of Flow

All the concepts discussed so far are incarnated into the “Three Ways of DevOps,” which are the foundational principles that guide the practices and processes in DevOps. In brief, these principles focus on:

1. Improving the flow of work (first way) by eliminating bottlenecks, reducing batch sizes, and accelerating workflow from development to production.
2. Amplifying feedback loops (second way) by quickly and accurately receiving information about any issues or inefficiencies in the system.
3. Fostering a culture of continuous learning and experimentation (third way) by encouraging a culture of continuous learning, experimentation and taking risks.

Following the lead of lean manufacturing and Agile, it is easy to understand what led to the definition of the above three principles. I delve more deeply into each of these principles in other articles. For the current discussion of how DevOps history connects to cloud development environments, we must look at the first way, the principle of flow, to understand the causative link.

Chapter nine of the DevOps Handbook explains that version control and containerization are central to implementing DevOps flows and establishing a reliable and consistent development process.

First, incorporating all production artifacts into version control serves as a single source of truth, enabling the recreation of the entire production environment in a repeatable and documented fashion. This ensures that production-like code development environments can be automatically generated and entirely self-serviced without requiring manual intervention from operations.

The significance of this approach becomes evident at release time, which is often the first instance where an application’s behavior is observed in a production-like setting, complete with realistic load and production data sets. To reduce the likelihood of issues, developers are encouraged to operate production-like environments on their workstations, created on-demand and self-serviced through mechanisms such as virtual images or containers, utilizing tools like Vagrant or Docker. Putting these environments under version control allows the entire pre-production and build processes to be recreated.

From Developer Workstations to a CDE Platform

The notion of self-service is already emphasized in this 2016 book as a key enabler of the principle of flow. Looking back at the TPS, the notion of self-service aims to empower Toyota’s workers to be more effective in controlling the development process. Using 2016 technology, this notion is realized by downloading environments to the developers’ workstations from a registry (an online portal) that provides pre-configured, production-like environments.

Through this operation, developers, in effect, (1) Copy files with infrastructure information to their machines, (2) add source code to it, and (3) build the application using their workstation computing resources.

Once the application works correctly, the source code is sent (pushed) to a central code repository, and the application is built and deployed using online or cloud-based resources.

The three steps listed above are, in effect, the only operations in addition to authoring source code using a “local” IDE. In other words, they use workstations’ physical storage and computing resources. All the rest of the DevOps operations are performed using web-based applications used as-a-service by development (even when these applications are self-hosted by the organization). The goal of cloud development environments is to move these operations online as well.

To do that, the CDE platform, in essence, provides the following basic services:

● Manage development environments online, as containers or virtual machines such that developers can access them fully built and configured, replacing step (1) above.
● Provide a mechanism for authoring source code directly online, such as inside the development environment using an IDE or a terminal, replacing step (2).
● Provide a way to execute build commands inside the development environment (via the IDE or terminal), replacing step (3).

Note that the replacement of step (2) can be done in several ways: For example, the IDE can be browser-based (in a cloud IDE), or a locally installed IDE can implement a way to remotely author the code in the remote environment. It is possible to use a console text editor via a terminal such as vim.

I cannot conclude this discussion without taking a recursive step to rethink the developer’s workflow. Often, multiple containerized environments are used for local testing, particularly in combination with the main containerized development environment. Hence, cloud IDE platforms need to provide the ability to run containerized environments inside the cloud development environment (itself a containerized environment). If this becomes a bit complicated, no worries. We have reached the end of the discussion, and we can move to the conclusion.

What Comes Out of Using Cloud Development Environments in DevOps

A good way to conclude this discussion is to summarize the benefits of moving development environments from the developers’ workstations online. For example, the use of CDEs for DevOps leads to the following advantages:

● Streamlined Workflow: CDEs enhance the workflow by removing data from the developer’s workstation and decoupling the hardware from the development process. This ensures the development environment is consistent and not limited by local hardware constraints.
● Version Control Integration: With CDEs, version control becomes more robust as it can uniformize the environment definition and all the tools attached to the workflow, leading to a standardized development process across the organization.
● Self-Service Environments: The self-service aspect is improved by centralizing production, maintenance and evolution of environments based on distributed development activities. This allows developers to quickly access and manage their environments without the need for operations manual work.
● Consistency Across Teams: The use of CDEs leads to uniform environments and tooling, which opens the possibility of harmonizing the entire development workflow, making it easier to onboard new team members and ensure that all developers are using the same configurations and tools.
● Reduced Local Resource Dependence: Migrating the consumption of computing resources from local hardware to centralized and shared cloud resources lightens the load on local machines and leads to more efficient use of organizational resources and potential cost savings.
● Improved Collaboration: Ubiquitous access to development environments, secured by embedded security measures in the access mechanisms, allows organizations to cater to a diverse group of developers, including internal, external and temporary workers, fostering collaboration across various teams and geographies.
● Scalability and Flexibility: CDEs offer scalable cloud resources that can be adjusted to project demands, facilitating the management of multiple containerized environments for testing and development, thus supporting the distributed nature of modern software development teams.
● Enhanced Security and Observability: Centralizing development environments in the cloud bolsters security and provides immediate observability due to their online nature, allowing for real-time monitoring and management of development activities.

By integrating these aspects, CDEs become a comprehensive solution for modern software development. They align with the principles of DevOps to improve flow, feedback and continuous learning, while also addressing the practical needs of development teams for security, accessibility and resource efficiency.

Dispelling a Few Myths About DevOps

For starters, “The DevOps Handbook” aims to dispel common misconceptions about DevOps and how it is applicable across diverse business environments, including non-software product delivery. That last point was one of my first moments of personal enlightenment when reading the book about the general applicability of the method. That led me to suggest to a friend creating a business of globally designed yet locally manufactured home furniture that designers post their models via a platform for furniture pieces to be built by local (relative to the delivery address) woodshops and that his manufacturing process perfectly fits a DevOps canvas.

Furthermore, the book refutes the notion that DevOps means eliminating IT operations. Instead, it highlights the importance of collaboration and integration between development and operations teams. On that point, it also strikes me that the mention of DevOps still has a strong attachment to the IT operations of building and deploying software rather than to the design and coding phases of that process. In other words, some managers fail to recognize that developers are indeed “doing DevOps” in the same way that IT operators are. Platform engineering aims to further reduce the gap between developers and IT operations by empowering developers (and other roles) to perform complex IT operations in a self-service environment.

Lastly, the idea that DevOps is solely about “infrastructure as code” and automation is also challenged in the book. While automation is a crucial component of many DevOps patterns, the book stresses that DevOps also requires a cultural shift and an architecture that supports shared goals across the IT value stream.

The RUP was the main software engineering methodology that IBM used to structure its development process and the ones of its customers, at the time I was part of the IBM Research division at T.J. Watson, New York in the 2000s. We sold RUP across every industry, including automotive manufacturers (a nice feedback loop), when they started to embed gigabytes of software in cars.

At IBM Research, we even evolved the RUP into a methodology to fit the needs of software-laden product development from a system perspective, dubbed model-driven systems development. This is important because software in manufacturing needs to communicate and actuate with independently-built hardware. I have taught that concept in Japan at Keio University (along with Prof. Nishimura) from 2006 to the mid-2010s.

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