The Doppler Quarterly Special Edition 2019 | Page 72

Lesson 2: Many organizations start their journey by taking traditional RDBMS tech-
nologies and putting them into containers. However, this practice creates operational
issues and makes the movement of containers difficult due to growing volumes. This
approach also risks encouraging embedding of business logic into the database. When
using a container approach, the business logic should be outside the database to facili-
tate scaling independent from other application functions, but also to allow flexibility in
the choice of data store to be used. Business logic should ideally be integrated with
other aspects of application functionality through a publish/subscribe model, enabling
scalability at different tiers of the application as workloads evolve.
Lesson 3: Application state should never be stored in the containers. Containers are
transient resources that cannot be relied upon to store persistent information. Instead a
data store layer should be used to track state that is necessary to manage workflows
and user experience.
Lesson 4: Messaging and workflow should be handled by services outside the con-
tainers and application logic. This will ensure that services evolution and scaling is
accomplished in a manner that is independent from the application functionality. It also
enables more robust and reliable error and retry handling.
These lessons show the importance of respecting two core cloud principles when bring-
ing containers to cloud: separating compute from storage, and the emphasis on decom-
posing monolithic applications into smaller, loosely-coupled functional modules. When
combined with the ephemeral “deploy when needed, destroy when done” capabilities of
containers, these lessons enable the provisioning of architectures that feature the best
inherent characteristics of both cloud and containers.
70 | THE DOPPLER | SPECIAL EDITION 2019