How DevOps Could Ease the Transition to the Cloud – InApps Technology 2022

If you’ve ever been to IKEA, you’ve probably experienced  pain on the level of adopting cloud computing.

When you arrive at IKEA, you’re greeted by room vignettes that are “just gorgeous!” Everything is clean, neat, solidly constructed, amazingly designed.

Your partner says, “We should do this at our place! Let’s go buy it!”

So you go to the warehouse area of IKEA and start lifting boxes. Then, once you get it all to your house, you battle to put it together…if you ever actually finish.

Beyond the frustration of actually putting the furniture together, IKEA can do actual damage to the relationship with your significant other.

Imagine this same conversation with your team when you are trying to move an on-prem application to cloud. That conflict can be equally damaging to your working relationship, but it doesn’t have to be.

DevOps to the Rescue

Adopting a sound DevOps strategy (especially with the database!) can lead to success in moving to the cloud.

Consider the suitcase as a metaphor. Regardless of what airline you fly or what hotel you stay in, if you pack your things in a suitcase, you will be able to easily move them from home to plane to hotel and back again.

By teasing out environmental data from the release packages, you are beginning down a path to environment agnosticism

However, if you choose to carry around a pile of clothes and toiletries, you’re more than likely going to have a difficult (if not hilariously comical) time. Unfortunately, you can’t just go buy a DevOps suitcase for your application, but these three steps can help.

Separate the “What” from the “Where”

Consider your next application release a “dress rehearsal” for the cloud and treat on-premise servers as if they are short-lived. Identify hardcoded environmental information from the application. For example, hostnames and other environment-specific data may be located inside a JAR file. Have the developers make that properties file external to the JAR so it can be edited at deploy time.

By teasing out environmental data from the release packages, you are beginning down a path to environment agnosticism, which will accelerate a move to an ephemeral cloud environment where data like hostnames can change during every deployment.

Prioritize Self-Service

At some point, all changes will need to be self-service. We will not reach enterprise scale if every cloud deployment depends on a person at a console. Thus, during change, consider what information the administrator is providing and eliminate it.

To circle back to the previous example, if your team is entering information about the environment (hostname, path, etc.), consider providing a mechanism where that information can be entered when the deployment is requested. This is similar to having build parameters captured by a build server during requested builds.

Of course, you’ll want to create this initially for yourself. Be your own guinea pig and allow yourself the time and ability to test and improve before rolling out self-service to the full team.

Fail Better

This one is simple and succinct. Failure is how we learned to walk, and it’s still how we learn today. You must treat post-mortems as an opportunity to improve. Don’t just assign blame; assign action items. By taking a “never again” approach with flexibility, you’ll notice a significant decrease in failures…and so will the management team.

You will inevitably have failures as you prepare your company for the cloud. That’s O.K. Any seismic shift is bound to have some post-IKEA moments of tension and complexity. Just buckle up, implement a rational DevOps strategy, and you and your team will have a fully-furnished cloud existence in no time.

Feature image from iStock via Datical.