We should take a minute here to consider what parts of our service might need improving if you are to use it in a real system and what the most optimal/practical mitigations might be. As the critical part of working with containers and the cloud is evaluating the pros and cons of larger architectures, this is something you should always try to do when developing a new system or changing an existing one.

From a cursory look, these are the obvious things that could be improved, what the impact is, and what might be the possible mitigations:

• The database has no authentication
  • Class: Security, very high impact
  • Mitigation: Private cloud or use authentication
• Database data is stored within Docker container (data lost if the container is lost)
  • Class: Stability, critical impact
  • Mitigation: Mounted volume and/or sharding and clustering

• Hardcoded endpoints
  • Class: Ops, very high impact
  • Mitigation: Service discovery (we will cover this in later chapters)
• Application server assumes it is the only one changing the word list
  • Class: Scaling, very high impact
  • Mitigation: Refresh data on each page load
• Application server requires database on container start
  • Class: Scaling/Ops, medium impact
  • Mitigation: Defer loading until the page is hit and/or show message that the database is not available
• Web server authentication is baked into the image
  • Class: Security, critical impact
  • Mitigation: Add credentials at runtime
• Web server authentication is over HTTP
  • Class: Security, very high impact
  • Mitigation: Use HTTPS and/or OAuth