[What are Microservices? | IBM]

To prepare for my capstone, I decided to read up on microservices. This article is mainly just describing what they are, but it also mentions some common pitfalls towards the end. I was also interested in exploring criticisms of microservice architecture, but I want to keep the scope of this post short. However, I think it’s a pretty straightforward trade-off, which I will mention in a moment.

Microservice architecture is an architectural approach in which one application is composed of smaller components called services. This is distinct from other forms of software encapsulation because services essentially function as distinct programs, potentially operating on different programming languages, frameworks, and with their own databases. Rather than messages within the same process, services communicate over a network with a shared API.

Services can be updated individually without knowledge of the overall application. Different programming languages can be used for different components to better suit the needs of those components. Individual services can be scaled when necessary, rather than the whole application. This method also demonstrates the quality of “loose coupling,” which is lowering the amount of of dependencies between components as much as possible. The risk of a change to one service introducing problems in other services is still present, but minimized.

In general, this kind of technique basically combats complexity by adding complexity. It isn’t applicable to every situation. It should not be chosen if the overhead of designing the system is significantly more than the overhead of not doing so, which will often be the case for small problems.

For the purpose of the LibreFoodPantry project, microservice architecture is useful. In another scenario, such as one where high performance is a major concern, it may be a problem. If different services are busy sending messages back and forth, it can waste a lot of processor cycles on providing flexibility that isn’t really necessary.

Microservice architecture introduces complexity in communicating between all the services. Different tech stacks being used between different services raises the amount of general knowledge a person needs to be able to understand the whole application.

All this being said, I’m actually looking forward to working on a project using this architecture. The only large project I’ve worked on before was the backend for a school website, which was using a more monolithic approach. We were locked in to one specific language, and what we were doing was often a little inscrutable (although this may be in part because I was a junior in high school). I think that microservice architecture allows for more flexibility in low-level decision making, which will make using it in practice more engaging.

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.

This week I took a look at the pattern “Craft over Art”. According to this pattern, programming is a craft not an art. As software developers, we are being hired to build some piece of software to solve a customer’s problem. We should not be trying to indulge our own interests by creating something we think is beautiful. While our software can be beautiful, it must primarily be functional.

This pattern made me think about how easy it is to get drawn into the program you are writing, especially if it is a project you are passionate about. You can quickly get sucked in and start trying to put every bell and whistle you can in, especially with projects that include a visual aspect. As students it is especially important to not go overboard. While extra effort is appreciated by instructors, you cannot get over an A grade anyway. That time should be spent on other things.

An important point here is also that as software developers we are providing a service to customers. Because of this we cannot wait for inspiration to strike before we start working on a project. We should still do satisfactory work even if the project is not something, we are passionate about. This is a profession not a hobby.

Something that was not touched on here is often times the most beautiful solution in programming is also the most functional and the most efficient. Programming is a very function driven field. Unlike painting or sculpting where the greatest pieces can also be the most abstract, programming rewards the code that is the cleanest and the most functional. It is unlikely for a programmer to create something that is more beautiful than useful, especially in a professional setting. I could definitely see it happening though in a personal project or in a field like game development.

The most important part I took away from this pattern is the need for a minimal level of quality. I typically focus on getting the job done as fast as possible. I need to learn to maintain a certain internal standard. Quality takes time and I must work on taking the time to do it right. In the future customers will not be as forgiving or provide as precise instructions as professors. I have to be prepared to solve real problems for real people that do not have solutions already.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

What this apprenticeship dives deep into is that along your journey of becoming a software craftsman, there will be many times you face trials and tribulations. There will be instances where you are burdened with working on a complex project and forced to solve problems you have no idea where to even start. I am sure most of us on our journeys have faced this pressure and this feeling of whether this is all worth doing or whether we are cut out for it. However, this pattern says that we need to have clear and strong motivations when these trials come to our front door. Many people have different motivations as well as altering goals and ambitions. We are all developing software and programming for various reasons as clearly defining these things help us moving forward. We wouldn’t have made it this far if it wasn’t for some motivation that kept us going.

I think this chapter is very relevant for all of us who are trying to become software engineers and architects, and to understand that this journey isn’t just some smooth sailing. There will be times where everything feels easy and you feel lucky to even be in these circumstances. However, there will be other times that bring either the best or worst out of us when we face hard problems related to programming which can mess with us mentally. As a result of this pressure, we need to keep our road and ambition clear on where we want to be heading. Our journey is unique but to keep the journey going we need some strong interior purpose and motivation to pick up our head and keep moving forward on those days when we feel like there is no purpose for doing this. It is at these times, our mind is fogged up with the current problem and not on the bigger picture as to why we are doing all this in the first place. To clear up that fog we need sustainable motivations to be our anchor and help us get through and keep the boat moving. Overall, software architects will need to develop the mindset of believing in themselves and know they are doing what is right for them if they have a clear vision.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

There is more information available today than ever before, largely thanks to the advent of the internet and the ease with which that information can now be accessed as a result. Because of this increase in available information, the choices can often seem daunting when attempting to choose any source in particular. Especially when searching out books to look into regarding a specific topic, the sheer variety and number of options on even very niche topics makes it hard to make a decision on any one of them to study from.

Concerning the problem I just described, the pattern discussed in section 6 of of Apprenticeship Patterns, Reading List, outlines a useful technique for organizing the seemingly endless collection of books and reading which accumulates when studying a topic. The general idea is to keep a literal reading list, with all of the books (or other sources) you plan to read, reference, or look into recorded for the future. While the text seems to approach this from the context of physical books, I see no reason why this wouldn’t apply to any sort of reference, manual, or other self-educational materials in practice.

Additionally, the authors of Apprenticeship Patterns recommend maintaining the list as a priority queue, in that more important books or references will be studied first, before continuing down the list in order of importance. This seems like a good idea as it makes it easier to prioritize learning things in a more efficient order; subjects or topics which are less important would naturally proceed to rank lower and lower on the list and might eventually be removed if they stay towards the bottom for too long.

This process of removing dead-ends and passed topics of interest would keep the reading list relevant in the long term and help to maintain cohesion (it seems likely that irrelevant topics or sources would naturally begin to rank lower on the list, organically moving them out of the list over time).

Very probably in the near future, I will begin my own reading list, keeping track of prospective sources of information and reference which I feel will be interesting or useful to study. Considering the relative ease of implementing this pattern (keep a list), I would say that it is an easy way to optimize learning or research regarding any topic, but in the context of software development it seems even more relevant still. As there are oftentimes many disparate syntax manuals, tutorials, and textbooks to learn from which could benefit from the concrete organization afforded by a reading list.

Text Referenced: Apprenticeship Patterns, Guidance for the Aspiring Software Craftsman (https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch06.html#reading_list)

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.

For my second to last apprenticeship pattern blog post review, I would like to talk about simply because of how close it hits to home with me is the pattern entitled “Draw Your Own Map” in the textbook readings. This pattern is based on the fact that throughout the lives of software developers, there will be many times in which jobs or opportunities will not quite fit what they are capable of or are even interested in doing. The main issue brought up in this chapter was that none of the career paths provided to young software developers are often fitting for them. The reason that I chose to review this specific pattern is because I believe it relates to me very deeply as I am worried that whatever direction I end up taking after college may not be right for me. I already have many different options and directions that I could take from here and the opportunities are almost more daunting than exciting at this point. I am worried I will make the wrong choice early on. The book tried to solve this problem by basically saying that I choose my own destiny. “Identify a logical but ambitious next step for your career. Understand that it’s not up to your employer, your career counselor, or your professors to give you a hand up.” Sometimes the guidance of others is not what is needed even if it is with good intentions, because more often than not, I should know what I like best. The book also explains that no matter what direction I want to choose, it is important for me to make sure to take the first step. Without the first step, the dominos will not start falling and there will be no momentum toward my goals. If others (such as employers) try choosing a path that is not right for me, I must reflect and make the decision to stay on the course that I personally see best fitting for me. Obviously, when working, I should complete my roles and not give up, but in the end, it is not wrong for me to change direction and even switch career opportunities for my own betterment if I feel I need to.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

            The “Find Mentors” learning pattern from the Apprenticeship Patterns book is one that I definitely should have focused on earlier. This pattern is focused on find more experienced developers around you early and leveraging their knowledge and practice to take steps forward in your apprenticeship. Keeping with the master craftsman and apprentice theme, no apprentice will learn as effectively without someone to help them along their way and point out the unknown unknowns. The pattern recommends reaching out early and often. The only downside is rejection, which is easy to get over, especially if it is followed by acceptance at some point.

            In my computer science journey, I need to take this message to heart. Oftentimes, I try to do most of my learning on my own. I know I can have a kind of unorthodox way of teaching myself things, so I usually try to stick to myself when learning. I do quite often leverage the help/advice of peers though. Most of the people I’ve become closer with in the WSU computer science program I have worked closely with and either have some knowledge to gain from them or have some to share. While I realize working with peers is great, I definitely have fallen short on the front of getting help from those who are leagues ahead of me, like my professors. Looking back, I definitely should have attended more office hours and been in closer contact with my professors and advisors. That’s a goal I have for grad school, especially since I hope to be working as a research assistant, so this would be perfect.

            As the pattern mentions, it is difficult to get over the awkwardness of asking someone to mentor you. I’m not really sure how or who to reach out to in a professional setting, and I’m also not sure of what I would be looking for from a mentor. Although mentoring in school is great, it would probably be quite different than mentoring in a workplace. This is something I should look further into. Who can I reach out to as a mentor and what should I be looking to gain from them? If I can get the answers to questions like these, I think I would feel more comfortable filling the apprentice role.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

This week we began to discuss REST APIs. While it was explained in class, the concept kind of went over my head so I wanted to look more into what they are. While looking around I found a helpful article from sitepoint.com

The author explains it with an analogy. A REST API is a way for two systems to communicate over HTTP. This is like when you get car insurance. The insurance agency must get data from the government, credit agencies, banks and other systems.

He goes on to give an example of a REST API that just shows a bad joke.

He also talks about the other data communication standards like CORPA and SOAP. They are much stricter than REST which is not a standard but a set of constraints that must be satisfied for an API to be RESTful.

The next section discussed was something we covered in class, requests and responses. He also includes an example for the reader to try at home.

REST APIs also have some challenges associated with them. One is that there are multiple endpoints that can be used to fetch the same data like:

• /user/123
• /user/id/123
• /user/?id=123

This can make is hard to be consistent on a large project with many developers.

It is also important to keep your application secure and a REST API provides another level that needs to be secured.

The author ends with additional articles and links to learn more about REST APIs.

A lot of what this article covered was also covered in class, specifically the part about requests and responses. I feel like what we discussed in class was clearer and more made more sense. This is probably because we were talking about it and could ask questions if necessary.

What was useful from this article was the REST API example. I did try the example myself and it worked with no issues, though this is to be expected as it was just copying and pasting the code. I would have liked if there were more explanation, but this was a simple example so not much more could be said.

The author here assumes that the reader is familiar with JavaScript. I am new to JavaScript, but this example was simple enough that I could understand what was going on. I don’t anticipate us doing an example this simple in class, but it was helpful, nonetheless.

https://www.sitepoint.com/developers-rest-api/

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.