Lesson 2 -
Many organizations start their journey by taking traditional
RDBMS technologies 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 busi-
ness logic into the database. When using a container approach, the business
logic should be outside the database to facilitate scaling independent from
other applications 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 scal-
ability at different tiers of the application as workloads evolve.
Lesson 3 - Application state should never be stored in the containers. Con-
tainers 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 nec-
essary to manage workflows and user experience.
Lesson 4 - Messaging and workflow should be handled by services outside
the containers and application logic. This will ensure that services evolution
and scaling is accomplished in a manner that is independent from the applica-
tion functionality. It also enables more robust and reliable error and retry
handling.
These lessons show the importance of respecting two core cloud principles
when bringing containers to cloud: separating compute from storage, and the
emphasis on decomposing monolithic applications into smaller, loosely-cou-
pled 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.
50 | THE DOPPLER | SPRING 2018