Migrating Java to the Cloud

Chapter 4. Getting Cloud-Native Deployments Right

In traditional enterprise deployments, it’s typical to have only a few machines and a single shared database. We assume the server and database IP will never change. We may use a virtual IP address (VIP) to dynamically reroute traffic in the event of a failure, but for the most part keep things simple with hardcoded or config file–based static IPs.

Before a major deployment, everyone sits in a room and discusses the plan before submitting the change request. The Change Management team reviews all of the scheduled changes to ensure the change won’t interfere with other activities in the organization. They’ll approve the deployment after reviewing all of the artifacts in a Change Advisory Board (CAB) meeting.

To redeploy the application, everyone gets on a conference call in the middle of the night and starts the deployment process by changing the httpd configuration to display a maintenance page. Two hours later, after manually making changes to the database schema, and modifying some configuration by hand, everyone congratulates each other on a job well done, hangs up, and goes back to bed. As we fall asleep, we pretend everything is fine; there’s no way we made a few mistakes when we manually edited the environment, right?

“On the bright side, even if the worst happens it’s not like I own the company. I can always find another job.”

But the first time an enterprise team redeploys their systems in the middle of the day with no ...