devopsy.kinsta.cloud

Category: API

Salesforce Adds Ability to Apply Custom Security Policies to APIs

Salesforce today added the ability to customize security policies for application programming interfaces (APIs) to the Mulesoft Anypoint API management platform.

Gerry Egan, vice president of product management for Mulesoft at Salesforce, said this capability makes it possible for organizations to use an Anypoint Flex Gateway Policy Development Kit to streamline development of custom API security policies that can be implemented as code.

In addition to providing integrations with integrated development environments (IDEs), the Anypoint Flex Gateway Policy Development Kit also provides test policies that can be employed to ensure API security.

That approach makes it simpler to ensure APIs are secure as they are being built and deployed within the context of an automated DevOps workflow versus having to rely entirely on a separate API security platform, he noted.

The Mulesoft Anypoint Gateway already comes with security policies that DevSecOps teams can readily implement. Salesforce is now adding the ability to apply custom policies that DevOps teams can apply as it becomes apparent cyberattacks against APIs are becoming more sophisticated, noted Egan. Those policies can, for example, be used to remove sensitive data or replace it with a token, he added.

Responsibility for API security is often not well established in many organizations, but as more accountability for API security shifts left toward DevSecOps teams, there is growing interest in addressing the issue as code when APIs are developed and deployed. While cybersecurity teams are responsible for maintaining cybersecurity after APIs are deployed, few of them have any insight into how an API is crafted. That’s a significant issue because cybercriminals have become more adept at both exfiltrating data via external facing APIs in addition to manipulating the underlying business logic to compromise a digital process, noted Egan.

The Mulesoft Anypoint Gateway automates the process of building and applying security policies to APIs as part of the software development life cycle (SDLC) in a way that minimizes any impact on developer productivity, he added. That approach provides the added benefit of reducing the level of cognitive load developers would otherwise experience if they had to manually create software policies, said Egan.

In general, most APIs are internally facing, but it’s not uncommon for them to suddenly be exposed to the internet as application use cases evolve. The best way to ensure API security is at the point of creation. Providing developers with API security tools gives them an opportunity to address security issues at the beginning of the application development process.

There have already been several cybersecurity breaches involving APIs in the past year. It may only be a matter of time before there are additional breaches that could prove catastrophic. Regardless of the size of the API breach, the application development team that created and deployed the API in the first place is ultimately going to be held accountable for fixing it. The challenge is to find the simplest way to eliminate the issue in the first place at a time when the number of APIs being built and deployed only continues to explode.

February 6, 2024
Graylog Makes Free API Security Tool Available to Developers

Graylog this week made available a free version of its platform for securing application programming interfaces (APIs), intended to encourage developers to adopt best practices to secure them.

The free version of Graylog API Security has all the capabilities of the paid version but is limited to 16GB of local rolling storage on a single node with a one-year renewable license.

Graylog CEO Andy Grolnick said the goal is to make it simple for developers to use this edition of the platform as they are building APIs. As applications are deployed in a production environment, the expectation is organizations will then need to access the version of the platform that is designed to scale, he added.

Based on technology Graylog gained with the acquisition of an API security platform originally developed by Resurface.io, this free version of Graylog’s API security platform is trying to help bridge the divide between the application development teams that create APIs and the cybersecurity teams tasked with protecting them, said Grolnick.

Capabilities of the platform include API classification, discovery, risk scoring, an ability to capture API request and response payloads and continuous monitoring of API and threat signatures in real-time. Collectively, these capabilities enable Graylog API Security to provide high-fidelity alerts using a data lake that is embedded in the platform, noted Grolnick.

That approach enables Graylog API Security to capture all API requests and response details to distinguish valid API traffic from malicious activity involving, for example, data exfiltration hiding under valid response codes.

In addition, Graylog API Security automatically surfaces remediation guidance for developers who typically lack cybersecurity expertise.

API security has become a major DevSecOps issue because cybercriminals are increasingly targeting APIs to steal data. As more externally facing APIs are deployed, the overall size of the attack surface that needs to be defended increases exponentially.

A recent survey conducted by Enterprise Strategy Group (ESG) on behalf of Graylog found more than three-quarters of respondents (76%) have an average of 26 APIs per application. Most respondents are using open APIs for public consumption (67%) or are connecting applications with partners (64%).

In general, most of those APIs are internally facing, but it’s not uncommon for those APIs to suddenly be exposed to the internet as use cases for applications evolve. The challenge is that few cybersecurity teams have visibility into APIs that, when manipulated by malicious actors, can expose code or provide a mechanism through which business processes can be compromised. This issue often exists because, in many organizations, it’s still not clear who is actually responsible for API security.

Arguably, the best way to ensure API security is at the point of creation. Providing developers with API security tools gives them a chance to do the right thing from the beginning of the application development process, said Grolnick.

There have already been several cybersecurity breaches involving APIs in the past year. It may only be a matter of time before there are additional breaches that could prove catastrophic. Regardless of the size of the API breach, the application development team that created and deployed the API in the first place is ultimately going to be held accountable for fixing it.

February 2, 2024
Will the Rise of Generative AI Increase Technical Debt?

In the last year and a half, we’ve seen a glut of new generative AI-related tools reach the market. Various AI pair programmers powered by large language models (LLMs) are becoming integrated into software development environments. The number of new generative AI startups is staggering, and generative AI seems to be the new “catch-all” to accelerate software development and operations.

In this new paradigm, AI tooling accumulation seems inevitable. Yet, the explosion of new AI APIs, libraries and frameworks has the very real potential to increase technical debt and, in the process, overwhelm DevOps teams. “These new applications and capabilities will require many new MLOps processes and tools that could overwhelm any existing, already overloaded DevOps team,” said Bob Quillin, vFunction chief ecosystem officer.

Below, we’ll consider if and how new generative AI tooling has the potential to exacerbate technical debt. Notably, the rush to adopt AI, shifts in the AI tooling landscape and accelerated code output could all be producers of technical debt. Choosing your tools correctly, iterating thoughtfully and upskilling teams will be important guidelines to mitigate negative outcomes. That, and creating unique solutions to ‘flip the coin’ — using AI to consolidate code and reduce existing technical debt.

How AI Will Contribute to Technical Debt

The rise of generative AI-related tools will likely increase technical debt, both due to the rush to hastily adopt new capabilities and the need to mold AI models to suit specific requirements. “New LLMs and generative AI applications will undoubtedly increase technical debt in the future, or at a minimum, greatly increase the need to manage that debt proactively,” said Quillin. “It starts with new requirements to continually manage, maintain, and nurture these models from a broad range of new KPIs from bias, concept drift, and shifting business, consumer, and environmental inputs and goals,” he said.

Incorporating AI may require a significant upfront commitment, leading to additional technical debt. “It won’t be just a build-and-maintain scenario, but rather, the first of many steps on a long road ahead,” said Prince Kohli, CTO of Automation Anywhere. Product companies with a generative AI focus must invest in creating a data and model strategy, a data architecture to work with AI, controls for the AI and more. “Technology disruptions and pivots such as this always lead to this kind of technical debt that must be continually paid down, but it’s the price of admittance,” he said.

AI is a tumultuous space, and some degree of technical debt will likely be produced by future organizational shifts. “The pace of change and innovation in the AI field itself is exceedingly rapid,” said Juan Orlandini, CTO of Insight North America, citing the staggering emergence of new AI startups and tools. “There will be consolidation, and also, unfortunately, a number of the startups will cease to exist.” When this occurs, teams must grapple with unsupported packages or tools.

Another type of debt is the nature of AI and how it accelerates development across the board. “One of the great values of these tools is the acceleration they bring to development,” said Orlandini. “Simply put, we can put out more features faster.” The other side of this double-edged sword is that AI accelerates the creation of all programming endeavors, even those that become technical debt.

Generative AI-related tools are most likely to accelerate the pace of change and deliver new code development outcomes more quickly. “In the process of consuming their output, there is a possibility of accumulating technical debt if the usage is broad, rapid, and pursued indiscriminately,” said Ajay Sabhlok, CIO and CDO, Rubrik. “Developers, in this case, may be too focused on program execution and forget to pay attention to code complexity, repetition or use of non-standard logic.”

Ways to Mitigate AI Technical Debt

Thankfully, there are specific methods organizations can adopt to manage new technical debt. For starters, you should focus on creating smaller proof of concepts and then iterating as you learn, said Kohli. “When leaders like the head of technology or IT are deploying these processes, they should first create small agile teams that learn fast and disseminate those learnings efficiently,” he said.

Also, technical debt is more likely to accrue when the wrong platform or tool is chosen. Therefore, “organizations should be very deliberate in choosing what products to leverage,” said Orlandini. He encourages IT leaders to avoid relying on companies or products with flashy presentations and poor tech or great tech with poor business acumen. “Our industry is rife with stories of great products with terrible business plans — which ultimately leads to their demise,” he said.

Other experts similarly foresee upcoming shifts that may affect internal operations. “Companies should keep their options open when considering AI model vendors or tool providers,” said Kohli. “They must keep their ‘hands on the wheel’ and be prepared for turns.”

Just like any new technological adoption, generative AI requires forethought. Therefore, putting the same amount of planning and preparation into deploying generative AI as we do for developing coding standards around manual coding could help minimize technical debt, said Sabhlok. “It will help to ease into areas of usage by adopting a tiered approach to expansion and, at each step of the way, review the results against standards, compare notes across the development organization, and course correct where necessary. This can avoid the accumulation of technical debt in the long run.”

“IT leaders should first ensure that additional resourcing and training are in place to both upskill existing teams and hire new talent as required,” said Quillin. “This includes adding observability tools that can identify new and existing forms of architectural and LLM drift. Finally, to always be ready for any new, rapidly emerging future requirements and opportunities, IT leaders should invest in best practices and tools that will proactively keep their app architectures clean and ready for the ‘next big thing.’”

How AI Could Decrease Technical Debt

On the other hand, some believe that if used properly, the contrary is true — that new AI technologies will actually reduce technical debt. “The rise of LLMs, frameworks, and APIs, when applied properly together, will actually reduce technical debt,” said Ashwin Rajeeva, CTO and co-founder of Acceldata. “Code discovery and reuse is more easily accomplished with LLMs.” He points to the ability of this technology to identify duplicative code and consolidate it into a more streamlined interface.

Automated documentation generation is another area where LLMs could help improve code discovery and reduce duplicative efforts. In addition, LLMs could also help reduce the prevalence of code that doesn’t follow company standards, said Rajeeva. “It is much easier for LLMs to understand the company standards by learning from good coding practices and applying it to newly written code.”

Others also see the power of using generative AI to enhance automation across the board. “AI tooling is probably going to help the most in automation, velocity to transform old codebases, and empowering non-coders to accelerate the adoption of new business processes into their workflows,” said Orlandini.

Final Thoughts

AI is a multifaceted subject, and its use could go one of two ways. On one hand, if not used correctly, generative AI could only add to the surmounting technical debt pile. To avoid this outcome, organizations will likely need guardrails on when and how to use LLMs, said Rajeeva. He also advocates “making it a best practice within the corporation with sufficient training for newer developers.”

Then, on the other hand, generative AI could be utilized to respond to technical debt. It has the awesome potential to unlock automation gains and enhance employee satisfaction and retention, especially within older industries that may be behind the technological curve, said Kohli. “With AI and now generative AI, intelligent automation can deliver on all those promises such that it is fast becoming a new pillar of enterprise architecture.”

So, take the new wave of AI with a grain of salt. It will open up immense solutions but will also come with a significant degree of technical debt. Thankfully, there are ways to manage debt caused by AI in a way that can benefit operations and push development objectives forward.

January 25, 2024
How Supergraphs Help Consolidate Data Access
GraphQL, a query language for APIs, has become more of a common tool for new web-based development. GraphQL can help streamline data access by providing all the resources a developer requires in a single request. Compared to the traditional REST approach to web-based data access, GraphQL has a more standardized and traversable schema and arguably better developer experience.

But GraphQL is not just great for improving developer usability for a single data model. If used to aggregate various data sources and APIs into a unified graph, GraphQL could become ‘one schema to rule them all‘ for enterprises. Some refer to this architecture as a supergraph.

I recently caught up with Tanmai Gopal, CEO of Hasura, to explore the concept of a supergraph and see how it can help make data more accessible for enterprises. Below, we’ll consider the expansion of the supergraph concept and what the benefits are of deploying such a strategy.

Understanding the Need for Supergraphs

In large software architectures, product teams need access to various data sources from different domains. “There is a need for integrative experiences, which are becoming more and more important for the end user,” explained Gopal. For instance, an e-commerce application might be composed of product catalog data, login functionality, payment data, shipping information and other necessary information.

However, there are hurdles in the way of pulling in data from these multiple domains. Different domains are often built as microservices, supported by a dedicated team and using a bespoke developer portal and API schema to externalize the services, said Gopal. The friction involved in API integration and the lack of a common registry of services could slow down development.

Not only do microservices that expose discrete endpoints have issues, but the lines between internal and external are blurring, necessitating a zero-trust approach. And if we begin to consider data as a product, explained Gopal, we need to access multiple domains in a secure, consistent and scalable way.

Benefits of Adopting GraphQL and Supergraph

A supergraph can solve some of these difficulties, explained Gopal. By exposing graphs from different domain services, you can automatically unify data into a supergraph, which could be accessed from various teams. And the great thing about using GraphQL is that the act of documenting is the act of building the API, meaning that the description and schema are more standardized.

By composing disparate services into a centralized registry, you could work across domains in a systematic but federated way, said Gopal. Implementing a layer here could also be a good area to enforce role-based identity or authentication.

Andrew Carlson, principal field architect at Apollo GraphQL, similarly proposed using GraphQL to centralize data access control. “When used as a layer to aggregate and orchestrate existing APIs,” Carlson said. “It’s an ideal location in our architecture to centralize access control and authorization down to the field level, providing field-level observability into which clients request what data.”

Gopal shared a handful of other specific advantages for using GraphQL in this context:
- Helps you write less code: Since GraphQL enables you to fetch whatever field you want, aligning on GraphQL as a common interface could reduce the number of requests required to integrate data. Also, certain developer experience perks, such as auto-complete, could enhance schema discoverability and have exponential benefits when sources are intertwined in a combined graph.
- Increases agility for new development: The need to quickly understand the overall schema and what it looks like is becoming especially relevant, especially for AI applications, said Gopal. There’s a massive agility boost when using a supergraph schema, he added, such as enabling software teams to fetch the context they require to quickly put things into motion.
- Improves data and service discoverability: Software teams are facing tooling sprawl, and the number of APIs in use within an organization keeps increasing. A supergraph can enable a traversable data mesh, greatly aiding discoverability and, in turn, the ability to innovate. “The benefit from the ability to understand and use data from different domains is massive,” said Gopal.
- Unifies teams from various domains: Another potential benefit of the supergraph concept is improved inter-departmental collaboration. Helping teams work together could enhance reporting and reduce risk. This new shared operating model helps to clean things up when updating code and the schema, said Gopal.
Next Step: Protocol Agnosticism

The idea of wrapping disparate data sources and formats in a standard, unified layer is an alluring concept. “The agility impact is massive,” said Gopal. Especially, he adds, if you have the ability to automate the creation of a supergraph around various styles of legacy databases.

However, investment into a supergraph can be time-intensive. The benefits are unlocked down the line, but you will need an internal champion to initially advocate for it and bring it to fruition, he cautions. Furthermore, enterprises may face hesitancy in going all-in on GraphQL due to past investments in other technology types.

While GraphQL is becoming more popular, various API styles are still commonly applied and will continue to be supported for some time. For instance, a 2023 study by API management and testing company Postman found that GraphQL use had eclipsed the mainstay API format of SOAP. Yet, REST is still the dominant API style, used by 86% of respondents, followed by Webhooks (36%), GraphQL (29%) and SOAP (26%).

As such, the next step is for the supergraph to be agnostic to GraphQL, said Gopal. Instead, it should be able to work with various protocols since most enterprises are utilizing multiple styles.
January 11, 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: ‘Scrum == Cancer’ ¦ Plus: Linux 6.5 Ships

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.

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

This week: Scrum sucks, sources say; and here comes the Linux 6.5 kernel. (more…)

December 29, 2023
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
Microsoft kills Python 3.7 ¦ … and VBScript ¦ Exascaling ARM on Jupiter

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

This week: VS Code drops support for Python 3.7, Windows drops VBScript, and Europe plans the fastest ARM supercomputer. (more…)

October 11, 2023
Raspberry Pi 5: Faster, Better, Stronger — Spendier

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

In a cheeky extra post this week: Everyone’s favorite single-board ARM computer, the Raspberry Pi, has a new generation coming soon. Compared to the ’4, RPi5 has double the performance, quadruple the base RAM and far more capable I/O. (more…)

September 29, 2023
Teleport Assist Leverages Generative AI to Democratize DevOps

Teleport has made available a chat interface, dubbed Teleport Assist, that makes use of OpenAI’s generative artificial intelligence (AI) application programming interfaces (APIs) to enable DevOps teams to troubleshoot infrastructure issues more easily.

Using the natural language interface (NLI) provided by Teleport Assist, DevOps engineers can ask questions and give instructions in English to massive fleets of servers. Capabilities include being able to suggest commands and scripts for debugging and resolving common issues and then generating commands for review before they are applied.

In future versions of Teleport Assist, support for other cloud resources, such as SQL databases and Kubernetes clusters, will be added. Teleport Assist currently supports Secure Shell (SSH) and bash scripts, with support for additional languages and interfaces to be added over time.

Teleport CEO Ev Kontsevoy said it’s already clear that many of the scripts that DevOps engineers rely on today for IT management will be replaced by generative AI platforms. The average IT administrator will be able to invoke DevOps platforms via an NLI that eliminates the need for extensive programming expertise, he added.

In effect, the NLI surfaced by generative AI platforms will serve to democratize DevOps expertise, Kontsevoy noted.

It’s still early days as far as the adoption of generative AI by DevOps engineers is concerned, but it’s already apparent that its impact will be profound. It will increase the pace at which applications are built while making it easier for software engineers to manage large codebases. Most of the generative AI advances thus far improve developer productivity, but tools such as Teleport Assist show how generative AI will also make it easier for more organizations to adopt DevOps best practices that previously were limited to organizations that could afford to hire and retain significant numbers of software engineers.

At their core, generative AI platforms are fundamentally changing the way humans interact with machines. Instead of requiring a developer or engineer to create a level of abstraction to communicate with a machine, it’s now possible for machines to understand the language humans use to communicate with each other. A a natural language interface will soon enable DevOps engineers to ask generative AI platforms to not only surface suggestions but also debug applications and even write code. The accuracy and quality of those results will vary depending on how the large language models (LLMs) that trained those platforms were, but over time there will be a wide range of LLMs that are trained to be used within specific domains such as DevOps.

The issue is determining how to organize DevOps teams as more tasks become automated. Generative AI doesn’t replace the need for IT professionals, but it does make it simpler to manage IT at unprecedented levels of scale. In fact, at this point, the proverbial generative AI genie is out of the bottle, so there is no going back. The only thing left to decide is how quickly generative AI becomes pervasively applied.

August 11, 2023