Twain Taylor
Twain is a guest blogger for Twistlock and a Fixate IO Contributor. He began his career at Google, where, among other things, he was involved in technical support for the AdWords team. His work involved reviewing stack traces and resolving issues affecting both customers and the Support team, and handling escalations. Today, as a technology journalist, he helps IT magazines, and startups change the way teams build and ship applications.
Service meshes have been getting quite a bit of attention, and with good reason. By providing reliability, security, and observability at the platform layer, service meshes can play a mission-critical role in Kubernetes applications. But tales of adoption are mixed: some practitioners report shying away from adopting a service meshes due to their apparent complexity, while others report getting them up and running with apparent ease. So which is it? Are service meshes too complex to be worth the effort, or ready for adoption today?
In this article I wanted to focus on
Tetrate sponsored this post.
Zack Butcher
Zack is a Tetrate engineer. He is an Istio contributor and member of the Istio Steering Committee and co-author of 'Istio: Up and Running (O’Reilly: 2019).'
In an upcoming Ramaswamy Chandramouli, we’ll be presenting recommendations around safely and securely offloading authentication and authorization from application code to a service mesh. We’ll be discussing the advantages and disadvantages of that approach. This article presents an overview of the paper that will be presented later this month, at
About 10 to 12 years ago, the world of software experienced a shift in the architectural aspects of enterprise applications. Architects and software builders started moving away from the giant, tightly coupled, monolithic applications deployed in the private data centers to a more microservices-oriented architecture hosted in public cloud infrastructure. The inherent distributed nature of microservices is a new security challenge in the public cloud. Over the last decade, despite the growing adoption of microservices-oriented architecture for building scalable, autonomous, and robust enterprise applications, organizations often struggle to protect against this new attack surface in the cloud compared to the traditional data centers. It includes concerns around multitenancy and lack of visibility and control over the infrastructure, as well as the operational environment. This architectural shift makes meeting security goals harder, especially with the paramount emphasis placed on faster container-based deployments.
The purpose of this article is to understand what microsegmentation is and how it can empower software architects, DevOps engineers, and IT security architects to build secure and resilient microservices. Specifically, I’ll discuss the network security challenges associated with the popular container orchestration mechanism Kubernetes, and I will illustrate the value of microsegmentation to prevent lateral movement when a Continue reading
Tetrate sponsored this post.
Jimmy Song
Jimmy is a developer advocate at Tetrate, CNCF Ambassador, co-founder of ServiceMesher, and Cloud Native Community(China). He mainly focuses on Kubernetes, Istio, and cloud native architectures.
In this article, I’ll give you an overview of
Ballerina language to demonstrate how you can effectively use WebSocket features.
The Dynamic Web: Looking Back
Anjana Fernando
Anjana is Director of Developer Relations at WSO2. His latest venture is his role in the Ballerina project, where he has been involved extensively in the design and implementation of the language and its runtime, and now primarily works on its ecosystem engineering and evangelism activities.
HTTP is commonly used for a typical request/response scenario. Using JavaScript, the Fetch API help send requests from the client to servers in the background. This allows us to execute data operations without refreshing or loading another web page. However, this doesn’t support the need for server push scenarios, where requests are initiated from the server and sent to the client. So people came up with workarounds to make Continue reading
Tetrate sponsored this post.
Nick Nellis
Nick is a software engineer at Tetrate, the enterprise service mesh company. He is a DevOps expert on Istio, public cloud architecture, and infrastructure automation.
You may have heard that DNS functionality was added in Istio 1.8, but you might not have thought about the impact it has. It solves some key issues that exist within Istio and allows you to expand your mesh architecture to include multiple clusters and virtual machines. An excellent explanation of the features can be found on the What’s new in Istio 1.8 (DNS Proxy).
Enabling Istio’s DNS Proxy
This feature is currently in Alpha but can be enabled in the IstioOperator config.
View the code on
Yasser Ganjisaffar
Yasser Ganjisaffar is the VP of Engineering at Forward Networks, overseeing all the company’s engineering efforts. He joined Forward Networks in 2014 as an early employee and led the team that scaled the computation core of Forward Enterprise product by 1000x in five years. Prior to that, he built large-scale search infrastructures in Facebook and Microsoft. He holds a Computer Science Ph.D. in the information retrieval domain.
Developing enterprise software is far from simple. Designing a platform to serve hundreds of thousands of users, devices, or data streams (sometimes all at once) is a Herculean task. But that doesn’t mean that it’s impossible to approach the design methodology in a way that encourages scalability in the future.
Scalability is one of the most important considerations in making a new software solution. Without it, the software cannot support user growth without crippling the user experience, and similarly inhibiting sales. Making a scalable software platform is challenging simply because it’s near impossible to know what factors, options and problems the vendor needs to take into consideration beforehand, requiring companies to instead iterate along the way.
That was the issue
Mizar is an open source project providing cloud networking to run virtual machines, containers, and other compute workloads. We built Mizar from the ground up with large scale and high performance in mind. Built in the same way as distributed systems in the cloud, Mizar utilizes XDP (eXpress Data Path) and Kubernetes to allow for the efficient creation of multitenant overlay networks with massive amounts of endpoints. Each of these technologies brings valuable perks that enable Mizar to achieve its goals.
With XDP, Mizar is able to:
Skip unnecessary stages of the network stack whenever possible and transit packet processing to smart NICs.
Efficiently use kernel packet processing constructs without being locked into a specific processor architecture.
Produce very small packet processing programs (<4KB).
With Kubernetes, Mizar is able to:
Efficiently program the underlying core XDP programs.
Manage the lifecycle of its abstractions via CRDs.
Have a scalable and distributed management plane.
Deploy its core components and modules across all specified hosts.
Mizar’s Goals and Continue reading
Infoblox sponsored this post.
Sandeep Rajan
Sandeep is a software engineer at Infoblox focussing on open source contributions to the Cloud Native Computing Foundation (CNCF) projects CoreDNS and Kubernetes.
There has been an increasing demand from users to be able to manage the health, status, rollout, rollback, etc., of CoreDNS in a Kubernetes cluster; and not just rely on CoreDNS being managed by the cluster management tools. Since the use of Operators in Kubernetes is now generally accepted, the aim of the
Third-party DNS providers have seen tremendous consolidation during the past few years, resulting in dependence on a smaller pool of providers that maintain the world’s largest website lookups. Reliance on only one of a few single DNS providers also represents a heightened risk in the event of a Carnegie Mellon University, 89.2% of the CDN MaxCDN, the researchers noted. A
Veteran networking pros at Extended Berkeley Packet Filter (eBPF) technology, which makes the Linux kernel programmable, to address the ephemeral challenges of Kubernetes and microservices.
“If you think about the Linux kernel, traditionally, it’s a static set of functionality that some Linux kernel developer over the course of the last 20 or 30 years decided to build and they compiled it into the Linux kernel. And it works the way that kernel developer thought about, but may not be applicable to the use case that we need to do today,” said Isovalent CEO
KubeCon+CloudNativeCon.
“There’s a lot to say about each of these service meshes and how they work: their architecture, why they’re made, what they’re focused on, what they do when they came about and why some of them aren’t here anymore and why we’re still seeing new ones,” Layer5, explained during his talk with “Service Mesh Specifications and Why They Matter in Your Deployment.”
Service mesh is increasingly seen as a requirement to manage microservices in Kubernetes environments, offering a central control plane to manage microservices access, testing, metrics and other functionalities. One-third of the respondents in The New Stack survey of our readers said their organizations already use service mesh. Among the numerous service mesh options available; Envoy, Linkerd and
Every so often, however, a new buzzword or acronym comes around that really has weight behind it. Such is the case with XDP (eBPF programming language to gain access to the lower-level kernel hook. That hook is then implemented by the network device driver within the ingress traffic processing function, before a socket buffer can be allocated for the incoming packet.
Let’s look at how these two work together. This outstanding example comes from Jeremy Erickson, who is a senior R&D developer with Sebastiano Piazzi on
Lens, the integrated development environment (IDE) for Kubernetes, has seen some rapid growth in the past year, ever since it made some changes to its deployment model and found the backing of Mirantis, that company that in 2019 acquired Docker. At this month’s launched an extensions API alongside several pre-built extensions from popular cloud native products, which
Kyverno, the open source Kubernetes-native policy engine built by Cloud Native Computing Foundation (CNCF) this week at the sandbox level. The development team hopes the software will help adoption of Kubernetes policies, by providing a method for doing so with native tools and languages, rather than requiring users to learn and adopt new ones.
kubectl, kustomize. Bugwadia explained that, by contrast, cert-manager, another new CNCF sandbox project, which Bugwadia said has expressed interest in using Kyverno for policies for certificate management.
Joining the CNCF, he said, leads to those forms of collaboration, which we would not have been able to do otherwise.
The Cloud Native Computing Foundation and KubeCon+CloudNativeCon are sponsors of The New Stack.
Feature image by Pixabay.
The post Kyverno, a New CNCF Sandbox Project, Offers Kubernetes-Native Policy Management appeared first on The New Stack.
gRPC: Up and Running, published by O’Reilly Media. gRPC (gRPC Remote Procedure Calls) is one of the most popular inter-process communication protocols in the modern microservices and cloud native era. With the increasing adoption of gRPC, we thought it was important to write a book on gRPC and share our experience of building cloud native microservices apps with it.
So, before we dive into the details of the book, let me give you a brief overview of what gRPC is.
gRPC is modern inter-process communication technology that can overcome most of the shortcomings of the conventional inter-process communication technologies, such as RESTful services. Owing to the benefits of gRPC, most modern applications and servers are increasingly converting their inter-process communication protocols to gRPC.
The foundation of a gRPC-based application is the service and Continue reading
Open Policy Agent (OPA, pronounced “oh-pa”) for cloud native environments was created, and policy enforcement in code became much more practical. Now, its developers, under their company, new three-tier product offering for Styra Declarative Authorization Service (DAS).
Before diving into DAS, though, let’s make sure we’re all on the same page with OPA and policies in general.
OPA is an open source, general-purpose policy engine that unifies policy enforcement across the stack. You write these policies in its high-level declarative language Datalog query language. With Rego, you can specify policy as code and create simple APIs to offload policy decision-making from your software. You can then use OPA to enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more.
And, what’s a policy engine you ask?
Linkerd, the open source service mesh, has been updated with a number of new features, including support for the ARM architecture, a new multicore proxy runtime, and the automatic enabling of mutual TLS (mTLS) security for all TCP connections.
Buoyant, the company behind AWS Graviton, and support for Kubernetes’s new service topology feature will again increase operating efficiency with the ability to decide routing preferences.
A complete rundown of Linkerd improvements, performance enhancements, and bug fixes can be found in the Ralf Skirr on
SD-WAN ( software-defined networking in a wide area network) and Kubernetes are two major technological developments of interest for businesses on the journey toward digital transformation. SD-WAN extends the SDN feature programmable network and automation to the WAN networks. And Kubernetes has largely adopted a containerized application orchestrator that has solid API architecture, autoscaling, deep monitoring, and load balancing capabilities for dynamic and distributed infrastructures.
Many companies are using them together, given that business applications are distributed to different data centers and edge cloud locations. Here, different Kubernetes clusters are connected to end-user applications and workloads, and SD-WAN is used to connect all the clusters and end users.
Sagar Nangare
Sagar Nangare is technology blogger, focusing on data center technologies (Networking, Telecom, Cloud, Storage) and emerging domains like Edge Computing, IoT, Machine Learning, AI). He is currently serving Calsoft Inc. as Digital Strategist. He is based in Pune. You can reach to him on Twitter @sagarnangare.
But there are still gaps in this amalgamated solution. SD-WAN is used mostly on the public internet, which has different performances in different parts of the world. When we deploy microservice-based applications there may be cases where some microservices may have specific latency requirements Continue reading