Microservices

Monolith applications is now a thing from the past. In order to build scalable and efficient applications, a new architectural style has come to try and solve the problems of deploying again and again the entire  code when a single change or modifications has been made to a single part of the project. I found logically correct to segment the application into units called services (each one with a specific purpose) and handle it like an independent application. 

Web development and applications are growing, and considering that this will keep trending, HTTP is used as a communication method between services. How it is properly done? Through this incredible and standardized interfaces called APIs (Application Programming Interfaces).

Since I learned Javascript,  when defining the routes I was already thinking in the required methods (GET, POST; PUT, DELETE, etc) and the scope for each one of them. Therefore, knowing about HTTP and APis will be (if it is not now) a necessary skill. 

I was thinking, if we separate the parts of the application into services there might be one downside (just a thought, might dive more after finishing this blog). Each service must be deployed in a different server or instance, but what about the means affecting the performance of the application?

Monolithic applications clearly did not have problems of communications between their parts, but by dividing them a new player enters the game: the network. It might be irresponsible to think that there might be infinite bandwidth or zero cost in the communication. Now imagine millions of requests/jobs trying to communicate among different services... Just a quick thought, so I would recommend to also take in consideration this. 

To conclude, I see more advantages for microservices, but required preparation and  fully satisfied what it takes to build these type of applications must be taken into consideration.

Comentarios

Publicar un comentario

Entradas más populares de este blog

Is Design Dead

Thsi week's activity... software design... it is said that the more senior you become, the higher level you go through projects and, well... maybe there is a bit of reason of software builders losing respect to the ones designing. But to be able to design such software systems, you need to have experience and had the whole picture of how systems work. You do not need to be specialized in a product or service, you just need to know how they work and interact with other components (perhaps like a black box). Where I work, I interact daily with all types of people. There are software engineers, cloud engineers, architects, consultants and project managers. With my two years meeting different professionals and being in different areas, I would like to tell more about the place I work.  Currently, I am a Cloud Solution Engineer. The job is a mixture of both hard and soft skills, but most of the time I am interacting with customers designing solutions, troubleshooting issues, presenting
Leer más

Who needs an architect?

This week's article was a little short, but there are many ideas that can I can come up with. Basically, what the article was trying to do was to show the importance of architects, especially software architects. We have come a long way on our major of comptuer science, and it is time to start thinking big. Most of the projects we have worked in school are small projects which almost all of them consisted on a set of approximately seven classes, a database and a web server. Maybe for these projects you do not need a special person to check or validate the whole system.  But as the world progresses, organizations require bigger and more complex information systems and applications. Many of them involve the use of applications interacting with each other. Now, with that being said a special role or person is needed for a whole system to work. This includes knowing how a system interacts with a database, an application programming interface (APIs), with other classes, operating system
Leer más