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
Post a Comment