Last week, Amazon announced the end of the reserved instance, commonly known as the “RI”, with the announcement of their new replacement, “AWS Savings Plans”.

If you happened to be in Tel Aviv, Israel last month, you probably saw the eye-catching JFrog billboards that took over the city. The JFrog logo with a solid bright green background challenged all of us to Imagine There’s No Version. The JFrog green billboards were everywhere! Decorating trains and buses and lighting up the city landmarks. The message was clear; it was an invitation to imagine a future where software updates flow like water.

While multi-site Kubernetes orchestration has numerous benefits, all of which have the potential to translate into a significant competitive edge, it still largely remains elusive — at least in the vendor space. The reason? Well, multi-site configuration is hard and, since during the first adoption wave, the focus was mainly on one cloud (most enterprises start with simple projects), there wasn’t a real need for it.

Yes, you read it right! The journey of existing apps on-prem to cloud-native has been automated with the use of CloudHedge.io. Allow me to share different steps taken for automation and which scenarios are a better fit. If you have 100s and 1000s of applications and are looking to assess them for cloud readiness, it can be overwhelming! The mix of applications, the infra, the network, and the geographic spread does make the effort of assessment overwhelming.

Now that GitHub Actions version 2 is out of Beta and available for general use, how can you start managing your Artifactory repositories in your automated DevOps workflows? Who will save your binaries in distress? Never fear, JFrog is here! A new Action has joined the GitHub Marketplace that enables you to use the JFrog CLI in your GitHub Actions workflows to move your builds through development, test, and release.