DEV Community: Pablo Bermejo

Experimenting with every Next.js 14 rendering option: From SSG to Partial Pre-rendering

Pablo Bermejo — Mon, 22 Jan 2024 10:51:50 +0000

Why am I doing this?

Early this year, I migrated Octotype (a blogging platform I created using GitHub Issues as a headless CMS) to Next.js 14. The migration experience itself was great, and working with the new App Router and React Server Components was bliss. The mental model these two new paradigms bring to the table is absolutely a step in the good direction for a better DX (and, therefore, for a better UX).

Because Octotype does not have a database and relies fully on a 3rd-party API (GitHub API), I got obsessed with fine-tuning the site's performance to the maximum. Little did I know that I got drunk with options, and I struggled to understand the differences between all of them:

Static Site Generation (SSG)
Incremental Site Regeneration (ISR)
Traditional Server-side Rendering (SSR)
Streaming
Partial Pre-rendering (PPR)
Bonus: Single Page Application (SPA)

After a few days, I finally figured it all out (or that's what I think 😇), so here I am sharing what I have learned. This is a summary of all the rendering options brought to the table by Next.js 14, and during this post, I'll direct the tradeoffs of each one of them with real code examples and videos.

Note: All the examples revolve around loading a user page that contains all their blog posts. The page renders a header with the user name and uses a React Server Component to fetch and render the user's posts. I have mocked a slow 3G connection in all the videos to make conclusions more evident. Also, I used Vercel to deploy my site.

Let's get into it!

1. SSG

One of the first lessons I learned is that Next.js pre-renders your site entirely at build time by default. This means that even if you use React Server Components, the server is the CI server. It will both fetch data and render HTML on the server at build time, so the browser will just need to download static files (HTML, CSS, and Javascript).

This is what we call Static Site Generation because now your entire site is static.

Note: I believe that even if Next.js would still create static output, it would also generate a Node.js server that serves that static output. This is why, by default, SSG mode in Next.js emits a Node.js app. Or that's what Dan says.

Here are some examples. This is how my user page looks like with SSG. Nothing is magical here; it's just a normal Next.js page using a UserPosts RSC.

app/[user]/page.tsx



import { UserPosts } from '@/components/server/user-posts'

export default async function Page({params}: Props) {
  return (
      <div>
         <h1>
           {params.user}.
         </h1>
         <UserPosts user={params.user}/>
      </div>
  );
}

This is what my UserPosts RSC looks like with SSG. All it does is call a getUserPosts() function to fetch posts (yes, usingNext.js augmented fetch()) and pass the data down to a UserPostsGrid client component for final rendering.

components/server/user-posts.tsx



import { UserPostsGrid } from '@/components/client/user-posts'
import { getUserPosts } from '@/lib/api.ts'

const UserPosts = async ({ user }: Props) => {
    const posts = await getUserPosts(user)
    return (
        <div>
            {posts.length > 0 && <UserPostsGrid posts={posts}/>} 
        </div>
    )
};

export {UserPosts}

As you can see in the video, the navigation is pretty fast.

SSG Video

And this is why it's fast. At run time (time arrow), all the browser does is download static content because the actual data fetching and rendering has been done at build time. Put in a graph, SSG can be represented like this:

PROS
✅ Amazing performance with a ver low loading time.

CONS
❌ I don't have dynamic data! If the user writes a new blog post, I need to build the site (manually or force a build) so it can be included in the static output

It would be nice if I could configure my app to automatically build the site every x seconds to guarantee fresh data at a given time.

Well, enter Incremental Site Regeneration.

2. ISR

Incremental Site Regeneration allows you to configure your site to generate a static output automatically at a given configurable frequency.

And this is where I started to get drunk with options. The thing is, Next.js is super-flexible and allows you to define what is that static output. In other words, you can configure your revalidation frequency at the page, component, or the fetch request levels.

Because I am a big fan of React's component-driven model, I started putting it at the component level. I leveraged the new Next.js 14 cache() function available in the next/cache package. It's unstable, but my site is simple, and I have yet to find any problems. This implementation basically follows a stale-while-revalidate pattern, where you specify your data fetching function, tag your cache, and establish your revalidation frequency. I love this pattern because it serves you stale data for a period until it's time to serve fresh new data, which has been fetched in the background by the Next.js server.

This is what my UserPosts RSC looks like with an ISR of 1 hour. No changes are needed to my user page.tsx.

components/server/user-posts.tsx



import { UserPostsGrid } from '@/components/client/user-posts'
import { getUserPosts } from '@/lib/api.ts'
import { unstable_cache } from 'next/cache';

const revalidateUserPosts = unstable_cache(
  async(user) =>{
    return await getUserPosts(user)
  },
  ['user-posts'],
  {
    revalidate: 3600
  }
)

const UserPosts = async ({ user }: Props) => {
    const posts = await revalidateUserPosts(user)
    return (
        <div>
            {posts.length > 0 && <UserPostsGrid posts={posts}/>} 
        </div>
    )
};

export {UserPosts}

PROS
✅ Amazing performance for cache hits

MEHS
🔶 Eventual fresh data

CONS
❌ Mediocre performance for cache misses
❌ Data is not fresh on demand

ISR is great for many use cases, and I actually use it in other parts of Octotype. However, if you (like me) are unwilling to pay the costs of these tradeoffs and always want fresh data at particular parts of the application, you may want to render your content dynamically on demand.

Now, enter Server-side Rendering.

3. Traditional SSR

This is equal to the traditional rendering model (PHP, JSP, ASP, etc.), where your data is fetched at the server, and your page is rendered based on that data. The client then downloads a fully operational page and hydrates it so the user can start working with it.

I won't enter into debates about if Next.js is reinventing these other technologies mentioned above. The main difference for me is the ability to combine server-side rendering with rich client interactivity following a component-based model (not MVC, there are no views here) where your UI is expressed declaratively. That mental model, for me, is a perfect fit.

Now, this is what my UserPosts RSC looks like with SSR. No changes are needed to my user page.tsx. I only had to stop using the cache() function and start using the new noStore() function. This forces my component to be completely dynamic and always fetch data on demand. Again, Next.js allows you to define this dynamism at the page, component, or fetch levels, but you already know my choice and way.

components/server/user-posts.tsx



import { UserPostsGrid } from '@/components/client/user-posts'
import { getUserPosts } from '@/lib/api.ts'
import { unstable_noStore } from 'next/cache'

const UserPosts = async ({ user }: Props) => {
    unstable_noStore();
    const posts = await getUserPosts(user)
    return (
        <div>
            {posts.length > 0 && <UserPostsGrid posts={posts}/>} 
        </div>
    )
};

export {UserPosts}

With this change, the navigation to this page isn't that fast. I am always getting fresh data at the expense of loading time. But this comes with a caveat; now, because I am using a dynamic component through the noStore() function, my whole page route becomes dynamic, as you can see in this video:

SSR Video

If we put this in a graph, this is happening.

PROS
✅ Always fresh data
✅ Better perceived performance

CONS
❌ Performance could be not great for huge data loads or slow data connection links
❌ By using a dynamic component, my whole page route becomes dynamic

I think people working at Next.js realized these tradeoffs and asked themselves: "Why do data fetching and rendering have to be sequential?" If you look at the UserPosts RSC code above, the server first fetches the posts and only then starts rendering the content. It means rendering is blocked by data fetches, but not all that content depends on data! If only there were a way to parallelize some of the things that happen at the server!

Enter Streaming.

4. Streaming

Streaming is like chopping up your data into chunks and sending them over progressively from the server to your screen. This way, you're not stuck waiting for everything to load before you can use the page. You get to see and mess around with parts of the site without hanging around for every piece of data to appear.

I like this approach because, in my mind, a chunk equals a component. This is the mental model I use, so this thing immediately clicked for me.

In my code, all I had to do to enable streaming when I deployed my site on Vercel was add Suspense boundaries around my RSC. Practically, this means adding a <Suspense> tag with a fallback, which is a component that will be rendered while my RSC gets processed (i.e., data is fetched and HTML is rendered) in parallel.

This is all it takes to enable streaming. There are no changes to my RSC, just a tiny change to my page.tsx:

app/[user]/page.tsx



import { UserPosts } from '@/components/server/user-posts'
import { UserPostsSkeleton } from '@/components/skeleton/user-posts'

export default async function Page({params}: Props) {
  return (
      <div>
         <h1>
           {params.user}.
         </h1>
         <Suspense fallback={<UserPostsSkeleton />}>
            <UserPosts user={params.user}/>
         </Suspense>
      </div>
  );
}

As you can see in this video, there is an improved real and perceived performance when loading the user posts. The page is shown faster, and a skeleton is rendered while the data is loaded and streamed in parallel. This is because the JSX inside the return statement is processed parallel to the UserPosts RSC processing (data fetching and rendering).

Streaming Video

This graph explains what's going on behind the scenes. As you can see, there is a substantial gain in performance, and the user can start interacting with the page sooner, compared to SSR:

The skeleton is shown during a brief time interval. This is because the amount of data fetched on the server is not huge, and the connection link to the GitHub API is fast. It means that the time difference between the shell page being ready on the client (rendered on the server and then downloaded in the browser) and the RSC being ready on the client (rendered on the server and downloaded in the browser) is very small.

PROS
✅ Always fresh data
✅ Even better perceived performance

MEHS
🔶 There is still a time gap between the user clicking a link and the shell page being displayed on the browser, although content chunks keep streaming

CONS
❌ By using a dynamic component, my whole page route becomes dynamic

Again, the folks at Next.js put their thinking hats on and asked themselves: "Why does the whole page route need to be dynamic?," "Can't we combine the best parts of SSG for the static parts and the best parts of streaming for the dynamic ones?".

Yes, we can. Enter Partial Pre-rendering

5. Partial Pre-Rendering

I'll quote the Vercel folks on this one:

When you build your application, Next.js will prerender a static shell for each page of your application, leaving holes for the dynamic content. When a user visits a page, the fast static shell is served from the end-user’s nearest Edge Region, allowing the user to start consuming the page and the client and server to work in parallel. The client can start parsing scripts, stylesheets, fonts, and static markup while the server renders dynamic chunks using React’s new streaming architecture.

In other words, the static parts of your page route are pre-rendered. This can be done at build time (SSG) or even based on revalidation frequency (ISR). Then, the dynamic parts of the same page route are streamed once the initial page shell has been loaded.

This is the only change I needed to make it work in my app on top of streaming. Nothing else, and you can see, it's still experimental.

next.config.js



/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    ppr: true,
  },
}

module.exports = nextConfig

Because the page shell has been pre-rendered, the first-page load is lightning fast as it is a pure static output served from a CDN. See this behavior in action in the following video:

PPR Video

Compare this graph with the others above! This is really amazing:

With PPR, the skeleton is shown during a longer interval. This is because the skeleton has been pre-rendered with the page shell and included in the static output, which means it's available at the client way sooner. This has an incredibly positive impact on perceived performance.

PROS
✅ Amazing performance, real and perceived, with always fresh data.

CONS
❌ It's experimental 🤷🏻‍♂️

Bonus: SPA

All the options described above involve some server-side rendering in one form or another with Next.js. These are all default features of the framework, which does not mean you can't do a SPA with Next.js. You can, but it isn't obvious, as it requires some additional work outside the responsibilities of the framework.

Let me explain.

First, you must translate your RSC into a client component and fetch data using React classic hooks, useState and useEffect. Nothing special here.

components/client/user-posts.tsx



import React, { useEffect, useState } from 'react';
import { UserPostsGrid } from '@/components/client/user-posts';
import { getUserPosts } from '@/lib/api.ts';

const UserPosts = ({ user }) => {
    const [posts, setPosts] = useState([]);

    useEffect(() => {
        const fetchPosts = async () => {
            const fetchedPosts = await getUserPosts(user);
            setPosts(fetchedPosts);
        };
        fetchPosts();
    }, [user]);

    return (
        <div>
            {posts.length > 0 && <UserPostsGrid posts={posts} />}
        </div>
    );
};

export { UserPosts };

Second, you can leave your default routing untouched using the App Router, but you need to export your application as an MPA so it can be hosted in a non-node environment, such as Amazon S3. This means you must build your application using the command next build && next export. (Remember, by default, Next.js SSG generates a node app).

Third and final (and this is not trivial) because you now have an HTML file per route instead of a single index.html, you need to write some custom logic to map your site routes to these different files. This can be done via a script in nginx or an Edge Lambda in AWS CloudFront, but you must do it yourself.

But hey, bear with me. Dan explains this better than I do and even includes some code examples on how to do it!

This is what SPA processing looks like in a graph. As you can see, the client download time is still okay. Unlike other SPAs, Next.js enables a better SPA as the client does not have to download an entire unique bundle containing the entire application. However, fetching data from the client is slower than on the server (.... at least theoretically!). In other words, it's worth analyzing the performance differences between Next.js SPA and SSR methods in detail, as differences can be minimal.

Summary

While I love frameworks that give you options, I got drunk with them. Documentation is still getting there, but the Next.js team is doing a great job creating educational material as some of these features are adopted and refined. Consequently, we are in a stage where much of the learning comes through rolling up your sleeves and start building, which is a good method anyway. And if you build in public and share your knowledge, you're contributing to improving all these features.

What rendering option is better? It all depends on your application and how you manage data. For example, it wouldn't make sense always to get fresh data for a blog post because its content does not change frequently. This would make ISR a good option for this use case. On the contrary, switch to SSR or Streaming if you have a page that renders content based on data that changes very often and you always want to show it fresh on demand. Lastly, if you have a mixed page with very clear static parts that don't change often, mixed with dynamic parts that change frequently, that makes it perfect for PPR. And, to be honest, this method could even become the default for many pages on many sites out there. And that's big.

The following picture represents an overall summary of all these rendering methods.

My 7 favourite tenets of a good Developer Experience

Pablo Bermejo — Sat, 02 Dec 2023 16:38:00 +0000

After 8+ years building tools for developers, I learned that a good Developer Experience (DX) can seriously become a product differentiator, as it usually leads to a good User Experience (UX). Yes, it's all about making developers more efficient, creative, and just plain happier, but it's also about making your software products just better.

I've picked up on some key things that really lift up the DX game. Today, I'm giving away my top 6 must-haves for an awesome Developer Experience in this post. These come straight from my own journey, chats with developers, and some good old community wisdom. So, whether you're deep in the code trenches, managing products, or just getting your tech feet wet, these tips could give you a perspective on the whole DX scene.

Values

1. Liability

Don't solve generic problems. Solve specific problems by curating technology opinions and configurations. Most of the time, you'll do it through code. Alternatively, you'll do it through documentation. You must choose what to build wisely because code is a liability, and every line of code has a maintenance cost. As a result, get ready to remove some of your developer tools over time. As things evolve and industrialize, you must find your core values and lean on third-party libraries and cloud services.

2. Simplicity

Don't try to build magical tools that turn complex problems into easy ones. That can't happen. Instead, it's better to provide tools to make it easier for developers to deal with the complexity without hiding the essential details of such complexity.

Principles

1. Low cognitive load

Developer tools should not get in the way of developers. Good tools let developers keep with their train of thought easily without distracting them. There are no mental gymnastics needed to solve a problem. None. Your tools must let developers maximize their moments of inspiration.

The mental model a good tool pushes to developers is lightweight. There is no magic, and developers must still feel in control. Recognizing that engineering cycles are scarce, you should create functionality that does one thing, and does it well, giving developers time and space to focus on fixing those complex problems.

2. Abstractions, not illusions

Reducing the developer's cognitive load does not involve taking as many things away as possible. You don’t want to turn your abstractions into compositions or orchestrations of multiple solutions because that leads to unexpected surprises. Developers must know and understand what they are doing; therefore, you shouldn't hide essential details of what you are abstracting away. Abstractions should adhere to the "principle of less surprise," so developers must know at every moment what is happening when they work with your abstractions.

3. Leaky abstractions

A corollary of the above principle is that you should do “just enough encapsulations.” Creating non-added value wrappers on top of standard libraries and functionalities is a smell. Make sure your developers build on standard technologies (libraries or cloud services) with the help of your tools instead of building on your tools.

This means that your tools should not save developers from knowing things. Build functionalities that minimize how much a new developer has to know to start shipping (with default configurations or conventions) but provide a pathway to go deeper over time. The underlying technology should be exposed as a peer dependency so users can become experts about it through your tooling over time.

4. (Not too much) inversion of control

Focus on building primitives for developers (building blocks and examples), and be wary of creating generic frameworks (overarching and locked-down tools). If you create a framework, ensure it addresses a particular problem. In the words of PHP creator Ramus Lerdorf: “Everyone needs a framework; what everyone doesn't need is a general purpose framework. Nobody has a general problem; everyone has a specific one they're trying to solve.”

5. No “one-size-fits-all” abstractions

Once you have decided to create an abstraction, it can't be all things to all people. It's okay for your developer tools to offer different functionalities in different levels of abstraction for the same persona (e.g., a frontend developer), depending on their needs. However, you should not create one level of abstraction to serve all needs for the same persona.

The Frontend Cloud

Pablo Bermejo — Sun, 16 Apr 2023 16:27:14 +0000

The landscape of Web dev tech has been oscillating between the "all server" and "all client" models, with each phase presenting its unique set of advantages and challenges. Now, this swinging pendulum is losing momentum and reaching a point of equilibrium (how did I manage to write three Latin words in 1 sentence?). Where's this equilibrium happening? At the center, obviously. Where is the center, though? At the edge

The latest innovations introduced by React-based frameworks such as Next.js and Remix and cloud platforms such as Vercel and Netlify are giving birth to a groundbreaking architectural hybrid model. This architecture is The Frontend Cloud, and it leverages the advancements in Edge Cloud computing and Content Delivery Networks (CDNs) to enhance Web development capabilities significantly. Concretely speaking, The Frontend Cloud leans on the CDN's new computing and storage capabilities, something unimaginable until very recently.

In this post, I will delve into the intricacies of thi model and analyze its potential in reshaping the web development domain.

The Foundation: Edge Runtimes and CDN

Edge Computing and CDNs are at the core of the Frontend Cloud model, which represents a significant departure from traditional cloud infrastructure running in data center regions. Edge computing enables the execution of server-side logic closer to the end-users in geographical edge regions, substantially improving response times and reducing latency.

However, edge the location is less important than edge the runtime when it comes to this idea of the Frontend Cloud. Therefore, most Cloud Computing providers allow developers to run workloads on edge runtimes. These are basically Javascript runtimes, such as V8, Node.js, or Deno. Why is that? Well, there are many reasons, but performance and security are chief among them:

For example, the V8 JavaScript engine supports the concept of "isolates," which are separate instances of the V8 runtime that share no memory or resources with each other. This isolation significantly reduces the risk of cross-script vulnerabilities, data leaks, or unauthorized access to sensitive information.
Running JavaScript in isolated sandboxes allows granular control over resources and permissions. Developers can explicitly define the resources, data, and I/O API access available to each sandbox, limiting the potential impact of security vulnerabilities or breaches
JavaScript is inherently suited for handling event-driven and non-blocking I/O operations, thanks to its asynchronous nature and single-threaded execution model. These characteristics make JavaScript an excellent fit for edge computing scenarios, where efficiently handling multiple concurrent requests is critical to achieving low latency and high performance.
WASM 😇

This ability to perform computations at the edge of the network, coupled with the dynamic content delivery capabilities of CDNs, has contributed to the genesis of the Frontend Cloud model.

Notable services like Cloudflare Workers and Vercel Edge Functions have already demonstrated the potential of the Frontend Cloud model with cool features such as HTTP Streaming, which, in combination with React's Supense API and Server Components, are paving the way for the development of lightning-fast, resource-efficient web applications. Moreover, CDNs now support ephemeral storage through Key-Value (KV) objects, further extending the server-side logic capabilities to run even more complex business logic!

The Limitations of Current Edge Technologies

Despite the numerous advantages of the Frontend Cloud model, we need to be aware of a good number of limitations. One key issue I see is the absence of global replication for KV objects. At present, KV objects are localized to the edge location, restricting their utility for global use cases. However, the introduction of solutions such as Cloudflare's Durable Objects seeks to address this challenge by offering global replication, although the technology is still in its infancy. Overcoming these limitations will be crucial for the widespread adoption of the Frontend Cloud model.

The rapid evolution of Edge Cloud computing and the introduction of the Frontend Cloud architecture suggests that web development will continue to experience remarkable transformations in the coming years. I am very excited about solutions like Radis on the CDN or even Neon Database, which opens the possibility of performing PostgreSQL read/write operations on the CDN, something that could happen within the next few years. Such advancements would pave the way for the development of web applications with greater flexibility, reliability, and performance.

As the Frontend Cloud model evolves, we can anticipate the creation of new web development tools and technologies that streamline the development process. Real-time data synchronization and adaptive server-side rendering are just a few examples of the innovations that will emerge from this new paradigm. Consequently, web applications will become increasingly versatile, allowing seamless operation across multiple devices and platforms.

Conclusion

Despite the promise of the Frontend Cloud model, several challenges must be addressed before it can achieve its full potential. Latency, data consistency, and security concerns are among the most pressing issues that need to be resolved to ensure the successful adoption of the Frontend Cloud model. As innovators in this emerging field, it is imperative that we collaborate and share our collective knowledge to tackle these challenges and unlock the true potential of the Frontend Cloud.

The Frontend Cloud model, with its unique fusion of server and client-side capabilities, has the potential to revolutionize the web development landscape. By harnessing the power of Edge Cloud and CDNs, web developers can create high-performance, adaptive, and immersive experiences for users across the globe. As the limitations of the current Edge technologies are addressed and overcome, the Frontend Cloud model will continue to mature and reshape the boundaries of web development.

Look at the following piece of code using Next.js and Planetscale:

Looking closely at the code, you may think we are reinventing PHP. However, I like to see this differently. Indeed the server-side code looks like PHP, and the client-side code looks like a SPA. But isn't that the magic? I love how I can combine server efficiency and client reactivity in one app.

It's time to rename serverless

Pablo Bermejo — Wed, 22 Mar 2023 08:32:06 +0000

This is a short post.

The theory of Wardley mapping talks about how things get a new meaning as they evolve.

DevOps does not mean the same in 2023 as in 2013
Cloud does not mean the same in 2023 as in 2010
Platform does not mean the same in 2023 as in 2000
Serverless does not mean the same in 2023 as in 2016

So let me go back to some basics.

What is the cloud?

The concept of the cloud started as industrialized, interoperable, and commoditized infrastructure services built on standards and distributed over the wire to users. Today, the concept of cloud expanded this definition to include the idea of a system made of services, features, and principles that work in harmony to allow users to build the thing right. With this definition, the value proposition of cloud platforms is about meeting business leading goals such as speed of development, reliability, security, agility, and efficiency.

In 2023, we have three different levels of services offered by cloud platforms:

Infrastructure services: this collection of services and features are basically VMs offered as a service. Example: Amazon EC2
Runtime services: this collection of services and features are runtimes offered as a service. Example: AWS Lambda.
Application services: this collection of services and features are applications offered as a service. Example: Salesforce CRM.

The thing is that, in 2023, you don't need to own a data center and distribute infrastructure as pay-per-use services to be a cloud provider:

Fly.io is a cloud provider of infrastructure services
Vercel and Supabase are cloud providers for runtime services
Atlassian is a cloud provider of application services

What is content?

Content is the collection of things that platform users own and put in the platform to build the right thing. Content's value proposition is about meetings meeting business lagging goals such as growth, revenue, and customer satisfaction. In other words, content is defined by what the user owns on the platform.

We have different types of content depending on the services:

For infrastructure services: the user owns the runtimes, code, and data.
For runtime services: the user owns the code and data.
For application services: the user only owns the data.

What is serverless, then?

The concept of serverless started as on-demand functions thanks to services to Google AppEngine and AWS Lambda. Today, we can find complex definitions that include a combination of Functions as a Service and Backend as a Service, especially since the introduction of serverless containers. To me, the concept of serverless in 2023 evolved to runtimes as a service that scale to zero where users own the code and the data. It is that simple.

So, the moment I see a new service out there, I ask myself two questions:

What do I own?
How does it scale?

Depending on the answer to these two questions, I mentally categorize the type of platform I am working with. The moment I own code and data and the service scales to zero, I know I am using Runtime as a Service, and I am conscious of my duties, including what I am responsible for upgrading and maintaining! Some people call this serverless 🫠

Conversational Programming

Pablo Bermejo — Tue, 10 Jan 2023 08:19:13 +0000

I heard multiple times Simon Wardley talking about Conversational Programming as far back as 2019, but I think it didn't strike me until I put my hands on it. Yes, as I have shared in this post, I used ChatGPT to generate about 30%-40% of the code I wrote for octotype, and I am still in awe.

Something I noticed is that the model behind ChatGPT is good enough to interpret semi-ambiguous requirements but still needs a considerable deal of detailed input that expresses my intent. The same happened when I re-trained a Stable Diffusion model with selfies to generate cyberpunk-like portraits of myself. That type of thought process to express intent and reduce uncertainty in the input is what many people call Prompt Engineering. However, I think this is precisely what Simon Wardley calls Conversational Programming.

In other words, Prompt Engineering looks a lot like Programming. When you are programming, there is a process to remove ambiguity and uncertainty, so your intent is understood by the machine, and you express that intent in a language that the machine understands, such as Javascript. Well, that's precisely what we are doing with these AI models, but instead of using a 4GL programming language, we are using our Natural Language.

I said it multiple times, but when you automate something (with AI or otherwise), you are actually constraining that something with automation, and you can only constrain something with very low levels of uncertainty. Unfortunately, high-level business requirements to create software are not something that you can automate in full. You still need a process to remove ambiguity and express your intent, and you need to do it iteratively. You still need to divide and break down your big uncertain problem into smaller, more certain chunks expressed in natural language. Basically, you are programming conversationally.

Maybe, in time, these models get more intelligent so that they offer higher-level abstractions for us to ease the process of removing ambiguity and expressing intent. That is precisely what happened when we moved from assembly to Java! In other words, we may be at the doorstep of a new generation (5GL) of programming languages based on problem-solving using constraints given to the machines rather than commands.

I created my own blog platform with Next.js, GitHub Issues and OpenAI in 2 days

Pablo Bermejo — Mon, 02 Jan 2023 16:59:23 +0000

What happened?

Those who know me (or have been following me for a while) know that I love writing. I find it a liberating experience, and it has enormously helped me sort and then consolidate thoughts in my head for years. I am okay with it if no one reads my content; for me, this is more of a learning in-public exercise, and somehow I consider my blog posts as personal rants sometimes! Yes, I write a lot, to the extent that I have compiled years' worth of personal notes while I worked on an incredibly challenging cloud product and published them as a book (go check out Building Software Platforms!)

For a while now, I have been considering running my own blog as an investment in my personal branding. Note that I said "running," not "hosting." As you know, I am a firm believer in SaaS, frontend cloud platforms, serverless, and everything that distills the spirit of treating software as a liability. In part because I am a terribly bad programmer 😇.

I find modern blogging platforms very compelling, but as I said, I wanted to double down on my personal branding without entering into too much development and maintenance costs. It's a sound tradeoff for someone like me, isn't it? I considered some options in the past using GitHub Gists but it was this post from Swyx that really triggered my curiosity. Yes, using GitHub issues as a CMS and building a small frontend on top sounds like an endeavor I can afford!

How did I do it?

First of all, being a terribly bad programmer as I am, I wanted to minimize damage and use a stack that maximizes the developer experience. For me, a good developer experience provides the tools that create spaces for you to focus on fixing the business problem at hand. It's not about magic tools that do hundred of things. That's why the following stack fits the bill for me:

GitHub Issues as CMS 📚. GitHub's Issue management system gives me all I need to create and manage content behind the scenes. I am very familiar with it, and it's easy to use, widely adopted, and has an out-of-the-box API with a good free tier. It's just perfect!
Next.js with the Blog template ✍🏻. My new blog site is leaning heavily on this template, and I only added a few new types, components, and UI functionality to fetch data from GitHub through its API, such as issues (as posts), comments, and reactions. Of course, it's a statically generated site, but I have used Incremental Site Regeneration, so new issues created in GitHub Issues show up as blog posts after a very short while. It's just perfect and lightning fast
Typescript 💻. I feel very comfortable programming with types. I think it forces you into a kind of healthy DDD thinking and way of programming.
Vercel as frontend platform 🚀. Nothing to add, you know I am in love with Vercel
OpenAI 🤖.

Wait, OpenAI? For what? Well, building the whole new site took me about two (2) days. Seriously. It may not sound like a lot to you, but it's a remarkable achievement for someone like me who does not code daily. I have used it extensively to customize the app created from the Next.js template, and ChatGPT helped me immensely to write Tailwind, Typescript, and other Next.js code when I hit a wall. This was one of the main reasons I wanted to build my own site: with this tool, I felt capable of doing something like this in a reasonable time for the first time in a while.

But there is more. Do you see the post excerpts on the landing page? I have used OpenAI API to generate these summaries of my blog posts and add them as excerpts. I am just testing this feature, and I believe this is going to work for a while until OpenAI starts to charge me. At that moment, I will probably replace this functionality with a dumb excerpt generator.

What's next?

I am super happy with the result and super proud of my work (or should I say AI's work?). I think this is a good MVP, but I can think of a few features down the road:

Better responsiveness for certain pages
Hashtags and search
Dark mode
....

And probably nothing else? This is a blog site, so I don't want features creeping over here. I want it to be fast, and I want it to be simple. And so far, this is what I have done.

I think I'm going to give it a try for a long while!

(Cover photo credits: Andrew Neel via Unsplash)

Why I always favor Serverless over Kubernetes

Pablo Bermejo — Thu, 29 Dec 2022 20:17:04 +0000

Introduction

Wait, before you go and pitch your boss on ditching your current setup in favor of serverless without knowing all the details, let's talk about the other player in town first: Kubernetes. Kubernetes (or K8s, as the cool kids call it) has gained a lot of popularity in recent years as a container orchestration platform. It's definitely a powerful tool and has its place in the world of cloud computing. But is it the right fit for your needs?

In this blog post, we're going to compare serverless and Kubernetes and try to answer that question. We'll go over the benefits of both and help you understand when it makes sense to use one over the other. And, just to keep things interesting, we'll even throw in some jokes along the way (because seriously, cloud computing doesn't have to be so serious all the time).

So, let's dive in!

What is Serverless Computing?

First things first, let's define what we're talking about when we say "serverless computing." Serverless computing is a cloud computing execution model in which the cloud provider dynamically allocates resources to run an application's code in response to incoming requests or events. This means that the developer doesn't have to worry about provisioning or maintaining servers – they can just focus on writing code that runs in response to certain triggers.

One of the main benefits of serverless computing is that it allows for a pay-per-use model. You only pay for the resources consumed while running the code, which can result in significant cost savings compared to traditional cloud computing models (where you pay for resources even when they're not being used). Because in many ways, having a friend with a boat is much better than owning a boat!

Serverless computing also allows for faster deployment and scalability. Since the cloud provider is responsible for managing the underlying infrastructure, it's much easier to deploy and scale applications without having to worry about capacity planning or resource allocation. It's like having your own personal cloud genie – just snap your fingers and boom, your application is deployed and scaling like magic.

What is Kubernetes?

Now, let's talk about Kubernetes. Kubernetes is an open-source container orchestration platform that was originally developed by Google. It allows you to automate the deployment, scaling, and management of containerized applications.

In a Kubernetes setup, you create "pods" that contain one or more containers. These pods can then be scaled up or down based on the needs of your application. Kubernetes also provides features for load balancing and rolling updates, so you can update your application without any downtime.

So, What's the Verdict? Serverless or Kubernetes?

Ok, now for the big question: which one is better? As with most things in life, the answer is "it depends." Both serverless and Kubernetes have their own unique benefits and drawbacks, and the right choice will depend on your specific needs and goals.

That being said, there are a few key differences between the two that might help you make your decision.

Simplified Architecture: With serverless computing, the developer doesn't have to worry about the underlying infrastructure or the management of containers. This simplifies the architecture of the application, allowing the developer to focus on writing code that runs in response to certain triggers. Kubernetes, on the other hand, requires a bit more setup and management. You have to worry about creating and scaling pods, as well as monitoring and maintaining the underlying infrastructure.
Pay-Per-Use Model: As we mentioned earlier, serverless computing offers a pay-per-use model, where you only pay for the resources consumed while running the code. This can be a big cost savings compared to traditional cloud computing models. Kubernetes, on the other hand, operates on a more traditional model, where you pay for the resources you use, regardless of whether your code is running or not.
Faster Deployment and Scalability: As we mentioned earlier, serverless computing allows for faster deployment and scalability, as the cloud provider is responsible for managing the underlying infrastructure. Kubernetes also allows for fast deployment and scaling, but you have to manage the underlying infrastructure yourself.
Integration with Cloud Services: Many cloud providers offer a wide range of services that can be easily integrated with serverless applications, such as databases, message queues, and analytics tools. This allows for the creation of highly scalable and performant applications with minimal effort. Kubernetes also allows for integration with various cloud services, but it requires a bit more setup and management.
Improved Security: With serverless computing, the developer doesn't have to worry about patching and updating the underlying infrastructure, as the cloud provider is responsible for this. This can improve the overall security of the application, as it reduces the attack surface and ensures that the infrastructure is always up to date. Kubernetes also offers various security features, but the developer is responsible for managing and maintaining them.

So, as you can see, both serverless and Kubernetes have their own benefits and drawbacks. It's up to you to decide which one is the right fit for your needs.

But Wait, There's More!

Of course, there's much more to consider when choosing between serverless and Kubernetes. Here are 17 advanced concepts every software engineer should know about serverless

Event-Driven Architecture: Serverless computing relies on an event-driven architecture, where the code is executed in response to certain triggers, such as incoming HTTP requests, database updates, or the arrival of new data in a message queue. It is important for software engineers to understand how to design and build applications using this architecture, and to be familiar with the various types of triggers that are available.
Function as a Service (FaaS): Serverless computing relies on the concept of "functions as a service," or FaaS, where individual pieces of code are executed in response to certain triggers. It is important for software engineers to understand how to write and deploy these functions, and to be familiar with the various frameworks and platforms that are available, such as AWS Lambda, Azure Functions, and Google Cloud Functions.
Cold Start Latency: One of the challenges of serverless computing is the potential for cold start latency, where it takes longer for a function to execute when it has not been recently used. It is important for software engineers to understand how to minimize this latency, and to be familiar with the various techniques that can be used, such as keeping functions warm or using a higher memory allocation.
Scaling: With serverless computing, the cloud provider is responsible for scaling the application based on the incoming traffic. It is important for software engineers to understand how this scaling works, and to be familiar with the various tools and techniques that can be used to optimize it.
Monitoring and Debugging: With serverless computing, the cloud provider is responsible for managing the underlying infrastructure, which can make it more difficult to monitor and debug issues. It is important for software engineers to be familiar with the various tools and techniques that can be used to monitor and debug serverless applications, such as cloud provider logs, APM tools, and debugging tools like AWS X-Ray.
State Management: With traditional cloud computing, it is easy to store state in a database or on the filesystem of a server. With serverless computing, this becomes more challenging, as the underlying infrastructure is ephemeral and the code is executed in response to certain triggers. It is important for software engineers to understand how to manage state in a serverless environment, and to be familiar with the various options that are available, such as using a database or using a cache like Redis.
Integration with Third-Party Services: One of the benefits of serverless computing is the ability to easily integrate with a wide range of third-party services, such as databases, message queues, and analytics tools. It is important for software engineers to understand how to integrate these services into a serverless application, and to be familiar with the various APIs and SDKs that are available.
Security: With serverless computing, the developer does not have to worry about patching and updating the underlying infrastructure, as the cloud provider is responsible for this. However, it is still important for software engineers to understand how to secure a serverless application, and to be familiar with the various best practices and tools that are available, such as using encryption and implementing proper access controls.
Cost Optimization: One of the benefits of serverless computing is the pay-per-use model, where the developer only pays for the resources consumed while running the code. It is important for software engineers to understand how to optimize costs in a serverless environment, and to be familiar with the various tools and techniques that can be used, such as using reserved instances or optimizing the memory allocation of functions.
CI/CD: With serverless computing, it is important to have a robust CI/CD pipeline in place to ensure that code is deployed quickly and efficiently. It is important for software engineers to be familiar with the various tools and techniques that can be used to automate the deployment of serverless applications, such as using a deployment platform like AWS CodePipeline or using a serverless framework like Serverless.
Serverless Frameworks: There are various frameworks available that can help software engineers build and deploy serverless applications more easily. These frameworks typically provide a set of tools and libraries that can be used to define and deploy functions, as well as handle tasks like scaling, monitoring, and deployment. Some examples of popular serverless frameworks include AWS SAM, Serverless, and OpenFaaS.
Event-Driven Data Processing: Serverless computing is well-suited for event-driven data processing, where data is processed in real-time as it is generated. It is important for software engineers to understand how to design and build applications that can handle this type of data processing, and to be familiar with the various tools and techniques that can be used, such as using a message queue or a stream processing platform like Apache Kafka or AWS Kinesis.
Microservices: Serverless computing is often used to build microservices architectures, where an application is composed of multiple independent services that communicate with each other using APIs. It is important for software engineers to understand how to design and build microservices using serverless computing, and to be familiar with the various tools and techniques that can be used to manage and deploy these services.
Integration with Server-Based Applications: While serverless computing is well-suited for building cloud-native applications, it can also be used to integrate with existing server-based applications. It is important for software engineers to understand how to integrate serverless functions with these types of applications, and to be familiar with the various tools and techniques that can be used, such as using a reverse proxy or an API gateway.
Hybrid Architectures: It is possible to build hybrid architectures that combine serverless computing with traditional cloud computing or on-premises infrastructure. It is important for software engineers to understand how to design and build these types of architectures, and to be familiar with the various tools and techniques that can be used to manage and deploy them.
Serverless Patterns: There are various patterns and best practices that have been developed for building serverless applications. It is important for software engineers to be familiar with these patterns, and to understand how to apply them to different types of projects. Some examples of common serverless patterns include the Fan-Out pattern, the Command Query Responsibility Segregation (CQRS) pattern, and the Event Sourcing pattern.
Serverless Limitations: While serverless computing has many benefits, it is not a panacea and there are certain limitations that software engineers should be aware of. It is important to understand when it is appropriate to use serverless computing, and to be familiar with the various trade-offs and limitations that come with it, such as cold start latency and the potential for vendor lock-in.

Conclusion

So, there you have it – a comparison of serverless and Kubernetes. As we mentioned earlier, the right choice will depend on your specific needs and goals. Both serverless and Kubernetes have their own unique benefits and drawbacks, and it's up to you to decide which one is the best fit for your project.

We hope this blog post has helped you understand the differences between serverless and Kubernetes, and has given you a better idea of which one is right for you. Remember, there's no one-size-fits-all solution when it comes to cloud computing, and it's important to consider the pros and cons of each option before making a decision.

But hey, don't stress too much about it. After all, we're just talking about cloud computing – it's not like anyone's life is on the line here. Just do your due diligence and choose the option that makes the most sense for your project. Happy cloud computing!

(Follow me on Twitter to keep the discussion going!)

What's next after serverless?

Pablo Bermejo — Thu, 08 Dec 2022 16:32:47 +0000

Primitives and Frameworks

We have heard many times that AWS builds primitives, not frameworks. But, what does that mean? For starters, here is my own definition of the terminology:

Primitives are low-level, highly-reusable building blocks with high Inversion of Control. With primitives, we give developers the power to implement their use cases and solve business problems while we don't leave them alone. We present them with added-value tools such as UI Components, APIs, or SDKs.
Frameworks, on the contrary, are high-level abstractions that encapsulate concrete and particular use cases. These solutions take longer to build because you are locking down a concrete use case, even for a concrete persona. That use case is only modifiable via the predicted API of the abstraction you are building, such as smart UI components pre-connected to the backend, low-code tools, or even configurable apps (the highest-level software abstraction possible!)

Are AWS execs really committed to this vision of building primitives only? Of course, they are. After another year of AWS re:Invent, we can see how AWS doubles down on this strategy by introducing new primitives (AWS VPC Lattice) and evolving the existing ones (e.g., AWS Lambda SnapStart), especially around serverless. It looks to me that adding the serverless identifier to an existing service name is a safe path to innovation (and survival) at AWS in this difficult times. I have no other explanation. How else can you say that new services such as AWS OpenSearch Serverless are serverless? This one is far from the first principles of usage-based pricing without minimums.

All this made me think. What happens when all AWS services have a serverless flavor? What's next after serverless?

We can look a this from 2 perspectives.

A cloud provider perspective

We call The Cloud a set of industrialized infrastructure and computing services offered as commodities you can subscribe to. This definition includes serverless computing, which is nothing but "runtime as a service" where the cloud provider owns the infrastructure and runtimes, and the customer owns the application data and code.

Will AWS (or any other cloud provider) ever go up the stack and own the application data and code? No, it's implausible that they enter the SaaS space with out-of-the-box applications, leaving their platform business model behind. As masters of industrialization, I can see AWS in the foreseeable future commoditizing all aspects of modern computing until they reach the highest level of abstraction possible according to its vision. What is this level? Remember, they don't build frameworks, so don't expect them to create new services that lock down specific use cases to help developers build a particular type of application. Instead, they make primitives, so expect new cloud computing services arriving to disruptive fields such as AI and simulated worlds, some of them with all kinds of serverless identifiers in their names. Also, expect improved documentation, refined APIs, and better pricing schemes.

In a nutshell, what's next after serverless for them? Nothing, they will keep industrializing computing services. Serverless is the end game for hyperscale cloud providers such as AWS, Google Cloud or Microsoft Azure.

Well, there is one path I believe they would eventually test deeper: the idea of distributed provisioning with centralized control. This is about pushing the cloud limits to the edge, where the edge is actually any piece of infrastructure closest to the user, even if that piece is self-managed by them. In other words, this is like transforming your own datacenter in a custom AWS cloud region. We can now say that AWS ECS Anywhere was a shy attempt to test these waters, as we didn't see much traction from AWS evolving this family of services.

A niche player perspective

With all the above, there seems to be a business case for niche players. There is an opportunity now to build frameworks that lock down concrete use cases that solve specific problems for developers when they are building serverless applications. You know, AWS would never do it ... and they should not, as Jeremy points out in this thread!

Okay, but what are these problems? Let me tell you: problem number one is (poor) serverless development experience.

One issue that I hear often is that when you are building serverless applications, you don't have a clear view of what services you are using. It's difficult to find your stuff. I've even listened to a few developers claiming that "with monolithic and serverful architectures, I know all the frameworks and technology I am using just by looking at the project structure in VS Code".

In the early days of serverless, my answer was: "When you are building a serverless app, that view is provided by the AWS console. You can see all you need there!". Almost. Now I reckon my answer was not very satisfactory and those developers still had a point. It's all too scattered in the AWS Console and it is very complicated to track down the AWS services you are using only by looking in there.

The problem is that from a developer's point of view, you don't have a very-much-needed, app-centric view of the serverless services you are using to compose your application. Of course, AWS Console is not the answer, but pointing the developer to lengthy AWS SAM or CloudFormation YAML files is also NOT the answer. That's not the right developer experience.

In a sense, new developer cloud tech such as Terraform and AWS CDK partially alleviated this problem. With Infrastructure as Code scripts, you can now have a dedicated repo of source code that defines and composes your infrastructure. Now, you can see all the services you are using just by looking at the IaC project structure in VS Code! That's a secondary code repo, separated from the main application business code repo, and that's okay. The IaC code repository is just for application composition code, not business logic, and it's good to have them separated. One could argue that the new AWS Application Composer service introduced at this year's AWS re:Invent visually solves this problem. I have feelings about this service generating YAML code, although I like the idea of deploying your UML collaboration diagram as a serverless app!

So, where is all this heading? What's next after serverless that niche players can help with? It seems that the answer pivots around a better developer experience to build serverless apps, and here's an idea that new cloud providers are introducing: Why do you even care about what serverless services you are using to compose your app? What if you let the cloud platform decide what is the best infrastructure needed for your application based on its code?

Enter Infrastructure FROM Code. I see an evolution here:

Infrastructure and code: This is traditional DevOps and IaaS, where operations teams write deployment scripts in chef, puppet, or custom tech to connect users with the infrastructure necessary to run the app.
Infrastructure as code: This is where where developers can write their own Terraform and AWS CDK scripts to compose the infrastructure necessary for their apps.
Infrastructure from code: This is where cloud providers transparently provision the infrastructure resources needed to run your applications, so development nor operations teams need to care about it.

Infrastructure From Code

First of all, let me clarify something. In my opinion, those niche players betting on Infrastructure from Code frameworks qualify as cloud providers. As I said multiple times, you don't need to own a data center and offer your infrastructure and runtimes as a service to be a cloud provider. Instead, evolve and industrialize your services (even if it is pure software) and offer your resources as commodities with sprinkles of self-service, and you also will become a cloud provider.

Okay, what examples of cloud providers fit this definition and offer Infrastructure from Code features? The answer is many already, with players such as Ampt and Shuttle disrupting the space with purpose-built IfC features and development kits.

However, I have to reckon that I have a hard bias toward Vercel for multiple reasons, the main one being precisely their Infrastructure from Code features designed explicitly for frontend developers building with the Next.js framework. Think about the following potential scenarios if you are building a Next.js app:

If you are hosting the app on your own infrastructure, it is very likely that after you get your UI bundle with all the assets, you have to put it on a nextjs hot server running inside a container (or inside an AWS Lambda function if you are brave enough). In any case, you need to think about the computing services you need, provision them with Terraform or AWS CDK scripts (if you are using AWS), and get your app deployed.
However, if you are hosting the app on Vercel, you don't need to think about this. Vercel takes care of the bundle splitting to deploy the respective assets on the right piece of infrastructure. And they do this transparently during the build process, so you don't even care what AWS (or other) serverless services they are using under the hood. They could get the static assets to an AWS S3 bucket, the SSR bits to an AWS Lambda function, and the Edge Functions to another server running on the CDN. In fact, that's what they actually do!

In the case of Vercel, the Infrastructure from Code features are super-powerful for your Next.js app. Because they own both the framework and the platform, they are in a very good position to offer this kind of added-value service, while others need to run behind catching up all the time!.

Conclusions

It's hard to predict where things might go in terms of cloud development, but one thing remains clear to me: there is an opportunity for startups to bet on serverless development experience. This is something that hyperclouds wouldn't do. This is still an unchartered area where we need definitions and techniques, but this is very likely what the future of native cloud development looks like.

(Cover photo credit: Alex Kulikov via Unsplash).

What does the cloud look like for software companies?

Pablo Bermejo — Mon, 25 Apr 2022 07:34:35 +0000

When I hear software companies are transitioning to the cloud, I generally take it with a pinch of salt because I am not sure if they know what they mean. But, what do they really mean?

This is a rough, unpolished thought but I think we should put more emphasis on distinguishing between transitioning to the cloud vs becoming the cloud. In other words, we shouldn't mistake the cloudifification of the software with the evolution of the software towards the services economy.

Let me be more specific.

Transitioning to the cloud vs. becoming the cloud

On the one hand, when a software company transitions to the cloud it typically means they are taking their existing software products and moving them to a fancier data center (i.e. "the cloud"). What motivates this change for software providers? In my experience, this is typically a reactive move after their customers have moved all their stuff to the cloud. Operating on new cloud infrastructure, these customers will ask software providers for mechanisms to integrate the software with other infrastructure components on the new cloud platform. The answer is then to lift and shift the software onto AWS EC2 instances so it can integrate better with the customer's AWS S3 buckets.

While this transition changes the delivery model and ownership of the software (i.e., it is now delivered through the internet) on many occasions there is a tendency to leave it untouched without rethinking how the customers will use it in this new world. Typically, these are enterprise software companies that still allow customers to work with their software in the same way they did before the transition to cloud. Now, it just happens that they are operating in a more reliable, secure, and scalable environment (i.e., a fancier data center). This way, customers can still do whatever customizations they used to apply without any restrictions. In order to give these customers full control as they used to have, these software companies end up building complex control planes and integrations that mimic the underlying cloud platform consoles in an attempt to enable full control to the customers.

On the other hand, when a software company becomes the cloud they not only move their software to the cloud, but they also rethink their product strategy by offering many of the software capabilities in a self-service manner. In other words, they move forward the industrialization line towards the services economy. We've got 2 options here:

Option 1: software companies create guidelines and constraints to allow users to customize the software in a very specific and controlled way. This is how the gurantee evergeen updates to the untouchable parts. For that, they create platform abstractions and tools for these users to create extensions or even entirely new applications within the boundaries of the platform they have been offered. This is Platform as a Service or PaaS, where the customers own the data and the code.
Option 2: software companies eliminate all customization possibilities and rethink how their software is offered as a service, allowing the users to introduce only certain and restricted configurations for their use cases. This is Software as a Service or SaaS, where the customers only own the data.

The evolution of the enterprise software

I think a safe strategy in the current legacy enterprise software industry (i.e., B2B) is to become the cloud and offer both Build and Buy options to the their customers:

So-called core legacy systems could be offered through SaaS with self-service configuration capabilities to final customers. These applications typically are important to sustain the business ... but they are also the cost of doing business. For example, the cost of having customers is managing relationships and offers (e.g., with a CRM such as Salesforce) and the cost of shipping goods is managing a supply chain (e.g, with an ERP such as SAP Ariba). Typically companies do not differentiate between each other thanks to these types of systems.
Building the so-called digital experience applications could be offered through PaaS with constrained customizations and developer tools. This way, consumer companies have full control on how they build these types of applications, while the software provider does not leave them alone, giving them platforms to build users experiences with efficacy. Yes, these are the applications that companies want to build because they are differentiating and help them achieve competitive advantages. For example, insurance carriers differentiate between each other for the Quote and Buy experience they offer to final consumers, so they can capture more business. That's why the want to build them.

What is the cloud anyway?

I know what you might be thinking:

"But, wait a minute Pablo, I thought cloud companies are just those that own data centers and offer infrastructure resources as a service, like AWS".

While this is entirely true, owning a data center and offering infrastructure or runtime services through an HTTP endpoint is not a necessary precondition for any tech company to become a cloud company. Let's pause for a moment and think about what cloud services actually are. The term has been so used and abused that it makes people think that cloud services are just those offered by AWS, Microsoft, or Google. However, the term cloud services capture the industrialization of the technology and practices of any business to offer their capabilities as commodities, moving from competing in the product space to competing in the services space. Top that with sprinkles of self-service and evergreen updates and you'll become a true cloud company!

That's what cloud services are all about, and that's why software companies of all kinds can become cloud companies too.

That's the cloud.

Follow me on Twitter to keep the conversation going!

(Cover photo credits: Javier Allegue Barros via Unsplash)

A software engineering analogy nobody asked for

Pablo Bermejo — Sun, 03 Apr 2022 19:16:19 +0000

Seeking analogies

Most of us have heard many analogies comparing software engineering to other engineering practices in the physical world, such as civil engineering or car manufacturing. While seeking metaphors like these is absolutely normal due to the inherent abstract (an intangible) nature of building software, many fail to make a genuine and equivalent comparison.

Let me explain.

Comparing building software to make cars is very tempting since there seem to be some similarities, to the point that we have even spun up software factories in the past. These so-called factories were based on the principles of Lean Manufacturing and the hyper-efficient and highly-automated assembly lines. There is a problem though: we don't make cars. A Toyota Prius has nothing in common with Elastic Search.

Automation in car manufacturing

Why is it so tempting? Let me put it this way. In manufacturing, there are two clear and well-separated processes:

Design Phase: You design that new car model that all your customers dream about. You capture market needs and then put your creativity together to develop a model that can be handed over to engineers to build and deliver.
Construction Phase: You build that one car model that has been designed, typically through a highly-automated and hyper-efficient assembly line.

Have you noticed something already? That's right. In the car manufacturing industry, you automate the construction phase but never the design phase. I may be wrong, but I don't think that designing new car models can be automated in the same way they are produced. Don't mistake using software to assist the design phase (e.g., CAD) with software to automate the generation of new designs.

Automation in software

For building software, these two types of phases also make sense. But not in the way many people think.

Design Phase (or Inner Loop): You design that new piece of software that your customers (think they) want. However, the tricky part is that in software, this phase includes making technical designs and writing code. Exactly, writing code belongs to the design phase. Writing code is designing.
Construction Phase (or Outer Loop): You make digital copies of that one software you have designed and ship it to your users. This is the build and deploy part of crafting software.

And here is the problem of comparing manufacturing cars with building software. There is a misbelief that because cars are produced in hyper-automated assembly lines, building software can be automated in the same way.

And that's wrong. In software development, when you automate something, what you are really doing is constraining that thing with automation. And you can only constrain a problem that is well known with a high degree of certainty.

Automation in software engineering must be applied to the build and deploy phase (i.e., the construction phase) and never to the coding phase (i.e., the design phase). Let's think about this as if it was a physics problem: data has mass, computing consumes energy, and the network takes time.
Then, you want to minimize all those variables during your creative work so it runs smoothly while you don't mind to maximize them to make digital copies of that work.

And this is where I believe that designing cars and building software is equivalent: you come up with a model that later you can copy multiple times and ship it to your customers. Again, in software, writing code is designing. That's why movements such as Extreme Programming promote the idea of designing every day.

Moreover, in software engineering bringing these two phases as closely as possible with short feedback loops during multiple iterations makes it really different from other types of engineering.

Conclusion

This idea has a corollary.

Bringing the world's best software engineers does not guarantee that you will build a successful software product that the customers will love to use. You need something else. There is a creative part that can't be neglected. In this way, building software is closer to making a movie than making a car. However, bringing the world's best software engineers will guarantee that this piece of software is built and shipped with efficacy to these customers.

That's what I think. Follow me on Twitter for more stupid rants like this!

(Cover photo by Hal Gatewood via Unsplash)

Modern Web Development with the Modern Cloud

Pablo Bermejo — Wed, 09 Mar 2022 15:21:00 +0000

Different rendering options

It appears to me that making architectural decisions for Web development is more complicated than ever due to the emergence of frameworks that bake in client/server tradeoffs. Yes, I am thinking of Next.js or Remix, which offer different rendering options for different use cases. In any case, there is a lot of information out there to help Web developers make informed decisions.

Typically, Web developers solve these tradeoffs and pick one rendering method or another driven by a combination of data and user experience requirements:

Static Site Generation (SSG): Pages of your Web App / Web Site are generated at build time. It helps build sites when data is not changed or updated frequently, such as information portals or news sites. Frameworks like Next.js support features such as Incremental Static Regeneration which means that the static site is regenerated on the server automatically based on a schedule configured by developers.
Server-Side Rendering (SSR): Content of your Web App / Web Site is generated dynamically on a request basis. This rendering solution is most appropriate for data-intensive scenarios where content is updated very frequently, it is very large, access latency is critical, or complex processing and transformation is needed before returning the response to the client.
Client-Side Rendering (CSR): The data displayed on your Web App / Web Site is served through an HTTP API and rendered by the client on the browser. To improve the performance time at the client device, this data must be lightweight and ready to be consumed without further processing. This approach can help for those cases where user interactions and state management of the user interface need to happen as close to the user as possible to offer a very interactive and reactive user experience.

However, modern deployment options have additional non-functional requirements (NFRs). I am talking about NFRs such as an extra twist in performance, cost implications, and environmental impact. These are things that nowadays Web Developers need to consider when making these architectural decisions.

The battle at the server-side

I believe the discussion and debate around what rendering mechanism is better is conceptually wrong. It may lead you to pick up the wrong framework after all!

The actual tradeoffs and the real discussion should be around architectural patterns such as JAMstack (i.e., no server-side logic) vs Fullstack (i.e., server-side logic). When you put the focus on the architectural style and not the rendering mechanism, you'll see it more clearly as you will look at the problem from a more accurate prism. At the end of the day, you can do SSR with JAMstack but it just happens at build time! Also, you can do SSG with Fullstack if you play with the stale-while-revalidate cache header like Remix does.

Why are Web development teams shifting to the server side again? The answer is because of the commoditization of infrastructure and serverless. It is now easier than ever to have backend computing for your Web applications and sites.

"Higher-order systems create new sources of value" - Simon Wardley

We now count on an extensive catalog of managed cloud services and pure serverless primitives. There is a battle in this server-side space between second-tier cloud platforms such as Vercel or Netlify (they don't own Datacenters) and first-tier cloud ones such as Cloudflare and AWS (they own Datacenters). They all compete with each other to offer the best Web developer experience and optimize those new NFRs.

Especially for first-tier cloud platform, this battle is making innovations spring at a pace we have never been before, especially with the emergence of Edge Computing solutions.

JAMstack was introduced as a workaround under certain infrastructural assumptions, advocating for the separation of server-side stuff from pure Web development for performance and UX reasons. The world has changed, and Edge Computing is breaking those initial assumptions!

I mean, you don't need full round trips to the cloud region to obtain data. You can now serve it from the CDN, or even run pieces of logic on the edge. That gives you speeds and UX for dynamic Web Apps that are similar to static sites.

As I wrote in the past, computing at the edge is not about CDNs and caches anymore; this is something else. We are now talking about moving part of our applications and services to an edge location. An edge location is where cloud providers cache content so that it can be very quickly accessed by local referrers. It also allows local access to the cloud platform's network backbone avoiding the public internet between the edge location and the regional datacenter from where content originates.

At the edge, actual client requests and application logic can be processed and executed without the need to send that request to a service running on the origin cloud region. Of course, this approach still qualifies as serverless because you don't need to provision or manage any type of runtime. Additionally, this approach comes with further benefits, such as global distribution and automatic multi-region access for your applications out of the box.

Edge Computing use cases

Okay, then, how does edge computing help Web development? In my opinion, it can make it better, faster, and cheaper with solutions that help and support the Javascript development community. Solutions such as Cloudflare Workers (or Cloudflare Page Functions) are very confortable for Web developers as they offer the same native Javascript APIs that developers are used to work with in the browser. It's a very natural ecosystem for them.

In its current form, I would choose Edge Computing services only as an add-on layer on top of my server-side components running at the cloud origin for very concrete use cases:

Data Filtering: Filter data coming from the application components before sending a response to the client. This can be done based on user-specific criteria such as location or device type. The goal is to avoid data processing and filtering as much as possible at the browser, so it can receive ready-to-render data.
Stateful Requests: Combined with lightweight storage at the edge (e.g., Key-Value stores), we could handle sophisticated states on edge on top of the application running on a serverless environment. And we could do it without firing full round trips to the cloud origin region. This would allow Web developers to build session-based online collaboration tools (e.g., Miro dashboard) running on serverless computing.
Authorization: Apply Role Based Access Control rules to UI components returned to the client. Imagine you are including an Admin section in your UI which options are affected by the user's role. Filtering those UI options at the edge would be a very cost-effective and high-performant solution.
Cyber-protection: Use native cybersecurity features and APIs at the CDN to identify networking patterns such as bot detection and apply URL redirects to avoid exposing the application code running at cloud region to malicious agents. Also, I've seen edge functions used to prevent clickjacking or XSS attacks by adding security headers to the response.
Performance: Remember that edge computing providers own cache datacenters all over the world, so I am sure there is one close to your location right now. This allow them implement powerful caching mechanisms to improve TTFB for static content (HTML, CSS, Javascript bundles) and other techniques such as image resizing optimization based on user devices.

Conclusion

These use cases can be game-changing especially for Javascript developers building Web applications. Solutions like Cloudflare Workers are based on Google's V8 engine allowing response times for client requests under 50ms (i.e., full round-trip, not just internal execution time). Then, as described above, the main logic for the server-side components would run entirely on the cloud region, with a preference for serverless components. But who knows, maybe edge computing evolves to the point where we can run larger pieces of business logic closer to the user location.

I am getting my hands dirty with a few of Cloudflare's solutions right now, so in my next post I will cover in detail a few of their most compelling edge computing services. Follow me on Twitter to keep the conversation going!

(Cover photo credits: Alan Tang via Unsplash)

How Edge Computing can make the Web better

Pablo Bermejo — Sun, 06 Mar 2022 17:30:24 +0000

Different rendering options

Typically, Web developers solve these tradeoffs and pick one rendering method or another driven by a combination of data and user experience requirements:

Static Site Generation (SSG): Pages of your Web App / Web Site are generated at build time. It helps build sites when data is not changed or updated frequently, such as information portals or news sites. Frameworks like Next.js support features such as Incremental Static Regeneration which means that the static site is regenerated on the server automatically based on a schedule configured by developers.
Server-Side Rendering (SSR): Content of your Web App / Web Site is generated dynamically on a request basis. This rendering solution is most appropriate for data-intensive scenarios where content is updated very frequently, it is very large, access latency is critical, or complex processing and transformation is needed before returning the response to the client.
Client-Side Rendering (CSR): The data displayed on your Web App / Web Site is served through an HTTP API and rendered by the client on the browser. To improve the performance time at the client device, this data must be lightweight and ready to be consumed without further processing. This approach can help for those cases where user interactions and state management of the user interface need to happen as close to the user as possible to offer a very interactive and reactive user experience.

The battle at the server-side

Especially for first-tier cloud platform, this battle is making innovations spring at a pace we have never been before, especially with the emergence of Edge Computing solutions.

Edge Computing use cases

In its current form, I would choose Edge Computing services only as an add-on layer on top of my server-side components running at the cloud origin for very concrete use cases:

Data Filtering: Filter data coming from the application components before sending a response to the client. This can be done based on user-specific criteria such as location or device type. The goal is to avoid data processing and filtering as much as possible at the browser, so it can receive ready-to-render data.
Stateful Requests: Combined with lightweight storage at the edge (e.g., Key-Value stores), we could handle sophisticated states on edge on top of the application running on a serverless environment. And we could do it without firing full round trips to the cloud origin region. This would allow Web developers to build session-based online collaboration tools (e.g., Miro dashboard) running on serverless computing.
Authorization: Apply Role Based Access Control rules to UI components returned to the client. Imagine you are including an Admin section in your UI which options are affected by the user's role. Filtering those UI options at the edge would be a very cost-effective and high-performant solution.
Cyber-protection: Use native cybersecurity features and APIs at the CDN to identify networking patterns such as bot detection and apply URL redirects to avoid exposing the application code running at cloud region to malicious agents. Also, I've seen edge functions used to prevent clickjacking or XSS attacks by adding security headers to the response.
Performance: Remember that edge computing providers own cache datacenters all over the world, so I am sure there is one close to your location right now. This allow them implement powerful caching mechanisms to improve TTFB for static content (HTML, CSS, Javascript bundles) and other techniques such as image resizing optimization based on user devices.

Conclusion

(Cover photo credits: Alan Tang via Unsplash)