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.

Before we get into the future of cloud-native security, though, let’s look at where we started in the distant past of … seven years ago.

Our industry started with a focus on basic security hygiene for containers, which formed the basis for “container security.”  While container-related technologies had existed for over a decade, Docker provided the toolset that popularized the Linux container as a standard distribution format for applications, making it widely accessible and adopted.  While it started out with developers building and running containerized apps on their local machines, Docker containers rapidly found their way into many software environments.

RELATED CONTENT: 4 reasons the future of cloud-native software is open source

Suddenly, with thousands of applications being distributed via Docker Hub, people realized this new, emerging area of the stack created new security problems. One of the most straightforward to address first was preventing obviously vulnerable software from being introduced into production environments. Container image scanning became commonplace, with many different options available, including open-source scanners like Clair and OpenSCAP, paid offerings like Black Duck, and ones proprietary to cloud providers.

“The Clair team built it in 2015 to detect vulnerabilities as soon as images were pushed to a registry. By making your container contents more visible, we helped mitigate the distribution of vulnerable applications across servers and workstations. This may sound historical, but many popular public container images are still vulnerable,” remarked Louis DeLosSantos of the Clair project.

Image scanning was “good enough” for most users since they were still running containers in a limited context, such as for non-sensitive web apps, or strictly in development and testing.  But then organizations started running containers in production and everyone had to think about baseline security best practices for the underlying container infrastructure, which led to the Center For Internet Security (CIS) Benchmark for Docker and other tools and guidelines such as those published by the National Institute of Standards and Techonlogy (NIST).  A few platforms, like OpenShift and CoreOS, extended this approach with security modules to further lock down the operating system on the underlying nodes.

Generally speaking, this combination of image scanning and secure infrastructure configuration then became the new “good enough” for production deployments, partly because there was no standard for container orchestration yet.  The major competing orchestration systems  (including Kubernetes, Fleet, Docker Swarm, Marathon, and others) each varied in their feature set, meaning that security tools would have to play to the lowest common denominator to support all of them.  Where the security functionality they provided wasn’t sufficient for users, a new ecosystem of container security vendors quickly emerged to fill in the gaps and augment the major platforms.  They provided — and continue to provide — solutions for security use cases such as runtime security, compliance, and network segmentation.

Progressing to Kubernetes Security

As Kubernetes became the dominant orchestration platform, container security evolved into Kubernetes security, the foundation for cloud-native security today. Enterprises rapidly increased their adoption of cloud-native technologies and matured their usage patterns of containerized applications: running in production, deploying sensitive workloads, scaling to hundreds of nodes, and implementing multi-tenant and multi-cluster scenarios. As a result, it eventually became clear that the only way to effectively manage security is to align with the system that is managing the applications that need to be protected.

As a result, we started extending security use cases into the Kubernetes infrastructure itself.  Vulnerability management meant supplementing image scanning with scanning for, and fixing, vulnerabilities within the Kubernetes control plane and node components.  Configuration management evolved to encompass securing Kubernetes configurations rather than just container configurations. CIS released a Kubernetes security benchmark.  Security vendors developed  threat detection methodologies focused on finding exploits to Kubernetes components like the Dashboard and malicious activity such as cryptojacking; Microsoft researchers published a Kubernetes Threat Matrix based on the well-known MITRE ATT&CK framework.  

This shift to Kubernetes security was also reflected in community efforts that focused on identifying security issues within, and protecting, Kubernetes itself.  The Cloud Native Computing Foundation performed a security audit of the main Kubernetes components.  The Kubernetes community launched SIG-Security, as well as requiring all component teams to have a member responsible for security, and switching the default settings for controls such as Role-Based Access Control (RBAC) in Kubernetes from optional to mandatory.

The Future: Kubernetes-Native Security

The next phase of cloud-native security is already underway, and we are progressing from “Kubernetes security” to “Kubernetes-native security,” as we describe in our whitepaper.  The small difference between those two phrases belies a widespread evolution in integration, tooling, and approaches.  Kubernetes-native security ensures that security is  tightly coupled with the underlying Kubernetes platform (such as OpenShift) and extends security controls by taking advantage of the extensibility of Kubernetes.  Features like Custom Resource Definitions (CRDs), created to enable application automation, also allow us to achieve security automation.

A key element of Kubernetes-native security is making the stack “secure by default.”  We know that users frequently stick to default configurations, which historically have been left insecure for operational convenience or backwards compatibility. With Kubernetes-native security, there is also the opportunity to provide all the capabilities that someone needs across the full application lifecycle for many different common scenarios, whether dev/test or production, single or multi-cluster, and public web apps or ones that process and store sensitive data.  

Aside from integration with native Kubernetes extension points, cloud-native security will also succeed through close integration with DevOps practices and teams, allowing them to manage their security declaratively the same way they manage their infrastructure and workloads. This is what we mean when we refer to the phrase “shift left”: embed and automate security in the workflows that people already use instead of making it an exception.  DevOps teams are the new security users we must enable, and our security tooling must be built with them in mind.

“By shifting security left with DevSecOps and leveraging Kubernetes to define security controls as code with a trusted, automated application and deployment pipeline, organizations can achieve highly scalable security and compliance, while spending less time remediating and more time innovating,” explained Chris Van Tuin, West Region Chief Solutions Architect, Red Hat.

Newer technologies like serverless platforms and service meshes, like early orchestration, are still more fragmented and as a result don’t yet have comprehensive security practices.  However, since most of these are built on top of Kubernetes, they too benefit from a Kubernetes-native security approach.  We can also extend our approach to cover the new security use cases that arise when they are used.

Cloud-native security continues to evolve and improve rapidly.  Since so much of it is open source, you can keep current on it by participating in the Kubernetes and CNCF security SIGs and following projects like Clair, StackRox, OpenShift, and many others. As you continue on your journey with Kubernetes, you can expect security to continually evolve to meet the demands of your business.

To learn more about the transformative nature of cloud-native applications and open source software, check out KubeCon / CloudNativeCon Europe 2021, a virtual event hosted by the Cloud Native Computing Foundation, which takes place May 4–May 7. For more information or to register for the event, go here.

The post The evolution and future of cloud-native security appeared first on SD Times.