Amplifying Feedback Through Microservices and Containers
Amplifying feedback through Microservices and Containers
Abstract
As the customer needs rapidly evolve and the innovation accelerates, businesses must become increasingly agile. Time to market is key differentiator in the current digital age. Over the years software development lifecycles moved from waterfall to agile models of development. These improvements are moving downstream toward IT operations with the evolution of DevOps.
Organizations that have successfully laid a foundation for continuous innovation, agility and DevOps are embracing architectures such as microservices and technologies such as containers to respond rapidly to the never-ending demands of the business.
Firstly, we will start by understanding how microservices architecture helps in accelerating feedback loops. We will move on to analyse the key design principles of microservices. We will also look into the significant factors that will influence the acceleration of feedback amplification when using the microservices and how to make use of them.
Secondly, we will understand the role of containers in accelerating the feedback by doing a comparative study with a non-container/VM based approach vis-à-vis container based approach. We will bring in the best practices of container based approach to improve the feedback.
Introduction
As the customer needs are rapidly evolving, enterprises are looking for ways to bring out new products and features at a rapid pace without compromising on the quality. While this is a perfect situation for the business, IT organizations are under tremendous pressure to match the pace.
On the other hand, Organization across the globe are already embracing and making bigger strides in their DevOps journeys. DevOps operates on 3 key principles
- Systems Thinking: Emphasizes end to end thinking and an approach which benefits the system as a whole.
- Continuous Experimentation : Encourages IT Organizations to experiment using new practises, technologies, tools, and methodologies and learn from failures and successes
- Amplifying Feedback:Take the signal of an imminent failure and bringing up to larger audience at a faster pace, bigger scale and in a visual way.
New age technologies such as Microservices and Containers offers a perfect solution to move in the direction of feedback amplification. QA organizations/teams can collaborate with the partners from Dev and Ops teams to amplify the feedback using Microservices and Containers.
Microservices Introduction
Microservices is a variant or an extension to the traditional Service Oriented Architecture (SOA).
The microservices style involves developing small applications that can work together and running as individual process and communicating with lightweight mechanism such as HTTP.
Characteristics of Microservices are
- Minimum centralized management
- Data storage technologies
- Can be written in different programming languages
- Built around business capabilities/ functionalities
- Deployed independently
QA Impact of Microservices
QA strategy for Microservices should not only cater to the requirements of the Microservices, but also allow should maximize the benefits of Microservices strategy.
In this next two section, we will go through some of the microservices specific testing required for
- Functional testing
- Non Functional Testing
Functional Test Strategies
Following are some of the Functional test strategies that can be followed for various layer of testing
Unit Testing
Unit testing plays a key role in testing the behaviour of microservices and majority of the testing should be done in unit level/module level. This ensures that the micro service core functionality is tested and the code works at the lowest level.
Component Testing
Test the Microservice as a whole to ensure all the functionality of the Microservice is working as designed. The test involves manipulating the system through internal code interfaces and using test doubles to isolate the code under test from other components.
This is similar to the white box testing done in traditional methodology.
Contract Testing
Interaction among microservices happens through a contract that is agreed as per the design. The contract plays a key role in ensuring the system (Microservice) under test perform as design.
In this context, it is very important to ensure that the contract is tested. This is similar to the black box testing done in traditional methodology. Tests should be written to ensure that the Microservice contracts can be verified and accepted.
Contract Testing allows verify interactions at the boundary of an external service asserting that it meets the contract expected by a consuming service.
Integration Testing
Integration Testing in Microservices plays a key role in ensuring that Microservices operate together to perform the intended behavior
•Verification of communication paths, data flows and interactions among the microservices to detect defects at interface level
•Verification of the integration code the glues the internal and external component and ensuring that the integrated system behaves as expects
•Verification to ensure protocol level issues such as missing HTTP headers, incorrect SSL handling, or incorrect request/response combinations.
End to End Testing
•The goal is to test the behaviour of fully integrated system.
•E2E testing involved full-fledged testing by covering the overall application in test as opposed to only certain pieces.
•E2E testing also ensures that the infrastructure related items such as firewalls, proxies, load balancer are configured as per the need
Microservices – Non Functional Testing
Performance Testing:
Microservices Architecture provides an ability to scale at an individual Microservice level based on the business needs.
This requires individual services to be tested for various level of performance as opposed to the traditional way of testing at the system level.
Hence the performance requirements and testing methodologies need to be planned per service level and at system level. The performance testing need to be done to cater the requirements.
Session Management & Cache Testing
Compared the traditional systems which run in a single process, the session management for microservices are different. Based on the functionality the user browsers the control goes from one process to the other. This requires the sessions to be handled and tested to ensure the user session is maintained across the application.
Similarly, QA teams need to understand the caching requirements & technology consideration for caching and ensure that the cache is maintained across the application
Fail Over and Recovery
Traditional systems that run over a single process either be in FAIL state or an ACTIVE state.Microservices applications does not necessitate entire system to be down, when there are changes in one or more microservices. A separateapplicationstrategy need to be built, so that application can still work when one or more microservices are down.
A parallel QA methodology need to be developed to test these fail over and recovery mechanisms for microservices.
Containers Introduction
A container image is a lightweight, stand-alone, executable package of a piece of software that includes everything needed to run it: code, runtime, system tools, system libraries, settings.
Containerized software will always run the same, regardless of the environment. Containers isolate software from its surroundings.
For example: differences between development and staging environments and help reduce conflicts between teams running different software on the same infrastructure.
Source:
Individual containers can be deployed without worrying the configurations, environment, systems, libraries and Operating System versions.
Containers are:
- Light weight
- Secure
- Standard
Containers vs VMs
Following are some of the key difference between Virtual Machine and Containers
Virtual Machines:
•Virtual machines (VMs) are an abstraction of physical hardware turning one server into many servers.
•The hypervisor allows multiple VMs to run on a single machine.
•Each VM includes a full copy of an operating system, one or more apps, necessary binaries and libraries - taking up tens of GBs. VMs can also be slow to boot
Containers:
•Containers are an abstraction at the app layer that packages code and dependencies together.
•Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes in user space.
•Containers take up less space than VMs (container images are typically tens of MBs in size), and start almost instantly.
QA Impact of Containers
Given the above context, it is clear that containerization provides a number of benefits. While, there are direct benefits for Dev team and Ops, the benefits containers provide for QA is often low-key event. Following are some of the benefits that containers offer to the QA world.
Ease of creating QA environments:
Often tester feel that creation of QA environment is a challenge. They often depend on development team/Infrastructure teams to help them in configuring the QA environment. This put a bottle neck to the QA environments in terms of scaling the QA needs.
Containers offers the easiest way to create a test environments. Testers can create these environments in a self-service mode and test at will.
Run more tests and Test faster
Containers are lightweight in nature and can easily instantiated and terminated at will. This allows QA teams to create multiple environment and run parallel tests, which will improve overall QA agility.
Improved confidence in the production system
Container environment can be replicated with accuracy across the environments. This gives confidence to the testers that the system they are certifying is exact replica of the system that is going to production.
This minimizes the environment, configuration, system and infrastructure related surprises in the production.
•Lesser environment/configuration mismatch issues
•Improved confidence in the production system
Run testing in environment with slight variation
In the new age fast paced application development situations, there is a need to maintain multiple environments with slight variation depending on the need. Containerized QA environment creation helps QA team to bring the QA environment up with ease and test with confidence.
Ease of reproducing the issue
Often testing teams face a challenge where issues cannot reproduced in other environments such as development/staging environments. Containerization makes it much easy where the team does not share the logs, but share the container images to replicate the issue.
Given the lightweight nature of containers, it is much easy to replicate the non-reproducible issues as well.
Canary Release
Canary releaseis a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small subset of users before rolling it out to the entire infrastructure and making it available to everybody.
Canary releases are a way of sending out a new version of your app into production that plays the role of a “canary” to get an idea of how it will perform (integrate with other apps, CPU, memory, disk usage, etc.). It’s another release strategy that can mitigate the fact that regardless of the immense level of testing you do in lower environments you will still have some bugs in production. Canary releases let you test the waters before pulling the trigger on a full release.
Canary release fail fast to Amplify Feedback
When running multiple versions of an application, one needsa quickly way to create copies of the application and make configuration changes. This is possible with containers, as they can be spun up in seconds, and abstract away the application from the operating system. Container is ideal for powering canary releases and testing them with confidence.
Conclusion:
As IT Organizations are chasing agility, they are embracing the technology at a quicker pace than ever before. IT Organizations that already moved on to the agile journey are embracing the DevOps, Microservices and Container based approach at a quicker pace.
In the light of the rapid changes in the technology, there is a strong need for QA organization to move ahead and partner the Development and Operations teams in ensuring that QA is rightly positioned for the next transformation.
References & Appendix
Author Biography
Meghashyam Varanasi has about 15 years of experience in IT and ITes industry. He holds an MBA from IIM Ahmedabad & B.Tech Computer science degree. He is also AWS, PMP, ITIL certified besides few other technology and domain certifications. Over the years he has been working in solving various customer problems in the technology leadership space.
He can be reached @
THANK YOU!