Website Architecture

Página 1

Monolithic vs Microservice Architechture

In microservice architecture, each service is self-contained and implements a single business capability.

Consider an e-commerce application as a use case to understand the difference between both of them.

Different clients from different devices try to use different services like search, build, configure, and other management capabilities.

All the services are separated based on their domains and functionalities and are further allotted to individual microservices.

These microservices have their own load balancer and execution environment to execute their functionalities, and at the same time, captures data in their own databases.

All the microservices communicate with each other through a stateless server which is either RESTor a Message Bus.

Microservices know their path of communication with the help of Service Discovery and perform operational capabilities such as automation and monitoring.

All the functionalities performed by microservices are communicated to clients via an API Gateway.

All the internal points are connected from the API Gateway so anybody who connects to the API Gateway is automatically connected to the complete system.

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.

Are independently deployable by fully automated deployment machinery.

Página 2

A monolithic application built as a single unit.

Enterprise Applications are often built in three main parts:

a client-side user interface (consisting of HTML pages and javascript running in a browser on the user's machine)

a database (consisting of many tables inserted into a common, and usually relational, database management system), and

a server-side application. (The server-side application will handle HTTP requests, execute domain logic, retrieve and update data from the database, and select and populate HTML views to be sent to the browser. This server-side application is a monolith - a single logical executable[2]. )

Any changes to the system involve building and deploying a new version of the server-side application.

Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. Over time it's often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module.

Página 3

Microservices

build systems by plugging together components

Our definition is that a component is a unit of software that is independently replaceable and upgradeable.

Library vs Services : a library is shared code that you compile into your application. A service is a shared capability that you access from your application

Libraries vs. Frameworks: In general, the differentiating feature is a matter of control — frameworks dictate how your project will be structured, whereas libraries are building blocks that can be used anywhere. If we use the metaphor of architecture, libraries are bricks, and frameworks are, fittingly, the frame.

Common Shared Library

Should provide a set of well-known operations that perform common tasks (e.g., String parsing, numerical manipulations, builders)

Should Encapsulate common reusable code

Have minimal dependencies on other libraries

Provide stable interfaces

Services

Should provide reusable application-components

Provide common business services (e.g., rate-of-return calculations, performance reports, or transaction history services)

May be used to connect existing software from disparate systems or exchange data between applications

A Web Service was designed for machine interop and to reach an audience easily by using HTTP as the means of transport.

A strong point is that by publishing the service you are also opening the use of the service to an audience that is potentially vast (over the web or at least throughout the entire company) and/or largely outside of your control / influence / communication channel and you don't mind or this is desired. The usage of the service is much easier as clients simply have to have an internet connection and consume the service. Unlike a library which may not be so easily done (but can be done). The usage of the service is largely open. You are making it available to whomever feels they could use it and however they feel to use it.

However, a web service is in general slower and is dependent on an internet connection.

It's in general harder to test than a code library.

It may be harder to maintain. Much of that depends on your maintainance and coding practices.

I would consider a web service if several of the above features are desired or at least one of them is considered paramount and the downsides were acceptable or a necessary evil.

What about a Shared Library?

What if you are far more in "control" of your environment or want to be? You know who will be using the code (interface isn't a problem to maintain), you don't have to worry about interop. You are in a situation where you can easily achieve sharing without a lot of work / hoops to jump through.

Examples in my mind of when to use:

You have many applications in your control all hosted on the same server or two that will use the library.

Not so good example, you have many applications but all hosted on a dozen or so servers. Web Service may be a better choice.

You are not sure who or how your code could be used but know it is of good value to many. Web Service.

You are writing something only used by a limited set of applications, perhaps some helper functions. Library.

You are writing something highly specialized and is not suited for consumption by many. Such as an API for your Line of Business Application that no one else will ever use. Library.

If all things being equal, it would be easier to start with a shared library and turn it into a web service but not so much vice versa.