Arts and Crafts of Designing a Container Platform — Part 4: Exhibit Your Artwork
Written by Hasibe Göçülü and Sergio Vicente Ruiz
As we outlined in Part 1: Sharpen the Pencil of this blog series, choosing the right container platform could be a challenging duty.
Following, in Part 2: Get Out Your Colors we introduced the main Kubernetes offerings provided by Cloud Service Providers (CSPs) and Software Vendors, which will setup the base for designing the right solution for the company needs.
In Part 3: Framing Your Painting we explained which are some of the available Kubernetes management tools and services and their coverage for the CSPs and Software Vendors offerings, that could help to manage the multiple Kubernetes-based environments deployed across public clouds and traditional data centers.
In this closing post for the blog series, we will share the typical set of questions that could help to understand better the company needs, to serve as the lighthouse to approach the design of the container platform once more concrete requirements are uncovered.
Designing the right container platform for a given company needs to be based on as set of principles, guidelines and requirements. Selecting the Kubernetes offerings and the management tools and services based on concrete specifications and non-functional requirements would help to produce a quality and enduring solution that satisfies the company’s wants and needs.
However, at the point of creating the draft design for the container platform, these principles and/or the concrete requirements might not be completely clear yet, and subsequent revisions might be needed to assess the validity and viability of the solution.
In any case, we can start the exercise by understanding how the following 5 relevant areas would influence the design:
Infrastructure architecture
- How does the company location’s topology look like? Is there a need to run containerized application in central premises, remote facilities and/or edge locations? Is it also needed to run containers in one or many Cloud Service Providers (CSPs) public infrastructure environments?
- What is the IT equipment, servers, storage and networking, available in the central, remote and edge locations? Are there any plans to run containerized applications that would need specialized HW elements, like GPUs or high-performance I/O devices?
- Are the connections from the central premises to the remote and edge locations reliable and redundant? Are there Internet connections in all the facilities?
Application architecture
- What type of applications are planned to be deployed in the container platform, Commercial-off-the-shelf (COTS) and/or self-developed? Would the company adopt a microservices architecture? Are there already any applications running in a container platform within the company environment?
- What special characteristics would the applications have? Would they require low latency interfaces with any other systems in the company premises? Would they connect to any other applications / services running in a CSP public infrastructure?
- What are the different data stores that could be required by the containerized applications? Would it be required to containerize any databases? Would data for containerized applications remain in external databases either in the company premises and/or in a CSP public infrastructure?
DevOps and automation
- How are the applications built, deployed and released in the company today? Has the company already adopted any CI/CD tool set? What is the company planning to do to build, deploy and release containerized applications? Is the company planning to adopt GitOps along with the container workloads and platform? What are the release test strategies that the company follow?
- Is there any automation framework implemented in the company? What is the company approach to observability for the containerized applications? Is the company planning to adopt a service mesh?
Operational and security models
- Does the company have enough skilled staff to manage the container workloads and platform? Would the development teams be end-to-end responsible to build / order and run their containerized applications and the container platform clusters? Would the operations team manage the container platform on behalf of developers? Would the company prefer to hand over the support of the container platform to an external service provider?
- What is the company approach to the security principles of Confidentiality, Integrity and Availability? Would there be any sensitive information and/or intellectual property within the container platform? Would the applications in scope of the container strategy have to comply with any specific regulation/s? What is the Business Continuity plan and how would the containerized applications be affected by such?
- How is IT Security and Compliance delivered today? Should it be delivered differently in the future container environment?
Commercial, partnerships and alliances
- Are there any commercial agreements, partnerships or alliances with any CSPs and/or Software Vendor that should influence the container platform selection? Are there any financial factors to be considered too?
These are all generic and overall questions that could help draft the base design of the container platform, that should be afterwards detailed and enriched further when the principles and requirements are better understood or more precisely defined.
Along this blog series, we have tried to illustrate why choosing the right container platform strategy for a given company could be a challenging and daunting duty. Understanding the details of every Kubernetes offering and management platform and been able to uncover the main guidelines in the early stages, are paramount to design the right solution for the company needs.
We hope we have provided useful and interesting information, and, please, leave us your comments and suggestions, it will be much appreciated.
Follow us on Twitter and LinkedIn for news and updates!
Disclaimer:
Every reasonable effort has been made to ensure that the information provided is reasonably comprehensive, accurate, clear and up to date at the time of writing this document.
However, the information provided on or via this document may not necessarily be completely comprehensive or accurate, and, for this reason, links to the official CSPs and Software Vendors documentation sites have been included.
