This blog article is the second of a three part series which describes how FlexDeploy enables the transition from running your Java applications on-premise to running them on the Oracle Java Cloud Service. The first article in the series focused on moving applications from on-premise to the cloud (i.e. “lift and shift”). This article will explore how FlexDeploy fosters another important facet of cloud computing – utilizing dynamic capacity to reduce cost. There are two aspects to dynamic capacity: quickly spinning up and tearing down cloud environments on-demand, and “turning off” environments when not in use to more effectively manage subscription costs. The Oracle Cloud Services enable both aspects, but for the purpose of this blog article we will focus on the later.
Certain environments during the dog days of the software development lifecycle can be utilized nearly 24×7. However, most organizations have environments that are not used quite so regularly. This may be test environments that are only utilized during the day, user acceptance testing environments that are only used during the later end of the release lifecycle, or in support environments that are only utilized to troubleshoot reported production problems. When you purchase an hourly subscription to Oracle Cloud Services you only pay when the environments are up and running. So effectively managing when the environments are running can produce a huge cost savings year over year. The remainder of this article will demonstrate how FlexDeploy can help manage this dynamic capacity more effectively.
Using the Java Cloud Service console I have provisioned 6 instances. A DEV, QA and PRODUCTION instance for managing the entire software lifecycle of our Payroll applications, and a DEV, QA and PRODUCTION instance for managing our Purchasing applications. In FlexDeploy terminology that relates to following constructs:
- 3 Environments (DEV, QA and PRODUCTION)
- 2 Instances (PAYROLL and PURCHASING)
Each FlexDeploy environment instance defines the properties required to connect to its associated Java Cloud Service instance.
FlexDeploy provides a Java Cloud Service plugin with operations to stop and start JCS instances. Let’s create two workflows to implement these operations. Their implementations are simple one step workflows which invoke the plugin operations.
We will now create a project to manage stopping our JCS instances, and another project for starting them. The JCSBuild workflow is simply an empty workflow without any steps. The purpose of the build workflow is simply to create a project version that can be deployed. In this case we are not actually deploying anything, but rather will use the build/deploy lifecycle to implement stop and start operations. For the deploy instances we will select the two instances we created above (PAYROLL and PURCHASING).
What makes these two projects a bit unique is that they are not used to build and deploy artifacts. Instead we are utilizing the underlying automation mechanism that FlexDeploy workflows provide. To accomplish this we must first create a project version (produced by a build operation) for each project. Since we won’t actually deploy anything, we will only ever require a single build for each project. Once these static builds are created we can run stop/start operations to target environment instances by way of the deployment workflows.
Now that we have configured the topology, workflows, and projects, and have created the static builds for each project, let’s explore the different options we have for executing the workflows. We have all the same options available as we do for managing builds and deployments. First, we can run the workflows on-demand by opening the start or stop project and clicking the “Request Deployment” button. In the Deployment Request Form simply select the Environment and Instance(s) you wish to start or stop.
Once the workflow request is completed the associated Java Cloud Service instance will be stopped/started. You can verify the instance status using the Oracle My Services console.
While on-demand options are suitable when environment usage is not deterministic (e.g. a production support environment), scheduling options become very powerful when usage is deterministic (e.g. during the day or during weekdays). You can schedule deployments using cron or your enterprise scheduler. FlexDeploy exposes RESTful web services, which can be invoked from the command line using the unix curl command.
See the FlexDeploy API Guide for detailed information regarding the REST API.
I have described use cases for starting/stopping cloud instances on-demand, as well as scheduling those operations using FlexDeploy’s REST API. Another more interesting use case is to integrate those operations into the build, deploy, and test lifecycle. Envision a scenario where testers are actively testing applications in a QA environment during the day. Application Development teams are busing fixing defects reported by the testers, and ultimately will deploy those changes into the QA environment after testing has commenced for the day. After deploying the application updates the environment will remain unused until 8am the next morning. Using FlexDeploy we can create a deploy workflow which performs the following:
- Deploy the application
- Execute a series of automated test cases
- If the test cases pass some defined quality metrics, shutdown the instance for the day
- If the test cases fail the quality metrics, fail the deployment workflow and notify the development team there is work to do
In summary, with Oracle Java Cloud Service’s hourly subscription model, and FlexDeploy’s rich plugins for Oracle Cloud, customers can take full advantage of dynamic and cost effective capacity in the cloud!
