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

Post a Comment

Popular posts from this blog

Software Architecture

 This week, we read a chapter of Pete Goodliffe's Code Craft: The Practice of Writing Excellent Code. The chapter, just like this course, focused only on the importance and different types of architecture. After this reading and after having completed the first Ruby activity, I think I finally have a good idea of what to expect throughout the semester.  Throughout our degree, we have always been told how important it is to design before we start coding, so that we have a "guide" and to get an idea of the workload or work distribution from the beginning. However, so far, it hasn't been taught to us in this way; we would think about the code, abstract it into a higher level, and define our design based on what we thought would be easier to do.  However, I now see that the correct way to do it is the other way around. Think of what you want your software to accomplish, figure out its scale and any other relevant details, pick a style that fits your project's needs, a...
Post a Comment
Read more

SOLID

 This week, we read a very straight-forward chapter by Edward Guiness of the book Ace the Programming Interview: 160 Questions and Answers for Success. It very quickly explains the SOLID principles, which are widely-known principles applied to object-oriented programming that have to do with minimizing dependencies between classes. I won't explain what each principle consists of (since it's very easy to find ), but I will share my general thoughts about them.  I still remember when I first started university, my code consisted of one very long python file that you could very easily read from top to bottom; the concept of functions was still foreign to me, and when we started using them, we would split up all of our code into two or three functions and that was that. Since then, we've been introduced to many different ways to make code cleaner and easier to read, and one that's been repeated often is the Single Responsibility Principle, which I agree is very useful in or...
Post a Comment
Read more

Hidden Figures

 This week, we watched a movie called Hidden Figures , telling the story of black women working at NASA at the time of segregation. I originally watched this movie when it came out, and saying I liked it would be an understatement. It's not a perfect movie by any means; I think the message was a little bit too on the nose and most characters besides the three leads were one-dimensional.  However, I think the movie does a great job at highlighting how oppression works. If you really think about it, there is no "bad guy". Everyone is just living their lives, trying their best, and following the rules that were set by society; no one is actively trying to make the main characters fail. Still, at almost every interaction, we can see they have to try harder than everyone else, and there's always the feeling that something could go wrong for them. And it's not obvious if you don't think about it, but that's the feeling they are faced with every day of their live...
Post a Comment
Read more