The microservice-based architecture - a SOA-inspired principle of dividing backend systems into indepen-dently deployed components that communicate with each other using language-agnostic APIs - has gained increased popularity in industry. Realistic microservice-based applications contain hundreds of services deployed on a cloud. As cloud providers typically offer a variety of virtual machine (VM) types, each with its own hardware specification and cost, picking a proper cloud configuration for deploying all microservices in a way that satisfies performance targets while minimizing the deployment costs becomes challenging. Existing work focuses on identifying the best VM types for recurrent (mostly high-performance computing) jobs. Yet, identifying the best VM type for the myriad of all possible service combinations and further identifying the optimal subset of combinations that minimizes deployment cost is an intractable problem for applications with a large number of services. To address this problem, we propose an approach, called Kuber, which utilizes a set of strategies to efficiently sample the neces-sary subset of service combinations and VM types to explore. Comparing Kuber with baseline approaches shows that Kuber is able to find the best deployment with the lowest search cost.

Microservices have become a popular pattern for deploying scale-out application logic and are used at companies like Netflix, IBM, and Google. An advantage of using microservices is their loose coupling, which leads to agile and rapid evolution, and continuous re-deployment. However, developers are tasked with managing this evolution and largely do so manually by continuously collecting and evaluating low-level service behaviors. This is tedious, error-prone, and slow. We argue for an approach based on service evolution modeling in which we combine static and dynamic information to generate an accurate representation of the evolving microservice-based system. We discuss how our approach can help engineers manage service upgrades, architectural evolution, and changing deployment trade-offs.