The cloud for DevOps: Tools and tips to consider

Source – techtarget.com

Moving applications and operations to the cloud can be scary, even when you know the payoff can be big. Indeed, cloud technology can empower your organization and provide the on-demand resources your developers need.

But when you start to build the cloud for DevOps, you will face at least two challenges. First, the staff will likely have a steep learning curve. Also, the staff must be kept happy as it learns to perform DevOps correctly, and avoids unforced errors and embarrassing security missteps.

The way to marry DevOps and the cloud is to use a cloud toolchain. Instead of choosing tools based on personal preference, consider a simple rubric to evaluate how potential tools can fit into your DevOps process. This not only provides for the best possible outcome but also keeps any bias out of play

Play well with others and share

The highest compliment you can pay a kindergartner’s parents is to say the child plays well with others and shares. This applies to your staff as well. You need to make certain that each team shares the same tools.

For example, if you have three-tier monolithic applications but eventually want to build microservice-based cloud-native applications, then choose a tool that can handle both. Your teams should have tools that not only handle cloud environment provisioning and application release automation but can also provision virtual machines in your data center and deploy three-tier applications.

It helps to control costs if you use one tool for both the data center and the cloud as it will also ease the transition for staff who work on legacy applications. Bonus points: Your staff will realize their skills still have value in the cloud for DevOps.

Buy the cheap tool first and the good tool when it breaks

Some woodworkers say, “Buy the last tool first.” The idea is that you will save money in the long run and have a great tool first. This advice doesn’t work here, because as you begin the cloud for DevOps journey, you don’t know which tool you really need. Also, just like a powerful hardware tool, if you don’t have the experience, there’s a real chance you’ll hurt yourself. If you buy a tool and blindly run SQL tests, you’ll end up wrecking your database much faster than you ever could manually.

Before you turn to the cloud for DevOps, you can’t know what functions are essential for your company — security, monitoring or something else. Furthermore, your cloud provider or even open source tools might already offer these functions.

I have seen how companies fumble database schema changes in the cloud. A word of caution: Do not use just any tool and throw SQL scripts into Jenkins to handle database schema updates. This works until you lose track of which SQL script needs to run next or you forget to run specific SQL scripts altogether.When it comes to managing database schema changes, consider starting with an open source tool like Liquibase. Liquibase can run SQL scripts and only notify on success or failure. There is no central reporting infrastructure and certainly no enforcement of standards for governance and auditing.

Eventually, companies will look to a commercial tool to improve on their open source experiment. Of course, there is no reason to buy a commercial tool first. You may only need to update the database schema once a quarter — unlikely, but if so, you’ve got bigger problems. The same can be said about other open source tools with commercial upgrades. Use Jenkins first and then move to a commercial option like CloudBees.

Track metrics to measure improvement

Don’t fall into the trap where you choose a tool simply because you think you want it. That’s the wrong way to build your ideal cloud for DevOps toolchain.

Companies make decisions based on the expected return on their proposed investment. If you evaluate a tool that can increase application release performance by 50%, and that’s worth $10 million to your company, you should expect to pay far less than $5 million for the tool. This requires you to measure the application release performance before and after you apply the tool. You must also have a small sample to verify the promised returns.

When you add a new tool to the arsenal, you’ll need to — as they say in the construction business — “snap the chalk line.” You need to establish a baseline to measure your improvement. Then, add the tool for a single application and measure the new performance. If the improvement justifies the tool purchase, fine. If not, keep looking.

This approach holds your staff accountable, avoids personal preferences, and creates a simple rubric any staff member can understand and follow. When you build the right cloud for DevOps toolchain, you create a culture that expects value in any tool you put to work.