Microservice Architecture is a strategy for designing software in which each part of software exists separately from the others in what is called a microservice. These microservices have their own CPU’s, exist in their own runtime environment, and are designed to do one specific job. Microservices communicate with each other through Application Program Interfaces (APIs) to form the whole of the product.

In their blog “What Is Microservice Architecture? Microservices Explained”, Johnathan Johnson and Laura Schiff discuss in detail the difference between Microservice Architecture and Monolith Architecture, a system in which the entire application exists as a single unit, and how Microservice Architecture is implemented and used. Today I want to discuss the pro’s and con’s of this architecture listed in the blog, and how I plan on using it in the future. I selected this post specifically because it goes into detail about the benefits and drawbacks of Microservice Architecture. If you would like to learn more about the specifics of the implementation, please visit the blog post linked above.

There are many pro’s to using microservices. The main reason it is implemented is because it promotes feature independence. This feature independence has many benefits, such as developer independence, isolation, resilience, and scalability. Personally I think that developer independence is the most beneficial since developers will become very competent with their microservice and will be experts at their specific job.

When a microservice wants to interact with another it makes a call to that service’s API. Since microservices exist in their own runtime environment they will continue to function even if that API call is not executed. This means that if a part of an application goes down the rest of the program continues to run, albeit at a loss of functionality. In my opinion this is the one of the best reasons to use microservices since it makes applications very resilient.

The final pro I would like to discuss is scalability. Since each service has its own dedicated CPU, its usage can be scaled to meet demand. I think this is a great byproduct of microservices, but do not believe this should be the main reason for using them.

The issues related to microservices are real, but manageable. Microservice Architecture adds complexity to a project, but this can be mitigated with training. Microservices also cost more since they use more processing power and require experienced engineers, but I believe the benefits are worth the cost. Finally microservices adds a security risk since each microservice can be attacked individually. Given an experienced team of engineers and good oversight, this risk can be lessened.

In conclusion, I believe Microservice Architecture to be a very good design choice and plan on using it in my future work. Reading the blog post was worth the few minutes it took, and I can say that I understand microservices much better now than I had before. The benefits far outweigh the risks and I can imagine many employers would already be using this architecture.

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

Semantic Versioning 2.0.0, SemVer for short, is a format widely used by developers to determine version numbers. When implementing Semantic Versioning, you will need to declare an API (Application Programming Interface). This is because the way the version number is incremented depends on the changes made against the previous API. A semantic version consists of 3 numbers separated by decimals and is formatted like so: MAJOR.MINOR.PATCH. There are rules to follow when incrementing each of the numbers and the SemVer documentation provides a very helpful summary of when to do so:

MAJOR version is incremented when API incompatible changes have been made.

MINOR version is incremented when backwards compatible functionality has been added.

PATCH version is incremented when backwards compatible bug fixes have been made.

Next let’s take a look at each version number specifically. I came across this blog post on the Web Dev Simplified Blog and it does a good job of explaining each of the versions further. 

MAJOR Version 

The major version number is only to be incremented when any API breaking change has been introduced. The blog provides examples and a major change could be as simple as an entire library rewrite or a rework of a single component that still breaks the API. The version MUST be incremented if any backwards incompatible changes have been made. It is possible that minor and patch level changes have been made as well, but they must be reset to 0 when the major version is incremented. For example, when a major change is made to version 1.17.4, the new version number will be 2.0.0.

MINOR Version

The minor version number is incremented when backwards compatible changes have been made that don’t break the API. According to the SemVer documentation, it MUST be incremented if any public API functionality is marked as deprecated and MAY be incremented if substantial new functionality or improvements are introduced within the private code. When incrementing the minor version number, the patch level must be reset to 0 as well. For example, when a minor change is made to version 1.14.5, the new version number will be 1.15.0.

PATCH Version

The patch version number is incremented simply when backwards compatible bug fixes have been introduced. This number is commonly updated, and the only change that should be made is the fixing of incorrect behavior. For example, a bug fix for version 0.4.3, would make the new version 0.4.4.

Hopefully this blog was helpful in understanding Semantic Versioning. It is evident of its wide usage that Semantic Versioning is a useful tool to use when creating new versions. For the most part, the process of deciding the version number is straightforward, but it is neat to see that there is an actual guideline that many developers follow.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Though most people may not consider this an issue during the early stages of learning how to use Docker for deployment, data retention and persistence is one of the problems that one needs to consider when they need to utilize Docker containers. Previously, I wrote about virtualization using either Virtual Machines and Docker, though I mostly focused on how both essentially work on an operating system and what they require regarding system resources. What I did not mention, however, was how either Virtual Machines or Docker operate when it comes to data persistence. We are aware that the host systems that we use retain the data that we create between sessions. This means that if I power the computer that I am using now off and then on after submitting this blog post, the majority of the data that was created in the previous session will be available in the next session. However, as we begin to work with virtualization, this  issue of data persistence becomes a much greater issue for us to consider when working with Docker. In the case of virtual machines, data persistence is not much of an issue.

Data persistence for Docker containers, however, works differently. It is stated in the Docker documentation that:

The data doesn’t persist when that container no longer exists, and it can be difficult to get the data out of the container if another process needs it.

https://docs.docker.com/storage/

When a container is stopped and then restarted, whatever files that were created and used in the container will be deleted and the container will essentially run on a “clean state”. However, there is a way to guarantee data persistence on a docker container at any point through binding mounts or volumes to the container. Though Docker offers other types of binds, such as tmpfs mounts and named pipes, I will mostly be focusing on bind mounts and volumes for the remained of this post as ways of maintaining data persistence between a host machine and a Docker container.

While I was researching for more information regarding the differences between using bind mounts and volumes, I came across the following two articles, one tutorial titled Docker Volumes – Tutorial on buildVirtual.Net and one article titled Guide to Docker Volumes on Baeldung.Com by Ashley Frieze. In the Baeldung article, Frieze showcases how the Docker file system works and, in turn, how data retention is affected in a Docker container before explaining the differences between using volumes and bind mounts. Likewise, the buildVirtual tutorial also outlines the above differences, as well as showing how to utilize and delete volumes through docker commands.

Although both bind mounts and volumes can be used for data persistence, it is important to know which method to utilize depending on where we want the binds to be stored in the host system or how other docker or non-docker processes may need to interact with the specific data.

Direct link to the resources referenced in the post: https://www.baeldung.com/ops/docker-volumes and https://buildvirtual.net/amp/docker-volumes-tutorial/

Recommended materials/resources reviewed related to Docker mount and volumes:
1) https://4sysops.com/archives/introduction-to-docker-bind-mounts-and-volumes/
2) https://medium.com/@BeNitinAgarwal/docker-containers-filesystem-demystified-b6ed8112a04a
3) https://www.baeldung.com/ops/docker-container-filesystem
4) https://digitalvarys.com/docker-volume-vs-bind-mounts-vs-tmpfs-mount/
5) https://medium.com/devops-dudes/docker-volumes-and-bind-mounts-2fb4bd9df09d
6) https://docs.microsoft.com/en-us/visualstudio/docker/tutorials/use-bind-mounts
7) https://blog.logrocket.com/docker-volumes-vs-bind-mounts/

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

The main focus of this apprenticeship pattern called concrete skills is to have a fundamental base. A person can’t just rely on having the ability to learn something, but they need to show that they already have some skills that they have learned and improved on over the years. Also, these skills directly relate to software constructing such as being familiar with a certain programming language and implementing different features that can be useful for a company. While it is important and recommended to have many soft skill qualities, you can’t solely rely on this to land a job relating to software. You need to be able to showcase technical skills and so this pattern talks about taking actions to improve skills that are needed for the certain job criteria. It recommends to look at cover letters of individuals who are currently doing the job you hope to seek and copy down discrete skills listed on it that you can use to improve yourself.

I think this pattern has a really great concept that software apprentices can use to improve their knowledge for programming and other aspects of engineering. We can’t just have the mindset that we can learn new things when the time is right and just try to learn it then. We need to do some more research on our own and try our best to not be relying on others to carry us to learn fundamentals. People in work and a team don’t want a team member who they constantly have to monitor and essentially babysit for them to complete their work. We need to learn the essentials for the required job and practice to implement those skills on our own to show a boss or team members that we are capable of doing the work. This will prove that you are in fact able to learn and down the line will be capable of learning a new software or process that is often the case with the technological advancement of the world at a rapid pace. Overall, I think once we follow this pattern in a practical sense and change our mindset, we will see vast changes in our skills as well as the way we look at learning.

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.

For this week’s blog post, I read the section  “Unleash Your Enthusiasm” from chapter two of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section talked about how software developers especially the newcomers find themselves self-holding back the enthusiasm you have towards the work than your colleagues. Mainly due to the fear of making a poor impression on your coworkers. As I was reading the pattern, I feel like it has a personal connection to me because I see myself in the same situation of holding back on certain circumstances, Mainly I do not want to make a bad impression. The author states that ” Most teams are not hyper passionate or overly enthusiastic about technology. Predictably, they are focused on delivering the next project or improving on the aspects of the development life cycle that are causing them pain”  I completely agree with this statement, I see many people nowadays in the field of technology are not passionate about the work they do daily.

However, I think it is important especially for a team member to be Optimistic, enthusiastic, and eager to learn.  For us, this is the perfect time in your career when it makes the most sense to take risks and speak your mind. Ultimately, we have very little to lose. Also, I believe that ideas and passion will add diversity and energy to a team. One of the risks the author talked how “unleashing your enthusiasm on an established team. If morale is low or if the team is not welcoming of newcomers, you will likely get some eye-rolling behind your back.” I agree with this but on a team that is open to excitement and contributions, you will provide some unique qualities that stand you out. Ultimately, unleashing enthusiasm or some excitement into your team is great because as a newcomer you will have a fresh perspective, which should allow you to offer some useful suggestions for improvement. Overall, this pattern was very interesting, and moving forward I should not be holding back, instead, I should show my enthusiasm qualities towards something and should speak up for what I think is right.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

When looking into opportunities for employment, a vast majority of posted openings or advertisements for positions include a list of requirements or preferred traits in prospective applicants. More often than not, this will include a minimum required degree in a related field (ie: BA in Computer Science) and a certain amount of experience in a certain language or languages, ability to work with specific frameworks and tools, and oftentimes a certain level of “work experience” in a related position.

While this often makes it relatively clear the sort of attributes employers are searching for when hiring, there is still the case of needing to stand-out, and prove your potential worth to a company. The pattern discussed in chapter 2 of Apprenticeship Patterns (https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch02s04.html), “Concrete Skills” discusses the idea of building up a central “concrete” set of skills which can be demonstrated to possible employers or managers as a way to showcase your skills and ability to contribute. This ties into the pattern “breakable toys” which I discussed previously, where the benefits of building practice projects solely for your own benefit and experience is showcased.

So by having a set of core skills, (comprehensive knowledge of a favored programming language, knowledge of common frameworks and adjacent technologies, web development and front-end development skills) you are able to better standout to employers, and can use these skills in making examples or “breakable toys” to showcase the extent of your abilities and what you can bring to a team.

I would say that the “concrete skills” pattern discusses a simple concept, but one which has value especially when looking to start a career or move on to a new position. Being able to visibly demonstrate proficiency to a prospective employer can showcase an ability to learn new things and improve self-sufficiently. As you would need to have somewhere to get practice or experience working with these concrete skills beforehand, using breakable toys in conjunction with the concrete skills pattern can work as a synergy, the breakable toys serving as examples to demonstrate the concrete skills to others.

Text Referenced:

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch02s04.html

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

            This week I read the section “Craft over Art” which is found in chapter three of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section focuses on a software developer’s struggle in balancing their own personal want of making something with artistic merit and a client’s need of a product fulfills their requirements. The developer might add components that may be impressive but could also be pointless to or be an outright hindrance to the client’s wants. The developer may also want to polish up a project to a mirror sheen that deadlines would simply not allow for. And additionally, a software developer is a craftsman and not an artist. That doesn’t necessarily mean that a developer can’t produce something with beauty; a craftsman creates beauty by fulfilling a request to their utmost abilities. It just means that the client’s wants should be balanced with the software developer’s personal standards.

            The whole “Craft over Art” concept I agree with and in fact, I’ve thought of the concept on some level before through a practical point of view. Like why would I add features to software that wouldn’t benefit the user in some way? I’d just be wasting time I could use to polish up the existing components of the software. For example, If I were to work on a program that kept track of the transactions of a business and I added an option to play chess, that’d seem kind of pointless. If I really wanted to make a chess program, then I’d set that aside as a side project that I could do for fun. That doesn’t conflict with the “Craft over Art” concept since there have been plenty of craftsman who’ve worked on personal side projects in between their main commissioned projects. Even when just talking about software, I’ve heard of a fair number of programmers who’ve made little side projects like a game for example on their off time. And when working on main projects, I at the very least try to fulfill the minimum requirements so I can go back and polish it up as much as I feel the need to. But even then, there are time where the circumstances don’t allow for much polish so I just have to suck it up.

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

For the next apprenticeship pattern that I would like to discuss, my choice was to do the one in the text book entitled “The Deep End.” This pattern was similar to a previous pattern that I have discussed in that it relates to a time when a beginner in programming is preparing to enter the real world of job opportunities. In the other pattern, I learned ways in which I should try to show that I am qualified for a new job if I do not have much prior experience, if at all. A lot of times, employers are looking for candidates who show that they have the skills necessary for the position based on many things (primarily prior experience or certification), but sometimes what is needed is more than that. Sometimes what is needed is the willingness to try more than anything else. For this pattern, the book discussed how to motivate me to dive off the deep end and get the job I want not just the one I think I can handle. If my enthusiasm and my will to excel and learn at the job remains strong, I should not have to concern myself as heavily with how well equipped I am for the job in the first place. I purposely decided to review this pattern because of what is going on in my life right now. I have been setting up job interviews and phone calls recently to try to get jobs after I graduate. In most interviews I have had, my background has been an issue even if the employer does not seem to think so. I am thinking too much about whether I will be able to even do the job if I get it rather than trying to get it as best as I can and then seeing what I can accomplish from there. The book explains that the solution to this problem is to reach for that opportunity even if there is the possibility that it could lead to failure. It states that “waiting until you’re ready can become a recipe for never doing a thing. So when you’re offered a high-profile role or a difficult problem, grasp it with both hands. Growth only happens by taking on the scary jobs and doing things that stretch you.” My solution would be to do just that. I am going to try to get involved in the opportunities that I have been hesitant about pursuing. The risk of failure is often overemphasized and crippling to anyone who tries to find their opportunities especially in the beginning of their journeys. I need to stop weighing the risks so heavily and quite literally “dive into the deep end.”

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.