Fast Five Things to Get Ready for the Cloud

Following up from my talk at SpringOne Platform this year I wanted to post a little deeper on the Fast Five. The Fast Five things you can do to your app today to get ready for the cloud tomorrow. Looking at some the things that are not as invasive but impactful when modernizing.

But in no particular order here are the Fast Five:

• Codebase
• Configuration
• Build, Run, Release
• Disposability
• Logs

Mind you these are all part of the 12 Factors. Taking a deeper dive on these concepts:

Codebase

One codebase tracked in revision control, many deploys

Codebase is going to be more on process within your organization than anything else. Once you have identified all core components your app need centralize all on to one code base. Now this seems like a crazy idea. Thinking it through this is one area for one to refactor and decompose your monolith. Now trying to figure out what to collapse in to one code base is not easy. The complexity of any organization has way to many nuances.

Branching strategy is part of this. Establish a branching strategy and stick with it. There are plenty of them to choose from (GitFlow, GitHub Flow, etc.). Focus on not allowing long running branches either. This is a management nightmare and avoid them at all cost. To combat this feature flagging products like Launch Darkly are great to use for this.

Configuration

Store config in the environment

We have constantly deployed configuration with our apps for years. This worked great when we were only deploying a few components to an environment to get an app running. But as we move to the cloud deployment points will grow. It is the simple nature of building a distributed system. So a simple config change would require a change in a lot place. To address this is centralizing configuration. Using something like Spring Cloud Config helps solve this issue.

This moves configuration from being deployed with our apps to being served up by SCC. Our apps consume the configuration being served up through a lightweight client.

Build, Run, Release

Strictly separate build and run stages

This is once again a bigger change on an organizations process rather than a technical change. Once a change is build it should be treating as immutable. Changes to that artifact should go through the build process. What we mean by this is if a build artifact has the wrong reference don’t add the correct binary to the artifact. Change the code to call the correct reference and rebuild and deploy that artifact.

Disposability

Maximize robustness with fast startup and graceful shutdown

Of all of the Fast Five this one isn’t the easiest to implement. This is a technical change that isn’t easy to implement. There are two sides of this start up and shut down. Where each need some careful consideration. For start up getting the start up time to be less than 15 seconds. This isn’t critical now but when deployed to the cloud this is critical. Shut down is just as important. You should target getting your shut down time to being less than 5 seconds. Shut down should not result in the lost of data.

Logs

Treat logs as event streams

Logs are again a technical change, meaning a code change. Where you should centralize on a single logging library. Each deployment point should have a single point where it is writing a log externally. This makes it easy when you need to change the way your app logs when moving to the cloud.

Conclusion

These are a few things today you can do to prep any app for a full on cloud modernization effort. This are not specific to any language we have done this to both .NET and Java apps. Here is the video of my talk at SpringOne.