devopsy.kinsta.cloud

Tag: distributed applications

  • DevOps is Making Gains on Mainframe Platforms

    DevOps is Making Gains on Mainframe Platforms

    A survey of 800 executive and technical professionals conducted by BMC found close to two-thirds (62%) are employing DevOps workflows to build and deploy applications.

    In addition, the survey also finds that just under a third of respondents (32%) are applying artificial intelligence to IT operations (AIOps) across all platforms.

    John McKenny, senior vice president and general manager of intelligent Z optimization and transformation at BMC, said the survey shows that organizations continue to invest in mainframe applications alongside distributed computing environments.

    In fact, 61% of respondents noted that data volume on mainframes increased in the last year, with 56% reporting an increase in the number of databases running. Well over a third of respondents (35%) also reported increased interest in taking advantage of cloud technologies to handle, for example, storage and data protection.

    Overall, the survey found that 94% of respondents have a positive perception of the mainframe, with nearly two-thirds (63%) reporting increased mainframe investments over the past year.

    Compliance and security lead the list of priorities for mainframe organizations, with 61% of respondents citing these as top issues, followed by cost optimization (49%), enhancing automation (41%) and data recovery (40%).

    In general, organizations with mainframes are adopting modern application development tools such as VS Code to attract a younger generation of developers. It’s critical to continue to attract developers to mainframe platforms that continue to run the most mission-critical applications in the enterprise, said McKenny. Many of those applications are being modernized using DevOps tools and practices rather than being moved to another platform, he added.

    He added that the appetite for using generative artificial intelligence (AI) to write code for mainframe applications is less clear because of intellectual property concerns. Most organizations are not going to want to expose their mainframe code to a general-purpose large language model (LLM) that drives a public generative AI platform, but there will be a role for private LLMs that are trained using code that has been validated, noted McKenny.

    Regardless of how generative AI evolves, there’s still much work to be done to further the adoption of DevOps best practices in mainframe environments. Each organization will determine how stringently to apply those practices based on the frequency at which applications running on mainframes need to be updated. In most cases, organizations with mainframes will use a mix of waterfall and DevOps-based approaches to building and deploying applications for many years. The decision as to which approach to employ will, naturally, have as much to do with culture as it does the rate at which the application needs to be built and deployed to drive, for example, a digital business transformation initiative.

    The days when mainframes were managed in isolation from the rest of a distributed computing environment are slowly coming to an end. A mainframe is, arguably, just another node for deploying applications. The challenge and the opportunity now is getting the right DevOps tools in the hands of the IT team managing heterogeneous IT environments, including mainframes.

  • You’re Already a Distributed Developer

    You’re Already a Distributed Developer

    For many coders, the idea of distributed systems development might seem like a dark art. They think of high-performance computing wizards crafting mysterious spells with job schedulers to work magic with hundreds of connected nodes in massively-parallel systems. Or large, distributed content delivery networks that balance resources to deliver content across the world no matter how high the demand. The folks doing those jobs have often worked in specialist distributed computing environments for years. But the complex problems they face at a massive scale aren’t so different from those that you deal with every day. In short, you’re a distributed developer too. It’s just that no one bothered to tell you.

    Everything is Distributed

    The world is a lot more distributed today than it used to be. Back in the day, code would talk directly to one mainframe or microcomputer, generally on the same LAN. Your PDP-11 and your batch order processing software had an intimate, exclusive kind of relationship.

    Computing environments began to change with the advent of open computing in the late eighties. It ushered in the era of multiple computers working together other over a network. The concept continued to evolve beyond PCs. Now phones, servers and smart kettles all expect an easy way to talk to each other.

    Today, distributed operation is so ubiquitous that people barely see it happening. When you type anything into a browser, it fires off dozens of queries to different backend systems owned by different organizations. These systems generally run on different infrastructure.

    Even a small application that makes a database query is a distributed system. The application often talks to a system—or even multiple systems—halfway around the world.

    Many apps these days are compositions of multiple API calls to different online services. When a developer gathers weather data from a service provider and feeds it into a cloud-based online geographical information system that decides how much to irrigate crops in Iowa tomorrow, what is that if not a distributed query?

    Software is becoming more distributed over time. As software became more complex, developers have long wanted to carve it up into smaller pieces. This began in earnest with the software component movement around CORBA in the mid-to-late nineties, gravitating to XML web services in the early noughts and then to RESTful APIs. All of these involved forms of remote procedure call to increasingly granular services.

    In the last decade, this atomization of monolithic software has become the norm rather than the exception. Container-based architectures ushered in the use of microservices for better development agility and maintenance. Most developers that started their careers in the last five years or so will have been forced to think about how these services communicate from the outset. Distributed design patterns are a fact of everyday life.

    And it’s Still Difficult

    While your distributed applications might not be as complex as those facing HPC and hyperscale services, they still come with some challenges that increase as systems become more granular. What happens if a remote API takes longer than expected to deliver a result because it is overloaded, meaning that API queries to different systems arrive in a different sequence than expected? How should you react if a network or system outage or an expired access key prevents an API from responding at all?

    Problems like these arise unexpectedly, meaning that you have to get more creative with code from the outset. Good developers do more than master object-relational mapping and send queries. They program defensively to ensure that their programs retry steps when a failure somewhere else delays that job or stops it altogether.

    There are different design patterns to handle most common distributed programming scenarios today, even though you might not think of them as such. For example, developers have been building load-balancing code into their applications for decades, distributing requests between different servers to maintain performance.

    Anyone who has tried to maintain transaction integrity when writing to multiple databases will also have dabbled in two-phase commit design, which ensures that all of the databases get updated (or that none of them do).

    The more experienced you get, the more complex and esoteric these patterns become. At some point, many developers move beyond basic CRUD models in their applications to handle more complexity when reading and writing data. For example, they might read data from a website in one format but collapse multiple records into one when writing data to the website’s back-end store. That means writing code that creates different types of read and write queries. That pattern, called command and query responsibility segregation (CQRS), is also a form of distributed programming.

    Then, there’s the Saga pattern, which people use to maintain application state across long-running processes comprising multiple transactions. This pattern relies on an event bus along with messaging and queuing code to handle services with unpredictable delays in response times. It ensures that the overall process transaction finishes in an acceptable state or rolls back.

    As you venture into more sophisticated patterns that hold transactions together while maintaining performance, you’ll find your code becoming more complex and, therefore, application development becoming more difficult. Such is the life of a distributed developer, even if you didn’t realize that you were one until now.

    Gaining this knowledge and experience as a developer is important, but once learned the hard way, you don’t have to keep doing it manually. There are technology solutions that manage some of these complex distributed patterns for you. As the volume of plumbing code to support distributed design patterns increases, so does the need to offload it. In an industry increasingly built on abstraction, it’s time to turn distributed systems management into a separate service and unburden your code.

    And—if you’re looking for an example platform specifically designed to address this issue—check out Temporal, a completely open-source (MIT license) microservice orchestration platform which enables developers to build scalable applications without sacrificing productivity or reliability.

     

  • Deploying a Service Mesh: Challenges and Solutions

    Deploying a Service Mesh: Challenges and Solutions

    A service mesh is a dedicated infrastructure layer that enables communication between microservices in a distributed application. It helps to abstract the underlying communication infrastructure, such as network protocols and load balancing and provides a consistent interface for microservices to communicate with each other.

    In a service mesh, each microservice in the application is represented as a “service” within the mesh, and the mesh acts as a proxy between the services, routing requests and responses between them. It also includes a control plane, which manages and configures the proxy instances and provides observability and monitoring capabilities for the services.

    Some of the benefits include:

    • Improved observability: A service mesh provides visibility into the communication between microservices, which can be helpful for debugging and monitoring the performance of the application.
    • Resilience: It can help to make microservices more resilient by providing features such as retries, timeouts and circuit breakers, which can help to prevent cascading failures.
    • Security: A service mesh can help to secure communication between microservices by providing features such as mutual TLS (mTLS) and rate limiting.
    • Ease of use: It provides a consistent interface for microservices to communicate with each other, which can make it easier for developers to build and manage distributed applications.

    Why is a Service Mesh Important?

    A service mesh is important because it helps to abstract the underlying communication infrastructure for microservices-based applications, which can make it easier for DevOps teams to build and manage these types of applications.

    One of the main benefits is that it provides a consistent interface for microservices to communicate with each other, which can make it easier for developers to build and manage distributed applications. For example, a service mesh can provide features such as load balancing, retries and timeouts, which can be useful for ensuring the resilience and reliability of the application.

    It can also help to improve observability for microservices-based applications by providing visibility into the communication between the microservices. This can be helpful for debugging and monitoring the performance of the application, which can, in turn, make it easier for DevOps teams to identify and resolve issues more quickly.

    What are the Main Deployment Challenges?

    There are several key challenges that a DevOps organization may face:

    • Complexity: Service meshes can be complex to set up and manage, especially in large, distributed applications. This can make it challenging for organizations to implement and ensure that it is configured correctly.
    • Operational overhead: Service meshes can add a layer of complexity to the application stack, which can increase the operational overhead of managing the application. This can be especially challenging for organizations that are not used to operating one.
    • Cost: While service mesh software is typically open source, the need to run a sidecar container alongside every container can increase the compute capacity needed to run a Kubernetes cluster.
    • Integration with existing systems: They can be difficult to integrate with existing systems and processes, especially if the organization has not previously used a service mesh. This can make it challenging to get the full benefits.
    • Lack of expertise: Service meshes are relatively new technologies, and there may be a lack of expertise within the organization. This can make it challenging for organizations to get started and ensure it is used effectively.
    • Performance overhead: Service meshes can add a performance overhead to the application as they introduce an additional layer of proxying between microservices. This can make it challenging to ensure that the application is performant and scalable.

    Best Practices to Ease Service Mesh Pain

    Here are a few best practices that can turn service mesh deployments from a pain to a pleasure.

    Use Configuration-as-Code in a GitOps Approach

    Using configuration as code in a GitOps approach is a best practice to improve reliability and maintainability.

    GitOps is a way of managing infrastructure and applications using Git as the single source of truth. In a GitOps approach, all configuration and deployment information is stored in Git, and changes to the infrastructure and applications are made by committing code changes to Git.

    Using configuration-as-code in a GitOps approach can help to improve the reliability and maintainability of the service mesh in several ways:

    • Version control: Storing configuration-as-code in Git allows you to track changes to the service mesh configuration and roll back changes if necessary. This can help improve the service mesh’s reliability by making it easier to identify and fix issues.
    • Collaboration: Git allows multiple people to work on configuration at the same time, which can make it easier to collaborate on changes and ensure that the service mesh is properly maintained.
    • Automation: GitOps approaches often use automation tools, such as continuous integration and delivery (CI/CD) pipelines, to automatically deploy changes to the service mesh when code is committed to Git. This can make it easier to manage and maintain and can help to improve its reliability by reducing the risk of errors.

    Focus On Developer Experience

    Ensuring a positive developer experience is a best practice because it can help to improve the productivity and effectiveness of the development team. A positive developer experience means that developers can easily understand and use the service mesh, and that it does not introduce unnecessary complexity or frustration into their workflow.

    Here are some ways to improve the developer experience:

    • Provide clear documentation: It is important to provide clear and comprehensive documentation on how to use the service mesh, including examples and tutorials. This will make it easier for developers to understand and use.
    • Integrate with existing tools and processes: The service mesh should integrate seamlessly with the existing tools and processes that the development team is already using. This will help to minimize disruptions to the team’s workflow and make it easier for them to work with.
    • Provide support and training: It is important to provide support and training to help developers understand and use the service mesh effectively. This can include online resources, in-person training, and support from the vendor.

    Reduce Costs With Low-Cost Cloud CPUs

    A service mesh increases the cost of an entire containerized deployment because it requires deploying a sidecar container alongside all workloads. When running on Amazon Web Services (AWS), the AWS Graviton processor can ease deployment by reducing the cost of running service mesh infrastructure.

    The AWS Graviton processor is a custom ARM-based processor designed specifically for use in Amazon Web Services (AWS) environments. It is optimized for running workloads commonly found in the cloud, such as microservices and containerized applications.

    Using the AWS Graviton processor can help to reduce the compute costs of a service mesh because it is generally less expensive than other processors, such as Intel Xeon processors. The AWS Graviton processor is also designed to be highly efficient, which can help reduce the service mesh’s overall resource utilization. This can help to reduce the cost.

    Choose the Right Control Plane

    Choosing the right control plane is a best practice because it can impact the performance, reliability and maintainability of the service mesh. The control plane is the central component that manages the proxy servers and enables you to configure and monitor the communication between microservices.

    Here are some considerations for choosing a good control plane:

    • Compatibility: It is important to choose a control plane that is compatible with the rest of the service mesh infrastructure, as well as with the application and its dependencies. This will ensure that the control plane can operate effectively and support the needs of the application.
    • Performance: The control plane should be able to handle the traffic and data volumes of the application without experiencing performance degradation. It should also be able to scale up or down as needed to meet changing demand.
    • Reliability: The control plane should be reliable and able to withstand failures without interruption. It should also provide features such as circuit breaking, retries and timeouts to help improve the resiliency of the service mesh.
    • Ease of use: The control plane should be easy to use and understand, with clear documentation and a user-friendly interface. This will make it easier for the DevOps team to manage and maintain the service mesh.
    • Integration with other tools: It is important to consider how the control plane integrates with other tools and systems, such as monitoring and logging tools, and how it can be integrated into the overall workflow of the organization.

    Conclusion

    In conclusion, deploying a service mesh can be a complex and challenging process, but it can also provide significant benefits in terms of improving the reliability, scalability and security of a cloud-native application. 

    Some of the key challenges include complexity, operational overhead, integration with existing systems, lack of expertise and performance overhead. 

    To overcome these challenges, it is important to choose the right service mesh, use configuration-as-code in a GitOps approach, choose the right control plane and ensure a positive developer experience. By addressing these challenges and following best practices, organizations can successfully deploy a service mesh and reap the many benefits it has to offer.

    Image Source 

     

  • Cosmonic Previews Deployment Platform for Distributed Wasm Apps

    Cosmonic Previews Deployment Platform for Distributed Wasm Apps

    Cosmonic has made available a preview of a platform for deploying applications built using the portable WebAssembly (Wasm) binary format that enables applications to be deployed on any platform.

    Cosmonic CEO Liam Randall said the company is providing early access to the Cosmonic Platform Developer Preview platform to enable developers to experiment with a new type of software artifact that will be used to build a new class of cloud-native applications.

    The Cosmonic Platform Developer Preview platform is based on wasmCloud, an open source application runtime that hosts components written as Wasm modules that can then be loosely connected to build applications. Originally developed under the auspices of the World Wide Web Consortium for building browser applications, Wasm is a portable binary instruction format for building software that describes a memory-safe, sandboxed execution environment.

    That approach replaces the current predominant method for building software that relies on the aggregation of software components that tend to lack distinct boundaries. It’s that lack of distinct boundaries that enables malware to flow so easily from one software module to another. The wasmCloud runtime, originally developed by Cosmonic, provides a platform for deploying distributed Wasm applications and is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF).

    Prior to Wasm, Randall noted, every format for building applications led to the creation of ‘walled gardens’ that resulted in developers being locked into a platform. Wasm is the first software artifact that enables applications to run on an platform, including Linux and Windows, without any modification required, said Randall.

    It may be some time before Wasm becomes the preferred artifact for building applications, but it’s clear the walls that have separated one IT platform from another are about to crumble. Once applications become much more portable, the longstanding goal of writing an application once and then deploying it anywhere may finally be achieved. Just as importantly, those applications will run in a memory-safe sandbox that is more secure than what can be enabled in legacy IT platforms. In fact, as more organizations review the security of their software supply chains, they may decide to accelerate their embrace of Wasm to build more secure applications.

    Naturally, the transition to Wasm will have major implications for DevOps teams, as it represents an opportunity to streamline deployment processes across multiple platforms. In effect, the total cost of application development and deployment would decline as processes spanning multiple platforms become more automated using platforms such as wasmCloud. Ultimately, much of the infrastructure complexity that developers need to navigate today would be eliminated, noted Randall.

    It’s not clear just yet to what degree Wasm will drive a transition to another era of computing, but the potential to change almost every aspect of IT is on the horizon. Ultimately, the issue will be decided by how quickly developers are willing to embrace yet another software artifact for building and deploying applications. What is clear is that the number of platforms that will make it possible to experiment with Wasm are starting to multiply.

  • Not Totally Buying Web3? You’re Not Alone

    Not Totally Buying Web3? You’re Not Alone

    The interest in Web3 is heating up. We’ve seen major excitement around blockchain and new Web3 protocols that are poised to reinvent the web as we know it. But it’s hard to hide the skepticism and the suspicion that there are ulterior motives behind large cryptocurrency coin fundraisers. There’s no doubt that there are benefits to the Web3 movement — the decentralized nature of Web3 brings innovative forms of shared ownership. Yet, both the marketing hype and investment fervor could get in the way of actual progress in the industry.

    I recently met with Netlify CEO Matt Biilmann to discuss the missing piece of Web3. For those who don’t know, Netlify has been a big proponent of the JAMstack movement, a design style incorporating JavaScript, APIs and Markdown (hence, JAM). The headless approach decouples the frontend and backend, enabling easier multi-platform support and other benefits.

    According to Biilmann, the theory behind Web3 is exciting and sound and it fits into the headless movement quite well. Yet, in practice, Web3 will require more emphasis on interoperability and open standards, said Biilmann. Without inter-chain portability and better data control, the trend will likely fall victim to the same walled gardens and centralization that underpins the current web. There are some other concerns to keep in mind about Web3 and blockchain, which we’ll explore below.

    Back to The Open Web

    First off, what exactly is Web3? Well, Web3 is a broad term with loosely-related phenomena, but it can be summed up as a new web designed with decentralized technology and built on blockchains with distributed ownership. “There’s a general sense behind the Web3 movement that goes back to roots of the web as a non-centralized entity,” explained Biilmann.

    Whereas in Web2 users were participating in someone else’s walled garden, the concept behind Web3 is that it’s fundamentally open. But how do we make more pieces of the stack a collaborative standard with no single owner? According to Biilmann, this is the aspect that the industry should expand upon.

    Issues With Web3

    There’s a lot of speculation. One big issue Biilmann foresees with Web3 is the rampant speculation. The long-term success of new Web3 projects founded on a blockchain is muddled by the fact that the creators wanted people to buy in so tokens rise in value. “How much of the underpinnings of Web3 are actually solving real problems and how much is pure speculative investment?” he asks. It’s not always apparent whether, behind their flashy, chic facades, blockchain solutions solve real problems.

    A lack of inter-chain interoperability. A lack of interoperability between the many emerging flavors of blockchain could also pose a risk to this fledgling space. “To what degree are they actually building things around standards with the possibility to move from one player to the other?” asked Biilmann. “We need open standards where you can migrate from one to the other.”

    Centralization still exists. No matter what the copy around decentralization said, there will still be players who hold more control and power in a capitalist economy. According to Biilmann, it will be important to make platforms fundamentally open and extendable to avoid creating more walled gardens. He admitted that having strong central providers is not a huge problem as long as these open platforms provided interoperability.

    A lack of identity portability. When a person owns a web domain, they can move content around freely from server to server. In a similar vein, Biilmam believes that comparable freedom is necessary for identity within Web3. The ideal is to increase ownership and portability of one’s digital identity. Yet, Biilmann questioned whether blockchain is the best vehicle for that goal, especially as competing blockchain protocols could interfere with portability.

    Blockchain will still hinge on the authority of an external source. Another issue is how blockchain will interface with reality. Often, a smart contract will point to a URL for an off-chain context without a strict guarantee of what’s happening outside of the chain. If blockchain must depend on the authority of an external source, this is somewhat counter to the ideals of an interdependent network. “Most of the time, you have to trust a provider between what happens in blockchain and what happens in the outside world,” explained Biilmann. In this scenario, the integrity of the blockchain could end up revolving around a single entity.

    Connecting blockchain to the outside world is hard. On that note, the exact process for interfacing with off-chain constructs is still being developed. This usually relies on a third-party oracle model, although some headway has been made to eliminate the oracle concept in favor of a more modern standard for integrating off-chain computations.

    Every operation incurs high processing costs. Blockchain requires excessive processing power to accomplish simple tasks, which can be wasteful at scale both in monetary and resource terms.

    The benefits of NFTs are greatly exaggerated. NFTs won’t likely help the majority of creators. As Kimberly Parker explained, NFT platform sales data showed “an acutely minuscule number of artists making a vast amount of wealth off a small number of sales while the majority of artists are being sold a dream of immense profit that is horrifically exaggerated.”

    NFT scams are common, and since minting an NFT requires exorbitant platform fees, the likelihood of an artist recouping their upfront investment is minimal. “I think that people who stand to gain the most are people like the Winklevoss twins, who are already mega-rich and own an NFT platform,” Cat Graffam said on Time.com. “The biggest losers are the vast majority of unestablished artists that are attempting to break into NFT sales.”

    Keeping Alternative Options On The Table

    “Let’s not jump to the conclusion that cryptocurrencies and blockchain are the solutions,” said Biilmann. As he noted, people have been tinkering with ways to open up identity and data for decades now. These thinkers may also have relevant insights and alternative solutions that shouldn’t be dismissed or ignored.

    For example, Tim Berners-Lee, inventor of the World Wide Web and the HTML programming language, has been spearheading a new initiative called Solid. Solid is a “proposed set of conventions and tools for building decentralized social applications based on linked data.” The project’s goal is to enable true data ownership and better privacy. “If we’re after the goal of an open web, we should be just as curious to know what they’ve been studying for years,” said Biilmann.

    We may be seeing Web3 projects excel simply due to the underlying speculative interest in cryptocurrency, Biilmann said, not that they’re technically the best solution or have the best open ownership model. Other solutions include IPFS for high-volume distributed storage. Or, take DNS, the decentralized naming system at the core of the web—”that part of the existing web is already very open and user-owned,” said Biilmann.

    Goal: Plant Gardens Without Walls

    “I’m excited about this—personally, I hold no grudge about the tech,” Biillmann clarified. “Making identity and underlying data fundamentally more open is awesome.”

    But, at the same time, the space is too speculative and too far removed from building useful things for users, said Biilmann. There is also a pressing need for interoperability and portability in the blockchain industry. And with so much noise driven by the interest in tokens, it could be more beneficial for society to trust a more neutral party in architecting the fabric of our digital lives.

    “It’d be a shame if people forget what we can build already,” said Biilmann, pointing to pre-existing technologies like IPFS and DNS. Although these open standards won’t make early stakeholders rich in the short term, they could help get us to that open state even faster.

    Web3 is still in an early space. And if we separate currency from this ambition, it could deliver tremendous outcomes. “Let’s figure out how we make identity and data open and not tied to specific walled gardens,” said Biilmann. “That’s something we, as an industry, should work toward.”

  • Credit Karma Looks to Open Source Distributed App Platform

    Credit Karma Looks to Open Source Distributed App Platform

    Credit Karma has launched an application platform, dubbed Talon Polly, that makes it simpler to deploy microservices across multiple runtime environments.

    Richard Pounder, principal software engineer at Credit Karma, said the consumer financial services provider expects to make Talon Polly available as an open source project next year.

    Written in the Rust programming language, Pounder said Credit Karma created Talon Polly to provide its developers with a language-agnostic platform for building and deploying applications. Talon Polly can be deployed as a sidecar using containers or as a process running within a software environment.

    While there is no shortage of frameworks for building and deploying software, Pounder said Talon Polly is designed to make it easier for development teams to reuse code and components across multiple applications using, for example, a contract-based library included in the framework. That approach also enables Credit Karma to ensure a common set of security policies are enforced across those application environments, he noted.

    Ultimately, the goal is to enable developers to spend more time writing business logic rather than mastering the nuances of multiple application development frameworks created for specific application environments, said Pounder.

    It’s not clear to what degree other frameworks may emerge to address the same issues at Talon Polly. Odds are good that other organizations that need to deploy distributed applications built using multiple programming languages have faced similar challenges. The Cloud Native Computing Foundation (CNCF) has also adopted Dapr, a set of application programming interfaces (APIs) created by Microsoft that are deployed as container sidecars to make it simpler to build distributed applications, as an incubating project.

    Regardless of approach, the rise of distributed microservices-based applications is creating a significant management challenge for DevOps teams. Each microservice is built by different development teams that prefer one programming language over another for any number of reasons. Deploying and updating those microservices across a distributed computing environment requires more sophisticated orchestration of workflows, given all the dependencies that exist between microservices.

    Of course, it’s not quite clear yet the degree to which microservices-based applications will supplant legacy monolithic applications. Most new applications are being constructed using microservices to make applications more resilient. However, the number of legacy monolithic applications running in existing IT environments means it could be years before microservices-based applications will ever outpace them. As such, DevOps teams will be managing a mix of monolithic and microservices well into the second half of this decade.

    The paradox is that while microservices-based applications are more resilient because calls to services can be rerouted in the event of a disruption, the overall application environment becomes more complex as the dependencies between distributed microservices increases. As such, many organizations are opting to use microservices to build applications only when a certain level of resiliency is required or it’s been determined that a function likely to be used by multiple applications is more easily accessed via a microservice that has its own API.

    One way or another, going forward, it’s not so much a question of whether microservices will be employed but rather to what degree and across how many applications.

  • When to Use API Management and Service Mesh Together

    When to Use API Management and Service Mesh Together

    Though sometimes described as competing architectures, API management and service mesh have slightly different use cases and can actually work well together. Whereas API management provides the business logic for outside-facing traffic, a service mesh excels at handling intercommunication between microservices. An organization could certainly adopt both simultaneously across their projects. So, when does it make sense to use both API management and service mesh?

    I recently chatted with Mark Cheshire, director of product, Red Hat, to discuss the nuances between API management and service mesh. According to Cheshire, API management and service mesh can work quite well side-by-side for particular use cases. For example, a large organization using service mesh could benefit from applying API management that wraps microservices in a usable contract for internal departments. Or, API management could help a company expose specific APIs from the mesh to outside partners.

    When to Combine API Management with Service Mesh

    Say you already have service mesh—do you need API management, as well? Cheshire offered four questions to keep in mind that may influence your decision.

    1. Consider the number of connections and the number of consumers: Is it many-to-one or one-to-many?

    Within a monolithic application, communication is more centralized—there is more of a one-to-one relationship. However, when you break apart services into microservices and reuse them across an organization, a service may now have many consumers. This is a good indication you need an API management approach for the interface.

    “When environments get larger and larger, you can’t manage that as a flat mesh,” explained Cheshire. “You need some kind of organizational grouping by line-of-business or by the functions that you may have.”

    API management can create more formal interfaces between internal groups in a large organization that likely have little to no contact with one another. For example, perhaps the customer data team needs a formal method to connect with the sales organization. Or, maybe a security team supporting a login microservice needs to access financial details from an accounting division.

    2. What sort of access control and limiting does the system require?

    Consider what access control is necessary to secure your environment and avoid service disruption. A service mesh will typically use a zero-trust approach, applying mutual TLS over every ingress to each microservice. API management can also bring authentication controls and more advanced authorization and traffic mechanics.

    API management can provide a streamlined way to apply fine-grained controls for inter-domain traffic that follows the business logic. This helps assign access to specific resources to different requesting parties, such as read-only access for basic users or update access for admins. Amid increasing API attacks, setting fine-grained policies and permissions around your endpoints is becoming increasingly important to avoid data overexposure. This imperative increases as the binary between external and internal traffic fades with more public cloud use, remote work and third-party contractors.

    API gateways also place greater emphasis on communication rules and patterns. Rate limiting, for example, is very important to avoid collapsing entire networks, explained Cheshire. In addition to rate limiting, filtering, pagination and content negotiation are also standard API management capabilities that further optimize the exchange between the client and server.

    3. Do you require documentation for the services?

    In a monolithic setup, you likely have all developers sharing the same repository, explained Cheshire. This may still be true within an internal network of distributed microservices wherein each microservice is independent, yet developers can still access each other’s repositories. When you’re connecting services inside a domain, it’s often just the code itself (and perhaps some in-line commenting) that represents the contract between services.

    However, north-south traffic requires much more formalization, he said. Formal contracts are often necessary when one domain is communicating with another within the same company. In this scenario, there’s less tribal knowledge around how things work. API management is useful, in this case, to produce a developer portal with human-readable documentation that explains the methods, request types, URL structures and sample calls. This makes it much easier for someone without preexisting knowledge of the system to integrate with it.

    This formal contract is often generated from a specific file, such as OpenAPI Specification, which has emerged as industry-standard metadata for describing REST APIs. Groups can use OpenAPI to automatically generate documentation and even drive specification-first development. All in all, standardizing the way you document APIs and microservices can significantly improve the knowledge-sharing around how services connect.

    4. What is the nature of interactions?

    Another trait to keep in mind is the nature of interactions between services, Cheshire said. He divided systems into two large types: First is a graph model, in which any service can connect to any service. The second is a hierarchical model in which north-south traffic enables one service to have multiple consumers. A hierarchical model is necessary for productization and SaaS since it creates a single intercept point to the underlying resources. Maintaining hierarchy here is vital to retain simplicity, as you wouldn’t want the consumer to be able to hit all private microservices in a connected graph (unless that’s the intent!).

    API management thus enables the sharing of APIs on the mesh. “While they both use communication proxies, and while there are parallels in function, the differences in domain set them apart, and most companies will see significant benefits from using them together,” wrote Dino Chiesa and Greg Kuelgen on the Google Cloud blog.

    Better Together

    In summary, API management and service mesh go well together. “The two are complementary and can work together,” added William Morgan, CEO, Buoyant. Joaquim Moreno wrote, “they are not mutually exclusive; we should think about them as different layers in your infrastructure.”

    Specifically, combining the two is beneficial when:

    • Exposing and productizing APIs on the mesh
    • Formalizing inter-service communication in large corporate networks
    • Applying fine-grained access control; rate limiting for API-based microservices
    • Standardizing services with more formal documentation
    • Interaction is a more hierarchical communication model
    • Providing access to partners
    • When you need to externalize data to third-party plugins or integrations

    “The worlds of APIs and services mesh are becoming ever more closely connected,” said Cheshire. And API management won’t stop at REST—as developers adopt new integration styles like Kafka, GraphQL and asynchronous formats, the solutions will evolve. “It’s essentially a governance layer for all your integration points.”

    Large companies that seek to standardize inter-domain traffic within organizations will likely benefit from API management. But API management also offers the potential to productize internal infrastructure. Another benefit is that an API management gateway may also monitor and log requests, helping spot actors at the perimeter and keeping a helpful tally of incidents.

    Of course, adopting both API management and service mesh may be overkill for some scenarios. And, it’s good to remember that introducing additional layers inherently increases overall latency. It’s up to developers and architects to weigh the options and determine what’s appropriate for their unique environment. To enable this, a healthy culture of open communication is important to ensure teams are on a similar page across divisions, to avoid mismatched adoptions that only increase technical debt.

  • Cortex Expands Microservices Catalog to Improve Collaboration

    Cortex Expands Microservices Catalog to Improve Collaboration

    Cortex, a provider of a catalog for tracking the ownership of microservices, today announced it has added a service creation capability that enables developers to use templates to scaffold new services in five minutes.

    In addition, the company has added a Cortex Teams offering that improves collaboration across teams of developers working on interdependent microservices.

    Fresh from raising an additional $2.5 million in funding, Cortex claimed it has increased its customer base by a factor of 10 since initially launching last May. Those customers include Rappi, Grammarly and 8×8.

    Cortex CTO Ganesh Datta said the company’s microservices catalog makes it simpler for teams of developers, DevOps engineers and security professionals to collaborate at a time when software development is becoming more complex. While microservices-based applications are easier to update and generally more resilient than monolithic applications, composing an application based on interdependent microservices created by different development teams can be more challenging to build and maintain.

    In some cases, organizations can even discover that different teams within their organization have built redundant microservices. Part of the reason that occurs is many IT teams still rely on spreadsheets to keep track of what microservices are being built and which ones are already deployed in a production environment.

    Cortex, in contrast, automatically imports data residing in developer tools to surface who within an organization is responsible for maintaining which microservices. A Cortex dashboard also enables DevOps teams to see which developers are on-call in the event of an unexpected incident as well as monitor and track the latency rate microservices are experiencing and which vulnerabilities have yet to be remediated.

    At the core of the platform is Cortex Query Language (CQL), a domain-specific language that allows DevOps teams to define granular rules that can be applied to, for example, on-call rotations, security vulnerabilities, package versions, service level objectives (SLOs) and the overall health of the microservice. Engineers can employ code in the form of YAML files to set reliability standards across teams and types of services.

    Grades can also be assigned to specific microservices based on associated metrics. That approach allows DevOps teams to apply gamification techniques using a scorecard to encourage developers to continuously improve their microservices. That capability makes it apparent to other developers which microservices can be most reliably employed.

    It may be a while before microservices-based applications dominate the enterprise landscape. Monolithic applications will be running in production environments well into the next decade. However, many of those monolithic applications are essentially being converted into a larger microservice that other applications can invoke via application programming interfaces (APIs) before being eventually being re-engineered into a set of logically connected microservices.

    The one thing that is clear, however, is that as the number of microservices expands, it becomes more difficult to determine precisely what capabilities are already available to highly distributed application development teams.

  • Using Rust to Build Distributed Applications

    Using Rust to Build Distributed Applications

    Rust is an open source programming language that was initially developed at Mozilla Research and became increasingly popular for building distributed applications. It has been referred to in the Stack Overflow Survey as “the most-loved programming language” by software developers for five consecutive years. Moreover, companies like Amazon and Microsoft have recently revealed that they are using Rust to develop the software components that are responsible for ensuring application safety.

    Rust allows the implementation of safe and predictable code by leveraging memory safety and speed. It is the ideal choice to create code without incurring undefined or unpredictable behavior thanks to its features such as consistent runtime behavior and a static type system.

    Although Rust can be used for any system programming application, it is mainly implemented to build applications like simulation and game engines, browser components and file and operating systems. Rust syntax is similar to C++, but it addresses issues that C and C++ normally struggle with such as developing code without security vulnerabilities, general memory errors and problems in writing concurrent programs.

    The Advantages of Rust in Distributed Programming

    Rust tackles the performance and reliability problems of other low-level programming languages by using a careful compiler which examines all the variables used and referenced. As the code is compiled, Rust uses monomorphization by creating exclusive and high-performance code for each type of channel. It prevents programmers from paying performance penalties due to its flexibility. Based on the principle that you don’t pay for what you don’t use, the code written in Rust is enhanced and abstractions are solved at compile time making the program safe and without runtime overhead.

    Rust doesn’t have a garbage collector, which allows programmers to build abstractions with predictable performance. In Rust, there is no garbage to collect because the moment something would have become garbage, it gets freed immediately at compile time, making the program much faster. Moreover, Rust uses a borrow checker to check where data is used across the program, and by following a set of rules it establishes where data needs to be dropped or initialized. It provides the same advantages of a garbage collector with the efficiency and predictability of manual management.

    Another crucial characteristic of Rust is its asynchronous I/O. In Rust, asynchronous programming is widely implemented and well-integrated. It enables developers to effectively scale on a certain number of cores and exploit the operating system resources. By running several units of code on each application, this feature enhances performance and responsiveness of the operating system.

    Rust prevents some of the software engineering problems that could critically damage the application development process. These issues concern concurrency and memory safety which can cause very often denial of service, code vulnerabilities or compromised secrets. Examples of these frictions that are common in other languages such as C or C++ include uninitialized variables, undefined behavior, invalid iterators and unexpected variable modification.

    Another great advantage of using Rust is the Rust developer community, an extremely friendly and welcoming community. There are multiple events, chat rooms and forums to participate in that makes it even more pleasant to build distributed applications with Rust.

    Thanks to its ability to fix concurrency and memory issues, to compile and run safe and predictable code and provide a fast implementation, Rust is quickly increasing its popularity and establishing itself as the ideal choice for building distributed applications.

  • Serverless Computing Brings New Security Risks

    Serverless Computing Brings New Security Risks

    Attracted by lower costs and less operational overhead, serverless computing is an unmistakable undercurrent in the world of DevOps. Developers are drawn to the innovation because it requires no architecture to manage while offering continuous scaling for anything from a few requests per day to hundreds of thousands of requests per second.

    More than 50% of the developers using serverless functions today started using the computing model in the last three years. By some estimates, serverless computing is the fastest-growing segment in the cloud services market.

    While businesses are drawn by the opportunity to extend and integrate cloud applications at greater scale, there’s a dark underbelly to this DevOps phenomenon: security. In fact, organizations cite security concerns as the leading reason why they haven’t yet adopted serverless computing. For good reason!

    Serverless functions are introducing a new breed of threats – misconfigurations, code-level risks, injections and weaknesses – many of which are the underlying risk factors for a software supply chain attack. With adoption of this technology accelerating, organizations need security that delivers more than just visibility into these dynamic environments. They also need the ability to detect and block code-level vulnerabilities and misconfigurations that occur during development and through to production. Most importantly, this needs to happen seamlessly and with little to no impact on DevOps.

    Dynamic Environments Create Complex Security Risks

    The nature of applications has evolved, creating a new paradigm of security risk. In serverless environments, code sprawl makes it harder to identify vulnerabilities and patch them before they become business-level risks.

    In a monolithic application environment, an identified vulnerability could be efficiently patched by the developer through upgrading a single package, pushing a deployment and then testing and deploying the app.

    In a serverless computing model, patching and resolving vulnerabilities becomes a lot more complicated, given that there may be several hundred (or more) environments across different providers and regions. So, instead of having to patch a single application, developers will need to patch, deploy and test hundreds of individual functions that rely on that library.

    With 39% of developers saying they’re now fully responsible for security, it means they’ll carry the burden of having to patch an identified vulnerability – often taking them away from development work.

    With Serverless, You Need to Rethink Your Approach to Security

    Given the distributed nature of serverless functions – essentially, the reason for its flexibility and scalability – many existing security tools will provide little to no visibility, nor the control capabilities, for these computing environments. Many of the security attacks that will occur in serverless functions will be a result of misconfigurations and mistakes that happen outside the purview of the security team and due to legacy solutions which don’t translate to serverless architectures. Further, because abstracted workloads create blind spots, attackers will have more room to maneuver undetected.

    Serverless functions will even render some traditional DevSecOps tools less useful. Scanning tools must monitor hundreds of individual repositories instead of a single monolithic repository, while application performance monitoring (APM) tools lack security proficiency and cannot protect from the OWASP Serverless Top 10 risks.

    The challenge for security teams will be implementing solutions in a way that does not modify workloads or require changing business logic — both of which slow development. When applying security to serverless functions, it’ll be critical that the solution can do the following:

    • Go beyond monitoring and actually detect and block vulnerabilities without elaborate or manual steps involved. The scale of serverless functions will make it nearly impossible for security analysts to manage and keep up with every alert they receive. Instead, they need a tool that delivers actual security and can help them block malicious activity without stopping development altogether.
    • Enable a positive security model that provides protection against malicious changes, like zero-day exploits, within the function. This approach gives security teams more control by automatically detecting and blocking anything that isn’t explicitly allowed in a given function.
    • Provide forensic detail from log-level information so security analysts can fully understand the context of every attack with virtually no impact on latency. Further, with the risk of supply chain attacks soaring, security teams need the ability to identify and map third-party dependencies used during runtime.

    For many organizations, serverless architecture is a very different and unique computing environment – unlike anything they’ve experienced or had to protect before now. That reality means that organizations need a fresh approach to securing these environments and will need to look beyond the traditional tools they have in their tech stack today.

    Above all, developers and security teams will need to work together to ensure security is built-in from the start. Otherwise, serverless functions will quickly become a playground for cybercriminals.