To learn more about this technology, we interviewed Ram Iyengar, chief evangelist of the Cloud Foundry Foundation, on the most recent episode of our podcast, What the Dev?

Here is an edited and abridged version of that conversation:

How do buildpacks — and the Paketo Buildpacks in particular — help developers deploy cloud native applications?

I think buildpacks have been very important in making a lot of applications get pushed to production and get containerized without having to deal with a lot of overhead that usually comes with the process of containerization. What can I say that we haven’t said already in the webinar and in the article and things like that? Well, there’s a community angle to this. Buildpacks is somewhat headed towards graduation within the CNCF, and we expect that it will graduate in the next six to 12 months. If there’s any show of support that you can do as a community, I highly welcome people giving it a star, opening important issues, trying the project out, and seeing how you can consume it, and giving us feedback about how the project can be improved.

One thing that I wanted to get into a little bit is Korifi, which is your platform for creating and deploying Kubernetes applications. Can you talk a little bit about Korifi and how it ties in with buildpacks?

Absolutely, one of the main areas where we see a lot of buildpacks being consumed is when people are getting into the job of building platforms on Kubernetes. Now, any sort of talk you see about Kubernetes these days, whether it’s at KubeCon or one of the other events, is it’s extremely complex, and it’s been said so many times over and over again, there’s memes, there’s opinion pieces, there’s all kinds of internet subculture about how complex Kubernetes can be. 

The consequence of this complexity is that some teams and companies have started to come up with a platform where they say you want to make use of Kubernetes? Well, install another substrate over Kubernetes and abstract a lot of the Kubernetes internals from interacting with your developers. So that resonates perfectly with what the Cloud Foundry messaging has been all these years. People want a first-class, self-service, multi-tenant experience over VMs, and they want that same kind of experience on Kubernetes today for somewhat slightly different reasons, but the ultimate aim being that developers need to be able to get to that velocity that they’re most optimal at. They need to be able to build fast and deploy faster and keep pushing applications out into production while folding down a lot of the other areas of importance, like, how do we scale this, and how do we maintain load balances on this? How do we configure networking and ingress?

All of these things should fall down into a platform. And so Korifi is what has emerged from the community for actually implementing that kind of behavior, and buildpacks fits perfectly well into this world. So by using buildpacks — and I think Korifi is like the numero uno consumer of buildpacks — they’ve actually built an experience to be able to deploy applications onto Kubernetes, irrespective of the language and family, and taking advantage of all of those buildpacks features.

I’m hearing a lot of conversation about the Cloud Foundry Foundation in general, that it’s kind of old, and perhaps Kubernetes is looking to displace what you guys are doing. So how would you respond to that? And what is the Cloud Foundry Foundation offering in the Kubernetes world? 

It’s a two part or a two pronged answer that I have. On the one hand, there is the technology side of things. On the other, there’s a community and a human angle to things. Engineers want new tools and new things and new infrastructure and new kinds and ways to work. And so what has happened in the larger technology community is that a sufficiently adequate technology like Cloud Foundry suddenly found itself being relegated to as legacy technology and the old way to do things and not modern enough in some cases. That’s the human angle to it. So when people started to look at Kubernetes, when the entire software development community learned of Kubernetes, what they did was to somehow pick up on this new trend, and they wanted to sort of ride the hype train, so to say. And Kubernetes started to occupy a lot of the mind space, and now, as Gartner puts it quite well, you’re past that elevated expectations phase. And you’re now getting into productivity, and the entire community is yearning for a way to consume Kubernetes minus the complexity. And they want a very convenient way in which to deploy applications on Kubernetes while not worrying about networking and load balancing and auto scalars and all of these other peripheral things that you have to attach to an application.

I think it’s not really about developers just wanting new things. I think they want better tools and more efficient ways of doing their jobs, which frees them up to do more of the innovation that they like and not get bogged down with all of those infrastructure issues and things that that you know now can be taken care of. So I think what you’re saying is very important in terms of positioning Cloud Foundry as being useful and helpful for developers in terms of gaining efficiency and being able to work the way they want to work.

Well, yes, I agree in principle, which is why I’m saying Cloud Foundry and some others like Heroku, they all perfected this experience of here’s what a developer’s workflow should be. Now, developers are happy to adopt new ways to work, but the problem is, when you’re on the path to gain that kind of efficiency and velocity, you often unintentionally build a lot of opinionated workflows around yourself. So, all developers will have a very specific way in which they’ll actually create deployments and create these immutable artifacts, and they’re going to build themselves a fort from where they’d like to be kings of the castle, lord of the manor, but it’s really assailing a lot of the mental image and any apprehensions that come from deviating from that mental image. And at the moment, Kubernetes seems to offer one of the best ways to build and package and deploy an app, given that it can accomplish so many different things. 

Now, if you take a point by point comparison between what Cloud Foundry was capable of in, let’s say, 2017 versus what Kubernetes is capable of right now, it will be almost the same. So in terms of feature parity, we are now at a point, and this might be very controversial to say on a public podcast, but in terms of feature parity, Cloud Foundry has always offered the kind of features that are available in the Kubernetes community right now. 

Now, of course, Kubernetes imagines applications to be built and and deployed in a slightly different way, but in terms of getting everything into containers and shipping into a container orchestrator and providing the kind of reliability that applications need, and allowing sidecars and services and multi-tenancy. 

I strongly believe that the Cloud Foundry offering was quite compelling even four or five years ago, while Kubernetes is still sort of navigating some fairly choppy waters in terms of multi-tenancy and services and things like that. But hey, as a community, they’re doing wonderful innovation. And yeah, I agree with you when I say engineers are always after the best way in which to, you know, gain that efficiency.

The post Podcast: The importance of buildpacks in developing cloud native applications appeared first on SD Times.

The Dxe sidecar offers the three key deployment benefits of isolation, quick deployment, and scalability. 

The application can run independently in one container while the sidecar hosts complementary HA clustering services. DH2i also claims that it’s easier to build and maintain a combined primary application and DxE container image. Lastly, DxE sidecar containers are easy to scale to support as many pods as needed. 

“With the DxE v22 sidecar, database architects and developers can enhance and extend the functionality of their K8s environment. For instance, the DxE sidecar enables users to create highly resilient Zero downtime application-level clusters that span K8 pods,” said Don Boxley, CEO and cofounder at DH2i. “In addition, the DxE sidecar uniquely provides smart HA clustering services to the application containers necessary for mission-critical applications.”

DxEnterprise support for containers can help digital transformation initiatives and provides SQL Server Availability Group (AG) support for SQL Server containers, including for Kubernetes clusters. It also enables customers to deploy stateful containers to improve operations with near-zero RTO to deliver products at lower costs.

The post DH2i announces DxEnterprise v22 with container sidecar appeared first on SD Times.

“Viewing API traffic between microservices is essential if you want to understand the root cause of problems found in complex distributed systems,” Alex Haiut, the co-founder and vice president of engineering at UP9, the company behind the project, wrote in a blog post. “Through our efforts to observe API traffic between microservices, we were able to isolate a chunk of our technology and package it as an open source project.”

Users can easily view traffic in the same way that they can use Google Chrome Dev Tool to view the traffic of their webapps.

The tool works by injecting a container that performs a tcpdump-like operation at the node level of a Kubernetes cluster. The operation can be performed on-demand via a CLI that injects the container when run. Alternatively, when ^C is used, it removes the container.

Mizu doesn’t require code instrumentation. It can be used in true on-demand fashion without prior preparation.

Mizu uses Kubectl and can  therefore run on any node through which kubectl is configured.

The tool supports HTTP/1.x, HTTP/2, AMQP, Apache Kafka, Redis protocols. A Kubernetes server version of 1.16.0 or higher is required.

The post SD Times Open-Source Project of the Week: Mizu appeared first on SD Times.

The guide offers an overview of the concept or use case, an explanation of a traditional solution to achieve it, key open-source projects, and a highlight of how major cloud providers are using open source to address the use case.

“Because every major cloud platform uses open-source software in their infrastructure, developing skills related to open technology makes developers more desirable to potential employers and helps developers compete in hybrid environments; that is, those that provide the ability and flexibility of running parts or all of your cloud solution and services on premises and/or on a public cloud, and/or in multiple clouds,” Todd Moore, VP of open technology at IBM, and Christopher Ferris, IBM Fellow and IBM’s CTO of open technology wrote in a blog post. 

A recent O’Reilly survey that IBM commissioned in late 2020 found that the most desired of the open-source skills are around Linux (containers), artificial intelligence and machine learning, and data storage, each of which IBM now has guides for. 

The guide aims to answer questions on how these skills translate to developing for hybrid cloud environments inclusive of the major cloud providers. 

The post IBM launches guide for contributing to open source cloud projects appeared first on SD Times.

Deploying container image artifacts into various environments remains a difficult task to many, and there are still no agreed-upon best practices. 

“Google Cloud Deploy is the product of discussions with more than 50 customers to better understand the challenges they face doing continuous delivery to GKE. From cloud-native to more traditional businesses, three themes consistently emerged: cost of ownership, security and audit, and integration,” Google Cloud product manager Victor Szalvay wrote in a blog post. 

The operational cost of Kubernetes continuous delivery is high and Identifying best and repeatable practices is resource-intensive and takes time away from the core business. That’s why Google Cloud Deploy eliminates the scaling and maintenance responsibilities that typically come with self-managed continuous delivery solutions. It also provides structure with declaratively defined pipelines and targets. 

As for security, Google Cloud Deploy enables fine-grained restriction, with discrete resource access control and execution-level security. Users can also take advantage of flow management features such as release promotion, rollback, and approvals.

Cloud Audit Logs audits user-invoked Google Cloud Deploy activities, providing centralized awareness into who promoted a specific release or made an update to a delivery pipeline.

Also, for integration, Google Cloud Deploy embraces the GKE delivery tooling ecosystems in three ways: connectivity to CI systems, support for leading configuration (rendering) tooling, and Pub/Sub notifications to enable third-party integrations.

“Comprehensive, easy-to-use, and cost-effective DevOps tools are key to building an efficient software development team, and it’s our hope that Google Cloud Deploy will help you complete your CI/CD pipelines,” Szalvay added. 

The post Google Cloud announces managed continuous delivery service appeared first on SD Times.

The agreement clarifies that developers can share purchase options with users outside of their iOS app; expands the price points developers can offer for subscriptions, in-app purchases, and paid apps; and establishes a new fund to assist qualifying US developers.

Apple and the developers agreed to maintain the program in its current structure for at least the next three years. Businesses earning less than $1 million annually will continue to benefit from the reduced commission, while larger developers pay the App Store’s standard commission on app purchases and in-app payments.

Additional details are available here. 

Qt Creator 5.0 released

Qt Creator 5.0 comes with experimental support for Clangd as the backend for the C/C++ code model. 

This feature is optional and turned off by default, replacing the libclang based code model, and builds on support for the Language Server Protocol. 

Another experimental feature that is shipped with 5.0 is some support for building and running applications in Docker containers.

The full list of new features in this release is available here. 

Phoenix Framework 1.6.0 first release candidate

The first release candidate of Phoenix 1.6.0 brings major additions such as quality of life improvements, bug fixes, and a couple deprecations. 

Phoenix 1.6 ships with a new ‘phx.gen.auth command’ for a complete authentication solution bootstrapped into your application. 

Also, Phoenix LiveView 0.16 was just released with a new HTML engine (HEEx, ~H) for HTML-aware template compilation which users will see utilized in all phoenix generated HTML files going forward.

Additional details are available here.

The post SD Times news digest: Apple resolves class-action suit from US developers regarding App Store, Qt Creator 5.0 released, Phoenix Framework 1.6.0 first release candidate appeared first on SD Times.

The work is the result of a major investment HCL made across its entire product portfolio to modernize its solutions for the cloud, according to Alex Mulholland, chief platform architect at HCL Software. “We wanted to take the software our clients have already made investments in and make it easy to use” in modern cloud environments, she explained. 

The key to this effort, Mulholland said, was leveraging Kubernetes and Helm charts. Each product in the HCL Software portfolio has been packaged in containers, with UIs and dashboards, wrapped as Helm charts. “SoFy is the platform that brings the portfolio together as services,” she said. “Each item in the [HCL Software] catalog is already a Helm chart, with pre-reqs all wrapped up with configuration so they run out of the box.”

Because this is based on native Kubernetes, it is cloud-agnostic, providing flexibility for customers to run the software without cloud vendor lock-in, she explained.

SoFy allows customers to look at what’s available and create their own solution packages; those packages can be deployed to a sandbox and include demos and step-by-step instructions for use, Mulholland noted.

HCL Now, the service offering, lets users run the HCL software wherever they want to run it, with access to log files, containers, and more.

HCL SoFy, which encompasses 26 of the company’s products, is available as a 30-day trial, through a one-click install that can be up and running in an hour. Mulholland also pointed out that cloud-native software also helps customers overcome the pain points of version upgrades, as it’s all done behind the scenes.

The post HCL announces cloud-native platform for building solutions appeared first on SD Times.

“Safe to say, Kubernetes plays a critical role in delivering value to your customers today and enabling you to adapt tomorrow. Keeping your skills sharp and staying up-to-date on developments around this fast-moving technology are paramount,” Mithun Dhar, vice president and general manager of Developer Tools and Programs at Red Hat, wrote in a post. 

RELATED CONTENT: Kubernetes is becoming ubiquitous

Kubernetes by Example was originally launched in 2017. Since then, it has added more learning paths and resources to teach the fundamentals of Kubernetes and containers as well as other related topics. 

The step-by-step guides include: Linux Essentials; Command Line Essentials; Container Fundamentals; Kubernetes Fundamentals; Application Development on Kubernetes; Developing with Java on Kubernetes; and Developing with Spring Book on Kubernetes. Users can get hands-on examples from minikube or OpenShift Playground. 

The company will also be launching its new streaming show KBE Insider on Kubernetes by Example to show first-hand the evolution of the project as well as keep developers up-to-date with the latest insights and skills. 

“We’ve made it as easy as possible to access and use these tutorials. That means there are no fees to participate, or hidden “premium” content that needs to be unlocked. Simply explore the learning paths and lessons from the homepage, and when you’re ready to get started, select and configure your cluster, and you’re ready to go,” Dhar wrote.

The post Red Hat to teach Kubernetes by Example appeared first on SD Times.

According to the company, users will just have to provide the source code, container image and deployment pipeline and the solution will take care of the network traffic, scale up or down depending on the demand, monitor application health and encrypt traffic. 

“With AWS App Runner, development teams—even those who have never used containers or managed infrastructure—can get a containerized application up and running in minutes, so these customers can instead focus on creating the applications that drive their businesses forward rather than managing the underlying hardware and software infrastructure,” said Deepak Singh, vice president of compute services at AWS. 

Amazon explained while users have benefited from AWS Fargate for deploying and running containerized apps, many were asking for a solution that tackled the entire container environment. “These customers want to simply point to their existing code or container repository and have their applications and APIs run and scale automatically in the cloud. They want a fully managed service that handles all of the tasks associated with running containerized applications like building and configuring container orchestrators, load balancers, and CI/CD pipelines, as well as ensuring consistent application and API response times by reducing latency and eliminating cold starts—even when their development teams lack prior experience deploying and managing containers or infrastructure,” Amazon wrote in its announcement. 

App Runner leverages AWS Fargate to automatically deploy, scale and manage apps, and is built with AWS operational and configuration best practices such as automated safe deployments and health checks. Additionally, the company explained the solution eliminates cold states, provides a consistent app response time, and helps developers of all skill levels to build modern containerized web apps. 

AWS App Runner is available now in US East (N. Virginia), US West (Oregon), US East (Ohio), Asia Pacific (Tokyo), and Europe (Ireland), with availability in additional regions coming soon.

The post AWS launches containerized web application solution App Runner appeared first on SD Times.

The new solution provides a private OpenShift environment in a shared, multi-tenant cluster that is pre-configured with a set of developer tools. The tight integrations between the infrastructure and tools provide a safe environment for prototyping or building new applications, creating containers from source files or Docker files and more, according to the company. 

Red Hat also announced updates to many of its tools which can be coupled with the Developer Sandbox. 

Red Hat OpenShift 4.7 web console developer perspective makes it easier for developers to get started with new integrations and fully-customizable quick starts. 

The CLI tool odo 2.1 also received an extended declarative developer workspace (devfile) to make it easier to build and debug apps. 

Red Hat CodeReady Workspaces 2.8 introduces a new dashboard that delivers a faster, more streamlined and more consistent user experience and Red Hat CodeReady Studio 12.19 further extends developer tooling with the ability to bootstrap and log into a developer sandbox, or to add, remove and edit devfile registries.

Other updated tools include Red Hat CodeReady Dependency Analytics 0.3.2, Red Hat CodeReady Containers 1.25, Eclipse JKube 1.2 and the new GitHub Actions for Red Hat OpenShift and Enterprise Linux provides users with an easier way to build and deploy their containerized applications.

Additional details on the new Developer Sandbox and updated tooling is available here.

The post Red Hat announced Developer Sandbox and new solutions to help get started with Kubernetes appeared first on SD Times.