As we continue to navigate the digital landscape, it is clear that every innovation brings with it a wealth of opportunities as well as a host of challenges. One of the most prevalent trends in today’s tech world is the increasing reliance on cloud-based applications. These applications offer flexibility, scalability and reliability but also introduce complexity, mainly when operating in multicloud or hybrid environments. We must adopt a fresh perspective to manage this ever-evolving IT ecosystem effectively.

In this blog post, I want to explore a transformative concept that could redefine the way we manage our business applications: the integration of the software bill of materials (SBOM) and infrastructure bill of materials (IBOM).

SBOM and IBOM: A Unified Approach to Tech Management

Traditionally, an SBOM serves as an inventory list detailing all components of software, including libraries and dependencies. It plays a crucial role in managing software updates, ensuring compliance and facilitating informed decision-making. However, in today’s intricate application landscape, having knowledge of the software alone is insufficient.

This is where the concept of the IBOM comes into play. An IBOM is a comprehensive list of all critical components a business application requires to run, including network components, databases, message queuing systems, cache layers systems, cloud infrastructure components and cloud services. By integrating an SBOM and an IBOM, we can better understand our application environment. This powerful combination enables us to effectively manage critical areas such as security, performance, operations, data protection and cost control.

The last few decades delivered great advances in infrastructure; now, it’s time to build apps that make the most of those new tools. VMware Tanzu helps you build new apps, modernize existing ones, and evolve your development process around cloud native technologies, patterns, and architectures.

Learn More

The latest from VMware Tanzu

The Business Benefits of SBOM and IBOM Integration

The integration of an SBOM and an IBOM offers numerous benefits that can enhance various aspects of business operations:

• Security – A comprehensive view of both software and infrastructure components allows organizations to identify potential vulnerabilities early on. This level of visibility is critical for bolstering data protection and reducing overall risk. In essence, complete visibility acts as a safety net, enabling businesses to safeguard their digital assets from threats.
• Performance – Detailed knowledge of software and infrastructure components can significantly enhance application performance. Improved performance translates into superior customer experiences and more efficient business operations, ultimately leading to increased customer satisfaction and profitability.
• Operations – A complete view of all application components facilitates effective operational planning. This not only simplifies the deployment and maintenance of applications but also streamlines workflows and boosts operational efficiency.
• Cost Control – The granular information provided by SBOMs and IBOMs enables businesses to make informed decisions, optimize resource utilization and manage costs effectively. By strategically deploying resources, businesses can eliminate unnecessary expenditures and invest in areas that offer the highest value.

Navigating the Complex World of Cloud-Based Applications

The rise of homegrown applications has led to a significant increase in the number of applications that need to be managed. Coupled with the shift toward cloud-based applications and the complexities associated with multicloud or hybrid environments, this trend underscores the importance of having a comprehensive SBOM and IBOM.

Without a thorough understanding of their application landscape, organizations may find it challenging to manage and prioritize operational and security tasks. SBOMs and IBOMs are indispensable tools for effective control and management in this rapidly evolving applications and infrastructure era.

Embracing the Future of Automation and Integration: The Role of GitOps

The future of business applications presents exciting opportunities for automation and integration. As the complexity and scale of applications continue to grow, manual management is becoming increasingly challenging. Automating the creation and maintenance of SBOMs and IBOMs is crucial to keeping pace with the rapidly changing tech landscape.

One of the most promising approaches to this automation and integration is GitOps. GitOps is a paradigm or a set of practices that empowers developers to perform tasks that typically fall under IT operations’ purview. GitOps leverages the version control system as the single source of truth for declarative infrastructure and applications, enabling developers to use the same git pull requests they use for code review and collaboration to manage deployments and infrastructure changes.

In the context of SBOMs and IBOMs, GitOps can automate the process of tracking and managing changes to both software and infrastructure components. By storing the SBOM and IBOM in a git repository, any changes to the software or infrastructure can be tracked and managed through git. This simplifies the management process and enhances visibility and traceability, which are crucial for security and compliance.

Moreover, these automated systems could be integrated into secure, automated supply chains, marking this technological revolution’s next phase. This is an exciting prospect and one that holds immense potential for businesses looking to streamline their operations and enhance their efficiency. With GitOps, the creation and maintenance of SBOMs and IBOMs become a part of the natural development workflow, making it easier to keep up with the fast-paced world of cloud-based applications.

The Role of SBOMs and IBOMs in Compliance and Auditing

Another significant advantage of integrating SBOMs and IBOMs is their crucial role in compliance and auditing. In today’s digital landscape, the emphasis on data privacy and security has never been greater. Businesses must adhere to many regulations, from data protection laws like GDPR and California Consumer Privacy Act (CCPA) to industry-specific regulations such as Health Insurance Portability and Accountability Act (HIPAA) in healthcare and Payment Card Industry Data Security Standard (PCI DSS) in finance.

Having comprehensive SBOMs and IBOMs provides the necessary transparency and traceability to meet these regulatory requirements. They serve as a detailed inventory of all software and infrastructure components, including their versions, configurations and interdependencies. This level of detail is crucial for demonstrating compliance with regulations requiring businesses to thoroughly understand their IT environment.

For instance, in the event of a data breach, an SBOM and IBOM can help a team identify which components were affected and assess the extent of the breach. This can aid in incident response and reporting, both of which are key requirements of data protection regulations.

The integration of SBOM and IBOM is not just about managing complexity in the cloud-based app era. It’s also about ensuring that businesses can meet their compliance obligations and maintain the trust of their customers in an increasingly regulated and security-conscious digital landscape.

The Future Is Integrated

As we continue to navigate the digital future, it’s clear that the integration of SBOMs and IBOMs will play a pivotal role in managing the complexity of cloud-based applications. Providing a comprehensive view of our application environment can help businesses enhance security, improve performance, streamline operations and control costs.

The future of business applications is undoubtedly integrated. By embracing the power of SBOMs and IBOMs, businesses can not only navigate the complexities of the digital landscape but also unlock new opportunities for growth and innovation. As we continue to explore the potential of these tools, one thing is clear: The future of tech management is here, and it’s integrated.

The post The Transformative Power of SBOMs and IBOMs for Cloud Apps appeared first on The New Stack.

Given the enormous complexity involved, orchestrating cloud infrastructure manually, even with Infrastructure as Code (IaC), is time-consuming and tough. Enterprises often have dozens and sometimes hundreds of public cloud accounts, with new ones popping up all the time.

Without a unified control plane that keeps track of application stacks across clouds and cloud accounts, achieving operational consistency, cost efficiency and resiliency becomes near impossible.

Additionally, enterprises are missing out on the opportunity to learn from what worked and what didn’t work in the past, when creating new app stacks, Torsten Volk, an analyst at Enterprise Management Associates, told The New Stack.

He added, “Ideally, developers will be able to define their infrastructure requirements straight from within code functions, without having to specify the exact resources needed, while the IaC platform analyzes the new app, compares it to existing apps that are similar in character, and automatically derives the optimal infrastructure resources.”

Pulumi, an IaC provider, is seeking to simplify and automate IaC for complex cloud environments (Amazon Web Services, for instance, has more than 300 infrastructure resources alone). As part of that mission, it announced new product features during its PulumiUP virtual conference on Thursday.

Pulumi lets engineers deliver infrastructure as code fast, using any language. Its Automation API lets customers manage 10x more resources at lower cost than others. Pulumi Insights unlocks analytics and search across clouds, and enables AI-driven infrastructure automation. www.pulumi.com

Learn More

The latest from Pulumi

For those organizations that may have cloud native ambitions and struggle with just getting started, Pulumi’s new AI-enhanced and other features and existing API are designed for the task.

Other newly introduced features include the ability to convert infrastructure across a stack from an alternative such as Terraform with accessible IaC commands.

AI and Insights

When managing thousands of resources across multiple clouds, manual errors can be devastating. A proper IaC platform must prevent manual errors and streamline operations. It should provide a single source of truth and become a necessity at the scale of cloud native environments.

For serverless architectures and Kubernetes applications, for example, managing infrastructure with a programming language of your choice — features that which Pulumi provides — is also critical as IaC becomes the default choice in the cloud native world.

“Pulumi is more suitable for this new world, where infrastructure plays a different role,” Aaron Kao, Pulumi’s vice president for marketing, told The New Stack.

Pulumi’s new features are designed to increase developer productivity and operational scalability by leveraging metrics from past projects to automatically compile an optimal application stack for new projects, Volk said.

For example, he said, the analytics engine might find that leveraging SQL databases over NoSQL ones leads to a decreased number of weekly deployments that at the same time show higher failure rates and a longer mean time to recovery.

The new features Pulumi announced at its conference include:

An On-Ramp from Terraform

Tf2pulumi, which converts Terraform projects to Pulumi programs, is now part of the Pulumi CLI. The new Terraform conversion support includes support for Terraform modules, all core features of Terraform 1.4 and the majority of Terraform built-in functions.

The tf2pulumi feature previously converted snippets of Terraform to Pulumi, and now supports conversion of most complete Terraform projects. It is now integrated with the pulumi convert command in the CLI, which can also be used to convert Pulumi YAML to other Pulumi languages.

A Deeper Dive into Cloud Resources

Pulumi Insights now lets engineers ask questions about cloud resource property values, in addition to resource types, packages, projects and stacks. This property search capability allows teams to perform deeper analysis on their resources.

The Insights feature also now allows search filtering by teams. This allows organizations to analyze resources under management per team and better estimate usage and cost.

Pulumi Insights is where Pulumi’s AI capabilities particularly shine, with a heavy implantation of ChatGPT functionality. The information retrieved by issuing commands in conversational English, and Pulumi Insights offers actionable analysis and information about how to accomplish infrastructure orchestration-related tasks.

On-Demand Infrastructure Stacks for Testing

Review Stacks, a new feature of Pulumi Deployments, are temporary, on-demand infrastructure environments created for each pull request in a repository. They allow engineers to review and test IaC changes in an isolated setting before merging them into the main branch.

The features streamlines the development process by maintaining a separation between testing and production environments and catching potential issues before they reach production. With Review Stacks, organizations can enhance resource efficiency by spinning up a test stack only when needed, which is intended to accelerate deployment cadence.

The post Pulumi: New Features for Infrastructure as Code Automation appeared first on The New Stack.

While container and cloud technology are increasingly mature, there are still a lot of different software, staffing and architecture considerations that CTOs must address to ensure that everything runs smoothly and operates together.

The Gartner “A CTO’s Guide to Navigating the Cloud Native Container Ecosystem” report estimates that by 2028, more than 95% of global organizations will be running containerized applications in production, which is a significant increase from fewer than 50% in 2023.

This level of adoption means that organizations must have the right software to effectively manage, monitor and run container-based, cloud native environments. And there is a multitude of options for CTOs and enterprise architecture (EAs) leaders to sift through, which makes it hard to get environments level-set and to standardize processes.

“Despite the apparent progress and continued industry consolidation, the ecosystem remains fragmented and fast-paced. This makes it difficult for EAs andCTOs to build robust cloud native architectures and institute operational governance,” the authors state.

Chronosphere is the only observability platform that puts you back in control by taming rampant data growth and cloud native complexity, delivering increased business confidence. Engineering organizations trust Chronosphere to help them operate scalable, highly available, and resilient applications.

Learn More

The latest from Chronosphere

As container adoption expands for cloud native environments, more IT leaders will see an increase in both vendor and open source options. Such variety makes it harder to select the right tools to run a cloud native ecosystem and stretches out the evaluation process.

Here’s a look at container ecosystem components, software offerings and how CTOs can evaluate the best configuration for their organization.

What Are the Components of Container-Based Cloud Native Ecosystems?

Gartner explains that “containers are not a monolithic technology, the ecosystem is a hodgepodge of several components vital for production readiness.”

The foundation of a containerized ecosystem includes:

• Container runtime lets developers deploy applications, configurations and other container image dependencies.
• Container orchestrator supports features for policy-based deployment, application configuration management, high availability cluster establishment and container integration into overall infrastructure.
• Container management software provides a management console, automation features, plus operational, security and developer tools. Vendors in this sector include Amazon Web Services (AWS), Microsoft, Google, RedHad, SUSE and VMware.
• Open source tools and code: The Cloud Native Computing Foundation is the governance body that hosts several open source projects in this space.

These components all help any container-based applications run on cloud native architecture to support business functions and IT operations, such as DevOps, FinOps, observability, security and APIs. There are lots of open source projects that support all of these architectural components and platform engineering tools for Kubernetes.

At the start of cloud native ecosystem adoption, Gartner recommends:

Map your functional requirements to the container management platforms and identify any gaps that can be potentially filled by open source projects and commercial products outlined in this research for effective deployments.

Choose open source projects carefully, based on software release history, the permissiveness of software licensing terms and the vibrancy of the community, characterized by a broad ecosystem of vendors that provide commercial maintenance and support.

What Are the Container Management Platform Components?

Container management is an essential part of cloud native ecosystems; it should be top of mind during software selection and container environment implementation. But legacy application performance monitoring isn’t suited for newer cloud technology.

Cloud native container management platforms include the following tools:

• Observability enables a skilled observer — a software developer or site reliability engineer — to effectively explain unexpected system behavior. Gartner mentions Chronosphere for this cloud native container management platform.
• Networking manages communication inside the communication pod, between cluster containers and from the outside world.
• Storage delivers granular data services, high availability and performance for stateful applications with deep integration with the container management systems.
• Ingress control gatekeeps network communications of a container orchestration cluster. All inbound traffic to services inside the cluster must pass through the ingress gateway.
• Security and compliance provides assessment of risk/trust of container content, secrets management and Kubernetes configurations. It also extends into production with runtime container threat protection and access control.
• Policy-based management lets IT organizations programmatically express IT requirements, which is critical for container-based environments. Organizations can use the automation toolchain to enforce these policies.

More specific container monitoring platform components and methodologies include Infrastructure as Code, CI/CD, API gateways, service meshes and registries.

How to Effectively Evaluate Software for Cloud Native Ecosystems

There are two types of container platforms that bring all required components together: integrated cloud infrastructure and platform services (CIPS) and software for the cloud.

Hyperscale cloud providers offer integrated CIPS capabilities that allow users to develop and operate cloud native applications with a unified environment. Almost all of these providers can deliver an effective experience within their platforms, including some use cases of hybrid cloud and edge. Key cloud providers include Alibaba Cloud, AWS, Google Cloud, Microsoft Azure, Oracle Cloud, IBM Cloud and Tencent.

Vendors in this category offer on-premises, edge solutions and may offer either marketplace or managed services offerings in multiple public cloud environments. Key software vendors include Red Hat, VMware, SUSE (Rancher), Mirantis, HashiCorp (Nomad), etc.

Authors note critical factors of platform provider selection include:

• Automated, secure, and distributed operations
  • Hybrid and multicloud
  • Edge optimization
  • Support for bare metal
  • Serverless containers
  • Security and compliance
• Application modernization
  • Developer inner and outer loop tools
  • Service mesh support
• Open-source commitment
• Pricing

IT leaders can figure out which provider has the most ideal offering if they match software to their infrastructure (current and future), security protocols, budget requirements, application modernization toolkit and open source integrations.

Gartner recommends that organizations:

Strive to standardize on a consistent platform, to the extent possible across use cases, to enhance architectural consistency, democratize operational know-how, simplify developer workflow and provide sourcing advantages.

Create a weighted decision matrix by considering the factors outlined above to ensure an objective decision is made.

Prioritize developers’ needs and their inherent expectations of operational simplicity, because any decision that fails to prioritize the needs of developers is bound to fail.

Read the full report to learn about ways to effectively navigate cloud native ecosystems.

The post A CTO’s Guide to Navigating the Cloud Native Ecosystem appeared first on The New Stack.

The third annual State of Cloud Strategy Survey, commissioned by HashiCorp and conducted by Forrester Consulting, focuses on operational cloud maturity — defined not by the amount of cloud usage but by adoption of a combination of technology and organizational best practices at scale.

The results were unambiguous: The organizations using operational best practices are deriving the biggest benefits from their cloud efforts, in everything from security and compliance to availability and the ability to cope with the ongoing shortage of critical cloud skills. High-maturity companies were more likely to report increases in cloud spending and less likely to say they were wasting money on avoidable cloud spending.

The seven headline numbers below capture many of the survey’s most important findings, and you can view the interactive State of Cloud Strategy Survey microsite for detailed results and methodology. Read on to learn more about our cloud maturity model and some of the key differences we found between high and low cloud-maturity organizations.

Source: A commissioned study conducted by Forrester Consulting on behalf of HashiCorp, February 2023

Our Cloud Maturity Model

To fully understand the survey results you need to know something about the cloud maturity model developed by HashiCorp and Forrester to describe where organizations are in their cloud adoption journey. HashiCorp commissioned Forrester Consulting to survey almost 1,000 technology practitioners and decision-makers from companies in a variety of industries around the world, primarily those with more than 1,000 employees.

Forrester asked about their use of best practices across technology layers including infrastructure, security, networking and applications, as well as their use of platform teams, and used that data to separate respondents into three tiers:

• Low-maturity organizations, the lowest 25% or respondents, are experimenting with these practices.
• Medium-maturity companies, the middle 50%, are standardizing their use of these practices.
• High-maturity respondents, the top 25%, are scaling these practices across the entire organization.

Infrastructure enables innovation. HashiCorp provides consistent workflows to provision, secure, connect, and run any infrastructure for any application.

Learn More

The latest from HashiCorp

How High-Maturity Organizations Are Different

Multicloud works better for highly mature companies. More than three quarters (76%) of high-cloud-maturity organizations say multicloud is helping them achieve their business goals, and another 17% expect it to within the next 12 months. That compares to just 60% of low-maturity respondents who say multicloud is working for them, while another 22% expect it to do so in the next year.

The Great Cloud Skills Shortage

“Skills shortages” is the most commonly cited barrier to operationalizing multicloud, and almost three quarters (74%) of high-maturity respondents say multicloud helps them attract, motivate and retain talent. That compares to less than half (48%) of low-maturity organizations who can say the same. Other large differences between the benefits experienced by high- and low-maturity respondents showed up in the areas of compliance and risk (80% to 56%), infrastructure visibility/insight (82% to 59%) and speed (76% to 59%). Also significant, 79% of high-maturity organizations report that their multicloud efforts have resulted in a stronger security posture, perhaps because working in multiple cloud environments can help organizations keep their security professionals engaged, and also be a forcing function toward more intentional oversight of their security operations.

Cloud Spending and Cloud Waste

Despite macroeconomic uncertainty, 62% of highly mature companies boosted their cloud spending in the last year. That compares to 56% of respondents overall and just 38% of low-maturity organizations. Yet even as they increased cloud spending, more than half (53%) of high-maturity respondents used multicloud to cut costs, compared to just 42% of low-maturity respondents.

Avoidable cloud spending remains high, with 94% of respondents reporting some degree of cloud waste (about the same as in last year’s survey). But the factors contributing to that waste differ notably: Low cloud-maturity firms, in particular, struggle with over-provisioning resources (53%, compared to 47% for high maturity firms), idle or underused resources (55% compared to 51%) and lack of needed skills (47% vs. 43%).

Multicloud Drivers

High- and low-maturity organizations also differ on what drives their multicloud efforts. For example, along with cost reductions, reliability, scalability, security and governance, digital transformation and, especially, portability of data and applications are much more commonly cited by high-maturity organizations. On the other hand, factors such as remote working, shopping for best-fit cloud service, desire for operational efficiency, backup/disaster recovery and avoiding vendor lock-in were relatively similar across all levels of maturity.

What are the business and technology factors driving your multicloud adoption?

Base: 963 respondents who are application development and delivery practitioners and decision-makers with budget authority for new investments. Source: A commissioned study conducted by Forrester Consulting on behalf of HashiCorp, February 2023.

When it comes to security threats, 49% of both high- and low-maturity respondents worry about data theft (the top-ranking choice), and roughly equal percentages are concerned about phishing and social engineering attacks. Notably, though, while 61% of low-maturity companies rank password/credential/secrets leaks as a big concern, only 47% of high-maturity respondents agree. Similarly, ransomware is an issue for 47% of low-maturity respondents but just 39% of their high-maturity counterparts.

What are the biggest threats your organization face when it comes to cloud security?

Base: 957 respondents who are application development and delivery practitioners and decision-makers with budget authority for new investments. Source: A commissioned study conducted by Forrester Consulting on behalf of HashiCorp, February 2023.

Find out More

You can explore the full results of the survey on HashiCorp’s interactive State of Cloud Strategy Survey microsite, where you can also download Forrester Consulting’s “​​Operational Maturity Optimizes Multicloud” study, which presents the firm’s key survey findings, analysis and recommendations for enterprises.

The post Survey Says: Cloud Maturity Matters appeared first on The New Stack.

Kubefirst delivers instant GitOps platforms made from popular free and open source cloud native tools. We’ve supported the Amazon Web Services (AWS) cloud for years and love how well our platform runs on Elastic Kubernetes Service (EKS). We recently announced our expanded support for the new Civo cloud, a cloud native cloud that runs all of its infrastructure on Kubernetes. There are some pretty staggering differences between the two clouds, yet some things remain virtually identical, and it got me thinking about the wild journey of how we got here as an industry.

Remember the Original Public Clouds?

Remember when public clouds were new? Think back to computing just 10 years ago. In 2013, AWS was trying to further its stronghold on the new cloud computing space with its self-service infrastructure public cloud model in Elastic Compute Cloud (EC2). Google Cloud Platform and Microsoft Azure were just a couple years removed from announcing their own, further solidifying the architectural shift away from self-managed data centers.

Despite the higher compute cost of public cloud infrastructure compared to its on-premises equivalents, the overall time and money saved by leveraging repeatable on-demand cloud infrastructure prompted companies to begin tearing down their rack space and moving their infrastructure to the public clouds. The self-service model gave more power to the developer, fewer handoffs in the DevOps space and more autonomy to engineering teams. The public cloud era was here to stay.

We are a team of experienced technologists creating open-source tools, which help teams build cloud native applications easier, better, faster. Kubeshop is backed by the most successful investors in the software industry who see Kubernetes as the foundation for building the software of tomorrow. Kubeshop and TNS are under common control.

Learn More

The latest from Kubeshop

The IaC Revolution

Although the days of sluggish infrastructure IT tickets were now a thing of the past, the potential of the cloud still remained untapped for many organizations. True to Tesler’s Law, the shift toward the public cloud hadn’t exactly removed system complexity — the complexity had just found a new home.

To tackle that complexity, we needed new automated ways to manage our infrastructure and the era of Infrastructure as Code (IaC) did its best to rise to this challenge. New technologies like CloudFormation, Ansible, Chef, Puppet and Terraform all did their best to step up to the need, but the infrastructure story from company to company was generally still a rather complex and bespoke operation.

The Container Revolution

Around the same time another movement was sweeping through the application space: containerization. Largely Docker-based at the time, containerizing your apps was a new way to create a consistent application runtime environment, isolating the application from the infrastructure that it runs upon.

With containerization, we were suddenly able to run an app the same way on different operating systems or distributions, whether running on your laptop, on on-premises infrastructure or in the public cloud. This solved a lot of problems that companies suddenly had as their infrastructure requirements began to dramatically shift in new directions.

Organizations with the classic monolithic applications began exploring how container-based microservices could be leveraged to optimize their software development and scaling woes. As the containerized world evolved and teams started building containerized microfrontends making calls to containerized microbackends, the sprawl of micro products started to become a lot to manage. This was particularly felt with the management of applications, infrastructure, secrets and observability at scale.

The Orchestration Battle

With the motion to put applications into containers and the resulting explosion of microservices and containerized micro products came a new challenge: managing all of them.

HashiCorp Nomad, Docker Swarm and Google’s Kubernetes (now part of CNCF) swiftly found their way to the conference keynote stages.

Each had its distinct advantages, but Kubernetes rose to the top with its declarative design, operating system and cloud portability, in addition to an unprecedentedly strong user community. The YAML-based system made it easy to organize your desired state into simple files that represent everything an application needs to work. It could be run in any cloud, on your on-premises infrastructure or even on your laptop, and it boasts a bustling community of cloud native engineers who share a uniform vision for modern solutions.

To Kubernetes Goes the Spoils

Cloud native engineers were quick to identify that all the software running inside Kubernetes was much easier to manage than the software that ran outside of Kubernetes. Opinions were beginning to form such that if your product didn’t have a Helm chart (the Kubernetes package manager), then it probably wasn’t very desirable to the cloud native engineers who were responsible for platform technology choices. After all, if you need to install complex third-party software, your choices are a Helm install command that takes seconds to run or pages upon pages of installation guides and error-prone instructions.

Opportunistic software vendors were quick to pick up on this trend and feverishly began rearchitecting their systems to be installed by Helm and operational on Kubernetes. The promise of delivering complex multicomponent software packages with complex microarchitectures, but still having it easily installable to any cloud environment has been the dream of software delivery teams forever, and it has finally reached that inevitability with Kubernetes at the helm.

How Complex Does Your Cloud Need to Be?

We first built kubefirst to provision instant cloud native (Kubernetes) platforms in the world’s largest public cloud, AWS, and it runs very well there. The maturity of the AWS cloud is largely unparalleled. If you need to accommodate large swaths of Fortune 500 complexities, Federal Information Processing Standards (FIPS)-compliant endpoints from all angles, extreme scales with enormous data volume or some other nightmare of this type, choosing one of the “big 3” (AWS, Google Cloud or Microsoft Azure) is a pretty easy instinct to follow.

If you’re working in this type of environment, kubefirst is lightning-fast and can turn 12 months of platform building into a single 30-minute command (kubefirst aws create).

We still love the big clouds. However, when we asked our community what clouds we should expand into, we weren’t too surprised to find a clamoring of interest for a simpler cloud option that focused on managed Kubernetes. The newer cloud providers like Civo, Vultr, DigitalOcean and others of this ilk are boasting blazing fast cluster provisioning times with significantly reduced complexity. With fewer resources to manage than the cloud pioneers can offer, you get you into that new cluster much faster.

Let’s break this down in terms of Terraform cloud resources, the code objects in your infrastructure as code. To create a new kubefirst instant platform from scratch in AWS, our kubefirst CLI needs to provision 95 AWS cloud resources. This includes everything — the VPC, subnets, key management service keys, state store buckets, backends, identity and access management (IAM) roles, policy bindings, security groups and the EKS cluster itself. Many of these resources are abstracted behind Terraform modules within the kubefirst platform, so the complexity of the cloud has been heavily reduced from the platform engineer’s perspective, but there’s still quite a bit of “cloud going on.” It’s also a very sophisticated and enterprise-ready setup if that’s what your organization requires.

But there’s a cost for this sophistication. To provision these 95 resources and get you into your cluster, you’ll have to wait about 25 fully automated minutes, and a lot of that is waiting on cluster provision time. It takes about 15 minutes to provision the master control plane and another 10 to provision and attach the node groups to it. If you need to destroy all these resources, it will take another 20 minutes of (automated) waiting.

But to have the same kubefirst platform in Civo, you only need to manage three Terraform resources instead of 95, and instead of the 45 minutes it takes to provision and destroy, you could do the same in about four minutes. When infrastructure is part of what you’re changing and testing, this is an enormously consequential detail for a platform team.

The Rise of Platform Engineering and the Cloud Native Cloud

Platform engineering is an emerging practice that allows organizations to modernize software delivery by establishing a platform team to build a self-service developer platform as their product. The practice requires that platform teams iterate regularly on the provisioning of infrastructure, cloud native application suites, application CI/CD, and Day 2 observability and monitoring. With entire software development ecosystems being provisioned over and over becoming the new normal, spending 45 minutes between iterations instead of four can be a costly detail for your platform team’s productivity.

If you fear that you will eventually need the complexities of “the big 3” clouds, that doesn’t mean that you need to borrow that cloud complexity today. Kubefirst is able to abstract the cloud from the platform so you can build your platform on kubefirst civo today and move it to kubefirst aws tomorrow with all of the same cloud native platform tools working in all the same ways.

The Kubefirst Platform on the Cloud Native Clouds

Kubefirst provisions open source instant fully automated open source cloud native platforms on AWS, Civo, Vultr (beta), DigitalOcean (beta), and on the localhost with k3d Kubernetes. Civo Cloud is offering a one-month $250 free credit so you can try our instant platform on its cloud for free.

To create a new Civo account, add a domain, configure the nameserver records at your domain registrar, then run kubefirst civo create (full instructions when using Civo with GitHub, and with GitLab).

Within a few minutes you’ll have:

• A gitops repo added to your GitHub/GitLab that powers your new platform so you can add your favorite tools and extend the platform as you need.
• A Civo cloud and Kubernetes cluster provisioned with and configured by Terraform IaC.
• A GitOps registry of cloud native platform application configurations, preconfigured to work well with each other.
• HashiCorp Vault secrets management with all the platform secrets preconfigured and bound to their respective tools.
• A user management platform with single sign-on (SSO) for your admins and engineers and an OpenID Connect (OIDC) provider preconfigured to work with all of your platform tools.
• An example React microservice with source code that demonstrates GitOps pipelines and delivery to your new Kubernetes development, staging and production environments.
• An Argo Workflows library of templates that conduct GitOps CI and integrate the Kubernetes native CI with GitHub Actions/GitLab pipelines.
• Atlantis to integrate any Terraform changes with your pull or merge request workflow so that infrastructure changes are automated and auditable to your team.
• Self-hosted GitLab/GitHub runners to keep your workloads cost-free and unlimited in use.

And with kubefirst you can throw away your production cluster with the next iteration available just a couple of minutes later.

The rise of the cloud native cloud is here.

The post The Rise of the Cloud Native Cloud appeared first on The New Stack.

As long as AI serves as a co-pilot rather than an auto-pilot, there’s room for a language that facilitates effective collaboration between humans and AI. This can be achieved by reducing cognitive load and enabling rapid testing, significantly cutting iteration times. Moreover, AI simplifies the adoption of new languages.

So, why invest time and effort in the development of a new programming language (for humans) today when AI is rapidly advancing and taking over more coding tasks?

I often encounter this question in various forms:

1. Won’t AI eventually write machine code directly, rendering programming languages obsolete?
2. Can a new language introduce features or capabilities that AI cannot achieve using existing languages? (For example, why create a cloud-portable language when AI can write code for a specific cloud and then rewrite it for another?)
3. Is it worthwhile to create tools for developers who might soon be replaced by AI?

First, I must admit that I cannot predict the pace of AI advancement. Reputable experts hold differing opinions on when, or if, AI will replace human developers.

However, even if AI does eventually replace human developers, it may not necessarily write machine code directly. Why would an AI choose to reinvent the wheel for each app by writing machine code directly when it can rely on proven abstraction layers and compilers, allowing it to efficiently focus on the unique aspects of the business it serves? By building on existing work and focusing on smaller, simpler tasks, the AI can yield faster, higher-quality results.

Having covered the more distant future, I now want to focus on the more immediate future for the remainder of this post.

I believe that, given human limitations and psychology, change will likely be gradual despite AI’s rapid progress, leading to a significant transitional period with humans remaining in the loop. For instance, it’s hard to imagine organizations not desiring a human to be accountable for the AI’s output. That human would be very reluctant to let the AI do its work in a way that the human cannot understand, modify and maintain.

Think about it, would you let ChatGPT write a professional article for your peers, in your name, in a language you don’t speak? Would you publish it without being able to read it? Probably not. Similarly, would an engineering manager release a mission-critical app to production knowing that it was written by AI in a way that would make it hard for humans to step in if something goes wrong?

Additionally, while it is true that AI is an equalizer between tools to some degree, it still doesn’t completely solve the problem. Let’s take the cloud portability example from above: Even if the AI can port my code between clouds, I still want to be able to read and modify it. As a result, I must become an expert in all these clouds at the level of abstraction the AI used. If a new language allows it to write at a higher level of abstraction, it will be easier for me to understand and modify it too.

Assuming AI empowers us to rapidly generate vast amounts of code, the bottleneck inevitably shifts to the testing and validation phase. This occurs not solely due to AI’s inherent limitations, but primarily because of our own imperfections as humans. We are incapable of flawlessly articulating our requirements, which necessitates experiencing a working version of the end product, interacting with it and determining whether it fulfills our needs or if we’ve overlooked any edge cases. This iterative process continues until our creation reaches perfection.

In a landscape where testing and validation consume the majority of software delivery time, there is ample opportunity for tools that significantly streamline this phase. By reducing the time required to deploy and evaluate an application within a development environment, these tools can greatly enhance overall efficiency.

Therefore, I believe that for the foreseeable future, there is room for tools that make it easier for both humans and AI to write quality code swiftly, collaborate effectively and test more rapidly. Such tools will allow us to enhance the quality and speed of our application delivery.

The Key: Reducing Cognitive Load and Accelerating Iteration

Whether you’re an AI or a human developer, reducing complexity and iterating faster will result in better applications developed more quickly.

So, what can be done to make these improvements?

Working at a Higher Level of Abstraction

Utilizing a higher level of abstraction offers the following benefits for both human and AI coders:

1. Reduces cognitive load for human developers by focusing on the app’s business logic instead of implementation details. This enables developers to concentrate on a smaller problem (e.g., instructing a car to turn right rather than teaching it how to do so), deal with fewer levels of the stack, write less code and minimize the surface area for errors.
2. Reduces cognitive load for AI. This concept may need further clarification. AI systems come pretrained with knowledge of all levels of the stack, so knowing less is not a significant advantage. Focusing on a smaller problem is also not as beneficial as it would be for a human, because as long as the AI knows how to instruct the car to turn, it shouldn’t have an issue teaching it how to do so instead of just telling it to turn. But it’s still advantageous, as explained above, since it reduces the problem surface, allowing the AI to generate the code faster and at a higher quality. However, allowing the AI to write less code and reducing the chance for it to make mistakes is highly beneficial, as AI is far from infallible. Anyone who has witnessed it hallucinate interfaces or generate disconnected code can attest to this. Furthermore, AI is constrained by the amount of code it can generate before losing context. So writing less code enables AI coders to create larger and more complex parts of applications.
3. Accelerates iteration speed because it requires writing less code, reducing the time it takes to write and maintain it. While it might not seem intuitive, this is equally important for both human and AI coders, as AI generates code one token at a time, similar to how a human writes.
4. Improves collaboration between human and AI coders. A smaller codebase written at a higher level of abstraction allows human developers to understand, modify and maintain AI-generated code more quickly and easily, resulting in higher-quality code that is developed faster.

Faster Deployment and Testing

Presently, deploying and testing cloud applications can take several minutes. When multiplied by numerous iteration cycles, there’s substantial potential for improvement. Particularly, as our AI friends assist us to accelerate code writing, the proportion of time spent on testing and validation within each iteration cycle becomes increasingly significant compared to code writing.

A prevalent workaround is running tests locally, bypassing cloud deployment. However, this approach presents its own challenges, as it necessitates simulating the cloud environment surrounding the tested components. Consequently, these tests are constrained in their scope, often requiring supplementary tests that run in the cloud to confirm code functionality within the actual environment.

Yet this is not the end of the journey. Such solutions primarily cater to automatic tests, while developers frequently desire manual interaction with applications during development or seek feedback from various stakeholders (product, sales, management, potential users, etc.). Achieving this without cloud deployment and its associated time penalties remains a challenge.

Hence, we need to be able to generate tests that can operate both locally and in the cloud and be executed swiftly. Additionally, we must enable rapid deployment of cloud applications and facilitate easy access for stakeholder validation.

By achieving this, we can significantly enhance iteration speeds, regardless of whether the code is created by AI, humans or is a collaborative effort.

So, how do we bring this vision to life?

Introducing Wing

Wing is a new programming language for cloud development that enables both human and AI developers to write cloud code at a higher level of abstraction, and it comes with a local simulator that lets developers test it quickly.

Quantifying the Improvement

As we’ll demonstrate below, we’re talking about a 90% – 95% reduction in code, and orders of magnitude increase in testing speeds.

Let’s See Some Code

Here’s an example of a small app that uploads a file to a bucket (think AWS S3, Azure Blob Storage or GCP Bucket) using a cloud function (AWS Lambda, Azure Function or GCP Cloud Function).

This is the code in Wing:

bring cloud;

let bucket = new cloud.Bucket();
new cloud.Function(inflight () => {
  bucket.put("hello.txt", "world!");

});

As you can see, whether a human or an AI coder is writing Wing code, they work at a high level of abstraction, enabling the Wing compiler to handle underlying cloud mechanics such as IAM policies and networking (don’t worry, it’s customizable and extensible, ensuring you maintain control when needed).

Unlike human and AI coders, the compiler is infallible. Additionally, it is faster, deterministic and doesn’t lose context over time. As a result, the more responsibilities we delegate to the compiler instead of humans or AI, the better the outcomes.

The compiler can adapt the app for any cloud provider, necessitating that humans only need to know and maintain the higher-level, cloud-agnostic code. The generated compilation artifacts, Terraform and JavaScript, can be deployed using proven, dependable tools.

Now let’s take a look at the same code in one of the leading cloud development stacks today — Terraform + JavaScript.

main.tf:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 3.0"
    }
  }
}

provider "aws" {
  region = "us-west-2"
}

locals {
  lambda_function_name = "upload_hello_txt_lambda"
}

resource "aws_s3_bucket" "this" {
  bucket = "my-s3-bucket"
  acl    = "private"
}

data "archive_file" "lambda_zip" {
  type        = "zip"
  source_file = "index.js"
  output_path = "${path.module}/lambda.zip"
}

resource "aws_lambda_function" "this" {
  function_name = local.lambda_function_name
  role          = aws_iam_role.lambda_role.arn
  handler       = "index.handler"
  runtime       = "nodejs14.x"
  filename      = data.archive_file.lambda_zip.output_path
  timeout       = 10

  environment {
    variables = {
      BUCKET_NAME = aws_s3_bucket.this.bucket
    }
  }
}

resource "aws_iam_role" "lambda_role" {
  name = "lambda_role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "lambda.amazonaws.com"
        }
      }
    ]
  })
}

resource "aws_iam_role_policy" "lambda_policy" {
  name = "lambda_policy"
  role = aws_iam_role.lambda_role.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents"
        ]

        Effect   = "Allow"
        Resource = "arn:aws:logs:*:*:*"
      },

      {
        Action = [
          "s3:PutObject"
        ]

        Effect   = "Allow"
        Resource = "${aws_s3_bucket.this.arn}/*"
      }
    ]
  })
}

output "bucket_name" {
  value = aws_s3_bucket.this.bucket
}

output "lambda_function_name" {
  value = aws_lambda_function.this.function_name
}

index.js:
const AWS = require('aws-sdk');
const S3 = new AWS.S3();

exports.handler = async (event) => {
  const bucketName = process.env.BUCKET_NAME;
  const key = 'hello.txt';
  const content = 'Hello world!';
  const params = {
    Bucket: bucketName,
    Key: key,
    Body: content,
  };

  try {
    await S3.putObject(params).promise();
    return {
      statusCode: 200,
      body: JSON.stringify('File uploaded successfully.'),
    };

  } catch (error) {
    console.error(error);
    return {
      statusCode: 500,
      body: JSON.stringify('Error uploading the file.'),
    };

  }

};

As you can see, the Wing code is seven lines long, while the Terraform and JavaScript code is 122 lines, or ±17X more code. Not only that, it dives deeply into lower layers of the cloud stack.

You might be wondering if there are newer solutions against which Wing’s gains are less significant, or if the same results can be achieved through a library or a language extension. You can see how Wing compares to other solutions and why it’s a new language rather than some other solution here.

Testing with Wing

Wing comes out of the box with a local simulator and a visualization and debugging console.

These tools enable developers to work on their code with near-instant hot-reloading and test cloud applications very easily without having to mock the cloud around them.

In the example of our very simple app above, deploying to any cloud provider in order to run tests would take close to a minute, whereas with the Wing Simulator it takes less than a second — or two orders of magnitudes less. Moreover, with Wing, you can write tests without mocking the cloud and run the same ones on the simulator and in the cloud.

You can get a first-hand sense of it in the Wing Playground.

Conclusion

Although Wing introduces significant improvements in cloud development, we understand that migrating to a new language is a substantial undertaking that may be hard to justify in many cases.

We’ve gone to great lengths to make adopting the language as easy as possible with the following features:

• Easy to learn because it is similar to other languages.
• Works seamlessly with your existing stack and tools (especially deployment and management).
• Mature ecosystem — import any NPM module or Terraform resource into your code.
• Integrates into existing codebases — write runtime code in other languages and reference it with Wing.

Furthermore, we believe that in the era of AI, adopting a new language like Winglang is easier for humans as AI assists with writing code in unfamiliar languages and frameworks and simplifies the migration of existing code to new languages.

As we move toward a future where AI plays a more significant role in code development, the creation and adoption of languages like Winglang will ensure better collaboration, faster development and higher-quality applications for both human and AI developers.

To get a glimpse of the future and experience writing code in Wing and testing it instantly, you can visit our playground.

The post Winglang: Cloud Development Programming for the AI Era appeared first on The New Stack.

Before Matt Stephenson worked at Starburst Data, he used to work at Square. There, he learned some hard lessons about working with legacy Infrastructure as Code (IaC).

“We built an entire system that kind of did a lot of orchestration with Terraform and Helm, and integrated with some of our own backend services,” Stephenson, a senior principal software engineer at Starburst, told The New Stack.

It’s not a project he remembers fondly: “The experience of having to build and maintain that service made me take a look at what was available out in the industry, for not having to build that again.”

The problem isn’t Terraform per se, he said, but “it’s all of the code to execute Terraform, all the code to manage the inputs and outputs to Terraform itself.”

Legacy IaC can bring a number of challenges into the lives of an engineering team. Among them:

• It can get more complex to follow required conventions and standards when configurations are being defined, and the complexity grows as it scales.
• As a result, configuration drift is common, and can result in noncompliance and service outages. (And misconfigurations in general are a leading cause of security breaches.)
• Necessary integrations and features aren’t always available for specific use cases.
• Legacy IaC can bring significant maintenance needs, and it can be tough to recruit and retain engineers who have those skills.

“A lot of the legacy Infrastructure as Code products have their own language, they have their own environment, you have to kind of become a bit of an expert in them to be effective at them,” Stephenson said. “Or you have to have some kind of support, going into using one of those.”

At Starburst Data, he oversees the architecture for the company’s Galaxy product, a managed data lake analytics platform. His team has gradually swapped out legacy IaC for Pulumi, an open source IaC product that allows infrastructure to be built in any programming language.

Stephenson will be among the presenters at PulumiUP, a virtual user conference on June 15 dedicated to Infrastructure as Code, how it enables faster application development and how users can navigate the challenges of legacy systems.

At the conference, he’ll be talking about Pulumi’s automation API, he said. “That was a big driver for us, being able to orchestrate all of our Pulumi stacks without having to write that whole service that we had to write in the past.”

Empowering the Whole Team

One of the differences between Pulumi and legacy IaC solutions, Stephenson said, is that “it’s based in programming languages that people learn in college or learn really quickly when they join the industry.”

Pulumi allows developers to build infrastructure in common languages including any Java language (Java, Scala, Clojure, Groovy, Kotlin); .NET (C#, F#, PowerShell); Node.js (JavaScript, TypeScript); Go, Python and even YAML. This helps make provisioning infrastructure something that more members of an engineering team can do.

Before his experience using Pulumi, Stephenson said, “it was mostly more senior engineers that would be involved in setting up all of your infrastructures, your code environments. These days we have folks across the skill-set level working in it.

Pulumi lets engineers deliver infrastructure as code fast, using any language. Its Automation API lets customers manage 10x more resources at lower cost than others. Pulumi Insights unlocks analytics and search across clouds, and enables AI-driven infrastructure automation. www.pulumi.com

Learn More

The latest from Pulumi

Now, he said, even people in his organization without infrastructure or site reliability engineering backgrounds, “when they’re doing product development, they’re able to just go in and make the changes they need. They don’t really have to worry about engaging an expert to be able to get something to happen that they want.”

As a result, Stephenson added, there’s less need for hiring IaC-specific experts for a team, and more people are empowered to handle problems.

“If there’s an incident that involves the infrastructure, a lot of times people can make the changes they need to execute our continuous delivery pipeline and get things fixed.”

A Search for Flexibility

Dennis Sauvé, the first DevOps engineer hired by Washington Trust Bank, will also be presenting at PulumiUP, talking about his company’s experience moving from an entirely on-premises system to one run on Microsoft Azure Cloud — with IaC, largely written in TypeScript, provided by Pulumi.

Before the bank hired Sauvé, it decided to start services to the cloud to move forward with innovations like a customer collaboration tool that will allow Washington Trust’s relationship managers to talk with clients directly. It had determined that Azure’s communications services would help it build that application more easily, Sauvé told The New Stack.

But the bank also wanted flexibility for applications it might build in the future, and for the clouds it might deploy those apps on.

Pulumi, Sauvé said, offered that flexibility and the options his team needed. “You can pick your cloud provider. And then once you have a cloud provider, you can pick a language you want to build that stack in, and they support it.

“And so we had that peace of mind that not only if we wanted to change the language we wrote our Infrastructure as Code with, we could also change our cloud provider as well. We could go to [Amazon Web Services] or Google Cloud, and we’d be able to take plenty right along with us. So that was a huge bonus when considering different providers.”

Saving Time and Toil

One of the biggest benefits of Pulumi for Washington Trust Bank, Sauvé said, has been the ability it gives his team to save time and toil. He and his development team have been creating best-practice templates for creating resources.

Instead of the back-and-forth that might have existed between developers and operations engineers, “the developers can now just go to our infrastructure package, find the resource that they want to build, choose that and set it up to deploy. And it really speeds up development and testing environments.”

Not only that, he added, but Pulumi has become a standardization tool, ensuring that resources are being created in the same way across the organization.

However, he added, moving to the cloud and onto Pulumi, hasn’t been without hiccups. Notably, the native Typescript package is, “from a file-size standpoint, just a massive package that is a little taxing on resources to use, but it works in production.”

Pulumi, he noted, will soon release a next-generation version of the TypeScript package that “should be very slimmed down and address some of the performance issues.”

Shifting away from legacy IaC can cause a bit of disruption on a team at first, Stephenson acknowledged. (“There’s always folks that really kind of hang their hat on being the expert in the room with specific things like Terraform,” he noted.)

But in the long run, he said, it empowers a broader set of people in the organization. He pointed to a colleague who joined Starburst Data soon after graduating from college: “Now he’s at a senior level; he’s basically gotten himself bumped a level twice, because he’s just so on top of everything. Pulumi was one of those things that he really dug into.”

Stephenson has heard similar stories from other companies. “You end up with people who might push back, but then at the end of the day, there’s a lot of people who excel and become the next rock stars as a result of making a shift like this.”

To learn more about Infrastructure as Code (and see presentations by Stephenson, Sauvé and other experts), register for June 15’s virtual event, PulumiUP.

The post Infrastructure as Code: Modernizing for Faster Development appeared first on The New Stack.

Enterprises are increasingly going beyond lift-and-shift migrations to adopt cloud native strategies — the approach of developing, releasing and maintaining applications, all within cloud environments. According to Gartner, more than 95% of new digital initiatives will be conducted on cloud native platforms by 2025.

As enterprises dial up the focus on cloud native functionality, they’re moving away from manual click-Ops approaches to adopt automation that enables higher velocity and better manages increasing cloud complexity and scale. HashiCorp’s State of Cloud Strategy Survey shows that 81% of enterprises are already multicloud or plan to be within a year. Of those who have adopted multicloud, 90% say it works for them.

There’s a familiar problem amid all this adoption, one that’s plagued the entire industry for years: Traditional security workflows can’t keep up. They were never designed to support a paradigm where the architecture is represented as code that can change several times a day. The velocity and scope of change of today’s cloud native architectures cause security teams to struggle.

Embracing automation is the only viable approach for security teams to support this new paradigm. Developers have leaned on Infrastructure as Code (IaC) to build these cloud native applications on a large scale, even in complex environments. Security as Code (SaC) also leverages automation to intelligently analyze and remediate security and compliance design gaps, even as context changes. It’s the missing piece that completes an enterprise cloud environment.

HashiCorp’s survey shows a whopping 89% of respondents see security as a key driver of cloud success. Cloud-service providers recognize their customers’ challenges and are making investments in security to mitigate them.

Infrastructure automation tools are a catalyst for boosting operational efficiency in development, and the same is true for security. Automation helps optimize cost and scale operations. SaC ensures these applications are built right the first time, rather than security teams rushing to put out fires after they’re deployed. Empowering security teams to codify security best practices, and enforce them autonomously, allows them to focus on the strategic work of building standards that provide the necessary guardrails for developers to move with velocity. The future of SaC should be a corollary of IaC adoption, which is growing.

SaC helps both security and development teams operate autonomously, share responsibility, and collaborate more effectively in delivering secure products and features at the speed required by today’s business landscape. SaC is the only way that we can ensure security keeps up with the rapid pace of cloud native development.

How We Got Here

Modern application architectures have increased scale and complexity, completely outpacing traditional security methods, which can’t offer adequate protection in today’s landscape. These architectures are defined in IaC languages like Terraform and often span more than 100,000 lines of code that change frequently. This has allowed development teams to rapidly evolve the architecture, deliver infrastructure in an agile manner, and build architectures at an unparalleled scale and velocity.

These developers are increasingly empowered to choose their cloud providers, feature capabilities and tech stacks to rapidly deliver on customer needs. With all the choices developers are empowered to make, applications live in heterogeneous environments that are difficult to manage. If we were to measure the average entropy of an application architecture based on the interconnectedness of components, the curve would be exponential. Add in the false positives and lack of actionable, achievable and applicable feedback, and the impact on developer productivity is huge. This is especially detrimental at scale, and when time to market is a critical business objective.

Now consider the breadth of the community that’s creating these complex architectures. The Cloud Native Computing Foundation (CNCF) reports that there are 7.1 million cloud native developers — more than two and a half times the population of Chicago.

Multicloud strategies, diversity of cloud-feature capabilities, disparate tech stacks and an enormous base of developers combine to make security an incredibly complex undertaking. Functionality is prioritized, and often the security guardrails we need are not calculated in that developer freedom.

Why SaC

Traditional security measures simply can’t match the scale of today’s cloud native architectures, and enterprises recognize this issue. One report shows that nearly 70% of organizations believe their cloud security is only “somewhat mature,” and 79% aren’t sure they enforce policies consistently.

The answer is SaC, because it solves the most-pressing business challenges.

Say you need to deliver a unique solution for a fleeting business opportunity. Often, security considerations slow down the time to market. With SaC, instead of being an inhibitor, security becomes an accelerator. SaC provides the developers with flexible guardrails that let them operate autonomously with velocity. Developers can evolve their feature capabilities without having to slow down for security and potentially miss the window of opportunity.

SaC comes to the rescue when technology needs change, like modernizing your tech stack to pay off tech debt and adopt new capabilities. It also allows you to rapidly evolve security practices when your threat landscape changes because your business is increasingly being targeted. Enterprises struggling with compliance at scale can alleviate those challenges by leveraging SaC to automate compliance workflows to reduce the time and cost of becoming compliant.

McKinsey saw the promise of SaC as the best “and maybe only” path to securing cloud native architectures more than a year ago. In addition to being the next logical step of IaC and operating at the scale and pace of innovation with security baked in, SaC creates transparency in security design, and consistent, repeatable and reusable representations of the security architecture.

What SaC Enables

We’re already seeing the payoff. Opening up our SaC framework is the feature our customers ask for the most. It’s allowed resource-constrained security teams to stop putting out fires and elevate their strategy, leveraging automation to do the tedious work. Our customers have reported a 70% reduction in security design review time and 40% reduction of cost in delivering security design by automating design validation using SaC.

SaC is also the key to unlocking collaboration, autonomy and shared responsibility across development and security teams, enabling the DevOps and DevSecOps cultures that organizations want to adopt.

This is increasingly a priority, as 62% of organizations have a DevSecOps plan or are evaluating use cases, and 84% believe getting the right data and tools to developers is key to enabling DevSecOps, according to ESG Research. As modern application development evolves, SaC is the accelerator that allows security to keep pace with everything else.

Envisioning a Modern Security Practice

Developers have been unleashed to innovate as fast as possible, using whatever tools and cloud environments they wish. The only way to have security keep up with them is to identify best practices at the policy level, agnostic to the technology stacks these developers choose. Automation, powered by SaC, turns that from a dream to reality.

We can use SaC to fit into developers’ workflows and democratize security for them. This completely changes the dynamic of how developers and security interact. Ten years from now, the traditional workflows that rely on Word documents, Excel spreadsheets and Visio diagrams will be a thing of the past. Developers will have an increased responsibility for security, with collaboration making those efforts stronger. When security is defined as code, developers can easily change a security architecture to better meet their requirements.

Shifting to SaC allows enterprises to make security a driver of their velocity and agility. Automation improves security from reducing human error, to eliminating scaling challenges so security can keep pace with development, to providing richer security policies.

With SaC, we finally have a way to quickly make changes that deliver repeatable outcomes at the same speed as application development. As cloud native architectures become more prominent, this is the only way security can keep pace.

The post Security as Code Protects Rapidly Developing Cloud Native Architectures appeared first on The New Stack.

Embracing the cloud widens your attack surface while your security budget stays the same. Choosing the right cloud native application platform is therefore a crucial decision to make — managing risk and regulatory compliance across the organization, expediting app delivery and remove friction with automated security.

Every dollar spent on security must minimize security risks and streamline security while producing a return on investment (ROI) in the form of better detection or prevention. As an IT leader, finding the tool that meets this requirement is not always easy. It is tempting for CISOs and CIOs to succumb to the “shiny toy” syndrome: to buy the newest tool claiming to address the security challenges facing their hybrid environment, instead of simplifying and extending their security across the entire infrastructure with the tools they already have to secure cloud native applications.

With cloud adoption on the rise, securing cloud assets is a critical aspect of supporting digital transformation efforts and the continuous delivery of applications and services to customers faster, securely and efficiently.

However, embracing the cloud widens the attack surface. That attack surface includes private, public and hybrid environments. A traditional approach to security simply doesn’t provide the level of security needed to protect this environment and requires organizations to have granular visibility over cloud events.

Organizations need a new unified approach, one that provides them with the visibility and control they need while also supporting the CI/CD pipeline, combining automated agent and agentless detection and response through the entire app life cycle.

CrowdStrike has redefined modern cybersecurity with our advanced cloud-native platforms for protecting endpoints and cloud workloads, identity and data. CrowdStrike’s adversary-focused approach to CNAPP provides agent-based and agentless solutions delivered from the CrowdStrike Falcon® platform.

Learn More

The latest from CrowdStrike

How to Begin

To address these challenges head-on, organizations are turning to unified cloud native application-protection platforms. But how do IT and business leaders know which boxes these solutions should check? Which solution is best for addressing cloud-security threats based on the changing adversary landscape? 

To help guide the decision-making process, here are four key evaluation points:

1. Cloud Protection as an Extension of Endpoint Security

Focusing on endpoint security alone is not sufficient to secure the hybrid environments many organizations now have to protect. For those organizations, choosing the right unified security platform across endpoint and cloud workload is vital.

2. Understanding Adversary Actions against Your Cloud Workloads

Real-time, up-to-date threat intelligence is a critical consideration when evaluating security platforms. As adversaries ramp up actions to exploit cloud services, having the latest information about attacker tactics and applying it successfully is a necessary part of breach prevention.

For example, CrowdStrike researchers noted seeing adversaries targeting neglected cloud infrastructure slated for retirement that still contains sensitive data and adversaries leveraging common cloud services to obfuscate malicious activity.

A proper approach to securing cloud resources leverages enriched threat intelligence to deliver a visual representation of relationships across account roles, workloads and APIs to provide deeper context for a faster, more effective response.

3. Complete Visibility into Misconfiguration, Vulnerabilities and More

Closing the door on attackers also involves identifying the vulnerabilities and misconfiguration they’re most likely to exploit. A sound approach to cloud security will weave these capabilities into the CI/CD pipeline, enabling organizations to catch vulnerabilities early.

For example, they can create verified image policies to guarantee that only approved images can pass through the pipeline. By continuously scanning container images for known vulnerabilities and configuration issues and integrating security with developer toolchains, organizations can speed up application delivery and empower DevOps teams.

Catching vulnerabilities is also the job of cloud-security posture-management technology. These solutions allow organizations to continuously monitor the compliance of all of their cloud resources. This ability is critical because misconfiguration is at the heart of many data leaks and breaches. Having these solutions bolster your cloud-security strategy will enable you to reduce risk and embrace the cloud with more confidence.

4. Managed Threat Hunting

Technology alone is not enough. As adversaries refine their tradecraft to avoid detection, access to managed detection and response (MDR) and advanced threat-hunting services for the cloud can be the difference in stopping a breach. Managed services should be able to leverage up-to-the-minute threat intelligence to search for stealthy and sophisticated attacks. This human touch adds a team of experts that can augment existing security capabilities and improve customers’ ability to detect and respond to threats.

Choosing the Right Cloud Native Application Protection Platform

Weighing the differences between security vendors is not always simple. However, there are some must-haves for cloud-security solutions. From detection to prevention to integration with DevOps tools, organizations need to adopt the capabilities that put them in the best position to take advantage of cloud computing as securely as possible.

The post 4 Factors to Consider When Choosing a Cloud Native App Platform appeared first on The New Stack.

Before he came to GitHub, then DevOps consultant Martin Woodward worked to bring legacy apps to the cloud; and he admitted he envied cloud native companies.

“We were always jealous of these born in the cloud startups that had it easy — it’s just cloudy, cloudy, it’s all good,” Woodward, now GitHub’s vice president of developer relations, told audiences at last week’s Microsoft Build conference. “And then I came to work at GitHub.”

That’s when he learned that cloud native companies have their woes as well.

“What nobody tells you about these fast-moving, cloud startups is just dealing with that growth, making sure you don’t build up tech debt as you go — and if you don’t keep modernizing your engineering systems, modernizing your engineering practices, then you’re just going to get swallowed up in your own pool of [tech] debt,” he said.

Woodward was joined by Brian Randell, staff developer advocate in Developer Relations at GitHub, in the cleverly titled presentation, “How GitHub Builds GitHub with GitHub.” The presentation focused on demoing various GitHub tools used internally; but along the way, the audience learned a good deal about GitHub’s development practices and philosophies as well.

Happy Developers Mean Productive Developers

To give the audience a sense of GitHub’s scope, they offered a few data points about what they deal with daily:

• An engineering organization of approximately 1,500;
• More than 100 million accounts on GitHub;
• 80,000 deployments a year to the .com production website;
• 1.9 million commits for internal repositories;
• 1.5 million commits for the GitHub.com codebase, of about 16 gigabytes;
• 4 billion API requests served a day; and
• 66 services with one “massive” Ruby on Rails monolith in the middle.

It’s not surprising, then, that availability is the number one priority for GitHub, followed closely by performance and security, Woodward said.

They then joked about revealing GitHub’s ultimate master plan, which they said was to build happy developers inside and outside the company.

“If you want to unlock productivity amongst your engineering team, you build happy developers, you improve the developer experience, you make it easy to do the right thing,” Woodward said. “Because we are engineers, we route around failure; that’s literally our job. If the process isn’t working for us, then we’re going to just route around it to get our jobs done. So we want to make the process as easy as possible to do the right thing, and have the best developer experience.”

One way in which they strive for a better developer experience internally is to ensure that developers are up and coding by day one at GitHub, Woodward said.

“We set a really ambitious goal that we wanted to have a new engineer, when they arrived at GitHub, have code running in the hands of customers, on the first day in the job,” Woodward said. “And that’s crazy — I did a lot of consulting gigs and I could be there two weeks before [they’d] even give me a machine sometimes.”

“It’s amazing how much money I made sitting in conference rooms,” Randell added.

Improving Developer Productivity with Cloud, AI GitHub Issues

GitHub is a fully remote workforce, so that makes the goal tricky, Woodward added, particularly when they’re dealing with such a large codebase — 45 minutes to clone it over high-speed internet at home, Woodward said — and security concerns about it. To meet its one-day productivity goal, GitHub made Codespaces, a cloud-based development environment that became available to external developers in November 2022.

Also key to GitHub’s productivity: the AI programming assistant Copilot. Woodward demoed how a project leader — even a non-coder — might use Copilot, by leveraging the AI to create inline Ruby on Rails code (a language he does not know well) that adds emojis to the page in the controller. He could then use that code as a proof-of-concept to give to actual Ruby on Rails developers.

Another benefit of Copilot over searching for the answer online is that it’s less distracting than an online search for a coding question, which can lead to cat GIFs and social media, he joked.

“A fully remote workforce, having that AI assistant, having that AI pair programmer, something you can ask questions of — it really helps you work and stay in the flow,” he said. “It helps you be faster as you’re coding. And also within our engineering team, three-quarters of the team say that Copilot, in particular, helps them stay in the flow rather than getting distracted.”

GitHub also uses GitHub, of course, as well as GitHub Issues, which lets developers and others track the data they care about, Randell said.

“Across the company, everybody — this is from dev rel, marketing, and yes, engineering and legal — use Issues to track different types of work,” Randell said. ”That’s one of the key things that we want you to take away from GitHub Issues, is that it’s very flexible and can be used any way you want to manage your work.”

GitHub’s Howie

Image from Microsoft Build presentation, How GitHub Builds GitHub with GitHub

Randell also explained that internally GitHub uses a workflow process it calls Howie, which is short for “How We Work at GitHub.” Howie divides work into a hierarchy of four categories: Initiatives, which take a quarter or longer; Epic, which are tasks that take 3-6 weeks; Batch, which are tasks that take a few days to three days; and Tasks, which take a few hours to a day.

“GitHub wants you to be able to manage your work the way you see fit, without us being overly opinionated,” Randell said. This approach is designed to be flexible and support “Big A agile” to more relaxed practices, he said.

Additionally, GitHub uses GitHub Actions to drill down into the deployment of new code. GitHub actions is a continuous integration and continuous delivery (CI/CD) platform that allows developers to automate their build, test and deployment pipeline.

New GitHub Security Measures

Randell and Woodward also highlighted two new security features in GitHub, starting with push protection, which GitHub announced May 9 to ensure developers aren’t uploading security tokens or other sensitive data. Randell demoed attempting to upload a personal access token on his GitHub and showed how it would reject the code.

“This is something that we made available just earlier this month in May, that allows anyone who has a public repo to make sure that you don’t accidentally submit some kind of secret into your source code and get it pushed out to the world and then have to remediate that problem,” Randell said.

Randell also highlighted a new available tool called Code QL, which basically acts as a security force multiplier, he said. It takes insights found by security teams around the world, who can submit the type of vulnerability, and Github translates that into a special type of query to run against code as part of the pull request process, Randell said. During the pull request, it will detect bad anti-patterns that might be lurking in the code. He demoed how it would deal with a recently found vulnerability.

“When the vulnerability is found, it will fail the pull request, … and we provide you with information that tells you why you shouldn’t do this, and why it’s bad for your application,” Randell said. “This is available to you today, in the open source community, and you can even submit your own as you find vulnerabilities.”

The post How GitHub Uses GitHub to Be Productive and Secure appeared first on The New Stack.

Look to slow down a development team with security and expect to be greeted with a wave of frustration. Between a lack of integration of security tools and confusion about shared responsibility, security teams are often playing from behind when it comes to defending cloud environments.

Meeting the needs of DevOps and the multiple clouds that companies now need to protect requires a unified platform that automates security controls and compliance for hosts and containers regardless of the cloud provider or deployment model. To win the cloud security race, organizations need the right ingredients for effective security to end up in the winner’s circle.

Ingredient No. 1: Unified and Portable

Let’s start with an unfortunate truth. Traditional security tools simply do not work in the cloud; they are not designed to scale alongside dynamic cloud environments. The end result is gaps in visibility and security. Meeting those challenges with point solutions is untenable for security teams seeking to keep pace with the realities of a cloud native world. As the limitations of those point products became apparent, it led to ad hoc approaches designed to address blind spots and a lack of integration.

Eliminating visibility gaps takes a cloud native security platform, a unified solution capable of providing visibility into the ever-growing number of containers and microservices today’s organizations need to protect. Armed with comprehensive visibility and continuous workload discovery, these platforms support efforts to identify vulnerabilities and ultimately help DevOps teams weave security into CI/CD workflows so that issues can be fixed before they reach production.

Security has to move at the speed of DevOps, and it needs to work across any cloud so that when workloads move, security and visibility are maintained. It’s a multicloud world, and security solutions need to live in it and not get passed on the outside.

CrowdStrike has redefined modern cybersecurity with our advanced cloud-native platforms for protecting endpoints and cloud workloads, identity and data. CrowdStrike’s adversary-focused approach to CNAPP provides agent-based and agentless solutions delivered from the CrowdStrike Falcon® platform.

Learn More

The latest from CrowdStrike

Ingredient No. 2: Automated and Fast

Rapid changes are a part of that world as well. Microservices, for example, can be quickly spun up and are often short-lived. While they can simplify application updates, they are also a reminder of how dynamic cloud environments are. Enterprises need to know what is running, where and who is running it. With automated asset discovery and monitoring, organizations can get a handle on everything happening across their cloud environment without slowing anything down.

As noted earlier, integrating security with CI/CD improves security by enabling a “shift left” approach. Automation allows security to be orchestrated more effectively to resolve vulnerabilities and security risks early in the development life cycle, though care must be taken to prevent security holes from being introduced via Infrastructure-as-Code (IaC) templates. Recently, a survey of 300 CISOs performed by IDC revealed that 67% of respondents viewed security misconfigurations in production environments as a top concern. By automating the discovery of misconfigurations, organizations can reduce the chance that one will slip through their defenses and affect their customers or business.

Ingredient No. 3: Integrated and Scalable

To ensure success, security and DevOps teams need to operate like a finely tuned engine. It should be clear by now that security cannot be treated as an afterthought or bolted on. It must be integrated into the development process from the beginning and implemented to work seamlessly with applications, cloud instances and cloud workloads. Doing so allows teams to build securely in the cloud knowing cloud native apps are protected from the control plane to runtime.

This is the ingredient that makes the term “cloud native” an essential part of the cloud security winning team you are trying to build for your organization. Non-cloud native tools increase complexity; they are not optimized for cloud native applications, and they make monitoring harder. They also require more manual intervention. Conversely, cloud native solutions ensure consistency across the entire cloud estate. API-driven and integrated with DevOps tools, cloud native solutions allow organizations to maintain security and compliance levels operating at top speeds to take the lead and win the race.

The right solution will also empower businesses to scale at will in accordance with their needs. As businesses grow, security needs to grow alongside it. Cloud security solutions need to be able to scale at will, adding and decommissioning capabilities as simply as possible so enterprises can get the security they need when they need it, where they need it.

A Winning Combination

To win the cloud security race requires the right ingredients, and so does protecting your cloud environment. The ability to leverage a cloud native platform that provides visibility and control across public, private, hybrid and multicloud environments is a winning combination for any business. By automating cloud security management across the application development life cycle and providing real-time monitoring of cloud resources, this type of approach will enable organizations to prevent the types of cloud misconfigurations that are often exploited in cyberattacks and to deploy applications securely.

The post Top 3 Application Security Must-Haves appeared first on The New Stack.

Of the many business challenges that organizations face today, I’d argue that skill gaps are one of the most underestimated. Many organizations don’t realize the impact, but the research is staggering: 90% of organizations will be affected by digital transformation IT skill shortages, which will cost more than $6.5 trillion globally by 2025, according to IDC.

When it comes to modern technology like cloud native computing, the impact of skill gaps becomes even more apparent. We all know that Kubernetes and containers enable us to move faster and ultimately make more money, but do we have enough people power to manage that?

According to the Cloud Native Computing Foundation’s 2022 Annual Survey, 44% of respondents that have yet to deploy containers in production said that lack of training is the most significant barrier inhibiting adoption. Even though containers are beginning to be considered the “new normal,” the hiring landscape simply doesn’t reflect the level of demand.

The last few decades delivered great advances in infrastructure; now, it’s time to build apps that make the most of those new tools. VMware Tanzu helps you build new apps, modernize existing ones, and evolve your development process around cloud native technologies, patterns, and architectures.

Learn More

The latest from VMware Tanzu

Why It’s Hard to Hire Cloud Native Experts

We’ve identified that there’s a cloud native skill gap, but for the people who actually are cloud native experts, competition for their talent is fierce. Here’s why:

• Highly skilled engineers know their worth — Expect to pay up. Engineers who are experts in cloud native technology know that their skill sets are in high demand and have countless organizations vying for their talent. As a result of their expertise, these engineers can command industry-leading compensation packages and work agreements. The Googles of the world might not have a problem attracting these types of engineers, but not every company can offer lavish compensation packages featuring six-figure salaries, stock plans, catered meals and other desirable perks.
• Difficult economic headwinds — We’ve all heard about the recent downturn in economic activity; companies are trying to tighten up while remaining competitive. Like I said, highly skilled engineers are expensive, and it can be difficult to keep pace from a hiring perspective in light of these difficult economic headwinds. As a result, many organizations are looking to alternative sources of talent, such as recent graduates and remote workers, to fill the gaps in their engineering departments. However, these sources of talent might not have much real-world experience when it comes to cloud native expertise.
• Rapidly changing technology — Modern technology moves FAST! Kubernetes and containers weren’t a thing until the last decade, so it’s hard to find folks who are truly experts at it. Recruiters often rely on certifications to assess capability, but a certification alone doesn’t necessarily indicate a person’s organizational experience. In addition, university programs provide only basic development skills, resulting in a lack of cloud native technology training for recent grads.

The Solution: Skill up Your People!

So, what’s the solution? Clearly, hiring people who are currently cloud native experts is difficult, ultra-competitive and expensive.

However, look inside your own organization and you’ll likely find people who are highly capable, intelligent and driven. Consider skilling up your existing employee base — your greatest asset — through robust training and certification programs. The benefits of providing a training and certification program to your employees are expansive:

• Competitive advantage — Training your people so they’re well-equipped with the skills necessary to keep your cloud native technology running will increase your agility, scalability and even reduce costs. You’ll develop an immediate competitive advantage in comparison to organizations that haven’t made that same investment in their organizations.
• Consistency and security — By training your people organically through a modern training and certification program, you’ll experience improved consistency across your teams. This consistency can help accelerate your organization’s speed in deploying, adopting and maintaining cloud native technology. In addition, this consistency can help bolster your security posture, as everyone will be following the same frameworks and standards.
• Career advancement — Training and certifying your people leads to career advancement within your organization. By offering opportunities to grow and develop internally, you can encourage mastery in cloud native technology within your employee base. In fact, in our experience with customers, we’ve even witnessed organizations skill up folks who were originally in nontechnical roles and who are now superstars in cloud native technology!
• Talent retention — Talent retention and career advancement go hand in hand. When your people know that they can advance in their careers and therefore increase their earnings within your organization, they’re compelled to stay longer. In fact, according to the American Upskilling Study, 61% of respondents said that upskilling opportunities are an important reason to stay at their job.

Through engagements between our consulting division, VMware Tanzu Labs (formerly Pivotal Labs) and organizations of all types across industries undergoing technological and cultural transformation, we see firsthand how critical learning and development are to their success. We believe cloud native skill gaps are a challenge worth conquering.

Consider skilling up your workforce in order to face this world of modern development, and you’ll be amazed at the outcomes your organization can accomplish. To learn more about the impact of skilling up your people for cloud native technology, check out the webinar “Unlocking the Full Potential of Cloud Native Technology with Education & Training.”

To start supporting your platform and application business goals today, check out freely available training programs:

Spring Academy — A comprehensive, project-based learning platform providing development projects that get you using Spring in real-world development scenarios and can help you prepare for the official Spring Certified Professional exam.

Kube Academy — A resource with dozens of courses led by subject-matter experts that offers hands-on practice with Kubernetes.

Tanzu Academy — An on-demand learning hub for platform and app operators to become experts at achieving desired outcomes with VMware Tanzu products, featuring highly curated material, such as tutorials, guides, hands-on labs infrastructure, and even a certification course that’s recognized across the industry.

Whether it’s enhancing platform and app engineering processes, optimizing workflows, or ultimately making your organization move more quickly, courses such as those offered in these active learning hubs can help equip your people with the skills they need to make your cloud native strategy successful.

The post Cloud Native Skill Gaps are Killing Your Gains  appeared first on The New Stack.

Kubernetes release 1.27 is boring, says Xander Grzywinski, a senior product manager at Microsoft.

It’s a stable release, Grzywinski said on this episode of The New Stack Makers from KubeCon Europe in Amsterdam.

The release has 60 total features, Grzywinski said. The features in 1.27 are solid refinements of features that have been around for a while. It’s helping Kubernetes be as stable as it can be.

Examples?

It has a better developer experience, Grzywinski said. Storage primitives and APIs are more stable.

“Storage primitives have been around in Kubernetes for a while, and people have debated whether you should store persistent data on Kubernetes,” he said. “But I think a lot of those primitives and APIs have become more stable. So one of the new ones that have gotten some excitement is the read-write-once access method. So there’s a feature now where you can restrict access of a storage volume. Only one pod at a time can read and write from it. Things like that. That’s like just general refinement that makes the developer experience a little bit better.”

The Cloud Native Computing Foundation (CNCF) hosts critical components of cloud native software stacks, including Kubernetes and Prometheus. CNCF serves as the neutral home for collaboration and brings together the industry’s top developers, end users and vendors.

Learn More

The latest from CNCF

It’s not all boring.

The Vertical Pod Autoscaler (VPA) is pretty cool, Grzywinski said. It’s in alpha this time, but it will allow pods to scale to larger resources on demand. It will enable users to scale up to a configured level without restarting.

According to its GitHub page, when configured, VPA sets the requests based on usage, “allowing proper scheduling onto nodes so that appropriate resource amount is available for each pod. It will also maintain ratios between limits and requests that were specified in initial containers configuration.”

Efforts will continue to communicate better without surprises.

For example, there’s a new depreciation process that came based on feedback from the community. Grzywinski noted the Dockershim removal that caught a lot of people by surprise in release 1.24.

The New Stack’s Joab Jackson reported in March of 2022 that Dockershim would no longer be supported.

The lesson learned: over-communicate so there are fewer surprises. For example, Grzywinski said a blog is launching dedicated to deprecations and removals that will get pushed out earlier than the regular release blog.

The post A Boring Kubernetes Release appeared first on The New Stack.

Cloud native success is a delicate balancing act. You must continuously take advantage of new and exciting technologies while you simultaneously keep operations rock-stable and reliable.

This isn’t easy. Microservices architecture adoption on container-based infrastructure means you can iterate changes quickly and pivot swiftly to meet the rapidly evolving needs of your customers. So you do.

But every time you introduce a new tool, make a process adjustment or change an app or infrastructure component, you risk creating a problem within your environment. What did you break? Where? There are frequently too many complexities and variables in cloud native to quickly triage.

Then there are the other, familiar-but-different risks your DevOps and system reliability engineering (SRE) teams face in their new cloud native setups:

• Human error abounds: 42% of enterprises experienced downtime due to human error in the last three years.
• External malicious actors keep trying: 40% of global businesses have suffered a cloud-based data breach in the last 12 months.
• Longer mean time to detect and mean time to repair affect operations: Because of little visibility into complex cloud and hybrid environments, it’s harder to get back online fast.
• Poor app performance loses customers: After waiting just three seconds, 50% of potential customers will abandon your website.

All this directly affects your business. A recent ITIC survey found that the hourly cost of downtime now exceeds $300,000 for 91% of businesses, and nearly half (44%) said that a single hour of downtime can cost more than $1 million.

In the on-premises world, application monitoring tools have helped track down and mitigate these problems. In cloud native environments, not so much.

Chronosphere is the only observability platform that puts you back in control by taming rampant data growth and cloud native complexity, delivering increased business confidence. Engineering organizations trust Chronosphere to help them operate scalable, highly available, and resilient applications.

Learn More

The latest from Chronosphere

Learn the Difference between Observability and Monitoring

Monitoring is simply the process of observing and recording the activity of a system. Monitoring tools collect data about how an application is functioning. The software then sends that data to a dashboard to analyze, and perhaps trigger alerts if previously established thresholds are exceeded.

Monitoring keeps on top of the health of your applications, helping you to stay vigilant to known points of failure.

As a superset of monitoring, observability includes all of these capabilities, plus more. That’s because you need more, and more varied, tools when troubleshooting complex, cloud native distributed systems. The kinds of failures you will encounter are not predictable or even known ahead of time. Observability helps your teams catch and remediate the so-called “unknown unknowns” in the new cloud native world.

Observability is not a completely new idea or category of technology; its roots are in monitoring. Both monitoring and observability are an evolution of control theory, a mathematical concept that uses feedback from complex systems to change their behaviors so operators can reach desired goals. The underlying principle is that a system’s visible “outputs” can help users infer what’s happening internally.

A Major Difference in Objectives

But the most important difference between monitoring and observability is the immense gap between their respective objectives.

Monitoring is used to watch over and improve application performance.

Observability is more about using internal measurements of a cloud native system to influence a business-centric outcome or goal. What is the impact on users? On customers? How can you iterate more agilely? And how can you deliver more benefits more quickly to the business as a whole? Observability is about having a bigger-picture approach to keep systems up and running.

The ‘Three Pillars’ of Observability, Redux

Here’s a rundown of the three types of telemetry:

• Metrics: Measurements taken of a system, typically within or over a set period of time. Metrics help businesses detect where there might be a problem.
• Logs: Timestamped records of an event or events. Logs describe the nature of a problem, and why it is happening.
• Distributed traces: A record of events that occur along the path of a request. Distributed traces indicate where a problem is to help troubleshoot an issue.

Though these three types of telemetry are essential in achieving observability, a growing number of voices say observability is more than just data collection and analysis.

One way to think about observability is to focus on the outcomes. This approach defines three phases of observability: know, triage and understand. The key difference from the traditional definition is that during each phase, the focus is to alleviate the impact on users and customers as quickly as possible.

Here’s how the three phases work:

• Know: First you must know there is a problem. If there’s a fire in the house, the first sign is usually the smell of smoke. In a cloud native environment, it’s essential to get an alert or on-call page to start the remediation process.
• Triage: Then gather your resources to fix the problem. Put the fire out. Make sure your users and customers are back to business as usual. Only then can you concern yourself with why and how an issue happened.
• Understand: Finally, try to figure out the “why” after you resolve the problem. Then you apply your learnings to the system to ensure it doesn’t happen again.

The Four Elements of Observability

Leading observability tools tend to share certain characteristics. Here are four of the key ones to look for when evaluating observability platforms.

1. Embrace Interoperability

The data that feeds into observability tools (metrics, logs, and traces) come from a broad range of sources or instrumentation. This data provides visibility into both apps and infrastructure and can come from instrumentation within apps, services, cloud, mobile apps or containers. The data also comes in a variety of formats: open source, industry-standard or proprietary.

The growing number of sources, both proprietary and open source, means that observability tools must collect all data from all types of instrumentation to get a full picture of your environment.

DevOps and SREs thus need an observability platform that possesses comprehensive interoperability of all data through open instrumentation, no matter where — or what — it comes from.

2. Abundant Context

Context in IT systems is the same as in real life. It would be very difficult to interpret the “data” we humans take in every day without context. How things are said, where they are said, and even such things as weather and whether we are hungry can affect our interpretation of real-life information.

For observability, the same applies. Telemetry data is very important as it gets insights into the internal state of applications and infrastructure. But contextual intelligence is also important.

You may want to know how a system performed last week, or yesterday. What is the configuration of the server the system is running on? Was there anything unusual about the workload when an issue occurred?

Leading observability platforms enable you to enrich your data with context to eliminate noise, identify the real problems and easily figure out how to fix the issue.

3. Programmable Tools for Customizable Searching and Analyzing

You also want the ability to customize your observability tools so they meet your specific business needs.

First, taking a step back. It’s important to understand that the key to any observability strategy is setting appropriate success metrics and establishing key performance indicators (KPIs) that tell you when your team meets those success metrics.

Still, traditional KPIs, although useful for monitoring and measuring app performance, don’t indicate how issues affect users, customers and businesses that rely on cloud native environments. No one is connecting the dots.

The traditional answer has been to visualize KPIs in dashboards. DevOps and SRE professionals must get beyond dashboards to fully connect observability with business outcomes. They must create apps that provide an interactive experience with the KPIs that use automated workflows, and which integrate external data with internal metrics in real time.

This gives businesses simultaneous insights into the technology, the business and the users. Your teams can make data-driven decisions that target particular improvement KPIs. And the return on investment (ROI) and effectiveness of new software investments can be optimized. A programmable observability platform helps your teams understand data, systems and customers. This helps you get the right data to the right people to ensure any business that supports your infrastructure runs smoothly.

4. An Accurate Source of Truth

Because you have so much data coming from so many places, it is dizzying (and impossible) to switch between different observability tools. You want complete visibility into your entire system by seeing everything, from anywhere in real time.

How Can Observability Help Me?

Observability helps cloud native businesses in many ways. Here are four in particular that distinguishes observability from basic monitoring:

Nurture a Culture of Innovation

Observability tells you very quickly what works and what doesn’t, so you constantly improve performance, reliability and efficiency in ways that benefit the business. As you grow your understanding of how technology supports your business, you can continuously optimize your infrastructure and services to align with customer expectations and avoid downtime or service interruption.

Make Wise Investments in New Cloud and Leading-Edge Tools

Engineering teams are no longer overseeing only physical computing hardware; now they’re constantly wrangling data and cloud infrastructure. By tracking business performance data, internal processes and customer-facing services instead of just system availability, IT can better prioritize any on-call pages or specific outages. It means IT can provide the necessary data for management to make critical investment decisions for future software, data collection and cloud services.

Get Real-Time Insight into How Your Digital Business is Performing

When you aggregate many disparate levels and types of facts into dashboards you know precisely what is happening in your environment and how it affects your business.

Information can include standard telemetry data, resource optimization feedback, business-oriented KPIs and user experience metrics. Real-time collection allows you to respond to any incidents before your customers notice.

Accelerate Time to Market of Cloud Native Applications

Agile workflows enable developers to quickly create, test, iterate and repeat, to get cloud native applications into production faster and with fewer errors.

But frequent iterations in any system can introduce potential issues and increase the risk of deployment. DevOps teams can take the feedback from observability and diagnose and debug systems more swiftly and effectively with continuous delivery and continuous integration (CI/CD) to reduce time between feature testing and deployment.

Evolve or Languish

DevOps engineers and SREs that manage cloud native environments face challenges daily. They must constantly make sense of the complexity of distributed systems, detect difficult-to-isolate issues and expedite troubleshooting so that the business isn’t affected by digital disconnects or even failures.

Monitoring tools have their place, but they’re not enough on their own. Today’s businesses must understand the direct connection between the technology they’re deploying and business success. They must support business needs with relevant data.

It’s also paramount to continuously stay on top of data collection to ensure developer productivity, meet fast time-to-market demands and deliver an exemplary customer experience.

Observability is the natural step forward from monitoring software. It provides the competitive advantage to stay relevant in today’s cloud native market through data cost control, faster time to remediation and reduced downtime.

The post Why Upgrade to Observability from Application Monitoring? appeared first on The New Stack.

With digital transformation sweeping across industries, we are seeing more and more organizations adopting cloud native technologies to modernize their IT infrastructure. Kubernetes have become the go-to solution for many when managing containers at scale.

While my experience building Red Kubes as CTO has highlighted the need for these technologies, it has also shed light on how integral the adoption process is for companies and organizations, such as The Municipality of Utrecht in the Netherlands.

Together, we addressed a common issue being complex and siloed applications. For context, Utrecht is one of the largest municipalities in the Netherlands that deals with a myriad of applications and huge volumes of data.

Essentially, its IT infrastructure needed a more modern approach to improving its services for the residents. I’m sure you’ve personally experienced the struggle and frustration of trying to get something from your council, municipality, or city.

The Challenge:

At Red Kubes, we designed Otomi (our open source platform) to address these issues, we personalize each aspect of the platform to meet the needs of the user. Considering the challenge lay in speeding up delivery, building connections between these siloes was of utmost importance.

Otomi logo

Before we stepped in, the process when updating (or even changing) was time-consuming, costly and complex.

Furthermore, there was an increasing need for collaboration and information exchange between municipalities, but the current architecture made it difficult to achieve.

I believe many organizations are facing similar issues in modernizing their infrastructure to support more modern application architectures

To address these challenges, Utrecht, along with 15 other major cities, initiated a review of their current information systems and architecture based on “Common Ground.”

The goal was to establish modern standards for data exchange between municipalities through microservices and an API-driven approach. The new standards could not be supported by the existing infrastructure so there was a need to transition to a modern architecture.

As applications and workloads were to be containerized for better cloud portability, Kubernetes was identified as the ideal solution for container orchestration.

Utrecht recognized that they would need to hire talent or contractors with the necessary skills and expertise to set up and manage a Kubernetes environment.

It’s a good thing the city was aware of the complexity of Kubernetes but especially what comes after installing a Kubernetes cluster.

The Solution:

Utrecht searched for a solution that would make Kubernetes easily manageable and ready for production without requiring extensive staff training or hiring new talent in such a tight market. The proposed solutions revealed that our open-source project Otomi could deliver to requirements.

In a nutshell, Otomi simplifies Kubernetes Engineering and management of all additional components required to run Kubernetes in a secure, compliant, and automated way providing self-service to developers. It is designed to enable organizations to get the most out of their containerized applications in just a few days.

Utrecht successfully adopted Kubernetes technology by leveraging Otomi and creating a platform engineering team to build a production-ready platform on top of the Azure Kubernetes environment.

This allowed developers to concentrate on coding while the platform engineering team focused on security, compliance, scalability and stability (the important stuff in Kubernetes environments!).

By combining AKS (Azure Kubernetes Service) and Otomi, Utrecht was able to set up its Production Ready Kubernetes environment within a few days instead of the many many months it would have taken using traditional methods.

The Results: Technical, Operational and Security

With the implementation of Kubernetes, topped with Otomi, the outcomes for the city included a host of technical, operational and security benefits. From a technical standpoint, the deployment resulted in faster, automated testing, enhanced observability, monitoring and immediate access to root cause analysis (RCA).

Additionally, automatic scaling of the Kubernetes environment was achieved, a process that previously took three to six months before Kubernetes and Otomi. Now, development environments can be deployed within one minute, providing instant self-service for development teams, compared to months in the legacy architecture.

Utrecht explained to us that the benefits of Otomi were also significant from an operational perspective. Applications can now be deployed within one day, compared to the previous process which took months.

Furthermore, the entire journey from application concept to production now averages around four weeks, compared to the prior duration of at least six to nine months.

The platform also achieved stability with 24/7 uptime, automatic restart and recovery, and up to 40% productivity gain for developers through Otomi’s self-service capabilities.

We were able to uplift the security posture as well as the implementation resulted in numerous improvements, including Open Web Application Security Project (OWASP), microsegmentation, live scanning, traceability, cluster and network policy enforcement, and more.

While naturally, I’m biased, the solution worked extremely well. Utrecht’s Senior Manager of Digital Services Lazo Bozarov, shared that the platform has allowed the municipality to accelerate its containerization and cloud journey in which they have modernized their architecture towards microservices and an API-centric infrastructure. Goal achieved.

By integrating Otomi with Kubernetes, containerization is simplified, reducing the need for extensive environment management. This results in organizations accelerating their container platform’s time-to-value and the applications on it. For organizations like Utrecht, implementing Otomi on top of Kubernetes will lead to substantial cost savings, time reduction and risk mitigation.

As someone who has co-engineered this product from the ground up, it’s rewarding to see these real-life adoptions actually making a difference. It’s also exciting to see how Kubernetes can revolutionize IT infrastructure modernization. There’s a bright future ahead for the world of Kubernetes, especially in organizations such as these.

The post How Otomi Helped the City of Utrecht Move to Kubernetes appeared first on The New Stack.

RabbitMQ is boring. Very boring. And we tend not to think about boring things. RabbitMQ, like the electrical grid, is entirely uninteresting — until it stops working. The human brain is conditioned to recognize and respond to pain and peril more than peace, so we tend only to remember the traumas in life. In this post, I want to try to change that. Let’s talk about RabbitMQ, an open source message broker I’ve been using for the better part of 15 years — happily and bored.

My background is in, among other things, messaging and integration technologies. Unfortunately, legacy systems are often hostile, mostly because those who came before us did not foresee the highly distributed nature of today’s modern, API-dominant architectures, such as cloud native computing and microservices.

There are many ways to approach integration. In their book, “Enterprise Integration Patterns,” Gregor Hohpe and Bobby Woolf talk about four approaches: shared databases, messaging, remote procedure call (RPC) and file transfer. Integration is all about optionality and coupling: How do we take services that don’t know about each other and make them work together without overly coupling them by proximity or time? Messaging, that’s how. Messaging is the integration approach that comes with batteries included. It has all the benefits and few, if any, of the drawbacks of the three other integration styles. Messaging means I can sleep at night. Messaging is boring. I love boring.

With the support of multiple open protocols, such as AMQP 0.9, 1.0, MQTT, STOMP and others, RabbitMQ gives people options and flexibility and interoperability, so a service written in Python can communicate with another in C# or Java, and both can be none the wiser.

The last few decades delivered great advances in infrastructure; now, it’s time to build apps that make the most of those new tools. VMware Tanzu helps you build new apps, modernize existing ones, and evolve your development process around cloud native technologies, patterns, and architectures.

Learn More

The latest from VMware Tanzu

A Beautiful Indirection 

RabbitMQ has a straightforward programming model: Clients send messages to exchanges. The exchange acts as the broker’s front door, accepting incoming messages and routing them onward. An exchange looks at the incoming message and the message’s headers — and sometimes at one special header in particular, called a routing key — and decides to which queue (or queues) it should send the message. These exchanges can even send messages to other brokers. Queues are the thing consumers consume from. This beautiful indirection is why inserting an extra hop between a producer and a consumer is possible without affecting the producer or the consumer.

It all seems so straightforward — and boring! — when you think about it. But you wouldn’t believe how many people got this stuff wrong from the get-go. Let’s look at Java Message Service (JMS), the Java-standardized API for messaging. It has no concept of an exchange, so it is impossible to reroute a message (without sidestepping the JMS interfaces) once a producer and a consumer connect. Meanwhile, some JMS brokers couple the consumer and the producers by the Java driver client to talk to the broker. If the client supports version X of the broker, and someone has upgraded the broker to X+1, then the producer and the consumer may need to upgrade their Java client drivers to X+1.

Born in 2007, RabbitMQ was conceived due to the need for large banks to standardize their digital systems so they and their customers (that’s us) can transact more easily. RabbitMQ implemented the AMQP protocol from the jump; it’s still the most popular way to connect to the broker today. But it’s not the only way.

Let Me Count the Ways

As mentioned, RabbitMQ supports multiple protocols, which certainly offers choice, but there are other benefits as well. Like MQTT, popular in the Internet-of-Things space, where millions of clients — think microwaves, refrigerators and cars — might need to communicate with a single broker in a lightweight, efficient way. This work’s ongoing and keeps getting better by the day. For example, Native MQTT was recently announced, dramatically reducing memory footprint and increasing scalability.

RabbitMQ supports federation and active/passive deployments. It has various approaches to storing the messages in RAM or on disk. It supports transactions. It’s speedy, and it guarantees the consistency of your data. However, RabbitMQ has traditionally served messaging and integration use cases, not stream processing pipelines.

The community around RabbitMQ is vibrant, burgeoning and fast-moving, and the last few years have been incredibly prolific. Have you tried RabbitMQ Streams? Streams are a new persistent and replicated data structure that models an append-only log with nondestructive consumer semantics. You can use Streams from a RabbitMQ client library as a plain ol’ queue or through a dedicated binary protocol plugin and associated clients for even better throughput and performance.

To say it’s been successful would be an understatement. StackShare states that, among others, Reddit, Robinhood, Zillow, Backbase, Hello Fresh and Alibaba Travels all use RabbitMQ.

There are drivers for virtually every language, platform and paradigm. For example, I work on the Spring team, and we have several increasingly abstract ways by which you can use RabbitMQ, starting with the Spring for RabbitMQ foundational layer and going all the way up to the support in Spring Cloud Data Flow, our stream and batch processing stack.

RabbitMQ is open and extensible, supporting unique features with plugins to the server and extensions to the AMQP protocol.

The RabbitMQ site has a nonexhaustive list of some of the best ones. They include things like publisher confirms, dead letter exchanges, priority queues, per-message and per-queue TTL (time to live values tell RabbitMQ how long an unacknowledged message is allowed to remain in a queue before being deleted), exchange-to-exchange bindings and so much more. These are extensions to the protocol itself, implemented in the broker.

Plugins are slightly different. Numerous plugins extend the broker proper and introduce new management, infrastructure and engine capabilities. For example, there are plugins to support Kubernetes service discovery, OAuth 2, LDAP, WAN federation, STOMP and so much more.

What does all this mean for me? It means that, like PostgreSQL, RabbitMQ is a Swiss army knife. Does it do everything that the costly alternatives from Tibco or IBM do? No. But I’ll bet it can do 95% of whatever I’d need, and it’ll do so in a way that leaves my options open in the future. (And you can’t beat the price!)

Maybe it’s just all those years spent wearing a pager or running into data centers with winter jackets on at 3 a.m., but I actively avoid running anything I can’t charge for directly. I prefer to have someone run RabbitMQ for me. It’s cheap and easy enough to do so on several different cloud providers or the Kubernetes distribution of your choice.

As a developer, RabbitMQ couldn’t be more boring. As an operator in production, RabbitMQ couldn’t be more boring. I love boring, and I love RabbitMQ.

If boring appeals to you too, I encourage you to learn more about RabbitMQ, how it works as an event-streaming broker, how it compares to Kafka and about the beta of RabbitMQ as a service.

The post RabbitMQ Is Boring, and I Love It appeared first on The New Stack.

It’s at the point where GitOps is getting enough notice that a brief on its principles is appropriate.

Last year, the OpenGitOps community released GitOps Principles 1.0. There’s general support for GitOps and many competing interests in developing GitOps engines, such as with Argo and Flux, two graduate projects from the Cloud Native Computing Foundation. But focusing on principles lets everyone know what GitOps is and, even more so, helps define what it is not.

OpenGitOps defines GitOps as a set of principles for operating and managing software systems, wrote open source software engineer Scott Rigby. “When using GitOps, the Desired State of a system or subsystem is defined declaratively as versioned, immutable data, and the running system’s configuration is continuously derived from this data. These principles were derived from modern software operations but are rooted in pre-existing and widely adopted best practices.”

With DevOps, operations and development teams collaborate on their own chosen tools. GitOps provides a declarative approach and complements DevOps. It allows for application delivery and cluster management. GitOps shares the same concepts as Kubernetes, making it easier for teams already working with it to adapt.

The cdCON + GitOpsCon conference, held this week in Vancouver, BC,  featured a presentation about the GitOps principles by Rigby, and Christian Hernandez, a senior principal product manager with Red Hat.

Here are a few takeaways, from this talk and others at the conference:

Principle #1: GitOps Is Declarative.

A system managed by GitOps must have a desired state expressed declaratively.

GitOps allows for automating security practices, said Eve Ben Ezra, a software engineer with The New York Times, who spoke at the cdCON + GitOps Con event. DevOps encourages collaboration, which means incorporating security into every stage of the software development lifecycle.

The comparison to security practices dovetails with the second principle of GitOps:

Principle #2: GitOps Apps Are Versioned and Immutable

The desired state is stored in a way that enforces immutability, versioning, and complete version history.

The general viewpoint: rollbacks should be simple.

“You go a step further with GitOps providing an auditable trail of all changes to infrastructure and applications,” Ezra said.

Versioning allows organizations to find gaps in their security and also allows for testing and declarative infrastructure, Ben Ezra said. Using tools like the Open Policy Agent, an open source project for establishing authorization policies across cloud native environments, allows for more productivity because once it’s automated, teams spend less time agonizing over whether or not their infrastructure is compliant, which gives them more time for innovation and feature development.

“While automation is an important part of DevOps, it’s by no means the only methodology also calls for cross-functional collaboration and the breaking down the silos and knowledge sharing across an org,” Ben Ezra said. “GitOps builds on these principles of leveraging automation and infrastructures as code to reduce configuration drift, and providing a single source of truth for an entire team or org.

By writing it down, all team members can contribute to the infrastructure code, which promotes shared responsibility across the entire software development lifecycle. Just as importantly, everyone is aware of these changes, so they can speak up if they see something you missed.”

“For example, at the New York Times, we’ve leveraged utilities from OPA to improve feedback and developer productivity within GitOps operational framework,” Ben Ezra said.

Principle #3: GitOps Apps Are Pulled Automatically

Software automation automatically pulls the declared state declaration from the source.

Take Flux, for example. Flux is a set of continuous and progressive delivery solutions for Kubernetes that are open and extensible, enabling GitOps and progressive delivery for developers and infrastructure teams.

“So Flux is a set of continuous delivery tools that are focused on security, velocity and reliability,” said Priyanka Pinky Ravi, a developer experience engineer with Weaveworks, in a keynote with other engineers from Cloud Native Computing Foundation graduated projects.

“And they are focused on automation. So the idea is that you have this setup Kubernetes controllers that you install onto your cluster, and they’re running on a reconciliation loop which is just an interval that you set. And every time that runs, the source controller will go in and pull from whatever source you said, such as a git repository, home or repo Image, Image registry, OCI registry. And the idea is that it pulls the manifests that it finds there and then actually applies them onto your cluster.”

Principal #4: GitOps Apps Are Continuously Reconciled

“Software agents continually observe the actual system state and attempt to apply the desired state.”

Of note are the different views that reflect the GitOps community. But with a set of principles, the community can build approaches that reflect the core focus of what GitOps is and what it is not; at least, that’s the concept.

Start reading the discussions on GitHub; there are still issues to clarify, even when explaining the meaning of pull.

And there’s more on the Twitter threads. Enjoy.

When
1. An operator pushes a button on GUI to change the running system state directly without updating the desired state
2. Failures leading to drift from the desired state

Now either
A) an agent changes the system back to correct state
Or B) system is in an unknowable state

— Alexis Richardson (@monadic) May 11, 2023

1) Any pipeline not stored in git (just setup in a ui for example)
2) A pipeline that doesn’t deal with desired state at all, (just running a build, testing an image, gathering metrics, doing a data transformation, updating a database etc)
3) Any pipeline operating without…

— Dan Garfield (@todaywasawesome) May 11, 2023

The post 4 Core Principles of GitOps appeared first on The New Stack.

Mirantis, the Docker and Kubernetes developer company, has released the latest version of its lightweight, open source Kubernetes distribution, k0s. The new version boasts compatibility with the brand-new Kubernetes 1.27 release with various other improvements and bug fixes.

Infrastructure enables innovation. HashiCorp provides consistent workflows to provision, secure, connect, and run any infrastructure for any application.

Learn More

The latest from HashiCorp

Back to Basics

K0s, for those that don’t know it, is one of several stripped-down, back-to-basics Kubernetes distros. Others include Minikube, k3s, and MicroK8s. While they all have their differences, the name of the game is to give developers the power to create Kubernetes clusters on low-end hardware. For example, K0s can run on as little as a single CPU and 1GB RAM for a single node.

The updated Mirantis k0s distribution significantly simplifies the installation and management process of Kubernetes clusters. One of the key enhancements includes support for containerd plug-ins, such as WebAssembly (WASM) and gVisor container sandboxes. This enhancement simplifies the running of these containers It also enables users to extend their clusters with additional container runtimes effortlessly.

Furthermore, to eliminate custom forks of project components and to ensure greater compatibility upstream Kubernetes functionality, Mirantis now provides its own system images, which in turn reduces complexity and improves security.

For one thing, many upstream Kubernetes system images contain Common Vulnerabilities and Exposures (CVE). For instance, Miska Kaipiainen, Mirantis VP Engineering, Strategy & Open Source Software, states that “If you scan a kube-proxy image at registry.k8s.io/kube-proxy:v1.25.8, you’ll see 12 vulnerabilities reported (or some other number, depending on the scanner you use).” Sure, many of these CVEs, such as old curl binaries and libs in the container, aren’t used at runtime. But you never know when that “harmless” CVE might turn out to be exploitable. So Mirantis takes full control of k0s images built with pure upstream functionality and doesn’t rely on any custom forks of project components.

The result? “As of this writing, system images shipping with k0s 1.27 come with zero (0) – yes, zero – known vulnerabilities. We have daily scanning in place, which lets us keep track of vulnerabilities as they pop up and mitigate them super-quickly.”

CNCF Certified

A Cloud Native Computing Foundation (CNCF)-certified Kubernetes distribution, k0s, is versatile enough to run on any Linux-based operating system, making it suitable for large-scale data center deployments, lightweight edge clusters, laptops, and even Raspberry Pi. K0s is distributed as a single binary and can be installed on any node from the internet with a single command.

For ease of management, platform deployment, and scaling can be administered locally via the k0s command line interface (CLI) and remotely via the k0sctl utility using configuration files. The built-in k0s Autopilot enables you to manage updates automatically. Additionally, operators can access k0s clusters via kubectl, Lens Desktop, and other standard Kubernetes CLIs and dashboards.

So, if you want a safe, lightweight Kubernetes for your work, play, or study, I’d give K0s a try. It’s a nice little distro.

The post Mirantis Updates k0s Lightweight Kubernetes Distro appeared first on The New Stack.

One of the most consistent barriers to contributing to open source is the dominance of the English language. These highly distributed, remote teams rely on asynchronous communication for code, documentation, Slack channels, mailing lists and more, making it hard to even get started if you don’t have a confident English level.

Since open source contribution relies on a lot of unpaid labor, many continue to volunteer because they feel part of a community. Those with a higher level of English language confidence are proven to feel a greater sense of belonging and thus have a higher intrinsic motivation.

This means those that don’t read, write or speak English proficiently are cut out of the opportunity that is open source — from technical and project management experience to networking to work requirements. And open source communities can access far fewer users and contributors. A direct result is that open source contributors reside predominantly in the Global North, meaning those that could potentially benefit the most from reliable and free software, are kept out of it.

And, with tech being the future, and open source making up about 70% of stacks, the predominance of the English language means whole countries are being locked out of participating in building our shared future.

Thankfully, some communities are starting to understand this risk to open source sustainability and are making an effort to translate their documentation. But again this is a time-consuming, largely voluntary effort.

The Cloud Native Computing Foundation‘s largest project — Kubernetes — has successfully translated its core docs into 14 languages, with at least three more in the works. At the recent KubeCon+CloudNativeCon Europe, Divya Mohan and Natali Vlatko, two of the three co-chairs of the massive documentation special interest group or SIG Docs, outlined the process of dismantling this inclusion hurdle — while of course encouraging others to contribute to localization.

Infrastructure enables innovation. HashiCorp provides consistent workflows to provision, secure, connect, and run any infrastructure for any application.

Learn More

The latest from HashiCorp

What Is Localization vs. Translation?

Mohan and Vlatko, along with Rey Lejano, are in charge of setting up the procedural, administration and technical approvals that are required around the documentation, which includes the whole Kubernetes website, reference docs, the blog and localization.

“We talk about translation, but it’s really more than that,” Vlatko underscored. “Localization is the act of translating and maintaining Kubernetes documentation into your native language.”

There’s an emphasis on “native here” because, she continued, “We really do rely on contributors who know how to translate a term that may actually have many words that could be used, many phrases that could be used in a certain translation. And we want our docs, which are used by people all around the world to actually learn about and use Kubernetes. We actually need them to be as technically accurate and then language-wise accurate as possible.”

That makes this a global project requiring a community of native speakers who understand the technology.

“Localization is not just about translation. It’s about community. It’s about doing a lot of work. But then it’s also about helping users adopt and welcoming them into your native community as well,” Vlatko continued.

It All Starts with a Community

The first step in open source localization is finding your community. “We need folks who are not only going to work together but actually approve each other’s stuff,” Vlatko said. With this in mind, the Kubernetes SIG Docs require a minimum of two owners for a localization to launch — already preparing to reduce the fragility of open source projects that have a single maintainer.

Then, to further reduce loneliness and to increase support, SIG Docs has created the Localization subgroup, which runs across languages and writing systems. Each localization subproject is then able to organize themselves as they see fit, in a way that’s most welcoming in their culture.

“So each of these subprojects has a different way of functioning,” Mohan later told The New Stack. “In turn, this also cascades to the various translations within the localization subproject as well. Each translation has a team and contributors that have different processes and meetings.”

With all languages, including English, Vlatko noted that building the community is not only the first step but the most challenging. After all, like all things open source, it relies on unpaid volunteers.

The localization subproject meets at 3 p.m. UTC the first Monday of each month. Notably, they follow a remote work best practice by speaking in the specific timezone UTC, which is both universal and doesn’t change with seasons. They also have asynchronous communication staples including a mailing list as well as a Slack community. The SIG also has an open agenda policy to allow for a more open, questioning culture.

What Are the Requirements to Get Started with Localization?

Community is the first but not the only requirement. You also already have to be an active Kubernetes organization member, before you can start your own community. That means you already understand and are committed to the project, but also are logistically able to review pull requests and take ownership of the work. This could be a technical contribution or contributing to another localization project including the English documentation.

Then once these standards of interest, community, and existing involvement are met, you can launch your localization. First, find your ISO 639-1 two-letter language code, which is used for the repository branch creation and naming your Slack channel.

Then, create a localization Slack channel so you are able to organize in your native language. The first thing that needs collaboration and localization of is the Kubernetes community code of conduct.

There are also other minimum required pieces of Kubernetes content for translation before the release of the project:

• Home page
• Setup
• Tutorials, both Kubernetes Basics and Hello Minikube
• All site strings
• Releases

What Localizations Exist and How You Can Contribute Today

Currently, the Kubernetes SIG Docs is in 15 languages:

• English
• French
• German
• Hindi
• Indonesian
• Italian
• Japanese
• Korean
• Mandarin
• Polish
• Brazilian Portuguese
• Russian
• Spanish
• Ukrainian
• Vietnamese

There are also existing subgroups in Bulgarian, Tamil, and Turkish, which hope to release localized docs and websites in their languages too.

Not to make English the default language, Mohan pointed out that English is also a localization. “If you are already familiar with Kubernetes or if you’re even just getting started, we really appreciate your points of view on how we could make the documentation better, whether that’s clarifying how a particular concept is explained or making a minor typo edit, it’s highly appreciated,” she said.

To get started contributing, you must sign the Kubernetes contributor license agreement. Then, you can join a community, best kicked off via the respective Slack channels, for both existing and upcoming localizations.

Then join both the SIG Docs and SIG Docs localization mailing lists. And attend those monthly meetings.

“Those are really good avenues to clarify your doubts. Because it’s a group of folks who are already working on the same stuff,” Mohan remarked.

This is a massive project, she commented, so start by posting on the SIG Docs Localizations Slack channel. Just don’t ask your questions in private, she recommends, as you run the risk of inundating the localization leads, while also not giving everyone the opportunity to respond. Plus, there can be doubts others share.

The mailing list, bi-weekly Tuesday SIG Docs meeting, as well as the fourth Wednesday of every month, has an APAC meeting.

Each localization project has about 25 to 50 contributors, Mohan estimates, but some languages manage to function with less.

“Most projects I know need help,” she said. It’s encouraged, if you’re interested in Kubernetes localization for your native language or find benefit from Kubernetes in some way, that you volunteer time and give back.

Hindi: A Kubernetes Localization Case Study

“Finding your community. Finding your tribe to build a localization is one of the most challenging aspects,” Mohan said, having learned it the hard way kicking off Hindi, the newest completed localization. This is the first localization in the Devanagari script, which is used for Sanskrit, Hindi and other Indian languages. The Hindi localization team now has six leaders, including two that are regular contributors over the past year.

The Hindi effort kicked off in late 2021 and launched at the end of August 2022. There are currently 245 Hindi speakers active in the respective Slack channel.

Localization into Hindi means opening up a language spoken by more than half a billion people.

“They’re still ongoing because docs are never done. They update every release cycle, and tracking those changes is a lot of manual effort currently. The people leading the localization are required to actively track the docs that change per cycle and put out issues for them, ask contributors to come and chip in, and this is an ongoing effort that doesn’t stop at the point the localization goes live,” commented Mohan.

The post Kubernetes Community: A Guide to Open Source Localization appeared first on The New Stack.

Ten years ago, Docker released its first version of what democratized container technology. According to a recent survey, it is still the most used software package technology, with Maven and NPM listed as second and third, respectively. To celebrate the anniversary of the Docker container technology, let’s explore four areas — and their associated open source tools — where developers can better use Dockerfiles and images.

Lint Your Dockerfiles

I’ve always liked to use linters, which ensures that your work is perfect and gives the satisfaction of seeing a green check mark after all the little details are adjusted. We, humans, tend to forget things and make typos. That’s where linters come to the rescue.

Hadolint is one of the most popular open source linters for Dockerfiles. A linter examines a Dockerfile for errors. It uses a set of predefined rules — the complete list is available here — to analyze your Dockerfile and provide recommendations for improving its syntax style, efficiency and consistency.

Hadolint checks for issues such as using the latest tag, incorrect syntax and unnecessary instructions. You can also bring in your own custom rules or ignore predefined rules that don’t apply to your use case. Hadolint is easy and quick to run from your command line interface, and it runs on Linux and Windows.

Run a Security Audit on Them

The Snyk 2022 Container Security Trends report found that 46% of respondents mentioned security being a bottleneck that slows the speed of cloud deployment. And while container-based distributed architectures can provide benefits such as increased scalability, flexibility and fault tolerance, they also introduce new security challenges that need to be addressed.

Dockle is an open source tool that performs security-focused analysis on Docker images and Dockerfiles. It analyzes various aspects of the image build, such as ensuring the use of trusted base images, the exclusion of unnecessary packages and that security patches have been applied. It also checks for configuration-related issues such as unnecessarily exposed ports, the use of the root user and the storage of secrets. This tool fits well in a shipping pipeline and can help ensure that Docker images are secure.

Build and Update Them

Building Docker images is an art, and while some have been doing it for a decade, there is a constant flow of newcomers. The recent platform engineering movement was clear about one thing: the fewer Ops tasks developers can do, the better. And the responsibility of writing Dockerfiles often ends up with developers who may not have the knowledge to do it properly.

Paketo Buildpacks are a collection of open source Cloud Native Buildpacks that transform your application source code into images that can run on Docker runtimes. These images can even be built without the need for Dockerfiles.

With a single command, the tool will automatically detect your application language and automatically build a Docker container image that fits production requirements, including dependencies, language runtimes and other components. It supports popular programming languages such as Golang, Java, Node.js, Python, Ruby and PHP. Paketo isn’t only helping to build container images; it helps to maintain them as well. The tool even allows updating the OS layer of your app images without rebuilding your source code.

Minimize Them

The size of Docker images getting out of control is a well-known issue: The 2020 Docker Usage Report, from Sysdig, found that the average size of Docker images has increased by 75% since 2016, and the average size of a Docker image is 1.5 GB.

Slim, which was initially created during a Docker Global Hack Day project, is tackling this. The open source tool can minify Docker images by up to 30 times their original size. The tool inspects the container metadata and data, and it runs the application to build smaller images. The results are impressive; for example, Slim minimizes the Ubuntu 14.04 Ruby Docker image from 433MB to 13.8 MB (31x).

A Decade of Docker

As the most used containerization method with a year-over-year growth of 10% in 2022, Docker isn’t going anywhere. The company, which struggled to adjust when Kubernetes won the orchestration battle, has been gaining momentum and recently announced WebAssembly tooling. Happy birthday, Docker! I hope this list of tools will help many to make better use of it.

The post 4 Ways to Enhance Your Dockerfiles appeared first on The New Stack.

A ZeroOps philosophy helps organizations focus more on innovation and less on infrastructure while helping accelerate development and save both time and money. Much of the conversation around ZeroOps strategy focuses on Kubernetes, but for some companies — or even teams within larger organizations — Swarm can be better suited to their requirements, such as:

• Smaller clusters under strict security regimes;
• Teams that need to migrate to containers quickly and simply, with minimal friction; and
• Small, high-velocity companies that need the benefits of container orchestration without the complexity of Kubernetes.

An open source container orchestration engine, Swarm has a focus on simplicity for developers is already closely aligned with the goals of ZeroOps, making it easy to get teams or new hires up and running quickly and enabling developers to focus on code. But the opportunities to realize a ZeroOps vision run deeper.

Here are three ways Swarm can help make life easier for developers:

1. Automation for a hardened software supply chain — and reduced developer burden

Cloud native security is tough at the best of times, and it’s all too easy for errors and misconfigurations to fall through the cracks. This gets even more challenging for developers when more and more responsibility for security “shifts left” to earlier in the development cycle.

Moby, the open source project underlying Swarm, provides a framework that can help take the burden off of developers, integrating smoothly with other tooling to provide automations and self-service platforms, such as:

• Drawing images from a;
• Scanning container images for vulnerabilities; and
• Signing and promoting images through your pipeline.

With these kinds of automations in place, you can reduce the surface for error in your development cycle.

2. Managed Swarm — so you can focus on value

Swarm was designed to be simple for developers, but that comes at the expense of some operational complexity. There are plenty of pitfalls and stumbling blocks for the would-be Swarm operator, from the proper configuration of overlay networks to storage provisioning.

Leveraging Swarm as a managed service enables you to focus internal resources on what brings you value — not infrastructure-wrangling.

While major cloud offerings are sometimes described as “managed,” the actual day-to-day operations are usually left as an exercise for the user. Look for a managed services provider who provides a truly managed service, including fully-managed remote operations with up to 99.99% SLA.

3. Tailor your developer platform to your needs

If you’ve decided that Swarm is the right fit for your needs, developer experience is likely a high priority. You want a platform that supports smooth, intuitive, high-velocity development and deployment — but you may have particular requirements to cater to around in-house tooling, compliance requirements, organizational structure or many other variables.

In cases like this, you may get optimal results from platform engineering. Platform engineering is the practice of building self-service, cloud-native development processes and pipelines tailored to your needs. Swarm can be a natural fit for the heart of your platform-engineering efforts, providing an easy-to-use, intuitive core for orchestration, integrations with security tooling and emerging features like Container Storage Interface (CSI) support.

Platform engineering can be a big lift, of course—and misconfigurations can be costly. For expert support, you may want to seek out a platform engineering partner who can help you implement the tools to manage Swarm effortlessly and integrate DevSecOps tools and practices, regardless of where and how you’re running Swarm.

Whether you engineer a platform, rely on managed services or build your own pipeline of integrated tools, Swarm brings the simplicity, flexibility and power to drive an accelerative ZeroOps strategy.

The post 3 Ways to Achieve ZeroOps with Docker Swarm appeared first on The New Stack.

Bobsled, a new venture based in Los Angeles, this week introduced its Data as a Service (DaaS) sharing platform and highlighted the data economy business requirements that are its underpinnings. The company also announced its Series A funding round, led by Greycroft and Madrona Venture Group.

Bobsled is working to make data sharing a universal prospect, providing connectivity to the major public cloud and data cloud platforms (including Microsoft Azure, Amazon Web Services, Google Cloud, Snowflake and Databricks) and providing the full plumbing necessary for dataset trial, subscription, version control, distribution and telemetry. Bobsled also supports delivery to numerous levels of the modern data stack, including data warehouse, data lake, notebook and business intelligence (BI) platforms.

Boblsed’s co-founder and CEO, Jake Graham, previously led the development of Microsoft’s Azure Data Share service, providing Bobsled with concrete knowledge of how to provide a sharing service, as well as a contextual understanding of what’s lacking in existing data sharing platforms. Additionally, as a result of the financing round, Bobsled is adding Greycroft Principal Brentt Baltimore, Madrona Managing Director Soma Somasegar, and .406 Ventures Partner Graham Brooks to its Board of Directors. Madrona was one of Snowflake’s early investors and Somasegar ran Microsoft’s Developer Division for several years, bringing even more domain expertise to the table.

A Contemporary and Legacy Need

For about as long as data has been around, there has been a need to share it, within teams, across business units and between organizations. The effort around doing so goes back decades and has engendered its own slate of acronyms and technologies. Approaches have included the generation of CSV (comma-separated values) “flat files” from the mainframe, more formal use of EDI (Electronic Data Interchange) across VANs (value-added networks), and erecting FTP (file transfer protocol) sites to allow parties to download data feeds. In addition to CSV and similar delimited text formats, data sharing provided the inspiration for longstanding formats like XML (Extensible Markup Language) and JSON (JavaScript Object Notation), as well as newer formats like Parquet that have given rise to the modern data lake.

But providing these technology nuts and bolts doesn’t constitute a true sharing service, any more than the provision of phone lines and email provides for customer service. Instead, these technologies have had to be cobbled together by technology teams, typically in an ad hoc manner, in order for data-sharing workflows to be operationalized. As a result, until recently, these efforts have been bespoke, at best.

Meanwhile, with the rise of the data mesh approach to data management, and its constituent innovation of “data products,” the demand for data sharing has grown, and budgets have materialized to make that demand a concrete business opportunity rather than a mere enthusiast wish-list item.

Efforts to Date

Critical mass has started to form in the last few years around more modern data-sharing protocols. Microsoft introduced Azure Data Share back in 2019, and has morphed it into Microsoft Purview Data Sharing. Databricks built the Delta Sharing protocol an open sourced it under the auspices of The Linux Foundation. Snowflake introduced Snowflake Data Sharing a while back, allowing a virtual warehouse interface to be built around shared data. Numerous vendors have also established data marketplaces to help organizations get to and use relevant third-party data sources.

But these protocols tend to be limited in scope and/or versatility. Purview Data Sharing works only between Azure Data Lake Storage (ADLS) Gen 2 or Azure Blob Storage accounts. Snowflake Data Sharing is, as the name would imply, something that gets implemented within Snowflake’s “data cloud.” Delta Sharing is more flexible, for a few reasons: it’s open source, it’s a protocol rather than a feature, and it can be integrated at the data lake, data governance, data developer, or BI tool layer of the modern data stack. Nevertheless, the protocol’s most concrete implementation as a full service is Databricks Delta Sharing.

Sharing Is Caring; Integration Brings Agitation

While data sharing has historically facilitated point-to-point data transfer, the modern crop of data-sharing platforms looks to provide discovery and connectivity, too. Bobsled is all-in on that reimagining of the space and it is explicitly looking to help eliminate the creation, maintenance and customization of data ingestion pipelines, in order to minimize complexity and (earnestly) compress time-to-value.

Sometimes the best new technology categories aren’t the ones that bring about some raw, novel innovation, but instead create adoptable platforms around things that numerous organizations have been building themselves, repeatedly and informally, often driven by urgent requirements that don’t leave time or budget for fit, finish and resiliency. A solid data-sharing platform looks like it falls into this latter category. And, as a data-sharing provider that operates independently of any particular cloud or data platform, Bobsled may bring the neutrality necessary to provide cross-platform versatility, in addition to base functionality.

The post Bobsled Offers Platform-Neutral Data Sharing Service appeared first on The New Stack.

To stay competitive, companies must adjust and adapt their technology stack to accelerate their digital transformation. This means engineering teams now experience exponential data growth that is starting to outgrow underlying infrastructure. That requires durable infrastructure that can support rapid data growth and high availability. With cloud native architecture, companies can meet all their availability requirements and effectively store data in real time.

So what is cloud native? Well, cloud native is an approach to build and run applications that takes full advantage of cloud computing technology. If something is “cloud native,” then it is designed and coded to run on a cloud architecture at the start of the application development process like Kubernetes.

At its core, cloud native is about designing applications as a collection of microservices, each of which can be deployed independently and scaled horizontally to meet demand. This allows for greater flexibility because developers can update specific services as needed, instead of updating the entire application.

Such agility lets engineering teams rapidly deploy and update applications through agile development, containers and orchestration. It also provides improved scalability because teams can easily spin up containers in response to traffic demand, which maximizes resource usage and reduces cost. Additionally, applications that are distributed across multiple servers or nodes mean that one component’s failure does not bring down the entire system.

Chronosphere is the only observability platform that puts you back in control by taming rampant data growth and cloud native complexity, delivering increased business confidence. Engineering organizations trust Chronosphere to help them operate scalable, highly available, and resilient applications.

Learn More

The latest from Chronosphere

The 4 Basic Cloud Native Components

Before your organization implements any sort of cloud native architecture, it’s important to understand its basic components. The four pillars of cloud native are microservices, DevOps, open source standards and containers.

No. 1: Microservices are the foundation of cloud native architecture because they offer several benefits, including scalability, fault tolerance and agility. Microservices are smaller and more focused than monolithic applications, which makes them easier to develop, test and deploy. This allows teams to move faster and respond more quickly to changing business requirements and application needs. Plus, a failure in one microservice does not cause an outage of the entire application. This means that developers can replace or update individual microservices and not disrupt the entire system.

No. 2: DevOps is a set of practices that emphasize collaboration and communication between development and operations teams. Its goal is to deliver software faster and more reliably. DevOps plays a critical role in enabling continuous delivery and deployment of cloud native architecture. DevOps teams collaborate to rapidly test and integrate code changes, and focus on automating as much of the deployment process as possible. Another key aspect of DevOps in a cloud native architecture is the use of Infrastructure as Code (IaC) tools, which allow for declarative configuration of infrastructure resources. DevOps’ focus on CI/CD enables products and features to be released to market faster; improves software; ensures that secure coding practices are met and reduces cost for the organization; and improves collaboration between the development and operations teams.

No. 3: There are a variety of industrywide open source standards such as Kubernetes, Prometheus and the Open Container Initiative. These cloud native open source standards are important for several reasons:

• They help organizations avoid vendor lock-in by ensuring that applications and infrastructure are not tied to any particular cloud provider or proprietary technology.
• Open source standards promote interoperability between different cloud platforms, technologies and organizations to integrate their environments with a wide range of tools and services to meet business needs.
• Open source standards foster innovation as they allow developers and organizations to collaborate on new projects and coding advancements for cloud native architectures across the industry.
• Open source standards are developed through a community-driven process, which ensures that the needs and perspectives of a wide range of stakeholders are considered.

No. 4: Containers enable organizations to package applications into a standard format to easily deploy and run on any cloud platform. Orchestration on the other hand, is the process of managing and automating the deployment, scaling and management of containerized applications. Containers and orchestration help build and manage scalable, portable and resilient applications. This allows businesses to quickly respond to market changes, which gives them a competitive advantage so they can constantly implement value-add features and keep customer-facing services online.

Chronosphere + Cloud Native 

Cloud native practices offer significant business benefits, including faster time-to-market, greater scalability, improved resilience, reduced costs, and better application agility and flexibility. With cloud native adoption, organizations can improve their software development processes and deliver better products and services to their customers.

When migrating to a cloud native architecture, teams must have observability software to oversee system health. Observability tools provide real-time visibility into system performance that help developers to quickly identify and resolve issues, optimize system performance and design better applications for the cloud.

Built specifically for cloud native environments, Chronosphere provides a full suite of observability tools for your organization to control data cardinality and understand costs with the Chronosphere control plane, and assist engineering teams with cloud native adoption.

The post Cloud Native Basics: 4 Concepts to Know  appeared first on The New Stack.

Back in the days of on-premise compute, reducing costs meant cutting capital expenditures. But with the cloud’s pay-as-you-go model, how can companies realize efficiencies in light of the current economic climate?

“It’s really becoming an … operational expense and impacting companies greatly,” said Aparna Subramanian, director of product engineering infrastructure at Shopify, during a Friday session at KubeCon+CloudNativeConEurope 2023 conference in Amsterdam. “That’s the reason why we have this increased focus on optimizing and doing more with less is the mantra these days.”

Subramanian joined Phillip Wittrock, an Apple software engineer; Nagu Chinnakaveti Thulasiraman, engineering manager in the car infrastructure department at Zalando SE; and Todd Ekenstam, principal software engineer at Intuit for Friday session on, “Cloud Computing’s First Economic Recession? Let’s Talk Platform Efficiency.” The panel looked at three broad categories of reducing costs: Culture, operations and design.

Spectro Cloud uniquely enables organizations to manage Kubernetes in production, at scale. Our Palette management platform gives effortless control of the full Kubernetes lifecycle, across clouds, data centers, bare metal and edge environments.

Learn More

The latest from Spectro Cloud

Culture: Measure at App and Service Level to Find Costs

When it comes to reducing costs, the first step is creating a culture of measurement, said Wittrock.

“One thing I think it’s helpful to start with is start out measuring where your big wins are, where do you want to focus? What’s going to move the needle a lot, what’s going to take a long time to do, what’s maybe not going to move it as much but is very easy to get done?” Wittrock said. “Then from there, figure out who the right folks to engage with are, what are the right teams, so you can start looking forward.”

It can also be hard to figure out whose problem it is to increase efficiencies and cut costs, added Subramanian. That’s why it should be a cross-team effort with a financial practice or center of excellence component to it, she said.

“Often we run into the situation where it’s everybody’s problem, but it’s nobody’s problem,” she said. “Having the central team is really important but it’s also important to understand that it now suddenly doesn’t become only the central teams responsibility for making sure the platform is efficient. It has to be a collaboration between engineering, finance, procurement — the team that is negotiating contracts with your cloud vendor or other vendors.”

Ekenstam asked the packed audience for a show of hands to determine who knows what their cloud bill is. He then asked for a show of hands from those who know how much their individual services or applications costs. Not surprisingly, the number was smaller although not insubstantial.

“That’s, to me, the first step you need to know — what you’re spending,” Ekenstam said. “That’s the big challenge, taking that cloud costs, that big bill, and actually breaking it into individual teams, individual applications, because only then when you have that visibility will you know where you have the opportunities to improve.”

Intuit runs a developer portal where it tracks all of its different software assets, whether it’s a service or application, he said. Each has an asset ID that is propagated and tagged to all the resources required to support that service or application, he said. Then, IT aggregates all the billing data attributed based on the service or application, and it provides a number for the development teams. Those numbers also are rolled up and provided to various directors and vice presidents.

“It’s not enough to give a top-level CTO or the CEO the bill — you need to get that visibility to people who can actually make decisions and make changes to how the system operates,” Ekenstam said.

“That level of visibility is really the first starting point when we started looking into things more closely at Shopify,” Subramanian added. “We were able to see clearly from the cloud bill what are the different projects, what are the different clusters, but it’s not exactly helpful, right? Because if you have a multitenant platform, you want to know how much is App A costing and how much is App B costing.”

Identifying application cost can enable the platform team to go to the team or leader and hold them responsible for making the changes necessary to improve the efficiency, she added.

Don’t Automatically Cut Where CPU Is Idle

It may seem like the best plan of action would be to cut wherever there are idle resources, but that’s actually not a great idea because it could interrupt a workload that’s trying to complete, warned Wittrock.

“The idle resources may be an artifact of what are the capabilities of the platform you’re running on? What does it offer and maybe that slack just needs to be there for your availability,” he said.

That’s why it’s important to view the efficiency and waste for each application across a variety of stakeholders.

“Shopify is an e-commerce platform and sometimes we have to reserve and scale up all the way because there’s a big flash sale coming up and that time, you don’t want to be scaled all the way down and you don’t want your Cluster Autoscaler to be kicking in and doing all of these things,” Subramanian said. “There are times when you want to protect your reputation, and it’s not about efficiency.”

That’s where a central finance team can come into play, ensuring that the platform returns to normal load after big peak events like Christmas for Shopify, she added.

“That’s why you need that central finance team because there’s somebody looking at this every day and reaching out to the appropriate teams to take action,” she said.

Operations: Focus on Business Need

Photo by Loraine Lawson

Intuit has a number of different patterns to its workload. TurboTax is busiest during tax season, for instance, while QuickBooks is very busy during the traditional 9-to-5 work day, Ekenstam said.

“CPU, memory and compute resources is a big component of cost,” he said. “You need to really see how can you make your clusters and applications run most efficiently to minimize costs, but at the same time, provide the services that you need to.”

Shopify actually prepares for Black Friday and Cyber Monday by disabling autoscaling and scaling all the way up to projected traffic because then the goal is to protect Shopify’s reputation on those high volume days, said Subramanian.

“But at other times, we do leverage autoscaling,” she added. “We use VPA [Vertical Pod Autoscaler] to recommend what the right memory and CPU should be and we make that suggestion to the respective application team using a Slack channel.”

The application team knows the specific nature of their workload, so it’s up to them to review the recommendation and make the appropriate changes, she added.

Autoscaling is a key capability for reducing cloud costs, Ekenstam said, but it isn’t a panacea.

“If we can autoscale, not only your application, but also your cluster up and down, that’s for cost,” he said. “That’s obviously the best, but it does come with some disruption. So how can you minimize that disruption? I think a lot of it starts with making sure the apps can be disruptive.”

Design: Kill Kubernetes Pods to Best Utilize Resources

You can’t launch a pod in Kubernetes and expect that pod to live forever, Ekenstam said. At Intuit, they rotate their clusters every 25 days — a de-scheduler automatically de-schedules pods and reschedules them on another node to ensure it takes full advantage of the node resources, as well as so Intuit can update security patches and Amazon machine image (AMI) on the nodes, he explained.

“It also has a side effect of forcing all those applications to get rescheduled and trains our developers that, ‘Hey, I can’t count on these pods running forever. It’s okay that they terminate. It’s okay that they come back up,’” said Ekenstam. “By doing that, we’ve helped build this culture of understanding how Kubernetes works for the developers.”

Intuit is investigating developing a system that takes the recommendations from the vertical pod autoscaling, the historical metrics from each application, and then using that to make decisions and recommendations for both the VPA and the horizontal pod autoscaling (HPA). The system would integrate those recommendations and then apply them the pipeline using GitOps, he explained.

“If you change the resources of a pod, the change in resource will start back in your pre-pod environment, get tested, validate that it does work in pre-prod and work its way through the pipeline to your production environment,” Ekenstam said. “We don’t want to just suddenly change the resources in production without being able to test it first.”

Profiling Apps for Efficiency

Another step to reducing cloud spend is to ensure applications are cloud native and can run on Kubernetes, Ekenstam said. But he asked the panel what can be done beyond that.

It takes a partnership between the platform or infrastructure team and the applications team, said Subramanian.

“Something that Shopify has been working on recently is continuous profiling of applications because you don’t want to just tell application developers … make sure it’s efficient and optimal at all times,” said “In order to reduce the friction, we have rolled up this continuous profiling feature that every application is getting profiled continuously at a certain sample rate.”

That’s made it easy for developers to look at their app profile and make decisions about CPU usage, processes running, and so on, she added.

“Being able to create such tools and enable the application developers to make the right decision is also a key part of efficiency and optimization,” Subramanian noted.

At Intuit, whenever there is a new release of their platform, they run it through Failure Modes and Effects Analysis (FMEA) testing, which includes a load test, Ekenstam said.

“Then we measure how many nodes did it take to do that workload and that helps us identify some kind of performance regression, and performance regressions are also quite often cost regressions, because if you’re suddenly needing to use more nodes to do the same workload, it costs you more, so that’s another technique that we’ve used to identify and to compare different releases,” he said.

CNCF paid for travel and accommodations for The New Stack to attend the KubeCon+CloudNativeConEurope 2023 conference.

The post KubeCon Panel Offers Cloud Cost Cutting Advice appeared first on The New Stack.

Rafay Systems recently announced the release of Backstage Plugins. These open source software plugins for Spotify’s Backstage platform create self-service workflows for developers while providing the governance and standardization platform teams require.

The announcement was made at KubeCon + CloudNativeCon Europe. Rafay Backstage Plugins will become globally available to consumers by July 2023.

The plugins are designed to balance the seemingly opposing needs of platform teams and developers while working with frameworks such as Kubernetes and varying environments. Platform teams seek to formalize how developers provision and access their resources, while developers are concerned with quickly innovating and testing varying applications or web pages.

According to Abhinav Mishra, Senior Product Manager at Rafay, “Developer self-service for Kubernetes is a huge challenge. Developers need a cluster, or namespace, or environment, to provision and test applications and it takes too long for this process to happen. It can take organizations three months to get an app fixed in production.”

Using Backstage Plugins, however, organizations can drastically reduce the time required to create, test, and operationalize applications — while doing so in a well-governed, repeatable manner.

Tigera provides the industry’s only active security platform with full-stack observability for containers and Kubernetes. Tigera’s platform, delivered as a fully-managed SaaS or self-managed service, prevents, detects, troubleshoots, and automatically mitigates exposure risks of security breaches.

Learn More

The latest from Tigera

Tedious Manual Approaches

Backstage Plugins connects developers’ Internal Developer Platforms (IDPs) in Backstage — a widely used open platform for developer teams — to Rafay Kubernetes Operations Platform. In turn, “Backstage allows for development of IDPs atop Kubernetes,” Mishra said. The plugins enable platform engineers to create reusable templates that adhere to the governance concerns of the organization, spanning everything from cost to multitenancy and regulatory compliance.

Without this methodology, organizations are frequently slowed by lengthy back-and-forth conversations between developers and platform teams about which resources to use, how to provision them, and how to secure them. “The way a lot of companies handle this workflow is if developers need an environment or to deploy an app, they submit a ticket,” maintained Sean Wilcox, Rafay SVP of Marketing. “Those tickets sit in a sea of tickets for like, a week, and there’s several questions and opportunities for platform teams to get back to them. There’s a back and forth like a ping pong game that happens for a month.” A Rafay survey found these manual methods often delay application implementations for anywhere from one to three months.

Governance Templates

The introduction of Rafay Backstage Plugins replaces these time-consuming efforts with an alternative approach in which platform engineering teams create templates for developers. Those templates specify all aspects of the infrastructural, governance, access, and provisioning of resources that platform engineering teams require developers to follow. Backstage Plugins enable developers to consume those templates (and their corresponding resources) while using their IDPs that are connected to Backstage. The connection to Rafay Kubernetes Operations Platform enables developers to avail themselves of its bevy of capabilities for facilitating governed access to Kubernetes.

Examples of templates include those designed to support “Cluster as a Service, Namespace as a Service, or Environments as a Service,” Mishra mentioned. Platform teams benefit from this approach by specifying how developers spin up resources and provision them in a governed manner. Developers benefit by accessing those resources and environments “by just entering a name and the description of a cluster,” Mishra said. “With a one-click provision, they get a nice view of their environment, where they can download [resources] and deploy apps easily to it and reduce the cognitive load of having to learn the intricacies of Kubernetes.”

Reducing the Cognitive Load

The reduced time-to-value that Backstage Plugins supports has lasting ramifications for developers and IT teams. It enables each of them to concentrate on what they do best. For platform teams, that’s “setting up those standards and workflows and ensuring they’re done in a compliant way for regulations, or internal policies, or even costs,” Mishra commented. For developers, it’s realizing the freedom from infrastructural, access, and security concerns to spur creativity.

“Developers shouldn’t have to deal with this stuff,” Wilcox remarked. “They want to code and deploy fast. All the infrastructure stuff they shouldn’t have to be concerned with, like does this even go in a cluster or a namespace? Frankly, they should just be able to deploy while the platform team, in an automated way, figures this out for them.”

The objective is for developers to spend their time pursuing more higher-value tasks related to devising new and better solutions, instead of miring themselves in the infrastructure particulars and governance demands of doing so.

The post Rafay Backstage Plugins Simplify Kubernetes Deployments appeared first on The New Stack.

The entire cloud native world revolved around Kubernetes, but it’s not even 10 years old yet. But, while its adoption rate has skyrocketed, concerns about securing containerized workloads persist. Red Hat‘s The State of Kubernetes Security for 2023 report delves into cloud native development security risks.

Based on a global survey of 600 DevOps, engineering, and security professionals, this report uncovers common security challenges in cloud native adoption and their business impact. More than just the usual report of what people are saying and thinking, the report also covers best practices and guidance for secure application development.

Findings

But the report’s key findings are worrying:

• 38% of respondents believe security investment in containerized operations is inadequate, a 7% increase from 2022.
• 67% of respondents have had to slow down cloud native adoption due to security concerns.
• More than half of the respondents have experienced a software supply chain issue related to cloud native and containerized development in the past 12 months.

This is not good. Adoption rates continue to grow, but security investments have not kept pace.

Tigera provides the industry’s only active security platform with full-stack observability for containers and Kubernetes. Tigera’s platform, delivered as a fully-managed SaaS or self-managed service, prevents, detects, troubleshoots, and automatically mitigates exposure risks of security breaches.

Learn More

The latest from Tigera

Recommendations

So, Red Hat recommends that organizations should invest in cloud native tools with built-in security to address this gap. IT teams need to focus on selecting and implementing security tools that provide feedback and guardrails in the CI/CD application pipeline and infrastructure pipeline. In other words, you should shift left with security whenever possible.

Specifically, cloud native security solutions should include a DevSecOps approach.

With 67% of respondents delaying or slowing down application deployment due to security concerns, these issues are seriously interfering with business.

Worse still, security incidents have led to employee terminations for 21% of respondents and fines for 25%. Revenue or customer loss was reported by 37% of respondents as a result of a container and Kubernetes security incident. You can’t afford these kinds of mistakes. They cost real money and can wreck your company’s reputation.

On the flip side, by prioritizing security early in a cloud native strategy, organizations can protect business assets, meet regulatory requirements, drive business continuity, maintain customer trust, and reduce the cost of remediating security issues.

Growing Concern

In addition, users are figuring out that software supply chain security is a growing concern. Sonatype reported a 742% average annual increase in software supply chain attacks over the past three years. The top three concerns for survey respondents were vulnerable application components (32%), insufficient access controls (30%), and a lack of software bill of materials (SBOM) or provenance (29%). How bad is it? More than half of the respondents have experienced virtually every issue identified in the survey.

However, many organizations are making strides to better secure their software supply chains by adopting a comprehensive DevSecOps approach. Nearly half of the respondents already have an advanced DevSecOps initiative, and 39% are in the early stages of adoption. By focusing on software component security early in the development lifecycle and automating security integration using DevSecOps practices, organizations can transition from inconsistent manual processes to consistent, repeatable, and automated operations.

Well, that’s the hope anyway. Clearly, these security issues must be addressed. If not, then cloud native-oriented companies are going to face serious business headwinds in the days to come.

The post Kubernetes Security in 2023: Adoption Soars, Security Lags appeared first on The New Stack.