Guest post by Raju Pavuluri
Application Modernization:
Application Modernization touches several areas and many aspects – ranging from application transformation, data modernization to business transformation.
AI powered tools, such as TCA discussed in this article, aim at easing the move to cloud by providing automation.
Role of containerization:
Containerization assessment and planning is the most important and perhaps very first step one should consider in modernization journey. A containerized application provides consistent, secured, OS-independent and portable way of running scalable applications on the cloud, and is a winner in modernization journey.
Tackle Container Advisor (TCA):
TCA is part of Konveyor (https://www.konveyor.io) community of projects. Konveyor aims at helping people modernize and migrate their applications to hybrid cloud, focusing on building tools for container and Kubernetes adoption.
Why TCA:
When we think of containerization as an engineer or developer, we often think of a couple of applications, some middleware, a database and a language – and try to find if there are existing container images available to suit our needs. This will involve some research, some figuring out different versions of software and their inter-dependencies, whether or not they can run on a particular OS etc. Now imagine an enterprise. With potentially tens of thousands of such applications. And more often than not, their descriptions not following any standard.
For example, have a look at application descriptions like this.
- Application 1: cobol java javascript: : , , unix/mainframe, unix/mainframe: unknown , db2 oracle 10g oracle 8i vsam other – db2 v9, , ibm-db2-v9, oracle-oracledb-10g, oracle-oracle db-8i
- Application 2: mq client 7.5 rightfax client 10 sql server 2008 connect direct 4.5, 4.6 & connect direct file agent tws zcentric 8.4, , windows, windows: no, sqlserver
- Application 3: openedge: : tomcat 3/4/5/6/7, , hp unix / rhel / win desktop, hp unix / rhel / win desktop: yes, openedge
It could take months for humans to go through all such applications in an enterprise and figure out potential container candidates and map them to available container images.
Here’s where TCA comes to the rescue. In a nutshell, TCA provides automation to map applications to containers in different catalogs (DockerHub, Openshift).
An example:
Consider an application with a description given such as this.
Application 1: cobol java javascript: : , , red hat linux , db2 oracle 10g oracle 8i vsam other – db2 v9, , ibm-db2-v9, oracle-oracledb-10g, oracle-oracle db-8i, sql, jekins, mongodb, mysql
TCA does an assessment of this description, and comes up with candidate container images in different catalogs, such as –
DockerHub:
- DB2: https://hub.docker.com/r/ibmcom/db2,
- Oracle Database: https://hub.docker.com/_/oracle-database-enterprise-edition
- MongoDB: https://hub.docker.com/_/mongo
- MySQL: https://hub.docker.com/_/mysql
- Jenkins: https://hub.docker.com/_/jenkins/
Openshift:
- DB2: https://catalog.redhat.com/software/applications/detail/823403
- Oracle Database: https://catalog.redhat.com/software/applications/detail/837443
- MongoDB: https://catalog.redhat.com/software/containers/rh-marketplace/mongodb-enterprise-advanced-ibm-bundle/5f84ce93ecb524508951386d
- MySQL: https://catalog.redhat.com/software/containers/rhel8/mysql-80/5ba0ad4cdd19c70b45cbf48c
- Jenkins: https://catalog.redhat.com/software/containers/openshift3/jenkins-2-rhel7/581d2f4500e5d05639b6517b
Operators:
- MongoDB: quay.io/mongodb/mongodb-enterprise-operator:1.12.0
- MySQL: grds/mysql-operator:1.0.0
- Jenkins: virtuslab/jenkins-operator:v0.3.0
Furthermore, it even determines certain other aspects, such as –
- VSAM is Unknown
- SQL is a General entity
We can get an overall picture of what can be containerized, what cannot be – and for those that can be containerized, where we can get the images from. This significantly reduces time and effort in modernization advisory and improves recommendation accuracy.
How does TCA work?
Central to the tool is a Knowledge Graph – which contains entities, types and relationships. Essentially all the information that tells us if a piece of software can be run on a particular OS and if there is an image available for it.
The container recommendation is a two step process. First step is the Containerization Assessment – where the given application description is cleaned, standardized and matching entities and versions (where applicable) are extracted from the knowledge graph. Second step is Containerization Planning, where the container recommendations are generated. Here the assessment output from the first step is taken, and matched with container image information. Where required, a recommendation to install additional software on top of the images is provided. Image recommendations come with a confidence score, based on match accuracy.
Where to get TCA from:
TCA is an opensource tool available at Konveyor github organization. You can clone it to your local machine.
git clone https://github.com/konveyor/tackle-container-advisor.git
Running TCA:
Easiest way to run TCA is as easy typing as a single command on your terminal.
sh run.sh
This will do all the leg work for you, build a docker image ‘aca_backend_api’ and run it for you. A requirement of course is you need to have Docker installed and running!
An output on your terminal will look similar to this.
You can check running docker container.
docker ps|grep aca
As you can see, Tackle Container Advisor’s api is available now at http://localhost:8000 and ready to be used.
Play with TCA:
There are a couple of ways of using this api. You can keep using your terminal and use curl. Or you can use a browser to test the api. For this discussion, let’s use the browser for simplicity. In a browser of your choice, go to the url http://localhost:8000. You will see the TCA api page.
Let’s create an api key, to use this api. Click on “Authorize” button on the right and give any value for the apikey in the resulting popup box.
Let’s check health:
As a good practice, let’s check if our tool is running and healthy. Click on “health_check” api, and click on ‘Try it out’ button. This function does not have any parameters to fill – so let’s hit the Execute button. You will see that the tool is running fine, with a ‘success’ message displayed in the result.
Containerization Assessment:
As a first step, let’s test containerization assessment. Click on the “containerization-assessment’ api and hit the “Try it out” button. You will see the payload for this api in a box. Wherever you see ‘string’, you can input a value. For testing purposes, you can give arbitrary values for the name, description and component name. Let’s say our OS is RHEL, and we are using Java, C and Python languages in our application. Our middleware is websphere application server (WAS) and we are using db2 as our database. In addition, we are using redis, mq, Jenkins and angularJS. Let’s input these values.
Clicking on the “Execute” button will give us the following result. Our input is assessed and the output is given back to us in a standardized format. Notice that since we did not give version numbers for the software we got the latest version numbers, where applicable.
Alternatively, we can do this using curl in a terminal, giving it a payload like this –
and get a response like this –
Now, let’s try something different. Let’s intentionally introduce some typos and give db2 a version number.
You will see that the version number for db2 is honored, and the typos are caught and displayed with an “unknown technologies detected” error.
Containerization Planning:
Next up is the planning phase. Click on the “containerization-planning’ api and the ‘Try it out’ button. Remember, we had done the assessment before, and we have a validated assessment output in a standardized format given to us. We will now copy that and paste it into the payload window here.
Here we have three choices for the container catalog. First let’s try the default Dockerhub catalog. Keep it selected, and hit the Execute button.
Dockerhub:
You can see in the result we got matches for four container images from the dockerhub catalog – for WAS, DB2, Redis, MQ and Jenkins. We got their locations as well. We even have a suggestion to install C, Python and JavaScript on our images as they won’t come standard. Recommendation here is to containerize and we have a confidence score of 83%.
Openshift:
We have similar recommendation when we select Openshift as a catalog of choice, with of course different image locations. We have a better confidence score this time, of 93%. We even have less work cut out for us now, since these images come with Python and C already installed.
Operator:
Selecting “Operator” as a catalog choice, gives us the available Redis and Jenkins operator references. However, the recommendation is to “Partially Containerize” – because as the reason mentions – feasibility is unknown for WAS and DB2.
Scaling to cater large number of applications:
Using a simple python wrapper (or similar), we can use scale the usage of this API to advise for tens of thousands of applications concurrently. As can be seen, there is a significant reduction in time, effort and assessment errors using TCA as a containerization advisory tool.
For the power user:
Existing knowledge base is created with extensive research. However, with ever changing software space and container domain, the knowledge base should periodically be updated to cater to present needs. There may be cases, depending on client needs, to upload a completely new knowledge base as well.
Updating the existing knowledge base and running TCA with new knowledge base is explained well along with instructions in the repository documentation – https://github.com/konveyor/tackle-container-advisor#readme
If you’d like , you can watch our team’s full presentation to the Konveyor community on Tackle Container Advisor.