devopsy.kinsta.cloud

Category: DevOps Practice

  • How Are API Management and Service Mesh Different?

    How Are API Management and Service Mesh Different?

    The use of APIs and microservices is increasing—a recent study from F5 estimated that the industry is approaching 200 million total APIs. As organizations expand their use of APIs and microservices, they inevitably require some form of service management architecture. There are primarily two major design options for implementing this: An API management system or a service mesh.

    The key distinction between API management and service mesh can be framed using the four cardinal directions. API management is typically adopted for REST services that face external developers—referred to as north-south traffic. On the other hand, service mesh is more commonly used by internal suites of microservices to help control lateral, or east-west, communication. There are more nuances between each, as we’ll cover below, but this is essentially how they’re adopted in practice.

    However, this binary is becoming blurred as collections of enterprise digital applications expand and access to cross-company business domains begins to look and feel more like consuming a third-party SaaS. Furthermore, some suggest that with the right controls, service mesh can cater to external users in the same way API management does. What’s more, service mesh and API management are complementary—they can coexist within the same organization and even be deployed in the same projects.

    I recently chatted with Mark Cheshire, director of product at Red Hat, about the emergence of both API management and service mesh. According to Cheshire, both approaches accomplished similar goals but evolved very differently. Below, we’ll revisit why these two paradigms emerged and compare and contrast them. In a separate article, we’ll consider when it’s best to integrate them both.

    What is API Management?

    API management is most often associated with north-south traffic. By exposing your API to the outside world, you enable other developers to connect it to their systems and leverage your data and functionality like building blocks.

    API management arose in response to the rise of web APIs. API management is a broad concept encompassing many functions required to expose an API endpoint to the outside world. This can include authentication, authorization, request routing, documentation, rate limiting, monitoring, logging, monetization and life cycle management. A key goal is to make integration easier for the developer consumer. Architecturally, API management follows a gateway pattern. Consumers issue requests to the gateway which then performs routing to the underlying services.

    For APIs, the big catalyst was the emergence of Web 2.0, Cheshire explained. Numerous startups began consuming RESTful APIs to connect their web properties and partner ecosystems. Companies also found REST APIs to be a much more straightforward integration approach than SOAP and SOA. They also saw the ease-of-use benefits and adopted API-first designs within their internal infrastructure.

    As of 2021, over 70% of APIs are built for internal use. So, do all these services need API management? It depends. “If you communicate externally, you need API management,” explained Cheshire. But, it’s a grey area for services within an enterprise, he says, though inter-domain traffic often could benefit from API management.

    A diagram of API management capabilities, from 3scale
    A diagram of API management capabilities, from 3scale

    Strengths

    • Can enable north-south traffic
    • Protects the boundary of an application
    • Designed to ease external developer consumption
    • Potential for monetization, subscription plans
    • Typically plug-and-play; easier to support
    • Many solutions on the market
    • Developer experience and docs
    • Analytics and reporting

    Weaknesses

    • May be heavier than service mesh
    • Fewer open source options; vendor lock-in
    • Analysis paralysis in comparing solutions

    What is Service Mesh?

    Service mesh is most often associated with controlling east-west communication between internal services. Service meshes like Linkerd, Istio and Kuma make it easier to reimplement similar logic—such as networking, observability, traffic management, security policies and routing—across many microservices from a single control plane.

    Service mesh was born to address slightly different challenges than API management. “The transition from monolithic to microservices is all about east-west traffic,” Cheshire said. Companies found it slower to innovate monolithic applications and thus broke them up into microservices that communicate via APIs. But these microservices all needed similar operational capabilities, which would be cumbersome to repeat over and over for each service.

    “For one monolithic app blown into microservices, you may not even need a service mesh,” said Cheshire. “However, when you have hundreds or thousands, that’s when applying service mesh becomes critical.”

    Istio service mesh architecture
    Istio service mesh architecture

    Architecturally, service mesh is typically divided into a data plane and a control plane. The service mesh deploys a sidecar proxy that sits alongside each individual service. Istio, for example, utilizes the Envoy proxy. Other meshes like Linkerd use their own proxy.

    Strengths

    • Fits the microservices architecture paradigm well
    • Good for traffic routing; improving resiliency
    • NIST-recommended architecture for achieving zero-trust
    • Many open source options
    • Fits large microservices deployments

    Weaknesses

    • Requires a more hands-on approach
    • Potentially more maintenance to support
    • Unnecessary for a single service
    • Requires filter chain add-ons for north-south abilities

    Comparing API Management and Service Mesh

    API management is predominantly aligned with externalizing APIs to partners. When you do so, maintaining the contract with a consumer is more important to meet SLAs. Thus, API management commonly delivers life cycle management abilities, such as versioning. API management is necessary even if you are exposing a single API, as this service needs to be adequately documented and secured. That being said, these tenants can also be relevant to developers reusing software within an organization—there’s something to be said for adopting a product mindset when dealing with internal APIs.

    On the other hand, service mesh is more aligned with controlling internal networks. Microservices are rarely deployed alone; typically, multiple microservices make up an application. And, many more might exist throughout an organization for unique purposes. Service mesh thus helps maintain consistency throughout large networks of decoupled microservices. Service mesh is also a rapidly growing field, experiencing an explosion of new development and production use. A Cloud Native Computing Foundation (CNCF) report found that service mesh use rose in production by 50% in 2020 alone.

    To put the comparison another way, William Morgan, CEO, Buoyant described how API management is more about business logic, whereas service mesh handles intra-cluster operations:

    “API gateways typically handle ingress concerns, not intra-cluster concerns, and often deal with a certain amount of business logic, e.g. ‘User X is only allowed to make 30 requests a day’. By contrast, a service mesh like Linkerd is focused on operational concerns (e.g. instrument these calls and report their success rate; secure this communication between these pods) and purposefully avoids the mixing of business and operational logic; and focuses on communication between the services on the cluster.”

    Though service mesh and API management achieve slightly different aims, both layers make it easier to reuse web-based services. And, they certainly can be used in conjunction. For example, you could build API-first microservices with service mesh and simultaneously use API management to expose certain domains. In another article, we’ll consider when it’s best to integrate the two technologies.

  • Enabling Cloud Adoption in the Government

    Enabling Cloud Adoption in the Government

    In 2022, federal agencies are estimated to spend $7.8 billion on cloud computing. While this spending on cloud computing is necessary, it’s imperative that the government uses its allotted funding appropriately to leverage the cloud’s full potential and avoid common pitfalls.

    Avoiding Common Cloud Adoption Pitfalls

    I’ve frequently witnessed government agencies get locked into a cloud reseller that doesn’t give them the full capabilities offered by AWS, Google Cloud or Microsoft Azure. Most people outside of the federal market don’t realize that the government does not buy cloud directly from the cloud providers—apart from some very large contracts like the upcoming JEDI replacement contract vehicle, JWCC. They buy through a network of reseller partners that offer volume discounts and try to bundle managed services to help with cloud management.

    This approach gives the reseller, not the customer, the power to hold the keys to their kingdom—and can make it difficult for the customer to easily switch between cloud providers in the event of poor performance, lack of access or billing transparency. The federal government would benefit from keeping a small, but purposeful, cloud project management office (PMO) in-house. Thus ensuring that root access is available to all the accounts, subscriptions and projects to provide freedom to the agency to more easily change partners as their cloud maturity evolves.

    I’ve also seen government customers unfocused on the holistic end-user experience of actually using the cloud. The result is fragmented collections of different systems, processes and steps that cause engineers to be frustrated and inefficient. Customers must transform the end-to-end cloud provisioning process so that self–service is paramount and existing technology investments are seamlessly and transparently integrated to the end-user. When done correctly, innovation will be the byproduct, because focus can go towards developing the next generation of mission systems and tools—rather than trying to determine how to get a cloud account to begin a project.

    Three Steps Government Agencies Can Take to Get Value from Cloud Infrastructure

    Challenges exist, but there are proven steps the government can take to get the most value from their cloud infrastructure.

    • Define purpose: First and foremost, understand the purpose the cloud infrastructure intends to serve. Are you looking to reengineer cloud architecture, become more cost-efficient, or transform the innovation potential within your organization by introducing new services that can take you farther, faster? Understanding this purpose and your goals will go a long way towards success.
    • Quantify ROI: To get the best return on your investment, understand what resources are already available and which are necessary for your operations. To fully take advantage of the cloud, it is important to make sure basic costs are under control, such as ensuring AWS EC2 or Azure VM instances are not overprovisioned or underutilized. It’s equally important to make sure you take advantage of reserved capacity reservations for your predictable workloads; these can save you 30% or more. Last but not least, keep a focus on fully leveraging technology solutions to help bring all the pieces together in an integrated user-friendly experience across cloud providers.
    • Consider the outsourcing approach: Bringing in cloud resellers and contractors can provide guidance to your organization and help you make better choices. Just like building or renovating a house, agencies need general contractor-type companies that can help to manage and orchestrate the process of migrating to the cloud and all of its moving pieces. These contractors can also help to locate the various specialists required to get the job done for each unique situation. Long term, having a small, efficient cloud PMO is something every agency should strive to have in-house; however, given the demand for cloud engineering talent, the near-term focus should be to ensure flexibility into engagements with partners, so that they don’t hold back the potential of the organization.

    As digital transformation and cloud migration continue, it’s important for the government to stay on pace with its adoption. As of now, most agencies are still relying on manual steps to validate controls and get Authorizations to Operate (ATOs) approved. Making the simple swaps to more automated processes, learning how to leverage cloud resources to their full ability, and outsourcing operations to contractors can make acceleration easy.  There has never been a greater need for cloud enablement. The time to scale up is now.

  • EEEWW—Green iMessage Bubbles | ‘Great Resignation’ Redux | Faster Firefox 96

    EEEWW—Green iMessage Bubbles | ‘Great Resignation’ Redux | Faster Firefox 96

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

    This week: iMessage lock-in lessons, attrition-rate fixes, and more on Mozilla.

    1. ‘Never Date a Green Texter’

    First up this week: The weekend story getting the technorati chattering was about how Apple iMessage denizens pour scorn on Android users—identifying them by their “icky” green chat bubbles. An iPhone user’s message gets a “proper” blue background, y’see.

    Amusing though the story was, the writer seemed to be hell-bent on proving some sort of Apple C-suite-led “conspiracy to lock in.” The reality is far more mundane—but it teaches important lessons for DevOps.

    Analysis: Unintended consequences FTW

    Could your DevOps team make a trivial engineering decision that pays unexpected dividends? While lock-in might be distasteful, seemingly irrelevant design or technical choices can have huge ramifications with users.

    Tim Higgins: Why Apple’s iMessage Is Winning

    [The] pressure to be a part of the blue text group is the product of decisions by Apple executives starting years ago that have … helped to cement the iPhone’s dominance among young smartphone users. [It] encourages people to pay the premium … and remain loyal to its brand.
    …
    Teens and college students said they dread the ostracism that comes with a green text. The social pressure is palpable. … Jeremy Cangiano, who just finished up his MBA, … tried to cash in on it last year by selling his own merchandise that touted, “Never Date a Green Texter.”
    …
    The blue iMessage bubble was born out of a simple engineering need, according to Justin Santamaria, a former Apple engineer who worked on the original feature. … The idea that it would keep users locked in to using Apple devices wasn’t even part of the conversation at the time, he said.


    And then the other shoe dropped—via Ron Amadeo:

    Google took to Twitter this weekend to complain that iMessage is just too darn influential with today’s kids. … The company is hoping this public-shaming campaign will get Apple to change its mind. [But it] probably has the least credibility of any tech company [because it] has released 13 half-hearted messaging products since iMessage launched in 2011.
    …
    Google … seems to have learned nothing from its years of messaging failure. Today … the situation is an incredible mess, and no single Google product is as good as Hangouts was in 2015.


    Ouch. With a sociological perspective, here’s Christina “filmgirlcw” Warren:

    iMessage is incredibly popular with certain demographics. … It’s an in-group signifier—the way teens have always had in-group signifiers (when I was in high school, it was AIM, a Nokia, and wearing Abercrombie). … It’s always fascinating for me to go to other countries and see a ton of iPhone users not using iMessage but something else because that app has become the in-group signifier. … Every teen I know uses Discord more than they use almost anything else.
    …
    It isn’t about lock-in or regulation or technology. It’s about fashion.

    2. How’s your Attrition Rate?

    A study published this week says DevOps orgs and other internet companies rank third for attrition in the 38 industries surveyed. And if you lump that category together with “enterprise software,” it would be in clear first place.

    Analysis: We’re #1! Oh, wait …

    But some companies get this right—how can you be one of them? Culture, innovation, recognition and remote work. It’s definitely not only about pay.

    Donald Sull, Charles Sull and Ben Zweig report their fascinating study: Toxic Culture Is Driving the Great Resignation

    Between April and September 2021, more than 24 million American employees left their jobs. [But] while resignation rates are high on average, they are not uniform … from less than 2% to more than 30%. … More-innovative companies … are experiencing higher attrition rates than their more staid competitors.
    …
    Pay has only a moderate impact on employee turnover. … A toxic corporate culture is by far the strongest predictor of … attrition and is 10 times more important than compensation. … Job insecurity and reorganizations are important predictors of how employees rate a company’s overall culture. … But it is surprising that … the more positively employees talked about innovation at their company, the more likely they were to quit. … Employees are more likely to leave companies that fail to distinguish between high performers and laggards [or] that tolerate underperformance.
    …
    Our analysis identified … actions that managers can take … to reduce attrition. … Lateral career opportunities are 12 times more predictive of employee retention than promotions [and] 2.5 times more powerful [than] compensation. … Company-organized social events, including happy hours, team-building excursions [and] potluck dinners … are a key element of a healthy corporate culture. … Unsurprisingly, when employees discussed remote work options in more positive terms, they were less likely to quit.


    And the flipside of resignation? Hiring replacements. Let’s turn to the equilibrium of Nash Reilly:

    It’s only gotten harder in recent months [and] I think I know why. … You need to offer engineers some combination of these three things to pique their interest: Cool stuff to work on, smart people to work with [and] some degree of repeatability.
    …
    You can’t really prove to an engineer that you can give them things like good management, minimal churn, and decision making authority [so] let them talk to your employees. … Also, figure out a way to let your team “backchannel” to the candidate. [If] your product is not that cool … play up the things you can offer them: smart coworkers, and a stable working environment. … You can afford to be honest about what it is that you do offer to a candidate, [so] pitch them the truth: that you want to do good work, sustainably, for as long as you can—ideally with them on your team.


    Perhaps the smart money is already skating to where the puck will be? Here’s echelon:

    Engineering salaries are … one of the biggest expenses. … Companies love that they can now hire remotely and pay adjusted cost of living. They’ll hire as many workers in middle America as they can, and once enough of the workforce is concentrated outside of expensive cities, you’ll see them stop hiring in SF and NY entirely. [And] startup capital is already beginning to shift to … emerging markets. Employment will eventually head there too.
    …
    Make your money now while the iron is still hot.

    3. Say Something Nice About Firefox

    After accusing Mozilla of jumping the shark last week, perhaps I owe the Firefox folks a positive inclusion this time? The release notes for Firefox 96 certainly sound good.

    Analysis: Improved sound; better perf; stronger anti-CSRF

    Outside the Apple walled garden, Firefox is about the only non-Chromium browser. A browser monoculture can’t be a good thing for anyone—not DevOps nor users.

    Michael Gariffo: Firefox 96 update focuses on noise improvements, main thread efficiency

    On the desktop side of things, Mozilla’s latest release made “significant improvements” to the browser’s built-in [sound] noise suppression and auto-gain-control features. These improvements are aimed at web-based video chat users.
    …
    The second tentpole feature in version 96 focuses on reducing main-thread load, which should help the browser function better on older, slower, or congested systems. [And] a new enforcement setting for cookies … will, by default, apply the “Same-Site=lax” policy. Mozilla claims this will help better defend users against Cross-Site Request Forgery (CSRF) attacks.
    …
    Mozilla also acknowledged that it is working on correcting the performance of detached videos being played in full screen on macOS devices. … No timeframe was mentioned for when it might be available again.


    Okay. Sounds good. But not to Tetch:

    Never mind all that fancy stuff. … Any reduction in crashes?
    …
    FF crashes for me several times a month. … I always take the trouble to fill in the “What were you doing immediately before the crash?” section of the crash submission dialog, and never hear another thing.


    But more efficiency on the main thread? Tell me more. ksec:

    Such an important detail that deserves at least few more sentences of marketing message or explanation. But the whole release note just feels like they couldn’t be bothered anymore.

    The Moral of the Story: A weasel wishing Happy New Year to a chicken harbors no good intention.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Moritz Knöringer (via Unsplash)

  • Continuous Delivery Challenge Looms Large in 2022

    Continuous Delivery Challenge Looms Large in 2022

    As 2022 kicks off, it’s becoming apparent that the major DevOps challenge organizations will face is mastering best practices that enable continuous delivery.

    A global survey of more than 19,000 software development professionals conducted by the Continuous Delivery (CD) Foundation found 44% of respondents use either continuous integration or deployment. However, less than one in five (18%) use both practices to automate the entire software delivery life cycle. Continuous integration is currently the most popular DevOps-related activity (32%) followed by continuous deployment at 29%, the survey found.

    The survey also found that only 14% of respondents said, on average, that they can go from code checked-in to successfully running that code in production in one day. Just 10% said they routinely deploy code to production each day. Nearly a third of respondents said they still manually approve code deployments to production.

    Tracy Miranda, executive director for the CD Foundation, said it’s clear there is a need for a better understanding of continuous delivery as a distinct DevOps discipline that stands apart from continuous integration processes. While the two DevOps practices are complementary, she noted that continuous delivery requires a level of engineering expertise that many developers either lack or are simply not interested in gaining.

    In fact, the survey found more than a quarter of respondents (26%) are not involved in DevOps-related activities at all. At the same time, however, the survey revealed that 80% of respondents that work for companies with two or more employees are involved in DevOps to some degree. Nearly 60% of enterprise developers that participated in the survey employ a continuous integration/continuous delivery (CI/CD) platform, as opposed to 48% of developers working in small businesses and 42% of contractors. However, it’s clear from the survey results that much of that activity is focused on continuous integration rather than continuous delivery.

    The survey revealed, for example, that less than a quarter of respondents (23%) are involved in infrastructure provisioning and management at all. That compares to nearly a third (32%) that are involved in application and infrastructure monitoring. Only 20% are involved in creating automated tests, Collectively, the survey results make it clear there is still a long way to go in terms of shifting responsibility for DevOps practices further left toward developers.

    One reason continuous delivery is so challenging is that automating deployments across platforms has never been especially easy. Each platform tends to be customized to the point where it is difficult to automate application deployments. In effect, each platform is its own unique type of “snowflake.”

    However, with more attention focused on the integrity of software supply chains in the wake of a series of high-profile breaches, Miranda noted that automating software delivery will play a major role in achieving automation goals by reducing the need to rely on manual processes that are more easily compromised.

    At the same time, more organizations are starting to embrace Kubernetes clusters—this can simplify automation of software delivery across a set of platforms that all share a common application programming interface (API), she noted.

    The growing complexity of application development projects, coupled with increased reliance on software to drive digital business transformation initiatives, will also accelerate the adoption of continuous delivery best practices, added Miranda.

    One way or another, application deployment in 2022 is shaping up to be a lot more automated than it was in previous years. The only thing left to be determined now is the degree to which that goal can be achieved.

  • Shift Left: Right or Wrong?

    Shift Left: Right or Wrong?

    The term DevOps emerged into mainstream software development communities roughly 10 years ago. It represented a combination of tools and techniques which helped solve many pertinent issues of the time, namely responsibility for code in production and lack of a positive feedback loop. As of today, DevOps is a massive movement. It is considered the default way in which software development should be practiced. It has allowed even small teams to function with the same efficiency as much larger ones. Several engineering teams have adopted derivative approaches of the DevOps methods in order to suit their niche workflows.

    The Dark Side Of DevOps

    DevOps in practice presents a lot of tangible benefits to software engineering teams. Automation, transparency, and velocity are the chief advantages. From a business perspective, engineers are now more invested and accountable for the experience of users. The era of “Your Success Is Our Success” has finally arrived for engineers—and business teams couldn’t be happier. 

    For the individual developer, the number of things they were responsible for was piling up. More objects to monitor in production. As more features were getting built and deployed, alarms from internal systems kept going off more frequently. Individually, an engineer became responsible for the behavior, performance, security, compliance and so many other aspects of the application and underlying systems. Often, this became a distraction and began to defeat the very purpose of the DevOps methodology which meant to remove hurdles that were in the way of developers. 

    This is DevOps done wrong. Lack of maturity within software engineering teams has caused a lot of people to go down a DevOps path that is toxic and consequently forced engineers to burn out quickly. The core tenet of DevOps is to enable engineers to do more, but not to the point where they’re having to undertake enormous toil. DevOps still recognizes two distinct forms of specialized effort – software development and platform operations. The nature of services, scaling, and security may vary the degree to which dev and ops responsibilities converge. 

    Dev-Oops: It Goes Wrong Over Time

    Interestingly, engineering teams view DevOps as development, and “everything else”. From the time a developer checks code into version control, there is a large assortment of workflows that kick in. Ideally, there is testing, integration, more testing, deployment and feedback. This is a large body of work, often underestimated and underrepresented. To pile this responsibility onto members responsible for development alone is where things begin to go wrong. Often, as a product ages, incident management, maintenance, and other engineering efforts pile up–resulting in fewer cycles being available for product development over time. 

    There is also the complementary case, where engineering teams are focused on product development and assign most free cycles to it. Platform operations are forced to become a watered-down effort and consist of the bare minimum it takes to keep the lights on, so to speak. This is a common observation in small teams and startups that typically have a new product release. 

    When implemented correctly, DevOps must allow engineers to take responsibility for all aspects of developing a feature and managing it in production. This means that programming the business logic, creating the declarative and non-declarative software, binding with services, building the artifact, and finally deploying to production all come under the gamut of a developer. In addition, a feedback loop—created by baking observability into the mix will provide insight into the health of the service (or feature)—will require the engineer to stay on top of the operational aspects of performance and reliability. 

    The current definition and practice of DevOps originated from Agile methodologies. They take off from the limitations of typically Agile teams which were released in “sprints”, still kept dev and ops efforts separate, and were agnostic of underlying tech. DevOps, on the other hand, is more tightly-coupled with the technology employed, for example: Microservices and automation. It facilitates continuous deployment and a high frequency of releases. Most importantly, it converges the notions of development and platform operations. We find that the interpretation of this “convergence” is what differentiates good implementations of DevOps from bad ones. 

    The Right Kind of Shift Left

    At the heart of healthy DevOps adoption lies a technology shift complemented by a cultural shift. The fundamental principle that belies successful teams is a great developer experience. Irrespective of the infrastructure that powers the technical stack of a web application, software engineers who work on it need to be able to develop and deploy with ease. Let’s explore how. 

    Examples of tools that aid engineers during the development phase include IDEs, Source Control, TDD suites, documentation generators, and many more. Tremendous amounts of research and product development are currently underway in enabling developers to program better and facilitate more efficient development. 

    Different skill sets and focus areas are required to optimize different portions of the operations spectrum. In the case of large enterprise organizations, the dichotomy is clear. There are Platform Operations teams that are responsible for keeping all the systems running by providing automated means to set up and sustain reliable systems on the server side. Application Development teams are tasked with creating the applications, API endpoints, integrations and various other artifacts that will enable users to execute their tasks. 

    Because of the common underlying nature of both these functions–writing software–they tend to cross-pollinate. This coalescing is welcome, provided it is managed well. This is where abstractions come in handy. In particular, PaaS abstractions that provide in equal parts agility and intransigence. Pliant enough to accommodate custom workflows and bespoke needs of software products and teams, and yet preventing needless osmosis between Dev and Ops responsibilities, ultimately resulting in a superior developer experience as the nucleus of this atomic transformation.

    PaaS With Flying Colors

     

    The PaaS-low’s Hierarchy! 

    The perfect balance can only come from PaaS systems that comprise an architecture that is modular and offers the functionality of application build and deployment. The ability to work across multiple languages and frameworks combined with packaging and deployment best practices is a basic tenet. Abstracting the underlying infrastructure to favor support for container-based artifacts and orchestrating them at scale is the next most desirable component of a PaaS framework. A batteries-included approach to automating continuous delivery, security best practices, and other workflows goes a long way in ensuring that the PaaS substrate works for all kinds of developer needs. When using abstractions, the biggest opacity comes in the form of a lack of production parity. If the PaaS can be functional on all staging instances viz. dev, test, pre-production, prod, or any other remote instances, it would save tremendous toil arising from a lack of parity. 

    Bonus points for being open source and accommodating compliance, policy mandates, and customization to suit the dynamic needs of different organizations. An active community supporting the ecosystem and driving innovation and change management would make a more compelling case for PaaS tools. 

  • CNCF Takes LitmusChaos Platform to the Incubation Level

    CNCF Takes LitmusChaos Platform to the Incubation Level

    The technical oversight committee (TOC) for the Cloud Native Computing Foundation (CNCF) announced today it is elevating the open source LitmusChaos application testing platform to the incubation level.

    LitmusChaos is a chaos engineering platform donated to the CNCF by ChaosNative in 2020. Since then, it has seen adoption within production environments by more than 25 organizations, including Intuit, Lenskart, Orange, Red Hat and VMware.

    ChaosNative CEO Uma Mukkara says LitmusChaos was developed to provide DevOps teams with a chaos engineering platform built using containers that makes it easier to scale up and down than existing monolithic alternatives. The platform itself, however, can be used to test both monolithic and microservices-based applications.

    The platform consists of a Chaos Operator based on a software development kit (SDK); a ChaosHub for hosting and sharing experiments; Litmus Workflows that declaratively chains experiments (either in sequence or parallel) to build a chaos scenario; a centralized control plane, dubbed ChaosCenter, to design, schedule and monitor Litmus Workflows; Litmus Probes for creating chaos scenarios that automate steady-state validation and remediation actions and a Chaos Observability tool to export Prometheus metrics.

    In total, there are now more than 400 contributors to the LitmusChaos project and more than 4,000 pull requests have been made. Mukkara said since the beginning of this year, Litmus operator installations have grown to more than 2,000 per day. Going forward, the goal for 2022 is to significantly increase the number of LitmusChaos integrations there are for a wider range of DevOps platforms, added Mukkara. Additional sets of experiments for Kubernetes and non-Kubernetes targets, improved observability and integration with other platforms—via the open source OpenTelemetry agent software also being advanced by the CNCF—is also planned.

    In general, it’s still early days as far as the adoption of chaos engineering with DevOps workflows is concerned. However, Mukkara said that as more organizations embrace observability to better understand IT processes, the number of organizations that also use chaos engineering to test IT resiliency should also increase. In fact, as IT environments become more complex—thanks mainly to the rise of microservices-based applications—chaos engineering approaches to testing may someday be required, noted Mukkara.

    In the meantime, there are still a lot of IT professionals that are uncomfortable with chaos engineering approaches to testing that deliberately break underlying services to test the resiliency of an application. The core idea, however, is that no application should have a single point of failure that could lead to it becoming unavailable. In theory, a microservices-based application won’t fail because when a service becomes unavailable calls are automatically rerouted to another service. The performance of that application will degrade, but it won’t go offline. The challenge is that building an application that achieves that level of resiliency using microservices requires a significant amount of DevOps expertise.

    Regardless of how an application is constructed, the one thing that is clear is how dependent organizations are on applications to drive revenue. As such, the tolerance for application failures—or performance degradation—has never been lower.

  • How Low-Code Enables the Composable Enterprise

    How Low-Code Enables the Composable Enterprise

    Enterprises know that their customers and partners expect a superior personalized experience. After all, customer experience has been a top priority for organizations over the last decade. However, despite all the technological advancements and transformation initiatives, the ability to deliver innovation with speed continues to elude. 

    Without this ability, enterprises constantly play catch-up with rapidly shifting business dynamics and customer expectations.

    Why is Strategic Agility so Elusive?

    Enterprises are unfortunately locked in a situation that Gartner Research identifies as “static application experience”. It is a paradigm of rigid and bloated application architecture, creating inertia that organizations find difficult to navigate around. This technological impedance is one of the primary reasons (besides organizational culture and structural challenges) at the root of organizational sluggishness.

    To adapt to the challenges of the modern world, enterprises need to move from a static application experience to a more dynamic one. This can be achieved through the approach — wrapped around a goal — of a composable enterprise.

    Composable Enterprise is the Future of Applications

    A composable enterprise aims to create an application architecture wherein enterprises can deliver various functions through composition (as against development), by leveraging packaged business capabilities (PBCs). Gartner estimates that by 2023, 30% of new applications will be delivered, priced, and consumed as libraries of packaged business capabilities, up from fewer than 5% in 2020.

    To be fair, this run-up to a composable enterprise is not a fresh-of-the-press revelation. Enterprises have been attempting to move from hardcore coding-based development to a more service-and-composition-oriented architecture over the last couple of decades, albeit only in pockets and not as fast as they would have wished.

    Composable enterprise has become the need of the hour. And this is being driven by the sense of urgency created by multi-faceted disruption across industries, coupled with technological advancements that make it possible for organizations to accomplish it at an enterprise scale. 

    One such advancement comes in the form of low code digital transformation platforms.

    How do Low-code Platforms drive Composable Enterprise?

    According to Forrester Research, low-code development platforms are emerging as a key strategy to accelerate app delivery to support digital business transformation. They have the potential to make software development as much as ten times faster than traditional methods. Low-code platforms use visual composition and a modeling-based approach to speed up application development. 

    A good low-code platform drives the creation of a composable enterprise in two ways, both of which are critical for long term sustainability:

    • By enabling rapid development of modern PBCs that deliver cutting-edge functionality without having to rebuild the organizational core, thereby protecting decades of investments in legacy and core applications 
    • By providing the core capability to create applications through composition and abstraction with a modeling-driven application environment, wherein the organization can create customer-centric business applications that deliver a dynamic omnichannel experience and drive the end-to-end customer journey

    Is There a Catch?

    Low code platforms come in various shapes and sizes, from those supporting the creation of relatively simpler stand-alone applications to those that enable the rapid development of mission-critical enterprise-scale applications with various functional components. Mostly, the latter category forms the core of a composable enterprise.

    To drive a composable enterprise, a low code platform needs to be equipped with a variety of capabilities. It should: 

    • Speed up pro-grade development through modular, modeling-driven, and abstraction-oriented development
    • Support a variety of business and technological needs, such as workflows, content management, straight-through transactions, mobile apps, collaboration, customer self-service, omnichannel customer engagement and automated business rules
    • Offer service-oriented integration that can extend beyond the organizational boundaries
    • Enable rationalization of application portfolio by helping avoid the introduction of multiple point-solutions in the mix with its own ability to develop a variety of applications quickly
    • Prevent shadow IT through central governance, visibility, and guardrails, without hindering innovation
    • Enable agile, continuous integration/continuous delivery (CI/CD) and adherence to quality standards and architectural requirements
    • Enable, even catalyze, change with traceability, thereby ensuring long term sustainability of business applications

    What Next?

    The ability of organizations to accomplish a composable enterprise of the future will depend on a multitude of factors. It is essentially a transformational journey.

    It is important to take the right steps and build in phases, starting from establishing a core low code platform and building peripheral capabilities with time. Picking the right set of applications and establishing early wins go a long way in building momentum towards the long-term goals.

    Identification of the right low code platform that can drive your transformation journey to a composable enterprise is critical for achieving a composable enterprise.

  • Step Aside, Monoliths: Meet the Composable Enterprise

    Step Aside, Monoliths: Meet the Composable Enterprise

    A composable enterprise, defined by Gartner as “an organization that delivers business outcomes and adapts to the pace of business change”, relies on the assembly of interchangeable application building blocks. This architectural overhaul has largely been driven by a demand for more configurable application experiences, and the need to evolve existing application portfolios that are often too risky and costly to replace.

    New business opportunities require agility from application portfolios; however, many enterprises are still limited in their ability to adapt. Why? They rely on monolithic ERP systems and cumbersome legacy applications with static processes and haphazard structures. A modular setup can enable a business to rearrange as required depending on external or internal factors, such as shifts in consumer attitudes or sudden supply chain disruptions. Organizations are experiencing these shifts now and require a new approach to enterprise applications to be able to adapt. 

    Bridge the CX Gap with Greater Composability

    A composability approach is the best way to capture all the advantages of modern enterprise software. According to a recent Boomi report, by 2023 organizations that have adopted a composable approach will outpace the competition by 80% in the speed of new feature implementation. This shift requires enterprises to rethink how they architect their operations, harness a combination of packaged functions and technologies and successfully deliver seamless moments of service to their customers.

    There are three key ways that businesses can make the composability shift:

    • Adopting a service mindset
    • Scaling the delivery of microservices
    • Packaging business capabilities using Application Programming Interfaces (APIs). 

    1. Designing for Service: Compete on Outcomes, not on Products 

    A composable enterprise whose portfolio is made up of heterogeneous applications from a palette of best-of-breed solutions allows organizations to address key inflection points throughout every customer, product or service lifecycle.

    As more consumers demand continuous value and reliability throughout an asset’s lifetime, businesses must shift to selling outcomes and experiences instead of products to meet these new expectations for quality service. This requires each part of an operation to align, not around immediate sales or revenue, but around delivering a quality Moment of Service™ — the inflection point where everything comes together to create better value and outcomes for customers. 

    Moving to a servitized model requires a composable stack to deliver services to order. At a systems level, this transformation requires organizations to adapt applications dynamically and deliver positive customer experiences with effective quality management, customer support, and access to complete information about the service offering. Unlike traditional enterprise software, this involves connecting data and applications that have often sat in separate silos. A composable enterprise can provide a service-orientated architecture, that enables businesses to become outcome-based and ready to quickly adapt to future disruptions. 

    2. Scale Component-based Architecture with Microservices

    If applications are built as loosely coupled services, then companies can employ a composable architecture to capitalize on independently deployable modules that are organized around business capabilities. This allows organizations to swap modules in and out, to suit emergent needs and build a well-structured best-fit solution for their unique business. 

    In contrast to a monolithic architecture, businesses can easily add resources to the most needed microservice rather than having to scale the entire application as demand for an application increases. In practice, this allows businesses to simplify customizable workflows and optimize business processes while leveraging and applying tools such as robotic process automation, artificial intelligence, or the plethora of hyper-automation capabilities available today.

    3. Embrace Open-ended APIs to Maximize Data-sharing Capabilities

    Packaged business capabilities (PBC) assembled using APIs are the foundation of every composable enterprise. They are used by businesses to secure data across cloud services, business systems and mobile applications. Historically, APIs have been used in monolithic applications to exchange data between the entire application and external applications and services. In composable software, APIs exchange data from individual modules to external applications and within the application — from module to module. This has significant implications for how systems are designed and built.

    APIs can provide a controlled and consumable method for connecting and sharing consumer and business data by creating experiences tailored to individual needs. For instance, an API-centric model can secure and manage data access to help businesses with faster decision-making and deliver relevant new services adaptable to market changes. In the future, there will be more automated continuous process improvements as machine learning models recommend, or even proactively make, process changes to improve outcomes for the business and end customer.

    Opt-in to the Composability Evolution

    To overcome the limitations of monolithic applications, businesses must rethink their approach to enterprise applications — starting with the business architecture and technology stack. A composable software architecture enables organizations to address the internal and external pressures that send shockwaves throughout the value chain. 

    As a composable enterprise, organizations can re-engineer their businesses to ensure customer touchpoints and stages come together for better moments of service, but companies must be certain that processes are optimized across each of these inflection points to mitigate issues and fuel growth. An IT architecture built on a foundation of composability will be essential to the successful delivery of a software-powered business development strategy that can provide continual value to customers and the business itself. 

  • Open Source Observability Comes of Age in 2022

    Open Source Observability Comes of Age in 2022

    Observability is growing in importance to meet envisioned business objectives. Despite the benefits to performance data, organizations have faced challenges in realizing the full potential of observability based on implementation, distributed software tools, and other technological hurdles. But with new innovation, the era of true observability is upon us.

    Innovative changes

    The open-source observability landscape, in particular, is going through a phase of innovation. Powered by distributed tracing “coming of age” with OpenTelemetry, and eBPF taking center stage in terms of restructuring as the next frontier of observability and monitoring on Linux, innovation is at an all-time high. 

    Kernel technology

    Extended Berkeley Packet Filter (eBPF) has presented a fascinating technology native to the Linux kernel. Born with the intent of having a programmable way of dealing with networking, eBPF has evolved into a rather generic and performant facility to have safe, dynamic access to the Linux kernel, that enables, among many other things, to extract telemetry for observability and security purposes. eBPF is powerful and growing in popularity, and Microsoft has been working on a port to Windows.

    Versatility

    In terms of observability, eBPF proved to be remarkably versatile in 2021. For example, there are tools that use eBPF to perform distributed tracing, like the Pixie project that was open-sourced in mid-2021 by New Relic. But the most promising aspect of eBPF for 2022 is the fact that it is possible, with eBPF, to implement continuous profiling of applications in production. Examples of this are the aforementioned Pixie project and Parca. As proven by tools like Google’s Cloud Profiler and various commercial observability tools, having a low-overhead, always-on profiler in production is a powerful way to troubleshoot latency and memory issues in production environments, which are notoriously hard and time-consuming to reproduce in test labs.

    Clear differences

    While production profiling with eBPF is happening now, it is not yet a general capability for use with most applications. The way profiling works is surprisingly different across different runtimes and programming languages. While pretty much all of the languages behave similarly in terms of using the CPU and allocating memory (and even in such foundational computing matters, there are differences), the way process concurrency is notably different, pretty much across the board. 

    For example, Java is using threads inside the Java Virtual Machine that are mapped to threads in the Operating System (to be fair, there are also other options, like NIO and libraries like RxJava, Reactor, Vert.x, plus Project Loom will eventually ship). In Node.js, on the other hand, concurrency is mostly dealt with the Event Loop, and “real” threads at the Operating System are abstracted away from the developer. Differences like these matter for a profiler, because the data shown to the person troubleshooting an issue must be “translated” to the model for concurrency used by the programming language, and this requires explicit support in the profiler for specific runtimes.

    Open source observability comes of age in 2022

    Fortunately, 2022 is going to be the year that brings us full-featured, open-source, eBPF-based production profiling tools that understand the specifics of the many runtimes that are prevalent in today’s cloud-native applications, like Java, Node.js, Python and .NET, as well as compiled languages like Go and Rust. And that will be a game-changer for improving software and solving issues faster, for all DevOps and SRE and operators.

    As we look out to the year ahead, revolutionary technology like eBPF means the rate of innovation happening at the operating system level is only picking up and setting the stage for the year of true observability. 

  • DevSecOps Will Cross the Chasm in 2022

    DevSecOps Will Cross the Chasm in 2022

    We’ve been talking about DevSecOps and shift-left security for years. Although this approach probably didn’t “cross the chasm” in 2021, we did see some very telling milestones. Cybersecurity VC funding surged to record heights with a focus on DevOps and cloud security and the need for DevSecOps became glaringly evident with the Log4j vulnerability. On a more personal note, our own open source security project Checkov has surpassed three million downloads.

    Much of this momentum was inevitable. Those in infrastructure and reliability circles have already been adopting and touting the benefits of shifting left and automating as much as possible, so in many ways, it’s expected that security would follow suit. Undoubtedly, the pandemic has also accelerated the need for developers to work more autonomously without having security personnel and processes acting as barriers to productivity and velocity.

    We’re confident that 2022 will see the silos between development and security teams continue to crumble as developer-led security practices become the norm for cloud-native organizations.

    DevSecOps finally crossing the chasm doesn’t mean that every enterprise and traditional organization will shift security left and adopt security best practices. It will, however, give them competitive advantages over those who don’t—both in decreased security costs and increased developer productivity and, thus, time-to-market.

    What else is in store for the future of DevSecOps?

    Rise of the DevSecOps Job Title

    Fewer than 5,000 people on LinkedIn currently have “DevSecOps” in their job title, yet there are over 20,000 current openings for DevSecOps roles. In 2022, expect to see more of those positions filled. This means security teams across industries will conduct fewer manual security audits, there will be a considerable influx of homegrown DevSecOps tooling and point solutions will likely begin to consolidate into single platforms. 

    Blurred Lines Between Application and Infrastructure Security

    Until recently, application security was a very well-defined (albeit fractured) space focusing on securing the custom code and open source packages that make up applications. However, with the rapid adoption of cloud-native applications, the lines between application and infrastructure security are blurring. We expect to see this trend continue as more engineers take on more infrastructure-related projects, vendors start catering to use cases outside of their core competencies (through acquisitions and in-house development) and the role of DevSecOps continues to expand within organizations.

    Infrastructure-as-Code: The Great Cloud Migration’s Next Chapter

    We’ve been talking about the great migration to the cloud for years. At this point, many companies are ready to move on to the next chapter: Infrastructure-as-code (IaC). As a result of this trend, DevSecOps will become much more important, as security needs to be baked earlier in development phases or risk being left behind. In addition, security teams will need to become more well-versed in development technologies and practices to provide the proper guidance for the new way applications are built and deployed. 

    More Software Supply Chain Attacks

    Hackers have been targeting retailers and security vendors for years, exploiting a minor weakness to gain access and move laterally into sensitive data. In the past year, however, software supply chain attacks stepped into the spotlight due to multiple supply chain attacks. We expect this trend to continue, which will, in turn, put more focus on securing supply chains. DevSecOps, which has focused mostly on tools and practices for securing the code and infrastructure, will expand to include the supply chain mechanism. 

    If 2021 was the year of hype for DevSecOps, we believe (and hope) that these best practices are embraced en masse across industries. The benefits of shift-left security are well documented: The number of high severity incidents is significantly reduced, the potential attack surface is minimized, compliance efforts are simplified and the time to remediation is lowered. Organizations also save money by catching misconfigurations and vulnerabilities earlier in the software development life cycle while at the same time gaining time back with tools, both open source and commercial, that are empowering developers to move fast and build applications that are more secure and reliable.