Microservices

I think it is clear enough the importance of architecture in the development of a system or application, so it should not be overlooked at any time.

Speaking of microservices we find the utility of a small, concise and available tool through HTTP requests that will be running at any time on a server and that will respond to all requests made from our original system.

What is the advantage of using an architecture based on microservices? Well, basically we can modularize the application by eliminating many dependencies, avoiding conflicts with local libraries and allowing the architecture to be deployed in a more distributed way, which increases the scope and ease of scaling.

For me, one of the most important things is that it facilitates the selection of the elements that are most occupied, or that carry a greater workload and allows them to be replicated in different instances and through the use of a load balancer it is possible to distribute the requests of an application and only replicate microservices that need more processing capacity. This would not be possible in a monolithic architecture because absolutely the entire system would have to be replicated, which increases the cost and reduces the possibilities.

The last point addressed in the article is about the future of microservices and although the author still does not give enough credit to these architectures, for me the future is heading there. We have seen how companies that provide services in the cloud have recently grown and, most of these, are microservices. Why does this happen? Simply and simply because the titans of computing services have realized that companies that use technology are more willing to pay only for what they are using to maximize their performance and reduce their costs. For this reason, I believe that we are going to a stage of computer systems that is based on microservice architecture. And even more so considering that the speed of data transfer over the internet has been increasing astronomically due to the new transmission methods, which increases the advantages of these microservices.

Software Craftsmanship

Throughout the career we have studied we have seen different methodologies to develop software, we even find ourselves with the dilemma of understanding the difference between a methodology and a framework (as agile is). Personally I believe that this framework of good practices to develop software more efficiently, quickly and with better teamwork, has been a total innovation in our area.

I totally agree with the author when he mentions about the craftsmanship of the software, because it is, no software is a copy of another because we are always producing new things and each programmer puts a little of his part, his essence, and the way he solves Problems when programming are part of the way you think, the way you express yourself, that makes software art.

Imagine for a moment return to the development of traditional, sequential software, with PMI. The requirements of our customers, today more than ever, constantly change. The technologies we work with are evolving day by day, the people we serve are and suddenly no longer, the business needs change day by day adjusting to the market, the ecosystem, the economy. Then what do we do? Are we still developing software unable to adapt? Do we cancel the projects at the moment they become useless? All these questions are solved with the implementation of this new way of developing software: agile. A framework that focuses on giving greater concentration to the client and that says "changes are welcome" allowing that, even at late stages of the project, changes are accepted in order to meet the needs of the client or end users who will use the system.

Personally I am very fan of this type of software development and I have even certified in Scrum methodology with ScrumStudy and IBM Agile courses because I think it is a fairly successful framework for the shortcomings of software development.

Wargames

I loved the film in all aspects like almost any material that Professor Ariel shares with us, always very attentive to what we need to know, but with a Geek touch that makes us more interested.

Well, where do I start? First, I work at IBM in the Security Intelligence department and obviously I am very focused on the cyber aspect of systems security. This movie touches on some issues such as the back doors, the monitoring of a person's activity on the network, protected systems, etc. He even mentions topics such as artificial intelligence and the classic "robots of the future will control the world and subdue human beings" by Terminator.

Not much to say, really. This film lets us see the capacity of the systems, even if they are very old, and the potential they have to facilitate the work and decision making of human beings, but always with responsibility.

I think that is precisely the point I would like to highlight, to develop technology with responsibility. Because in my opinion it is not just about developing technology just because it is, but about understanding the consequences of what we are doing and the destructive capacity that any system can have in the wrong hands. It sounds a bit like a science fiction movie, yes, but let's imagine that what happened in the movie happened today in real life. Doesn't it sound so far from reality? Yes, it is possible for a system to take military control of a country and start a world war that ends the lives of everyone on the planet, only that we don't think about it very often.

We will have to continue advancing with technology, but apply our ethical education so as not to make systems that compromise, in any way, the integrity of people, animals, the environment, etc. It sounds complex, but it is our duty as engineers and as humans to consider the impact of our actions and more taking into account that we, as experts in the technological area have the future of the world in our hands.

Is design dead?

What I found most important in this article is how it addresses the fact that, today, designing a software architecture has become something extremely complex, but why? Simply the applications that the engineers develop become too complex to know, from the beginning, everything that is going to be needed and the problems that are going to be generated. This is why having an initial architecture, as the project progresses, it is modified too much or left aside due to its futility; however, we cannot begin to program an architecture without having a base, a planning.

This reminds me of when we made our life plan in high school and many people said "Why do we do this? We don't know what will happen in 5 years, everything may change." And of course, everything changed. But having made the life plan allowed us to have a slightly clear picture of where we were going, it allowed us to take small steps towards where we wanted to go and whenever there were doubts we could consult that life plan to find out what was next .

Something similar happens, in my opinion, with the design. It is not something that should be followed to the letter, but it is a kind of guide that you may or may not follow depending on how the project is developed, but if you do not have it there will be no way to go to the place Right.

In my opinion the design is not dead, it has only evolved into a completely different thing. It is designed less and produced more, yes. But this design is more abstract, less specific and allows to be permeable in the development of the project for future changes. It focuses only on the fundamental parts that should not change to meet the system's requirements, but leaves the most specific things such as technologies, service architecture, database, for the consideration of the people who will develop the project, etc.

Who Needs an Architect?

The software architecture has always been known as "the physical design of the software system to be developed" with a great deal of emphasis on the structure of the components and the technology that will be used, at least where I have worked. However, this article mentions some important points that I would like to highlight:

1. It must be understandable for all the people involved in the development of the system, thus becoming the highest level abstraction understandable by the entire work team. This makes it easier for everyone to know where they are digested and make a better work plan.

2. The software architect must be involved with the process and follow up the people involved, serving as a guide for the project.

3. The architecture is based on the most important aspects of the system and this depends on the context, therefore the architecture of a system A can differ greatly in the aspects that it considers with respect to the architecture of a system B.

Finally, the idea of ​​eliminating architecture by reducing the difficulty of changing components at late stages seems interesting to me. Personally I am involved in the agile paragidma of project development, so this idea I think can be implemented not only in software projects but in others that, as mentioned in the same article, are not limited by physical laws but only for imagination, creativity and human capacity. I believe that, although making the systems easier to modify in the future implies an increase in complexity, it allows for better maintenance, selecting the technologies and decisions that best fit the progress of the project and ending with a better final product . That is, to involve the agile paradigm not only in the way in which the project is developed (activities, meetings, changes, etc.) but also in programming (components, classes, methods, etc.).