Board

The ability to combine the functionality of multiple services by weaving together their APIs is a powerful skill, and it's becoming a more common method of building workflows, processes, and even entire products. I've heard it referred to as 'Vendor Engineering', which I think is an over-simplification of a complicated practice.

In my head, this new evolution is 'Domain-Specific Serverless' (DSS). The idea boils down to allowing users to write code that tightly integrates with a product - because it runs within it. By re-imagining integrations as serverless functions that users have full control over, we allow them to be expressed with the highest level of customization.

If SaaS products begin embedding serverless capabilities directly, it allows users to take full advantage of their offerings without needing to undergo the huge lift of developing custom software. This is the key advantage of DSS; a tight integration between the business logic of an application and the execution of users' serverless functions, making it possible to customize a product with little effort. Not to mention the vast performance and security benefits this method has over traditional webhooks.

We remove some limits you have in current offerings, where end users have to select a specific cloud technology between functions and containers, when they just want to be able to, for instance, process images and videos. We are letting them select the technology which is the most suitable depending on their needs.”

With the newly launched ability to run both on the Koyeb Serverless Engine, Léger says they hope to ease the developer experience, allowing users to run whatever code they have, without having to worry about time limits or compatible runtimes.

The more we can remove unnecessary abstractions, the closer we can get to the concept of "The Network Is the Computer". Cloudflare Workers is essentially an implementation of this concept in the Cloudflare network. Deno Deploy is a new implementation of this idea (on the GCP network).

At Deno we are exploring these ideas; we’re trying to radically simplify the server abstraction.

In this emerging server abstraction layer, JavaScript takes the place of Shell. It is quite a bit better suited to scripting than Bash or Zsh. Instead of invoking Linux executables, like shell does, the JavaScript sandbox can invoke Wasm. If you have some computational heavy lifting, like image resizing, it probably makes sense to use Wasm rather than writing it in JS. Just like you wouldn’t write image resizing code in bash, you’d spawn imagemagick.

Why is Rust now being used to replace parts of the JavaScript web ecosystem like minification (Terser), transpilation (Babel), formatting (Prettier), bundling (webpack), linting (ESLint), and more?

t knows when the program is using memory and immediately frees the memory once it is no longer needed. It enforces memory rules at compile time, making it virtually impossible to have runtime memory bugs. You do not need to manually keep track of memory. The compiler takes care of it.

Rust has been a force multiplier for our team, and betting on Rust was one of the best decisions we made. More than performance, its ergonomics and focus on correctness has helped us tame sync’s complexity. We can encode complex invariants about our system in the type system and have the compiler check them for us. – Dropbox

Millions of lines of code have been written and even more bugs have been fixed to create the bedrock for shipping web applications of today. All of these tools are written with JavaScript or TypeScript. This has worked well, but we've reached peak optimization with JS. This has inspired a new class of tools, designed to drastically improve the performance of building for the web.

SWC, created in 2017, is an extensible Rust-based platform for the next generation of fast developer tools. It's used by tools like Next.js, Parcel, and Deno, as well as companies like Vercel, ByteDance, Tencent, Shopify, and more.

While WASM isn't the perfect solution yet, it can help developers create extremely fast web experiences. The Rust team is committed to a high-quality and cutting-edge WASM implementation. For developers, this means you could have the performance advantages of Rust (vs. Go) while still compiling for the web (using WASM).

Once you're on native code (through Rust, Go, Zig, or other low-level languages), the algorithms and data structures are more important than the language choice. It's not a silver bullet.

Even though learning Rust for JavaScript tooling will be a barrier to entry, interestingly developers would rather have a faster tool that's harder to contribute to. Fast software wins.

Currently, it's hard to find a Rust library or framework for your favorite services (things like working with authentication, databases, payments, and more). I do think that once Rust and WASM reach critical adoption, this will resolve itself. But not yet. We need existing JavaScript tools to help us bridge the gap and incrementally adopt performance improvements.

I believe Rust is the future of JavaScript tooling. Next.js 12 started our transition to fully replace Babel (transpilation) and Terser (minification) with SWC and Rust. Why?

Regardless, I'm confident Rust will continue to have a major impact on the JavaScript ecosystem for the next 1-2 years and into the future. Imagine a world where all of the build tools used in Next.js are written in Rust, giving you optimal performance. Then, Next.js could be distributed as a static binary you'd download from NPM. That's the world I want to live (and develop) in.

These infrastructure providers, on average, are growing quicker than their SaaS counterparts in the public markets. 7 out of the top 102 fastest growing cloud businesses with over $500M in revenue are infrastructure-related ones.

The alternative, which is the fragmented market of today, enables teams to purchase best-of-breed point solutions, try them, and quickly cycle through all the different offerings until they find the best one for their needs. This change in purchasing behavior is happening broadly across SaaS.

But these are tractable challenges in the market that values piecing together an optimal software stack. At least for the moment, I expect to see further and further fragmentation in the software landscape, enabled by APIs.

Software is eating the world. Software now defines the speed of innovation and continues to differentiate the winners from the losers. Digital transformation continues to be key to survival for established companies. The winners don’t just need to be capable of building software; they need to be exceptional at it. Software development consistently requires more scale and more speed. Today, over 70% of DevOps teams release code as frequently as once a day, up 11% from 2021.

DevOps is a cultural shift that touches a variety of steps within the software development lifecycle. There currently isn’t a single all-encompassing platform to cover the entire scope. DevOps teams usually put together a customized toolchain to connect the various people and workflows that consist of open-source and vendor tools. The output from one is an input for another, and so on. That leads to a very fragmented vendor landscape.

Software, overall, has become increasingly fragmented as users take advantage of the opportunity to test out best-in-class solutions. As the speed of software production cycles increases, the need for a seamless toolchain has become increasingly important. Determining which DevOps tools an organization will use can be complex given the multiple stakeholders involved. Executives want to ensure uptime and control costs, while developers are focused on performance and ease-of-use.

s cloud computing emerged, so did GitHub, which has become the largest cloud-based platform that extends the benefits of Git.

As cloud computing emerged, so did GitHub, which has become the largest cloud-based platform that extends the benefits of Git.

As DevOps becomes the de facto methodology for producing software, more players have looked to extend their platform. GitLab has held a unique position in the market by clearly stating early on that they were trying to build an open core platform to extend across the DevOps lifecycle.

HashiCorp pitches all their products as multi-cloud, which positions them favorably for developers and engineers who have to deploy across multiple different cloud providers. Similar to GitLab, HashiCorp makes its code viewable to their open-source community, which has a number of benefits including enhanced security (i.e. bugs are found quicker) and higher quality software that will benefit from continuous improvement. Thousands of developers have contributed to its development and will continue to look to optimize the code.

CircleCI is one of the only CI/CD tools to get certified by FedRAMP. It supports isolated execution environments including Docker, Linux, macOS, Android, Windows, and self-hosted runtimes.

Developer productivity has been placed front and center as the speed of deployment has increased. Every company feels resource-constrained when it comes to developers’ time. Adding more software engineers isn’t a scalable fix, and we’re also seeing demand exceed supply. Some sources estimate the shortage of software engineers will reach over 80 million by 2030. Companies are doing everything they can to increase the capacity of their developers.

GitHub, Atlassian, Microsoft... They’re trying to get everyone to adopt a unified tool system. But most people still go with best-of-breed, as far as tools go. The idea, though, is that some people will eventually go with more of a “you can’t get fired for buying IBM” approach, where you buy everything from a single vendor."

With the advances in [ML-enabled software development], we believe that programming should become a semiautomated task in which humans express higher-level ideas and detailed implementation is done by the computers themselves.”

Up to this point, cloud computing has been the key to unlocking rapid software development. Access to the very best tools and resources has increased developers ability to build exceptional software, and to do it quicker than ever. Those same capabilities, however, have also led to dramatic complexity in the development process. DevOps is the solution to the problems that speed without infrastructure created.

The future of DevOps is the future of software development. Last year, VCs invested $37 billion into companies building developer tooling. The demand for software, and for software developers to build that software, is only going to increase. A massive opportunity exists for the platforms that can become the central building blocks of that increasingly important process.

“90% of our users will never pay us, and that’s by design. It’s really important for us to have a healthy open source community. That’s mission number one.”

Given how much of Grafana’s competitive advantage comes from the quality of their open source community, there is a constant need to maintain the relationship that the company has with the community. Every open source company has to find this same balance between building proprietary functionality while still maintaining the flexibility inherent in their open source model.

The most prominent case was when Amazon AWS (using Elastic’s open-source software, OpenSearch) released a data search tool directly competing with Elastic. In response, Elastic announced plans to change its software license to prevent AWS from using its software. Amazon responded by announcing plans to fork Elastic and maintain the software as a ‘truly open-source option.' All open-source software platforms face the risk of strip mining. Grafana Labs’ open-source offerings are no exception. For monitoring, this threat is lessened because the public cloud vendors have their existing solutions and it's a question of competitiveness vs. replication.

Microsoft has a path to becoming the source of truth for customer data through Azure, which would make it mission-critical to all business software. If Microsoft convinces customers to store their customer data in an Azure warehouse (enriched by LinkedIn’s data) instead of a CRM, then the CRM becomes a simple window through which companies access customer data. Other business applications would then build on top of Azure, not Salesforce. If Microsoft divorces the CRM from the customer data system of record, it commoditizes its complement to beat Salesforce.

But modern teams don’t choose Microsoft, opting for the modern data stack of Fivetran + dbt + Snowflake. Is there a chance Microsoft can win them over?

But owning GitHub doesn’t immediately translate into young developers that love Azure. Microsoft’s task is to gracefully harness its newfound developer love. But you can’t force love, like Google tries to force Meet on its unsuspecting users. Microsoft needs deeper OSS support and developer tooling before pushing users towards Azure.In other words, Azure needs organic adoption to fully penetrate the enterprise.

Execution is critical, but riding an S curve is the path to win in tech.

Traditional wisdom tells us that founders are the only determinant of startup success. Great founders are necessary but not sufficient. Great product theses and fast-growing categories are increasingly the true bottleneck.

The classic consideration for VCs is whether incumbents can copy the startup’s technology before the startup copies the incumbents' distribution. For the past 20 years, the answer was almost always no – startups achieved escape velocity across categories, seemingly immune from incumbents’ distribution power.

Megaproject success can be hard to see when it happens within large companies. Azure and AWS are two of the most successful megaprojects of this century, but were hidden from the public for years, nested inside much larger corporations. Starlink, the global satellite internet network, is only possible given the scale of SpaceX’s core launch business, but could be one of the most successful megaprojects of our time.