devopsy.kinsta.cloud

Tag: application development

Broadcom Survey Surfaces Slow but Steady VSM Progress

A survey of 501 business and IT leaders published this week found well over half (60%) have adopted some form of value stream management (VSM), but most of those efforts are still in the early stages, with 13% in planning, 25% having a pilot project and 23% applying VSM to a single project. Only 10% are applying VSM broadly across their application development initiatives.

Conducted by Dimensional Research on behalf of Broadcom, the survey found the most widely used VSM tools remain Excel spreadsheets (50%), followed by 42% using home-grown tools. Well over two-thirds (69%) share VSM metrics quarterly or monthly but only 9% indicate this data is being made available continuously, the survey finds.

Not surprisingly, only 36% said they have good or excellent visibility, while 21% characterize their visibility as either poor or a complete “black hole.”

Laureen Knudsen, chief transformation officer at Broadcom, said while VSM progress is being made, there is clearly much work to be done. To facilitate those efforts, Broadcom is now making available a VSM Maturity Model describing the five stages organizations will need to navigate before fully mastering VSM.

The primary reasons cited for adopting VSM include efficiency (79%), customer experience (71%), customer value (62%), profitability (60%) and alignment (44%). In general, organizations are adopting VSM to reduce redundant efforts, which should result in more profits from investments being generated faster, noted Knudsen.

Ideally, organizations should be able to surface business objectives within the context of the tools used to build and deploy applications, noted Knudsen. That approach will enable developers and the DevOps teams that support them to make better business decisions based on the dependencies that might exist between projects, she added. Otherwise, individual team members will make decisions without any understanding how they impact the business at all, said Knudsen.

Unfortunately, that lack of visibility is hard to achieve. The survey finds 85% of decisions are either made at the leadership level, or teams need leadership approval before implementing their decisions. Only 5.8% said decisions are made and implemented at the team level. That dependency on a centralized command and control model for managing application development is a direct result of an inability to collect and share relevant data with the teams working on various elements of a project, noted Knudsen.

In fact, the survey found only 11% of organizations don’t give employees business metrics by which they can achieve or measure products, even though 63% indicated they have metrics.

The more data a DevOps team has the more likely it becomes that the right decision will be made at the right time. Otherwise, factors that are more influenced by inherent biases that stem more from the role of the individual rather than the strategic objectives of the organization will have a bigger impact on how and when decisions are made.

Of course, VSM requires organizations to make investments in platforms capable of capturing and analyzing relevant data. The issue then becomes determining to what degree a VSM platform will provide a return on that investment in a way that results in more business objectives being achieved faster.

January 5, 2024
Best of 2023: 5 Microservices Design Patterns Every DevOps Team Should Know

As we close out 2023, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2023.

Microservices have revolutionized the world of application development, breaking down large, monolithic systems into smaller, more manageable components. The architectural style, characterized by independent, loosely-coupled services, brings numerous advantages from scalability and modularity to increased flexibility.

How can DevOps teams best utilize this approach for maximum efficiency? The answer lies in understanding and effectively employing microservices design patterns. In this article, we will delve into the five key microservices design patterns that every DevOps team should know: The API gateway pattern, database per service pattern, circuit breaker pattern, event-driven pattern and the saga pattern. We’ll explore what these patterns are, the benefits they bring, their challenges and touch on how to choose the optimal microservices design patterns for your project.

What Are Microservices?

Microservices is an architectural style that structures an application as a collection of small, loosely coupled and independently deployable services. Each of these services corresponds to a specific business functionality and can be developed, deployed and scaled independently.

The idea behind microservices is to break down a large, monolithic application into a collection of smaller, more manageable pieces. Each microservice is a separate component that can be developed, tested, deployed, scaled and updated independently of all other microservices. This approach offers numerous advantages, such as increased modularity, flexibility and scalability, making it highly popular among organizations seeking to improve their application’s performance and maintainability.

Contrary to the monolithic architecture, where all components of the application are interconnected and interdependent, in a microservices architecture, each service is independent and communicates with others via well-defined APIs and protocols. This independence allows for using different technologies and languages for different services that best fit each service’s requirements.

Benefits of Microservices in DevOps

Microservices architecture has emerged as a game-changer in the DevOps landscape. Let’s delve into some of the key benefits of integrating microservices into your DevOps practices.

Independent Deployments

One of the biggest advantages of microservices is that they can be deployed independently. This means that changes can be made to a single service without affecting the entire application. In a monolithic architecture, even a small change requires redeploying the whole application, which is both time-consuming and risky. However, with microservices, teams can update, adjust or even completely rewrite a service without disrupting the overall application’s functionality. This facilitates continuous delivery and deployment, key aspects of DevOps culture.

Fault Isolation

Another major benefit of microservices is enhanced fault isolation. In a monolithic architecture, a failure in one component can bring down the entire application. However, in a microservices architecture, if one service fails, the others continue to function normally. This isolated failure can be dealt with without impacting the overall application performance. Therefore, microservices contribute significantly to the stability and resilience of an application.

Enhanced Scalability

Microservices also offer superior scalability. Since each microservice is a separate entity, it can be scaled independently based on demand. If a particular functionality experiences high demand, only the corresponding service needs to be scaled up rather than the entire application. This targeted scaling is not only more efficient but also cost-effective, making microservices a preferred choice for businesses experiencing variable loads.

Importance of Design Patterns in Microservices Architecture

When it comes to microservices, one size does not fit all. Different applications have different requirements, and the design of your microservices architecture should accommodate these specific needs. That’s where design patterns come into play. Let’s examine the importance of these patterns in the context of microservices.

Scalability

Scalability is one of the critical factors to consider while designing a microservices architecture. The ability to handle increased loads by adding more instances of services is a core advantage of microservices. However, this requires careful design to ensure that services can be easily duplicated and distributed. Design patterns like the replicated service instance and sharded services patterns help achieve this scalability.

Reducing Complexity

Design patterns play a vital role in reducing the complexity associated with microservices architecture. Breaking down an application into microservices can lead to a proliferation of services, which can be challenging to manage. However, with the right design patterns, such as aggregator or API gateway, you can simplify service management and improve communication between services.

Distributed Data Management

Microservices often rely on distributed data management, which can be complex. Each microservice has its own separate database to ensure loose coupling and independence. However, managing transactions and ensuring data consistency across services can be challenging. Design patterns like saga and event sourcing can help manage distributed data effectively.

Enhancing Communication

In a microservices architecture, services need to communicate with each other to function correctly. This inter-service communication is usually done via APIs, but it can become complicated as the number of services increases. Design patterns like client-side load balancer and circuit breaker can help streamline this communication and ensure that services can interact efficiently.

5 Key Microservices Design Patterns

The API Gateway Pattern

In a microservices architecture, each service exposes a set of fine-grained APIs. Managing these APIs individually can be a daunting task, especially when your application consists of dozens or even hundreds of microservices. That’s where the API Gateway pattern comes into play.

The API gateway serves as a single entry point for all client requests. It routes requests to the appropriate microservice and subsequently aggregates the responses. It also handles cross-cutting concerns like authentication, monitoring and rate limiting. Furthermore, it provides a unified API that is easier to consume by the client, shielding them from the complexity of the microservices architecture.

However, the API Gateway pattern is not without its challenges. It can become a bottleneck if not properly designed and scaled. Also, it’s a single point of failure unless highly available. Despite these challenges, with careful design choices and good operational practices, the API Gateway pattern can greatly simplify client interaction with microservices.

Database Per Service Pattern

In a monolithic application, all modules typically share a single database. While this approach might seem convenient, it leads to a tight coupling between modules, making it hard to scale and maintain the application. The Database Per Service pattern provides an elegant solution to this problem.

In this pattern, each microservice owns its database, ensuring loose coupling and high cohesion. This allows each microservice to use a database type that is best suited to its needs. Furthermore, it enables independent scaling and evolution of each microservice.

However, implementing the Database Per Service pattern can be challenging. It involves dealing with distributed data management issues, like ensuring data consistency across services. Despite these challenges, the Database Per Service pattern is a powerful tool for achieving data isolation and autonomy in a microservices architecture.

The Circuit Breaker Pattern

In a microservices architecture, services often rely on each other. If a service fails or becomes slow, it can impact all the dependent services, leading to a cascading failure. The Circuit Breaker pattern aims to prevent this scenario.

With the Circuit Breaker pattern, you can prevent a network or service failure from cascading to other services. When a failure is detected, the circuit breaker trips and prevents further calls to the failing service. It then periodically attempts to call the service, and if successful, it closes the circuit and lets the calls go through.

This pattern helps maintain service performance and avoid timeouts during a failure. However, it requires careful tuning to balance between responsiveness and sensitivity to failures. Despite the complexities, the Circuit Breaker pattern is a key pattern for building resilient microservices.

The Event-Driven Pattern

In a microservices architecture, maintaining data consistency among services can be challenging. The Event-Driven pattern provides a solution to this issue.

In the Event-Driven pattern, services publish events when their state changes. Other services subscribe to these events and update their state accordingly. This way, each service can maintain its consistency without the need for synchronous communication.

This pattern enhances the decoupling between services and improves performance by enabling asynchronous communication. However, it can also make the system more complex and harder to understand due to the indirect nature of the interactions between services. Nevertheless, the Event-Driven pattern is a powerful tool for ensuring data consistency in a microservices architecture.

The Saga Pattern

In a microservices architecture, implementing business transactions that span multiple services can be a big challenge. The Saga pattern provides a solution to this problem.

A saga is a sequence of local transactions where each transaction updates data within a single service. If a local transaction fails, the saga executes compensating transactions to undo the impact of the preceding transactions.

While the Saga pattern can effectively manage distributed transactions, it also adds complexity to the system. It requires careful design and coordination between services. Despite these challenges, the Saga pattern is a critical tool for managing complex business transactions in a microservices architecture.

Conclusion

In conclusion, understanding and applying these five key microservices design patterns can help you design more scalable, reliable and maintainable applications. However, it’s important to remember that each pattern comes with its trade-offs and should be applied judiciously based on the specific needs of your application. As you dive deeper into the world of microservices, you’ll realize that these patterns are essential building blocks for developing robust and resilient applications.

January 2, 2024
Best of 2023: Don’t Build Microservices, Pursue Loose Coupling
As we close out 2023, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2023.

Given how demand for reliable application performance is always growing, it’s no surprise that many firms build their systems with future expansion in mind. Many industry pundits have pointed to microservices as the best way to future-proof a system—but it might be better to use the term “right-sized services” instead, as there’s no single strategy that works for every firm at every point in time. Rather than thinking about which of the latest trends to adopt as a strategy, teams should instead recognize and focus on the underlying factor of coupling. Systems are more flexible and dynamic if there is loose coupling between the components that are mostly likely to change.

Coupling, in the systems context, refers to how components of a system are connected. Interfaces are necessary for loose coupling. For electrical systems, those interfaces are implemented as physical connectors with pins and sockets and protocols described in terms of voltage levels. The software systems analogy to an electrical connector is an application programming interface (API), which could be implemented as a set of functions or HTTP-based resources, among others. But an interface alone is not enough for loose coupling. That interface must also be somewhat stable, which is to say that a user can count on that interface to be there, with its inputs remaining the same for a long time or, at least, changing predictably.

Why Loose Coupling Matters

When components of a system are loosely coupled, those components can be changed internally without significantly disrupting the rest of the system. Consider a quotidian example: The light bulb. Light bulb sockets have a standard size with standard threads and a standard voltage. The light bulb itself has evolved through various types of materials for the filament to LEDs, all without requiring a change to lamps and light fixtures. Now consider a simple example in software systems: An HTTP server and a datastore, such as a cache, queue or database. In most cases, it would be beneficial to place an interface between the server and datastore that would make changing the implementation of the datastore easy. Once these two components are only loosely coupled, things that are likely to change can do so without requiring significant changes to the other things.

If the components of your system are too closely intertwined, then even the smallest change could wreak havoc somewhere else in the system. You might compare this structure to a group of plants that were grown in proximity. Because all of the stems are intertwined, trying to swap out one plant for a new one will be challenging, as one false move could easily uproot many other plants.

In contrast, in a loosely coupled system, changes can be made with the confidence that when one component experiences an issue, the rest of the system will remain resilient. This confidence results in greater flexibility to make changes, enables shorter time-to-market for new features and products, and potentially affords a competitive advantage.

A corollary benefit of loose coupling is evolvability: When interfaces are located in the places most likely to change, it will be easier for the system to evolve. Interfaces are meant to be stable and opaque so that anything that goes on behind them is generally unknown and irrelevant to a user of that interface. So, as long as interfaces remain stable, the systems behind them are free to change and, therefore, evolve.

For Small Projects, Microservices May Negate Loose Coupling Benefits

While it is true that microservices strategies do support loose coupling, they’re not the only way. Simpler architectural strategies can afford smaller or newer projects the benefits of loose coupling in a more sustainable way, generating less overhead than building up microservices-focused infrastructure.

Architectural choices are as much about the human component of building and operating software systems as they are about technical concerns like scalability and performance. And the human component is where microservices can fall short.

When designing a system, one should distinguish between intentional complexity (where a complex problem rightfully demands a complex solution) and unintentional complexity (where an overly complex solution creates unnecessary challenges). It’s true that firms like Netflix have greatly benefited from microservices-based architectures with intentional complexity. But an up-and-coming startup is not Netflix, and trying to follow in the streaming titan’s footsteps can introduce a great degree of unintentional complexity.

The microservices approach is a way to manage the complexity of a system once it has gotten too large to handle safely. Still, there is a trade-off between complexity and overhead. There is substantial overhead associated with managing a number of services. If adopted prematurely, a microservices approach can result in staff members spending all of their time supporting the tools that support the services and neglecting the actual product.

Two Ways to Move Fast and Remain Nimble

There are at least two options that may be worth considering for any team that wishes to stay nimble by fostering loose coupling and to make progress by avoiding the overhead of maintaining a microservices-based infrastructure.

The first option is to embrace monolithic architecture. While monoliths are often maligned as inflexible and outdated, a properly planned one can support loose coupling and require much less support overhead. The key is to build a code-based interface that can take one component’s inputs and relay them to another. Even if one component of the monolith is altered, such an interface minimizes the impact on any other component, and the system can evolve more easily where interfaces exist.

The second option is to employ a serverless platform provided by a major cloud provider. This approach is much closer to microservices in spirit, but the overhead cost is assumed by the cloud provider. As a result, serverless architecture can afford the benefits of loose coupling with minimal unintentional complexity. It may turn out that serverless is not for you because of other constraints, but as long as you construct your interfaces carefully by focusing on the interactions that are most likely to change in the future, it doesn’t hurt to try serverless first.

Choosing the Best Loose Coupling Strategy

Even if you decide to pursue one of these two strategies for loose coupling, it may not be clear which one to choose. Here are a few factors that may help you determine whether to opt for monolithic or serverless cloud-based architectures:
- Cost. If you do not have experience in optimizing utilization with providers like AWS or if you underestimate your resource utilization, serverless architecture can become very expensive.
- Prior Knowledge. A monolith will require a little more maintenance and, therefore, is a better fit for companies that have worked with one before. Otherwise, serverless architecture may have more appeal because the provider handles much of the upkeep.
- Traffic Patterns. If traffic for your system tends to come in bursts, you may benefit from the use of a serverless platform, which will only activate when it is needed. An “always-on” monolith may be a better fit for use cases with continual traffic.
- Stage of the Product. If you’re testing out hypotheses about technical or market viability, then serverless solutions could help you test them more quickly and with less overhead. Serverless solutions are typically quick to build and configure, quick to tear down and they obviate the need to think about infrastructure, even more so than managed compute solutions.
Focus on ‘Right-Sized Services,’ Not ‘Microservices’

The objective is not to decouple everywhere, nor is it for everything to be loosely coupled. Rather, it is to make the system evolvable by strategically choosing where and by how much components are loosely coupled. This is a game of educated guesses and trade-offs. There is no best way, just a least-worst one.

When analysts and industry leaders talk about “microservices” like it is the universal answer for software systems, this only applies to teams building the most mature systems that have the capacity to support the associated overhead. The term “right-sized services” better conveys that, even within a company, each team has different constraints and, therefore, different ways of achieving loose coupling. This may entail the use of microservices, monoliths, serverless platforms or a mixture of these things; but, in any case, teams that embrace loose coupling are better equipped to respond to challenges, gain a competitive advantage and adapt to a constantly changing tech landscape.
December 26, 2023
Best of 2023: Are We Witnessing the End of Open Source?

As we close out 2023, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2023.

Hailed as a groundbreaking movement in software creation, open source software has become an indispensable pillar of modern software development. Often described as democratized technology, it has empowered countless individuals and organizations to collaborate and innovate. However, the community now stands at a critical juncture, and there’s some speculation that we’re seeing a decline in the open source space.

Why is Open Source so Popular in Modern Software Development?

At the heart of open source lies the power of collaboration. Unlike proprietary (closed source) software, open source invites participation from a diverse range of contributors, allowing them to work collectively to create and improve software. This inclusivity fosters shared knowledge and cooperation, leading to the creation of groundbreaking software.

In addition to collaboration, the open source development approach eliminates financial barriers and significantly enhances accessibility in software development. With open source software typically distributed under licenses that allow users to access, use, modify and distribute the software freely, this eliminates the need for costly licenses usually associated with proprietary software. This affordability allows organizations of all sizes to leverage innovative solutions without accruing high upfront costs.

Within the framework of open source software, transparency is ingrained. The accessibility of the source code makes it possible for users and contributors to scrutinize the source code, promoting trust and accountability. By promoting scrutiny and peer review, transparency ensures that flaws are quickly identified and addressed. It also empowers users to have greater control over their choices in technology.

With these benefits coupled with success stories from enormous projects like Linux, Apache and MySQL, open source positioned itself as having the potential to compete with proprietary alternatives, leading to widespread adoption across the technology industry.

More Projects are Jumping Ship

Given these numerous benefits, one might wonder: What challenges could arise with this approach? In recent years, there have been sentiments amongst contributors that the space might be losing steam. Their concerns are fueled by a few key factors that may erode or undermine the collaborative essence of the movement.

A huge factor is the commercialization of open source projects. A popular example of this phenomenon is the GitHub acquisition – GitHub, the home for open source projects for years, was acquired by the tech giant Microsoft in 2018. This news ruffled some feathers in the community, as Microsoft was seen as a proponent of proprietary software. It also raised doubts about whether GitHub would maintain autonomy over its decision-making process.

Regardless of these doubts, the community overcame the bump in the road rather quickly and continued contributing to the platform for years. However, in 2022, GitHub announced that a sub-program called Copilot, which open source developers had been working on, would emerge as a commercial product, with the profits going to GitHub itself. This development infuriated community developers, and they faced a rude awakening that any open source platform could decide to commercialize their projects without contributors sharing in the financial rewards or even gaining recognition for their work. Another open source project that has fallen victim to commercialization is OpenAI.

There have also been increasing concerns about whether open-sourcing core business models will cause more harm than good. Unlike in the past, it’s a lot easier for projects to become popular, creating a high possibility that someone else can steal the idea or offering and quickly create a commercial product based on the project.

These considerations are part of a broader discussion regarding the shifting dynamics and potential departure from the core principles within the community, causing participants to be uneasy.

The Dust Settles: Open Source Remains Strong

Despite the concerns and challenges facing the community, open source has undeniably transformed how we build and deploy software. We must approach the future of the movement with cautious optimism.

Drawing from past experiences like GitHub and OpenAI, it is clear that the community is resilient and adaptive. Contributors who do not agree with the acquisition of GitHub or the commercialization of OpenAI will take their gifts and contribute to projects whose values they agree with.

However, open source is at a crossroads and is grappling with challenges and changes that demand introspection. This introspection, hopefully, will lead to adjustments in the open source space that reaffirm its core principles and address concerns. Open source is not fizzling out, at least not yet; we can think of it as undergoing a transformative phase that will shape its future and ensure that it remains an important pillar in the software development landscape.

To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2023 – November 6-9, 2023.

December 22, 2023
Using Low-Code/No-Code to Fast-Track Enterprise Solutions

Not long ago, it wasn’t uncommon for a new application deployment to take a year or more. Today, that timeframe is measured in weeks. What has changed?

For many enterprises, traditional, full-code waterfall application development, with its focus on a sequential define-develop-test-deploy-maintain approach, has given way to low-code/no-code development, a faster, more accessible method for developing and modifying applications using intuitive tools without extensive coding. Low-code and no-code development systems fulfill ever-increasing demands for fast application delivery and highly customized automation workflows.

In addition to putting control back in the hands of users who know their needs best, low-code and no-code systems are also credited with improving developer productivity by enabling professional developers to streamline aspects of the development process.

According to Gartner, the no-code/low-code platform market is forecast to grow almost 20% in 2023 to $10 billion and reach $12.3 billion in 2024.

This growth is not surprising when you consider the following:

• Tech Talent Shortage. The market for low-code/no-code platforms is driven in large part by a global shortage of skilled software developers, a situation that is expected to continue throughout this decade. Low-code/no-code platforms enable companies to quickly get development projects off the ground without the need for professional developers.
• Focus on Cost. As companies become ever more mindful of their tech spend, low-code/no-code solutions can offer an accelerated, less expensive alternative to custom software development, which involves professional developers, longer development cycles and more comprehensive support programs.
• Need to Reduce IT backlogs. Low-code/no-code is also having a significant impact by reducing application enhancement backlogs in IT departments and application requests from end users that haven’t yet been addressed. In many companies, this backlog is years long. With no-code/low-code, users can actually create and/or modify applications themselves rather than waiting in a queue for their needs to be addressed.
• Agile Development. Many companies today follow the Agile methodology of software development, where teams work together in incremental cycles to continuously improve. Key drivers of Agile development are flexibility and speed. Low-code/no-code application development can empower those teams with a faster approach to continuous software development based upon pre-defined elements and templates and drag-and-drop interfaces.
• Growth in Cloud-Native Applications. Growth in low-code/no-code is driven in part by the increased adoption of cloud-native technologies as organizations rapidly embrace the benefits and availability of the cloud. The advantages of cloud-native software development include increased agility, lower hosting costs, faster time to market and improvements to user experience.

Varian Medical Systems Leverages Low-Code/No-Code to Ensure Compliance

Today’s enterprise software providers are increasingly opening up their code to enable greater customization and innovation of critical systems. Take, for example, Varian Medical Systems, a leading manufacturer of medical devices and software for treating cancer and other medical conditions. As a global life sciences company, it must adhere to FDA regulations and those of other regulatory bodies around the world. While its quality management system was able to provide a good level of visibility and oversight to meet the specific requirements of its market, Varian wanted to customize the system to add a new layer of compliance management and streamline core field action processes. It used low-code/no-code modules within its quality management system (QMS) to enable compliance and standardization of key processes and integrate with other quality records, such as meeting records or complaints and risk assessments, to more easily gather information supporting the field action.

Understand the Landscape and the Limitations

While low-code/no-code development is on the rise, helping companies roll out almost-ready-made solutions quickly, cost-effectively and with less risk, it is essential to understand that it can come with sacrifices to scalability, flexibility and integration with existing tools.

Solutions won’t always have a customized front end, they may not have industry-first capabilities and they’re often viewed as software commodities. Yet, maybe it isn’t always about the technology that drives the outcome, but the user experience it delivers.

One of the hallmarks of a successful organization is striking the right cost/benefit balance. For today’s organizations, faced with labor shortages, tight profit margins and a need for speed, knowing when heavy-lifting custom software development is required and when low-code/no-code offers a better, more cost-effective approach can mean the difference between success and failure.

November 29, 2023
Bitrise Tightens Mobile DevOps Integration With AWS Cloud Services

Bitrise this week will tighten integration with its DevOps platform for building and deploying mobile applications and the application development services provided by Amazon Web Services (AWS) cloud.

Announced at the AWS re:Invent 2023 conference, the goal is to provide easier access to automated building, testing and release management capabilities provided by AWS as part of an effort to increase overall efficiency.

Bitrise CEO Barnabas Birmacher said those capabilities will streamline workflows for a Bitrise Mobile DevOps platform that has been specifically designed for building and deploying mobile applications that typically need to be updated frequently.

Based on a continuous integration/continuous delivery (CI/CD) platform developed by Bitrise that can be deployed in an AWS cloud computing environment, the integrations will make it simpler to build and run mobile applications at scale, noted Birmacher.

The goal is to reduce the total cost of building mobile applications while at the same time improving developer productivity for mobile applications that have to be thoroughly tested before being made accessible via an application store, he added.

It’s not clear how many organizations will prefer to have a dedicated CI/CD platform for building and deploying mobile applications versus using the same CI/CD platform they might already be relying on to build and deploy other applications. Bitrise claims to have more than 6,000 customers, including Reddit, WISE, Equinox and Philips Hue.

As the percentage of mobile applications that make up an organization’s portfolio continues to increase, the pace at which those applications need to be updated lends itself better to a CI/CD platform optimized for those types of applications, said Birmacher.
In fact, a recent survey conducted by Bitrise found 62% of respondents have been adversely impacted by manual processes that slowed the rate at which mobile applications were deployed and updated. The survey also found (44%) of respondents reported their release approval process is mostly or entirely manual, with only 9% having fully automated application releases.

The survey also found that nearly two-thirds of organizations (66%) have deployed applications that can’t be opened in two seconds or less, which is widely considered the accepted level of performance required for mobile applications. In addition, three-quarters of organizations (75%) required more than two days to address bug fixes.

Many mobile apps have become increasingly mission-critical thanks to digital business transformation initiatives. Consequently, the amount of focus on them within most organizations is high; any issues that arise are likely to be noticed at the highest echelons of an organization. That level of attention can easily put pressure on DevOps teams, mainly because the general expectation among end users is that mobile applications will be regularly updated with new functionality. However, if release processes are largely manual, regularly improving the user experience can become problematic.

Each IT organization will need to decide for itself how best to go about building and deploying mobile applications, but the one thing that is certain is adjustments to DevOps workflows will need to be made as a lot more of these applications are continuously built, deployed and updated.

November 27, 2023
GitHub Aims to Expand Copilot Scope and Reach in 2024

GitHub is gearing up to launch Copilot Workspace next year, a platform that will leverage generative artificial intelligence (AI) to automatically propose a plan for building an application based on natural language descriptions typed into the GitHub Issues project management software.

The platform, revealed at the GitHub Universe 2023 conference, Copilot Workspace will generate editable documents via a single click that can be used to create code that developers can then visually inspect, edit and validate. Any errors discovered by application developers or the Copilot Workspace platform can also be automatically fixed.

In addition, summaries of the project can automatically be created and shared across an application development team.

GitHub CEO Thomas Dohnke told conference attendees this “revolutionary” approach will enable developers to employ AI as a “second brain.”

In the meantime, GitHub is making an enterprise edition of Copilot available that can be trained using code connected to a private repository to ensure intellectual property is protected. GitHub also moving to integrate GitHub Copilot with third-party developer tools, online services and knowledge outside GitHub by collaborating with, for example, Datastax, LaunchDarkly, Postman, Hashicorp and Datadog.

GitHub is moving to make the generative AI capabilities it provides accessible beyond text editors. Copilot Chat, starting next month, can be accessed via a mobile application to foster collaboration by explaining concepts, suggesting code based on your open files and windows, detecting security vulnerabilities and finding and fixing code errors.

Copilot Chat, based on Chat GPT 4, can also be accessible across the GitHub website in addition to integrated development environments (IDEs) such as JetBrains and via a command line interface (CLI).

Generative AI is already having a massive impact on the rate at which applications are developed, but that code still needs to be reviewed. Chat GPT is based on a general-purpose large language model (LLM) that is trained by pulling in code of varying quality from all across the web. As a result, code generated by the platform might contain vulnerabilities or be inefficient. In many cases, professional developers still prefer to write their own code.

Of course, not every programming task requires the same level of coding expertise. In many instances, ChatGPT will generate, for example, a script that can be reused with confidence across a DevOps workflow. There is no shortage of mediocre developers who are now writing better code thanks to tools such as GitHub Copilot, and soon, domain-specific LLMs will make it possible to consistently write better code based on validated examples of code.

The one thing that is certain is the volume of code written by machines is only going to increase. The challenge will be managing all the DevOps pipelines that will be needed to move increased volumes of code into a production environment. There is no doubt that AI will be applied to the management of DevOps pipelines, but for the moment, at least, the pace at which AI is being applied to writing code is already exceeding the ability of DevOps teams to manage it.

November 15, 2023
Netlify Unfurls Composable Jamstack Framework for Web Apps

At its Compose 2023 conference, Netlify today launched a composable framework that promises to make it simpler to build web applications spanning multiple backend services.

Netlify CEO Matt Biilmann said the Netlify Composable Web Platform provides a more holistic approach for loosely coupling the frontend of a web application with backend services that can be swapped out as needed.

The goal is to make it simpler to unify content, data sources, code and infrastructure at a higher level of abstraction while providing development teams with a maximum amount of flexibility, he added.

The Netlify Composable Web Platform consists of Netlify Core to manage workflows, Netlify Connect to access content and data sources and Netlify Create to build applications using JavaScript, application programming interfaces (APIs) and markup languages, otherwise known as Jamstack, framework.

Collectively, the tools will enable development teams to move away from monolithic web applications that are more difficult to update and maintain, noted Biilmann. Instead, development teams can compose applications faster using a framework that automates many of the underlying processes that conspire to slow down application development, he added.

In the face of challenging economic headwinds, interest in improving developer productivity is rising because organizations need their existing teams to consistently deliver applications faster. Most organizations can’t afford to continue expanding development teams when the current processes relied on to build software result in developers spending only a quarter of their time writing code.

There is also a greater need for collaboration using a framework that enables different members of a development team to build elements of an application in isolation from one another without impacting the entire application. Each organization will need to decide for itself whether it wants to make applications from multiple services, but at a time when the speed of adding new capabilities to an application is core to an organization’s ability to differentiate itself, the need for a different methodology for building applications has never been more apparent.

There is, of course, no shortage of frameworks for building web applications, but DevOps teams have a vested interest in making sure that whichever one is adopted is based on a modern architecture. The time and effort required to support monolithic applications in an era where new capabilities need to be added regularly has become cost-prohibitive. The challenge is finding a framework that enables developers to quickly build applications that can be deployed within the context of a DevOps workflow that typically needs to support applications being developed in multiple programming languages.

It’s not clear who inside IT organizations is driving adoption of composable frameworks for building the next generation of applications, but as more organizations become dependent on software, legacy approaches to building monolithic applications have become antiquated. The good news is that in terms of the developer talent pool, there are large numbers that are already familiar with multiple variants of the JavaScript programming language. The challenge, as always, is making sure that whatever code finds its way into a production environment is actually reliable enough to consistently drive a business process.

October 19, 2023
Low-Code/No-Code Application Development – Putting Users in Control

Not long ago, it wasn’t uncommon for a new application deployment to take a year or more. Today, that timeframe is measured in weeks. What has changed?

For many enterprises, traditional, full-code waterfall application development, with its focus on a sequential define-develop-test-deploy-maintain approach, has given way to low-code/no-code development, a faster, more accessible method for developing and modifying applications using intuitive tools without extensive coding. Low-code and no-code development systems fulfill ever-increasing demands for fast application delivery and highly customized automation workflows.

In addition to putting control back in the hands of users who know their needs best, low-code and no-code systems are also credited with improving developer productivity by enabling professional developers to streamline aspects of the development process.

According to Gartner, the no-code/low-code platform market is forecast to grow almost 20% in 2023 to $10 billion and reach $12.3 billion in 2024. This growth is not surprising when you consider the following:

• Tech Talent Shortage. The market for low-code/no-code platforms is driven in large part by a global shortage of skilled software developers, a situation that is expected to continue throughout this decade. Low-code/no-code platforms enable companies to quickly get development projects off the ground without the need for professional developers.
• Focus on Cost. As companies become ever more mindful of their tech spend, low-code/no-code solutions can offer an accelerated, less expensive alternative to custom software development, which involves professional developers, longer development cycles and more comprehensive support programs.
• Need to Reduce IT Backlogs. Low-code/no-code is also having a significant impact by reducing application enhancement backlogs in IT departments and application requests from end users that haven’t yet been addressed. In many companies, this backlog is years long. With no-code/low-code, users can actually create and/or modify applications themselves rather than waiting in a queue for their needs to be addressed.
• Agile Development. Many companies today follow the Agile methodology of software development, where teams work together in incremental cycles to continuously improve. Key drivers of Agile development are flexibility and speed. Low-code/no-code application development can empower those teams with a faster approach to continuous software development based upon pre-defined elements and templates and drag-and-drop interfaces.
• Growth in Cloud-Native Applications. Growth in low-code/no-code is driven in part by the increased adoption of cloud-native technologies as organizations rapidly embrace the benefits and availability of the cloud. The advantages of cloud-native software development include increased agility, lower hosting costs, faster time to market and improvements to user experience.

Understand the Landscape and the Limitations

While low-code/no-code development is on the rise, helping companies roll out almost-ready-made solutions quickly, cost-effectively and with less risk, it is essential to understand that it can come with sacrifices to scalability, flexibility and integration with existing tools.

Solutions won’t always have a customized front end, they may not have industry-first capabilities, and they’re often viewed as software commodities. Yet, maybe it isn’t always about the technology that drives the outcome but the user experience it delivers.

One of the hallmarks of a successful organization is striking the right cost/benefit balance. For today’s organizations, faced with labor shortages, tight profit margins and a need for speed, knowing when heavy-lifting custom software development is required and when low-code/no-code offers a better, more cost-effective approach can mean the difference between success and failure.

October 17, 2023
Moving Beyond Legacy API Management Tools and Strategies

What is legacy API management? That’s a question that many organizations haven’t even thought to ask because they don’t realize that the way they manage their APIs is outdated. On the contrary, they assume that if they have API gateways in place to provide security and load balancing for their APIs, they’re already ahead of the curve when it comes to managing and protecting their APIs.

But the fact is that traditional approaches to API management are fast becoming outdated. In a world where the ability to communicate in real-time is more critical than ever, legacy API management solutions can’t keep up, because they’re not designed for APIs that need to share large volumes of data using asynchronous paradigms.

That’s why forward-thinking organizations should be looking for ways to overhaul their API management tools and strategies. They need to embrace next-generation API management solutions, which can do much more than manage traditional, synchronous APIs.

Allow me to explain by walking through the shortcomings of traditional API management tools and explaining what next-generation API management entails.

Legacy API Management

Legacy API management solutions are tools designed to manage and secure synchronous APIs. Typically, these tools come in the form of gateways that sit between backend REST APIs and applications that connect to those APIs using the HTTP protocol. The gateways manage traffic flows and secure communications between the applications and the API backend.

That approach works well if two conditions are true:

1. All of your APIs are synchronous, which doesn’t always work well with continuous data streams.
2. All of your clients can consume data from APIs using HTTP requests.

Traditionally, these conditions were true for most API use cases at most organizations. That’s why the standard approach to API management is to deploy a gateway, configure some load balancing and security policies and call it a day.

Next-Generation API Management

Increasingly, however, not all data is shared synchronously, and not all applications can consume data using HTTP requests. Instead, businesses want to be able to stream data in real-time to multiple types of applications. They might use an open source event broker like Kafka to stream monitoring data from across their IT assets to the tools that IT engineers use to observe and analyze systems, for example. Or, they might need to stream sales transaction data to a fraud detection engine so it can catch fraudulent transactions in real-time.

For use cases like these, legacy API management doesn’t work well at all. Traditional API gateways aren’t very compatible with event brokers because the gateways are not designed to manage real-time data streams. Nor do they typically support protocols other than HTTP, which is a problem because event brokers like Kafka use their own protocols, not HTTP, to enable communication between servers and clients.

Next-generation API management solutions fill this gap. They operate as gateways that can not only mediate between traditional REST-based client and API endpoints, but also support event brokers, asynchronous APIs, and even apply policies at the message level to support message-based communication.

In addition, next-gen API management tools offer the ability to translate between different front and backend protocols. That means that you could have, for example, a Kafka stream on the backend that is exposed to clients using HTTP – effectively allowing apps that can only make requests via HTTP to connect to Kafka data streams, without having to build support for protocol translation into the applications themselves.

Thinking Beyond Internal APIs

At this point, you may be thinking, “We don’t expose data streams externally, so why would we need a next-gen API management solution to support them?”

That’s a fair point. The most basic use cases for data streaming platforms like Kafka involve streaming data internally – from one set of applications to another within the same IT environment, for example.

But this is certainly not always the case. There are plenty of circumstances where you might want to expose a data stream externally and require the security and reliability protections that next-gen API management tools deliver. Maybe you’re a manufacturer who wants to stream data to regulatory authorities so they can monitor your operations remotely, for example. Perhaps you use third-party monitoring or cybersecurity tools and need to stream data from your own systems to that software. Or, even if you are only exposing APIs and data to internal consumers, perhaps that data contains sensitive PII and additional security mechanisms are still necessary. And, for almost all use cases, being able to centrally expose, catalog, and make APIs discoverable is a major leg up.

Even if your business doesn’t currently expose data streams externally, by the way, there’s a good chance it will in the future. As Gartner notes, “Organizations are improving their decision intelligence and real-time applications by tapping the growing availability of streaming data.” The future for most organizations is likely to include more data streams and more complex use cases for those streams, making the functionality of next-gen API management increasingly critical to business success.

Conclusion

In short, it’s time to move beyond the confines of legacy API management – which means no longer being limited to supporting only REST API management. To capitalize fully on the opportunities enabled by streaming data, businesses need a more flexible and dynamic approach to API management, which requires a new breed of API management software.

October 5, 2023