Monday, May 25, 2020

22 - Buzzword Alert - Container Basics

Date: 5/25/2020

Guests: None


Welcome and greetings


Recap of last episode

  • In the last episode, I discussed my adventure in MacBook Pro purchasing and upgrading. It’s not really a bad experience if you have the right tools, a little know-how, and a little bit of luck.


  • Check out the full episode using the following link.


Scott's Spot 5 - Tech Review - Mid-2012 Uni-body MacBook Pro


Summary of this episode

  • In this episode, I’m going to discuss everyone’s favorite topic….containers. I’ll discuss what containers are, how they are different from a regular bare metal server or Virtual Machine, and how they can make your application deployments and upgrades easier.


What’s in it for you?

  • After listening to this episode, you will be able to discuss containers with confidence, determine if containers are the right fit for your applications, and have the knowledge to begin the process of creating containerized applications.


Episode Content


  • What is a container?

    • An object that can be used to hold or transport something.

    • A standardized unit of software – from the Docker website

  • Container terminology

    • Container – a running instance of an image

    • Image (or container image) - an application that is coded as a container. A container is basically an instantiated image. There are currently several different formats for container images (Docker, Appc, LXD, etc.). The Open Container Initiative (OCI) is striving to define an industry standard for the image formats.

    • Image Layer – one or more items that have been added to an image configuration. Each update to an Image results in the differences being stored as a new layer in the configuration.

    • Base Image – every container has a base image or O/S that it is built off of. This is the starting point for new containers. There are several different ones to choose from: alpine, tinyOS, etc. Each one has some of the functionality that you would find the full version of an operating system, but not all of it.

    • Registry – contains a list of available images that can be downloaded and instantiated as containers. These can be hosted on-site by a company or they can allow their developers to use external registries. This can cause security concerns as you cannot always determine the security profile of an external image.

    • Repository – this is what you pull from a container registry. A pull command will download all version (tags) of the application hosted in that container image.

      • ex. docker pull abcxyz

        • abcxyz is the repository

        • and individual image would be abcxyz:latest or abcxyz:ver1.1

    • Tag – similar to how tags are used in git to identify a container at a specific point in time.

      • Refers to a specific version of a container image.several

        • abxyz:latest

        • abcxyz:ver1.1

    • Docker – this is a very popular container management system.

    • Dockerfile – this is a configuration file that is used to build a container.

    • Podman – another container management system.

  • How does it differ from a Virtual Machine or server?

    • A server is basically what you see is what you get when it comes to memory, cpu and storage. A Server can dual boot, but typically only runs one type of Operating system.

    • A Virtual Machine can have memory, cpu, and storage changed on the fly. A virtual machine doesn’t have its own physical hardware and shares resources with other VMs on the host. It still has its own full copy of the Operating System, so a defined number of VMs can run on a given host.

    • A container shares the system resources with other containers running on the system. It actually uses system level resources so its container OS can be much smaller and more containers can be run on a given host.

  • Where do containers run?

    • There are many flavors of containers and depending on how they are architected, they can be run on linux, unix, or windows hosts.

  • What can you put in a container?

    • Best practice is that each container should encapsulate a single application.

    • If you have multiple applications, you can put each one in a separate container and open ports between them so that they can communicate.

  • What are the benefits of using containers for application development?

    • Its easy to create your dockerfile (or similar manifest) at the same time as your application (they can both share the same source code repository).

    • If you mess up a container in development, you can trash it and create a new one quickly

  • What are the benefits of running your “production” applications in a container?

    • Its easy to scale your capacity by quickly spinning up new instances of your application that is running in their own container instance.

    • If one has a problem, you can easily kill it off and then create a new one to replace it. This results in very little downtime unless you are running an orchestration tool to manage your containers.

  • What happens when a container has a problem?

    • Like we said, you can easily destroy or freeze the problem container, create a new instance, and then troubleshoot what caused the problem with the original container.

  • How do you create a container?

    • First, you can download a container image of the source OS (alpine is an example)

    • Then you create a container by using the “docker run” or similar command.

    • You can then log into the container and manually install and configure all the software that your application needs.

    • Or….you can take the easy route and create a dockerfile that contains all the configuration information that the container manager needs to create and run your container.

  • How and when do you choose a third party source (vendor) for your containers?

    • You can use the open source version of the container managers or if you have a high priority application you can opt for the vendor supported route to ensure that there is a lower chance of failure in either the container or the container management system.


Recap of this episode





Like me….. Like my podcast…. Please share the link, click on the like, give us a thumbs-up, leave us a review, hit the subscribe button, and tell your friends!


Next Episode: <next_episode_description_here>




Where you can find us!


Direct Messages:

  • @cs_everhart on Twitter

  • ScottTalksTech group on Facebook

  • ScottTalksTech.slack.com


Links to Podcast Providers:


Monday, May 18, 2020

Scott's Spot 5 - Tech Review - Mid-1012 uni-body MacBook pro

Scott's Spot 5 - Tech Review - Mid-1012 uni-body MacBook pro


Date: 5/18/2020

Guests: None


Welcome and greetings


Recap of last episode

  • In the last episode, we discussed the various types of performance testing, how they are different, and some of the benefits that come from running a successful performance test.


Summary of this episode

  • You are in for a treat today…. I’m going to review the MacBook Pro that I bought off of Groupon. I’m going to talk about the reason why I chose this exact model, what it came with, and the upgrades that I had planned for it when I bought it.


What’s in it for you?

  • After listening to this episode, you will have a better understanding of this model of MacBook Pro so that you can determine if it is a project that you would want to undertake for yourself.


Episode Content


  • I have been watching a lot of youTube videos on several channels where the host buys and upgrades a mac (of some make or model).

    • It seemed like it was not that bad of a project to undertake if you had a little bit of handiness and chose the right model.

    • After watching what felt like 200-300 videos, I found on Groupon the model that I finally bought.

    • It was a mid-2012 uni-body MacBook Pro 13” model.

    • Besides the fact that the company that was fulfilling the order took forever to send me the laptop, it is a pretty good little machine.

    • I had a Dell before that and it was just too big to get in my backpack to take on trips.

    • I was looking for smaller laptop that I could take with me on trips so that I could record podcasts episodes from remote locations.

  • I unboxed the laptop and what was supposed to be a refurbished grade-A actually had a couple of tiny dents in the cover.

    • So I crank it up and it boots with no problem.

    • It took about 5 minutes to get to a login prompt.

    • Some of the specs that this thing came with: 4 GB RAM, core I5 processor, 500 GB 5400 RPM drive.

    • That is so not what I was hoping for.

  • Now comes the upgrades that I had planned.

    • So trash the RAM and upgrade to 16 GB.

    • Swap out the hard drive for an SSD.

    • I would love to swap out the processor but the board that came with it would not support a newer processor.

  • So back to YouTube to watch a couple dozen more videos on the best way to upgrade the macBook and I’m finally ready.

    • I pop it open and the ram upgrade goes pretty darn easily.

    • I then pulled the hard drive out and started to swap it for the SSD…….tada…...I don’t have the correct screwdriver to remove the posts that hold it in place.

    • So off to Amazon to order a complete set of micro tools which takes a week to arrive.

    • Then I try it again. Boom. I take the SSD where I had already copied the drive contents to and it popped right in.

    • Go figure. If you have the right tools, and follow the instructions, things just work.

  • So now I get the hardware straightened out and what do I find…..this sucker boots up in under 45 seconds.

    • From 5 minutes to 45 seconds. I like that improvement.

    • I tested it with a bunch of the core apps and it was pretty snappy.

    • Not stellar but not bad.

    • I ran the performance metrics and guess what I found out.

    • My expectations are pretty low apparently.

    • The benchmarks on this thing are really low.

    • But you know what….I’m not using it for gaming...I’m not a gamer….and I’m not doing 4K video editing on it….so for what I need it is what I’ll call sufficient.

  • If you choose to do this type of project yourself, you will need the following:

    • uni-body MacBook Pro (a model that is upgradable, check before you buy it)

    • A SCSI SSD transfer cable

    • A SSD drive

    • New memory cards (check the model you want to see what the main board memory capacity is)

    • A toolkit with specific screwdrivers.

  • This project only works because of the model of MacBook Pro that I selected. So buyer beware!

    • The mid-2012 uni-body MacBook Pro is the last model that is upgradable by the buyer.

    • All of the newer models have chipsets and memory that is soldered to the mainboard.

    • So…..you have to send your laptop to Apple to have it upgraded (for a cost).


Recap of this episode



Like me….. Like my podcast…. Please share the link, click on the like, give us a thumbs-up, leave us a review, hit the subscribe button, and tell your friends!


Next Episode: <next_episode_description_here>




Where you can find us!


Direct Messages:

  • @cs_everhart on Twitter

  • ScottTalksTech group on Facebook

  • ScottTalksTech.slack.com


Links to Podcast Providers:


Monday, May 11, 2020

21 – Making it in the real world - Performance Testing

Date: 5/11/2020

Guests: None


Welcome and greetings


Recap of last episode

  • In our last episode, I discussed the concepts relating to System Integration Testing. I talked about what it is, how it differs from other testing, and what you hope to gain from performing it.


Summary of this episode

  • In this episode, I’m going to discuss what performance testing is and the benefits that you receive once it is completed successfully. I will also talk about the different types of performance testing and how they each tell a different story about the health and reliability of your application.


What’s in it for you?

  • After listening to this episode, you will be able to discuss the various types of performance testing and the benefits of each one. You will hopefully be able to have conversations with your peers that show the value that can be realized by a successful performance test.


Episode Content


Performance testing goes by a variety of names but in all instances you are trying to determine how your application will perform under real world conditions. Nobody wants to deploy their application to their production environment only to realize too late that their web servers do not have the capacity to handle all the users that are trying to use it for some purpose. This is especially true for companies that run websites that sell products or perform banking activities.


Types of Performance Testing:

  • Load Testing: How the system performs under a defined load

  • Stress Testing: How the system performs when the load is increased

  • Spike testing: How the system performs when the load is dramatically increased for a short duration

  • Endurance testing: How the system performs when the load is maintained for longer than expected

  • Scalability Testing: How the system performs when it is dynamically scaled by a pre-determined factor for transaction volume (2:1, 3:1, etc.)

  • Volume testing: Another name for Load Testing that involves large sets of data.


Here are some of the activities that take place when you are planning a performance test:

  • Determine test environment requirements

    • This can include servers, operating systems, the application to be tested, other applications needed to run the test, and any configurations needed to ensure the successful completion of the performance test

  • Design performance testing requirements

    • what is an acceptable response time for the application under test for a given transaction type?

    • what is an acceptable level of uptime for the application and what tests will ensure that that level has an acceptable chance of being reached?

  • Design the tests that will be executed

    • identify specific use cases that are in the high volume category

    • this can be accomplished by working with the development team to identify candidate use cases.

  • Buy, install, configure the testing environment

    • this will include ensuring that the software required to execute the test is available, licensed, and configured prior to executing the test.

  • Write you performance testing scripts per the agreed upon design

    • This can be complicated with web applications that generate lots of dynamic content.

    • The dynamic content will need to be parameterized in the scripts so that run-time errors are not encountered during the test if a non-parameterized value is encountered

  • Execute the tests according to the plan

    • The performance tests are run as agreed upon.

    • Support staff should be scheduled prior to the test to ensure that any issues can be addressed in a timely manner.

    • The time it takes for a test to get to the steady state of a particular transaction volume is called the ramp up time and should be built into the testing timeframe.

    • The time it takes for all transactions to finish after the agreed upon transaction volume is reached is called the ramp down time and while not needed for most performance metrics that you will compile, it can help clean up a system if you are planning on running several performance tests consecutively.

  • Accumulate, document and publish the test results

    • all results should be collated and analyzed in order to provide the most accurate recommendation possible after a test is complete.

    • The results can either clear an application for release or send it back to the software engineering team for changes to improve its performance.


Recap of this episode

  • In this episode, we discussed the various types of performance testing, how they are different, and some of the benefits that come from running a successful performance test.



Like me….. Like my podcast…. Please share the link, click on the like, give us a thumbs-up, leave us a review, hit the subscribe button, and tell your friends!


Next Episode: Scott’s Spot Product Review




Where you can find us!


Direct Messages:

  • @cs_everhart on Twitter

  • ScottTalksTech group on Facebook

  • ScottTalksTech.slack.com


Links to Podcast Providers:

24 – Tools - Docker

     Date: 6/8/2020 Guests: None Welcome and greetings Recap of last episode In our last episode we contrasted a few different container man...