SoftwareArchitecture

Microservices are the architectural equivalent of a midlife crisis

Someone in a zip-up hoodie has just told you that monoliths are architectural heresy. They insist that proper companies, the grown-up ones with rooftop terraces and kombucha taps in the breakroom, build systems the way squirrels store acorns. They describe hundreds of tiny, frantic caches scattered across the forest floor, each with its own API, its own database, and its own emotional baggage.

You stand there nodding along while holding your warm beer, feeling vaguely inadequate. You hide the shameful secret that your application compiles in less time than it takes to brew a coffee. You do not mention that your code lives in a repository that does not require a map and a compass to navigate. Your system runs on something scandalously simple. It is a monolith.

Welcome to the cult of small things. We have been expecting you, and we have prepared a very complicated seat for you.

The insecurity of the monolithic developer

The microservices revolution did not begin with logic. It began with envy. It started with a handful of very successful case studies that functioned less like technical blueprints and more like impossible beauty standards for teenagers.

Netflix streams billions of hours of video. Amazon ships everything from electric toothbrushes to tactical uranium (probably) to your door in two days. Their systems are vast, distributed, and miraculous. So the industry did what any rational group of humans would do. We copied their homework without checking if we were taking the same class.

We looked at Amazon’s architecture and decided that our internal employee timesheet application needed the same level of distributed complexity as a global logistics network. This is like buying a Formula 1 pit crew to help you parallel park a Honda Civic. It is technically impressive, sure. But it is also a cry for help.

Suddenly, admitting you maintained a monolith became a confession. Teams began introducing themselves at conferences by stating their number of microservices, the way bodybuilders flex biceps, or suburban dads compare lawn mower horsepower. “We are at 150 microservices,” someone would say, and the crowd would murmur approval. Nobody thought to ask if those services did anything useful. Nobody questioned whether the team spent more time debugging network calls than writing features.

The promise was flexibility. The reality became a different kind of rigidity. We traded the “spaghetti code” of the monolith for something far worse. We built a distributed bowl of spaghetti where the meatballs are hosted on different continents, and the sauce requires a security token to touch the pasta.

Debugging a murder mystery where the body keeps moving

Here is what the brochures and the medium articles do not mention. Debugging a monolith is straightforward. You follow the stack trace like a detective following footprints in the snow.

Debugging a distributed system, however, is less like solving a murder mystery and more like investigating a haunting. The evidence vanishes. The logs are in different time zones. Requests pass through so many services that by the time you find the culprit, you have forgotten the crime.

Everything works perfectly in isolation. This is the great lie of the unit test. Your service A works fine. Your service B works fine. But when you put them together, you get a Rube Goldberg machine that occasionally processes invoices but mostly generates heat and confusion.

To solve this, we invented “observability,” which is a fancy word for hiring a digital private investigator to stalk your own code. You need a service discovery tool. Then, a distributed tracing library. Then a circuit breaker, a bulkhead, a sidecar proxy, a configuration server, and a small shrine to the gods of eventual consistency.

Your developer productivity begins a gentle, heartbreaking decline. A simple feature, such as adding a “middle name” field to a user profile, now requires coordinating three teams, two API version bumps, and a change management ticket that will be reviewed next Thursday. The context switching alone shaves IQ points off your day. You have solved the complexity of the monolith by creating fifty mini monoliths, each with its own deployment pipeline and its own lonely maintainer who has started talking to the linter.

Your infrastructure bill is now a novelty item

There is a financial aspect to this midlife crisis. In the old days, you rented a server. Maybe two. You paid a fixed amount, and the server did the work.

In the microservices era, you are not just paying for the work. You are paying for the coordination of the work. You are paying for the network traffic between the services. You are paying for the serialization and deserialization of data that never leaves your data center. You are paying for the CPU cycles required to run the orchestration tools that manage the containers that hold the services that do the work.

It is an administrative tax. It is like hiring a construction crew where one guy hammers the nail, and twelve other guys stand around with clipboards coordinating the hammering angle, the hammer velocity, and the nail impact assessment strategy.

Amazon Prime Video found this out the hard way. In a move that shocked the industry, they published a case study detailing how they moved from a distributed, serverless architecture back to a monolithic structure for one of their core monitoring services.

The results were not subtle. They reduced their infrastructure costs by 90 percent. That is not a rounding error. That is enough money to buy a private island. Or at least a very nice yacht. They realized that sending video frames back and forth between serverless functions was the digital equivalent of mailing a singular sock to yourself one at a time. It was inefficient, expensive, and silly.

The myth of infinite scalability

Let us talk about that word. Scalability. It gets whispered in architectural reviews like a magic spell. “But will it scale?” someone asks, and suddenly you are drawing boxes and arrows on a whiteboard, each box a little fiefdom with its own database and existential dread.

Here is a secret that might get you kicked out of the hipster coffee shop. Most systems never see the traffic that justifies this complexity. Your boutique e-commerce site for artisanal cat toys does not need to handle Black Friday traffic every Tuesday. It could likely run on a well-provisioned server and a prayer. Using microservices for these workloads is like renting an aircraft hangar to store a bicycle.

Scalability comes in many flavors. You can scale a monolith horizontally behind a load balancer. You can scale specific heavy functions without splitting your entire domain model into atomic particles. Docker and containers gave us consistent deployment environments without requiring a service mesh so complex that it needs its own PhD program to operate.

The infinite scalability argument assumes you will be the next Google. Statistically, you will not. And even if you are, you can refactor later. It is much easier to slice up a monolith than it is to glue together a shattered vase.

Making peace with the boring choice

So what is the alternative? Must we return to the bad old days of unmaintainable codeballs?

No. The alternative is the modular monolith. This sounds like an oxymoron, but it functions like a dream. It is the architectural equivalent of a sensible sedan. It is not flashy. It will not make people jealous at traffic lights. But it starts every morning, it carries all your groceries, and it does not require a specialized mechanic flown in from Italy to change the oil.

You separate concerns inside the same codebase. You make your boundaries clear. You enforce modularity with code structure rather than network latency. When a module truly needs to scale differently, or a team truly needs autonomy, you extract it. You do this not because a conference speaker told you to, but because your profiler and your sprint retrospectives are screaming it.

Your architecture should match your team size. Three engineers do not need a service per person. They need a codebase they can understand without opening seventeen browser tabs. There is no shame in this. The shame is in building a distributed system so brittle that every deploy feels like defusing a bomb in an action movie, but without the cool soundtrack.

Epilogue

Architectural patterns are like diet fads. They come in waves, each promising total transformation. One decade, it is all about small meals, the next it is intermittent fasting, the next it is eating only raw meat like a caveman.

The truth is boring and unmarketable. Balance works. Microservices have their place. They are essential for organizations with thousands of developers who need to work in parallel without stepping on each other’s toes. They are great for systems that genuinely have distinct, isolated scaling needs.

For everything else, simplicity remains the ultimate sophistication. It is also the ultimate sanity preserver.

Next time someone tells you monoliths are dead, ask them how many incident response meetings they attended this week. The answer might be all the architecture review you need.

(Footnote: If they answer “zero,” they are either lying, or their pager duty alerts are currently stuck in a dead letter queue somewhere between Service A and Service B.)

Six popular API Styles explained with everyday examples

APIs are the digital equivalent of stagehands in a grand theatre production, mostly invisible, but essential for making the magic happen. They’re the connectors that let different software systems whisper (or shout) at each other, enabling everything from your food delivery app to complex financial transactions. But here’s the kicker: not all APIs are built the same. Just as you wouldn’t use a sledgehammer to crack a nut, picking the right API architectural style is crucial. Get it wrong, and you might end up with a system that’s as efficient as a sloth in a race.

Let’s explore six of the most common API styles using some down-to-earth examples. By the end, you’ll have a better feel for which one might be the star of your next project, or at least, which one to avoid for a particular task.

What is an API and why does its architecture matter anyway

Think of an API (Application Programming Interface) as a waiter in a bustling restaurant. You, the customer (an application), tell the waiter (the API) what you want from the menu (the available services or data). The waiter then scurries off to the kitchen (another application or server), places your order, and hopefully, returns with what you asked for. Simple, right?

Well, the architecture is like the waiter’s whole operational manual. Does the waiter take one order at a time with extreme precision and a 10-page form for each request? Or are they zipping around, taking quick, informal orders? The architecture defines these rules of engagement, dictating how data is formatted, what protocols are used, and how systems communicate. Choosing wisely means your digital services run smoothly; choose poorly, and you’ll experience digital indigestion.

SOAP APIs are the ones with all the paperwork

First up is SOAP (Simple Object Access Protocol), the seasoned veteran of the API world. If APIs were government officials, SOAP would be the one demanding every form be filled out in triplicate, notarized, and delivered by carrier pigeon (okay, maybe not the pigeon part). It’s all about strict contracts and formality.

What it is essentially SOAP relies heavily on XML (that verbose markup language some of us love to hate) and follows a very rigid structure for messages. It’s like sending a very formal, legally binding letter for every single interaction.

Key features you should know It boasts built-in standards for security and reliability (WS-Security, ACID transactions), which is why it’s often found in serious enterprise environments. Think banking, payment gateways, places where “oops, my bad” isn’t an acceptable error message.

When you might actually use it If you’re dealing with high-stakes financial transactions or systems that demand bulletproof reliability and have complex operations, SOAP, despite its perceived clunkiness, still has its place. It’s the digital equivalent of wearing a suit and tie to every meeting.

Everyday example to make it stick Imagine applying for a mortgage. The sheer volume of paperwork, the specific formats required, the multiple signatures, that’s the SOAP experience. Thorough, yes. Quick and breezy, not so much.

SOAP is robust, but its verbosity can make it feel like wading through molasses for simpler, web-based applications.

RESTful APIs are the popular kid on the block

Then along came REST (Representational State Transfer), and suddenly, building web APIs felt a lot less like rocket science and more like, well, just using the web. It’s the style that powers a huge chunk of the internet you use daily.

What it is essentially REST isn’t a strict protocol like SOAP; it’s more of an architectural style, a set of guidelines. It leverages standard HTTP methods (GET, POST, PUT, DELETE – sound familiar?) to interact with resources (like user data or a product listing).

Key features you should know It’s generally stateless (each request is independent), uses simple URLs to identify resources, and can return data in various formats, though JSON (JavaScript Object Notation) has become its best friend due to its lightweight nature.

When you might actually use it For most public-facing web services, mobile app backends, and situations where simplicity, scalability, and broad compatibility are key, REST is often the go-to. It’s the versatile t-shirt and jeans of the API world.

Everyday example to make it stick Think of browsing a well-organized online store. Each product page has a unique URL (the resource). You click to view details (a GET request), add it to your cart (maybe a POST request), and so on. It’s intuitive and follows the web’s natural flow.

REST is wonderfully straightforward for many scenarios, but what if you only want a tiny piece of information and REST insists on sending you the whole encyclopedia entry?

GraphQL asks for exactly what you need, no more no less

Enter GraphQL, the API style that decided over-fetching (getting too much data) and under-fetching (having to make multiple requests to get all related data) were just plain inefficient. It waltzes in and asks, “Why order the entire buffet when you just want the shrimp cocktail?”

What it is essentially GraphQL is a query language for your API. Instead of the server dictating what data you get from a specific endpoint, the client specifies exactly what data it needs, down to the individual fields.

Key features you should know It typically uses a single endpoint. Clients send a query describing the data they want, and the server responds with a JSON object matching that query’s structure. This gives clients incredible power and flexibility.

When you might actually use it It’s fantastic for applications with complex data requirements, mobile apps trying to minimize data usage, or when you have many different clients needing different views of the same data. Think of apps like Facebook, which originally developed it.

Everyday example to make it stick Imagine going to a tailor. Instead of picking a suit off the rack (which might mostly fit, like REST), you tell the tailor your exact measurements and precisely how you want every part of the suit to be (that’s GraphQL). You get a perfect fit with no wasted material.

GraphQL offers amazing precision, but this power comes with its own learning curve and can sometimes make server-side caching a bit more intricate.

gRPC high speed and secret handshakes

Sometimes, even the targeted requests of GraphQL feel a bit too leisurely, especially for internal systems that need to communicate at lightning speed. For these scenarios, there’s gRPC, Google’s high-performance, open-source RPC (Remote Procedure Call) framework.

What it is essentially gRPC is designed for speed and efficiency. It uses Protocol Buffers (protobufs) by default as its interface definition language and for message serialization, think of protobufs as a super-compact and fast way to structure data, way more efficient than XML or JSON for this purpose. It also leverages HTTP/2 for its transport, enabling features like multiplexing and server push.

Key features you should know It supports bi-directional streaming, is language-agnostic (you can write clients and servers in different languages), and is generally much faster and more efficient than REST or GraphQL for inter-service communication within a microservices architecture.

When you might actually use it This style is ideal for communication between microservices within your network, or for mobile clients where network efficiency is paramount. It’s less common for public-facing APIs due to browser limitations with HTTP/2 and protobufs, though this is changing.

Everyday example to make it stick Think of the communication between different specialized chefs in a high-end restaurant kitchen during a dinner rush. They use their own shorthand, specialized tools, and direct communication lines to get things done incredibly fast. That’s gRPC, not really meant for you to overhear, but super effective for those involved.

gRPC is a speed demon for internal traffic, but it’s not always the easiest to debug with standard web tools.

WebSockets the never-ending conversation

So far, we’ve mostly talked about request-response models: the client asks, and the server answers. But what if you need a continuous, two-way conversation? What if you want data to be pushed from the server to the client the moment it’s available, without the client having to ask repeatedly? For this, we have WebSockets.

What it is essentially WebSockets provide a persistent, full-duplex communication channel over a single TCP connection. “Full-duplex” is a fancy way of saying both the client and server can send messages to each other independently, at any time, once the connection is established.

Key features you should know It allows for real-time data transfer. Unlike traditional HTTP where a new connection might be made for each request, a WebSocket connection stays open, allowing for low-latency communication.

When you might actually use it This is the backbone of live chat applications, real-time online gaming, live stock tickers, or any application where you need instant updates pushed from the server.

Everyday example to make it stick It’s like having an open phone line or a walkie-talkie conversation. Once connected, both parties can talk freely and hear each other instantly, without having to redial or send a new letter for every sentence.

WebSockets are fantastic for real-time interactivity, but maintaining all those open connections can be resource-intensive on the server if you have many clients.

Webhooks the polite tap on the shoulder

Finally, let’s talk about Webhooks. Sometimes, you don’t want your application to constantly poll another service asking, “Is it done yet? Is it done yet? How about now?” That’s inefficient and, frankly, a bit annoying. Webhooks offer a more civilized approach.

What it is essentially A Webhook is an automated message sent from one application to another when something happens. It’s an event-driven HTTP callback. Basically, you tell another service, “Hey, when this specific event occurs, please send a message to this URL of mine.”

Key features you should know They are lightweight and enable real-time (or near real-time) notifications without the need for constant checking. The source system initiates the communication when the event occurs.

When you might actually use it They are perfect for third-party integrations. For example, when a payment is successfully processed by Stripe, Stripe can send a Webhook to your application to notify it. Or when new code is pushed to a GitHub repository, a Webhook can trigger your CI/CD pipeline.

Everyday example to make it stick It’s like setting up a mail forwarding service. You don’t have to keep checking your old mailbox. When a letter arrives at your old address (the event), the postal service automatically forwards it to your new address (your application’s Webhook URL). Your app gets a polite tap on the shoulder when something it cares about has happened.

Webhooks are wonderfully simple and efficient for event-driven communication, but your application needs to be prepared to receive and process these incoming messages at any time, and you’re relying on the other service to reliably send them.

So which API style gets the crown

As you’ve probably gathered, there’s no single “best” API style. It’s all about context, darling.

SOAP still dons its formal attire for serious, secure enterprise gigs.
REST is the friendly, ubiquitous choice for most web interactions.
GraphQL offers surgical precision when you’re tired of data overload.
gRPC is the speedster for your internal microservice Olympics.
WebSockets keep the conversation flowing for all things real-time.
Webhooks are the efficient messengers that tell you when something’s up.

The ideal choice hinges on what you’re building. Are you prioritizing raw speed, iron-clad security, data efficiency, or the magic of live updates? Each style offers a different set of trade-offs. And just to keep things spicy, the API landscape is always evolving. New patterns emerge, and old ones get new tricks. So, the best advice? Stay curious, understand the fundamentals, and don’t be afraid to pick the right tool, or API style, for the specific job at hand. After all, building great software is part art, part science, and a healthy dose of knowing which waiter to call.

June 1, 2025 by Fernando SRE Computer Science stuff

From Monolith to Microservices, Amazon’s Two-Pizza Team Concept

In the early days of software development, most applications were built using a monolithic architecture. This model, while reliable for small-scale systems, often struggled as applications grew in complexity and user demand. Over time, companies like Amazon found themselves facing significant operational challenges under the weight of their monolithic systems, leading to an evolution in software design, the shift from monoliths to microservices.

This article delves into the reasoning behind this transition and explores why many organizations today are adopting microservices for better agility, scalability, and innovation.

Understanding the Monolithic Architecture

A monolithic application is essentially a single, unified software structure. All the components, whether they are related to the user interface, business logic, or database operations. are bundled into one large codebase. Traditionally, this approach was the most common and familiar to software engineers. It was simple to design, test, and deploy, which made it ideal for smaller applications with minimal complexity.

However, as applications grew in size and scope, the limitations of monolithic systems became apparent. Let’s take a look at an example from Amazon’s history.

Amazon’s Monolithic Beginnings

In the 1990s, Amazon’s bookstore application was built on a monolithic architecture, consisting of a simple web server front end and a database back end. While this model served them well initially, the sheer growth of their business created bottlenecks that couldn’t be easily addressed. With every new feature, the complexity of their system increased, making it harder to release updates without affecting other parts of the application.

Here’s where monoliths begin to struggle:

Coordination Complexity: Developers working on different features had to coordinate with one another constantly. If a team wanted to add a new feature or change a database table, they needed to check with every other team that relied on that feature or table. This led to high communication overhead and slowed down innovation.
Scaling Issues: Scaling a monolithic system often means scaling the entire application, even if only one part of it is experiencing high demand. This is both inefficient and expensive.
Deployment Risk: Since every part of the application is tightly coupled, releasing even a minor update could introduce bugs or break functionality elsewhere. The risks associated with deploying changes were high, leading to a slower pace of delivery.

The Shift Toward Microservices. A Solution for Scale and Agility

By the late 1990s, Amazon realized they needed a new approach to continue scaling their business and innovating at a competitive pace. They introduced the “Distributed Computing Manifesto,” a blueprint for shifting away from the monolithic model toward a more flexible and scalable architecture, microservices.

What are Microservices?

Microservices break down a monolithic application into smaller, independent services, each responsible for a specific piece of functionality. These services communicate through well-defined APIs, allowing them to work together while remaining decoupled from one another.

The core principles that drove Amazon’s transition from monolith to microservices were:

Small, Independent Services: The smaller each service, the more manageable it becomes. Teams working on different services can make changes and deploy them independently without affecting the entire system.
Decoupling Based on Scaling Factors: Instead of decoupling the application based on functions (e.g., web servers vs. database servers), Amazon focused on decoupling based on what parts of the system were impeding agility and speed. This allows for more targeted scaling of only the components that require it.
Independent Operation: Each service operates as its entity. This reduces cross-team coordination, as each service can be developed, tested, and deployed on its own schedule.
APIs Between Services: Communication between services is done through APIs, which ensures that the system remains loosely coupled. Services don’t need to share databases or be aware of each other’s internal workings, which promotes modularity and flexibility.

The Two-Pizza Team Concept

One of the cultural shifts that helped make this transition work at Amazon was the introduction of the “two-pizza team” model. The idea was simple: teams should be small enough to be fed by two pizzas. Smaller teams have fewer communication barriers, which allows them to move faster and make decisions autonomously. Combined with microservices, this empowered Amazon’s teams to release features more quickly and with less risk of breaking the overall system.

The Benefits of Microservices

The shift from monolith to microservices brought several key benefits to Amazon, and many of these benefits apply universally to organizations making the transition today.

Faster Innovation: Since teams no longer have to coordinate every feature release with other teams, they can move faster. This leads to more frequent updates and a shorter time-to-market for new features.
Improved Scalability: Microservices allow you to scale individual components of your application independently. If one service is under heavy load, you can scale only that service, rather than the entire application, reducing both cost and complexity.
Better Fault Isolation: With a monolithic system, a failure in one part of the application can bring down the entire system. In contrast, microservices are isolated from one another, so if one service fails, the others can continue to operate.
Technology Flexibility: In a monolithic system, you’re often limited to a single technology stack. With microservices, each service can use the most appropriate tools and technologies for its specific requirements. This allows for greater experimentation and flexibility in development.

Challenges in Adopting Microservices

While the benefits of microservices are clear, the transition from a monolithic architecture isn’t without its challenges. It’s important to recognize that microservices introduce a new level of operational complexity.

Service Coordination: With multiple services running independently, keeping them in sync can become complex. Versioning and maintaining API contracts between services requires careful planning.
Monitoring and Debugging: In a microservices architecture, errors and performance issues are often harder to trace. Since each service is decoupled, tracking down the root cause of a problem can involve digging through logs across several services.
Cultural Shifts: For organizations used to working in a monolithic environment, shifting to microservices often requires a change in team structure and communication practices. The two-pizza team model is one way to address this, but it requires buy-in at all levels of the organization.

Is Microservices the Right Move?

The transition from monolith to microservices is a journey, not a destination. While microservices offer significant advantages in terms of scalability, speed, and fault tolerance, they aren’t a one-size-fits-all solution. For smaller or less complex applications, a monolithic architecture might still make sense. However, as systems grow in complexity and demand, microservices provide a proven model for handling that growth in a manageable way.

The key takeaway is this: microservices aren’t just about breaking down your application into smaller pieces; they’re about enabling your teams to work more independently and innovate faster. And in today’s competitive software landscape, that speed can make all the difference.

September 14, 2024 by Fernando SRE Computer Science stuff