Skip to main content

Microservices

 This week, we read an article called Microservices by James Lewis and Martin Fowler, which did a great job explaining the differences between monolithic applications and those that run on microservices (and the ones that use a little bit of both). They explained the advantages and pitfalls of implementing any of these methods, and they conclude that while microservice-based applications seem promising, it's still too early to tell whether they'll be better than monolithic ones. Luckily for us, this article was published in 2014, and we're far enough in the future to know that they are, in fact, more widely used today.

Before reading this article, I was already aware of these different types of applications, and I knew that the market had a preference towards microservice applications, but I hadn't realized how much this change had affected how businesses are run today. From personal experience, I belong to a cross-functional (XFN) team that dabbles in many different products, all of which are owned by somewhat-small teams. And while modifying the code, it's very clear that everything is very modular, which makes it easier to work with if you're not too familiar with the product.

However, I do also agree with their opinion regarding the team's skill level. I wouldn't consider myself to be too skillful as a software engineer just yet, since I'm still starting out and have a lot to learn. For this reason, it's sometimes hard to move between different products, because just as I'm getting familiarized with one of them, my time there ends and I have to move to another, which sometimes includes a new language altogether. 

I would have to agree, seeing the success of the businesses who have adopted this kind of application development, that in an environment like ours, with constant innovation and continuous delivery, it makes sense to switch over to a microservice-based approach, but it is important for companies to consider its implications and take the necessary steps to reduce risks involved with them. 

Comments

Popular posts from this blog

Man on the Moon

The third episode of Moon Machines, titled  Navigation Computer  tells us all about the process of building the Apollo Guidance Computer. It amazes me the amount of work that goes into a project of this size, and it has always surprised me how many people don't care about space travel, or even the amount of people who, despite seeing all the people involved and all the hard work, still deny the moon landing ever happened.  I also found it really interesting how seemingly unorganized MIT's software team was while working on this project. This isn't meant as a jab at them, but the fact that one of today's most prestigious institutions didn't have a well-defined plan speaks of how much project management and software development in general have evolved in such little time.  However, it's also funny to see how little things have changed in that regard, in the sense that even today, the amount of work that goes into developing software is grossly underestimated (even...

4+1 View Model

 This week, we looked at many different resources: two very short videos ("The 4+1 Model" by the Virtual Training Company and "Six Blind Men" by Phat Phish) and an article by Grady Booch titled The Elephant and the Blind Programmers . What they all had in common is that they all touched on either the 4+1 view model, or a concept known as wisdom gap, which is very closely related to the model.  In order to explain the need for the 4+1 model, Booch relates it to the old Indian story, which talks about how different blind men examine an elephant and come to different conclusions as to what it is, since they are all looking at different parts of it. The moral of the story is that they are all right in their own way, yet none of them have the full picture. The same applies to the model. Depending on who you are and what part of a system you're working on, you'll be interested in looking at it from a certain way, which will definitely differ from the other team me...