DEV Community: Napptive

The Business Value of an IDP

Napptive — Mon, 04 Sep 2023 06:52:59 +0000

Nowadays, customers expect to see their favorite applications to be refreshed frequently. As users, we can see that new features and improved functionality updates are constantly rolling in. How to keep up with the competitors’ pace and remain relevant in today’s fast-evolving world? In this article, we will break down how an Internal Developer Platform (IDP) is your best tool for drastically cutting back time to market.

Today’s market is constantly evolving with updates, avoid becoming stagnant!

Benefits of an Internal Developer Platform
An IDP is an internal product that developers use for their everyday work. It combines and integrates all the infrastructure, systems, and tools that they need to achieve maximum efficiency and productivity. As a secondary effect, it also translates into better collaboration, which adds to the goal of shipping updates faster. This is how an IDP achieves all this (and more!).

A. Efficiency and Productivity
An IDP provides a standardized, automated, and centralized ecosystem for development that will allow fast-release cycles:

Developer self-service — Developers have readily available all the tools they need to avoid halts in their workflow. With a few clicks, they have access to resources, environments, integrations, deployments, rollbacks, etc. instead of having to create tickets and wait for their resolution.
Promotion of automation culture — Save time by automating tasks such as application configuration or infrastructure management. For example, setting up a new environment is the most common requirement for fresh development, yet it takes a lot of time to manually create one. By streamlining operations, your organization makes more value of both your Dev and Ops teams’ time.
Lower cognitive load — Thanks to automation, IDPs also reduce complexity. Cloud-native applications have made managing and deploying software more complex, and not every developer is also an expert on, say, AWS, Kubernetes, or Terraform. A unified platform aids developers in building, testing, and deploying applications with ease, regardless of the underlying architecture.
In addition to this, there is something to be said about not only being more efficient but also more productive. Avoiding critical situations, easier auditing, and fast recovery are key in this sense. Internal Platforms enforce good practices and limit the chance of errors by the establishment of golden paths and role-based access control (RBAC). The platform becomes the place for centralized debugging information. All deployments are versioned. Rollbacks can be done automatically. A good portion of time devoted to failure-fixing can now be freed for adding value.

Some examples
To illustrate the advantages above, let’s recall some usual pains in software development in which an Internal Developer Platform can help:

There is a new developer in the company. If there aren’t golden paths, automated processes, or a centralized source of documentation, this person will need many hours to find out how things are done (and will likely misconfigure something).
When Development teams are ready to start testing in infrastructure, they have to ask an Operations team to provision it. They may be faced with long waits, maybe weeks, before they can continue working on this application, breaking workflows and trains of thought, and unnecessarily delaying its release.
Infrastructure and application configuration management are usually manual tasks that, in lack of an IDP, developers have to do, instead of using their time to do what they do best — develop.
As cloud computing becomes more and more prevalent, and without an IDP to reduce the complexity, organizations face the necessity to hire multi-skilled engineers who will be able to successfully handle all these new technologies — which, of course, is difficult and expensive.
B. Improved Collaboration
It seems counter-intuitive that a tool that promotes self-service will boost collaboration, but it’s true. There are a few factors that weigh in on this result. First of all, the Dev and Ops teams will have a golden opportunity to collaborate during the IDP adoption and maintenance. Developers must point out bottlenecks that Ops will work on alleviating. The Ops team in charge of the IDP should design ideal deployment pipelines and adjust them as developer necessities evolve over time.

Ideally, such pipelines include the publication of reusable components to the company’s catalog. Standardization and enforcement of good practices lead to consistency and cohesiveness in processes and the codebase. This lets developers from different teams jump into each other’s projects with minimal difficulty because they work with the same set of tools and follow the same best practices.

Cross-region collaboration is another area where an IDP shines. It empowers Development teams spread across the globe to work together seamlessly, enabling efficient knowledge sharing and fostering a culture of innovation.

Tailored to the unique needs of your business
An IDP must integrate as much as possible with the organization’s existing infrastructure and culture. The technology culture of a company comprises the stack it uses, its tools, its codebase, and the set of processes being followed. The platform needs to comply with the existing — or desired — source code management, release management strategies, security, and other major processes.

Such a platform will meet all the organization’s needs and promote the goals that the stakeholders — the company, the developer teams, the operations teams, and the final clients — have set for it. Suppose that a company already uses Crossplane to enable developers to provision infrastructure using yaml files. A customized IDP can integrate the use of Crossplane so that the organization makes use of existing know-how. Letting developers use a well-known tool, instead of making them learn to use yet another one, will help in effectively reducing the cognitive load and resistance to change.

Real-World Examples of IDPs Generating Business Value
IDPs offer a scalable solution that can accommodate the needs of organizations, regardless of their size. Let’s see how three leading tech companies have brought in an IDP in their structure to solve problems they were struggling with.

Uber
Uber’s fragmented codebase created issues that permeated library versions, build tools, and dependency management, impacting collaboration and code sharing significantly. In response, Uber decided to transition developers to a remote development environment called DevPod. By consolidating all codebases into a single repository and centralizing the build platform, it managed to attain better dependency management, consistent universal production library versions, and improved support for a standard set of tools and processes. The cherry on the cake was the boosted visibility, collaboration, and code sharing that this transformation brought about.

Adidas
Adidas noticed that routine operations were slowing down the delivery process, curbing spontaneity, and impeding the fast-paced development work that the company needed to stay competitive. So they decided to completely overhaul their approach. They used a combination of advanced methodologies and tools: containerization, agile development, continuous delivery, and the induction of a cloud-native platform encompassing Kubernetes and Prometheus. By adopting these cutting-edge technologies, Adidas was able to create an efficient, streamlined Internal Developer Platform designed to improve speed, operability, and observability.

Spotify
Spotify’s Backstage is the best well-known IDP of this set. The company infrastructure had become a labyrinth of multifaceted tech stacks, redundant tasks, and disparate documentation, each making infrastructure management increasingly complex. To simplify and streamline the software development process, they set to create a platform that would offer a consistent interface, a standardized backend, and enough flexibility to allow teams to adapt it to their unique needs. Teams found themselves with more time and resources to devote to developing new features and services, rather than wrangling with a complicated infrastructure.

Conclusion
As Navdeep Singh Gill (global CEO of Xenon Stack) puts it in a Forbes article, “IDPs help rapidly growing enterprises focus on work that provides optimal business value.” By automating routinary tasks, developers can focus on adding value to the organization, releasing faster, bringing up innovative ideas, and engaging in fruitful collaboration. Shortening time-to-market is key in today’s fast-paced world. A self-service platform prevents dependency blocks and ensures Operations-approved configuration and infrastructure management.

If you want your company to take the next step towards reaching lightning-speed release cycles, consider using Napptive. It is a robust and versatile out-of-the-box IDP that can be customized to meet your business needs. Make the choice that will empower your operations and elevate your team’s productivity to new heights. Try Napptive completely free here.

IDPs for Developers

Napptive — Mon, 28 Aug 2023 07:27:43 +0000

As software development becomes more sophisticated and teams get bigger, there is a rising need for an internal platform that would bring streamlined workflows, automation of repetitive tasks, and centralized collaboration. IDPs free developers so they can concentrate on innovation, problem-solving, and code quality. They provide a unified environment for managing development environments, integrating tools, and facilitating continuous integration and deployment. With their ability to boost productivity, efficiency, and collaboration, IDPs are increasingly recognized as essential tools for contemporary software development, driving their rising importance in today’s tech companies. But do not take our word for it. In the next sections, we will break down exactly how IDPs can help developers.

*How IDPs Empower Developers *
There are three fundamental ways in which an Internal Platform can make a developer’s life easier: streamlining processes, improving collaboration, and managing environments.

*A. Streamlined Processes *
Internal Developer Platforms integrate with tools and frameworks that automate all kinds of tasks:

Build and Deployment Automation: CI/CD pipelines to automatically build and deploy code changes to various environments, such as development, staging, and production.
Code Formatting and Style Enforcement: Linters and code analysis tools to analyze the code and provide feedback or automatically apply formatting rules. This ensures that the codebase follows a unified style to improve code readability and maintainability across the team.
Automated Testing: Test automation frameworks to write and execute tests automatically, including unit tests, integration tests, and regression tests.
Error Monitoring and Alerting: Error monitoring and logging tools to automate the detection and alerting of application errors in real-time. This improves application stability and reduces the time spent on manual error detection and troubleshooting.
Dependency Management and Updates: The platform can monitor dependencies and notify developers about available updates or security patches on libraries, frameworks, or packages. This saves time and effort while minimizing the risk of using outdated or vulnerable components.
Code Generation and Templating: Developers can define templates for commonly used code patterns or project structures. The platform can generate code based on these templates, reducing the need for developers to write boilerplate code manually.
*B. Improved Collaboration *
By providing a centralized environment and integrated communication channels, IDPs enable seamless collaboration, knowledge sharing, and improved teamwork. This is done at four levels:

Centralized Knowledge Repository: Internal developer platforms serve as a central repository for documentation, code samples, best practices, and other resources. This eliminates fragmented communication channels and ensures that everyone has access to up-to-date information.
Code Sharing and Reusability: Developers can publish their reusable components on the platform’s catalog. This reduces duplication of efforts and encourages discussions and feedback on shared code, leading to better code quality.
Collaborative Tools: IDPs often provide a suite of collaborative tools that facilitate teamwork, like version control systems, issue trackers, communication channels, etc. Developers can seamlessly collaborate on projects, track progress, communicate with each other, and even seek peer review and learn from constructive feedback.
Cross-Team Collaboration: IDPs provide visibility into other teams’ work, allowing for knowledge exchange, and fostering cooperation. Developers can share insights, seek assistance, and collaborate on shared projects more effectively, breaking down silos and promoting a culture of collaboration.
*C. Environment Management *
Environment provisioning is a burdensome task that usually implies creating a ticket and waiting. IDPs enforce environment self-service, so that developers can instantly provision new environments, even triggered by a CI/CD pipeline, with the required infrastructure, dependencies, and configurations using predefined templates or scripts. This eliminates the time-consuming manual setup process and reduces the chances of environment-related issues.

By using containers, automatically created environments can be isolated and closely mimic the production one. Developers can package their applications, along with all the necessary dependencies, into containers to be deployed across different environments, such as staging, testing, or production, ensuring consistent behavior and reducing compatibility issues. Even in the case that the environment gets altered and is no longer in a healthy state, developers can just reload an IT-approved container image and continue working.

Additionally, IDPs often include monitoring and debugging tools to check the performance of their applications in different environments. They provide insights into resource usage, logs, and metrics, allowing developers to identify and debug issues efficiently.

Getting Started with an IDP
If you are in the search for an IDP for your team, you should pay attention to the following features:

Ease of use: Does it have a user-friendly interface and intuitive workflows? Does the platform provide a seamless experience?
Centralized collaboration: Does it offer a centralized collaboration environment? Look for the existence of any integrated communication channel, such as chat, forums, or notifications.
Integrated development tools: Does it integrate with a wide range of development tools? Can you integrate the CI/CD pipelines, version control system, issue tracker… that you currently use?
Scalability and customizability: Is the platform able to scale with the needs of growing development teams and organizations? Does it provide flexibility and customizability?
Security and compliance: Does the IDP incorporate robust security measures? Does it adhere to industry security standards and regulations?
Support and documentation: What kind of resources does the platform offer to assist developers? Can you ask for support?
With these questions in mind, we are proud to present Napptive as the IDP that will help you boost your development. It is a Kubernetes developer platform that will let your team accelerate the deployment of cloud-native applications without needing deep infrastructure know-how . Its main features are:

Accelerated project deployment
Transitioning from local development to a production environment or sharing your work can be complex. With Napptive, you can deploy your projects autonomously and effortlessly without sacrificing control or limiting extensibility.

Reduced complexity
Deploy your code directly in the cloud without worrying about the provider or the automation process. Napptive is built on open-source technologies, eliminating vendor lock-in. It integrates with Golang, Python, NodeJS, Docker, Helm, GitHub, AWS, Azure, Google Cloud, GKE, RKE2, bare metal and more.

Integrated collaboration
Napptive’s growing catalog of commonly used applications lets you implement technologies you’re already comfortable with. It offers the same experience you get for single containers but for complete applications, with the ability to create and share your ready-to-deploy apps without complex configuration processes.

Secure, user-friendly platform
Napptive makes deploying complex applications on Kubernetes easier and faster. Using KubeVela, it manages the technical details so you don’t need extensive Kubernetes knowledge. You can interact with clusters conveniently, create different environments easily, and trust that your applications are securely managed.

Fully Extensible
Leverage advanced tools and extensions to radically accelerate the process of creating applications, covering essential requirements such as app-centric monitoring, unified logging, managed secure endpoints, and many more!

Conclusion
Internal Developer Platforms aid developers by streamlining workflows, ensuring environment self-service, and facilitating collaboration. This way, they can focus on problem-solving, improving code quality and coming up with innovative ideas. If you want to boost productivity, efficiency, and collaboration in your team, consider using Napptive. You can try it for free here.

Uber's DevPod - A Case Study

Napptive — Mon, 17 Jul 2023 10:24:38 +0000

One of the most common issues companies often grapple with is that of having complex codebase fragmentation. Uber, in 2017, was no exception. Their fragmented codebase created issues that permeated library versions, build tools, and dependency management, impacting collaboration and code sharing significantly. In response, Uber took a bold step - transitioning developers to a remote development environment anchored on Monorepos run on a Kubernetes cluster.

DevPod: Uber's Remote Development Environment

The decision to migrate to a Monorepo architecture wasn't a small one. It was a strategic choice recommended by Uber's build-strategy team to consolidate Uber's sprawling codebase, which, at the time, spanned over 10 programming languages, 4,000+ services, 500+ web apps, and nine build tools. These were distributed across thousands of repositories, each with its trunk-based development and unique version per third-party library.
In an effort to combat these issues, Uber launched its proprietary remote development environment, DevPods, which run on Kubernetes clusters. With zero setup required, DevPods run in the cloud instead of on developers' laptops, leading to significant improvements in build times. As of November 2022, over 60% of Uber engineers have embraced this new development environment.
By consolidating all codebases into a single Monorepo and centralizing the build platform based on Google's Bazel, Uber managed to attain better dependency management, consistent universal production library versions, and improved support for a standard set of tools and processes. The cherry on the cake was the boosted visibility, collaboration, and code sharing that this transformation brought about.
However, it wasn't all smooth sailing. The transition to the new code edit-build-run development loop introduced its own set of challenges. The process became lengthier with cloning, in some cases, taking up hours.

A Tailor-made Solution

Uber's DevPods were designed to provide a superior developer experience, allowing engineers to leverage faster machines in a secure, controlled cloud environment. Each DevPod is a custom-fitted container running on a Kubernetes cluster, designed with the necessary tools and resources for seamless development on Uber's monorepo.
These cloud-based DevPods boast enhanced performance, near-zero setup time, and advanced security, running the latest stable versions of each dependency. What's more, DevPods are persistent, ensuring that engineers won't lose their setups, files, or code changes while working on different devices or collaborating with others.
The advantages of using DevPods include zero setup and maintenance, top-notch security, and a commitment to low latency. With DevPods, Uber developers can hit the ground running on any of the main monorepos, as tools are ready-to-use, environments are provisioned on-demand, and repositories are pre-cloned.

User Experience: An Intuitive Approach

Uber engineers are presented with a "flavor" - a Docker image preset with tools, default settings, and configurations for specific groups. This approach, Uber engineers believe, "made perfect sense." It allows them to base the DevPod image on the production image base, enabling the re-use of their critical production software configuration.
Moreover, Uber introduced a web-based interface for a smoother first-time experience with DevPods and improved troubleshooting, with plans to extend Devpod Central for visibility into resource usage and consumption.

Harnessing the Power of Kubernetes

The transition from laptops to cloud computing was just the beginning. Kubernetes served as a foundation, offering a host for containers on powerful hardware, networking for container connectivity, and persistent volumes for storing engineering work between restarts.
Uber used custom resource definitions (CRDs) to extend Kubernetes by providing a data structure stored inside the control plate, eliminating the need for an internal database for Devpod metadata. This also facilitated the creation of and access to Devpods using kubectl.

The road ahead

DevPods have demonstrated their effectiveness in reducing local Git command performance, improving build times by up to 2.5 times over laptops for complex builds. This innovation has been welcomed by the Uber developer community, with over 60% of Uber software engineers adopting DevPods as of November 2022.
As Uber continues to refine its developer ecosystem, the future focus is on making DevPods even more seamless for engineers. Some areas of exploration include reducing the time to set up DevPods, creating ephemeral DevPods, and facilitating seamless file transfers between laptops and DevPods.
Uber's DevPod stands as a testament to the power of innovation, bridging the gap between the complexities of development and the need for efficiency and speed. As we move forward, the question is no longer about surviving the challenges but about harnessing them for continuous improvement, much like what Uber has done with its DevPod platform.

In conclusion, the groundbreaking shift pioneered by Uber through DevPods presents a formidable model for remote development environments, which, although impressive, might not be feasible for every organization to adopt. This strategy requires a significant commitment of resources, time, and technical prowess, elements that may not be readily available or viable for all companies.
Undertaking such an extensive shift could be a daunting prospect for organizations, particularly those lacking wide in-house expertise and resources that can spend years in making such a tool. This is where Napptive's Internal Developer Platform (IDP) comes into the fold, offering a comprehensive, ready-to-use solution that meets the needs of companies who look for a fully featured IDP that empowers teams without the need for intensive, time-consuming overhauls. This streamlined, out-of-the-box solution is precisely what businesses require to stay competitive in today's rapidly evolving technological landscape, bridging the gap between present capabilities and future needs effortlessly. Try Napptive, for free now!

Adidas Developer Portal – Case Study

Napptive — Mon, 10 Jul 2023 08:29:19 +0000

For any company that deals with technology, the real deal lies in swiftly accessing and employing its resources to solve real-time problems and deliver cutting-edge solutions. One such transformative journey of redefining the accessibility and usability of software tools was undertaken by the global sportswear giant, Adidas, who took it upon themselves to build their own Internal Developer Platform.

Identifying the Bottleneck: The Initial Challenge
Adidas, much like any tech-forward company, equipped its teams with an array of sophisticated software tools. However, the tech teams faced a significant hurdle in their routine operations. The procurement of a developer Virtual Machine (VM), a fundamental asset in a tech-based project lifecycle, was far from efficient.

The process to acquire a VM was mired in a bureaucratic web, involving a sequence of steps including submitting a request form, providing a detailed purpose, defining the title of the project, identifying responsibility, and communicating with the internal cost center. The outcome? A significant waiting period ranging from 30 minutes to a staggering week-long delay before the VM was ready for use.

Such a drawn-out procedure was proving counter-productive, slowing down the process, curbing spontaneity, and impeding the fast-paced development work that the company needed to stay competitive.

A Developer-Centric Solution
Recognizing the gravity of the problem, Adidas decided to overhaul its approach. Instead of focusing on top-down bureaucratic procedures, they chose to view the issue through the lens of the developers who grappled with these challenges daily. The objective was clear — to devise ways that could significantly shorten the time taken to kickstart a project and efficiently integrate it into the Adidas infrastructure.

The breakthrough was realized in the form of a combination of advanced methodologies and tools: containerization, agile development, continuous delivery, and the induction of a cloud-native platform encompassing Kubernetes and Prometheus. By adopting these cutting-edge technologies, Adidas was able to create an efficient, streamlined Internal Developer Platform designed to improve speed, operability, and observability.

In 2017, Adidas joined hands with Giant Swarm, a prominent consulting firm specializing in Kubernetes management. (You can read their interview with our CEO here) This strategic collaboration assisted Adidas in installing, configuring, and managing all Kubernetes clusters across their AWS and on-premise platforms. The decision underscored the belief that Adidas’s competitive edge did not lie in managing a Kubernetes cluster, but rather in equipping their engineers to build top-of-the-line, speedy, resilient, and high-functioning e-commerce stores.

Feeling the Impact: Remarkable Outcomes
The transformation brought about by the integration of the new Internal Developer Platform was swift and striking. Just six months into the project, the entire Adidas e-commerce site transitioned to Kubernetes. The site’s load time was slashed by half, and the frequency of releases skyrocketed from once every 4–6 weeks to a staggering 3–4 times daily.

Moreover, Adidas began managing 40% of its most critical systems on its cloud-native platform. It handled an impressive array of 4,000 pods, 200 nodes, and 80,000 builds per month, marking a monumental shift in the company’s technological landscape.

Embracing the Change
The revamped Internal Developer Platform didn’t just transform the technological framework but also marked a cultural shift within the company. The developers, an integral part of Adidas’s 300-strong engineering division, welcomed the new system with open arms.

As part of the onboarding process, each team member spent a full week gaining hands-on experience with the platform, which contributed to its widespread acceptance and use. The hands-on approach gave the developers a sense of familiarity, control, and confidence while dealing with the new platform

Conclusion
While the transformation Adidas underwent is commendable, it is essential to recognize that such a comprehensive, resource-intensive shift might be too overwhelming for most companies. The approach adopted by Adidas, although effective, required significant investments of time, effort, and resources. It also necessitated an organization-wide commitment to changing existing systems and cultural mindsets. For many businesses, the lengthy overhaul could be a challenging prospect, especially for those seeking ‘out-of-the-box’ solutions that deliver immediate results with minimal disruption to existing workflows.

This is where Nappitive becomes a game-changer. Nappitive offers an accessible, user-friendly platform that empowers organizations with immediate access to key tools and technologies without the need for a complex, company-wide transformation. The solution offered by Nappitive is designed to bridge the gap between the existing setup and the desired future state, allowing companies to streamline their processes without the associated teething pains of a complete overhaul. This agile and adaptable approach is exactly what companies need to stay competitive in today’s rapidly evolving tech landscape. Try Napptive, for free now!

Spotify’s Backstage – A Case Study

Napptive — Tue, 04 Jul 2023 12:30:54 +0000

The Birth of Backstage: A Case Study of Spotify’s Developer Platform

In the fast-paced world of software development, managing an intricate network of services and teams can be a daunting task. Spotify, constructed on a microservices architecture and home to numerous autonomous teams, found itself grappling with these complexities. In response, Spotify required an Internal Developer Platform (IDP). An IDP is designed to standardize developer workflows, abstracting away the complexities of the underlying infrastructure and enabling developers to focus more on coding and less on configuring and managing their environments. The value of an IDP lies in its ability to accelerate the software development lifecycle and improve productivity by providing a self-service interface where developers can create, manage, and deploy their applications. Spotify aimed to resolve these challenges with a solution called Backstage. Let’s explore the journey of Spotify’s creation of Backstage and its far-reaching implications.

The Problem
Spotify’s astronomical growth rapidly transformed it into a sprawling ecosystem of services. Housing hundreds of autonomous teams each working on an array of software components, Spotify soon faced the daunting reality of a fragmented and convoluted developer experience. Its infrastructure became a labyrinth of multifaceted tech stacks, redundant tasks, and disparate documentation, each making infrastructure management increasingly complex.

This intricacy led to inefficiencies, slowing down the development process and eating into productivity. Spotify recognized these challenges and realized the pressing need for a more cohesive, user-friendly system. A system that could streamline developer operations, enhance productivity, and enable the continuous delivery of high-quality software.

The Solution: An Internal Developer Platform (IDP)
In an innovative response to these challenges, Spotify conceived and constructed its IDP, designed with a singular aim: to simplify and streamline the software development process. The objective was to build a familiar, intuitive interface that developers could use to interact with, manage, and maintain their software, just as easily as they would with any web application.

The design of the platform was based on three core principles. First, a unified front end, offering a single, consistent interface for all infrastructural tools. Second, a standardized backend, reduces complexity and fosters consistency. Lastly, a flexible platform for developing custom plugins, allowing teams to adapt the platform to their unique needs.

The Execution: Backstage
The launch of Backstage heralded a new era in Spotify’s software development journey. It provided a standardized, user-friendly UI and a navigable catalog of all software components, significantly reducing the complexity of managing services. The previously convoluted developer experience was now simplified, more efficient, and more pleasant.

A key feature of Backstage is its flexible plugin architecture. This feature allows teams to create custom plugins that represent the various infrastructure tools with which developers interact. This has resulted in a unified, user-friendly interface that simplifies and enhances the development process.

Its Impact on Spotify
The introduction of IDP transformed the developer experience at Spotify. It provided a platform for a higher degree of standardization, consistency, and ease of use across a myriad of tools and services.

Teams found themselves with more time and resources to devote to developing new features and services, rather than wrangling with a complicated infrastructure. The plugin architecture of Backstage also reduced redundancy, as it encouraged the reusability of solutions.

Understanding the potential of Backstage IDP, Spotify took the decision to open-source the platform in March 2020. This move has allowed other companies to benefit from the unified, streamlined developer experience that Backstage offers.

Backstage stands as a testament to Spotify’s proactive and innovative approach to problem-solving. It transformed a complex network of operations into a streamlined, cohesive system. Backstage offers valuable lessons for other companies navigating similar challenges and has the potential to become a vital tool in the world of software development.

Backstage as a production-ready IDP
Rather than conceptualizing Backstage as a ready-to-use product, it’s more apt to perceive it as a versatile framework. Its installation alone does not unlock its full potential — it requires the backstage managing team to curate its setup in a way that addresses users’ needs. Backstage thrives on its powerful plugin system, each tailored to resolve developers’ challenges. Therefore, we can consider it to be the scaffolding of what an Internal Developer Platform should be.

Backstage may not be the go-to solution for every organization. It does shine in visualizing and implementing self-service layers, courtesy of its intuitive plugin system. Still, crafting the Developer Portal that precisely caters to your developers’ unique needs might demand significant amounts of coding. If your DevOps engineers lack the necessary proficiency and experience in fast UI component development, you could end up facing tedious challenges.

The development of such a multifaceted product necessitates a seasoned team to steer its course. To use Backstage successfully, your organization would need to boast a dedicated ensemble of DevOps Engineers, Senior Full-Stack Engineers, and a Product Owner, then it would make Backstage a good choice as an IDP.

If you don’t want to let the complexities of application development slow down your innovation, take the leap with Napptive today and discover the power of a fully-featured, production-ready Internal Developer Platform (IDP). With Napptive, you can streamline your workflows, simplify your cloud-native deployments, and foster seamless collaboration within your team. Try Napptive, for free now!

Cloud Native Hackathon

Napptive — Mon, 03 Apr 2023 11:03:30 +0000

We are super excited to present our first-ever Hackathon in collaboration with WeMakeDevs, a community focused on providing free hands-on training in various fields of computer science with a learn-by-doing approach.

If you want to learn new skills, discover how to build and deploy cloud-native apps and meet like-minded people, you will find this and much more by participating in our hackathon!

This is your chance to collaborate with other talented developers and work together to build something amazing. You will have access to a cutting-edge platform, based on the most advanced cloud-native technology and get the opportunity to learn from experts and gain valuable experience working on real applications.

The WeMakeDevs <> Napptive Hackathon is the right place for you if you are a passionate, hands-on developer. This will help you push yourself to new heights and learn along the way. All you need is the drive to just get started!

Join the Hackathon by registering here.
Participants must create a Napptive account.
Your project must be deployable and uploaded to the Napptive platform.
Delivered materials must be in an open-source compatible license

PRIZES
$1,200 in prizes

Best migration of an open-source application to the Open Application Model

Using this guide choose an open source app of your choice (e.g MySQL), and using the OAM standard, make it deployable on the Napptive Platform.

– Mechanical keyboards for all team members
– 1:1 career mentorship and growth support by Kunal
– Swag to all team members
– Shoutout on socials + interviews

Best application extensions

Use the trait documentation and get super creative customizing applications making them more extensible

– Mechanical keyboards for all team members
– 1:1 career mentorship and growth support by Kunal
– Swag to all team members
– Shoutout on socials + interviews

We look forward to your participation, happy coding!

KubeVela Joins CNCF Incubator

Napptive — Mon, 13 Mar 2023 09:08:35 +0000

Great news! KubeVela has been accepted as a CNCF incubation project, which means our favorite application delivery platform (it was already included in our Top 10 Kubernetes resources list) is more popular than ever. But what exactly is KubeVela?

What is KubeVela?

KubeVela is an open-source CNCF project that simplifies application delivery in Kubernetes environments providing support for multi-tenancy, multi-cluster, and multi-cloud scenarios.

Kubernetes’ versatility, as any cloud software engineer will tell you, comes with a price. Managing low-level entities such as Services, Deployments, Pods, etc., requires a global understanding of the entities, their relationships, and their overall impact on the cluster and the deployed applications. To address this issue, the Open Application Model specification was born aimed to provide a simpler method to describe today’s cloud-native applications.

By abstracting away the low-level details and introducing a first-level Application entity in Kubernetes, we can simplify how we deploy, manage and operate enterprise applications in Kubernetes. KubeVela provides an Open Application Model runtime for Kubernetes introducing new high-level entities such as Applications, Componentes, Traits, and Policies among others in Kubernetes. This abstracts away complicated Kubernetes artifacts from developers, and at the same time, provides a framework for platform builders to create user-friendly and extensive platforms with development teams in mind. For more information on this topic, check the OAM spec.

KubeVela is designed to work as a Control Plane System to enable simple yet robust app delivery across hybrid, multi-cloud environments. Its main features are:

It is extensible: KubeVela abstraction layers allow you to easily extend the Open Application Model to tailor the application building blocks to your specific use case. Moreover, a collection of add-ons is available to easily integrate with existing tools in the Kubernetes ecosystem such as Prometheus, Grafana, ArgoCD, etc.
It is app-centric. KubeVela doesn’t lose focus on what’s important, and thus there is a whole ecosystem around the apps with extra capabilities to enhance their delivery and management.
It is infrastructure agnostic. The OAM specification makes applications provider agnostic so you will not need to write a specific version of the application depending on the target Kubernetes distribution. The implementation of the different traits, components, policies, and workflows is responsible for adapting the Kubernetes entities to the underlying provider if required.

KubeVela’s potent infrastructure is also able to connect with many Continuous Integration and Development (CI/CD) tools, like Jenkins, GitLab CI, or CircleCI: you can reuse the CI process you already adopted, and KubeVela will take over the CD process by empowering it with modern application delivery best practices.

How does KubeVela work?

Separation of concerns
One of the keys to KubeVela’s success is its design accommodating different user roles involved in the development process including developers and the platform team. The platform team is able to create new capabilities in the form of custom components, traits, policies, and/or workflow definitions. This combined with existing addons that enable the integration with other Kubernetes tools enables the creation of custom systems tailored to the specific needs of the team. Developers can then focus on using all the available components to simplify their day-to-day operations.

This separation helps the Dev Team follow an application-centric approach in a cloud environment without the need to dedicate a chunk of their working time to learning Kubernetes.

It also makes things easier for the Platform Team. We’ve already talked about platform engineering and the importance of making your dev team’s life easier with an internal development platform, and KubeVela can be a very valuable asset in this area since platform engineers can provide reusable capability templates and enforce best practices (by creating golden paths where the right thing to do is also the easiest).

Key features
KubeVela’s adaptability is supported by 4 main pillars:

Deployment as Code, with the deployment workflow powered by OAM. Devs can declare their deployment plan as a workflow and run it automatically, and after that, they can extend or modify it as they see fit.
Built-in security, compliance, and observability building blocks. There is a wide range of integrations already available, that developers can use as-is or customize for their specific needs.
Native support of multi-cloud/hybrid-environments app delivery, taking into account realistic scenarios.
Lightweight but highly extensible architecture, that can be tailored to each specific organization by adding and orchestrating many different infrastructure capabilities. App Management KubeVela not only supports the dev team until deployment but also after that. There are specific capabilities for application management after deployment, such as:

Resource management: The developer establishes the desired application state in the application as well as the workflow required to achieve it. The KubeVela core monitors the state of the application and it is able to reconcile the associated Kubernetes entities when the current and desired state drifts. Also, the garbage collector recycles resources that are no longer necessary.
Version control, to provide a fast recovery in case of a faulty new version.
Observability. The Vela CLI provides in-time status info for the application at a fine-grain or aggregated level, and the VelaUX addon is the Web UI version.

Napptive & KubeVela: a match made in the cloud

Putting the focus on the Applications is something that also defines Napptive since its conception. The only way of taming Kubernetes’ wild potential is to create a tool that lets you ease into it, a safety net that allows you to fail without catastrophic consequences.

The Napptive Playground uses KubeVela as the OAM runtime for Kubernetes deployments. One of the features that differentiate Napptive from other KubeVela adopters is the fact that our Playground provides an environment abstraction with multi-tenant guarantees, which means that the user can easily create different isolated environments to work in, and it also offers unparalleled transparency for its configuration, thanks to a higher abstraction level that does not involve any Kubernetes knowledge.

In the Playground, KubeVela manages the low-level application lifecycle, creating the appropriate Kubernetes entities after the application is deployed. The multi-tenant adaptation in Napptive is integrated with Kubernetes RBAC and offers a native user management layer, which allows KubeVela to capture the user identity of those who deploy an OAM application and ensure that each user can only access their allowed resources. Daniel Higuero, Napptive’s CTO, explains this process more in this article in KubeVela’s blog.

From passive members of the community to active contributors, especially in the field of the multitenant, RBAC compliance installation of KubeVela, Napptive’s love story with KubeVela has evolved over time. The Napptive Playground is the perfect entry to the Open Application Model paradigm, since there is no need to modify or expand your current infrastructure, and KubeVela fits perfectly in it. We’re also very excited about the new functionalities of KubeVela, like multi-cluster support, and already working on how we could adopt them. We don’t know what the future will bring, but it looks promising, and we’re thrilled to find out.

In case you have not yet tried Napptive, we encourage you to sign up for free and discover how we are helping propel the development of cloud-native apps.
Original article can be found here

Kubernetes for Data Science

Napptive — Tue, 28 Feb 2023 08:02:50 +0000

Are you a data scientist? If so, are you tired of devoting precious time to tasks that have nothing to do with models? Are you overwhelmed by the complexity of moving your models to the production environment? If your answer is a resounding YES, we’ve got your back! In this article, we explain how to leverage Kubernetes for data scientists plus a really easy way to use Kubernetes in data science projects – without having to waste any more time learning and configuring tools unrelated to data models or machine learning.

Kubernetes for data scientists

Data science projects (very much like most projects) face two distinct stages: development and production. In this particular case, as Chip Huyen pointed out in a very enlightening article, the differences remain mainly in the scale and the statefulness. During development, you usually have one instance that can keep running forever. When moving the project to production, you need to provide a mechanism for autoscaling, as well as a way to persist data and state across dynamically changing instances.

You may have heard – or even experienced – that Kubernetes can help both with scaling up and down, and with providing ways for the instances to communicate and store data/state… if its complexity wasn’t such a barrier. But don’t despair. Let’s see all the reasons why Kubernetes is the way to go, and how you can avoid all the excruciating configuration it requires.

Benefits of Kubernetes for data science

Kubernetes (aka K8s) is an orchestration tool. This means that it’s able to create and destroy instances of an application according to demand over a cluster of machines. In fact, what it runs aren’t exactly instances, but containers. A container is a running instance of an application, together with its dependencies and configuration, packaged and isolated from other applications running on the same machine. The beauty of using containers is that you can wrap your development environment and send it to production as is. You don’t need to rewrite your code to a different language, and you can keep using the same dependencies.

In addition, given that the environment is preserved between different people and points in time, experiments are reproducible, which is key to data science. Due to the isolation between containers, you can use different versions of the same tool for different steps in your pipeline, just by breaking up the app into several microservices. This simplifies the development environment because you’re not restricted by a dependency’s version for other uses.

These microservices can be automatically scheduled to the best-fitting devices. Kubernetes gives you infrastructure abstraction because it’s able to manage the underlying infrastructure. It can also spin up new instances when heavy computational loads occur and then shut them down when they are no longer needed. Both features lead to the efficient use of resources and make a data scientist happy.

What’s more, you could even get access to cutting-edge equipment at a low cost if you choose to run your models on a public cloud. Investing in private machines is costly because they get outdated over time and are expensive to maintain. K8s has become the de facto standard of the cloud, and so all cloud vendors offer Kubernetes support. You could choose the best fit for you and even have some cloud flexibility, as it would be relatively easy to change vendors or make use of multi or hybrid cloud environments.

Of course, it’s not all a bed of roses. The main drawback to using such a powerful tool is, obviously, its complexity. Full-stack data scientists are well aware of this and have surely spent many hours tweaking YAML files. But, we’ve got something in store that really simplifies the use of Kubernetes, and it’s called Napptive.

How to use Kubernetes in data science projects

Napptive is a cloud computing platform that abstracts an underlying Kubernetes, so that you don’t have to spend much time configuring your workloads. You can still access some Kubernetes configuration in case you need it, but its main purpose is to let you start running your apps in no time. We’ll show you how by launching R Studio from the tool’s catalog.

First, you need to login into Napptive at https://playground.napptive.dev. If you don’t have an account yet, you can easily log in for free with your email or your GitHub or Google account.

Once you’re in, you have to click the catalog icon.

Search for R, you’ll find it as rstudio.

When you click the card, it will open a box with more information about the app image. Click “Deploy”.

It will ask in which environment you want to deploy the app. If you’re using the free account, you have just one, so click “Deploy” again. Then, “yes, deploy” to confirm.

After that, you can close the catalog to restore the playground view

You’ll see rstudio status as a colored box. It’ll be yellow for a while.

Once it’s ready, the box will become green.

You can click on the box to see more information about the application. There you’ll find the path and a button to access the endpoint and open the app.
And that’s it! In this demonstration, we’ve used an existing app from the catalog, but you can certainly create and upload your own applications to Napptive. You can refer to the documentation to learn how.

If you want to propel your development, why not try our playground? It’s free, simply sign up and get started!

Cloud App Developers February Meetup

Napptive — Mon, 13 Feb 2023 16:21:10 +0000

Towards the end of 2022, we decided one of the best ways to give back to the cloud native community was to sponsor the recently created Cloud App Developers community.

As per their manifesto, Cloud App Developers is “a community for enthusiasts of cloud-native technologies, where we will share knowledge, and support developers in their professional growth. Our mission is to create a community where we can share best practices related to the development of cloud-native applications and technologies, via meetups, webinars, and posts where you will find relevant information for your development.”

With this in mind, these three tenets guide the communities’ principles:

Open: We want everyone to participate. We encourage members and their colleagues to send us talks or blog contributions. We will help disseminate and amplify your stories!
Focused on developers: We are a developer community, by developers, for developers, and vendor-neutral. This is a place to learn and share best practices and knowledge.
Cloud-oriented: Whether it’s Azure, AWS, or Google… we don’t care. We are united in our love for all things cloud!

Cloud App Developers February Meetup

This month, they host their 3rd meetup and at the time of writing over 430 people have already registered!

On February 15th at 18:30 CET make sure to sign up and watch Abdelfettah Sghiouar from Google present how to “Secure your software supply chain from dependencies to deployment”, and Alessandro Vozza from solo.io, who will talk about “The Future of Service Mesh: Sidecarless, eBPF or both?”.

Abdelfettah Sghiouar, Senior Cloud Developer Advocate at @Google

“Secure your software supply chain from dependencies to deployment”

No matter where you are on your software supply chain security journey, one thing is clear. Security is everyone’s responsibility and it starts from the development environment all the way to the runtime. In this session, you will learn how Google Cloud thinks about end-to-end secure software delivery. We will see what products and features exist on Google Cloud to be able to track, secure, and deliver your software in an automated way. We will cover multiple products with a focus on containers and automation.

Abdellfetah Sghiouar is a Google Cloud Engineer based out of Stockholm, Sweden. Working on everything Serverless, Kubernetes, Service Mesh, and containers with a background in Infrastructure and Security. You can follow him on twitter.com/boredabdel for random tweets about technology and other stuff.

Alessandro Vozza DevRel @solo.io

“The Future of Service Mesh: Sidecarless, eBPF, or both?”

Every service mesh, including Istio, uses a sidecar proxy as its data plane. With this pattern, a mesh can intercept and enhance the capability of networking communication on behalf of an application. However, this sidecar deployment pattern comes with challenges, including operational cost and complexity. With the advent of eBPF in modern kernels and some coordination with the Linux networking capabilities, we can remove the need for a sidecar and adopt a transparent approach. In this talk, we dive into the future of Istio to show how Istio can run in an ambient mode while maintaining the features of Istio running in a standard method. Benefits: The top concerns we address with sidecar-less mode are simplified operational and management overhead, broader application compatibility, reduced infrastructure costs, and improved performance.

Community leader and CNCF ambassador, Alessandro has spent the last few years building cloud-native infrastructures for Microsoft customers, animating the Dutch community, and training others to pass the CKx exams. He has a passion for all things cloud native, he’s been around open source for 25 years and recently moved to a new Developer Relations role. Twitter handle:

Bongo

Do you want to contribute to the community?

Join their Substack and have all the info sent straight into your inbox, keeping you up to date with events, articles, tutorials…
Follow them on Twitter, Youtube, and Linkedin.
Join the conversations on Discord.

We encourage you to expand the knowledge and tools that shape cloud-native technologies by sending your ideas and contributing to the community by writing to hello@cloudappdevs.org.

Platform Engineering enters the Hype Cycle

Napptive — Mon, 06 Feb 2023 15:23:42 +0000

Platform engineering officially entered the Gartner Hype Cycle for Emerging Technologies in 2022, consolidating it as the improvement for developer teams we already know it is. But what is the Gartner Hype Cycle, and how does it affect the evolution of a given technology?

The Gartner Hype Cycle

Every year, Gartner, the technological research and consulting firm, releases the Gartner Hype Cycle. It provides a graphic representation of the evolution of visibility, maturity, and adoption of specific technologies. It combines the typical progression of emerging technology (from overenthusiasm to disappointment because of unrealistic expectations, to understanding) with its natural maturity curve.

Taking the community response into account makes this a very powerful tool to discern where technology really is, in terms of stability and mainstream adoption. Businesses can use the hype cycle to guide technology decisions in accordance with their level of comfort with risk since each phase of the cycle has its own risks and opportunities.

How does it work?

The hype cycle consists of five phases:

Technology (or Innovation) Trigger. The technology is conceptualized: it may be a product, a concept, or an idea that attracts media attention and, because of it, is considered a breakthrough. Early adopters are interested in the technology but usually can’t access it because it is only available to a restricted set of users (research labs and startups).
Peak of Inflated Expectations. Everyone is talking about technology. It’s used as a buzzword and it generates a lot of interest from vendors. Here is when early adopters can actually adopt it. There are a lot of reviews of promising experiences, and also of catastrophic ones, which begin to appear.
Trough of Disillusionment. When the technology doesn’t fulfill the impossible standards imposed by the public, disappointment arrives. Some producers drop their products due to the flaws they now see in the technology. The technology evolves into its next generation with only a small percentage (up to 5%) of the audience adopting it.
Slope of Enlightenment. The technology is familiar to more people, and it’s more mature now. Without the expectation of transforming the world overnight, companies implement or test it in their environments. Second and third generations of innovation emerge, presenting proven solutions to specific problems and industrial use cases. As a result, adoption rises closer to 20% of the audience as the technology reaches its next maturity phase. The perceived value is now closer to reality.
Plateau of Productivity. Mainstream adoption (30% or more of the audience): the technology is now more reliable and understood. It becomes widely implemented and has a growing community around it.

Different technologies have different timing, and the Hype Cycle takes that into account, specifying how long it will take (according to Garter’s research) to reach the Plateau of Productivity for each of them. Some progress faster than others, and some disappear completely in the process (depending on what was the perceived value at the beginning, whether they live up to that expectation, and whether the industry is in a position to assume risk).

Platform Engineering enters the Hype Cycle

Platform Engineering (defined by Gartner as “the discipline of building and operating self-service internal developer platforms (IDPs) for software delivery and life cycle management”) appears on the Gartner Hype Cycle for Emerging Technologies, published on 25 July 2022, as well as on the Gartner Hype Cycle for Software Engineering, published on 1 of August 2022.

It is well established in the Innovation Trigger phase and with an expectancy of reaching the Plateau of Productivity in 2 to 5 years. We can also see some familiar technologies in the graph, like cloud-native architecture, well into its way to the Plateau of Productivity, and microservices, finally reaching the end of the Trough of Disillusionment.

Platform Engineering was introduced as a solution to improve the developer experience, reducing employee frustration and attrition. We discuss the term and what it encompasses in this article, where we talk about putting the focus on the developer for this technology. Gartner agrees, and acknowledges the importance of taking care of the dev team in its report “A Software Engineering Leader’s Guide to Improving Developer Experience”, which underlines that an Internal Developer Platform, while essential, is not enough:

“Internal developer portals serve as the interface through which developers can discover and access internal developer platform capabilities.”

An IDP built by a platform team, following a Platform as a Product approach, will be tailored to the needs of your dev team. Also, a dedicated developer portal, with service catalog capabilities that your team can use to access said IDP, will help them solve the underlying workflow and configuration issues affecting their experience. We dive deeper into the benefits of an Internal Developer Platform in this article, highlighting how crucial it is to create one with your dev team’s input.

The goal of Platform Engineering is to make life easier for developers, reducing cognitive load, developer toil, and repetitive manual work. To know the specific issues in your team, you need to listen to them. That is the only way to create an environment where they can thrive.

Kubernetes Cheat Sheet

Napptive — Mon, 30 Jan 2023 14:52:32 +0000

Stop scrolling search results! We bring you the ultimate Kubernetes cheat sheet so that you have all the basic info in one useful resource. Especially convenient if Kubernetes is new to you, keep it at hand and avoid having to google every single Kubernetes command you need.

Kubernetes shortcuts

In this article, we will cover basic concepts, the most common Kubernetes commands for deploying and debugging your applications, and a few tips and tricks to help you out. We are certain some special commands in the list will save you time and effort. You will find that the CLI is a truly powerful tool when dealing with cloud-native applications deployed in Kubernetes.

Kubernetes commands

First of all, let us state that you will communicate with Kubernetes via Kubectl. This CLI uses the exposed API that the master plane offers to access your cluster. The syntax of the kubectl command is as follows:

kubectl [command] [TYPE] [NAME] [flags]

The command specifies the kind of operation you want to perform, the resource type, its name, and any additional flag you may want to use. We have a whole article about Kubectl for beginners, so we will not expand on that here. Please refer to it if you need more information about Kubectl.

Output

Before we dive into the cheat sheet, we want you to know that if you use a kubectl get command, there are several output types – apart from the standard – to choose from. Two that you may find useful are these:

-o wide

adds more information, depending on the type of objects being queried

-o yaml and -o json

output the complete current state of the object in YAML or JSON format.

Kubernetes Cheatsheet
Configuration files (manifest)

You can specify your Kubernetes configuration in a manifest file and the tool will work towards reaching the state you have declared. This file can be either a JSON or a YAML file, though it is usually recommended to use the YAML syntax. To leverage a configuration file, use this command:

kubectl apply -f config.yaml

And to compare the current state of the cluster against the state that the cluster would be in if the manifest was applied:

kubectl diff -f config.yaml

Cluster
A Kubernetes cluster consists of a set of worker machines, called nodes, that run your workloads. Every cluster has a control plane that manages it all and at least one worker node.

Nodes
Nodes represent the logical machines, either physical or virtual, that compose the cluster.

This command reports each node’s name, status (running, ready, inactive), roles (master, worker, controlplane, etcd), age, and Kubernetes version:

kubectl get nodes

To get a verbose description of a specific node, use this one:

kubectl describe nodes <node_name>

Namespaces
It is a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects (e.g. Deployments, Services, etc) and not for cluster-wide objects (e.g. StorageClass, Nodes, PersistentVolumes, etc).

Use this command to list all services in the current namespace:

kubectl get services

To retrieve a list of services in all namespaces, use the –all-namespaces (or -A for short) flag:

kubectl get pods --all-namespaces

You can create a new namespace using the following command:

kubectl create ns <new_namespace>

Context
Not to be confused with namespaces. The concept of context only exists on the client (kubectl) side. Setting a context is used to avoid specifying a series of parameters – like cluster or namespace – that are the same for all the following commands. They are defined in the ~/.kube/config file.

Pods
A pod is the smallest deployable and scalable unit in Kubernetes. It contains one or more containers that are relatively tightly coupled. Containers inside the same pod share storage and network resources. Kubernetes pods are created and destroyed to match the desired state of your cluster.

To learn which pods are running in the current namespace, use this command:

kubectl get pods --field-selector=status.phase=Running

To list all pods sorted by restart count, use this:

kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

To delete a pod using the type and name specified in config.yaml:

kubectl delete -f ./config.yaml

And to delete a pod immediately:

kubectl delete pod <unwanted_pod> -now

Services
They are a way to expose an application running on a set of pods as a network service. Kubernetes gives pods their own IP addresses and a single DNS name for a set of pods and can load-balance across them.

To list all services in the namespace sorted by name, use:

kubectl get services --sort-by=.metadata.name

Use this command to display endpoint information (name, resource type, etc.) for your services:

kubectl cluster-info

Deployments
You describe a desired state in a deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate. They are necessary in several use cases, such as rolling back to an earlier Deployment revision, scaling up to facilitate more load, or cleaning up older replicas that you do not need anymore.

You usually declare deployments in a YAML file. After you create the deployment with it, you can check the status with:

kubectl get deployments

To see the deployment rollout status, run:

kubectl rollout status deployment/<deployment_name>

To rollback to the previous deployment:

kubectl rollout undo deployment/<deployment_name>

To scale the deployment (or any other resource) specified in “config.yaml” to 3:

kubectl scale --replicas=3 -f config.yaml

Secrets
A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key so that you don’t need to include confidential data in your application code.

Caution: By default, they are stored unencrypted in the API server’s underlying data store (etcd). Anyone with API access or with access to etcd can retrieve or modify a Secret. Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read any secret in that namespace; this includes indirect access such as the ability to create a Deployment. Read the Kubernetes documentation to learn about ways to safely use secrets.

Use this command to fetch a list of all Kubernetes secrets:

kubectl get secrets

Logs
Kubernetes offers the possibility to handle and store pod, container, and system component logs on nodes. However, cluster-level logging is not native to K8s and you should use a logging solution for that purpose.

To fetch the logs from a pod:

kubectl logs <pod_name>

If your pod has multiple containers, specify which container’s logs you want to access by appending a container name to the command with a -c flag:

kubectl logs <pod_name> -c <container_name>

And to retrieve the logs from a specific service, use this:

kubectl logs -f <service_name>

In case you have not yet tried Napptive, we encourage you to sign up for free and discover how we are helping propel the development of cloud-native apps.

Top CNCF Projects to look out for in 2023

Napptive — Mon, 23 Jan 2023 14:56:49 +0000

If you were thinking you only needed Kubernetes for developing and deploying cloud-native applications, we’re sorry, it’s not! But that’s actually good news and we’re going to tell you why. Kubernetes automates the deployment, scaling, and management of applications. That’s already a lot, but there are so many more challenges around cloud computing, that now and then a new project arises to address one of them. In this post, we will tell you which are the top CNCF projects to look out for in 2023.

CNCF landscape

Before diving into the top 10 CNCF projects, let’s clarify what is the CNCF part. CNCF stands for Cloud Native Computing Foundation. It was created by Google and the Linux Foundation in 2015 to encourage the development and collaboration of Kubernetes and other cloud-native solutions. It defines itself as “the open-source, vendor-neutral hub of cloud-native computing, hosting projects like Kubernetes and Prometheus to make cloud-native universal and sustainable.”

They currently host 147 projects, categorized as Graduated, Incubating, Sandbox, and Archived, according to their maturity. Sandbox projects are in an early stage and require more community involvement before being deployed in production. Incubating and Graduated projects are both considered stable and used successfully in production. The difference is in the adoption rate, the governance process, and other indicators of maturity. Archived projects are at the end of their lifecycle and so the CNCF no longer provides services and marketing for them. The CNCF landscape is an interactive tool you can use to visualize the current state and category of all the CNCF projects.

CNCF incubating projects

As of today, there are 35 incubating projects in the CNCF. Here you have the top 5 in no particular order:

Cilium is in the category of Runtime / Cloud Native Network, which means that it provides networking functionalities to containerized applications. It uses eBPF (extended Berkeley Packet Filter), a revolutionary kernel technology, for providing, securing, and observing network connectivity between container workloads. It is getting a lot of action with 500+ contributors, making it into the top 10 of CNCF projects with the most contributors.
Backstage is a project categorized as App Definition and Development / Application Definition & Image Build, and the one that got the most commits this year of all 147 CNCF projects. It is a framework for building developer portals that was created at Spotify and then donated to the CNCF. Its main goal is to simplify and standardize procedures so that developers can make the most of their time.
Thanos belongs in Observability and Analysis / Monitoring as it is based on Prometheus, a monitoring CNCF project. It makes it easier to scale Prometheus horizontally and obtain a global view of data from several Prometheus servers. Thanos promises high availability and virtually unlimited historical data storage. This year, it got in the top 5 CNCF projects with the most contributors.
gRPC is the Incubating project with the most GitHub stars and the only CNCF project in the category of Orchestration & Management / Remote Procedure Call (RPC). RPC is a way of handling communication between services. It allows for bandwidth-efficient communications and many programming languages enable RPC interface implementations.
Istio is an Orchestration & Management / Service Mesh project. With a service mesh, traffic between services is handled at a platform level. This way, reliability, observability, and security features can be tackled here and provided uniformly across all services, instead of being delegated to developers to include in their code. Istio has become the second Incubating CNCF project with the most stars and with most contributors this year.

Top 10 CNCF Projects

Now that we have covered the most promising Incubating projects, let’s move on to the CNCF Top 10 of 2022. These were the 10 projects with the most GitHub starts (from low to high):

Backstage (Incubating) – We have already explained that Backstage provides an open platform for building developer portals. This is the youngest project (its first commit was just 3 years ago) to make the top 10.
Kubevela (Sandbox) – Kubevela is a software delivery platform that makes deploying and operating applications across hybrid, multi-cloud environments easier, faster, and more reliable. It is infrastructure agnostic, programmable, and application-centric.
Envoy (Graduated) – Envoy is a proxy that serves as a data plane for service mesh. It provides load balancing and resiliency features and can be used as a network API gateway.
k3s (Sandbox) – This is an exceptionally starred Sandbox project! It is a lightweight, certified Kubernetes – also known as K8s – distribution, built for IoT (Internet of Things) and Edge computing.
Helm (Graduated) – It provides a versionable way of defining, installing, and upgrading Kubernetes applications. Self-declared as “the package manager for Kubernetes”, it was introduced at the first KubeCon and became the tenth CNCF project to graduate.
Istio (Incubating) – We presented Istio in the previous section as a service mesh. It extends Kubernetes to establish a programmable, application-aware network using the Envoy service proxy.
gRPC (Incubating) – It is the best-rated Incubating project on the list. As we explained in the previous section, it is an RPC framework to efficiently connect services.
etcd (Graduated) – It is “a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines.” It is, in fact, a component of Kubernetes’ control plane.
Prometheus (Graduated) – It is an open-source system monitoring and alerting toolkit. It was created in 2012 and joined the CNCF in 2016 as the second hosted project.
Kubernetes (Graduated) – The inaugural project of the CNCF is still the most starred. Kubernetes is an orchestration tool that has become the heart of cloud computing development.

Conclusion

Cloud-native computing is fast evolving. Each year, new challenges pop up and new solutions are proposed. In this post, we have given a look at the top CNCF projects to look out for in 2023, based on community metrics such as GitHub stars, community count, and the number of commits. If you want to keep up to date, have a look at the CNCF landscape every so often, and save the Napptive blog to your bookmarks.