[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.

“Interpreter Pattern – Spring Framework Guru”

The above article describes in detail how the Interpreter pattern from the gang of four book works. Before I continue, I should specify that the book, this post and the above article are focused on the Interpreter pattern primarily in terms of object oriented programming, which is not the only way that the general concept may be applied. There is the general idea, which is creating a small, limited language inside of a program, and then there is the gang of four specification, which includes more specific implementation details. For example, it mentions regular expressions, which do not necessarily have to be written in an object oriented way.

I sort of understood what the interpreter pattern was in a broad sense, but not in the specific technical sense one needs to actually make use of it. For example, I didn’t know that it employed the use of another pattern, called the Composite pattern. The Composite pattern is essentially the idea of treating individual objects and compositions of objects uniformly by representing them as a tree. The Interpreter pattern uses the Composite pattern in order to represent an expression to be interpreted. It does this by representing the components of the expression as atomic expressions arranged in a tree called an “abstract syntax tree,” and then expressing the language by recursively processing each node in it. The components of this expression may be either non-terminal or terminal, representing operations with and without operands, respectively (for example, a multiplication versus a constant). The pattern also specifies a “context,” which represents string data that is parsed, and a “client,” which actually parses the expression.

This pattern may be useful in a case where I want to create a smaller, more focused programming language inside of a project for use by less technically oriented people. Specific potential use cases like this include a language for writing plugins in an art program or a simplified language for directing game behavior inside of a game engine like GameMaker’s GML. Other, more common examples include SQL parsing and, as was mentioned previously, regular expressions.

At its core, the Interpreter pattern is essentially about converting instructions from one language to another, much like how a language interpreter interprets ideas from one language to another. “Interpreted” languages such as Python can be seen as an instance of this idea, using an interpreter to convert Python expressions into work by the computer. In the same way, you might also view a C compiler as an interpreter that converts C instructions to machine instructions.

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.