In the previous section, you learned about loose coupling and how important it is for our architecture to be loosely coupled for scalability and fault-tolerance. Developing service-oriented thinking will help to achieve a loosely coupled architecture (as opposed to a server-oriented design, which can lead to hardware dependency and a tightly coupled architecture). SOA helps us to achieve ease of deployment and maintenance for your solution design.

When it comes to service-oriented thinking, solution architects always gear towards SOA. The two most popular SOAs are based on Simple Object Access Protocol (SOAP) services and RESTful services. In SOAP-based architecture, you format your message in XML and send it over the internet using the SOAP protocol, which builds on top of the HTTP.

In RESTful architecture, you can format a message in XML, JSON, or plain text, and send it over a simple HTTP. However, RESTful architecture is comparatively more popular, as it is very lightweight and much more straightforward than SOAP. 

When talking about SOA nowadays, microservice architecture is increasingly popular. Microservices are independently scalable, which makes it easier to expand or shrink one component of your application without impacting others. As you can see in the following diagram, in a monolithic architecture, all components are built in a single server and tied up with a single database, which creates a hard dependency, whereas, in a microservice architecture, each component is independent with their framework and database, which allows them to be scaled independently:

In the preceding diagram, you can see an example of an e-commerce website, where customers can log in and place an order, assuming the items they want are available, by adding items to the cart. To convert a monolithic architecture to a microservice-based architecture, you can create applications that are made of small independent components, which constitute smaller parts to iterate.

Taking the modularization approach means that the cost, size, and risk of change reduces. In the preceding case, each component is created as a service. Here, the Login Service can independently scale to handle more traffic, as the customer may log in frequently to explore the product catalog and order status, while the Order Service and the Cart Service may have less traffic, as a customer may not place the order very often.

Solution architects need to think of SOA while designing a solution. The clear advantage of services is that you have a smaller surface area of code to maintain and services are self-contained. You can build them with no external dependencies. All prerequisites are included in the service, which enables loose coupling, scaling, and reduces the blast radius in case of failure.