back to all blogsSee all blog posts

Meet our open source champions: Monica Tamboli, Quality Assurance Warrior

image of author image of author
Monica Tamboli and Grace Jansen on Nov 19, 2021
Post available in languages:

In this blog series, we’re highlighting some of the amazing individuals who contribute to Open Source software (OSS). We’ll delve into their contributions within OSS, their career journey, how OSS involvement has helped them, and their advice to others for getting involved.

Introduction:

Monica Tamboli is System Verification Test (SVT) Team Lead for WebSphere Hybrid Edition, which includes Open Liberty and various application modernization tools. Monica has more than 20 years of industry experience, most of which is focused around the Java ecosystem. Lately, her focus has been on testing applications in containers on Kubernetes, especially OpenShift on private and public Clouds (IBM Cloud, Azure and AWS) using Open Liberty and WebSphere. She is also involved in testing operational and application modernization using tools like Transformation Advisor and Mono2Micro. She enjoys sharing her experiences with modern technologies at various conferences (DevNexus and ACT-W) and STEM events for schools. She is passionate about going green and sustainable living. 

Headshot of Monica Tamboli

Tech introduction:

Operational modernization gives an operations team the opportunity to embrace the practices for modern operations without putting change requirements on the development team. As companies are using containers and moving their operations to Kubernetes clusters, they are looking into moving their existing application to Kubernetes. This path gets the application into a container with the least amount of effort but doesn’t modernize the application or the runtime. The Open Liberty Operator helps to deploy and manage applications running on Open Liberty into Kubernetes clusters. With this operator, you specify details for your application, such as application image, service port, and whether to expose the application outside the cluster. It creates and manages all Kubernetes resources like deployments, services, routes which can involve significant learning curve. You can also perform Day-2 operations such as gathering traces and dumps using the operator. The Open Liberty Operator has a capability level of five, which means that it has the highest level of enterprise capabilities. 

Runtime Modernization moves applications from traditional runtimes to cloud-ready runtimes like Open Liberty. Tools such as Transformation Advisor facilitate this move. However, the application is mostly unchanged and is not modernized to a newer architecture such as microservices.

Application Modernization involves refactoring business-critical monolithic applications into microservices. These microservices are independent and scalable running in a cloud-ready runtime like Open Liberty providing agility and improved speed of delivery. Tools like Mono2Micro can accelerate this process of breaking monolithic application into microservices. These microservices use cloud native runtimes like Open Liberty and use open cloud-native Java frameworks like MicroProfile to use services such as fault tolerance, health and metrics.

Q&A:

How did you decide to focus on system testing work? Describe a little bit on what does this work involves.

My first job as a Unix System Administrator involved managing production systems. Although I learned new things, I did not enjoy it much. So when I was looking for my next job, I had 2 offers: one from the development team and the other from test team of the same product. I decided to start with the test team to get a good high-level view of the product with the intention of moving to the development team after some time. However, I have been enjoying my job so much that I have stayed with testing/QA. I know some people think of QA being the first job anyone with 6 month of training could do. But that is not the case here. This level of testing is very involved. 

We have a diverse range of customers each with their own application and environment/infrastructure. But really, it’s the system test team that is the first customer for our products - helping to ensure everything works effectively before our 'real' customers get the technology or update. In testing, we have to simulate our customers environments by developing business applications and running them on different platforms for long periods of time and under stress. Debugging problems in complex environments can be very challenging to determine real defects versus user issues or problems in other tools. This job requires a mix of various technical skills, including cloud administration, system administration, database administration, automation development, and programming/scripting.

As you have been with the Liberty team for a number of years, can you describe some of the systems that you have worked on?

I joined the Liberty team during earlier versions of the traditional WebSphere Application Server. My earlier testing involved setting up different operating systems (like Solaris, AIX, HP-UX and Windows) and installing WebSphere, Database Systems (DB2, Oracle, Sybase, MS SQL etc) and LDAP servers. Then I assumed the roles of different focal points, including dynamic caching, transaction processing, and security. Security has been my favorite because I got to work on technologies like SSL/TLS, OAuth and OIDC, which you can see in action during the daily life as a consumer of e-businesses. Check out my blog to find out more.

Later, it was really interesting to work on WebSphere Liberty and Open Liberty. A few years ago, we started to focus on testing our WebSphere products in containers on Kubernetes. As a part of this, I also got to work on additional open source projects like Kabanero, Appsody, and Tekton. I also own a Java EE test application focused on testing enterprise security that I update for new features, including migrating to Jakarta EE. In addition to running test applications using Open Liberty on VMs, my team also uses container images to deploy them to Kubernetes (OpenShift) clusters using the Open Liberty Operator.

Photo of Monica with colleagues at a conference booth

What do you think are the challenges of doing system testing in the current "modern" cloud native environment, and how are they different from the previous "cloud-less" days?

This question took me down the memory lane of the fun days when we used to work with physical servers in a typical noisy lab. You would put actual compact disk (CD) in those systems to install OS and other products. Slowly, CDs got replaced with network installs and physical machines with Virtual Machines (VMs) and now containers. As much as I love new technology, sometimes it feels like we had better control over those systems. The technology scope was not as wide and it was not changing as quickly.  

Cloud-native offers many advantages for our workloads like agility, scalability, and portability but it brings many challenges as well. The technology involved is more complicated and there is a steeper learning curve to fully grasp and reap the true benefits. With open source, there is a wider variety of product choices and technology changes very rapidly. By the time you get comfortable with a product, there might already be a new product you need to consider. It is hard to predict what additional products (like, for observability) our customers will use with our products, making it harder for us to mirror the customer environments. In modern cloud native environments, many container images that include products in your environment could be available and you want to make to use the correct certified images. It also becomes important to take appropriate security considerations like scan (vulnerability detection) and sign (to avoid tampering) for the images. Lots of our workloads involve transactions and require stateful deployment. Finding the correct persistent storage in different cloud environments can become a bit tricky too. 

Given the widespread DevOps practices nowadays, are you finding it easier to perform automated testing than it was back in the days before DevOps, or, are you encountering any new obstacles at all? What open-source technologies have enabled this to be easier?

DevOps encourages automation at every step to achieve speed and agility and is an integral part of our testing strategy. Jenkins jobs are used to automate various steps of the testing lifecycle, saving time , avoiding user errors, and archiving logs and metrics for later reference. Travis is used for building and verifying SVT applications updates. We also used Tekton Pipelines to automate various tasks like building the application, publishing the image to container registry, scanning the image, and deploying to the cluster. DevOps also encourages "Shift Left Testing": moving testing tasks as early as possible in software development process. This involves a cultural shift for an organization and you must also find the right balance of automated versus manual tests. To me, the biggest challenge seems like too many choices, with each of having different strengths.

We use many open source technologies like Kubernetes, Podman, Docker, Git, Maven, Jenkins, Prometheus and Ansible. These open source tools have helped us tremendously to become more efficient and effective by automating multiple tasks.

Can you give any advice to team leads or managers out there who have perhaps experienced prejudice or discouragement towards testing on how they can enable a love for testing among their team and specifically enable new or younger team members to once again be excited by testing?

I have had many opportunities to mentor interns who are often skeptical about System Test when they join our team. But by the end of their internship they would enjoy the work and many of them chose to return and work for us within the testing team after graduation.

I’d give this advice: It is really important to spend time to find out what their interests are (for example: AI, Cloud, Coding, DevOps etc) and find them something which keeps their interest and creativity alive while contributing towards the team goals. Also, I think it’s important to take time to really explain and emphasize to them the broad scope of testing for your product. For example, the flexibility that comes with a role in testing means they can work on all aspects of application development and operations. Automation provides a fantastic, solid foundation as they progress in their career and enables them to develop valuable skills useful in many other roles.

My words of wisdom: In the technology field these days, there is so much to do. There should not be a dull moment at work. If you are not feeling motivated, talk to your team lead and find something which excites you. 

How did you feel when you first started working on and contributing to open-source products?

Initially, I found it a little awkward. We were opening bug issues on a public GitHub repo and that process was a bit intimidating. But, it is something you get used to over time and gradually grow more comfortable and confident doing. Most of the people working on these projects are very passionate, supportive, and helpful. Anybody from the entire globe could be your teammate - I love that! I have enjoyed working on many open source projects: Kubernetes, OKD,  Open Liberty, Open Liberty operator, Tekton pipelines, Kabanero, Appsody etc.

Monica presenting her work at the DevNexus conference

What advice would you give to someone who is interested in getting involved in an open source project? Any specific advice for those wanting to contribute to the quality assurance elements of a project or technology?

I would start with using the open source technology first to get comfortable with it. Open bug issues in the open source repositories and start working with the community. It is important to be very specific and provide all relevant details when opening bugs for any open source projects because people may not have the same context as teams within the same organization. You need to be aware of any information (screen shots etc) you are sharing in these public issues so that it does not become any security threat. You may want to start with a very small update to understand the process. I encouraged our team to start with some document updates. All the professional and soft skills like being respectful, clear communication, and constructive feedback are important while working in open source. 

If you are involved in development of open source projects, creating good unit and functional tests is important. We use the same standards for testing of open source projects (open liberty) as other commercial products. 

As enterprises have started to depend on open-source projects heavily, it is really important to focus on quality.  I would like to wrap up this post with this thought of making sure that we keep focus on serviceability (good error handling and clear log messages) and usability (easy to use), reliability and security aspects of open source projects.

Getting started with Open Source

If this article has helped inspire you to get started contributing to open source, why not consider contributing to Open Liberty. It’s easy to get started: https://openliberty.io/contribute/