In the realm of technology, we've witnessed a significant evolution over the years, a topic I touched upon in my previous article discussing our growing dependence on subpar software.

> Back in the 1970s, computing was a luxury. The Kenbak-1, one of the first personal computers, had a price tag of $750 — a staggering sum of over $4,500 in today's currency. This high cost extended to software as well.

> Fast forward to the 1980s, the landscape began to shift with the introduction of more accessible home computers like the IBM PC and Apple II. These systems became user-friendly, with a range of third-party software such as word processors and games becoming available.

> This era also marked the emergence of pricing disparities. Typically, when you create a product, each copy sold equates to revenue. However, with software, a single copy can be replicated and sold multiple times, leading to competitive pricing strategies that prioritize volume over profit.

> On the subject of pricing, it naturally began to decline due to the vast online competition.

> This trend was further accelerated by the mobile revolution in the 2000s, epitomized by iTunes' 99-cent song pricing, which set a precedent for mobile applications, many of which were priced similarly. This pricing model is absurd when compared to the minimum wage or the cost of a coffee, compelling developers to sell thousands of apps just to earn a decent income, especially after accounting for Apple and Google's commissions.

> This pricing pressure contributed to our addiction to inferior software; the emphasis shifted from quality to marketing prowess. Consider the case of Duolingo, which highlights this disconnect.

Software prices continue to plummet, creating challenges for profitability within the tech sector. Nevertheless, one category of companies thrives: serverless providers.

Indeed, serverless technology has proven to be a gold mine for AWS. While AWS represents a small fraction of Amazon’s total revenue, it accounts for a substantial portion of its profits. Many speculate that Amazon leverages AWS profits to support its retail operations.

I've been contemplating how AWS has thrived within a contracting market, and I believe the answer lies in microservices.

To understand this, we must recognize a fundamental issue with technology: it has become a commodity. This was exemplified by IBM's partnership with Microsoft, which allowed Microsoft to produce IBM-compatible PCs, ultimately eroding the value of IBM's own products. Why choose an IBM PC when a Dell PC is available for less? Microsoft turned DOS into a commodity.

This phenomenon persists today; consider Android phones, which are widely available at low prices, versus iPhones, which remain a premium product. Apple has effectively avoided commodification.

The first lesson: never allow your offerings to become commodities. This is the core issue with cloud services: if you provide hosting or VPS solutions, you're essentially selling a commodity. Countless hosting companies offer similar services, often at lower prices, resulting in minimal profitability.

What you need is a value-added layer on top of those servers — a proprietary managed system. Enter serverless computing.

Serverless architectures effectively create customer lock-in. The days of straightforward database backups and simple migrations are gone; now, lengthy and challenging migration processes are the norm, often accompanied by additional fees.

This positioning is a significant improvement for businesses, but it doesn't fully address the issue of low-cost computing.

The solution lies in low-code platforms. Many users dislike coding, and we can capitalize on that discomfort. We can streamline simple tasks while making scaling up prohibitively expensive and complex.

I previously addressed this in my article on the pitfalls of no-code app development:

> These 'no-code solutions' aim to enable limitless functionalities using a limited set of tools. While coding can achieve this, it already presents a challenge when abstracting the intricacies of the operating system. Creating user-friendly interfaces for every function is an even larger hurdle, which I consider a daunting task.

Low-code platforms primarily target front-end app development, which lacks the necessary integration to ensure customer retention. Ideally, front-end systems should manage minimal logic tied to server data, making them easily replaceable.

Front-end no-code solutions lack the stickiness required for long-term engagement. However, when it comes to the back end, the title of this piece — "The Advantages of Microservices for Serverless Architecture" — highlights their critical role.

Microservices differ from no-code solutions, but they share a common goal: they lock in customers with the promise of simplified development. In fact, they surpass no-code tools since they require minimal effort in development. A glance at AWS's product catalog reveals many lackluster offerings.

Why wouldn't they be subpar? AWS can simply adopt open-source software, like Elastic Search, and host it on their servers. The focus isn't on who uses it but on volume — akin to how brands provide numerous product variations to enhance their perceived importance.

AWS's marketing strategy employs a clever principle: if brilliance can't win them over, overwhelm them with complexity. AWS dominates the serverless market simply because of its size — no other reason.

Furthermore, AWS can create additional services by taking previously simple tasks and complicating them through fragmentation. For instance, code that could run on a $5 VPS can instead be billed by the millisecond. This model ensures greater revenue as slower servers equate to longer execution times. It's a win-win scenario.

Offering a multitude of services creates further advantages. By making these services unnecessarily complex, we can profit from training offerings. Since they use our branding, we maintain control over every aspect.

This strategy also serves as free advertising. Instead of seeking "Go programmers" or ".Net developers," companies are now searching for "AWS specialists." It's akin to creating a proprietary programming language without the effort — just repackaging open-source tools under a proprietary banner.

Competent programmers can learn new languages easily (except for perhaps Rust), but management often lacks this understanding. Azure? What’s that? It's not compatible with AWS.

Meanwhile, customers endure inflated costs. A case study revealed that using AWS services can inflate expenses by tenfold. If Amazon engineers struggle with microservices, it raises the question: who can succeed? I call this scenario arbitrage.

You might wonder who falls for this approach.

First, recognize that programmers often display cult-like behavior. Programming is challenging, leading many to cling to "best practices" as dictated by our marketing team.

Our marketing department has invested heavily to propagate several myths:

• Scalability: SQLite doesn't scale! Only our proprietary NoSQL database does.
• Easier Debugging: Microservices are simpler to debug due to their size.
• Agility: Smaller components allow for faster development.
• Cost-Efficiency: Initially expensive, but savings will come — eventually.
• Real Programmers Use Microservices: More microservices equate to greater success; aim for more microservices than users for guaranteed growth.
• Technology Diversity: Microservices let you utilize the best tools for each task or, at least, the preferred tools of the developer who created that microservice.
• Zero Downtime: Unless, of course, someone mistakenly pushes the wrong button, resulting in prolonged outages.

You may perceive these as absurd, yet you'd be surprised by the gullibility. Consider the concept of "clean code," which bears a striking resemblance to our marketing propaganda. Just a few changes in wording, and the message resonates. Uncle Bob is indeed not on our payroll, but he might be on someone else's.

Convincing programmers isn't the challenge; influencing management is where the difficulty lies. Despite their quirks, management often displays even greater naivety. They aren't the ones experiencing the implementation challenges firsthand.

We've also successfully misled aspiring programmers into believing this is the standard approach to software development through the "system design" interview process. The systems they design often represent overkill for most side projects and are notoriously difficult to maintain. Yet, they embrace these concepts wholeheartedly.

Additionally, we employ a final strategy to entice users: offering them a "free tier." This costs us minimally — only a few dollars per customer monthly — but people are drawn to anything labeled as free.

The downside is that most users will likely remain within the confines of the free tier, leading to ongoing subsidization. AWS has cleverly implemented a time limit on free tier usage, but allowing many customers to exploit free services can be worthwhile if it attracts a few major clients.

Once we secure a "whale" customer with the allure of free or heavily subsidized offerings, they become nearly impossible to extricate, especially as their projects evolve into legacy code that no one wants to touch. It's a brilliant strategy!

The tech industry is caught in a downward spiral. Although Moore's Law has plateaued, innovations like AI and shifts to Arm architecture continue.

The path forward necessitates convincing customers to pay more for less. How do we accomplish this? We deceive them into believing they're receiving greater value. This is precisely where microservices come into play.

Microservices stand alone in their market, spawning a surrounding ecosystem of inefficiencies that benefit service providers like AWS, Azure, and Google Cloud.

These offerings are exceedingly lucrative. While Google Cloud may not be as profitable for reasons unknown, AWS and Azure are thriving, free from the risk of losing significant clients. It's akin to taking candy from a child.

Just avoid making your microservices too similar to other options. For instance, don't fall into the trap of offering managed Postgres databases, as that invites customer defection.

The potential loss of substantial clients for not adhering to "industry standards" is a fair trade-off, in my view. They weren't going to pay well, anyway. Open standards are for the naive.

Proprietary standards are where the real value lies. Microservices provide that unique advantage, which is why they represent the best advancement for serverless computing.