Tag: microservices

  • There’s No Value in Observability Bloat. Let’s Focus on the Essentials

    There’s No Value in Observability Bloat. Let’s Focus on the Essentials

    The observability market paired with cloud security has been predicted to reach $70B by 2026, but that market prediction is a myth, and I’ll tell you why.

    If observability was a grand buffet and every company needed a feast of features and capabilities of this proportion, maybe this prediction would be valid. But most companies don’t need an over-the-top feast. Legacy APM and observability solutions are serving up an all-you-can-eat buffet when the reality is that most companies only need the essential ingredients to satisfy their observability strategy. And the cost for that can be much more modest. The $70B observability market prediction is, therefore, suspect, considering the true needs of most organizations.

    Complex cloud ecosystems, the rise of applications built on microservices and Kubernetes, and the overall scale and complexity of applications have led to exponentially more data being created in the pursuit of observability. Storing and processing all that data is expensive, and as the volume of data balloons, so does the cost.

    And while the complexity of business-critical systems and the volume of data have scaled, so have the overall cost of those legacy tools—in direct proportion. Partially, this is driven by the features and instrumentation added that only contribute to the bloat and valueless telemetry.

    Customers aren’t seeing value in any of this bloat, and for the most part, all that’s been accomplished is increased complexity in deploying and operating the system, with a commensurate lengthening of time to value. Plus, pricing models haven’t significantly changed despite the advancements in the market. The fact is, organizations can’t really say that they have gotten more insight into the overall performance of their mission-critical systems. What they are saying, however, is that these tools are becoming overwhelming to manage and overwhelmingly expensive, and developer productivity is not increasing.

    What organizations need and want are real-time insights into the health and performance of their cloud infrastructure and applications–specifically the confluence of logs, metrics and traces within the context of modern observability. There is little tolerance for software bugs, slow web experiences, crashed apps and other service interruptions, and the responsibility lies on developers, engineers and ITOps teams to quickly resolve production issues before they impact customer experience.

    There is a call for observability, but rather than an explosion of features and noise, what’s being called for is a narrowing of focus.

    Observability Has an Efficiency Problem

    Telemetry data gathered from the distributed components of modern cloud architectures needs to be centralized and correlated for engineers to gain a complete picture of their environments.

    Engineers need a solution with critical capabilities such as dashboarding, querying and alerting, and AI-based analysis and response, and they need the operation and management of the solution to be streamlined.

    What’s important for them to know is that it’s not necessary to spend more to ensure peak performance and visibility as their environmental complexity grows.

    Legacy players experiencing some maturity in the market may have conditioned them to believe this is true—they have set a standard for higher costs correlating with incremental amounts of data, no matter the quality of that data. Companies are being fed the lie that all this data may be relevant and they’ll be doing themselves a disservice by neglecting even one byte of it.

    Data Does Not Inherently Equal Insights

    No doubt, more data is being generated, but most of it is not relevant or valuable to an organization. Observability can be optimized to bring greater value to customers, and that’s where the market is headed.

    Call it “essential observability.” It’s a disruptive vision to propose a re-architected approach to observability, but what engineers need is a new approach making it easier to surface insights from their telemetry data while deprioritizing low-value data. Costs can be reduced by consuming only the data that enables teams to maintain performance and drive smart business decisions.

    Essential observability is cutting out the fluff and only focusing on—and paying for—the impactful data. It’s about arming engineers with meaningful insights so they can quickly resolve production issues and business disruptions. Organizational performance increases without inflating data complexity and resource consumption.

    The Essential Observability Revolution

    Observability tools have evolved beyond the model of linear price increases as complexity and data scales. For companies (especially growth-stage organizations) that want a partner to help them make more informed decisions and keep their costs more reasonable (i.e., stop recklessly spending for useless data), they need to focus on tools offering them the essentials.

    Solutions are available, offering targeted features and automated capabilities out of the box, delivering the insights needed to understand and fine-tune data. These solutions provide continuous support, reduce complexity and accelerate time to value.

    The next revolution in observability isn’t features and functionality but providing insights to make data-driven decisions that keep essential observability cost-effective while not compromising the value derived.

  • From DevOps to the Future: The Evolutionary Leap to Platform Engineering

    From DevOps to the Future: The Evolutionary Leap to Platform Engineering

    The paradigm of technology development never ceases to amaze. Over the past few decades, we’ve witnessed an unbroken chain of progress from traditional IT to Agile methodologies, from cloud computing to microservices and now, another leap is on the horizon. Enter the age of the platform engineer, a role that is swiftly emerging as a logical evolution of DevOps culture.

    From the Roots: Understanding DevOps

    DevOps revolutionized the way teams design, build and deliver software. With its advent, we saw the amalgamation of developers and operators into a single team, fostering a culture of collaboration and integration. The core idea was to tear down the traditional silos and ensure seamless interaction between different stakeholders in the development process.

    This unique approach has proven its mettle over time, bringing about shorter development cycles, higher deployment frequency, more dependable releases and quicker resolution of issues. DevOps set the stage for continuous delivery, integration and monitoring, thus speeding up the digital transformation of many organizations.

    The Evolution: Birth of the Platform Engineer

    As we delve further into the era of cloud-native technologies, containers and service meshes, the demands on the DevOps methodology have evolved. To cater to the increasing complexity and scale of modern infrastructures, we witness the emergence of a new breed of professionals, aptly titled platform engineers.

    This role is not just a renaming of the traditional DevOps engineer; it is an evolution. Platform engineers build upon the foundational practices of DevOps but go beyond by embracing a holistic view of the technology stack. They focus on creating platforms that provide a unified, consistent, and efficient environment for development and operations teams to work within.

    Platform Engineering: The Core Components

    Platform engineers possess a skillset that spans software development, infrastructure management, system operations, and, importantly, a deep understanding of the business context. They are entrusted with the design, construction and management of the underlying platforms supporting the deployment and scaling of applications.

    A significant part of the platform engineer’s role involves creating self-service infrastructures that empower teams to deliver software independently and efficiently. This can involve building and managing internal toolchains, maintaining cloud-native infrastructures, designing service observability systems and ensuring high levels of automation across the board. 

    The Future is Here: Embracing Platform Engineering

    The rise of the platform engineer signifies a shift towards more scalability, resilience and efficiency in managing modern tech ecosystems. It’s about leveraging technology to its fullest extent and creating a platform that is more than the sum of its parts. 

    As the technology landscape continues to evolve, the transition from DevOps to platform engineering may soon become the norm. It’s an exciting prospect, promising a future where innovative platforms can seamlessly integrate and orchestrate the complexities of the modern digital world. After all, in this era of rapid digital transformation, those who adapt will thrive. 

    In conclusion, the platform engineer role is not replacing DevOps but evolving from it, extending the principles that made DevOps so successful to meet the challenges and opportunities of the new tech era. As we continue this exciting journey into the future of software development and delivery, there’s no doubt that platform engineering will play an increasingly important role. 

  • CDF Marries Emporous Repository to Ortelius Management Platform

    CDF Marries Emporous Repository to Ortelius Management Platform

    The Continuous Delivery Foundation (CDF) has added the open source Emporous repository for software artifacts to an Ortelius platform for managing the software artifacts that make up a microservice.

    Ortelius was originally created by DeployHub and subsequently contributed to the CDF, which also oversees the development of the open source Jenkins continuous integration/continuous delivery (CI/CD) platform.

    Emporous is based on a Universal Object Reference (UOR) conceptual model that enables dynamic schema registration and decentralized content-addressable reference of a wide spectrum of software artifacts. Originally developed by Red Hat, Emporous will now be managed as a sub-project within the larger Ortelius incubation-level project by the CDF.

    DeployHub CTO Steve Taylor said this integration would make it simpler to store, organize and search metadata related to software artifacts, along with the artifacts themselves, within the context of the Ortelius platform for managing microservices.

    Ortelius provides insights into the relationships and dependencies between different software components and applications. It does this by collecting and aggregating pipeline data from multiple sources within a software supply chain. Emporous will be incorporated within Ortelius to enhance metadata search capabilities and provide a single repository to store any type of artifact, from containers to jar files. It will now also be able to store metadata and also the artifacts themselves within the same Emporous catalog.

    Those capabilities will significantly improve security and compliance reporting across a software supply chain, added Taylor. DevOps and cybersecurity teams will be able to automatically apply and enforce supply chain policies and procedures, he said.

    DevOps teams need a way to aggregate all the data from the various tools they use and the data must be easily searchable. Armed with those insights, it should become simpler to surface insights into, for example, which components of an application contain known vulnerabilities.

    In the longer term, IT organizations will be able to apply machine learning algorithms and other forms of artificial intelligence (AI) to automatically surface insights that will enable DevOps teams to automate workflows, said Taylor.

    Microservices-based applications are considerably harder to build and manage than monolithic applications, but they are also easier to maintain because individual microservices can be ripped and replaced.

    Most microservices today are built using containers, but there are also microservices that are written in Java, for example. In some cases, developers view monolithic applications as being a large, less flexible microservice that they invoke via an application programming interface (API).

    There’s no doubt that the rise of microservices made application environments a lot more complex. The tools needed to simplify the management of the next generation of applications are finally starting to become more widely accessible. In theory, the number of organizations that can successfully build and deploy these types of applications should steadily increase in the months and years ahead.

    In the meantime, there’s clearly still plenty of work that needs to be done to improve the overall state of software delivery. A recent CDF survey found only 22% of respondents were using continuous integration and continuous delivery (CD) to automate the building, testing and deployment of code in a production environment. As CD becomes more distinct from CI, however, the number of organizations that can achieve that goal when deploying microservices-based applications should steadily increase.

  • 8 Hot Takes: Will We See a Monolithic Renaissance?

    8 Hot Takes: Will We See a Monolithic Renaissance?

    Is the DevOps world slowly backing away from microservices and to a monolithic renaissance? After years of proselytization about the benefits (Flexibility! Resilience! Support faster release speeds!) of microservices and serverless architecture, there are signs of a potential backlash against the singularly fragmented microservices architectural approach.

    The argument in favor of rolling back to monolithic architectures feels similar to the cloud repatriation debate. Just as with a lot of cloud-first transformations—often in lockstep with them, actually—many organizations moved headlong toward microservices without a case-by-case business or technical rationalization for the change. As the shiny newness of microservices has dulled under that approach’s daily exposure to real-world deployment and business challenges, the monolith isn’t looking so bad in a lot of situations.

    The monolithic versus microservices debate boiled over the last few weeks in the wake of the publication of a case study earlier this month from the Amazon Prime Video team. The analysis from Marcin Kolny, senior software development engineer for Prime Video, reported that his team was experiencing scaling bottlenecks in its audio/video quality inspection tooling, which was architected as a distributed system using serverless components. By rearchitecting the tool as a monolith, they were not only able to increase scaling capabilities but drastically reduced the infrastructure costs around that tool.

    “Moving our service to a monolith reduced our infrastructure cost by over 90%,” Kolny wrote.

    The announcement elicited a fair degree of hyperbole on the topic, but it also spurred a very organic airing of the pros and cons of monolithic, microservices and serverless architectures.

    The following are 10 different perspectives spurred on by this online debate from a range of CTO and engineering experts. Some of them are diametrically opposed to one another, many are overlapping in their opinions. But as a body, they point to the general (and very pragmatic) consensus that there simply will never be a one-size-fits-all approach to software architectures.

    Microservices a Siren Song for Complication

    “It’s clear that in practice, microservices pose perhaps the biggest siren song for needlessly complicating your system. And serverless only makes it worse. Replacing method calls and module separations with network invocations and service partitioning within a single, coherent team and application is madness in almost all cases.”

    —David Heinemeier Hansson, creator of Ruby on Rails and CTO at 37signals (maker of Basecamp and HEY)

    Architectures Aren’t Good or Bad

    “Application architectures are neither good nor bad, nor are they appropriate for every use case. Organizations need to step back and consider carefully what it is they’re trying to achieve and which architecture might best serve that need instead of choosing the most “modern” architecture because, well, it’s in vogue.”

    —Lori MacVittie, distinguished engineer in office of CTO at F5Networks

    Distributed Architectures Will Suit AI-Driven Future

    “In the ongoing debate between monolithic and serverless architectures, it is important to acknowledge that both approaches have their merits and considerations. Monolithic architectures have been prevalent in large human-centric organizations due to their management advantages and historical use cases. However, as the world continues its rapid progression towards a more AI-driven future, the landscape is shifting towards architectures that embrace fluidity, autonomy, and distribution.”

    — Reuven Cohen, veteran CTO and entrepreneur, mentor for TechStars

    Monolithic and Serverless Each Have Pros And Cons

    “Over the last 15 years, everyone has wanted to move to serverless microservices-based horizontally-scaled architecture – but it is not ideal for every application’s specific needs.  As with any choice in life and in business, there are always tradeoffs;  you must evaluate and choose the appropriate architecture based on your business and technology needs. Another important dimension to this is workforce skills for application architecture.

    —Hemang Davé, client technical leader and CTO at Kyndryl

    The Amazon Rearchitect Wasn’t Even Truly a Monolith

    “The problem is that they called this refactoring a microservice to monolith transition when it’s clearly a microservice refactoring step, and it is exactly what I recommend people do in my talks about serverless first. I don’t advocate “serverless only”, and I recommended that if you need sustained high traffic, low latency and higher efficiency, then you should re-implement your rapid prototype as a continuously running autoscaled container as part of a larger serverless event-driven architecture, which is what they did. If you built it as a microservice to start with, it would probably take longer (especially as you have to make lots of decisions about how to build and run it) and be less able to iterate as you figure out exactly what you are trying to build.”

    —Adrian Cockcroft, longtime DevOps advocate and veteran architect with stints at eBay, Netflix, Amazon, and Battery Ventures, among others

    One Tool as a Monolith, Maybe, But Not All of Amazon

    “Microservices, while duplicative and inefficient from a compute standpoint, allow you to release stuff really quickly, which is a tradeoff that most organizations at scale are willing to make.

    Microservices exist to reduce communication pathways—not to solve technical scaling challenges. At a certain point, teams stop functioning due to the communication overhead. A seven-person team has 21 communication pathways, whereas a 100-person team has 4,950. I work with large retailers selling billions of dollars a year online, and putting everything into a single monolith just doesn’t work. Could the entirety of Amazon.com be deployed as a single monolith? No way.”

    —Kelly Goetsch, chief strategy officer at commercetools

    Architectural Tension Always Exists Between Speed and Maintainability

    “Speed to market and speed to develop does not always equate to long-term scalability and maintainability. You must actively balance your investments across these two critical pillars to build a viable product. Active rebalancing and reconsideration of the stack and technology mix for your FinOps and BizOps context is both art and science.

    Cloud-native distributed systems paradigms are here to stay. The Prime Video folks have mistakenly labeled a properly factored, highly coupled data-intensive processing step a monolith—it’s at best a rocky outcropping in their distributed microservices forest. “

    —Ajish George, managing director of cyber data & analytics for State Street

    The Shiny Thing is Not Always the Best Thing

    “The news that AWS discovered that serverless and microservices aren’t for everything is surprising. Not because it didn’t work out for that use case; but because the wrong use cases have been so well-known for the serverless/microservices pattern and should have been obvious to Prime Video. It’s worth remembering: That shiny new thing isn’t necessarily a better way of trapping mice. Right tool for the right job.”

    —Doug Vanderweide, director of cloud architecture for Avanade

  • State of Developer Experience Report Finds Growing API Reliance

    State of Developer Experience Report Finds Growing API Reliance

    Web APIs continue to grow in interest among developer users. APIs can empower new customer experiences and help engineers avoid rebuilding common functions. The technology is also powering microservices and headless architectures that we’ve seen gain more traction in recent years as enterprises become more composable.

    On the provider side, a web API strategy can enable co-creation in partner ecosystems and even open new revenue opportunities for the business. Yet, like any software-as-a-service (SaaS), APIs require great developer experiences to create quick onboarding journeys and easy ongoing maintenance.

    Nylas recently released its inaugural State of Developer Experience Report, detailing the key trends, technologies and priorities that are molding the modern developer experience. The study found increasing reliance on APIs and hopes to increase investment in API-driven technologies. I also met with Isaac Nassimi, SVP of product, Nylas, to explore the reasons behind some of these findings and to get his perspective on the API economy at large.

    Rising Importance of APIs

    As I’ve covered before, the number of APIs in the market has ballooned as more development teams have come to rely upon APIs to power new application functions. The largest companies, those with 10,000 or more employees, have more than 250 internal APIs, according to Rapid’s 2022 State of APIs report.

    Similarly, the Nylas study underlined the growing reliance on APIs. A full 98% of developers said they view APIs as a key contributor to helping them and their team get their work done. And 86% of developers said they expected their use of APIs to increase in 2023.

    According to Nassimi, APIs are something that’s become more and more prevalent over time. For example, in 1998, setting up a web server was pretty cumbersome. But nowadays, a junior developer can accomplish the task (and much more) with a few lines of code, he said. APIs abstract complexity and help leverage external infrastructure so you aren’t constantly reinventing the wheel. “They add more functionality and help outsource labor, thought and cognitive load,” explained Nassimi.

    APIs Bring Developer Experience Benefits

    Another possible reason to shift toward APIs is to handle escalating tool usage. Almost half (48%) of developers said they are either always or often overwhelmed by the number of tools they use daily. Simultaneously, 98% of developers said APIs would lessen the number of workplace tools they use daily. The study indicates that investment in APIs can increase automation and reduce the manual headaches of crafting new features by hand.

    For example, Nassimi describes creating a video transcoding service from scratch in a previous company. The entire engineering team had to dedicate months and months to the process, using muscles they hadn’t ever exercised. After much effort, they ditched their work and ended up just using an API. “It was a really good feeling to delete 200 lines of code,” said Nassimi. “If you do that five times, you reduce all these esoteric things you have to learn how to do in your company by an order of magnitude.”

    In addition to reducing headaches, APIs can also enable speed. For example, it can take over a year for three senior engineers to build an email or calendar integration without the help of an API, the report found. With an API, this integration timeline can be minuscule, said Nassimi. As a result, 95% of all respondents said they would like to see their company invest more heavily in APIs within the next year.

    Developer Experience Improvements

    Developers find speed to be the number one benefit when working with APIs. And to grant this speed, API providers must create a streamlined developer experience (DX). The speed of implementation can make the difference between a good DX and one that is not so good, and a significant contributor to this speed is familiarity. One DX hangup is that the API you use must function like the code you use in your own environment, said Nassimi.

    Although solid documentation and naming conventions should exist in the background, Nassimi shared that forcing developers to learn terminology about the thing the technology is abstracting is a lousy developer experience. Instead, installing SDKs in the unique language of choice, like TypeScript bindings, and using autocompletes to understand the SDK can grant a much better experience.

    Workflow automation and AI can also enhance developer experience, as it frees up time for engineers to be more productive. In fact, two out of three developers would like their company to invest in AI for workflow automation and to curate better user and customer experiences. And 72% of developers said they or their organization are currently using AI for data analytics and making sense of their data.

    However, when it comes to generative AI like ChatGPT and Bard, developers are less enthused—only 14% of developers reported it as a useful area that their companies should invest in over the next year. Although the headlines proclaim that generative AI will disrupt most aspects of modern work, the technology is still new and can produce errors and introduce potential security repercussions.

    Looking Through the Micro Lens

    Developers integrating with APIs will have various backgrounds and priorities. And although speed is an important consideration, providers should also understand where their workloads lie and what particular features they should be driving, said Nassimi. “You want to show off all endpoints and features, but if you narrow down to show users what they need to get started, you will close more deals,” he said.

    For more details, you can download a copy of Nylas’ State of Developer Experience 2023 behind an email gate here.

  • Loosely Couple Your Schema and Keep Data Separate

    Loosely Couple Your Schema and Keep Data Separate

    In software development, one of the primary goals is to write clean, maintainable and extensible code. To achieve this, developers often strive to design systems that are loosely coupled and separate concerns into smaller, more manageable components. Loose coupling refers to the practice of designing components that are not tightly dependent on one another, allowing them to be modified or replaced without affecting the rest of the system. Separating data into distinct layers, such as a database layer, further contributes to this modularity by allowing developers to focus on writing business logic without worrying about data management. Together, loose coupling and data separation provide a solid foundation for building scalable and adaptable systems that enable developers to concentrate on writing high-quality business logic. This approach also lends itself to platform engineering best practices, a popular methodology that is being implemented or considered by developer teams today.

    Loose coupling is an important concept in microservices architecture because it helps to achieve the goal of creating modular, scalable and easily maintainable software systems. In a microservices architecture, individual services are designed to be independent, self-contained and loosely coupled, meaning they can be changed, updated or replaced without affecting other services or the system as a whole.

    There are several benefits to loose coupling in microservices:

    • Scalability: Microservices architecture allows scaling of individual services independently based on their needs, and with loose coupling, the interdependencies between services are minimized, allowing for better scalability.

    • Maintainability: With loose coupling, it’s easier to make changes to individual services without disrupting the system as a whole, reducing the risk of introducing bugs and making maintenance tasks easier to perform.

    • Flexibility: With a loosely coupled architecture, services can be developed, tested and deployed independently, enabling teams to work in parallel and make changes to the system without impacting each other.

    Platform engineering plays a crucial role in ensuring that microservices are loosely coupled. A well-designed platform should provide a standardized set of APIs, protocols and interfaces for service communication, as well as tools and frameworks for building, testing, deploying and managing services. This enables service teams to focus on developing their services rather than worrying about the underlying infrastructure and communication protocols.

    Moreover, platform engineering can also ensure that there is a standardized and centralized approach to security, monitoring and logging, which are critical aspects of microservices architecture. By providing a consistent and standardized approach to these areas, platform engineering can help ensure that individual services remain loosely coupled and can evolve independently, without negatively affecting the system as a whole.

    It’s All About Keeping the Schema Separate

    In platform engineering, the concept of keeping the schema separate typically refers to separating the schema of a database or data store from the application code that interacts with it. This separation allows for greater flexibility and scalability in the platform, as changes to the schema can be made independently of the application logic. By decoupling the schema from the application code, developers can avoid introducing breaking changes to the platform, and can more easily evolve and scale the platform over time.

    Separating the schema also allows for different parts of the platform to interact with the same data store using their own specialized schemas, without interfering with each other. This is particularly important in large and complex systems, where different teams may be working on different parts of the platform concurrently. By keeping the schema separate, teams can work independently and avoid stepping on each other’s toes, while still interacting with the same underlying data store.

    In summary, it’s all about the schema – don’t share databases and tables. The separation of data is fundamentally driven by that desire for loose coupling. Microservices should be as independent as possible from each other from design to development to production. Why? Efficiency. Disparate teams can change data structures and will not affect others versus the more traditional approach where we do share and it’s more cumbersome and involves more coordination between teams.

    Keeping schema separate in platform engineering is important for several reasons:

    ● Scalability: Each microservice owns its private schema, which enables the platform as a whole to scale more effectively. As the platform grows and evolves, it may become necessary to change the data schema without necessarily changing the underlying code. Separating the schema makes it easier to make these changes without disrupting the rest of the platform.

    ● Maintenance: Separating schema from code makes maintenance easier. It allows developers to make changes to the schema without needing to change the code, which reduces the risk of introducing bugs or errors.

    ● Collaboration: Separating schema from code makes it easier for multiple developers to work on the platform at the same time. When developers work on the code and schema separately, they can work independently without interfering with each other’s work.

    ● Flexibility: Separating schema from code provides greater flexibility for integrating with other systems or applications. It enables the platform to adapt to changing requirements or to interface with different data sources more easily.

    Separating Schema From Code is an Essential Practice

    By hiding data from service components from other service components, It provides guardrails and “just works.” While it does provide a form of coupling, it’s through messaging (typically asynchronous). Platform engineering encourages good design patterns from the start versus having to be more aware of these things. It’s a lot easier for especially newer developers that are not familiar with some of these architectural patterns and can get themselves into trouble.

    Overall, separating schema from code is an essential practice in platform engineering that provides scalability, maintenance, collaboration and flexibility benefits. It allows developers to build more robust and flexible platforms that can adapt to changing business requirements and technical environments.

  • 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 

     

  • Best of 2022: Using Event-Driven Architecture With Microservices

    Best of 2022: Using Event-Driven Architecture With Microservices

    As we close out 2022, 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 2022.

    Microservices architecture is on the rise, already forming a key part of several current transformation projects, breaking down traditionally monolithic applications into self-contained, independently deployed services that are identified using domain-driven design.

    Stats from a recent study found that more than 60% of respondents have been using microservices for a year or more. In particular, finance and banking lead the way in using microservices, but many other industries are following suit including retail/e-commerce and telecoms.

    Not only do microservices hold the potential for enhanced scalability, flexibility and durability, but the time taken to deploy and maintain components is also significantly improved. This isn’t the case for all microservice architectures. Major impediments come in the form of ecosystem integration challenges and weak distribution processes.

    Busting the Myths of Distributed Computing 

    The implementation of microservices is more complex than one may first think, exacerbated by the fact that many DevOps teams fall into the trap of making false assumptions about distributed computing.

    The list of distributed computing fallacies was originally addressed in 1994 by L. Peter Deutsch and others at Sun Microsystems, and still holds true today. There are key fallacies that hold special importance to microservices implementation: reliable, homogenous, and secure networks, latency is zero and transport cost is zero.

    The smaller you make each microservice, the larger your service count, and the more the fallacies of distributed computing impact stability and user experience/system performance. This makes it mission-critical to establish an architecture and implementation that minimizes latency while handling the realities of network and service outages. 

    Uncovering the New, Updating the Old

    Microservices require connectivity and data to perform their roles and provide business value, however, data acquisition/communication has been largely ignored and tooling severely lags behind. We can see this with API management or gateway products that only support synchronous, request/reply exchange patterns. This only goes to exacerbate the challenges of distributed computing – they don’t have the ability to integrate with or acquire data from legacy systems.

    At the same time, eventing/messaging tools have also been stuck in the antiquated, non-agile world, being incompatible with many of the guiding principles of microservices such as DevOps and self-service. 

    Solving the Logistical Maze of Integration 

    As services become smaller and their purpose more singular, the potential for reusability increases, but that’s contingent on the ability for services to collaborate. Acquiring data for greenfield systems is easy, but microservices almost always come as a side effect of digital transformation, modernization — or the need to build new capabilities at a more rapid pace. 

    The Disconnect

    Most existing systems live on-premises, while microservices live in private and public clouds so the ability for data to transit the often unstable and unpredictable world of wide area networks (WANs) is tricky and time-consuming. 

    There are mismatches everywhere: updates to legacy systems are slow, but microservices need to be fast and agile. Legacy systems use old communication mediums, but microservices use modern open protocols and APIs. Legacy systems are nearly always on-premise and at best use virtualization, but microservices rely on clouds and IaaS abstraction. 

    The case becomes clear – organizations need an event-driven architecture to link all these legacy systems versus microservices mismatches.

    Creating the Perfect Microservices Harmony 

    The smaller the service, the less value it offers the end-user – value comes from orchestration. Historically, orchestration was handled by a central component like BPEL engines or ESBs, or, these days, API gateways.

    Orchestration is a good description – composers create scores containing sheets of music that will be played by musicians with differing instruments. Each score and its musician are like a microservice. In a complex symphony with a hundred musicians playing a wide range of instruments – like any enterprise with complex applications – far more orchestration is required. 

    Microservices are Well-rehearsed

    So, an example of microservices orchestration is when a microservice performs a series of steps within the code. The input or output of a microservice is a data event that has domain significance. But what is key is that since the microservice is merely producing an event, it does not have knowledge of if or when it will be processed. Other services must register their interest in the event, or set of events, and react accordingly. This all needs microservices orchestration. 

    Time to Shift the Focus

    Event-driven maximizes agility as it liberates data from being ‘at rest’ to being ‘in motion’ – consumable in real-time. Choosing the right eventing or messaging platform is one of the most critical steps to realizing the vast benefits of microservices.

    Microservices per se are not enough. Gartner has identified this need as far back as 2018 when it spotlighted ‘event-driven’ as one of its top strategic technology trends, citing “Digital business is event-driven, so organizations need to invest in event-centric design practices and technologies to exploit digital business moments.”

    The Full Potential of Event-driven Microservices

    Merging event-driven architecture with microservices can house major benefits. Developers can build highly scalable, accessible, robust and versatile systems that can digest and aggregate exceptionally large amounts of events and information in real-time. 

    Not only should modern events platforms be able to be deployed in every cloud and platform as a service, but they should also support DevOps automation. In such an ever-changing world, developers need a seamless self-service experience – only made possible with event-driven microservices.

  • Shift Left Testing in Microservices Environments

    Shift Left Testing in Microservices Environments

    By now, it’s common knowledge that the later a bug is detected in the software development life cycle (SDLC), the longer it takes and the more expensive it is to fix that bug.

    In 2017, the Ponemon Institute found that it cost around $80 on average to fix a defect detected early in the SDLC and around $7,600 to fix the same defect if it was detected in the production stage.

    Relative Cost of Fixing a Defect Based on Development Stage

    Design

    Implementation

    Testing

    Maintenance

    Cost of Fixing Defects

    1x

    6.5x

    15x

    100x

    While these numbers can be debated, it’s clear that early detection of defects can save organizations significant time and money while enabling those organizations to deliver higher quality software more rapidly. For these reasons, many organizations are implementing shift left testing practices, including in microservices environments.

    Shift left is a set of practices intended to find and prevent defects early in the software delivery process instead of during the testing and maintenance stages. The idea behind shift left testing is to improve software quality by making actionable test signals and feedback available as early in the SDLC as possible.

    Here, we’ll highlight how shift left testing, in combination with test automation, can better enable both innovation and fast delivery of high-quality software. We’ll also address some of the challenges involved in implementing shift left testing in microservices environments, as well as introduce a valuable strategy for successful microservices implementation.

    Shift Left Testing Benefits

    The waterfall model of development involved the explicit passing of responsibilities between highly specialized design, development, QA, and release teams. It also involved lengthy feedback loops.

    Scrum and agile methodologies made the entire SDLC more flexible and nimble by introducing sprints and allowing more frequent iterative development and delivery. Further, DevOps and DevSecOps focus on removing the silos between development, operations, and security through tooling and automation. As a result, the time to market and quality have improved dramatically. Adding shift left testing into the mix better positions teams to handle the broad range of responsibilities from the design stage through the maintenance stage as effectively as possible.

    Shift left testing focuses on prevention rather than detection. Shift left benefits include the following:

    • Increase efficiency by eliminating bugs earlier in the SDLC.
    • Reduce human errors and associated costs.
    • Increase delivery speed and reduce the time between releases.
    • Improve the quality of software.
    • Gain a competitive advantage.

    It may be helpful to think of shift left testing like this: Test early and in parallel with development, instead of the traditional waterfall model of development followed by QA testing. 

    Shift Left Testing Challenges in a Microservices Environment

    By structuring an application as a collection of loosely coupled, independently deployable services, a microservices architecture enables frequent delivery of large, complex applications.

    While shift left testing practices bring many benefits, shift left testing also comes with three challenges that organizations must address when implementing it across a decentralized, microservices-based stack:

    1. Building and managing each microservice separately reduces development time. However, implementing shift left testing at the microservices level means shift left practices must be applied to each individual microservice.
    2. Microservices developers can choose the programming language and service dependencies best suited to their development needs. However, as a result, shift left testing practices need to be implemented and managed across different programming languages and dependencies.
    3. To ensure that microservices function as expected, teams usually run integration tests, end-to-end tests, and performance tests that assess functionality in the context of the larger stack. Shift left testing is especially challenging in the microservices context because of the complexity of testing against the stack.

    Microservices, each with their own SDLC pipeline

    Pipeline Scaling Considerations

    Several classes of automated shift left tests can be integrated into the DevOps pipeline, including unit tests, integration tests, performance tests, and security tests. Different microservices will have different testing needs.

    The key is to apply shift left testing practices to each microservice while maintaining the flexibility and decentralization of those microservices. The ideal workflow system and DevOps pipeline implementation must simplify pipeline creation while enabling development teams to manage the pipeline and requiring minimal input from DevOps and platform teams. In other words, shift left practices must be tailored to the specific needs of the microservice in question to make the testing process scalable and easy for development teams to manage on a continuous basis.

    As just one example, GitHub Actions and similar CI/CD pipeline tools enable development teams to use GitOps-based practices to configure, manage, and administer the entire pipeline for their microservice while leaving infrastructure testing and testing that relies on or affects other parts of the system to DevOps teams.

    Test Environment Considerations

    Test environments are environments where unit tests, integration tests, performance tests and security tests can be run on an isolated collection of microservices and configurations. The nature and quality of these test environments directly correlate with the effectiveness of shift left testing.

    A cloned production or staging environment can be used for testing when the number of microservices is low and overall complexity is relatively low. However, once an organization reaches a threshold number of microservices or a threshold level of complexity, runaway infrastructure costs and operational burdens make such environments untenable.

    In response, some organizations rely upon smoke testing (minimal viable stability testing) and mock-based integration testing early in the SDLC. While such tests can prove useful in the near term, deferring essential testing to a later stage in the SDLC often introduces test signal and validity problems in the staging environment and can lead to delivery delays and serious issues with software quality.

    So how can shift left testing be used successfully in a microservices environment? The solution involves the use of scalable, ephemeral test environments.

    Ephemeral Shift Left Testing Environments

    The availability of high-quality test environments is a common bottleneck for organizations looking to scale shift left testing practices. Using a few high-fidelity staging environments for signal testing can slow the release process. More to the point, it tends to slow down the entire SDLC and increase stack instability over time.

    Ephemeral test environments offer a fundamentally different approach. These sandbox environments use isolated environments that enable users to test independently without impacting other users. In particular, they enable isolation while sharing resources (e.g., external cloud dependencies and hosted databases) using application-level multitenancy instead of the resource duplication approach in traditional environments.

    The idea is that microservice test environments can be used to test changes against a much larger stack of services. Because multiple tests can be conducted at the same time, test coverage and resource efficiency vastly increase.

    High-quality sandbox environments can spin up in seconds and scale to tens of thousands of microservices. In fact, each pull request, branch, or commit can have its own test environment without significantly increasing infrastructure and operational costs. Any change, no matter how small, can be tested in isolation to ensure performance and stability against the entire stack.

    Shift Left Testing Solutions for Microservices

    A microservices-based organization looking to scale shift left testing across the organization must first address several challenges. Considerations include the need to apply testing practices to separate microservices, the need to accommodate different programming languages and service dependencies and the need to test against the stack.

    The right tooling and automation are needed before shift left testing practices are scaled across the organization. In addition, a cultural shift may be required in order to help developers understand the ways in which shift left testing can expedite and improve the core functionality that they are developing.

    To apply valuable shift left testing practices in a microservices environment, organizations should consider using ephemeral sandbox environments. Using the right set of tools in a sandbox environment can enable development teams to test microservices throughout the SDLC. In doing so, organizations can ensure those services follow security best practices and perform exactly as intended, both independently and against the stack–all while reducing costs, speeding time to market and improving software quality and user satisfaction.

  • Index Tracks Impressive Growth of API-First Startups

    Index Tracks Impressive Growth of API-First Startups

    APIs are the building blocks of modern software, and their use continues to grow around the globe. A full 89% of investment into APIs will increase or stay the same over the next 12 months, Postman’s 2022 State of the API report found. And the evolving API-first approach is ushering in many innovations and startups into the field. This trend is epitomized by the latest research from GGV Capital, which maintains an API-First Index of leading developer-first software companies.

    The API-First Index tracks API-first companies that have raised $50 million in funding or more. And as of Q3 2022, the number of businesses that met this threshold increased to over 60. Just in Q3 alone, $350 million in funding was raised by companies on the index, and, in total, the index represents over $14 billion in funding. Undoubtedly, interest and investment in this space are expanding and will continue to increase in the year ahead. It’s a good area to keep tabs on, as the emphasis on modularity impacts how software is pieced together.

    I recently met with Tiffany Luck, partner at GGV Capitol, who oversees the API-First Index. Below, we’ll explore the index a bit more and get Luck’s viewpoint on why these findings represent a unique moment for API-first technology and business models as a whole.

    The API-First Index

    The API-First Index focuses on companies that serve niche functionally through APIs; also known as API-as-a-product. The list includes an assortment of API-based tools from FinTech, communications, health care, commerce and other sectors.

    For example, Stripe is likely the most well-known API-as-a-product, as it is commonly integrated as a way for businesses to accept payments. There’s also MessageBird, an API for sending notifications across any channel. Other examples include Mapbox, an API for geolocation data, Mux, an API for creating live and on-demand video experiences, Nylas, which offers a popular email API and Alpaca, an API for stock and cryptocurrency trading and many others.

    Currently, the index doesn’t include the entire API platform landscape of tools, which ranges from areas like API management to testing, documentation, monitoring, design, security and observability. There are also middleware integration platforms to consider as well. With these included, the list of well-funded API-related toolsets would surely be even longer.

    Why the Excitement About API-First?

    The number of people deciding to build API-first companies is rapidly increasing. These API-based web components are interchangeable and represent the future of software development. “The world is going toward web and cloud components,” said Luck. The trend represents a global movement with much effort reflected in Europe, Asia and the U.S. Furthermore, API models seemed resilient throughout ongoing economic uncertainty and the patchy VC funding of 2022. “APIs are holding up very well compared to the broader VC landscape,” said Luck.

    So, why is there so much excitement around APIs? Well, people are looking for best-in-class structural blocks that can be used to build common features like geolocation, AI, weather, payments or specific CRM functions. Niche APIs can swiftly deliver particular features without the bulk of a large platform. Another reason is that they’re relatively sticky—API-based delivery models are efficient at building a self-service platform that expands over time, which is a very keen prospect to investors, said Luck.

    Unicorn APIs Solve Hard Problems

    In evaluating API-first companies, Luck looks for those offering B2B solutions to super-hard, shared problems. This equates to reusable functionality that is difficult to build, maintain and scale individually. Furthermore, the solution must solve a need that’s common across companies but that is not core to their products.

    For example, Luck has her eye on a few impressive API-first use cases. Stream, for example, powers in-app user-facing features. Knock offers solutions for handling notifications. But many of the top most-challenging areas include financial services, as this functionality is difficult to build from a regulatory and connectivity perspective. Examples include Pinwheel, which aggregates real-time income and employment data. Method API does something similar but for aggregating consumer debts.

    Luck described APIs as a “modern way of accessing what would otherwise be technically inaccessible.” We’re seeing this action unfold in open banking, as new standards around the globe now mandate that consumer financial data be programmatically accessible, often in the form of an API connection.

    Developer Experience: The New Competitive Advantage

    In a competitive market surging with powerful developer-facing tools, non-functional aspects such as developer experience (DX), security, performance and reliability are becoming more of a focus. According to Luck, developer experience is probably at the top of the pyramid as it represents a catch-all for many of the aforementioned traits. Specifically, developer tools with high-quality DX have excellent documentation and must maintain backward compatibility to avoid breaking changes on the consumer side. “Ultimately, what you’re implementing impacts that customer’s end customer. Customers want zero negative impact and zero disruption,” she said.

    The API-First Index is good for the industry as it helps educate the public on private investing rounds. And as discussion around it increases, it brings awareness and visibility to the benefits of building API-first.