This post is a part of my degree project “How can we adjust to Working Agile with Cloud-based Microservices in CI/CD” written during the last course of a software test engineer education. All information from the thesis is not included and some text is changed. The original document is available as a pdf Link to pdf here
Background
The methodology of waterfall is done in a linear sequential lifecycle model where all development activities are divided into separate phases. One phase needs to be reviewed and verified before moving to the next phase, which means that testing carries out only after development completion. In this test engineers are not involved from start in the development process. Testing cannot be done in parallel; each level of testing is done after each other. It also includes pre-determined requirements that needs to be followed and no changes can be made along the process. Long lead times, bottlenecks causing delays, heavy workload of documents to follow, no insight in other phases causing frustrations in the business. Alongside with this the monolithic architecture was used. Monolithic means a system is built as one indivisible unit. Usually built with one large codebase, where an update means that we need to modify the entire software and minor changes affects the entire application.
With the technology changing and evolving, demands on flexibility, scalability and better performance made many to migrate from monolithic/SOA to microservices. These demands also included the organizational structure, which have resulting in organizations changing architecture from waterfall to agile or a hybrid model between the two. The architecture changes meant a major change in how people were used to work.
With teams now working independently, systems including a large number of services and containers, the continuous integration and deployment could be made in parallels. Teams working on individual modules, deploying more frequent, testing can be done alongside the development process. It has solved many of the earlier frustrations and disadvantages seen in waterfall and monolithic. But there are also areas causing various problems with testing these systems. Testing monoliths we can use traditional testing approaches, microservices are too complex to do the same. We have independent teams to coordinate, components outside of the service, like databases, communication between each service and testing-levels. Microservices have a complex architecture and testing them are an architecture of its own.
Today many have migrated their systems to the cloud, made the application container based, using a variety of tools and resources like PaaS, IaaS, SaaS. We have test automation integrated in the system, different application platforms, frameworks, and languages.
All changes in organization and systems also means that we need to find new approached for testing, make sure to keep a high test-coverage and be able to trace issues inside the system.
Theoretical background
What is cloud-based environment?
Simple explained cloud computing or cloud-based means that we use hosting for our systems and applications instead of storing them on a hard drive or an on-site server. So, cloud in this context means the internet, we store off-site. There are several types of cloud computing, where different services are being provided. We have the three main types: IaaS, SaaS, PaaS, and there is also FaaS and serverless. The definitions of which services that are included in what type and what is an overlap between them, can just as the word cloud-based be a bit abstract. This because people use the words differently and it includes several different systems and services.
IaaS, Infrastructure as a Service
With IaaS we have a service that will manage our infrastructure. This includes servers, storage, networking firewalls and virtualization. All the fundamentals are provided by a pay as you go basis. This gives a flexibility to scale resources as needed and increase the reliability of the infrastructure. We are still responsible for any data, applications, and operating system.
PaaS, Platform as a Service
With PaaS we still let the provider host the services included in IaaS, all the infrastructure. This model also includes everything we need to build our application, middleware, development tools, operating system, runtime, code libraries and more. Without the need to think about back-end features such as: maintenance and updates, we now can focus on hosting, build, and test.
SaaS, Software as a Service
This is the most known service; it is a user-ready software applications for specific functions. The service, updates and maintenance are managed by the provider. The user connects with the service over the internet and there is no need for installation on the user’s machine. Example of well-known SaaS: Gmail, Slack, Dropbox.
Serverless and FaaS, Function as a Service
Serverless and FaaS are other concepts used, they are many times said to be the same thing but there are some differences. With serverless the provider manages the configuration of the server, serverless databases, pipelines etc. basically all infrastructure. FaaS provides even more abstraction, it focuses on the services themselves and manages the server setup and installation of the application.
Then we also have different deployment models, Cloud, Hybrid and On-premises. I won´t go into any details about it here but worth to mention that it exists.
What is microservices?
Most applications used to be built with a monolithic architecture, a single application where everything is linked. Usually it has one codebase, including server-side, client-side, and database. All these components depend upon each other, this means that any change in in the code might affect the whole application. Since it only has one codebase the application might grow too big and make the development time-consuming and exceedingly difficult to scale.
The problems faced with monolithic applications combined with more applications deployed to the cloud led to the interest of microservice architecture.
History
There are some different claims of the origin of the term microservices, one is refereeing to Peter Rodgers presentation at the Web Service Edge Conference 2005, where he mentioned “software components are micro-web-services” (CloudComputingExpo, 2015),
Greg Young made a presentation where he explains the core ideas that has led to the microservices architectures as of today. He states that this goes back to the 1970s, and that SOA already had the aspects of microservices. (Young, 2016).
But for focus of microservices as we know them today in 2014 James Lewis and Martin Fowler decided to publish a detailed definition of microservices. This is a part of the definition they wrote:
“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.” (Lewis, Fowler, 2014).
If we break this definition down in keywords we get:
- Small services, running in its own process
- Communicating, often an HTTP resource API
- Build around business capabilities
- Independently deployable
- Can be written in different languages
- Can use different data storage technologies
The advantage of this architectural approach is eliminating some of the problems the monolithic architecture is facing.
Since the service runs their own process independently, we get the possibility to develop and run them differently. Each team can decide their own approach, select their own code language, make code changes, build new features without too much concern about other services. Deployment is made isolated and automation tests can be set up to run with every deployment. With this independency all changes and behavior is connected to that specific service, in case of failure the rest of the application can still be up running.
Containerization
Simple explained containers are an encapsulated package of a software and its dependencies.
To explain the difference between a microservice and a container Ev Kontsevoy wrote this: “A container is something DevOps people get excited about. A microservice is a software design pattern. It’s something developers get excited about.” (Kontsevoy, 2021)
While microservices is created as single units they are mostly sharing dependencies like libraries, system tools and might need other services to run. Then we can use a container to store all we need to run the software. A container is portable and includes the application and all dependencies and can be deployed to a host operating system, which it shares with other containers. The data packed together inside of a container is called a container image and the instance of the image is the container.
CaaS, Container as a Service
Is a cloud-service for container-based software, it helps to automate the deploy and run process of the application in a more scalable and secure environment. It uses container virtualization, APIs, or web portal to connect with the application or containers and is many times compared as a subset of IaaS. CaaS does not have dependencies at the application level, which reduces the bottlenecks and resources and makes it have portability. One of the most well-known CaaS is Docker. From a testing perspective CaaS gives the service of providing logs, monitoring and performance checks to easier analyze the application data.
K8, Kubernetes
When using CaaS and the most common one is a s mentioned Docker, it might be that the application is installed on different operation systems. CaaS is mostly made to run a single node per host, to be able to manage all these different nodes we can use Kubernetes. Or as it is called a Kubernetes cluster, this container orchestration platform helps to simplify and automate the management of containers.
Links to previous posts in this series can be found here:
Link to part 2
Link to part 3
Link to part 4
Link to part 5