Category Archives: Week 12

Virtual Machines vs. Containers

Assume a software developer who has a Windows computer creates an application and sends it to a tester who has an Apple computer. Do you think the application would work on the tester’s computer? The application may not work because it may be runnable on only Windows computers. The developer should solve the potential problem by using virtual machines and containers, ways of packaging applications into self-sufficient units that can run on any computer. When I was learning how to use Docker, a program used to create and run containers, my instructor often compared it to a virtual machine. To make sense of the comparisons, the goal of this post is to define the relationship between virtual machines and containers. To achieve the goal, I will be using the information from Preethi Kasireddy’s article, ‘A Beginner-Friendly Introduction to Containers, VMs, and Docker” which differentiates virtual machines from containers by architecture.

A virtual machine is an emulation of a computer. It is run on physical computers, called host machines, using a hypervisor, a program that creates and runs virtual machines. A few commonly used hypervisors are VMware, Hyper-V, and VirtualBox. For every virtual machine, the hypervisor provides an operating system, application, and assortment of dependencies. When a virtual machine is running, it depends on its operating system to manage how the application uses a partition of the host system’s resources. Each virtual machine’s operating system then depends on the host machine’s operating system to manage how the host system’s resources are partitioned.

A container is an executable package with an application and the application’s dependencies. They run on physical computers called host machines, using a containerization application, a program that creates and runs containers. As of today, the most used containerization application is Docker. For every container, the containerization application provides an application and assortment of dependencies. Because every container does not have a separate operating system, one can think of it as a virtual machine without a separate operating system. When a container is running, it depends on the host machine’s operating system to manage how the host system’s resources are used.

When I think about the architectural differences between a virtual machine and a container, I think about a house and an apartment respectively. A house represents a virtual machine because each family has their own set of utilities in the same way each virtual machine has an independent operating system. An apartment represents a container because multiple families share the same set of utilities in the same way multiple containers share the host system’s operating system.

If I continue to pursue a career as a software engineer, my understanding of virtual machines and containers will help me decide how to deploy my applications. If I want my application to efficiently use operating system resources, I should consider deploying it with a container. If I want to deploy a system, I should consider deploying it with a virtual machine.

https://www.freecodecamp.org/news/a-beginner-friendly-introduction-to-containers-vms-and-docker-79a9e3e119b/

From the blog CS@WORCESTER – Andy Truong's Blog by atruong1 and used with permission of the author. All other rights reserved by the author.

UML Diagrams

Hello everyone and welcome back to another week of my blog. This week I will be talking about UML diagrams. UML stands for Unified Modeling Language and it is used to model business, application structures, programming languages, analysis, design, and implementation of software-based systems. In other words, it is a way to visually represent the design and implementation of complex software. There can be many lines of codes in your software and it can be difficult to keep track of all the class relationships and hierarchies. UML diagrams can make it easier for developers to see the relationships and hierarchies. UML diagrams can work for many different programming languages. It is a standardized modeling language that any language can incorporate into the language of their choosing.

There are two different types of UML diagrams. The two different types are structural and behavioral. Structural UML diagrams show how a system is structured. They show how classes and object components work together and show the relationships between those components. Behavioral UML diagrams on the other hand, show how a system would behave from the objects interacting with each other in it. In this class I am currently taking at Worcester State University, we look at the design and structure of programs through structural UML diagrams. We went through different versions of a “DuckSimulator” and its UML diagrams to see how the program can be improved. When given a difficult concept to add to the DuckSimulator, we were able to come up with a solution through the UML diagram because we could visually see how adding interface classes would affect the DuckSimulator.

The DuckSimulator structural UML diagram we used was a class diagram intended to be written in Java. UML diagrams are very commonly used to represent software that is based on object orientated programming because they can easily show the different classes with their attributes and behaviors as well as the relationships between each class. Class diagrams are split into three vertical sections. The section at the top is the name of the class, the section in the middle are the attributes, and the section at the bottom are the methods. Types of variables and return types of methods are indicated after the name and a colon (id : int). Typically the attributes in the middle section of each class are private variables indicated by a minus sign (-) before the name. Classes can be linked together with many different arrows to show relationships between them. UML diagrams are very powerful at representing a program written with a object orientated language.