Microservices, Availability, & Message Driven Architectures

Everyone builds "monolithic" apps by default. They weren't called Monoliths, just applications. It was simpler to build them together. The frontend talks to the backend in the same codebase. Then you can serve it on IIS, or similar server software. Majority of small to medium sites are developed in this way.

Majority of the internet has been developed in a very reactionary way. If something isn't working for situations redesign it.

In the case for enterprise web applications, Software as a Service products, the increased need for availability, and increased team size, required something different.

Microservices were created, and rapidly the industry is shifting towards this development model. The microservice architecture is focused on splitting the typical monolith app into pieces.

You split up components into Microservices for many reasons:

• Better Scaling & Component Redundancy
• Organized Development
• Quicker Development
• Simplified Maintenance
• Better Testing
• Increased Partition Tolerance
• Higher Availability

The first we will go over is..

Scaling

There are two types horizontal and vertical.

Horizontal scaling is the ability to add computers, to add "redundancy" to your application. Vertical scaling is increasing the memory and cpu allocated to nodes. There is a limit to vertical scaling which is why the industry is shifting away from the monolithic approach.

This separation of concerns allows you to horizontally scale each specific app as you need. If the frontend needs more machines to serve pages, then spin more up. The real icing on the cake comes from the benefits of vertical scaling. Instead of just the one monolith app being scaled to max cpu and memory, you can now scale each individual node/component as needed.

Stateless vs Stateful Applications.

To use horizontal scaling and add redundancy to your apps, you need stateless applications. Stateless applications are components that do not carry "state" from one session to another. This means that any computer can pick up where another computer left off, and any computer can handle any request. They all have access to the same data.

If one machine crashes or fails, no big deal, spin up another one.

Stateful apps work for monoliths because they are typically vertically scaled up and down with increased CPU/Memory.

Another benefit to microservices is..

Asynchronous Development

With larger code bases comes larger teams. Teams need to test their code, they need to work on it, and deploy it. Imagine the git tree for a monolith vs a microservice. The branches and commits would be chaotic. There would be a lot more room for error.

If you are a non-coder, imagine a word document, every time you want to work on a different copy you would save it under a different name. Then you would eventually need to merge the changes to the main one. The more people doing this, the more difficulty, time and maintenance it would take to merge. With micro services everyone is working on different word documents.

Message Driven Architecture

Another architecture that has been frequently used lately is the event/message driven architecture. It is a design pattern to store client requests in a stateless manner. Originally developed in the late 1900s, hardware wasn't accessible enough to benefit from using this technique.

With the help from containers, most notably Docker, deploying apps to any computer became extremely easy. You create an image, which includes all the files that your app needs to run, and the image can be run on any operating system, with any package manager version. Furthermore container orchestration software like kubernetes (k8s) by Google, allows for easy stateless scaling up and down of resources, load balancing, all in an automated fashion. Companies have built out all this software that is open source and constantly growing to meet the availability needs of users.

Websites typically make a request to the backend for resources or data and wait for a response, then update the user.

The reason to use the message driven architecture allows for websites to be designed in a "non-blocking" fashion. Clients produce a message that is placed on a Queue, AWS SQS or Kafka for example. This message is typically a string, has an account id, and a status. Clients then continue on as if everything went smoothly. Now it is up to the backend computers to process it.

Exponential back-off algorithms help with availability when using this structure because when a call to the backend fails, it needs to be repeated until its registered. If it keeps failing then it will clog up and bottleneck the API Gateway / HTTP Route.

It adds additional complexity, but it makes sense in the highly available internet that we as consumers have come to expect.

High Availability Expectations

From 2017, Akami a leading CDN company reported:

A 100-millisecond delay in website load time can hurt conversion rates by 7 percent A two-second delay in web page load time increase bounce rates by 103 percent 53 percent of mobile site visitors will leave a page that takes longer than three seconds to load Bounce rates were highest for mobile phone shoppers, while tablet shoppers had the lowest bounce rate

That was years ago, and COVID brought on even more users, and increased availability needs. They aren't the only ones who came to this conclusion. Amazon did a report 10 years ago, google, facebook have all done reports all pointing to the same thing, Availability matters most with consumer sites.

Looking back, YokD my personal training startup took long to load the homepage which could have caused customer drop offs. Suffice to say, its extremely important your site operates fast.

Availability is important, how does the industry measure it?

What are nines of availability?

As the image suggests, 100% availability is extremely unlikely. 5 nines with only 5 minutes. When you're a company like Netflix, one bad code push and you're out. 5 Nines of availability requires high use of automation. Automated tests, CI/CD. Blue/Green, Canary deployments.

There are many ways to achieve high nines of availability. Another main way that microservices help is with partition tolerance.

Partition Tolerance

As you can see as you add more "computes/redundancy" to each of your applications, availability gets significantly higher. When you do this with microservices the scope of the downtime remains only with that one component instead of effecting the whole application.

Summary

A microservice architecture separates deployment and scaling of applications. This allows easier and quicker development, better testing, better partition tolerance.

The main reason the industry is moving towards a microservice architecture is because when paired with a message passing architecture/event driven architecture it leads to a better user experience, from better site availability. If a website loads slow, or processes slow then users will drop off from using your site.

Other ways to increase site availability would be using caches, CDNs, image optimization, precomputing & generating HTML pages, which will be discussed in future posts.

This has been a letter from a coder.

Best Regards, Tyler Farkas