All right, if you're still here, glad to have you aboard. Let's dive in with our first topic, microservices. So what is a microservice? Sadly there's no single definition. Microservices is an architectural type. I define a microservice as a finely tuned piece of software that performs a single or small collection of tasks. This is what I considered to be a microservice and you'll see variations of this definition all around the internet.

At their core though, microservices usually meet the following criteria. They are highly maintainable and testable, meaning that they're quick to deploy and to develop. They're loosely coupled meaning they don't have any major dependencies on other parts of a systems code base. They are independently deployable. New versions can be deployed to the stack without interfering with other components. They're organized around business capabilities whether that be a web server running crud endpoints for a single entity or focused around data processing. They should be focused solely on a single piece of your overall application. Lastly, with microservices, they can be owned by a small team allowing your engineering team to have high deliverability.

Okay, so what's the difference between a monolithic code base and a microservice? Well, for starters, in a monolith, all sources in a single code base, it's tightly coupled. Classes can be dependent on each other throughout different parts of the code. This makes the monolith a single point of failure. If one piece of the application crashes, it has the potential to crash the entire application rather than just that individual component.

It's difficult to manage the appointments and maintenance as well. Chances are you will have considerable more downtime for deployments with this model of code when compared to microservices. This is because of the fact that the entire application or API needs to be brought down.

Monoliths are also difficult to scale. When we're talking about scaling, we can scale up fairly easily but that can get costly. Monoliths are difficult to scale out because of their large size dependencies and requirements. The other software architecture I want to talk about is service-oriented architecture or SOA.

SOA can range from a small specialized service all the way up to enterprise wide services. The key difference I see between SOAs and microservices is scope. SOAs have enterprise level scope. Microservices on the other hand almost always have application scope. Outside of scope though, in fact, these two types of architectures can go hand in hand where an enterprise application can utilize underlying microservices.

The other difference between SOAs and microservices is communication. Components of service oriented architectures communicate directly over an enterprise service bus or ESB. The microservices tend to communicate to one another over HTTP. And depending on the traffic, the ESB can actually become the single point of failure for the whole enterprise rather than a single application. And if a single service slows down, the entire system can be affected.

I do want to point out before moving on that microservices are not a cure-all rather, they are just another design pattern that you can keep in your software architectural arsenal. And when the project arises you may find that microservices fit your use case. There is nothing wrong with using a monolith or SOA. In fact, there are legitimate reasons as to why you would want to do one or the other over microservices. Always consider the best tool for the job.