Skip to main content

FizzBuzz - part 4

 This is no longer really about FizzBuzz

At this point, we are not talking about a simple number generator, and if we ask people to pretend it's a "typical" enterprise web application, we can continue to talk with an applicant about what they know.

Nothing runs in a vacuum

Even with properly running FizzBuzz code, you still need to deploy it.  A simple deployment would look something like this:

  • It's not a good idea to directly expose your application server, so a more limited device like a firewall, load balancer and a reverse proxy server in some combination generally sits in front of an application.
  • Almost all enterprise applications will also need to store the results of their processing somewhere - otherwise why did we build this?
  • A cloud and an on premise deployment have the some functionality.  At the heart of it, they differ in
    • Who runs the component (vendor, customer or shared)
    • What it's called

Run in the face of adversity 

An applicant should also be able to look for single points of failure and suggest options for different performance, availability and complexity such as:

And we are still only talking about a single site.  The next level is multiple regions, zones, data centers, etc.:

And manage it too

On a different dimension, we have management concerns like:
  • Observability - The three pillars of management data are metrics, logging and traces.  Where are they going and how are they getting there?
  • Security events have to be tracked
  • Backups are probably necessary
  • Authentication and authorization are needed.

And then do it the other way too

Then you can discuss the ways to deploy FizzBuzz differently, perhaps something like:

If they have Kubernetes experience you could start with something like this and then discuss things like
  • Network Policies
  • Secrets
  • Config Maps
  • Deployments
  • Service Mesh
  • etc.

Comments

Popular posts from this blog

Spring Boot native builds when internet downloads are blocked made simple

 No direct access to the internet If you work at a company that controls their software bill of materials, it's quite common to be blocked from directly downloading from: Maven Central Docker hub GitHub (the public parts) Getting the bits Maven Maven is first, because without it, you won't be able to compile your Spring Boot application, let alone move on to turning it into a native docker image. I will be showing changes need to work with artifactory, but you should be able to adapt it to other mirror solutions.  repositories {   maven {     name = "central"     url = "https://artifactory.example.com/central"     credentials {       username = "${project.ext.properties.artifactory_username}"       password = "${project.ext.properties.artifactory_apikey}"     }   } } With this configuration change, you should be able to download your plugins and dependencies, allowing you to compile and ...

Kotlin Notebook when you're blocked from Maven Central

 TLDR; If you are blocked getting to maven central when first using Kotlin Notebooks because of company firewalls, you can use a tool like Fiddler Tool to redirect to a different network location. Kotlin Notebooks Kotlin Notebooks are a JDK based environment that brings the Python based Jupyter Notebooks  expressiveness to IntelliJ. From the blog post announcing the plugin, it looks like this: At home, the installation of jar files looked like this: I played around with it at home, but I couldn't use it at work.  Many companies, mine included, do not allow software components to be used when downloaded directly from the internet. In my companies case, we use a product called Artifactory, which allows you to mirror the content from Maven Central while still applying policies like CVE scanning, tracking, etc. The way it should work IntelliJ, as one of the leading IDE's, generally supports this quite well.  In fact, there is a whole setting page dedicated to dealing wi...

Active vs. Passive Log4jShell remediation

 Log4jShell  All computer professionals should be aware of the Log4jShell ( CVE-2021-44228 ) and it follow on defects.  There is no shortage of opinions and lessons to be be learned: The difficulty of performing safe interpretation The problems when assumptions are not clearly documented.  I, for one, was completely shocked to find out that a logging system would actually attempt to do variable substitution in an actual message. The difficulty of finding and resolving issues with such a common library that is not provided by an OS package manager. IT'S A LOG4J CHRISTMAS One of my favorite podcasts, Security Now - episode 850 , discussed an analysis by Google regarding the depth of log4j dependencies.  From the show notes : One contributing reason is because Log4j is, more often than not, an indirect dependency. Java libraries are built by writing some code which uses functions from other Java libraries, which are built by writing some code which uses functions f...