- component easily without affecting other components (loose coupling).
- Reuse (T3): Many projects had a similar feature set for software to work with the cloud. For this reason, a set of standard services to be used in multiple projects was identified.
- Continuous deployment (T4): A feature added to a service must be visible at once, so that the compatibility with other services can be tested automatically.
- Code quality (T5): The same code shall be used in different projects (T3). Thus, the demands on quality and genericity have increased.
From an organizational point of view, the following points had the strongest impact:
- Working mode (O1): Is the development in a cloud environment compatible with agile methods, or is another working mode needed?
- Team Setup (O2): Do the team members have the right skills? Are specialists within the team or specialized teams needed?
- Self-Service (O3): In cloud computing, an instance or repository must be available at once, so no additional tasks in the process are acceptable.
- Configuration Management (O4): For every solution in the cloud an infrastructure is set up which needs to be reproducible for quality and control.
- Cost controlling (O5): The scaling in cloud computing comes with new demands on cost controlling as instances are paid on an hourly basis and services like AWS Lambda [AC15] are payed according to usage.
The microservice architecture is defined as developing an application as a set of small independent services, where each of the services is running in its own independent process [NS14]. Services communicate with some lightweight mechanisms like HTTP [FL14] and are deployed independently [NS14]. The key reason to decide on an architecture based on microservices was the ability to replicate on demand across servers [FL14], which targets directly requirement T1.
Moreover, an architectural paradigm with microservices enforces the single responsibility of