The New Stack Podcast

"Developers aren't cryptographers. We can only do so much security training, and frankly, they shouldn't have to make hard choices about this encryption mode or that encryption mode. It should just, like, work," said Kenneth White,  a security principal at MongoDB, explaining the need for MongoDB's new Queryable Encryption feature. 

In this latest edition of The New Stack Makers podcast, we discuss [sponsor_inline_mention slug="mongodb" ]MongoDB[/sponsor_inline_mention]'s new end-to-end client-side encryption, which allows an application to query an encrypted database and keep the queries in transit encrypted, an industry first, according to the company.

White discussed this technology in depth to TNS publisher Alex Williams, in a conversation recorded at MongoDB World, held last week in New York.  

MongoDB has offered the ability to encrypt and decrypt documents since MongoDB 4.2, though this release is the first to allow an application to query the encrypted data. Developers with no expertise in encryption can write apps that use this capability on the client side, and the capability itself (available in preview mode for MongoDB 6.0) adds no noticeable overhead to application performance, so claims the company.

Data remains encrypted all times, even in memory and in the CPU; The keys never leave the application and cannot be accessed by the server. Nor can the database or cloud service administrator be able to look at the raw data.

For organizations, queryable encryption greatly expands the utility of using MongoDB for all sorts of sensitive and secret data. Customer service reps, for instance, could use the data to help customers with issues around sensitive data, such as social security numbers or credit card numbers.

In this podcast, White also spoke about the considerable engineering effort to make this technology possible — and make it easy to use for developers.

"In terms of how we got here, the biggest breakthroughs weren't cryptography, they were the engineering pieces, the things that make it so that you can scale to do key management, to do indexes that really have these kinds of capabilities in a practical way," Green said. 

It was necessary to serve a user base that needs maximum scalability in their technologies. Many have "monster workloads," he notes.

"We've got some customers that have over 800 shards, meaning 800 different physical servers around the world for one system. I mean, that's massive," he said. "So it was a lot of the engineering over the last year and a half [has been] to sort of translate those math and algorithm techniques into something that's practical in the database."

For the past six years, WSO2 has been developing Ballerina, an open-source programming language that streamlines the writing of new services and APIs. It aims to simplify the process of being able to use, combine, and create network services and get highly distributed applications to work together toward a determined outcome.

In this episode of The New Stack Makers podcast Eric Newcomer, Chief Technology Officer of WSO2 discusses how the company created a new programming language from the ground up, and the plans for it to become a predominant cloud native language. Darryl Taft, news editor of The New Stack hosted this podcast.

Founded on the idea that it was too hard to do development with integration, Ballerina was created to program in highly distributed environments. “Cloud computing is an evolution of distributed computing of integration. You're talking about microservices and APIs that need to talk to each other in the cloud,” said Newcomer. “And what Ballerina does, is it thinks about what functions outside of the program that need to be talked to,” he added.

With Ballerina, developers can easily pick it up to create cloud applications. The language design is informed by TypeScript and JavaScript but with some additional capabilities, Newcomer said. “Developers can create records and schemas for JSON payloads in and out to support the API's for cloud mobile or web apps, and it has concurrency for concurrent processing of multiple calls transaction control but in a very familiar syntax, like TypeScript or JavaScript.”

WSO2 is using Ballerina in the company’s low-code like offering, Choreo, which includes features such as the ability to create diagrams. “The long-time challenge in the industry is how do you represent your programming code in a graphical form. [Sanjiva Weerawarana, Founder of WSO2] has solved this problem by putting into the language syntax elements from which you can create diagrams. And he did it in such a way that you can edit the diagram and create code,” said Newcomer.

Engineering for the cloud requires a programing language that can reengineer applications to achieve the auto scale, resiliency, and independent agility, said Newcomer. WSO2 is continuing push their work forward to tackle this challenge. “We're thinking Choreo is going to help us because it's leveraging the magic of Ballerina to help people get their job done faster. Once they see that, they'll see Ballerina and get the benefits of it,” Newcomer said.

VALENCIA – Open source code is part of at least 70% of enterprise stacks. Yet, a lot of open source contributors are still unpaid volunteers. Even more than tech as a whole, the future of open source relies on the community. Unless you're among the top tier funded open source projects, your sustainability replies on building a community – whether you want to or not – and cultivating project leadership to help recruit new maintainers – whether you want to hand over the reins or not.

That's where the Tech Advisory Group or TAG on Contributor Strategy comes in, acting as maintainer relations for the Cloud Native Computing Foundation. In this episode of The New Stack Makers podcast, recorded on the floor of KubeCon + CloudNativeCon Europe 2022, we talk to Dawn Foster, VMware's director of open source community strategy; Josh Berkus, Red Hat's Kubernetes community manager; Catherine Paganini, Bouyant's head of marketing and community; and Deepthi Sigireddi, a software engineer at PlanetScale. Foster and Berkus are the co-chairs of the Contributor Strategy TAG, while Paganini is the creator of Linkerd and Sigireddi is a maintainer of Vitess, both CNCF graduated projects. Each brought their unique experience in both open source contribution and leadership to talk about the open source contributor experience, sustainability, governance, and guidance.

With 65% of KubeConEU attendees at a CNCF event for the first time, albeit still during a pandemic, it makes for an uncertain signal for the future of open source. It either shows that there's a burst of interest for newcomers or that there's a dwindling interest in long-term contributions. The executive director of CNCF Priyanka Sharma even noted in her keynote that contributions for the foundation's biggest project Kubernetes have grown stagnant.

"I see it as a positive thing. I think it's always good to get some new blood into the community. And I think you know, the projects are working to do whatever they can to get new contributors," Foster said.

[sponsor_note slug="kubecon-cloudnativecon" ][/sponsor_note]

But it's not just about how many contributors but who. One thing that was glaringly apparent at the event was the lack of diversity, with the vast majority of the 7,000 KubeConEU participants being young, white men. This isn't surprising at all, as open source is still based on a lot of voluntary work which naturally excludes those most marginalized within the tech industry and society, which is why, according to GitHub's State of the Octoverse, it sees only about 4% women and nonbinary contributors, and only about 2% from the African continent.

If open source is such an integral part of tech's future, that future is built with more inequity than ever before.

"The barrier to entry to open source right now is having free time. And to do free work? Yes, and let's face it, women still do a lot of childcare, a lot of housework, much more than men do, and they have less free time." Sigireddi continued that there are other factors which discourage those widely underrepresented in tech from participating, including "not having role models, not seeing people who look like you, the communities tend to have in-jokes [and other] things that are cultural, which minorities may not be able to relate to." Most open source code, while usually forked globally, exists in English only.

One message throughout KubeConEU was, if a company relies on an open source project, it should pay some of its staff to contribute to and support that project because business may depend on it. This will in turn help bring OSS up a bit closer to the standard of the still abysmal tech industry statistics.

"I think from an ecosystem perspective, I think that companies paying people to do the work on open source makes a big difference," Foster said. "At VMware, we pay lots of people who work primarily on upstream open source projects. And I think that does help us get more diversity into the community, because then people can do it as part of their regular day jobs."

Encouraging those contributors that are underrepresented in OSS to speak up and be more representative of projects is another way to attract more diverse contributors. Berkus said the Contributors Strategy TAG had a meeting at KubeConEU with a group of primarily Italian women who have started in inclusiveness effort, starting with some things like speaker coaching and placement.

"It turns out that a lot of things that you need to do to have more diverse contributors are things you actually needed to do anyway, just to make things better for all new contributors," Berkus explained.

Indeed, welcoming new open source contributors – at all levels and in both technical and non-technical roles – is an important focus of the TAG. Paganini, along with colleague Jason Morgan, is co-author of the CNCF Landscape Guide, which acts as a welcome to the massive, overwhelming cloud native landscape. What she has found is that people will use the open source technology, but they will contribute to it because of the community.

"We see a lot of projects really focusing on code and docs, which of course is the basics, but people don't come for the technology per se. You can have the best technology, it's amazing, and people are super excited, but if the community isn't there, if they don't feel welcome," they won't stick around, Paganini said. "People want to be part of a tribe, right?"

Then, once you've successfully recruited and onboarded your community, you've got to work to not only retain but promote from within. All this and more is jam-packed into this lively discussion that cannot be missed!

More on open source diversity and inclusion efforts:

 

• Beat Affinity Bias with Open Source Diversity and Inclusion

 

• Open Source Communities Need More Safe Spaces and Codes of Conducts. Now.

 

• WTF is Wrong with Open Source Communities

 

• Look Past the Bros, and Concerns About Open Source Inclusion Remain

 

• How to Give and Receive Technical Help in Open Source Communities

 

• Navigating the Messy World of Open Source Contributor Data

 

• How to Find a Mentor and Get Started in Open Source

VALENCIA, SPAIN —Managing the cloud virtual machines (VMs) your containers run on. Running data-intensive workloads. Scaling services in response to spikes in traffic — but doing so in a way that doesn’t jack up your organization’s cloud spend. Kubernetes (K8s) seems so easy at the beginning, but it brings challenges that rachet up complexity as you go.

The cloud native ecosystem is filling up with tools aimed at making these challenges easier on developers, data scientists and Ops engineers. Increasingly, automation is the secret sauce helping teams and their companies work faster, safer and more productively.

In this special On the Road edition of The New Stack Makers podcast recorded at [sponsor_inline_mention slug="kubecon-cloudnativecon" ]KubeCon + CloudNativeCon EU[/sponsor_inline_mention], we unpacked some of the ways automation helps simplify Kubernetes. We were joined by a trio of guests from [sponsor_inline_mention slug="netapp" ]Spot.io by NetApp[/sponsor_inline_mention]: Jean-Yves “JY” Stephan, senior product manager  for Ocean for Apache Spark, along with Gilad Shahar, ​and Yarin Pinyan —product manager and  product architect, respectively, for Spot.io.

Until recently, Stephan noted, Apache Spark, the open source, unified analytics engine for large-scale data processing, couldn’t be deployed on K8s. “So all these regular software engineers were getting the cool technology with Kubernetes, cloud native solutions,” he said. “And the big data engineers, they were stuck with technologies from 10 years ago.”

Spot.io, he said, lets Apache Spark run atop Kubernetes: “It’s a lot more developer friendly, it’s a lot more flexible and it can also be more cost effective.”

The company’s Ocean CD, expected to be generally available in August, is aimed at solving another Kubernetes problem, said Pinyan: canary deployments.

Previously, if you were running normal VMs, without Kubernetes, it was pretty easy to do canary deployments because you had to scale up a VM and then see if the new version worked fine on it, and then gradually scale the others,” he said. “In Kubernetes, it’s pretty complex, because you have to deal with many pods and deployments.”

In enterprises, where DevOps and SRE team members are likely serving multitudes of developers, automating as much toil as possible for devs is essential, said Shahar. For instance, Spot.io’s tools allow users to “break the configuration into parts,” he said, which can task developers with whatever percentage of responsibility for the config that is deemed best for their use case.

“We try to design our solutions in a way that will allow the DevOps [team] to set things once and basically provide pre-baked solutions for the developers,” he said. “Because the developer, at the end of the day, knows best what their application will require.”

Telecoms are not necessarily associated with adopting new-generation technologies. However, Deutsche Telekom has made considerable investments cloud in native environments, by creating and supporting Kubernetes clusters to supports its operations infrastructure. 

In this episode of The New Stack Makers podcast, recorded on the floor of KubeCon + CloudNativeCon Europe 2022, DevOps engineers Christopher Dziomba and Samy Nitsche of Deutsche Telekom discuss how one of Europe’s largest telecom providers made the shift to cloud native.

Deutsche Telekom obviously didn’t start from scratch. It had decades worth of telecom infrastructure and networks that all needed to be integrated into the new world of Kubenetes. This involved a lot of “discussion with the other teams,” Dziomba said. “We had to work together [with other departments] to see how we wanted to manage legacy integration, and especially, and especially, policy and process integration,” Dziomba said. 

As it turned out, many of the existing services Deutsche Telekom offered were conductive to integrating into the distributed Kubernetes infrastructure. “It was suited to be deployed on something like Kubernetes,” Dziomba said. “The decision was also made to build the Kubernetes platform by ourselves inside Deutsche Telekom and not to buy one. This really  facilitated the move towards cloud native infrastructure.”

The shift also heavily involved the vendors that were “coming from the old route,”  Nitsche said. “It's sometimes a challenge to make sure that the application is really also cloud native and to make sure it can use all the benefits Kubernetes offers.

OpenTelemetry is defined by its creators as a collection of APIs used to instrument, generate, collect and export telemetry data for observability. This data is in the form of metrics, logs and traces and has emerged as a popular CNCF project. For this interview, we're delving deeper into OpenTelemetry and its metrics support which has just become generally available.  

The specifications provided for the metrics protocol are designed to connect metrics to other signals and to provide a path to OpenCensus, which enables customers to migrate to OpenTelemetry and to work with existing metrics-instrumentation protocols and standards, including, of course, Prometheus. 

In this episode of The New Stack Makers podcast, recorded on the show floor of KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain, Morgan McLean, director of product management, Splunk, Ted Young, director of developer education, LightStep and Daniel Dyla, senior open source architect, Dynatrace discussed how OpenTelemetry is evolving and the magic of observability in general for DevOps.

Nearly seven years after Google released Kubernetes, the open source container orchestrator, into an unsuspecting world, 5.6 million developers worldwide use it.

But that number, from the latest Cloud Native Computing Foundation (CNCF) annual survey, masks a lot of frustration. Kubernetes (K8s) can make life easier for the organization that adopts it — after it makes it a lot harder. And as it scales, it can create an unending cadence of triumph and challenge.

In other words: It’s complicated.

At KubeCon + CloudNativeCon EU in Valencia, Spain last week, a trio of experts — Saad Malik, chief technology officer and co-founder of Spectro Cloud; Bailey Hayes, principal software engineer at SingleStore; and Fabrizio Pandini, a staff engineer at VMware — joined Alex Williams, founder and publisher of The New Stack, and myself for a livestream event.

The pandemic has significantly accelerated the adoption of Kubernetes and cloud native environments as a way to accommodate the surge in remote workers and other infrastructure constraints. Following the beginning of the pandemic, however, organizations are retaining their investments for those organizations with cloud native infrastructure already in place. They have realized that cloud native is well worth maintaining their investments. Meanwhile, Kubernetes adoption continues to remain on an upward curve. And yet, challenges remain, needless to say. In this context, we look at the status of cloud native adoption, and in particular, Kubernetes at this time, compared to a year ago. 

In this episode of The New Stack Makers podcast, recorded on the floor of KubeCon + CloudNativeCon Europe 2022, we discussed these themes along with the state of Kubernetes and the community with James Laverack, staff solutions engineer, Jetstack a member of the Kubernetes release team, and Christoph Blecker, site reliability engineer, Red Hat, a member of the Kubernetes steering committee.

Go was created at Google in 2007 to improve programming productivity in an era of multi-core networked machines and large codebases. Since then, engineering teams across Google, as well as across the industry, have adopted Go to build products and services at massive scale, including the Cloud Native Computing Foundation which has over 75% of the projects written in the language.

In this episode of The New Stack Makers podcast, Steve Francia, Head of Product: Go Language, Google and alumni of MongoDB, Docker and Drupal board member discusses the programming language, the new features in Go 1.18 and why Go is continuing on a path of accelerated adoption with developers. Darryl Taft, News Editor of The New Stack hosted this podcast.

In the State of Developer Ecosystem 2021, Go ranked in the top five languages that developers planned to adopt and continues to be one of the fastest growing languages. According to Francia, it was created with the motivation to see if a new system programming language could be built and compile quick with security as the top focus. With developers coming and going at Google, the simplicity and scalability of the language enabled many to contribute across several projects at any given time.

“The influences that separates Go from most languages is the experience of the creators behind it who all came to build it with their collective experience,” Francia said.  Today “Go is influencing a lot of the mainstream languages. Elements of it can be found in a tool that formats everyone’s source code to be identical and more readable. Since then, a lot of languages have adopted that same practice,” said Francia. “And then there’s rust. Go and rust are on parallel tracks and we're learning from each other. There's also a new language called V that has recently been open sourced which is the first major language inspired by Go,” Francia said.

The latest release of Go 1.18 was Google’s biggest yet. “It included four major features, each of which you could build a release around,” said Francia. In this release, “Generics is the biggest change of the Go language which has been in the works for 10 years,” Francia added. “Because we knew that generics have the potential to make a language more complicated, we spent a long time going through different proposals,” he said. Fuzzing, workspaces and performance were three other features released in this past version of Go.

“From improving our documentation and learning – which you can go to go.dev/learn/ to get the latest resources – we’re really focused on the broad view of the developer experience,” Francia said. “And in the future, we're seeing not our team so much as the community taking Go in new ways,” he added.

First released in 2016, the Svelte Web framework has steadily gained popularity as an alternative approach to building Web applications, one that prides itself on being more intuitive (and less verbose) than the current framework du jour, Facebook's React. You can say that it reaches back to the era before the web app — when desktop and server applications were compiled — to make the web app easier to develop and more enjoyable to user.

In this latest episode of The New Stack Makers podcast, we interview the creator of Svelte himself, Rich Harris. Harris started out not as a web developer, but as a journalist who created the framework to do immersive web journalism. So we were interested in that.

In addition to delving into history, we also discussed the current landscape of Web frameworks, the Web's Document Object Model, the way React.js updates variables, the value of TypeScript, and the importance SvelteKit. We also chatted about why Vercel, where Harris now works maintaining Svelte, wants to make a home for Svelte.

TNS Editor Joab Jackson hosted this conversation.

Below are a few excerpts from our conversation, edited for brevity and clarity.

So set the stage for us. What was the point that inspired you to create Svelte?

To fully tell the story, we need to go way back into the mists of time, back to when I started programming. My background is in journalism. And about a decade ago, I was working in a newsroom at a financial publication in London. I was very inspired by some of the interactive journalism that was being produced at places like the New York Times, but also the BBC and the Guardian and lots of other news organizations, where they were using Flash and increasingly JavaScript, to tell these data rich interactive stories that couldn't really be done any other way.

And to me, this felt like the future of journalism, it's something that was using the full power of the web platform as a storytelling medium in a way that just hadn't been done before. And I was very excited about all that, and I wanted a piece of it.

So I started learning JavaScript with the help of the help of some some friends, and discovered that it's really difficult. Particularly if you're doing things that have a lot of interactivity. If you're managing lots of state that can be updated in lots of different ways, you end up writing what is often referred to as spaghetti code.

And so I started building a toolkit, really, for myself. And this was a project called Reactive, short for interactive, something out of a out of a Neal Stephenson book, in fact, and it actually got a little bit of traction, not it was never huge, but you know, it was my first foray into open source, and it got used in a few different places.

And I maintained that for some years, and eventually, I left that company and joined the Guardian in the U.K. And we used Reactive to build interactive pieces of journalism there, I transferred to the U.S. to continue at the guardian in New York. And we use directive quite heavily there as well. After a while, though, it became apparent that, you know, as with many frameworks of that era, it had certain flaws.

A lot of these frameworks were built for an era in which desktop computing was prevalent. And we were now in firmly in this age of mobile, first, web development. And these frameworks weren't really up to the task, primarily because they were just too big, they were too big, and they were too bulky and they were too slow.

And so in 2016, I started working on what was essentially a successor to that project. And we chose the name Svelte because it has all the right connotations. It's elegant, it's sophisticated. And the idea was to basically provide the same kind of development experience that people were used to, but change the was that translated into the experience end users have when they run it in the browser.

It did this by adopting techniques from the compiler world. The code that you write doesn't need to be the code that actually runs in the browser. Svelte was really one of the first frameworks to lean into the compiler paradigm. And as a result, we were able to do things with much less JavaScript, and in a way that was much more performant, which is very important if you're producing these kinds of interactive stories that typically involve like a lot of data, a lot of animation

Can you talk a bit about more about the compiler aspect? How does that work with a web application or web page?

So, you know, browsers run JavaScript. And like nowadays, they can run WASM, too. But JavaScript is the language that you need to write stuff in if you want to have interactivity on a web page. But that doesn't mean that you need to write JavaScript, if you can design a language that allows you to describe user interfaces in a more natural way, then the compiler could turn that intention into the code that actually runs. And so you get all the benefits of declarative programming but without the drawbacks that historically have accompanied that.

There is this trade off that historically existed: the developer wants to write this nice, state driven declarative code and the user doesn't want to have to wait for this bulky JavaScript framework to load over the wire. And then to do all of this extra work to translate your declarative intentions into what actually happens within the browser. And the compiler approach basically allows you to, to square that circle, it means that you get the best of both worlds you're maximizing the developer experience without compromising on developer experience.

Stupid question: As a developer, if I'm writing JavaScript code, at least initially, how do I compile it?

So pretty much every web app has a build step. It is possible to write web applications that do not involve a build step, you can just write JavaScript, and you can write HTML, and you can import the JavaScript into the HTML and you've got a web app. But that approach, it really doesn't scale, much as some people will try and convince you otherwise.

At some point, you're going to have to have a build step so that you can use libraries that you've installed from NPM, so that you can use things like TypeScript to optimize your JavaScript. And so Svelte fits into your existing build step. And so if you have your components that are written in Svelte files, it's literally a .SVELTE extension. Then during the build step, those components will get transformed into JavaScript files.

Svelte seemed to take off right around the time we heard complaints about Angular.js. Did the frustrations around Angular help the adoption of Svelte?

Svelte hasn't been a replacement for Angular because Angular is a full featured framework. It wants to own the entirety of your web application, whereas Svelte is really just a component framework.

So on the spectrum, you have things that are very focused on individual components like React and Vue.js and Svelte. And then at the other end of the spectrum, you have frameworks like Angular, and Ember. And historically, you had to do the work of taking your component framework and figuring out how to build the rest of the application unless you were using one of these full-featured frameworks.

Nowadays, that's less true because we have things like Next.js, and remix-vue, And on the Svelte team are currently working on SvelteKit, which is the answer to that question of how do I actually build an app with this?

I would attribute the growth in popularity is felt to different forces. Essentially, what happened is it trundled along with a small but dedicated user base for a few years. And then in 2019, we released version three of the framework, which really rethought the authoring experience, the syntax that you use to write components and, and the APIs that are available.

Around that time, I gave a couple of conference talks around it. And that's when it really started to pick up steam. Now, of course, we're growing very rapidly. And we're consistently at the top of developer-happiness surveys. And so now, like a lot of people are aware of is, but we're still like a very tiny framework, compared to the big dogs like React and Vue.

You have said that part of the Svelte mission has been to make web development fun. What are some of Svelte's attributes that make it less aggravating for the developer?

The first thing is that you can write a lot less code. If you're using Svelte, then you can express the same concepts with typically about 40% less code. There's just a lot less ceremony, a lot less boilerplate.

We're not constrained by JavaScript. For example, the way that you use state inside a component with React, you have to use hooks. And there's this slightly idiosyncratic way of declaring a local piece of state inside the component. With Svelte, you just declare a variable. And if you assign a new value to that variable, or if it's an object, and you mutate that object, then the compiler interprets that as a sign that it needs to update the component.