consider a number of factors, including business critical- ity and technical complexity and difficulty. Overall, workloads need to be assessed and prioritized based on business requirements and financial return on invest- ment considerations. Business services will then need to be defined based on the required application functionality. Decomposing an application into a set of microservices follows no set rules. In general, however, examining the specific ser- vices and how they interact “outward” (to customers and other stakeholders), and “inward” (with internal and back office services), and dividing functionality will be based on the most efficient way to orchestrate these interac- tions. Interacting with back end systems is particularly important, since in some cases, containerization may not be a viable option. There are a variety of container platforms available in the marketplace – some are open source. In addition, some container platforms are offered by vendors who add value in terms of ease of use and scalability. The careful exam- ination of current and future needs will play into deter- mining the right platform to use. Finally, the role of operations will change where cloud- enabled applications prevail. We’ve seen that cloud ena- blement can add complexity and pose management chal- lenges, but also create great opportunity to exploit the cloud. Kubernetes as a management and orchestration system for cloud native applications built with containers is a way to effectively get the most out of a distributed, modularized application implementation. 41
Building Cloud Native Apps Painlessly Page 45 Page 47