At Microsoft’s Build conference in Seattle today, the software and cloud giant announced the public preview of Microsoft Fabric, the company’s new end-to-end analytics platform. The product both evolves and unifies heretofore separate cloud services, including Azure Synapse Analytics, Azure Data Factory and Power BI. And though all of the precursor services on the Azure side have been available as separately-billed Platform as a Service (PaaS) offerings, Microsoft Fabric unifies them under a single Software as a Service (SaaS) capacity-based pricing structure, with a single pool of compute for all workloads within the scope of the platform.

Fabric’s functionality spans the full data lifecycle, including data ingest and integration, data engineering, real-time analytics, data warehousing, data science, business intelligence and data monitoring/alerting. All such workloads are data “lake-centric” and operate on top of a unified data store called OneLake, in which data is persisted in Apache Parquet/Delta Lake format, a combination that brings relational table-like functionality to data stored in open data lake formats. And since Fabric can also connect to data in Amazon S3 (and, in due time, to Google Cloud Storage, Microsoft promises) via so-called “shortcuts” in OneLake, there’s a multicloud dimension to all of this as well.

Less Assembly Required

The New Stack was briefed last week on Microsoft Fabric by Arun Ulagaratchagan, Microsoft’s Corporate Vice President of Azure Data, who provided important color on why Microsoft created Fabric and what its goals were with it. With the benefit of that insight, it seems the real innovation in Microsoft Fabric may be around the analytics integration it delivers, which has been sorely lacking in the industry at large, and even within Microsoft’s own collection of data and analytics services.

Ulagaratchagan got to the point pretty quickly with one key observation about the analytics landscape today: “if you put yourself in the customers’ shoes, there are literally hundreds, thousands of products out there that they have to figure out what makes sense for them, how do they use it, how do they wire it all up together to be able to take advantage the data, get it to the right shape that they need, and make it work for their business.”

Fabric was designed to solve this very real deficiency in the modern data stack, and the level of integration and rationalization that Fabric has already achieved is unprecedented. I say this as someone who participated in the early adopter’s program for Fabric and who has used Microsoft data and analytics technology for almost 30 years.

• Must read: Data 2023 Outlook: Rethink the Modern Data Stack

The Microsoft analytics stack was fractured even in the enterprise software days, and the era of the cloud had only made it worse. What Microsoft has done with Fabric is to address these disconnects and arbitrary segregations of functionality, not just technologically, but also in terms of the pricing/billing model and the structure of the engineering organization behind it all. I will explain all of that in more detail later in this post, but first, let’s take inventory of Fabric’s components, capabilities and use cases.

What’s in the Box?

Of Fabric’s seven core workload-specific components, one, called Data Activator, which implements data monitoring/alerting, is built on new technology and is in private preview. The other six, which are based on technologies that existed previously, and are available today in the Fabric public preview, are as follows:

• Data Factory, based on Azure Data Factory and Power Query technology, provides for visual authoring of data transformations and data pipelines.
• Synapse Data Engineering, based on the same technology as the Spark pools in Azure Synapse Analytics, and related technologies for Apache Spark, including notebooks, PySpark and .NET for Apache Spark, provides for code-first data engineering. However, unlike the explicitly provisioned Spark pools in Azure Synapse Analytics, Spark resources in Fabric are provided on a serverless basis using “live-pools.”
• Synapse Data Science, which provides for training, deployment and management of machine learning models. This component is also based largely on Spark, but incorporates elements of Azure Machine Learning, SQL Server Machine Learning Services and the open source MLflow project, as well.
• Synapse Data Warehousing, based on an evolution of the original Azure SQL Data Warehouse (and, ultimately, SQL Server) technology provides a “converged” lakehouse and data warehouse platform.
• Synapse Real-Time Analytics, which combines Azure Event Hubs, Azure Stream Analytics, Azure Data Explorer and even open source event streaming platforms like Apache Kafka, allows analytics on IoT, telemetry, log and other streaming data sources.
• Power BI, Microsoft’s flagship business intelligence platform, but soon-to-be enhanced with a new large language model AI-based Copilot experience that can generate DAX (Data Analysis eXpressions — Power BI’s native query language). In many ways, Power BI is the “captain” of the Microsoft Fabric team as its Premium capacities and workspaces are the basis for their counterparts in Fabric.

The inclusion of Power BI in Microsoft Fabric goes beyond its own capabilities and provides integration with Microsoft 365 (read: Office) by extension. Tight integration between Power BI on the one hand, and Excel, PowerPoint, Teams, SharePoint and Dynamics 365, on the other, means the power of Fabric can be propagated outwards, to bona fide business users and not just business data analysts.

• Check out: Microsoft Power BI Gets Low-Code Datamart Feature

All for One

Despite the varied branding, which may have been done for reasons of continuity or politics, Fabric is a single product with a single overarching user interface and user experience. As Ulagaratchagan explained, “even though it is seven workloads running on top of One Lake, it looks and feels and works from an architecture perspective as one integrated product. We wanted to make sure we conveyed how all of these experiences just flow. That’s why the Fabric name seemed appropriate.”

Although persona-specific UIs are provided for different workloads, they are more akin to “skins” or “views” than distinct products. In fact, The “Create” button in Fabric’s navigation bar presents a menu of all artifacts from all workloads, as an alternative to the compartmentalized experiences and, in the process, emphasizes the integrated nature of it all.

Whether the workloads are engaged from their respective user interfaces or the general one, the “artifacts” created in each are kept together in unified Fabric workspaces. And because the basis for each data artifact consists of Delta/Parquet data files stored in OneLake, many of the assets are just thin, workload-specific layers that sit atop those physical data files. For example, a collection of data in OneLake is directly readable and writeable by Spark, as with any data lake, but it can also manifest as tables in a relational data warehouse or a Power BI dataset.

Of course, each artifact type can contain its own unique assets; for example, a warehouse can have views and stored procedures, and a Power BI dataset can have measures and hierarchies. None of the components in Fabric gets dumbed down, but several (and, eventually, all, quite possibly) use Delta/Parquet as a native format, so the data doesn’t need to be replicated in a series of component-specific proprietary formats.

Cooperation, Not Duplication

This means that, in Fabric, a data engineer writing Python code running on Spark, a data scientist training a machine learning model, a business analyst creating sophisticated data visualizations, and an ETL engineer building a data pipeline are all working against the same physical data. And folks using other data platforms — including Databricks or non-Microsoft BI tools — can share this same physical data too, because OneLake is based on, and API-compatible with, Azure Data Lake Storage, to which most modern data stack technologies have connectivity.

In the case of Power BI, the ramifications get even more interesting. When working with data in Microsoft Fabric, a BI engineer doesn’t have to decide whether to import the data into a Power BI model or leave it in OneLake and query it on the fly. With the aid of something called Direct Lake mode, that distinction goes away, because the data in OneLake already is in a Power BI-native format. Power BI already supported composite models, where Import and DirectQuery access methods could be combined in a single model. But with Direct Lake mode, composite models aren’t necessary, as the need to import data from OneLake is simply eliminated.

Eliminating the segregation between services, artifacts and data formats means the economics get simpler, too. Fabric’s capacity-based compute model provides processing power that is fungible between, and usable from, all of its workloads. Ulagaratchagan had this to say on that subject: “We see this as an opportunity for customers to save a ton of money because today, often every analytics product has multiple subsystems. These subsystems typically require different classes of products, often coming from different vendors, and you’re provisioning multiple pools of compute across many different products, and weaving them all together to create one analytics project.”

While Ulagaratchagan identifies this as a problem with a multi-vendor approach, even a Microsoft-only solution has up until now suffered from the same issue. The combination of Power BI and the present-day Azure services needed to create an equivalent to Microsoft Fabric has up until now required separately provisioned compute. This sprawl can even be an issue within an individual service. For example, Azure Synapse requires the management of four different types of compute clusters (Dedicated SQL, Serverless SQL, Spark and Data Explorer), three of which invoke separate infrastructure lifecycles and billing. Fabric eliminates these redundancies and their accompanying complexity and expense.

Take Me to Your (Common) Leader

There’s corporate unification at play here too. Many of the teams at Microsoft that built Fabric’s forerunner technologies — like Azure Synapse, Data Factory and Power BI — worked together to build Fabric and are all part of the same organizational structure under the management of Ulagaratchagan and the technical direction of Technology Fellow Amir Netz, the duo that previously led the standalone Power BI organization. This alignment is rather unprecedented at Microsoft, a company infamous for its internal competition and the sometimes disjoint technologies that result. The challenges here involved geography, too: engineering teams in the US, India, Israel and China, each with their own culture and operating in their own time zones, worked together in a remarkably cohesive fashion to build Fabric.

Building a federated product team like this was a calculated but very big gamble. Frankly, it could have gone horribly wrong. But from my point of view, morale was high, hubris was practically non-existent and top talent at Microsoft was skillfully honed to build a very comprehensive platform that changes the analytics game immensely. All three cloud providers were guilty of creating numerous siloed services and putting the burden of implementing them in combination on the customer. That’s not just an issue of discourtesy or insensitivity — it’s one of expense too, as customers need either to allocate significant human resources to such projects, or else invest an enormous amount of capital in the consulting talent necessary to carry them off.

Some of the technologies that now work together within Fabric have literally decades of history. And those that are newer had to be integrated with the older ones, and each other. Much as PC “defrag” tools tidy and reorganize files on spinning hard drives that have become scattered across the disk, Microsoft has had to defrag itself and its analytics technology stack to get Fabric built. Even if much of the technology itself isn’t new, the harmonious unification of it is a huge breakthrough that will enable new analytics use cases because of new simplicity, ease of use, efficiencies and economies of scale.

How to Get Started

The public preview of Microsoft Fabric begins immediately. Microsoft says Power BI Premium customers can get access to Fabric today by turning on the Fabric tenant setting in the Power BI admin portal, which will have the effect of upgrading Premium capacities to support Fabric. Customers can also enable Fabric in specific capacities instead of their entire tenant. Microsoft says that using new Fabric functionality (versus capabilities that were already available under Power BI) will not incur capacity usage before Aug. 1, 2023, but customers can still use the Capacity Metrics app to monitor how Fabric would impact capacity usage were the meter running.

Non-Power BI Premium customers can get access to a free 60-day Fabric trial.

Next Frontier

There’s more work to be done. Not only does Fabric have to move from Public Preview to GA, but more functionality is required. Microsoft is promising Copilot experiences for all workloads, rather than just Power BI. The company says this is in private preview now, so general availability would seem a long way off. Likewise, Data Activator needs to move forward to public preview and full release. And data governance functionality of the type offered by Microsoft Purview will be needed in Fabric to make it a truly complete offering. For now, the lineage, impact analysis and asset endorsement capabilities of Power BI will have to do.

There’s lots of other work ahead, too. Just because the Fabric team was successful with the heavy lift required to get where they are now doesn’t mean the pressure’s off, by any means. As the product moves to public preview, the technology, the pricing model, and the very notion that customers will prefer the end-to-end approach to “a la carte” functionality and procurement will now all be put to the test. There’s more pivoting, more innovation and more risk management required; and if Fabric is successful, competition from AWS and/or Google Cloud is almost sure to follow.

But Microsoft can celebrate significant interim success with Fabric already and betting on its ultimate success seems prudent. In an era when everyone’s going gaga over AI, we need to keep in mind that AI’s models are only as good as their underlying data, and the engineering used to discover, shape and analyze it. AI may get a lot of the “oohs and ahs” at Build, but I’d argue Fabric is the real news.

Disclosure: Post author Andrew Brust is a Microsoft Data Platform MVP and member of Microsoft’s Regional Directors Program for independent influencers. His company, Blue Badge Insights [www.bluebadgeinsights.com], has done work for Microsoft, including the Power BI team.

The post Microsoft Fabric Defragments Analytics, Enters Public Preview appeared first on The New Stack.

There are a lot of things to love about WebAssembly — but how do developers decide when to use it? Does it matter in what language you write to WebAssembly? And what about security? To learn more about what frontend developers need to know, I sat down with Andrew Cornwall, a senior analyst with Forrester who specializes in the application development space.

The good news is, functionality does not alter depending on which coding language you write in. Write in C++, AssemblyScript, Rust — it’s the developer’s choice, Cornwall said. Typically, it’s easier to compile languages that do not have garbage collectors, so languages such as Java, Python, and interpreted languages tend to be more difficult to have running in WebAssembly than languages such as C or Rust. But the end result will be WebAssembly, which he noted is best thought of as a processor rather than a language.

“Something like JavaScript or Java or Python, where there’s a whole ecosystem in there that needs to be in place before you can run,” Cornwall said.

Typically, developers will take the C implementation of Python, compile it using a compiler that outputs WebAssembly, he said. Now they have a Python interpreter that is written in WebAssembly, which they can then feed regular Python code.

“That is easier to do than converting Python to WebAssembly itself,” he added.”Once it’s in WebAssembly, it doesn’t matter. It just runs — it’s essentially very similar to machine code.”

For other supported languages, rather than compile to x86 or Arm on a compiler, developers opt for WebAssembly when compiling, he explained. The compiler outputs the byte code that will run — WebAssembly, or Wasm, is a low-level byte code that can be translated to assembly. A bytecode is computer object code that an interpreter converts into binary machine code so it can be read by a computer’s hardware processor. Essentially, WebAssembly converts code to this portable binary-code format. As such, it has more in common with machine language than anything else and that’s why it’s so gosh darn fast.

Wasm Use Cases for the Frontend

When WebAssembly first came out, it was seen primarily as a solution for frontend needs, Cornwall said. Typical use cases for the frontend include operations with a lot of matrix math and video. If you need something to start executing right away and don’t have time to wait for the JavaScript to download and parse in the browser, then WebAssembly is a great solution, he said. For instance, the BBC created a video player for its site in Wasm and Figma is written in C++ and compiled to WebAssembly, where it cut load time by three times.

“WebAssembly can be streaming so you can download it and start executing it right away,” Cornwall said. “Other than that, the other interesting use case for WebAssembly on web front ends is going to be not so much for JavaScript developers, but for developers of other things.”

That’s in part because JavaScript running through the just-in-time [JIT] compiler is actually pretty fast, he said, adding that developers can get to half native speed with JavaScript “if you let it run long enough.” For other developers, Wasm means they can write in their favorite, supported code and then compile to Wasm for the frontend.

“The interesting parts where WebAssembly gets used are essentially things where you’d go down to machine code if you were writing a program in another language,” he said. “If there is something that needs to be really fast right away, and you can’t afford to wait for the JIT to bring it into high speed by optimizing it, or if there is something you need it to start right away and you don’t want to wait for the time for the JavaScript to be parsed, for instance, so you have it in WebAssembly.”

Wasm for the Backend

Then a funny thing happened along the way to the assembly (ahem): Wasm started to become less of a frontend thing and more of a backend thing as it began to be leveraged for serverless compute, he said.

“WebAssembly VMs [virtual machines] start really fast compared to JavaScript VMs or containers,” he said. “A JavaScript VM starts in milliseconds, so 50, 100 milliseconds; WebAssembly VMs can start in microseconds. … If you’re running serverless functions, that’s great because you make a call out to the server and say, give me the result. It can then start up and give you the results really quickly, whereas other things like Javascript VM, Java VMs and containers have that startup time the cost that it takes to for them to start running before they can then do something with the values that you’re passing them and give you the result.”

That includes Kubernetes containers, he added. And there are places — serverless functions or where the web browser wants to make a request of a search function — where developers would want to use WebAssembly VMs instead of a Kubernetes container, he added.

“If you send that search request off, you’re waiting until the container comes up, runs the code the search code itself and then sends the result back. Often containers will allow multiple connections because it’s expensive to bring a container up,” he said. “So Kubernetes, it has a cost to bring the container up. With WebAssembly you don’t have as much of a cost. It’s microseconds to come up rather than milliseconds; or even if it’s a container, it could even be hundreds of milliseconds or getting close to half a second.”

Multiple that by 1000s and those milliseconds start to add up.

How Wasm Improves Security

There’s also a security risk in containers because people tend to reuse them rather than shut them down and start over. That’s not an issue with Wasm.

“Then you need to worry about how did what someone that came before me affect what the current person is requesting or what the current request is going on?” Cornwall said. “With WebAssembly it’s so cheap, you just throw it away. You can just write a serverless function, start up the VM, execute the serverless function and then throw it all the way and wait for the next request.”

Not that Wasm is a replacement for containers all the time, he cautioned. Containers are still needed and make sense when running big queries on large databases, where adding another 300 milliseconds to the query really doesn’t make much of a difference.

“Things like that will probably stay in containers because it is a little bit easier to manage a container, at least right now, than it is to manage WebAssembly serverless functions that just kind of float around in space,” he said. “WebAssembly is going to be an addition to when you need to make fast calls to serverless functions, as opposed to taking over for all containers.”

Another way Wasm is more secure than other options is that it will only execute within its sandbox — nothing goes outside of the sandbox. That’s why so far the biggest security threat seen with WebAssembly has been from websites where bitcoin miners were hidden in the Web Assembly, causing the website user to unwittingly loan CPUs for bitcoin mining. It’s not possible for code compiled into Wasm to reach and send out passwords, for instance, because the code stays within the Wasm sandbox, Cornwall explained.

The post Forrester on WebAssembly for Developers: Frontend to Backend appeared first on The New Stack.

A blog post from the engineering team at Amazon Prime Video has been roiling the cloud native computing community with its explanation that, at least in the case of video monitoring, a monolithic architecture has produced superior performance than a microservices and serverless-led approach.

For a generation of engineers and architects raised on the superiority of microservices, the assertion is shocking indeed. In a microservices architecture, an application is broken into individual components, which then can be worked on and scaled independently.

“This post is an absolute embarrassment for Amazon as a company. Complete inability to build internal alignment or coordinated communications,” wrote analyst Donnie Berkholz, who recently started his own industry-analyst firm Platify.

“What makes this story unique is that Amazon was the original poster child for service-oriented architectures,” weighed in Ruby-on-Rails creator and Basecamp co-founder David Heinemeier Hansson, in a blog item post Thursday. “Now the real-world results of all this theory are finally in, and it’s clear that in practice, microservices pose perhaps the biggest siren song for needlessly complicating your system. And serverless only makes it worse.”

In the original post, dated March 22, Amazon Prime Senior Software Development Engineer Marcin Kolny explained how moving the video streaming to a monolithic architecture reduced costs by 90%. It turns out that components from Amazon Web Services hampered scalability and skyrocketed costs.

The Video Quality Analysis (VQA) team at Prime Video initiated the work.

The task as to monitor the thousands of video streams that the Prime delivered to customers. Originally this work was done by a set of  distributed components orchestrated by AWS Step Functions, a serverless orchestration service, AWS Lambda serverless service.

In theory, the use of serverless would allow the team to scale each service independently. It turned out, however, that at least for how the team implemented the components, they hit a hard scaling limit at only 5% of the expected load. The costs of scaling up to monitor thousands of video streams would also be unduly expensive, due to the need to send data across multiple components.

Initially, the team tried to optimize individual components, but this did not bring about significant improvements. So, the team moved all the components into a single process, hosting them on Amazon Elastic Compute Cloud (Amazon EC2) and Amazon Elastic Container Service (Amazon ECS).

Takeaway

Kolny was careful to mention that the architectural decisions made by the video quality team may not work in all instances.

“Microservices and serverless components are tools that do work at high scale, but whether to use them over monolith has to be made on a case-by-case basis,” he wrote.

To be fair, the industry has been looking to temper the enthusiasm of microservices over the past decade, stressing it is only good in some cases.

“As with many good ideas, this pattern turned toxic as soon as it was adopted outside its original context, and wreaked havoc once it got pushed into the internals of single-application architectures,” Hansson wrote. “In many ways, microservices is a zombie architecture. Another strain of an intellectual contagion that just refuses to die.”

The IT world is nothing but cyclical, where an architectural trend is derided as hopelessly archaic one year can be the new hot thing the following year. Certainly, over the past decade when microservices ruled (and the decade before when web services did), we’ve heard more than one joke in the newsroom about “monoliths being the next big thing.” Now it may actually come to pass.

The post Return of the Monolith: Amazon Dumps Microservices for Video Monitoring appeared first on The New Stack.

It’s been 12 years since IBM’s Watson took on Jeopardy champions and handily won. Since then, the celebrity of Watson has been usurped by ChatGPT, but not because IBM has abandoned Watson or artificial intelligence. In fact, the company’s approach to artificial intelligence has evolved over the years and now reflects a different, more targeted path forward for AI — beyond pumping out generic large language models.

I sat down with IBM Fellow and CTO of IBM Cloud Jason McGee during KubeCon+CloudNativeCon EU, to discuss how Big Blue is approaching modern challenges such as serverless, WebAssembly in the enterprise, and of course artificial intelligence. The conversation has been edited for clarity and brevity.

Using AI for Code Automation

What is IBM doing with automation?

There [are] a lot of dimensions to automation. At the base technology level, we obviously do a lot of work with Ansible and the Red Hat side, and then we use TerraForm pretty extensively as a kind of infrastructure as code language for provisioning cloud resources and managing a lot of those reference architectures — under the covers are essentially collections of TerraForm automation that [are] configured [in] the cloud. There is also higher level work going on in automation, and that’s more like business process automation and robotic process automation, and things like that. With products like Watson Automate, [we] are applying AI and automation to customers, business processes and automating manual things. So that’s kind of higher up the stack.

Tigera provides the industry’s only active security platform with full-stack observability for containers and Kubernetes. Tigera’s platform, delivered as a fully-managed SaaS or self-managed service, prevents, detects, troubleshoots, and automatically mitigates exposure risks of security breaches.

Learn More

The latest from Tigera

We have tools [like robotic process automation and business process management] in our space, and we’re applying AI to that and then down the technology stack. We have software automation tools like TerraForm and Ansible that we’re using. We’re doing some interesting work on Ansible or the research team, with applying foundation models to help code assist on Ansible and helping people write automation using AI, to help fill in best practice code based on natural language descriptions and stuff.

What does the AI do in that context?

Think about if you’re writing an Ansible playbook, you might have a block that’s, “I want to deploy a web application on Node.js” or something. You could just like write a comment, “Create a Node.js server. running on port 80” in natural language, and it would read that comment and automatically fill in all of the code and all the Ansible commands, to provision and configure that using best practices. It’s been trained on all the Ansible Galaxy playbooks and GitHub Ansible code. So it’s like helping them write all the Ansible and write good Ansible […] based on natural descriptions of what they’re trying to achieve.

The AI is based on large language models. Do they hallucinate? I keep hearing they hallucinate and I’m reminded of the story, “Do Androids Dream of Electric Sheep?”

A great question and it’s part of the example I gave you of that model [which] was trained for a more narrow purpose of doing Ansible code assist, versus something like GPT, which was like trained on everything and therefore it can be more accurate at the smaller scope, right? It understands natural language but also understands Ansible very precisely, and so it can have a higher accuracy than a general purpose large language model, which also could spit out Ansible or TerraForm, or Java or whatever the heck you wanted it to, but maybe has less awareness of how good or accurate language is.

We’re using it in AI Ops as well for incident management, availability management and property termination. That’s another kind of big space that IBM is investing a lot in — Instana, which is one of our key observability tools.

How do we help customers adopt and leverage large-scale foundations with large language models? In IBM Cloud we have this thing called the Vela cluster, which is a high-performance foundation model training cluster that’s in our cloud in Washington, DC. It was originally built for our research team so that the IBM Research Group could use it to do all their research and training on models and build things like Project Wisdom on it.

Now we’re starting to expose that for customers. We believe that enterprises will build some of their own large language models or take base models — because we’re also building a bunch of base models — and then customize them by training them on additional unique data. We’re doing work in OpenShift, to allow you to use OpenShift as the platform for that. We’re doing work in open source around that software stack for building models. And then we’re of course building a whole bunch of models.

Beyond Traditional Serverless

TNS: What else are you here promoting today at KubeCon?

McGee: There’s a lot of activity in this space that we’ve been working for a long time on, so it’s more progression. One is serverless and we have a capability called IBM Cloud Code Engine and that’s based on K data, which is like a layer on top of Kubernetes, designed to help developers consume cloud native. We’ve been doing a lot of work recently expanding that serverless notion to a more varied set of workloads.

Traditional serverless was like apps and functions running event-driven kinds of workloads — a lot of limitations on what kinds of applications you could run there. What we’ve been doing is extending that and opening up the kinds of workloads you can run, so we’re adding in things like batch processing, large-scale parallel computation, compute-intensive, simulation kind of workloads. We’re starting to do some work on HPC [high-performance computing] so people can do financial modeling or EDA [exploratory data analysis], industrial design and silicon design workloads, leveraging a serverless paradigm. We have a lot of activity going in that space.

We’re also working with a project called Ray, which is a distributed computing framework that’s being used for a lot of AI and data analytics workloads. We’ve enabled Ray to work with the Code Engine so that you can do large-scale bursts [of] compute on cloud and use it to do data analytics processing. We’ve also built a serverless Spark capability, which is another data analytics framework. All of those things are exposed in a single service in Code Engine. So instead of having seven or eight different cloud services that do all these different kinds of workloads, we have a model where we can do all that in one logical service.

What kinds of use cases are you seeing from your customers with serverless?

One of the challenges with serverless is [that] when it started a few years ago, with cloud functions and Lambda, it was positioned in a very narrow kind of way — like it was good for event-driven, it was good for kind of web frontends.

That’s interesting, but customers actually get a lot more value out of these more large-scale, compute-intensive workloads. Especially in cloud, you’d have this massive pool of resources. How do you quickly use that massive pool of resources to run a Monte Carlo simulation or to run a batch job or to run an iteration of design verification for a silicon device you’re building? When you have those large-scale workloads, the traditional way you would do that is you would build a big compute grid, and then you have a lot of costs sunk in all this infrastructure.

We’re starting to see them use serverless as the paradigm for how they run these more compute-intensive, large-scale workloads, because that combines a nice set of attributes, like the resource pool of cloud, with [a] pay-as-you-go pricing model, with a no infrastructure management. You just like simply spin up and spin back down as you run your work. So that’s the angle on serverless we’re seeing a lot more adoption on.

Wasm’s Potential

Are people using serverless on the edge?

They do. It’s more niche, of course. But you see, for example, in CDN (content delivery network), where people want to push small-scale computation out to the edge of the network, close to the end users — so I think there [are] use cases like that. At IBM Cloud, we use Cloudflare as kind of our core internet service, [with] global load balancer and edge CDN, and they support our cloud functions. You see technology like Wasm — just a lot of people here talking about Wasm. Wasm has a role to play in those scenarios.

Is IBM doing anything with Wasm? Is it useful in the enterprise?

We’re enabling some of that, we’re looking at it in the edge. We support Wasm Code Engine, it gives you a nice, super fast startup time, like workload implication in 10 milliseconds or something, because I can inject it straight in with Wasm, which is useful if you’re doing large-scale bursty things but you don’t want to pay the penalty of waiting for things to spin up.

But I still think that whole space is more exploratory. It’s not like there [are] massive piles of enterprise workloads waiting to run on Wasm, right? So it’s more next-gen edge device stuff. It’s useful — there [are] some interesting use cases around that HPC [high-performance computing] space potentially … because I can inject small fragments of code into an existing grid, but I also think it’s it’s a little more niche, specialist workloads.

CNCF paid for travel and accommodations for The New Stack to attend the KubeCon+CloudNativeConEurope 2023 conference.

The post IBM’s Quiet Approach to AI, Wasm and Serverless appeared first on The New Stack.

Over the last two decades, the rise of cloud computing has enabled the creation of countless new businesses and revolutionized how existing organizations operate and scale. The value offered by cloud-service providers during this transition cannot be overstated, but there have also been tremendous advantages for the cloud-service providers themselves.

The efficiencies of scale that are distributed to customers are experienced to an even larger degree internally, allowing for these platforms to grow and expand at a rapid rate. With Crossplane, an open source framework for building cloud native control planes, customers can start to realize those efficiencies in their own internal platforms.

KubeCon + CloudNativeCon conferences gather adopters and technologists to further the education and advancement of cloud native computing. The vendor-neutral events feature domain experts and key maintainers behind popular projects like Kubernetes, Prometheus, Envoy, CoreDNS, containerd and more.

Learn More

The latest from KubeCon + CloudNativeCon

The Value of Foundation Services

Most cloud-service providers started out with a few core offerings in storage and compute. Amazon Web Services (AWS) famously began with just S3 before expanding into compute with EC2. These services have and continue to provide immense value to customers who previously would have had to invest a lot of time and money in both managing physical infrastructure and writing software. However, they also serve as a foundation for AWS to rapidly expand the catalog of services they offer.

The reason cloud-service providers are able to launch new services at an increasingly rapid rate is that the new services can be built on the capabilities of the existing infrastructure.

For example, AWS Lambda, a popular serverless platform, was launched at scale because it is built on top of the battle-tested compute offered by EC2. Furthermore, these new services are able to integrate with others offered by the cloud provider, such as databases and storage, and a common identity and access management (IAM) framework could be extended to support the new functionality. The result is a flywheel effect where, in aggregate, the cost of launching the next service diminishes over time.

When a cloud provider has robust compute, network, and storage capabilities at their fingertips, it becomes much easier to implement new services on top of those primitives.

While customers have benefited from this capability in the form of having new services made available to them, they have typically been unable to develop the same competency when building their own internal platforms. The impact is twofold:

• Customers are subject to the decisions of cloud providers when it comes to what new services are launched. Often these decisions are heavily influenced by the provider’s largest customers.
• Customers must take on the burden of onboarding and “productionizing” new services, which typically includes extensive testing, documentation and compliance review.

It is rare that an organization of reasonable size exposes raw cloud infrastructure to developers. Instead, they implement some layer of abstraction over the API in order to ensure that only infrastructure that meets internal policies can be provisioned. These policies may enforce certain security, reliability or cost requirements. For example, developers may only have the ability to provision some subset of EC2-instance types in order to avoid incurring high costs.

Unfortunately, every time a new cloud service is introduced into an organization, these policies have to be mapped to that service’s API. While the cloud provider may be offering new products by building on top of its own foundational services, every new service they expose to customers is a net new API to be onboarded in an organization.

This linear trend in overhead of onboarding the next service stands in stark contrast to the logarithmic curve that the cloud providers experience when launching the service.

When every new service offers its own API, the effort invested in vetting previous services does not reduce the effort required to vet the next one.

Ideally, doing the hard work of onboarding a service in an organization would be amortized over the subsequent services it enables. More and more organizations are moving to building internal platforms, rather than just consuming cloud-service primitives. This pattern creates a unique opportunity for these organizations to build their own foundational services, which can subsequently be used to build higher-level services in the future.

However, operating a platform is complex, and cloud providers have done a lot of work to build control planes that power theirs, presenting a single API surface and ensuring that services are resilient to failure. Replicating this amount of engineering effort in most organizations is not feasible. Fortunately, the Crossplane project has taken the capabilities of Kubernetes and constructed a framework that makes building control-plane-based platforms possible for anyone.

Defining Your Platform Foundation

When starting out on their internal platform journey, every organization must determine what APIs will serve as their foundation services. Countless factors could determine where to begin, including size of the company, complexity of the product, and culture of the engineering organization. Starting with a commonly used primitive, such as a database or containerized workload, is usually a safe bet.

In Crossplane, platform APIs are defined using Composition, which allows a platform team to define an API for developers to interact with, and one or more implementations of that API. For example, if developers frequently deploy applications packaged as OCI images, a platform team may define a ContainerizedWorkload API with parameters for an image reference and a set of environment variables.

An implementation of that API could be an AWS Lambda function, an ECS Task Definition or any other set of compute primitives. While these AWS services offer a wide array of customization options, only the parameters that a developer cares about are exposed in the internal platform, allowing the platform team to incorporate any organizational policies, such as tags or memory limits, behind the scenes.

An internal platform codifies policy, allowing organizations to take advantage of the value offered by cloud infrastructure while establishing guardrails for operations that developers are able to perform on their own.

Providing the initial implementations of the ContainerizedWorkload are high-touch activities that require understanding of the cloud-service APIs they rely on. In other words, this is the early part of the logarithmic curve, where there is still significant toil required to add a new API. However, your platform now has its first service that is fully compliant with organizational policy. You’ve defined a foundation service.

Growing with Confidence

In the early stages of building a platform, much of the work will involve building out additional foundation services. Perhaps developers also frequently need to provision databases, so a MySQLInstance API is defined and implemented. However, as the core set of foundation services are rounded out, the cost of adding the next service starts to decrease.

For example, with a workload and database API in place, a StatefulWorkload API can be added to the platform with minimal effort because it relies on foundation services that have organizational policy baked in. In other words: compliance composes.

Validation and compliance are transitive. If a higher-level API is built only on other compliant APIs, then it too is compliant.

Furthermore, implicit in this architecture is the propagation of platform changes and improvements from lower-level services to higher-level ones. New organizational mandates, for anything from SOC2 compliance to switching cloud providers, can be carried out at the foundation level but applied to all levels above.

Additionally, transitioning a higher-level API, such as StatefulWorkload, to rely on cloud services directly instead of internal platform APIs can be carried out at any time because the platform is built by stacking APIs, not by stacking implementations.

Your First Platform in 5 Minutes or Less

Defining a platform is inherently iterative, and Crossplane makes getting started on the journey easy. Grab a Kubernetes cluster from your favorite provider, install Crossplane and pick a QuickStart package to implement your first APIs!

The post Cloud Control Planes for All: Implement Internal Platforms with Crossplane appeared first on The New Stack.

WebAssembly (often shortened to Wasm) was built for the web browser. But oftentimes, a technology grows beyond the intentions of its creators. Wasm is an excellent example. And one place where Wasm shows promise is in the cloud. It is a fantastic platform for running serverless functions.

In this article, we’ll take a look at the design intent for Wasm, and how it improved the browser. Then we’ll see how Wasm made the leap to a generic technology.

Finally, we’ll take a look at a particular problem in the cloud — executing serverless functions — and see how Wasm can solve that problem.

Move Over Applets, Flash and Silverlight!

In 2015, Mozilla introduced the world to WebAssembly. In this blog post, Luke Wagner described WebAssembly this way:

“WebAssembly… defines a portable, size- and load-time-efficient format and execution model specifically designed to serve as a compilation target for the web.”

The goal was to build a binary format that could execute in every major web browser. The characteristics of that format enable many different languages, from C to Python, to run in the browser. Code is written in one of the supported languages, compiled to the Wasm format, and then executed in the browser. JavaScript code controls the execution of the Wasm, and can even interact with the Wasm by calling functions inside the Wasm library.

Pioneering the next wave of cloud computing. The Fermyon team hails from a fine tradition of open source development. We built CNCF projects like Helm, the package manager for Kubernetes and Brigade, the tool for scriptable tasks.

Learn More

The latest from Fermyon

This was not the first time something like this had been attempted. A few other languages have been added to (and later removed from) the browser. Java Applets were first. VBScript had a brief life in Microsoft browsers. Silverlight and Adobe Flash also came and went. But this time, the Mozilla folks had done a few things differently:

Instead of supporting a language, they defined a binary format that existing languages could compile to.

Instead of going it alone, Mozilla joined forces with Google, Microsoft, Apple and others. And they committed to doing the work under the auspices of the W3C.

Instead of focusing on augmenting the user interface (as Flash, Silverlight and Java had done), Wasm was focused on library usage and sharing code.

The use cases that the Wasm team sought to solve weren’t widgets and streaming players, but porting over code from other places to the browser. For example, consider that crufty old C library that has dutifully done some important job for years, but that everyone is afraid to touch for fear of breaking it. Could that be compiled to Wasm to enjoy new usage in the browser? Or consider that complex problem that demands highly efficient computing, like graphics processing. High-performance code might more easily be expressed in a language like Rust. Wasm allows developers to write code in the language a developer prefers, and then use it within the confines of the browser.

Outgrowing Intentions

Throughout computing history, we’ve invented technologies to solve a narrow problem, only to realize afterward that the tool has a broader application. The internet was built for the U.S. Defense Department’s communication. The web was for exchanging physics papers. Java was for embedded computing. JavaScript, now the world’s most popular language, was initially a “toy” language for popping up alerts in the browser. Each of those technologies jumped from a niche solution to a general-purpose tool.

Wasm is in that moment now.

It has been successful in the browser. But people are finding a variety of other uses for Wasm. From compiler toolchains to user-defined functions in a database, Wasm is popping up in some notable spaces.

• SingleStore uses Wasm for user-defined functions inside of their database.
• The Zig language folks recently announced they “annihilated” 80k lines of C++ code by using Wasm to self-host the compiler.
• Docker announced support for running Wasm inside of Docker Desktop, while Microsoft now supports running Wasm inside of Kubernetes clusters.

But there is one use case that I find particularly exciting. WebAssembly seems like an excellent fit for cloud computing. To understand why, let’s start by looking at one of the core technologies of today’s cloud: serverless functions.

Serverless Functions v1

Serverless functions, sometimes called Functions as a Service (FaaS), are intended to provide an easy way to create small cloud services. It’s easiest to understand a serverless function by contrasting it with a server. Web server software listens for HTTP requests on a socket, parses each request and then handles the requests. During a web server’s process lifetime, it may handle hundreds of thousands of separate HTTP requests. The typical HTTP server also must manage SSL connections, system processes, thread pooling and concurrency, and a variety of other lower-level tasks, all in service of answering HTTP requests.

A serverless function is designed to strip away as much of that “server-ness” as possible. Instead, the developer who writes a serverless function should be able to focus on just one thing: Respond to an HTTP request. There’s no networking, no SSL configuration, and no request thread pool management — all of that is handled by the platform. A serverless function starts up, answers one request and then shuts down.

This compact design not only reduces the amount of code we have to write, but it also reduces the operational complexity of running our serverless functions. We don’t have to keep our HTTP or SSL libraries up to date, because we don’t manage those things directly. The platform does. Everything from error handling to upgrades should be — and, in fact, is — easier.

Given this relentless focus on simplicity, it is no wonder that 4.2 million developers say they have written at least one serverless function. Amazon reports that they execute 10 trillion (yeah, that’s 10 trillion!) serverless functions a month.

As enticing as the programming paradigm is, though, the early iterations of serverless functions suffered from several drawbacks. They were slow to start. The experience of packaging a serverless function and deploying it was cumbersome. Debugging and troubleshooting were difficult. Yet the reason behind these problems is at once easy to understand and surprising.

This brilliant new idea of serverless functions was running on top of the wrong technology stack — lumbering virtual machines. Per-language runtimes and package managers. Cloud infrastructure built for a different class of computing was being repurposed for a technology that, in hindsight, it was ill-suited for.

It turns out that the technology we needed to bump serverless from good to great was living in the browser. We just needed to pluck Wasm from there and plant it in the cloud.

What Wasm Does for Serverless

If we are trying to improve the state of serverless functions, there are some high-priority bits that need improvement. We need the serverless environment to be blazingly fast, ultra secure, and we want it to hide as much of the “server” details as we can. That is, the second we have to start asking users to pick the operating system or the CPU type, we’re forcing the user into making server decisions, instead of serverless decisions. And when it comes to deploying serverless functions, smaller binaries in well-defined package formats make it much easier for us to do releases.

It is here that Wasm’s heritage makes it perfect for serverless functions. When we talk about Wasm as “built for the browser,” we are really talking about a few key features that make Wasm a good fit for the browser model:

• Fast startup time. Nobody wants to wait for a page to load.
• Cross-architecture, cross-operating system. Gone are the days when “Internet Explorer is required to view this page.”
• Compact binaries. When we’re moving our code across the internet, we don’t want to be sending big files.
• Secure sandbox. A browser runs untrusted code on a daily basis. We rely on the browser to protect us from both bugs and hackers.

Those four features just so happen to be desired traits for a serverless functions platform. We want zero-latency startup time. We don’t want to know or care about the architecture or operating system on which our function runs. (That’s the joy of serverless, right? We don’t have to care one iota about the server underneath!) We want our binaries to be compact so we can quickly package and upload them. And we want to know if it is safe to run our function in a multitenant cloud.

A serverless functions platform that runs on Wasm would make it easy to build a huge variety of applications, including highly responsive HTTP apps, and then deploy them with a high degree of confidence. This is exactly the use case we at Fermyon had in mind when we built the open source Spin framework.

Conclusion

Many of our go-to technologies started in a niche and grew into general-purpose tools. Wasm is going through such a transition now, as we find new applications beyond the Web browser. Serverless functions have enjoyed much success already. But to leap forward, the technology needs underpinnings that are faster and more robust. Wasm is just such a technology.

The post Serverless WebAssembly for Browser Developers appeared first on The New Stack.

Is incremental change a bad thing? The answer, as with most things in life, is “it depends.” In the world of technology specifically, the balance between innovation and tried-and-true concepts and solutions seems to have tipped in favor of the former. Or at least, that’s the impression the headlines give. Good thing there’s more to life than headlines.

Innovation does not happen overnight, and is not applied overnight either. In most creative endeavors, teams work relentlessly for long periods until they are ready to share their achievements with the world. Then they go back to their garage and keep working until the next milestone is achieved. If we were to peek in the garage intermittently, we’d probably call what we’d see most of the time “incremental change.”

The ScyllaDB team works with their garage doors up and are not necessarily after making headlines. They believe that incremental change is nothing to shun if it leads to steady progress. Compared to the release of ScyllaDB 5.0 at ScyllaDB Summit 2022, “incremental change” could be the theme of ScyllaDB Summit 2023 in February. But this is just the tip of the iceberg, as there’s more than meets the eye here.

I caught up with ScyllaDB CEO and co-founder Dor Laor to discuss this.

The ScyllaDB team works with their garage doors up. A look at what kept the team busy in 2022, plus trends and tradeoffs in high-performance compute and storage.

Note: In addition to reading the article, you can hear the complete conversation in this podcast:

Mini player:

Data Is Going to the Cloud in Real Time, and so Is ScyllaDB

The ScyllaDB team has their ears tuned to what their clients are doing with their data. What I noted in 2022 was that data is going to the cloud in real time, and so is ScyllaDB 5.0. Following up, I wondered whether those trends have kept pace with the way they manifested previously.

The answer, Laor confirmed, is simple: Absolutely yes. ScyllaDB Cloud, the company’s database-as-a-service, has been growing over 100% year over year in 2022. In just three years since its introduction in 2019, ScyllaDB Cloud is now the major source of revenue for ScyllaDB, exceeding 50%.

“Everybody needs to have the core database, but the service is the easiest and safest way to consume it. This theme is very strong not just with ScyllaDB, but also across the board with other databases and sometimes beyond databases with other types of infrastructure. It makes lots of sense,” Laor noted.

ScyllaDB is the database for data-intensive apps that require high throughput and low latency. It harnesses the ever-increasing computing power of modern infrastructures–eliminating barriers to scale as data grows. Game-changing companies use ScyllaDB for their toughest database challenges.

Learn More

The latest from ScyllaDB

Similarly, ScyllaDB’s support for real-time updates via its change data capture (CDC) feature is seeing lots of adoption. All CDC events go to a table that can be read like a regular table. Laor noted that this makes CDC easy to use, also in conjunction with the Kafka connector. Furthermore, CDC opens the door to another possibility: Using ScyllaDB not just as a database, but also as an alternative to Kafka.

“It’s not that ScyllaDB is a replacement for Kafka. But if you have a database plus Kafka stack, there are cases that instead of queuing stuff in Kafka and pushing them to the database, you can just also do the queuing within the database itself” Laor said.

This is not because Kafka is bad per se. The motivation here is to reduce the number of moving parts in the infrastructure. Palo Alto Networks did this and others are following suit too. Numberly is another example in which ScyllaDB was used to replace both Kafka and Redis.

High Performance and Seamless Migration

Numberly was one of the many use cases presented in ScyllaDB Summit 2023. Others included the likes of Discord, Epic Games, Optimizely, ShareChat and Strava. Browsing through those, two key themes emerge: High performance and migration.

Migration is a typical adoption path for ScyllaDB as Laor shared. Many users come to ScyllaDB from other databases in search of scalability. As ScyllaDB sees a lot of migrations, it offers support for two compatible APIs, one for Cassandra and one for DynamoDB. There are also several migration tools, such as Spark Migrator, scanning the source database and writing to the target database. CDC may also help there.

While each migration has its own intricacies, when organizations like Discord or ShareChat migrate to ScyllaDB, it’s all about scale. Discord migrated trillions of messages. ShareChat migrated dozens of services. Things can get complicated and users will make their own choices. Some users rewrite their stack without keeping API compatibility, or even rewrite parts of their codebase in another programming language like Go or Rust.

Epic Games, Optimizely and Strava all presented high-performance use cases. Epic Games are the creators of the Unreal game engine. Its evolution reflects the way that modern software has evolved. Back in the day, using the Unreal game engine was as simple as downloading a single binary file. Nowadays, everything is distributed. Epic Games works with game makers by providing a reference architecture and a recommended stack, and makers choose how to consume it. ScyllaDB is used as a distributed cache in this stack, providing fast access over objects stored in AWS S3.

A Sea of Storage, Raft and Serverless

ScyllaDB increasingly is being used as a cache. For Numberly, it happened because ScyllaDB does not need a cache, which made Redis obsolete. For Epic Games, the need was to add a fast-serving layer on top of S3.

S3 works great and is elastic and economic, but if your application has stringent latency requirements, then you need a cache, Laor pointed out. This is something a lot of people in the industry are aware of, including ScyllaDB engineering. As Laor shared, there is an ongoing R&D effort in ScyllaDB to use S3 for storage too. As he put it:

“S3 is a sea of extremely cheap storage, but it’s also slow. If you can marry the two, S3 and fast storage, then you manage to break the relationship between compute and storage. That gives you lots of benefits, from extreme flexibility to lower TCO.”

This is a key project that ScyllaDB’s R&D is working on these days, but not the only one.

In the upcoming open source version 5.2, ScyllaDB will have a consistent transactional schema operation based on Raft. In the next release, 5.3, transactional topology changes will also be supported. Metadata strong consistency is essential for sophisticated users who programmatically scale the cluster and Data Definition Language.

This paves the way toward changes in the way ScyllaDB shards data, making it more dynamic and leading to better load balancing.

Many of these efforts come together in the push toward serverless. A free trial based on serverless was made available at the ScyllaDB summit and will become generally available later this year.

P99, Rust and Beyond

Laor does not live in a ScyllaDB-only world. Being someone with a hypervisor and Linux Red Hat background, he appreciates the nuances of P99. P99 latency is the 99th latency percentile. This means 99% of requests will be faster than the given latency number, or that only 1% of the requests will be slower than your P99 latency.

P99 CONF is also the name of an event on all things performance, organized by the ScyllaDB team but certainly not limited to them. P99 CONF is for developers who obsess over P99 percentiles and high-performance, low-latency applications. It’s where developers can get down in the weeds, share their knowledge and focus on performance in real time.

Laor said that participants are encouraged to present databases, including competitors, as well as talk about operating systems development, programming languages, special libraries and more.

ScyllaDB’s original premise was to be a faster implementation of the Cassandra API, written in C++ as opposed to Java.

Although ScyllaDB has invested heavily in its C++ codebase and perfected it over time, Laor also gives Rust a lot of credit. So much, in fact, that he said it’s quite likely that if they were to start the implementation effort today, they would have done it using Rust. Not so much for performance reasons, but more for the ease of use. In addition, many ScyllaDB users like Discord and Numberly are moving to Rust.

Even though a codebase that has stood the test of time is not something any wise developer would want to get rid of, ScyllaDB is embracing Rust too. Rust is the language of choice for the new generation of ScyllaDB’s drivers. As Laor explained, going forward the core of ScyllaDB’s drivers will be written in Rust. From that, other language-specific versions will be derived. ScyllaDB is also embracing Go and Wasm for specific parts of its codebase.

To come full circle, there’s a lot of incremental change going on. Perhaps if the garage door wasn’t up, and we only got to look at the finished product in carefully orchestrated demos, those changes would stack up more impressions. Apparently, that’s not what matters more for Laor and ScyllaDB.

The post ScyllaDB’s Incremental Changes: Just the Tip of the Iceberg appeared first on The New Stack.

Event-driven architectures are reshaping the way information is shared between the services producing it and those consuming it. Systems idling and waiting for data are becoming more and more obsolete, as software architectures continue to transition from API-driven to event-driven, and as real-time event streaming continues to grow in popularity.

As companies, projects and infrastructure grow, so does the need for more multicloud, real-time data flows. Enterprises demand simpler workflows for DevOps engineers, real-time alerts when testing is complete, and tracking security logs between different Software as a Service (SaaS) applications.

All are necessary in today’s growing cloud native ecosystem, and without open source tools or the confinement of vendor lock-in, they’re tough to find.

TriggerMesh is an serverless event router with one simple main goal: to process events in real time and route them to the correct consumers. It’s a multi-purpose tool with an ever-growing list of use cases.

TriggerMesh’s open source integration platform provides users with a configuration-driven solution that will feel familiar to users of Infrastructure as Code (IaC) offerings like Ansible, Chef and Terraform. Built on top of Kubernetes, it includes a declarative API to quickly and programmatically connect data and services from multiple sources into event-driven applications.

Sources for message consumption include Amazon Web Services (AWS) SQS, Google Pub/Sub, Azure Event Hubs, and Kafka. TriggerMesh filters and transforms messages, combines processing capabilities with serverless functions, and connects them with messaging sinks linking Elasticsearch, AWS Simple Storage Service (S3), and Apache Kafka.

TriggerMesh connects to legacy service buses as well to create workflows between applications or data sinks to other systems such as Azure Data Lakes or Snowflake.

“Often people will use it to do things like trigger a function, or service, or … microservices,” Jonathan Michaux, product manager at TriggerMesh, told The New Stack.

TriggerMesh can also play a role in a larger streaming ecosystem, he added, such as providing “a function [for] processing events and pushing them to another system like Kafka for further processing to happen later on.”

For a quick comparison, think of Amazon’s EventBridge. Introduced in 2019, the event router allows developers to write rules that take action once an event occurs in Amazon’s S3 bucket.

TriggerMesh is the open source alternative, offering similar capability without vendor lock-in requirements. More recently, TriggerMesh introduced its latest open source offering, Shaker, which continues the push toward more widespread adoption of TriggerMesh. Shaker removes the Kubernetes requirement and provides the capability for TriggerMesh to run on Docker.

TriggerMesh is an open-source alternative to AWS EventBridge that captures, transforms, filters and reliably routes events across cloud services, on-prem, SaaS apps, messaging systems, and more. Runs natively on Kubernetes and also includes a powerful CLI for development.

Learn More

The latest from TriggerMesh

Open source doesn’t just offer freedom from vendor lock-in. It means TriggerMesh is completely cloud agnostic, allowing users to produce and consume between multiple clouds and on-prem data centers.

“Think about what this is and how powerful it could be if we could just take any application and connect it through events in such an easy way,” Michaux said. “You can deploy it anywhere you want on any Kubernetes cluster or on any machine that has Docker on OpenShift, on Amazon, on Azure, or Google.”

Michael Edenzon, co-founder of Fianu Labs, a software governance company, told The New Stack that TriggerMesh’s cloud agnosticism “absolutely moves the ball forward when it comes to making it easier for developers to build event-driven applications.”

Case Studies and Use Cases

How are real organizations using TriggerMesh in their event-driven architectures? Here are two examples.

ManoMano: Saving Costs on Running Microservices

ManoMano, a home-improvement marketplace based in Europe, is an e-commerce site that offers web and mobile experiences. Its many business needs require hundreds of microservices. With a codebase that large, it relies on diverse performance testing.

By adding TriggerMesh to its stack, ManoMano’s site reliability engineering (SRE) team now had the correct software tool to provide a serverless eventing experience that allows test developers to execute code when specific AWS events occur, by having the test developers subscribe to specific events.

More recently, ManoMano dove into its long-running microservices. Do they need to be long-running and always up? Does their usage justify the continuous consumption of compute resources and associated costs?

The answer was no, which drove the company’s desire to start running services on an as-needed basis only. The investigation revealed that many of these services only process a few requests per day, and most of their time is spent idling.

ManoMano replaced long-running idle tasks with containers scheduled on-demand to run EKS in reaction to AWS S3 events. This was made possible thanks to the new event-driven architecture, which gathers events from AWS services, ingests them into a centralized broker, and allows developers to subscribe to specific events for consumption. The platform abstracts security and infrastructure concerns away.

Fianu Labs: On-Prem Automated Software Governance

Fianu Labs’s fully automated, event-driven software governance tool provides instrumentation throughout the CI/CD process and captures events throughout the software development lifecycle and compares them against predefined policies and automated compliance documentation.

TriggerMesh, which sits on top of Google Kubernetes Engine with Knative, is a key part of Fianu’s architecture and is woven through the fabric of its workflow. Though not operating at huge scale, Fianu requires redundancy and reliability while supporting 200,000 code repositories, which roughly breaks down to 500 to 1,000 events per minute.

“The TriggerMesh tooling and the way that we’re using it allows us to keep a robust, event-driven system and keep it pretty neatly,” Edenzon, of Fianu Labs, told The New Stack.

An example of the typical TriggerMesh workflow inside Fianu starts with the ingestion of events. As events are ingested, Fianu uses TriggerMesh functions (Fianu uses embedded Python but TriggerMesh has Node.js and Ruby options as well) to make transformations and computations on the payloads.

Edenzon discussed the example of changing strings to floats to ensure the incoming data is consistent with policy. While there may be one incoming source of data, a number of different outputs could be needed and TriggerMesh functions abstract away the need to create core tooling.

“Without creating a serverless function, we can embed the TriggerMesh functions to perform small bits of business logic along the way,” he said.

TriggerMesh Targets was another aspect of the TriggerMesh functionality that Endezon pointed out. Targets allow Fianu’s customers to build customizations on top of the Fianu software as it aids with complicated event destinations, by abstracting away the complexity for events going to a Kafka stream or to slack.

TriggerMesh doesn’t only help Fianu developers, it also helps the company’s customers. Fianu provides a lot of out-of-the-box capabilities to its end users, and while the company isn’t offering specific TriggerMesh tooling but because of TriggerMesh’s high level of abstraction, customers can write custom plugins as Knative functions in any language and snap them into the running instance, because TriggerMesh treats them as just another event processor.

“As developers, if we were only ever required to just focus on the business functionality, we’d be extremely productive,” Edenzon said. “So that’s one of the things that we like about [TriggerMesh]. It makes it very easy for us to isolate and test business functionality.”

Embedded into SaaS Apps

TriggerMesh makes it possible for SaaS applications to ingest events from multiple cloud providers, transform the events to match specific schemas, and then send those events to any destination.

“TriggerMesh makes it very easy to ingest new event sources into an application,” Michaux said. He added that “B2B SaaS vendors can extend their app’s ecosystem, while keeping development teams focused on the core product.”

In cybersecurity, this means the transformation of different cloud security events into standardized schemas, such as the recently announced Open Cybersecurity Schema Framework, before sending them to the customer’s preferred security solution for analytics and threat detection.

The value for the security community is incredibly high. Since security threats happen in real time, the value isn’t only in having a collection of data or integrating applications, it’s about processing events as they occur.

“A typical example would be someone making a failed login attempt into a system, for example a cloud provider like Oracle or AWS,” Michaux said. “That’s an event that a threat detection system would be interested in analyzing. TriggerMesh can help ingest the event and deliver it to the security system, in real time, in the right format, with minimal fuss.”

Conclusion

TriggerMesh is an example of a use case meeting demand and allowing demand to speed up to interact with the technology. It’s open source, with the only requirement now being Docker with the newly released Shaker making adoption even more available.

“When using TriggerMesh to its fullest, with the right application design, it allows you to isolate the business functionality without having to worry about the mechanics of how data goes where,” Edenzon said. “So you can just focus on the business functionality”.

The post TriggerMesh: Open Sourcing Event-Driven Applications appeared first on The New Stack.

Figma, Google Docs, Miro — these applications have spoiled end users with real time, collaborative capabilities. Now end users, stinkers that they are, want the same capabilities from other web apps.

Real-time company Ably wants to help developers fill that gap. Last week, the UK-based platform-as-a-service company launched a pre-built Next.js starter kit on Vercel’s Templates Marketplace that provides real-time functionality, including live collaboration. Ably also offers a similar tool on Netlify.

“You see those avatar stacks on so many sites nowadays,” Tim Buntel, Ably’s chief product officer, told The New Stack. “Users don’t want to have to hit refresh on a web page to see real-time updates to data that they might see in a web application.”

Real time is one of the two big trends in application development today, according to Buntel. The other is the ability of platforms such as Vercel and Netlify to really change the way that developers deliver content.

“We also see customers expecting that real time and multiplayer experiences are no longer a niche feature that you would have in Google Docs, or Miro only, but people want to start to see that in all kinds of different applications,” Buntel said. “So that’s really what this announcement was about, is recognizing that growth of these new platforms to change the way developers can get value to their customers and then allowing them to bring the types of experiences that their customers really want in those applications.”

Real-Time Use Cases for Frontend Developers

Ably offers APIs and SDKs to add real-time capabilities to web and mobile applications. The startup kit, in addition to supporting multiplayer experiences and chat, supports data synchronization between the frontend and backends. A use case might be real-time monitoring of how many items remain in stock as customers make purchases from the website, and updating that automatically. It also supports data broadcasting, where large numbers of users would be interested in simultaneously receiving the same data, such as an announcement or a sports score. Another popular use case for real time is enabling push notifications, particularly when it involves real-time location data, such as alerting customers that a delivery is arriving.

“If I was just one developer by myself, I don’t know anything about real-time, but if I’m using Vercel to build my website, I could easily now add something like cursor tracking or live data updates or chat to my application without having that expertise myself,” Buntel said. “Those sorts of multiplayer experiences or live chat, or data synchronization, really anything where a number of clients need to be connected in real time, through our APIs and SDKs developers can add that range of different types of capabilities to their app.”

One-Click and an API to Real Time

The startup kit provides developers with the ability to connect into Ably’s platform and makes it easy to manage the state of users and the underlying complexity of real time, he said. The template includes a gallery that developers can pursue and connect with the capability through a single click, he said. The starter kit then walks developers through getting an API key from Ably. With Netlify, Ably works in a similar way in that developers can select the Ably plugin from Netlify’s Integrations Hub and the real-time functionality will be dropped into the application, he explained.

“If you think about those real-time experiences they all take advantage of the same underlying infrastructure,” he explained. “So it’s creating a WebSocket connection, a persistent connection between the client and the service to maintain state between those clients. All of that complexity that typically you’d need an understanding of distributed systems or real-time architecture to do. We handle that complexity so the developer can just start delivering those experiences right away.”

Ably is also a serverless platform, so it manages the scaling challenges of operating a real-time infrastructure globally, Buntel said. With the Vercel starter kit, Vercel provides the workflow and the hosting platform for an app, while Ably provides the connectivity to make the real-time pieces possible.

“Vercel and Ably are both serverless, so developers aren’t maintaining their own servers or backend infrastructure,” he told The New Stack. “Vercel will allow you to host the client side of the application and generate and host the client side of the application, and then from within that client application, [it] can connect to Ably to coordinate the real-time components of that application.”

The company published a step-by-step tutorial explaining how to build a real-time chat app with Ably and Next. Js. Ably also offer a free tier that allows developers to try out functionality before moving to a paid tier. It also announced the release of its Ably Terraform Provider, which enables developers to manage their Ably infrastructure as code.

“For a developer who doesn’t want to think about the complexity of deploying software, a platform like Vercel is great (or Netlify), because they remove any of the complexity of spinning up servers and deploying infrastructure,” Buntel said. “However, for a lot of larger companies, they want to maintain the control over that complex infrastructure themselves. TerraForm is one of the tools that is most commonly done for that.”

The post Ably Touts Real-Time Starter Kits for Vercel and Netlify appeared first on The New Stack.

Serverless computing allows developers to build and run applications without worrying about infrastructures. Serverless computing services eliminate infrastructure management tasks like capacity provisioning and patching, and offer automatic scalability, high availability and a granular pay-for-use billing model.

Amazon Web Services (AWS) Lambda is a popular event-driven serverless computing platform that allows users to run code without the need to manage infrastructure. Within Lambda, code is stored in a code deployment package. All interaction with the code occurs through the Lambda API (application programming interfaces) and there is no direct invocation of functions from outside of the service. Lambda functions have many use cases, but the main one is to respond to and process events. While it is popular among the DevOps community for the many benefits it offers, it comes with a spectrum of security risks that are too often neglected.

Image source: https://aws.amazon.com/lambda/

Why Consider Security When Using AWS Lambda?

Security is a key consideration when using AWS Lambda for three primary reasons.

1. AWS Lambda functions are used to build applications: AWS Lambda provides a highly reliable service, allowing users to deploy serverless applications with confidence. Lambda is suitable for mission critical applications in many industries. A broad variety of customers, from media, retail, and consumer services to banking and financial services and other regulated industries, take advantage of Lambda. The managed runtime environment model enables Lambda to manage much of the implementation complexity of running serverless workloads. A security incident that compromises your Lambda functions can result in widespread disruption to several mission-critical aspects of your business.
2. AWS Lambda functions process sensitive data: Sensitive data includes personal identifiable information (PII) such as customer names, social security numbers, driver’s license numbers, financial information and medical records that can identify an individual. If this data were to be accessed or modified by an unauthorized party, it could result in serious harm to individuals and your business.
3. AWS uses a shared responsibility model for security: Security and compliance is a shared responsibility between AWS and the customer. What this means is that Amazon Web Services (AWS) owns “security of the cloud” and handles protecting the infrastructure that runs all the services offered in the AWS Cloud. On the other hand, “security in the cloud” is always customer’s responsibility. As an example, for abstracted services, such as Amazon S3 and Amazon DynamoDB, AWS runs the infrastructure layer, the operating system, and platforms, and customers access the endpoints to store and retrieve data while customers handle managing their data (including encryption options), classifying their assets and using identity and access management (IAM) tools to apply the right permissions. When it comes to Lambda, the data integrity and confidentiality is the responsibility of the AWS customer. Therefore, AWS and its customers have a shared responsibility to ensure the continuous security of Lambda implementations, ensuring that they are protected from potential security threats.

Panoptica provides a comprehensive security solution for the entire software development lifecycle (SDLC)—from development to runtime. It simplifies the task of securing your cloud-native application development lifecycle—from build pipelines to workload runtimes in one or more clouds.

Learn More

The latest from Panoptica by Cisco

What Security Risks Could Be at Work Here?

Let’s examine some security risks that your unsecured Lambda functions could be exposed to:

Authentication and Access Control

An application built using serverless functions contains numerous AWS Lambda functions. Each programmatic function is distinct and serves a specific purpose. When spliced together and orchestrated, the functions create the overall business logic where the configuration and management of servers are invisible to the end user. Some functions collect, store and dynamically display real-time data, while other functions connect payment and API gateways to automate transactions.

Additionally, some functions “consume events” or subscribe to an event that triggers your functions to run. An event triggering a Lambda function could be almost anything, from an HTTP request through API Gateway, a schedule managed by an EventBridge rule, an IoT (Internet of Things) event or an S3 event.

In other words, when using AWS as your cloud provider, an “event” is any occurrence in AWS that triggers a Lambda function, like an S3 bucket upload, an SNS topic or HTTP endpoints created via API Gateway. You can imagine the security complexity arising from each function having different expected outcomes, triggered from a different event and with no notion of the other moving parts.

Broken authentication in serverless architectures results from poor application of identity and access controls management especially with multiple services, events, triggers and no continuous flow.

Any unauthenticated and unauthorized access to functions can break the system’s business logic and flow of execution. Applying rigorous AuthN+AuthZ schemes that provide robust access controls to every function, event types and triggers must be managed carefully to close the door on the possibility of a security breach.

Function Event-Data Injection

On AWS, Lambda functions must be connected to events from several sources that trigger their execution. The overabundance of event sources expands the attack surface. Securing Lambda functions from event-data injections then becomes a complex task. The type of event and its source determines whether the event input is controlled by an attacker. Some types of event data are resistant to corruption by an attacker.

For example, standard notifications of database events. But others such as HTTP/S API calls are much more vulnerable to being hijacked for malicious purposes. A few common types of injection flaws in serverless architectures are operating system (OS) command injection, function runtime code injection (Node.js/JavaScript, Python, Java, C#, Golang), SQL injection, NoSQL injection and Pub/Sub message data tampering (MQTT data injection).

Identity Access Management 

For Lambda functions, AWS manages the underlying infrastructure and application platform, the operating system, and the execution environment. The DevOps team handles continuous security in the SDLC (software development life cycle), starting from code security, as well as identity and access management to the Lambda service and within their serverless functions.

As a rule of thumb, granting permissions and access should follow the “principle of least privilege,” which essentially means that the Lambda functions should only be assigned those privileges that are essential to performing their intended logic.

In a real-world scenario, this is easier said than done. For example, if you need to write an IAM policy for a Lambda function that needs access to the DynamoDB service, you need to work through over 50 different DynamoDB permissions and give least-privilege access to exactly those sets of permissions that the Lambda function would need to execute on its intended logic and nothing else. You must also work through the condition keys that allow granting of access under certain conditions.

Now consider another very realistic scenario where your serverless application is made up of dozens, if not hundreds, of different Lambda functions. The sheer number makes managing function permissions and roles a daunting task. If you lean on a single permission model or security role for all Lambda functions, you will inadvertently grant all functions full access, thereby creating a security risk.

Another issue to note is the possibility of an IAM credential leak due to an IAM policy misconfiguration. Lambda functions use temporary security credentials when they are granted an IAM role. When the function executes, it receives access tokens from the AWS security token service. An attacker who maliciously gains access to the tokens can remotely impersonate the function from outside the Lambda environment and retrieve any resources available to it.

Logging and Monitoring

Serverless monitoring allows developers to gain important insights on each execution and event. AWS provides the logging service CloudTrail and the monitoring service CloudWatch. AWS CloudTrail is enabled by default on every AWS account once the account is created. When a supported event activity occurs in AWS Lambda, that activity is stored in a CloudTrail event, along with other AWS service events in the “Event History” console.

Lambda automatically monitors the functions on your behalf and reports metrics through Amazon CloudWatch. From a security standpoint, it’s critical to log and monitor security related events to detect and mitigate risks in real time. While it’s true that both tools are extremely valuable, for some developers the tools’ out-of-the-box configurations aren’t always conducive in capturing the entire security event audit trail that is bespoke to your application.

Ensuring Security Is a Shared Responsibility

AWS provides a robust set of security controls for its users. But it is up to the users to make the most of these built-in capabilities. The AWS Lambda console helps secure your Lambda functions by allowing you to view and manage your Lambda functions, including their configuration files and IAM roles. However, to eliminate the possibility of inheriting vulnerabilities in your Lambda functions, it’s important to ensure that only verified code from trusted publishers is deployed within Amazon Lambda and vulnerable functions are weeded out. These are key to a safer deployment.

Panoptica Secures AWS Lambda Serverless Functions

It’s evident that AWS Lambda is undoubtedly at the heart of serverless applications. The “stateless” nature of Lambda functions, with no affinity to the underlying infrastructure, allows you to focus solely on what you love doing most — developing code.

Cisco Panoptica scans serverless functions in AWS accounts and evaluates them for security issues and vulnerabilities. After connecting it to your AWS account, Panoptica scans your serverless functions for security issues and vulnerabilities and assigns them a risk score, ranking them based on the score. The risk scoring is based on the function’s code and the cloud configuration metadata and takes the following into account:

• Authentication and authorization of functions, verifying identified and authorized function triggers.
• Code vulnerabilities in open source packages or dependencies.
• The presence of secrets, such as keys and passwords, in the function’s code or environment variables.
• Inappropriate or excessive permissions granted to functions.
• Functions with public-access exposure and access to data sources that might be targets for exfiltration.
• Dead or inactive functions.

You can manually trigger a scan at any time, or you can schedule scans to be run at regular intervals. What else? Configure the policies, customizing the types of risks that apply to your environment. If Panoptica’s risk score rises to an unacceptable level, you can set it to kill the process and alert you — letting you know exactly which serverless function triggered the alert.

For signing and verification of core cloud function artifacts, such as images or code, use our open source tool FunctionClarity. Its code-signing capabilities ensure the trust and integrity of your functions, allowing for tamper proofing and nonrepudiation.

Try Panoptica for free and refer to this quick-start guide to instantly connect Panoptica to your AWS cloud account.

The post Going Serverless on AWS Lambda? Recognize Potential Risks  appeared first on The New Stack.

Kubernetes makes sense at the edge if deployed with the right tooling.

At last week’s Civo Navigate conference, Portainer demoed how it simplifies edge Kubernetes deployments, using what it touts as a universal container management tool. Basically, it can work with both Docker and Kubernetes to make the deployment and management of containerized apps and services easier, Jack Wallen said in his assessment last year.

Kubernetes makes sense at the edge, Portainer co-founder Neil Cresswell told Civo audiences.

“One of the major benefits with Kubernetes is that really we have a recipe or a means to declare how we want our application to run and that’s the manifest,” Cresswell said. “The manifest really is a game changer. And in my career, it’s the first time I’ve ever seen a way that you have a way to basically declare how your application runs, and it runs that way everywhere.”

While it can be overwhelming, the manifest makes sense once you’ve wrapped your head around how it works — that it’s infinitely reproducible, he explained.

“No matter where you run the manifests it’ll pretty much run the same way every single time,” he said, adding Portainer ships its product as a Kubernetes manifest. Using Portainer to run a manifest means it will run in seconds and in very predictable ways, and it will deploy the same way, he said.

For the purposes of the demo, Cresswell defined the edge as the network’s edge.

“When we say network edge what we’re talking about here is putting applications closer to users,” he said. “We do this to try to reduce network latency and reduce bandwidth. But the whole thing there is to say how do I get an application close to my user so they get a snappy responsive application experience and I pay less for bandwidth between my user and the backend system.”

He gave an example of why this matters today more than ever — he has a bank app that, when he travels to the U.S., experiences excess latency issues because it’s trying to hit the backend of his bank in New Zealand.

“Whenever I am here [the U.S], my internet banking application is completely unusable because it is trying to do API requests — 1000s of them — to a backend server in New Zealand,” he said. “That latency just breaks the application. So by being able to have API endpoints closer to your users, you get a much faster application experience.”

Stateless Services and Kubernetes

The edge relies on stateless services and the Kubernetes working group has done a really good job helping to transition it to more stateful services, but predominantly Kubernetes is built around stateless, and edge applications are also predominantly stateless.

“They’re designed for ingesting and tuning and buffering and caching. They’re not designed really to hold data,” he said. “So Kubernetes is a stateless orchestrator and edge — stateless workloads — really are a perfect match. It just makes sense.”

Moving applications to edge makes it possible to reduce bandwidth between users and the backend; reduce latency overall; provide a faster app experience; and support data separation.

That said, there are challenges to deploying Kubernetes at the edge, he said. While certified Kubernetes distributions use a standardized API, a lot of providers want to add value to the native Kubernetes API, which leads to lock-in. That’s why it’s important to be careful about things like authentication and load balancing, he added, which can lock developers into a particular buyer.

Cresswell showed a diagram of providers, noting that Civo, Linode and Digital Ocean all provide the raw Kubernetes without adding aspects that will lock you in. Azure and Google also offer raw environments, though they do provide some value add but are generally quite compliant, he said. Other providers may make it more difficult, he added, to “have a fully transformed work location.”

Multiple Cluster Kubernetes Management

The Kubernetes management challenge comes in when you’re deploying multiple clusters rather than a single cluster, Cresswell said.

“When you get to three, four, 10 clusters, things start a little harder,” he said. “When you’re talking edge, though, you really are talking standard and you really have to change the way you think about how I manage this.”

Among the issues to consider are:

• How do you manage the clusters centrally?
• How do you perform authentication centrally?
• How will users automatically get propagated to backend clusters?
• How do you define back roles somewhere centrally and have those propagate?

There are three main features developers need, he said:

1. Centralized access;
2. Access control with monitoring dashboards; and
3. Centralized deployments.

“You really have to have all of those,” he said, and you have to do it at scale. While it’s possible to go cluster-by-cluster, you still have to think about user authentication.
“You really do have to say, ‘I want to have a single API endpoint that every developer or consumer can connect to, and their proxies, to a backend,” Cresswell said. “This is how you manage things at scale. And the same thing with dashboards.”

One Dashboard to Manage the Edge

Cresswell said that everyone thinks they can install Prometheus or Grafana and have a monitoring dashboard — but you don’t want to have 47 different dashboards open.

“You want to try and get a macro global view of where the clusters are. You can do that with Prometheus and Grafana, but you have to architect it that way,” he said. “You can’t just don’t install it in each cluster. Yes, you have to install the edge, the Prometheus edge agents, and send the streams back to a central Prometheus instance. You have to configure things correctly. So you have to think differently. And bulk deployments is actually quite complicated.”

GitOps will help but it won’t get you there all the way, he added, specifically pointing to a Chik-fil-A rollout of a couple 1000 clusters where they started using GitOps and “found out very early on that you can’t just deploy GitOps and pray that it’s going to update,” he said. “You actually have to have some centralized dashboard to see the current status of all these deployments.”

Portainer faced the same challenge, he said, and has added tooling to manage these clusters, along with identity management and access management, from a centralized dashboard, Cresswell said.

“Portainer has a high level of abstraction; we try and make things really easy,” he said “We try to be the one tool you need to manage Kubernetes… So full Kubernetes API proxy, multicluster management, centralized identity management, and dashboards, monitoring everything you need to basically go live with Kubernetes in production at scale.”

Cresswell and Adolfo Delorenzo, Portainer’s IT sales and business development executive, demoed how Portainer could manage the edge from one dashboard by broadcasting a live stream of the audience into three different locations supported by Civo — London, New York and Frankfurt — in about two minutes.

“We have customers who’ve got upwards of 50,000 environments. We have a customer who need us to stand us up 125,000 clusters by the end of this year,” Cresswell said.

Civo paid for Loraine Lawson’s travel and accommodations to attend the conference.

The post Portainer Shows How to Manage Kubernetes at the Edge appeared first on The New Stack.

When selecting serverless and Lambda as the preferred architecture for your cloud operations, you need to understand the inherent limitations in order to scale once your application and product code start to grow in size and complexity.

Serverless is a good choice to get ramped up quickly when building your application code, but there is a common misconception that serverless means DevOpsLESS or NoOps, and this simply is not the case.

What’s more, sometimes you have to really invest in design and architecture in advance to not hit a wall later or incur a lot of technical debt. In this post we’ll provide an overview of some of the limitations we encountered when building Jit, a software-as-a-service DevSecOps platform, based on serverless and event-based architecture.

A Quick Overview of the Serverless Gotchas

When your applications start to grow there are challenges unique to the serverless paradigm that are quickly encountered if you don’t plan for them in advance. We’d like to help those exploring serverless be aware of what they need to design their applications for, before they even get started (or possibly quickly rework, if they already have).

Throttling

Lambda throttling happens as a result of the number of instances you can run simultaneously. (This post explains how to overcome that).

AWS Lambda limits this to 1,000 by default (you can request to increase this threshold, but you need to be aware that it exists in the first place). However do note that this has cost implications, so you shouldn’t automatically increase your threshold before examining the design of your architecture and ensuring you truly need this.

This means that the more events or services you run simultaneously, the more rapidly you will hit a wall. This is something that you need to think about as early as the first line of code if you plan to run entirely on serverless architecture.

While your design might work today at a small scale, you have to think very early on if this will linearly scale.

Remember, this limitation’s purpose is to protect you as well as AWS from mistakes or bad design. For instance, imagine a case where somehow a Lambda calls itself in a loop. Without this built-in protection mechanism, you could reach millions of invocations.

While your design might work today at a small scale, you have to think very early on if this will linearly scale when you have thousands of tenants or customers (or more). Depending on how you architect your resources, Lambdas and microservices (and how “micro” each service is), if you break down your services into too small chunks, you may end up breaking your entire service chain flow due to throttling from too many parallel events.

Jit is a self-serve DevSecOps orchestration platform that makes it easy for high-velocity engineering teams, of any size, to achieve continuous security & compliance while increasing dev velocity. Jit implements security-as-code and offers remediation recipes with a Dev-native experience. Jit and TNS are under common control.

Learn More

The latest from Jit

This means you need to be well aware of how much traffic you are currently handling, in the form of events per minute, and even spikes and outlier traffic that your services handle. All this needs to be considered in addition to the communication invocation method employed for each — sync or async (we dig into this more deeply later) — where with synchronous invocation each service or system call adds up and can overload the system.

It’s important to be aware that the way throttling works isn’t exactly predictable. So even if you have the monitoring in place to ensure you don’t reach 1,000 parallel events, and you think you’re covered, this may actually happen with your first spike where throttling may happen at an even lower threshold, as this is essentially unexpected behavior (but documented in the AWS docs). So a good practice is to architect your systems in a way to be able to recover when that happens (such as idempotency and retries).

Timeouts

As its name implies, serverless does not run on servers that run forever, they provide ephemeral runtime that has at best a 15-minute total window for function runtime. This can affect the size of the input your service can handle. When you design your functions from the get-go, and the size of the input continuously increases along with the processing time, you can encounter timeouts during runtime.

Therefore, a recommended design pattern for services or functions with a runtime that linearly scales with the size of your input is to split the input into chunks or batches and handle them in different Lambdas. It is also a good practice to use queues, when doing so, to avoid throttling.

Event Size

The event-driven design pattern, popular in serverless-based systems, many times requires a diversity of services in the chain for event handling, including an API gateway, SQS (Amazon Simple Queue Service ), event bridge, SNS (Amazon’s pub/sub service), where each of these has different event size limits. Each resource you use may have different size limits you need to be aware of, where passing data along the chain may break when sending a large payload.

Each of these resources in the chain is capable of processing different-sized payloads, and this means that you will have failed events if you don’t take this into account in advance.

This means you can’t send limitless payloads between resources and need to be aware of this when building your functions and services. Each of these resources in the chain is capable of processing different-sized payloads, which means that you will have failed events if you don’t take this into account in advance, and ensure this payload can be received across your system services and resources.

One solution, essentially a workaround, can be to pass large payloads through an S3 bucket by leveraging a different resource that does support the payload size. [Pro tip: Search for “AWS service quotas” to learn more about resources you use. This is a good reference to get started.]

Idempotence

Due to all the challenges and reasons outlined above, and because failure will always happen, latency happens. Lambdas and serverless resources are often built on retry mechanisms. This is where idempotence is critical. Services need to deliver the same result for a given input, no matter how many times they are retried or partially retried (that means that even if just a part of the flow is retried, the result still needs to be the same).

You need to design for idempotence in advance so that retries and replays do not affect the state of your production systems. A good practice is to ensure that when you run data, you create unique, yet not random, and deterministic IDs for each instance. This is a good guide for doing this right.

Memory Leaks

To understand how memory leaks happen, you first need to understand how the mechanism that runs your code works, because it too has its limitations. When it comes to Lambda functions, the same Lambda runner is reused again and again until it dies. Perhaps it runs 1,000 times perfectly, but it can start to break down on the 1,001st run and can cause issues with your services.

For example, take Python code with the same interpreter that is used again and again. If this code adds global memory objects with each run that may be passed through different instances of runs, this can lead to memory leaks, where you exceed instance memory limits. And then your Lambda will crash.

This is particularly important when using shared resources and with multitenancy architecture. You need to ensure that you don’t leave behind unused resources, sensitive data or essentially other garbage. When it comes to tenant isolation, if you’re using shared memory, you need to be very careful that data does not leak between instances, because then data can leak between tenants. We shared in a post about tenant isolation on the data layer, but this is equally true for the runtime.

Sync vs. Async Invocation

Synchronous invocation in serverless can lead to many issues (some of which are noted above, like throttling). When possible, and immediate responses are not required, the asynchronous invocation pattern is by far preferred with serverless.

Serverless generally was designed to be more asynchronous and stateless than synchronous and stateful, so it is always best to play to the technology’s strength. When you do require synchronous invocation, make sure to have the right guardrails in place like using an API gateway and have visibility through proper logging.

Guardrails for Cost and Fault Tolerance

That was a mouthful, and probably daunting for those exploring serverless as your infrastructure of choice. That said, serverless is extremely powerful, scalable and flexible, and with the right guardrails in place you can avoid these issues almost entirely.

Another common concern when it comes to running on serverless is, of course, cost, and this should not be ignored. The way you design and architect your applications will have direct cost implications as well. You need to have the proper mechanisms in place to not overly exceed resources starting with billing alerts and generally cost-aware system design, which is an extremely important practice with serverless.

The way you design and architect your applications will have direct cost implications as well.

Other areas that are a full blog post unto themselves are monitoring and testing of serverless applications. It is indeed critical to have the right monitoring, observability, logging and tracing in place to ensure that when you do write an application that is composed of 50 Lambdas, you can test that the flow is properly working and continues working correctly during runtime in production.

This is particularly true when production means 10,000 tenants. An added advantage to being aware of how serverless architecture works under the hood, by following the guidelines suggested here, you will achieve significant cost improvements, as a byproduct, alongside better system design.

Designing for Resilience and Robustness with Serverless Applications

Serverless is an excellent choice for those looking to run fast, focus on delivery and roll out products and features without too much management and overhead of infrastructure. When choosing to run serverless, you need to bear in mind that this means using a number of different AWS resources, and it’s critical to understand how each works independently as well as together, alongside their limitations and flaws.

In our next post, we will dive into additional recommended serverless design patterns including tenant isolation, connection pools for databases, and least privilege, alongside how to avoid antipatterns like tenant starvation, infinite loops, inefficient invocations, and overly large CPU and RAM instances.

Remember, like all cloud native applications in the unpredictable and dynamic cloud landscape, ensuring you have the proper visibility into the way your applications are working through monitoring and logging is especially important with serverless applications.

It is also essential to ensure security, as well as data privacy, to not compromise critical data when using shared resources and multitenancy. There are excellent DevSecOps tools that can help you do so. When you understand how your technologies work under the hood, you can optimize your design, architecture and application code for better performance, safety and fault tolerance.

The post Serverless Doesn’t Mean DevOpsLess or NoOps appeared first on The New Stack.

As 2023 gets into high gear in the coming months, the cloud native ecosystem is set to reinforce its core business value across enterprises to become even more mission critical to the digital economy. By contrast, embedding security into the DevOps methodology is still evolving, leaving specific predictions about the future of DevOps engineering open to question.

However, in our opinion, a few trends are more than likely to shape the cloud native security landscape in the coming year:

1. Cloud Native Security: Forrester expects more enterprises to adopt cloud native technologies as they increasingly opt to run workloads in containers rather than legacy virtual machines. As such, 40% of organizations will take a “cloud native first” strategy in 2023, as they look to increase agility and efficiency while reducing costs, but security will continue to be a major concern.

As more organizations adopt container and Kubernetes technologies, there will be a corresponding growth in the development of tools and practices for securing these environments, prompting DevOps to respond more thoughtfully to security.

Threat actors will unleash iterations of malware designed to break cloud native environments. Developers will feel a greater need to incorporate security earlier in their application development cycle. And therefore, as 2023 unfolds, the industry will see DevOps increasingly evolving into DevSecOps. New security standards will solidify into actionable best practices, greater adoption of cloud native security tools and increased focus on zero trust as a security principle.

Panoptica provides a comprehensive security solution for the entire software development lifecycle (SDLC)—from development to runtime. It simplifies the task of securing your cloud-native application development lifecycle—from build pipelines to workload runtimes in one or more clouds.

Learn More

The latest from Panoptica by Cisco

2. Containers and Kubernetes Security: Securing containerized applications and Kubernetes will be a priority this year due to adoption going mainstream. There will be a greater focus on integrating Kubernetes security with broader cloud security frameworks, including integrations with cloud-based identity and access management systems and cloud-based security event and incident management systems. Securing the Kubernetes control plane is critical to the overall security of the cluster, and it will become an increasingly important focus for Kubernetes security practitioners. Policy-as-code for Kubernetes is expected to mature and gain greater traction. This year, dozens of leading organizations will embrace Open Policy Agent (OPA) in their Kubernetes deployments. We also believe thatDevSecOps will welcome observability solutions in the cloud native security marketplace. These solutions pull data from events, logs, telemetry and traces together into a comprehensive yet aggregated view from which to quickly figure out troubleshooting issues in Kubernetes.

3. Serverless Computing and Security: Serverless computing is relatively new to the cloud native landscape. Despite its ability for adaptation and integration, it lacks standardization and interoperability. The resulting risk of vendor lock-in has left many enterprises stalled in their adoption journey even as serverless computing continues to pique the interest of developers for event-based workloads. To bridge the gap and broaden adoption across vendor-agnostic functions, we will witness disruption in this space with the Google-sponsored Knative project. The open source, enterprise-level Knative framework will ensure standards are shared across different serverless Function as a Service (FaaS) implementations, thereby raising the bar on interoperability. Another disruption to serverless is an emerging concept called “infrastructure-from-code” (IfC) as a way of creating applications that allow your cloud provider to inspect the application code during deployment, then automatically provision the underlying infrastructure the application code needs.

Further, as the complexity of serverless environments increases, automating security policy enforcement and leaning on AI/ML techniques to improve the accuracy and efficiency of SecOps will take precedence. Expect to see an increased emphasis on securing the function code and runtime environment with measures such as code signing and verification along with hardening runtime environments to prevent malicious code injection.

4. API Security: Gartner predicts that this year over 50% of business-to-business transactions will be performed through real-time APIs. By 2025, less than 50% of enterprise APIs will be managed, with the growth in APIs surpassing the capabilities of API management tools. While REST- and HTTP-based services remain the most popular API architecture styles, use of them will continue to level off as this year progresses as newer event-driven API architectures such as GraphQL and gRPC are growing in popularity.

That said, the ubiquity of APIs will exacerbate sprawl issues this year. The sprawl of APIs within and between cloud native infrastructures has made API security one of the biggest challenges for DevOps today. This also means that unmanaged APIs will become a popular target for cybercriminals who can use them as gateways to gain unfettered access to sensitive data. In pursuit of this data, cybercriminals will put more focus on vulnerable API endpoints that connect directly to an organization’s underlying databases. Expect to hear more about damaging attacks on individual APIs that lead to data leakage.

When it comes to the banking and financial services industry, we would be remiss to not overemphasize that API security should be their single most important cybersecurity priority this year. Newly minted APIs will continue to overrun modern banking apps, causing a continuous widening of the attack surface across this vertical.

5. Software Supply Chain Security: If what the industry has witnessed in the past three years is any indication, cyberattacks on software supply chains will only increase in both frequency and severity throughout this year, as they have in previous years. Gartner predicts that by 2025, 45% of organizations will experience attacks on their software supply chains, which will be three times as many as in 2021. Software supply chain (SSC) security is a key priority in 2023, as organizations contend with an onslaught of attacks. From open source and third-party software libraries to developer user accounts and log-in credentials to components required to build, package and sign software — every element of the software supply chain will be subject to attack.

That said, new federal mandates and industry guidance intended to address supply-chain risks will put new pressure on enterprises this year to adopt established and evolving best practices that address SSC security.

And consequently, software component management tools used to track and manage open source software components that developers use will become important. Developers will embrace them to identify and address any vulnerabilities that may be present in their software bill of materials or SBOMs.

Final Thoughts

It is imperative for enterprises of all sizes and geographies to adopt a cloud native application development model, one that supports the development of modern apps built to meet the needs of the modern user. But, for your modern app to yield unprecedented efficiency, scale and value, the single biggest enabler in 2023 is security.

Cisco’s Panoptica solution protects the full application stack from code to runtime by scanning for security vulnerabilities in the cloud infrastructure, microservices (containers or serverless), the software bill of materials, and the interconnecting APIs. And best of all, it integrates with the tools that your application development and SecOps teams are already using. To learn more about Panoptica, visit us here or sign up here to try it for free.

The post Cloudy with a Chance of Malware – What’s Brewing for DevOps? appeared first on The New Stack.

Serverless functions, which account for around half of the workloads today at cloud-first companies, have become a popular means of deploying applications largely because serverless minimizes the number of complexities that teams need to think about. By eliminating the need to configure host servers, serverless functions simplify IT operations.

That doesn’t mean, however, that serverless functions also simplify security. On the contrary, a variety of security challenges and risks can arise within serverless computing environments. That’s why it’s critical to have a plan for protecting serverless functions and the architecture that supports them.

This article walks through the main security risks that affect serverless functions, then discusses key principles for managing those risks.

Agentless cloud security and compliance for AWS, Azure, Google Cloud, and Kubernetes – in a fraction of the time and operational costs of other solutions.

Learn More

The latest from Orca

Serverless Functions Security Risks

The main difference between serverless computing and traditional computing is that serverless frees development and IT operations teams from having to configure and manage the underlying server environment in which applications run.

Beyond that difference, however, serverless functions work in a similar way to conventional application deployment technologies like VMs and containers, and they are subject to the same types of risks:

• Malware that exists within serverless functions.
• Insecure access controls to govern which resources each serverless function can access, as well as who can deploy, stop and modify serverless functions.
• Insecure third-party dependencies that serverless functions call when they run.
• Insecure management of sensitive data or secrets that serverless functions produce or access.

In addition, serverless functions are at risk of a special type of attack that is less prevalent with other types of deployment technologies:

• Financial resource exhaustion happens when attackers force serverless functions to execute repeatedly. Because serverless functions execute on demand, and because cloud providers charge relatively high fees for serverless execution time, financial resource exhaustion attacks allow malicious parties to run up their targets’ cloud bills. Most other types of hosting technologies aren’t subject to this type of attack because they use different pricing models.

Three Core Principles for Protecting Serverless Functions

The serverless security risks described above can be mitigated on a function-by-function basis using various tools, like configuration scanners that check functions for configuration oversights. Teams can and should take advantage of these tools to protect their functions.

However, at a deeper level, security should be baked into serverless functions themselves. In other words, teams should take steps to ensure that their overall approach to serverless computing is as secure as possible. This strategy builds in another layer of protection that extends beyond securing individual functions.

Here are three ways to integrate security into your serverless functions.

1. Ensure Your Serverless Strategy Includes Security by Design

Serverless functions are easy to deploy, and it can be tempting to turn to them as a simple, cost-effective means of running whichever applications you need to run.

But that doesn’t mean that serverless functions are the most secure solution for deploying every workload. Some types of applications, such as those that need to manage highly sensitive data in a complex way or that require extensive third-party dependencies, are difficult to secure, which gives teams less control over and visibility into the hosting environment.

The takeaway here is that you shouldn’t use serverless functions to deploy workloads that require a level of security control and observability that is difficult to achieve using serverless functions. Sometimes, serverless is just not the way to go, despite its simplicity.

2. Be Minimalist

Serverless functions are designed to make it easy to run small, discrete pieces of code on an on-demand basis. However, it can be easy to forget this principle and instead treat serverless functions as a means of deploying any type of application.

Doing so is a mistake not only because it typically means you won’t take advantage of the core benefits of serverless functions, but also because the more code you run inside each function, the higher the risk that you’ll misconfigure something or introduce insecure dependencies.

A better practice is to take a minimalist approach to serverless computing. Strive to reduce the code inside each function to the bare minimum. In addition to helping to save money and improve performance, this strategy will improve overall serverless security.

3. Isolate Functions

Although it’s common to have serverless functions trigger each other to execute workflows that require multiple functions, teams should strive to isolate each function to the extent possible.

Isolation between functions means applying a “zero trust” approach to function configuration: by default, no function should blindly trust another function or consider data received from it to be secure. In addition, engineers should configure tight perimeters around each function by strictly limiting which resources functions can access.

Finally, where possible, teams should avoid having functions invoke each other directly, since that approach opens the door to issues like financial exhaustion attacks in the event that one function is compromised by hackers. Instead, manage function execution using an external control plane rather than relying on the logic that is baked into individual functions.

Conclusion: Securing Serverless Functions and Technologies

In short, serverless functions are a powerful technology, but they have their limitations, not least when it comes to security. Before embracing serverless, it’s critical to understand the potential security risks and take measures to brick defenses into your overall serverless strategy.

For more tips on securing serverless functions, along with data about how companies are approaching serverless security today, check out the free “Serverless Technology Trends Report 2022,” developed by Techstrong Research in conjunction with Orca Security.

Further Reading

• 4 Best Practices to Cloud Security Challenges
• Malware in the Cloud: Challenges and Best Practices
• Tell me your secrets: Serverless Secrets in AWS Lambda

The post 3 Principles for Building Secure Serverless Functions appeared first on The New Stack.

When Tony Grant, a UK-based digital marketing professional, set out to analyze data around local businesses, he found Excel too limited and too memory intensive, even on a powerful Windows machine.

If someone searched for a plumber in his home city of Lincoln, for instance, he wanted to be able to automatically find the three other nearest plumbers.

“This sounds easy enough, but when you start to understand how UK postcodes work, it becomes less helpful. You cannot just assume that similar postcodes are near to each other, and you also need to factor in that there are almost 2.25 million different postcodes in England alone, not including Wales, Scotland or Northern Ireland,” he explained in email.

Then there was the problem that postcodes are not naturally adjacent and do not equate to a set area of land. A UK postcode could refer to just one house, or it could refer to several hundreds, if not thousands.

The logical answer was to turn to geo-coordinates, but that would triple the data set, making this an impossible task with Excel’s limits of around 1 million rows.

So he set out to find an online tool for the project, but found them also limited and expensive. Amazon Web Services he found too technical and jargony for a layman, Airtable too sales-focused. Then he stumbled upon bit.io, which promised to solve these problems and be simple.

“Bit.io was a dream. Even the free starter table had something like 10 million rows. Even if I added Scotland and Wales, I would still be only 25% full,” he said.

Tapping the Postgres Ecosystem

Bit.io enables users to quickly create a full-featured serverless Postgres database and share it with team members or clients easily.

“You can go to Bit today and without signing up, drag a file and get a database,” said Bit cofounder and CEO Adam Fletcher. “We just want people to use the software and find the value right away. That was a key tenet for us.”

These databases work with any tool that works with Postgres. Users don’t even have to set up an account, although doing so unlocks more features.

You can load data by dragging and dropping files, entering a data file’s URL, sending data from R or Python applications or using just about any other Postgres or HTTP client. It has an in-browser SQL editor or you can work in tools like R, Python, Jupyter notebooks, the command line and more.

Getting to Value Quickly

Fletcher previously was head of technology for cybersecurity vendor BlueVoyant, director of engineering at healthcare analytics platform Nuna, and a site reliability engineer at Google. Co-founder Jonathan Mortensen, a data scientist at Stanford, led data science at medical and cybersecurity companies. BlueVoyant bought out their developer tools company Gyroscope Software.

“Everywhere we’ve been we’ve encountered the same data problems,” Fletcher said. “In particular, there’s the problem around productivity with data and effectiveness with data and iteration speed.

“When we left the company that bought my last company, we said, ‘Let’s build that thing, just one last time for everybody, right? Like everybody seems to have this problem.”

Basically they wanted to alleviate the headaches of data ingestion and data sharing. Making it serverless means users don’t have to manage infrastructure.

Tackling Ingestion

Bit.io uses algorithms to determine the structure for CSV, JSON and other data for loading into Postgres.

“It’s actually quite hard in any traditional relational database to get data in,” Fletcher said. “You have to do it in a programming language. You have to do it with command line tools that are hard to use and not native. And what we just said was, ‘Look, people have these datasets. All we want to have them do is drag and drop the data they have without having to do any work on it, and it turns into a real Postgres database.’

“In order to do that, we had to solve a couple of problems, one with CSV files in particular and Excel files, you know, sort of the regular tabular data you see all over the place. … there’s no schema, right? And so we used a bunch of open source tools, and then we modified them and wrote a bunch of technology on top of that, so we can do things like say, ‘Oh, this column is a string, this column is an integer, this column is you know, whatever.’ And type it into Postgres columns such that … you have a real schema, real columns, real data types, and then support all of the millions of corner cases that show up when you do that,” he said.

“So it’s really just taking on that kind of engineering / dirty data problem upfront, and making sure it’s as easy as possible.”

Bespoke Control Plane

Then there’s the sharing problem, which Fletcher describes as “hard in a different way.”

Sharing is hard, he said, because of authentication and authorization models that come with Postgres. They decided to take a page from GitHub and built authorization and authentication into a control plane outside of Postgres.

Extracting out user and security information and sending it the Bit control plane to ensure users have the correct access took what Fletcher called “a complex bit of programming on that side too.”

Users can make their data either public or private. COVID data, for example, have been popular public data sets that can be shared with read-only access.

“We’ve had some really interesting stuff like liquor consumption in Iowa. … like during the pandemic, do people drink more? Iowa happens to track every sold bottle of liquor and beer and everything like that, right? Like, what a fun piece of data!” he said.

But sharing internally is important too. As a member of a finance team, for instance, you could share billing information as read-only. And when a team member leaves the company, access can be revoked with the click of a button.

Embracing Serverless

In addition to focusing on ingestion and sharing, the team built out proxying and an API so you can do this all programmatically. By combining the Postgres ecosystem with serverless means users don’t have to manage it or worry about scaling. He said the system has been tested to 25,000 transactions per second.

“It just scales up automatically. It just kind of grows as you go and then it scales down. And if you’re not using it, it shuts itself off,” he said.

Former MongoDB CEO Max Shireson, an investor in bit.io with Battery Ventures, considers serverless a game changer.

“I think that people had this idea that the cloud would be completely elastic and flexible, and you wouldn’t have to worry about hardware anymore. And in many ways, that has not yet been true,” he said in an interview.

“What the team at bit.io is doing is helping the cloud live up to its promise for data by creating a serverless offering, which means that when you create a database there, you don’t have to tell the thing how much hardware to run it on or what type of hardware to run it on. It just gives you an endpoint in the cloud that grows and expands as you need it without being limited to the granularity of machines.

“And in particular, when you have lots of little new experimental things, there can be a lot of overhead for that, right? Your new experimental application might only need 3% of a machine and you don’t want to allocate a whole machine or even … equivalent of a quarter of a machine — that still may be a lot more than you need. And it doesn’t necessarily sound like a big problem. You’re renting still a fairly small slice, and it’s not that expensive. But in terms of fostering experimentation and innovation, really being able to use just what you need makes a big, big difference. You may want to let 1,000 flowers bloom and each flower isn’t worth spending 100 bucks on [because] you don’t know that anything is going to come of it.

“That’s why I think a lot of people are excited about this idea of a serverless database that you just use as much as you need. Maybe it’s really tiny, maybe it’s medium, eventually, maybe it grows into something large. But it’s really great for experimentation. It’s great for getting started.”

Bit.io is far from the only serverless database, though. It competes with serverless offerings including CockroachDB, PlanetScale, Amazon Aurora and DynamoDB, Google Firestore and Fauna DB.

Growing Startup

The San Francisco-based startup announced general availability of its Database as a Service product in October, as well as $7.5 million in seed funding led by Battery Ventures and GreatPoint Ventures. Founded in 2019, the company’s product had been in private beta since 2021.

It has since grown to more than 15,000 users, including companies like Ford, Visa and Morgan Stanley, and use cases including production OLTP (online transaction processing) workloads, building web applications, low-code/no-code backends, data analysis and mobile applications.

The free tier allows users to create up to three free databases with 3GB of storage and query 1 billion rows with data access via any Postgres-compatible tool. It supports all major programming languages, business intelligence tools such as Tableau and PowerBI, and ETL (extract, transform, load) tools such as Airbyte, Airflow, and Dagster. It also offers the ability to migrate from the open source SQLite database.

“bit.io has very simply answered almost all of my initial needs. It delivered a truly simple service that doesn’t baffle the normal user, and doesn’t complain when I try to throw 2.5 million rows of data at it,” Grant said.

Almost as an afterthought, he added that he is blind and can only access the computer through the keyboard, not a mouse.

“This tool works perfectly under this accessibility situation, so another thumbs-up from me.”

The post Bit.io Offers Serverless Postgres to Make Data Sharing Easy appeared first on The New Stack.

The edge is in vogue right now. In 2023, there’s a good chance every website and application will have a little bit of edge in its wardrobe.

There are components to an edge architecture — it can include IoT devices, for instance — but when it comes to frontend development, the edge is about putting more of the application near the end user, explained Alessandro Cauduro, chief developer experience officer at Azion, an edge provider with 100 edge locations around the world. Azion has a strong presence in North and South America.

“Instead of having everything centralized in a single place, like in the cloud data center [if] it’s in New York, the edge is basically near the end user,” Cauduro said. “It’s making distributed applications so that they’re faster, they’re more secure because you have to go from the edge nodes before you get to the application. So it’s so way to build instant response applications, basically.”

Azion competes with CDNs like Akamai and Cloudflare, but Azion focuses primarily on edge computing for web applications

“A single developer today can use like Next.js, which is becoming a full-stack development environment, and create a whole application,” Cauduro said. “So it’s very easy today for a single developer to create a world-class application using the most modern ways of building an application that can scale.”

Couchbase delivers Capella, the cloud database platform for modern applications. Capella enables developers and architects to quickly build the apps of the future and deliver always-on experiences to customers, on a mission to simplify how businesses develop, deploy and consume modern applications.

Learn More

The latest from Couchbase

Speeding Applications

It turns out, the edge goes great with serverless. The edge can be used to accelerate existing cloud applications that currently run on a specific server, he said, adding in that situation, the edge acts as a cache.

“You can hit the edge before going to the cloud and you can do some compute and decide what you’re going to do — if you if you’re actually going to need to go all the way to the cloud, or you can just give back an immediate response based on what the user is doing,” Cauduro said. “So it’s serverless but it can also work with existing cloud infrastructure.”

That’s one of the big use cases because developers can put a web application firewall at the edge, ensuring that before the call goes through your server, the infrastructure is protected.

Shifting Development to the Edge

There’s a shift happening, though, with developers considering whether they can bypass the cloud infrastructure to just build at the edge. The edge works well with the Jamstack architecture, he added. The API doesn’t have to reside on a cloud server — it can also be delivered at the edge, which, along with running JavaScript on the frontend, makes for a fast-reacting application.

“So that’s just basically [going from] being centralized to being decentralized, that’s the change that the edge is doing right now,” he said. “It’s much faster, we don’t need to be taking care of servers, because that’s a pain.”

It also can be more economical, he added.

“The edge can decide if we already have the answer to what you need, you just give it back to the user; we can go all the way to the server, so it makes you need less of an infrastructure,” he said. “You only pay for when you use it, so you don’t need to have a server running 24 hours a day, because the edge is there ready for it.”

What providers like Azion do is abstract the deployment to the edge, so that it’s simple for developers to do that, he added. It allows developers to simply deploy the application online without a specific understanding of what’s happening behind the scenes, he said.

Underneath the hood, however, what happens is that applications such as Next.js split the page into functions. The functions are created and deployed to the edge to run. This can be accomplished with JavaScript or WebAssembly, Cauduro said, much like a CDN does with static content. Azion uses standard web APIs to spread the code over to its network automatically, he added.

“It’s a very easy way to create a planet-scale application,” he said. “A single developer can create something that’s very reliable because we have 100 digital locations. If one goes down, we have another one that it’s rerouted to automatically. It’s secure, in the sense that we have the firewalls in place before your code is used. And it’s very fast, because [it’s] very, very close to the user. That’s why everybody’s talking about the edge right now.”

The post Why the Edge for Applications Is a Trend Heading into 2023 appeared first on The New Stack.

In Jan. 2022, The New Stack raised the question: “Will 2022 Be a Golden Age for Full-Stack JavaScript? The article drew on the work of developer and Best of JS creator Michael Rambeau, who tracks trending projects in the JavaScript ecosystem and assembles them into his yearly JavaScript Rising Stars, which ranks projects according to stars given on GitHub.

It’s a compelling idea, this notion that JavaScript might be in a Golden Age. Despite early and frequent rumblings that WebAssembly or the htmx framework might shake JavaScript loose from its throne, those predictions are still that … predictions.

JavaScript, meanwhile, had arguably another golden year, as it spread to the edge and its frameworks proliferated.

Javascript Goes to the Edge

One big trend that will likely only accelerate in 2023 is JavaScript’s shift to the edge. More companies — including Cloudflare, Netlify, Deno and Vercel — embraced this paradigm, making it easier than ever for developers to deploy on the edge.

“One more [trend] that is really, really interesting is the rise of edge computing, and this is primarily led by CloudFlare and Deno,” Shawn “@swyx” Wang told The New Stack earlier this year.

Edge has traditionally meant Internet of Things technologies, but when developers use the term, they tend to mean a content delivery network (CDN), which is a geographically distributed group of servers that deliver content from the location closest to the user. It’s even used as a synonym for serverless.

“They try to cache the content close to the user,” Wang explained. “So when I’m sitting in San Francisco and I’m requesting content from U.S. east one, I’m not actually paying for the U.S. east one, I’m actually pinging my local CDN data center.” These CDN serves can be as small — small enough to sit on a cell tower, he added. Wang contends that there’s a big push to rewrite code to take advantage of the edge.

“Because you’re deploying your code to more servers, essentially, they’re just smaller servers everywhere. The new center — the new generation of […] edge compute companies — they have found a way to deploy it in sort of V8 isolates, which are actually taking the JavaScript engine from Chrome and running that as a server,” he said. “Chrome is super-light compared to an entire operating system, [so you’re] just running that as a server; and when you shrink it down that much, you can make it a lot cheaper.”

As a result, edge servers tend to be cheaper than serving a page from a central location, he added.

Wang isn’t the only one who touts the value of the edge. It took center stage at this year’s Jamstack Conference, where Sunil Pai, a former senior system engineer at Cloudflare, suggested developers put part of their website on the edge within the last quarter of 2022.

“We’re working on the rest of it at the moment. There’s a lot of work to do, but you should use a lot of it today,” Pai said. Pai is now a founder of Cool Computer Club, which builds developer tools for edge applications.

Netlify co-founder and CEO Matt Biilmann said his cloud-based development company has seen approximately three times month-over-month growth in edge use cases recently. According to a survey conducted by Netlify of nearly 7,000 developers in the Jamstack community, more than half are testing the edge by building edge-dynamic sites. The survey defined edge-dynamic sites “as sites that are fully dynamic, and render all their content at the edge (i.e. using serverless functions or edge functions).”

The Beginning of the End for Static Pages

One reason for the drive to the edge is that it promises some level of personalization that can’t be realized by a static, server-side site.

Wang contended that static side generation (SSG) is “basically dead” in a talk at Reactathon this year. He also noted a movement towards incremental rendering, along with edge routing. He pointed out that “Next.js is winning so hard” as a framework that supports these trends.

Couchbase delivers Capella, the cloud database platform for modern applications. Capella enables developers and architects to quickly build the apps of the future and deliver always-on experiences to customers, on a mission to simplify how businesses develop, deploy and consume modern applications.

Learn More

The latest from Couchbase

Wang outlined the “ages” of JavaScript at the conference, claiming that we’re now in the third age. He predicted a “re-skilling” away from JavaScript by the end of the 2020s. While he didn’t specify what might take the place of JavaScript, he did remark that WebAssembly is “in its first age” currently.

You Get a Framework! And You Get a Framework!

Well, not quite. The same Jamstack Community survey found the most used framework is React, at more than 71% usage on some or most projects in the ranking of 29 frameworks that made the list. While React is technically a JavaScript library, it forms the basis of many JS frameworks.

“The most obvious story in our framework data is the continued growth of React,” the survey stated. “While there are many options for building a reactive web app, the enormous ecosystem around React continues to make it an easy choice for many.”

That didn’t stop alternative frameworks from entering this crowded field, including Fresh.

Fresh is a full-stack JavaScript framework created by Deno software engineer Luca Casonato. It is based on Preact, a JavaScript library that promotes itself as an alternative to Meta’s React. It also uses Deno, rather than the more common NodeJS.

Continuing the trend of moving to the edge, Fresh is optimized for edge computing, with most of the rendering done on the server, Casonato told The New Stack. That translates into a great performance all over the world, Casonato claimed, even on slow devices. Other JavaScript frameworks that send more code to the client often struggle in comparison on slow devices, he said.

He compared it to Node.js or Vercel, which he said might have serverless functions that run on Amazon Web Services in a single region. Why create another framework, though? Casonato said that speed and developer experience were two aspects he felt were missing from other frameworks. The combination, he contended, is a better framework with fewer downsides than existing frameworks.

“The framework is really built for server-side rendering, so it sends very little JavaScript, very little code to the clients, and keeps as much as possible on the server, to make it a really snappy experience for users,” he said.

Redwood also released this year. It’s another JavaScript-based full-stack framework that uses React, but it targets startups and businesses wanting a complete stack based on popular tools. Tom Preston-Warner, the founder and former CEO of Github, is one of the four founders and 300 contributors to the open source web development framework.

“What I wanted to do was collect together a set of tools that was already commonly used, but do the hard work of really beautifully integrating them so that people could just get to work building what’s special about their application,” Preston-Warner told The New Stack.

It’s unlikely we’ve seen the end of new JavaScript frameworks, according to Kelsey Hightower, a Google distinguished engineer and frequent conference speaker. Hightower told The New Stack there will never be just one JavaScript framework.

“There will never be one because the experience keeps changing,” Hightower said. “We like that, as humans, because we want to hear something new. … It will never stop. But do we want it to? I don’t think we actually want it to.”

ECMAScript Progress

JavaScript, the open standard, also experienced eight updates this year, with the release of ECMAScript 2022. Several developers pointed to the error.cause features as a key upgrade.

One change Wang is looking forward to in 2023 is the temporal proposal, which is in stage three of the four-stage proposal process. This would address data formatting problems that can complicate and sometimes be ambiguous, he told The New Stack.

So all in all, JavaScript continues to be the driver of web application innovation on the web. Only now, it’s more prominent on the edge and there are even more frameworks to choose from.

The post 2022 a Golden Year as JavaScript Moves to the Edge appeared first on The New Stack.

No code and low code are part of the greater citizen development movement. Its goal is to have more people, even those without technical training, participating in the creation of technology. If done correctly, these technical building blocks should allow for faster builds that save organizations money. They can also free developers from handling repetitive, mundane tasks.

But, as the United Nations Climate Change Conference (COP27) left an even greater sense of urgency in its wake, we’re reminded of the need to consider environmental impact throughout the software development life cycle — including the impact of the third-party tools we use every day.

IT and telecommunication are the only major industries that are on track to grow their emissions, which are already at about 12 to 14% of total global emissions. Tech companies must do better now, and carbon footprint must influence tech consumer choice.

Is low-code or no-code development or serverless actually greener? Turns out, according to Paul Johnston, a  consultant who provides interim chief technology services, “It all depends on what is meant by low code.”

Here’s how to start working out the carbon footprint of your different low-code options — which in turn will help you make faster, more reliable code.

Defining Low Code vs. No Code vs. Serverless

Low-code development comes with fewer choices, which should mean less development and less technical debt — which should logically mean lower carbon emissions. But a lot depends on which tools you’re outsourcing part of that coding to, and where they host. First, we need to clarify what we’re talking about when we compare no code, low code and serverless.

As Jessica Wachtel, a New Stack colleague, wrote in her recent article “Low Code vs. No Code”: “Both low code and no code allow faster application builds and applications builds where they may not have been possible at all. Both processes could include automated and abstract development by way of drag and drop, limited code writing, templating and model making.”

Instead of writing all the lines of code, developers drag-and-drop workflows. No-code development requires less or no coding knowledge, but may also offer users less flexibility and interoperability, Wachtel warned. Both of these trends aim to create a highly visual common language for both technical and non-technical users.

Serverless architecture, on the other hand, is a combination of a Backend as a Service and ephemeral containers running on a Functions as a Service platform, as Mike Roberts, a cloud architecture consultant, described on author Martin Fowler’s website, and event-driven architecture, as TriggerMesh’s co-founder Mark Hinkle wrote for The New Stack, all with a low-latency data layer and a strong emphasis on automation.

Johnston told The New Stack that serverless is basically “doing low-code and no-code development at 100 miles an hour.”

Decoupled event-driven architecture is inherently more scalable and energy efficient because it works in real time, only performing actions when triggered by other actions. Low code and no code aren’t necessarily event driven, though they can be.

Low code/no code allow you to throw things in a container, which doesn’t necessarily increase efficiency, Johnston said. But with serverless, you are entirely reliant on the cloud provider and their functions, data layers, and event system. “And because of all that, what you’re doing is clearly and simply reducing as much as possible your application design to remove complexity,” he said.

Serverless code, in turn, is simpler and more scalable, and thus more efficient.

Can’t Fix What You Can’t Measure

We know a reduction of carbon footprint is a widely held environmental goal, but we often make assumptions on how that should be measured. Of course, these measurements become even more challenging when using a third-party tool.

Zapier has been one of the most recognizable low-code tools for over a decade now. Like its competitors If This Then That and Make, Zapier pushes data from one service to another via an API or interface.

“Something like a Zapier is essentially saying all of these interfaces are known, stable, secure, so we are going to provide you a way of connecting things together,” Johnston said. ”In many ways, that kind of a platform is going to be better in terms of management and maintenance for the developer.” But its carbon efficiency depends on how efficiently it runs and where it’s hosted.

Zapier, which is more transparent than other tools we examined, hosts on Amazon Web Services (AWS) in the U.S., which in turn is notoriously hit or miss depending on where its servers are located— with Virginia’s Data Center Alley being usually the worst. Zapier doesn’t specify where in the U.S. it hosts.

No matter what, the cloud is inherently better than on-premise data centers, as these newer facilities have hardware that’s more efficient at cooling, and higher utilization rates across shared and as-needed servers. This means less downtime for maintenance, which means less electricity is needed to start the servers back up.

AWS research has found across multiple studies “that AWS can lower customers’ workload carbon footprints by nearly 80% compared to surveyed enterprise data centers, and up to 96% once AWS is powered with 100% renewable energy.” As of the end of 2021, Amazon reached 85% renewable energy and today reports it is the world’s largest corporate buyer of renewable energy.

As The New Stack has already reported, cloud cost remains the best proxy for environmental cost — for which, Johnston contended, “Serverless will be cheaper by orders of magnitude.”

Comparing two other low-code platforms, he said, “I know so many people who are running WordPress websites, spending thousands of pounds a month and it’s open source, but you can spend pennies with serverless,” pointing specifically to the serverless functions used in Netlify, a website and application builder.

Indeed, Netlify’s Jamstack architecture is notably sustainable. “In a non-Jamstack architecture, whenever a user wants to go to a URL, the page is built by the server, and the user’s browser. This can be a drain on computing power, depending on how heavy a website is,” Cassidy Williams, adviser for Netlify and CTO at Contenda, a creator of artificial intelligence tools, told The New Stack.

Jamstack-style sites, on the other hand, use static-site generators, which “are built once, in that when they’re deployed by developers, the site is bundled in a way that when the user hits that URL, a server isn’t needed, and the browser just has to display what’s already built,” Williams said.

Netlify compresses dynamic websites into static ones, making the carbon footprint of a website on Netlify smaller than that of a traditional website, which rebuilds each page every time via server-side rendering.

In addition, since Netlify auto-scales infrastructure, there are no extra servers running, which breaks the data center industry’s bad habit of provisioning for double the amount of servers needed. Hosting on both AWS and Google Cloud, Netlify states: “We actively manage the scalability of the sites we host on our providers by only adding resources when spikes in traffic require them and shut them down when they are not in use.”

While low code and no code look to simplify the development process, serverless can make it more complicated, relying on designing more intentionally — and more slowly — upfront, focusing on improving user needs and scalability. “To reduce cost, it becomes a process problem, not a technical problem,” Johnston said.

This isn’t something that can be easily done with low-code/no-code tools like Zapier — which he said is “all about the blocks [when] we should be looking at how well-designed the interface is. How easy to use is the interface. What you’re actually interested in is the API, which is why you look at AWS” for the answers.

“If this is well designed and it just works over time,” Johnston said, “then the likelihood is that it’s the most energy efficient.”

How Green Is Serverless?

Generally speaking, a no-code or low-code third-party application or tool that is pursuing continuous improvement, will be more likely to maintain or increase efficiency over time, while older applications managed in-house will become less efficient.

So, in reality, is low code or serverless greener? “That could be definitely broadly true in some cases,” said Astrid Atkinson, CEO and co-founder of Camus Energy, a grid management platform for utilities. Because, she told The New Stack, “if you manage in serverless or low code, you typically are in a model that only spins out resources when you need them.”

She added,  “There’s certainly an argument to be made that serverless increases efficiency of a data center fleet.”

Leveraging third-party tools will always be cheaper and more efficient than building from scratch. But Scope 3 emissions —those that are not directly produced by a company itself but are produced as part of its value chain — make it incredibly hard to figure out that environmental impact.

When companies are considering third-party tools, “they should actively go and seek the sustainability statements and reports of the cloud provider they are using,” Atkinson advised. “Once they’ve understood what choices they are making in terms of the base impact of the energy footprint of their data environment, they can optimize by using resources more efficiently.

“Serverless is great at that,” she noted, as it only uses the compute resources it needs in the moment. Also, “using compute-efficient languages will definitely reduce the overall footprint of any given workload.”

However, Atkinson noted, the vast majority of data center impact is generated by very large users, which, she said, find it “very, very difficult to take advantage of serverless,” as they are bogged down with resource overhead. This, she said, makes it much harder to optimize the usage of compute resources for workloads, to schedule instances, and to allocate resources.

Consider Your Application’s Full Life Cycle

“Faster is better for the environment. There is a direct correlation between speed and energy usage,” Johnston said.

How is that achieved? If you’re just using a huge number of servers, it’s never going to be efficient. But when you have “an incredibly efficient application that does exactly what it’s supposed to do and can scale at any size,” he said, you aren’t just ensuring your current energy usage but your usage across your application’s entire life cycle, from design to retirement or replacement.

Therefore, while it’s simpler to calculate cloud cost, a better proxy for energy efficiency is an application’s total cost of ownership over its entire lifecycle. This includes how much time and effort has gone into designing, developing, managing and maintaining the app, combined with the cost of hosting, network, usage and retirement/replacement — namely, is it maintainable? The Institute of Electrical and Electronics Engineers (IEEE) has long tied software sustainability to software maintainability.

Then, “usually, relying on economies of scale from a cloud or SaaS provider can give you improved energy efficiencies, limiting the amount of effort to put in,” Johnston said.

He added, “you can still get things wrong, but the point is you generally have to fix less,” as you have a smaller codebase and everything is more about interfaces and optimizing for flow.

Overall, as tech ethicist Anne Currie once told The New Stack, machines managed via cloud providers are simply more efficient than human-managed storage and hosting. So while there are better clouds and especially better hosting regions than others, the managed cloud will always be better for the Earth.

Of course, with more abstraction when you use a third-party provider, “you have to trust the providers are going to do what they say they are going to do,” Johnston said. “We are talking about reliance. And we are talking about putting that trust in the provider, such that we can focus on the elements in the application that are actually important, rather than building all the code.”

Then comes continuous monitoring and observability to maintain or increase that efficiency. For example, if you see a 5% increase in latency, you start to look at why, which Johnston said “you can’t do in a low-code, no-code [tool] like Zapier because you’re not really in control. But in a serverless environment, you have that control … and it’s more efficient and you are maintaining less, reducing maintenance, and the system should be more efficient over time.”

Can You Abstract the Carbon from Low-Code Sites?

Just because it is hard to build greener low-code tooling, doesn’t mean engineers aren’t trying to.

Fershad Irani, a website sustainability and performance consultant, told The New Stack about building Flowty to help people build and host greener no-code sites through the low-code, drag-and-drop website builder Webflow.

Flowty, Irani said, came about after conversations among members of the ClimateAction.Tech community who built websites for clients using Webflow, “but wanted to do so in a way that was more sustainable than Webflow offers.”

This demand arose because Webflow uses AWS for hosting. “Amazon’s a sustainability laggard among major hosting providers,” Irani said. “The people I spoke to were looking for a way to have sites hosted on greener services, while still being able to edit and maintain their sites on Webflow.” 

Webflow says it’s carbon neutral via carbon offset donations to Pachama, which looks to leverage technology to restore nature. However, those community members wanted to better address Scope 3 emissions. These are often the largest emissions for software companies, as these include any data centers they use, even those managed by an external cloud provider like AWS.

The Flowty project also aimed to reduce the weight of the Webflow pages in order to decrease load time and increase speed. “Some content optimizations are available on paid Webflow plans, but others, like optimizing images or embedded videos, are lacking,” Irani said.

In the end, Webflow brought a cease-and-desist order against very similar tools, deeming them in breach of Webflow’s terms of service. In response, Irani open sourced Flowty on GitHub and sunsetted the project.

No matter what a no-code or low-code tool is trying to achieve, a lot of it comes back to where the tool user hosts. “I don’t have much experience with other no-code tools, but I’d assume using AWS is a key part of how they are built. I’d love to know that others are being more active in their efforts to use cleaner sourced services,” Irani said.

While the Big Three account for two-thirds of global cloud computing, and “all have pledged to fully decarbonize their data centers, none have completely divested from fossil fuels,” according to Maryam Arbabzadeh, director of science at Climatiq.

Based on Climatiq’s data, generated by the open source tool Cloud Carbon Footprint, all three companies potentially greenwash via offsets, depending on the region in which they operate because they still have sites, especially in the Asia-Pacific region, which heavily rely on fossil fuels. Therefore the greatest criticism of AWS lies in its poor transparency and carbon footprint reporting, which still don’t reflect Scope 3 emissions.

Vetting Vendors for Sustainability

No matter if you are going the low-code, no-code or serverless route, or if you are just subscribing to a third-party SaaS, their carbon footprint becomes yours. Atkinson suggested you kick off by examining the energy practices and energy footprint of the service providers you are using. The privacy policy can be a good place to start, to see where data is being stored on what cloud.

Running a vendor’s Website Carbon score is another useful starting point. Overall, sustainable.dev, which produces this score, is helpful to identify ways to make your work greener.

There are two ways to look at any vendor’s energy footprint, Atkinson said:

• Physical carbon footprint: carbon intensity on the wire
• Economic carbon footprint: financial or market arrangements, trade-off incentives, carbon offsets and power purchase agreements, which help contribute to energy transition

If a company really cares about their impact, it should be pretty apparent on their website, Atkinson said. Look for “any stated net-zero carbon goals and do they report progress against them.” She added, “Whereas if they aren’t making any statement whatsoever, then they probably don’t care very much.”

Reflecting on some big names, Atkinson said, “Meta focuses a lot on using their data center resources to push decarbonization on the broader energy supply. Microsoft and Google provide data center details.”

By contrast, she said, “Amazon doesn’t have any specific policies around decarbonizing their data center supply mix.”

She noted that Microsoft also invests in a lot of innovative programs, including proving the effectiveness of underwater data centers. “Amazon is a bit of an outlier,” Atkinson said, echoing Irani.

Appian, which makes a low-code development tool, is doing interesting things around embedding environmental, social and governance (ESG) goals into operational processes. Its website states that Appian integrates pre-existing data systems and “virtually any third-party data source, including ratings, benchmarks, and analytics providers,” which should make it easier to report.

Now what remains to be seen is if companies actually set such goals and publicly share the progress against them. “If they have broader ESG goals, the behavior or targets set by their providers are often provided in ESG-type reporting and it’s worth considering what the goals of your carbon policy is,” Atkinson said.

Atkinson suggested this should include:

• Minimize carbon impact.
• Optimize for overall ESG impact.
• Include formal reporting in your goals.

You can spot red flags too, she said. For instance, “if they are involved in crypto[currency] or any form of blockchain that’s intentionally, wildly inefficient.”

And don’t forget, she reminded, to “understand the landscape within your own company environment and how much you are considering these when you are making technical deployment choices.”

For more on green software development, check out this episode of The New Stack Makers podcast:

The post Is Low-Code Development Better for the Environment? appeared first on The New Stack.

In this article, we will build a comprehensive “to-do app” with APIs and end-to-end (E2E) tests using some of the modern stacks together. It will demonstrate how to build a modern web application by using a continuous integration (CI) pipeline and monitor the CI process to catch potential errors before introducing them to production.

Here’s the modern stack used in this project:

• Next.js to-do app for building the web application
• Playwright for end-to-end testing
• GitHub Actions for building the CI pipeline
• Foresight for CI and test monitoring

Purpose of this Project

The need to create production applications blazingly fast is rapidly increasing in the tech world. Our motivation while creating this project was to contribute to the developer community with an end-to-end stack for a web application. We picked free tools so no one has to pay.

Expected Outcomes

We wanted to create a production-ready serverless sample web application in the simplest possible way. That’s why we chose Upstash to create a Next.js-based application.

In the testing phase, we went with the Playwright framework because it makes it pretty easy to work in any browser and platform. We implemented JUnit and generated a test report with it.

Deciding on a platform for building a CI pipeline was one of the least challenging decisions for us because GitHub Actions does that pretty well.

And finally monitoring both our tests and CI pipelines was something we found pretty challenging. Although there are some tools in the market like Allure for test monitoring and Meercode for CI monitoring, these seemed not so useful at the end of the day. We decided to go with Foresight because it provides deep analytics for both tests and CI pipelines.

Foresight lets you monitor your GitHub Actions workflows, tests, and untested code changes on a single dashboard. It visualizes your GitHub Actions workflows by status, duration, and cost. It helps optimize build duration, enable more frequent deployments, boost productivity, and lower CI costs.

Learn More

The latest from Foresight

Setting up the To-Do App with Next.js

This project requires a Next.js application. If you already have Next.js configured in your system, you can use that. If not, we recommend using the example below.

This guide was created by the Upstash team, and it is very minimalistic and easy to understand.

Setting up Tests with Playwright

Run the following command and initialize the Playwright. After quick configurations, you are ready to get started.

npm init playwright@latest

• You can either choose JavaScript or TypeScript.
• Give a name to your tests folder.
• To run tests on CI, just add a GitHub Actions workflow.

You will have the base Playwright setup after the installation is completed. You will see your test under the tests folder and under the .github folder you will see your GitHub Action playwright.yml.

Creating the E2E test

We want to ensure our APIs and user interactions are working properly. So we will add an E2E test, which will add a to-do item and complete it.

Under the tests folder, you should create add.spec.js file and paste the following code:

// @ts-check
const { test, expect } = require('@playwright/test');
 
const TODO_ITEMS = [
 'buy some cheese',
 'feed the cat',
 'book a doctors appointment'
];
 
test.beforeEach(async ({ page }) => {
 await page.goto('https://localhost:3000/');
});
 
test('add a todo item', async ({ page }) => {
 
 var todoName = TODO_ITEMS[0];
 
 // Text input
 await page.locator('#todo').fill(todoName);
 await page.locator('#todo').press('Enter');
 
 // Make sure the list only has one todo item.
 await expect(page.locator('.Home_card__2SdtB')).toHaveText([
   todoName
 ]);
 
});
 
test('complete a todo item', async ({ page }) => {
 
 var todoName = TODO_ITEMS[0];
 
 // Text input
 await page.click(`.Home_card__2SdtB:has-text("buy some cheese")`);
  // Make sure the list only has one todo item.
 await expect(page.locator('.Home_card__2SdtB')).not.toHaveText([todoName]);
});

In order to run our tests one by one, disable the parallelization in playwright.config.js.

/* Run tests in files in parallel */
 fullyParallel: false,

Then go to package.json and add a test script.

"test": "playwright test"

You will be able to run the test by the npm run test command in your terminal and in the GitHub Actions.

Run your test and check whether your configuration works correctly so far.

Creating a JUnit Report

To make sure of the health of our tests, we use test reports. JUnit reporter produces a JUnit-style XML report. This is essential for ensuring our to-do web app achieves an acceptable quality level.

Add the following in the playwright.config.js file:

reporter: [ ['junit', { outputFile: 'results.xml' }] ],

A file named as results.xml will be generated when you run your tests.

The test reporter includes the error logs and messages when there is an error.

GitHub Actions Configuration

Push your code to a GitHub repository. The initial playwright.yml action will help us to run our test in every commit and pull request. Your configuration should look like this:

on:
 push:
   branches: [ main, master ]
 pull_request:
   branches: [ main, master ]
jobs:
 test:
   timeout-minutes: 60
   runs-on: ubuntu-latest
   steps:
   - uses: actions/checkout@v2
   - uses: actions/setup-node@v2
     with:
       node-version: '14.x'
   - name: Install dependencies
     run: npm ci
   - name: Install Playwright Browsers
     run: npx playwright install --with-deps
   - name: Run Playwright tests
     run: npx playwright test
   - uses: actions/upload-artifact@v2
     if: always()
     with:
       name: playwright-report
       path: playwright-report/
       retention-days: 30

You will be able to see your workflow runs if your Action works.

GitHub Action works flawlessly to automate the works you have done manually. You don’t need to run npm run test by yourself; GitHub Actions does it automatically when you commit a new code. However, GitHub Actions is not offering enough information about your tests and their performance. When they fail, you need to understand by finding them in a log pile in the workflow run details.

We will use Foresight to monitor our tests. It is free for open source projects and requires a simple configuration to start.

Setting up Foresight for Monitoring

Configuring Foresight takes less than two minutes. All you need to do is set up an account, install Foresight’s GitHub app and watch the repository that you’ve initiated for this tutorial.

After watching this repository, you need to update your YAML file. You can remove the last step and add Foresight’s test kit.

name: Playwright Tests
on:
 push:
   branches: [ main, master ]
 pull_request:
   branches: [ main, master ]
jobs:
 test:
   timeout-minutes: 60
   runs-on: ubuntu-latest
   steps:
   - uses: actions/checkout@v2
   - uses: actions/setup-node@v2
     with:
       node-version: '14.x'
   - name: Install dependencies
     run: npm ci
   - name: Install Playwright Browsers
     run: npx playwright install --with-deps
   - name: Run Playwright tests
     run: npx playwright test
   - name: Foresight test kit
     if: success() || failure()
     uses: runforesight/foresight-test-kit-action@v1
     	with:
       api_key: ${{ secrets.FRS_PROD_API_KEY }}
       test_format: JUNIT
       test_framework: JEST
       test_path: ./results.xml

As you can see, we entered the format, framework and path fields by the configuration we’ve created above.

This action will automatically send your test report to Foresight, and Foresight will analyze your tests in the most user-friendly way. After updating your YAML, your workflow will run automatically, and you will be able to see your workflow run results.

The Foresight UI is similar to GitHub Actions. It gives you the ability to trace your CI workflow steps, gather all the metrics together, and monitor and debug your tests. You can learn more about Foresight from its documentation.

Summing up

That’s it! We created this project with the hope of helping the developer community by showcasing how easily and cost-free you can create a production-ready web application.

The post Building a To-Do App using GitHub Actions, Playwright, Next.js appeared first on The New Stack.

Which architecture is better in terms of scaling, cost, and security — Kubernetes or serverless?

A breakout session at Amazon Web Services‘ recent Re:Invent conference,  “Competition of the modern workloads: Serverless vs. Kubernetes on AWS” was a six-point comparison of serverless vs. Kubernetes to finally determine which architecture was better, presented by Niv Yungelson, DevOps leader at payment provider Melio and Shimon Tolts, co-founder and CEO of Datree, which provides configuration software for Kubernetes.

The categories covered everything from maintainability to logging and everything in between. Each attendee had the chance to cast their vote at the end of each round via a hand raise, a live action pros and cons if you will.

Tolts, on the Kubernetes side, credentialed himself as a committer and maintainer for numerous large-scale applications that use Kubernetes has seen the good, bad, and once in a lifetime. In terms of relatability, he knows the tradeoffs and how to work within the gray area.

Yungelson was the first DevOps engineer at Melio and now leads the serverless team for the company. She believes serverless is farther down the innovation scale. First, there was on-premises then everyone moved to the cloud but with the same mindset as on-prem: infrastructure first then build out based on needs. Then serverless came along and flipped everything on its head by first starting with the need-then-build-out.

Category 0 – Maintainability

To kick things off, Yungelson quoted Werner Vogels (AWS chief technology officer): “No server is easier to manage than no server.” Kubernetes on the other hand requires a lot of maintenance — regular updates and the occasional random production-level code depreciation.

AWS does help with Kubernetes maintainability with Amazon’s Elastic Kubernetes Service (EKS), which offer conveniences such as auto version upgrades.

It’s no surprise that the audience favored serverless by a landslide.

Serverless 1

Kubernetes 0

Category 1 – Cost

How do we buy this? How do we pay for this?

The Kubernetes tradeoff came down to cluster optimization. Build optimized clusters with the correct ratios of I/O, compute, and memory-intensive workloads. That comes at a high development cost. Are the savings with the potential development cost? Only the specific organization can make that determination.

“Who has a DevOps position they can’t fill?” was Yungelson’s response. A lot of attendees raised their hands. That’s not to say that a serverless architecture isn’t a challenge but the engineering specialty is elsewhere.

There are two more things to consider. Reliability. Kubernetes is reliable. Large traffic spikes don’t affect the cost and the workload doesn’t have to be estimated or forecasted as precisely as it does with serverless as serverless costs can grow quickly.

A major pro for serverless is that the only services paid for are services used which is not the case for Kubernetes.

The raised hands were evenly split in numbers.

Serverless 2

Kubernetes 1

Category 2 – Scalability

Kubernetes and serverless were designed with scaling in mind but function differently. It really came down to serverless’ quotas vs the high amount of babysitting needed for Kubernetes. To the cons, Tolts admitted that scaling Kubernetes was more complicated than scaling serverless but not without also adding that AWS does offer autoscaling. It does exist.

In order to work comfortably within the quota system, Melio created multiple accounts (ie staging, production, etc) because AWS doesn’t allow scaling over hard limits but they do have friendly options.

The audience was still didn’t completely buy into serverless. Tie.

Serverless 3

Kubernetes 2

Category 3 – Developer Friendly

Neither are easy but with Kubernetes, once someone understands the technology, they understand how to work with it. High bar to enter but only have to enter once since Kubernetes as a single API across runtimes. The challenge lies in orchestrating a large environment.

Serverless had a longer list of cons but they can be categorized as being vendor specific. Each vendor has their own tech, their own rules, and everything that goes along with that. In Melio’s case specifically, developers need to understand the limitations of AWS Lambda, and it’s harder to work on the same resources (emulators aren’t exactly the same).

Melio’s solution is private accounts. Rather than have each developer work off a main account and troubleshoot different environments, everyone has their own AWS account and connects to the main account with a script and short feedback loop. Rather than deploying an entire code file update, only their specific changes are deployed.

One point for Kubernetes.

Serverless 3

Kubernetes 3

Category 4 – Ecosystem

The developer world at large or the world created by a cloud provider. Severless is vendor-locked (at least in the case of AWS Lambda) and Kubernetes is open source software managed by the vendor-neutral Cloud Native Computing Foundation (CNCF), and user community Kubernetes has a rich ecosystem around it and can use any service by any provider but serverless is locked to one provider — but its the provider of choice. It’s not like there’s only one serverless option around.

Yungelson is happy with AWS, its vast amount of innovative services, and said she, “doesn’t feel like she’s missing out. It was our choice to vendor lock.”

The attendees were not quite ready to make that commitment though. Another point for Kubernetes.

Serverless 3

Kubernetes 4

Category 5 – Monitoring and Logging

This one takes it back to the earlier idea of serverless being a new way of thinking. With Kubernetes, developers can monitor and log with the same tools they know and love from everything else (ie “it’s how we monitor Linux”) but with serverless there is no server infrastructure to monitor and log. There’s no hardware or hardware limitation to manage though all standard monitoring software supports serverless though the use may be different.

The main con with Kubernetes are the multiple layers and objects to monitor.

It wasn’t enough to push serverless for a win. It was a tie.

Serverless 4

Kubernetes 5

Category 6 – Security

They both have help with security. Kubernetes from regular updates and serverless from the cloud provider, but there is still development work. For example with Kubernetes, if they’re running on EC2 instances the devs need to secure the EC2 instances. With serverless the elopement work comes from the making sure the code meets the security requirements, lambdas are built inside the virtual private cloud (VPC), and there aren’t any virtual public clouds.

Serverless won!

Serverless 5

Kubernetes 5

And in the end it was a tie!

Both applications discussed in the talk are running on Amazon Firecracker.

This was an incredibly engaging way to talk about tech tradeoffs. It was engaging and informative. The space was packed as was the overflow space and the presenters were very knowledgeable. Five stars. Do recommend.

The post Serverless vs. Kubernetes: The People’s Vote appeared first on The New Stack.

Developers are testing the edge, according to a recent survey conducted by Netlify of nearly 7,000 developers in the Jamstack community. It found that more than half of developers have built an edge-dynamic sites. The survey defined edge-dynamic sites “as sites that are fully dynamic, and render all their content at the edge (i.e. using serverless functions or edge functions).”

The survey noted that the number of those who have used serverless technology jumped from 46% to 71%, “taking it fully into the mainstream.”

“We’re seeing these edge environments evolve,” Chris Bach, chief strategy and creative officer of Netlify, told The New Stack ahead of last week’s Jamstack conference. “You can run a lot more compute there rather than just serve things.”

He credited more support from the runtime Deno and Netlify’s own edge computing offering with making the edge much more accessible to developers.

“Everyone was talking about serverless but Netlify could see that a lot of web developers and web projects weren’t using them yet,” he said. “Now we allow people to simply put your serverless functions in a folder and upload.”

The report stated the growth was “much faster than we predicted,” and that 35% said they’ve done “some” or “many” projects with serverless technology, “which relative to frameworks would make it bigger than Vue but smaller than Next.js.”

Another 36% reported they’ve completed “a few” projects in serverless, suggesting most are still in the experimental phase with serverless. Five percent said they’ve done all projects in serverless. Another 30% said they’ve done no project in serverless.

Correlated to that jump in serverless deployment was a shift in the people who described themselves as full-stack developers rather than frontend developers.

“We think the big jump in serverless adoption may be the explanation: Serverless lets frontend developers build full-stack applications with a minimum of fuss, and the adoption has been so fast it’s changing how we describe ourselves,” the report stated.

Couchbase delivers Capella, the cloud database platform for modern applications. Capella enables developers and architects to quickly build the apps of the future and deliver always-on experiences to customers, on a mission to simplify how businesses develop, deploy and consume modern applications.

Learn More

The latest from Couchbase

Who’s the Fairest of Frameworks?

When it comes to frameworks, the most used framework is React, at more than 71% usage on some or most projects in the ranking of 29 frameworks that made the list.

“The most obvious story in our framework data is the continued growth of React,” the survey stated. “While there are many options for building a reactive web app, the enormous ecosystem around React continues to make it an easy choice for many.”

React Express ranked second at nearly 50% on the “some or most ranking” followed by Next.js at 47% — which means nearly one in two developers say they’ve used Next.js in some or many projects, the report noted. Given that Next.js is “a full-featured ‘kitchen sink’ framework based on React,” Netlify predicted it will continue to grow.

It was the sixth-ranked Vite, however, that scored the highest when it came to satisfaction, ranking nearly a 10 out of 11. That may be because it’s not so much a framework as a bundler, competing more with Webpack and Babel, noted Netlify.

“It has been adopted as the default bundler for several other frameworks including Nuxt and SvelteKit, contributing to its high share, but its stellar satisfaction score is all its own,” the report noted.

In the small framework category, Remix moved from 2% to 10% of developers saying they used it on “some” or “many” projects. It was followed closely by progressive framework Nest and VuePress in usage. Though less used, Blitz.js ranked the highest for user satisfaction.

WordPress Dominates CMS

WordPress ranked the highest in the CMS usage category, but newcomer Notion actually ranked second — besting headless WordPress (3), Contentful (4) and Strapi (5) as the content management system of choice. Anyone who uses Notion may find that surprising since it’s certainly not a typical CMS system — it’s closer to a project management tool.

“Notion is something of an outlier in this data: Certainly some people are using it via its API to power websites, but we believe many people who answered yes to this option are using it for internal content,” the survey report stated, adding that Netlify intends to run a small follow-up survey to confirm this.

The open source Drupal ranked seventh in the listing, behind Sanity, an open source headless real-time CMS.

The post Survey Finds Majority of Jamstack Community Testing Edge appeared first on The New Stack.

DETROIT — Even in the midst of hand-wringing at KubeCon + CloudNativeCon North America about how the global economy will make it tough for startups to gain support in the near future, the news about a couple of young WebAssembly-centric companies was bright.

The Latest Milestones on WebAssembly’s Road to Maturity

Cosmonic announced that it had raised $8.5 million in a seed round led by Vertex Ventures. And Fermyon Technologies unveiled both funding and product news: a $20 million A Series led by Insight Partners (which also owns The New Stack) and the launch of Fermyon Cloud, a hosted platform for running WebAssembly (Wasm) microservices. Both Cosmonic and Fermyon were founded in 2021.

“A lot of people think that Wasm is this maybe up and coming thing, or it’s just totally new thing that’s out there in the future,” noted Bailey Hayes, a director at Cosmonic, in this episode of The New Stack Makers podcast.

But the future is already here, she said: “It’s one of technology’s best-kept secrets because you’re using it today, all over. And many of the applications that we use day-to-day — Zoom, Google Meet, Prime Video, I mean, it really is everywhere. The thing that’s going to change for developers is that this will be their compilation target in their build file.”

In this On the Road episode of Makers, recorded at KubeCon here in the Motor City, Hayes and Kate Goldenring, a software engineer at Fermyon, spoke to Heather Joslyn, TNS’ features editor, about the state of WebAssembly. This episode was sponsored by the Cloud Native Computing Foundation (CNCF).

Wasm and Docker, Java, Python

WebAssembly — the roughly five-year-old binary instruction format for a stack-based virtual machine, is designed to execute binary code on the web, lets developers bring the performance of languages like C, C++, and Rust to the web development area.

At Wasm Day, a co-located event that preceded KubeCon, support for a number of other languages — including Java, .Net, Python and PHP — was announced. At the same event, Docker also revealed that it has added Wasm as a runtime that developers can target; that feature is now in beta.

Such steps move WebAssembly closer to fulfilling its promise to devs that they can “build once, run anywhere.”

“With Wasm, developers shouldn’t need to know necessarily that it’s their compilation target,” said Hayes. But, she added, “what you do know is that you’re now able to move that Wasm module anywhere in any cloud. The same one that you built on your desktop that might be on Windows can go and run on an ARM Linux server.”

Goldenring pointed to the findings of the CNCF’s “mini-survey” of WebAssembly users, released at Wasm Day, as evidence that the technology’s user cases are proliferating quickly.

“Even though WebAssembly was made for the web, the number one response — it was around a little over 60% — said serverless,” she noted. “And then it said, the edge and then it said web development, and then it said IoT, and the use cases just keep going. And that’s because it is this incredibly powerful, portable target that you can put in all these different use cases. It’s secure, it has instant startup time.”

Worlds and Warg Craft

The podcast guests talked about recent efforts to make it easier to use Wasm, share code and reuse it, including the development of the component model, which proponents hope will simplify how WebAssembly works outside the browser. Goldenring and Hayes discussed efforts now under construction, including “worlds” files and Warg, a package registry for WebAssembly. (Hayes co-presented at Wasm Day on the work being done on WebAssembly package management, including Warg.)

A world file, Hayes said, is a way of defining your environment. “One way to think of it is like .profile, but for Wasm, for a component. And so it tells me what types of capabilities I need for my web module to run successfully in the runtime and can read that and give me the right stuff.”

The Cloud Native Computing Foundation (CNCF) hosts critical components of cloud native software stacks, including Kubernetes and Prometheus. CNCF serves as the neutral home for collaboration and brings together the industry’s top developers, end users and vendors.

Learn More

The latest from CNCF

And as for Warg, Hayes said: “It’s really a protocol and a set of APIs, so that we can slot it into existing ecosystems. A lot of people think of it as us trying to pave over existing technologies. And that’s really not the case. The purpose of Warg is to be able to slot right in, so that you continue working in your current developer environment and experience and using the packages that you’re used to. But get all of the advantages of the component model, which is this new specification we’ve been working on” at the W3C’s WebAssembly Working Group.

Goldenring added another finding from the CNCF survey: “Around 30% of people wanted better code reuse. That’s a sign of a more mature ecosystem. So having something like Warg is going to help everyone who’s involved in the server side of the WebAssembly space.”

Listen to the full conversation to learn more about WebAssembly and how these two companies are tackling its challenges for developers.

The post The Latest Milestones on WebAssembly’s Road to Maturity appeared first on The New Stack.

JavaScript developers should be experimenting with sending code to the edge now, a panel told audience goers at the Jamstack Conference this week.

Sunil Pai, who worked with the edge as a senior system engineer at Cloudflare until recently, suggested developers put part of their website on the edge within the quarter.

“We’re working on the rest of it at the moment. There’s a lot of work to do, but you should use a lot of it today,” Pai, who is now founder of Cool Computer Club, which builds developer tools for edge applications, told the audience at Tuesday’s conference. It will take time to adapt, particularly when it comes to NPM scripts, Pai said.

“It turns out that a lot of packages on NPM right now don’t really work on a bunch of these new edge runtimes,” he said. “It feels like there’s now a phase where we are going to flesh out the ecosystem for production usage. Nobody wants to use a weekend project that someone put out on GitHub. It has to walk through the fires of production to be battle ready.”

Some are already moving to the edge. Netlify co-founder and CEO Matt Biilmann said that the cloud-based development company has seen approximately three times month-over-month growth in edge use cases recently.

New Possibilities for Runtime

Brian Douglas, founder and CEO of OpenSauce, asked the panel what possibilities were unlocked now that developers can build on top of new runtimes. The accessibility will enable regular developers to build very ambitious, planet-scale applications, Pai said.

“I love systems that are great for zero to one to many. I do not want to commit a bunch of money or time, I just want to write something and quickly put it out there and see,” Pai said. “So the ability to do that for effectively free is a big difference from the JavaScript scene [of] 15 years ago, where I’d have to get an American credit card from my uncle.”

Runtimes that are built on top of isolates (such as Deno) with strong security guarantees, and runtimes built around WebAssembly, are similar in the possibilities they unlock for different sets of developers, Biilmann added. These runtimes will allow systems to be more nimble and support smarter decisions around scaling, concurrency and where to run the code, he said.

“Some of the possibilities we’ll see is both running code very close to the end user, but also running the same type of code very close to our data,” Biilmann said. “So I’m also expecting to see interesting integration of tools, like Deno into databases and so on, because both paths will be really interesting. Can we get our code running really close to the edge, but can we also flip the script on that sometimes and send code to where our data lives, and then get a get simpler result back rather than then having to do these multiple round trips, and so on.”

The core layer of isolates in the case of JavaScript — or WebAssembly in the case of more general programming languages — will allow developers to build architectures where they can, over time, think more about where code should actually run. It will also make it easy to ship that code around in a way that developers couldn’t when the core abstraction was a long-running application server, he added.

Better, Cheaper, Faster

In the immediate future, these optimizations that developers can take advantage of will make it better, cheaper and faster, said Ryan Dahl, founder and CEO of Deno and creator of Node.js.

“It’s essentially an order of magnitude cost improvement over traditional AWS Lambda solutions, for example, for serverless,” Dahl said.

He also mentioned SSR — taking React code [or] JSX style code and running it server-side, and rendering the HTML using server-side JavaScript runtimes such as Deno deploys, he said.

“You can take that React code and run it server-side and actually generate static HTML that you’re shipping to your user, but doing that instead of as a build step ahead of time, doing that just in time on first requests,” Dahl said.

Predictions for the Future

The panel offered future predictions for how the edge would change development. More web frameworks will target the edge use case, Dahl said.

“Coming back to the state, like either getting the runtime close to the state, … or getting the data closer to the runtime itself is also an important thing that is going to be worked out,” Dahl said. “We’ll see more iteration in how you manage state in these edge runtimes.”

Biilmann predicted that companies will build their APIs to be run on the edge out of the box, to ensure that APIs can respond fast globally, as well as new patterns around how caching is done.

There will be more focus on streaming technologies and patterns, suggested Pai.

“There are technologies that [have] been there for a bunch of years, which is streaming responses, but nobody really knew how to use it,” Pai said. “Frameworks are now taking that abstraction for you and edge runtimes, it turns out, are a great way to do it. So your React applications now start way faster because they can send a few bytes and your head tags before they even start rendering the rest of the page. Streaming patterns for APIs and web pages seem to be a thing to keep an eye on.”

The post Jamstack Panel: How the Edge Will Change Development appeared first on The New Stack.

Kelsey Hightower is a minimalist. As such, he likes to tease through the noise and focus on what problem a solution is trying to solve.

“When people really scope it down to the problem we’re trying to solve, when you say DevOps or you hear some new fancy deployment tool, or CI/CD, you’re like, ‘Okay, what’s the problem?’” Hightower, a distinguished engineer at Google and a full stack developer, told The New Stack. “The problem is, we’re trying to take code that I’ve written and put it on the server so people can use it. It’s a very minimalist way of understanding it.”

Taking that approach, it becomes clear that sometimes people lose sight of the original goal, he said. Focusing on that can be very clarifying, he explained.

“Whenever you do minimalism, this is how you end up with serverless,” he said. “Everyone wants a server; you go to Dell, HP, you buy the server, you plug it in, the server gets bigger, it consumes more power, Intel has more chips, you’re putting all this stuff there. And now you need a config management system to manage the server. What was the goal again? Wasn’t the goal to write the app and give it to the customer?”

Hightower, who helped establish the KubeCon conference, said there’s a simplicity to the paradigm that uses APIs, services and containers to manage services.

He sees a need for simplicity in software design, however.

“In software, we don’t do that [simplicity], because it’s like clay, you can do whatever you want — and without those constraints, people end up doing whatever they want and they create complexity, because it will still work,” he explained.

Hightower on Next.js 13

The New Stack spoke with Hightower at Vercel’s Next.js conference in San Francisco. He’s an advisor to Vercel and was at the conference to answer questions about the latest release.

He offered an analogy to explain what Vercel is trying to do: If the web is the new computer, with the edge functioning as middleware, and cloud providers functioning as data centers, then Next.js is aiming to be the operating system. Where does Next.js 13, released last week at the conference, fit in? It’s progress, he said.

“With any ecosystem, you want to see a stable release cadence. Why do you think the new iPhone 14 looks like the old iPhone, right? […] We don’t always want huge jumps, because the problems that we’re trying to solve now are very specific,” he said. “It’s not like we’re trying to create Next.js from scratch again. We’re trying to address the problems that were there with 12.”

It’s also faster at rendering, thanks to TurboPack, he noted, which is key to supporting collaboration. Thirty minutes to render deters software developers from trying new tactics; so with faster rendering, developers are more likely to experiment.

One feature he questioned at first was the image optimizer.

“I looked at that feature — like, why is this a bullet point? Who really cares, right? It’s just a thing where you can put images in a webpage. We’ve always done that,” he said.

But after watching the videos and tutorials, he realized it was a significant announcement because it improves performance, which Google tests for rankings, and it impacts the user experience. There’s also a real cost in terms of how fast the website loads — and serving images from CDN isn’t free, he added. The bigger the image, the more sites have to pay.

“What they do now is say, Hey, we’re going to take that image thing that was working and we’re going to give you all the best practices that the big web companies know how to do,” he said. “When you check in that image, and you’re using Next.js’ framework, we’re going to do all the right things, like resizing the image.”

These best practices ensure the image loads fast, even on a mobile device on 3G.

“Just that little functionality, someone that has written a bunch of code to do that — nothing makes an engineer feel better that I can delete all of that code and just do this,” he said. “That’s a game changer.”

Minimalism in JavaScript

I asked Hightower whether there’s more room for minimalism in JavaScript.

“Yes, I think so,” he said. “What does minimal look like in JavaScript? JavaScript is a tool to create experiences in the browser — because if it was just information, then HTML would just be fine.”

JavaScript by its nature minimizes the work developers have to put into create these experiences, he pointed out. For instance, to import a location, developers just call the JavaScript function location to get back the location from the browser, rather than write hundreds of lines of codes to do that.

“JavaScript is kind of like English: Anyone’s free to create new words — doesn’t mean it’s going to catch on. Sometimes we find the perfect word that means so many things, and then you get to start using it, but it doesn’t mean all the other words are gone,” he said. “That’s the way I see JavaScript itself, its raw essence is just this low level thing that allows you to create experiences in the browser.

“So the answer to your question is yes, but it will be answered by 50 different people and you have to pick the one you want,” he said.

That’s why there will always be more than one JavaScript framework, he added.

“There will be never be one because the experience keeps changing,” he said. “We like that, as humans, because we want to hear something new. … It will never stop. But do we want it to? I don’t think we actually want it to.”

Vercel paid for travel and accommodation for Loraine Lawson to attend the conference.

The post Kelsey Hightower on Software Minimalism and JS Frameworks appeared first on The New Stack.

This is part of a series of contributed articles leading up to KubeCon + CloudNativeCon on Oct. 24-28.

Serverless application stacks have been stuck in a conundrum: Most applications need some kind of state store, but most state stores aren’t serverless. Rich data applications like payment apps, buy online/pick up in-store services and real-time online sports betting are incompatible with fully serverless architecture simply because, at some point, the database becomes a bottleneck.

With a serverless application, your scalability depends on your cloud provider’s ability to spin up more nodes as your load grows. Without a scalable database to receive the load from the application, though, at some point, there is not enough data-handling capacity to accommodate the current volume of traffic. When this happens, the bottleneck shifts directly to the database and the flow of data is impaired, or even stopped entirely, with potentially disastrous results.

There are, of course, distributed databases that can scale out automatically to meet increasing demand. The problem? Almost every distributed state store on the planet has a minimum scale required to operate. This is fine for users who already know they have a large-scale problem. But, when you’re just getting started, the cost in both time and money to ensure your application can scale out later is prohibitive when what you need most is to build a minimum viable product (MVP) as rapidly as possible.

Resolving the dilemma between scaling vs. starting when building a stateful, ground-up serverless application requires a serverless distributed database with true “scale to zero” capability. One that can automatically scale up and down to accommodate workload demand, while charging only for the amount of compute actually consumed. The first to deliver the ability to build fully stateful applications in a fully serverless way was CockroachDB Serverless.

KubeCon + CloudNativeCon conferences gather adopters and technologists to further the education and advancement of cloud native computing. The vendor-neutral events feature domain experts and key maintainers behind popular projects like Kubernetes, Prometheus, Envoy, CoreDNS, containerd and more.

Learn More

The latest from KubeCon + CloudNativeCon

Hello, CAKE Stack

Building fully stateful serverless applications require a new approach to your application stack, and so today we introduce the CAKE stack.

C — CockroachDB Serverless
A — Authorization, authentication, session and user management
K — Kubernetes
E — Event-driven serverless platforms

C Is for CockroachDB Serverless

To power these next-generation serverless applications, we need a database that solves your scale-up and scale-down problems. And it needs to be a consistent data store so you can use it for your most business-critical applications. CockroachDB serverless does all of these things and more, all while giving you a generous free hosted scale with your workload serverless offering.

A Is for Auth

To enable all those different endpoints to have common access controls, we also need next-generation authorization, authentication, session and user management. Platforms like Keycloak and Authzed enable distributed session management for centralizing access across multiple frontends, all in a container-native way. When using CockroachDB as the backing store, it becomes resilient and redundant across instances with no potentially complex backend configuration changes required.

K Is for Kubernetes

Distributed systems are inherently complex, so we need a way to orchestrate all the moving pieces. The essential anchor of our new stateful serverless stack is Kubernetes, since the big K8s vendors are offering dynamic, low-friction scaling mechanisms for our orchestration layer. This allows us to move away from any serverless platform that would lock us into a specific Infrastructure as a Service. It instead gives our stack full portability across data centers, cloud regions or even cloud providers so we can spin up resources as close to our users as possible.

E Is for Serverless Frameworks

Of course, we need to host and deploy our serverless, event-driven architecture. At this point in the stack there are two moving pieces to select: serverless frontend and backend frameworks. For our presentation layer, we need a distributed hosting and content delivery platform to operationalize our data and make it available over APIs for ease of use. A platform like Directus or Vercel (both of which have added native CockroachDB support to their offerings recently) enables centralized data access across multiple consumption modes — native application, web, mobile, IoT, etc. — and built-in serverless functions. Put another way, it makes it easy to just code against the data in our database instead of having all our microservices talk to the database directly.

On the backend, platforms like Knative enable our serverless deployment workflow, allowing individual event processing pipelines and functions to scale elastically as required to meet user demands. No more tightly-coupled application monoliths or even complex services that still require intervention to scale. Now, each atomic function or workflow can scale up, and down, as necessary. No more overprovisioning for burst events and no more paying for unused capacity.

(And M Is for Modular)

The great thing about the CAKE stack is that it’s fully modular. Don’t like Knative? Use Lambda or Cloud Functions. Not a fan of Keycloak? Integrate with your favorite authentication platform. Now that we have the missing-link power of a truly serverless database at our fingertips, we can unlock the full potential of fully serverless applications. Let’s look at an example.

Imagine you’re building a platform that enables florists to work with local delivery drivers to supply fresh bouquets to local homes and businesses. This business is very bursty: Valentine’s Day is going to bring peak workloads, as are mornings on most business days. But you really don’t need much running overnight.

To start, you might just be working with a handful of drivers and florists in a single town. Your MVP certainly doesn’t need the infrastructure to run this nationwide during your initial launch. But, if you don’t build it that way from the start, you’ll have to re-architect when your business catches on coast-to-coast and you need to scale out. Using the CAKE stack, though, means that your apps, your data and your location all scale right along with your business and your usage — all in real time with no intervention, and also without running a bunch of infrastructure you don’t yet need in the meantime.

Architecting an app for scale from the start used to mean choosing between starting fast now vs. scaling fast later. Either taking on the complexity and cost of distributed architecture before you even have your first customer or starting out with an enormous amount of technical debt that can cause you to fail to scale once your customers do begin pouring in, or requiring massive rearchitecting.

Now, however, the serverless universe has matured to the point where you can start with a configuration that will meet your needs for the long term. All of the elements of the CAKE stack we have named here are even free to get started, with costs eventually incurring once your usage goes up, rather than having to pre-pay for a bunch of dormant infrastructure. Building an application using the CAKE stack means performance and costs scale so you can focus on onboarding the most important asset of all: your customers.

To hear more about cloud native topics, join the Cloud Native Computing Foundation and the cloud native community at KubeCon + CloudNativeCon North America 2022 in Detroit (and virtual) from Oct. 24-28.

The post Have Some CAKE: The New (Stateful) Serverless Stack appeared first on The New Stack.

Hazelcast has a vision of democratizing real-time data processing and management, and the key to this strategy is the company’s Viridian Serverless offering.

Launched in beta at the end of July, Viridian Serverless is a self-service provisioning process where the cluster grows and shrinks automatically based on the workload, said Manish Devgan, chief product officer at Hazelcast. The service provides users with quick access to a horizontally scalable real-time data platform that includes a high-speed data store and stream processing capabilities.

Perfect for Hazelcast

Thus users can speed up app development, simplifying provisioning, and enabling flexible integration of real-time data into applications, Devgan said. With the service handling all underlying hardware configuration and any operational complexity, users can deploy a functional cluster in seconds. Moreover, the service helps organizations avoid over- and under-provisioning, and users can get started immediately with the free-for-life tier. At launch, Hazelcast said it would provide users with a limited-time offer of up to 2 Gibibytes (GiB) of data storage at no cost. This offer is still valid.

“Serverless is perfect for Hazelcast since they support extremely low-latency workloads that often oscillate wildly from a trickle to a thunderous rush of event data,” Mike Gualtieri, an analyst at Forrester Research, told The New Stack.

Without serverless the only possible way is to build a cluster with enough headroom to handle the largest expected load — or manually reconfigure clusters which is labor intensive, he noted.

“The serverless approach enables always right-sized compute, storage, and network resources without wasting electricity, cooling and thus cost,” Gualtieri said. “Serverless is not new or novel, but it is a particularly good architecture for Hazelcast Viridian because of the latency and throughput workload variability.”

ScyllaDB is the database for data-intensive apps that require high throughput and low latency. It harnesses the ever-increasing computing power of modern infrastructures–eliminating barriers to scale as data grows. Game-changing companies use ScyllaDB for their toughest database challenges.

Learn More

The latest from ScyllaDB

While large enterprises with lots of developers, DevOps teams and SREs are equipped to stand up their own platform on a public cloud or in their own data center. “But not everybody can do that,” Devgan said. “Not everybody has 20 developers working on a real-time application and having to manage all this. So for those customers, we basically are targeting this offering where it’s a service offering. We basically want to democratize this real-time aspect of the economy.”

Getting Unpredictable

However, Hazelcast Viridian Dedicated is a managed, single-tenant cluster designed for organizations that have clear, predictable usage models and want precision control over their own clusters. Meanwhile, users can choose the serverless model for development and unpredictable production workloads, though customers requiring an enterprise-grade solution for production and predictable workloads will likely choose Viridian Dedicated for their company’s needs.

“If your workload is unpredictable, that’s when you would use Viridian,” Devgan told The New Stack. “And you want to build your application as quickly as possible. You don’t have to decide upfront, how many nodes in a cluster you need, you basically answer a few questions, and we will do the sizing under the hood for you.”

The pay-as-you-go model also benefits users who want to get started quickly and use the resources they need.

“When the serverless approach started a few years ago, it was mainly limited to stateless applications. However, we now see an increasing number of data management tools adopting this model,” said Sanjeev Mohan, principal and founder at SanjMo. “There are many benefits, such as optimized resource usage, decreased complexity of configurations, pay-per-use pricing, and scalability. We see this trend continuing as more databases announce their serverless capabilities.”

What’s Inside

Features include:

• Self-service sign-up with a free-forever tier that will include a limited-time offer of 2GiB of in-memory storage
• Familiar, declarative API for building applications that leverage real-time streaming data
• Support for streaming SQL to enable a large base of developers to run queries on real-time data
• Out-of-the-box connectors to multiple cloud data sources, and an API for building custom connectors to any other data source
• Integration with cloud deployments of popular data technologies, such as Apache Kafka
• WAN replication capabilities that enable data integration across cloud deployments to support geo-distributed systems and disaster recovery strategies
• Change data capture (CDC) technology to allow real-time responsiveness to data updates

The Hazelcast Platform

“Real-time applications are hard to build on traditional data platforms, forcing businesses to compromise on their strategic aspirations,” Devgan said in a statement. “Hazelcast Viridian Serverless is the next step in providing a truly real-time cloud, all while making it even easier to develop, configure and deploy innovative applications.”

Hazelcast competes with the likes of Redis and Aerospike, which are data platforms that provide very similar, low latency access to data. But they don’t they don’t do streaming.

The Hazelcast Viridian products are powered by the Hazelcast Platform, a real-time data platform and integrated runtime that combines distributed stream processing and real-time data management to automatically act on discovered patterns, trends, and anomalies, the company said. This eliminates functions that create bottlenecks in other architectures, including database writes, batch processing, and the need for human intervention.

“The days of nightly batch jobs are numbered,” Mohan told The New Stack. “A huge need in the market is to make decisions on the most recent data. To enable real-time analytics, we not only need the right data platform, but also a serverless data infrastructure. Hence, Hazelcast’s serverless option will help its customers increase development agility and deployment of their real-time applications.”

Moreover, Hazelcast has two popular open source projects. One is in the data management space — the company’s eponymous in-memory data grid. And the other big project is the Jet project, which is a streaming analytics engine.

“Imagine you’re writing a real-time application, and you’re able to do like a join of the data at rest, and also data in motion,” Devgan said. “There are a lot of use cases like this around — being able to do real-time analytics while the data is flowing in, and while doing that also pull contextual information for that event which is happening in real time.”

Use Cases, Availability

A typical use case for Viridian Serverless would be a bank extending an offer or coupon while a customer is banking or detecting a fraudulent event, Devgan said.

Indeed, from banking to retail and an increasing number of other industries, the adoption of serverless architectures continues to grow. In fact, 40% of enterprises using cloud native technologies are also using serverless, according to Cisco’s “2022 Global Hybrid Cloud Trends Report.”

According to Hazelcast, the Viridian Serverless offering is applicable to digital integration hub pattern architectures, enabling companies to capture data from numerous sources and correlate the data immediately to create enhanced context for end users. With this architecture, companies can gain a 360-degree customer view, track assets in real-time, prevent fraudulent transactions, deliver personalized recommendations, create real-time promotional offers, and more, the company said.

Also, the Hazelcast Serverless service is applicable to stream processing environments that are the foundation for payment processing, Internet of Things analytics, and microservices messaging.

The service is available on AWS, with availability on Google Compute Platform (GCP) coming soon. Hazelcast Viridian Dedicated is available on Microsoft Azure, but the serverless version is not yet available, Devgan said.

The post Hazelcast Aims to Democratize Real-Time Data with Serverless appeared first on The New Stack.