Microservices

The reading starts explaining the definition of "microservices", and as I understood the Microservices architecture is similar to the modular architecture. Let me explain, the author's describes that microservices architecture is a set of independently deployable services, this sounds like the "partion of funcionality inside modules". The author continues explaining why this approach is being more used nowadays and the advantages of this model against the monolothic one. 

Later on, the article talks about how the developers are trying to build systems the same way we craft things in the real world, plugging together components (little parts that are there to perform some functionality and that together will conform a new thing). An interesting addition to this definition is that a component is a piece that can be "upgraded and replaced". Something interesting is that this architecture as I understand is designed to be implemented in cloud-based applications. The author mention that is better using services instead of using libraries.

Similar to another articles, this one talks about some  subjects that are familiar to me due to another classes, the author talks about the advantages of using services, the principal is to reduce the cohesion that the libraries may have. Another one is that the use of services helps to define a more explicit component interface. Something interesting is that this approach treat the software as a product, not as a project, this keeps the developers in touch with the software, this seems to me like some of the ITIL practices, where there a product owner , which can be a service, and I know that the ITIL product owner its not necessary a software developer.

I had never heard about the Polyglot approach, the idea with this approach is to let every service to run on their own database instead of running over the same database as the other services. A problem taht appears with this approach is that the team needs to find a way to deal with the failure of a service. As the services can fail at any time is important to find as quick as possible the failure and restore the service as soon as possible.

Comentarios

Publicar un comentario

Entradas populares de este blog

Hidden Figures

The movie was interesting, this was the first time I heard about it. The plot is simple, but interesting. The movie remind me to one of the articles we’ve previously read, about the software development to reach the moon. It was interesting to know a little bit more about the process that the NASA took to archive this. Notwithstanding that the movie plot doesn’t focused on something closely related to the software development or architecture (even if there’s some exploration about an IBM mainframe) , I think the important thing  is to reflex about  the difficult process that some projects need to get through. In this case, the project needed to analyze and take decisions as soon as possible, because the data became obsolete really fast. Also the data that needed to be reviewed was a lot, and in that time it was really hard due to the low processing power of the computers. In other hand, the movie talks about an important topic of our era, the racism. It’s wonderful to see...
Leer más

The 4+1 View Model

The topics of the two videos are related with the article topic. Starting with the 4+1 video, I think this video information is like the topics of my class of software quality and tests. I’ve worked with some of the mentioned diagrams in the video. The new “scope” is the view encapsulation according to the different type of information that the diagram represents. But it makes sense to divide the diagrams with these criteria, because maybe the needed information may be different for whom is requesting it. And this scope will reduce and define properly the work to produce and deliver the diagrams. In other hand, the other video is a metaphor of the problem that is to design or select a paradigm to develop something, specially when the work is handled by a group. This is a result of the different approaches that each developer takes when defining or implementing requisites, each’s mind works and abstract the information differently. In this case the metaphor uses an elephant as the ...
Leer más