At this week's CoreOS Fest in San Francisco, CoreOS is - unsurprisingly - pushing hard on the Application Container Spec (appc) and its first implementation, rkt, making it the topic of the first session after the keynote and a bold story about broad adoption.
When making technology decisions, Red Hat continuously evaluates all available options with the goal of selecting the best technologies that are supported by upstream communities. This is why Red Hat is engaging upstream in appc to actively contribute to the specification.
Red Hat engages in many upstream communities. However, this engagement should not imply full support, or that we consider appc or rkt ready for
enterprise IT, or that the specification will ever be considered “enterprise-ready.” With that said, here are some of my observations after listening to the panel discussion this morning:
There is a lot to like about rkt - the clean execution model around systemd, the open development and governance model, even the spec itself.
Let’s take a look at the spec.
The App Container spec is definitely a great step in the right direction. It addresses many of the shortcomings of Docker v1 on both the technology-level and the development model, as well as the decision-making process, which has been perceived as difficult by some users. The App Container spec displays a lot of what we would be looking for from a container spec and I honestly believe that there is a need for a spec of this nature in the enterprise container world. I also think that CoreOS has the best intentions with the spec and the community that they are building around it.
Except...
As it is today, appc only covers a very small part of what needs to be sorted out for a container-based, application-centric model. The impact of containerization in redefining the enterprise OS is still vastly underestimated by most; it is a departure from the traditional model of a single-instance, monolithic, UNIX user space in favor of a multi-instance, multi-version environment using containers and aggregate packaging. We are talking about nothing less than changing some of the core paradigms on which the software industry has been working for the last 20 - if not 40 - years.
There are still a lot of moving parts in terms of security, syscalls, signals, and more. The spec is an evolving target as even beyond its current scope, there is a need to go deeper in tracking compatibilities, dependencies on the underlying system, operating systems, federated registries namespaces, and discovery.
Another important scope issue is primarily induced by the name "Application" - at this point, the appc covers individual containers up to a pod. Unfortunately - and this is a problem as much for where Docker is right now - there are very few applications that consist of only a single container / single pod. This gap seems to be reflected in suggestions like the introduction of multi-node pods raised in today’s appc panel. There still is a higher-level concept missing for actual application portability. A first attempt at addressing this can be found in the current draft for the Nulecule [pronounce: newly-cool] spec: it expands the concept of portability to the full application - or a service as a component for further aggregation - and allows describing the multi-container application with all its dependencies.
So while the foundation to address a lot of this is laid in appc, we are really only at the beginning of a long journey in which Red Hat will continue to engage through our community involvement.
It’s important to note that an even bigger concern than the early stage of appc, is that rkt also introduces its own container package format in addition to supporting a compatibility interface to the docker model. I have long credited Docker for the brilliant idea to combine aggregate packaging, image layering, and containers. This gives us a tool to change the industry's approach to software delivery. The introduction of multiple different package formats to implement this concept introduces risks and slows momentum as the projects compete for mindshare. At the end of the day, it will mean fragmentation of the ecosystem, headaches for companies that provide actual content for containers, including Red Hat and our ISV partners, as well as those users trying to adopt containerization.
On the lower component level, we have had to live with this fragmentation for a long time when working with dpkg versus rpm versus a bunch of marginal others. In retrospect, looking at apt/dpkg versus yum/rpm the conclusion has to be that the competition between the two components has not significantly benefited users - quite the opposite. Essentially, it means that we have to provide the same content in multiple formats and either enable the whole toolchain and system architecture to manage two highly redundant formats in parallel or even worse, force customers to choose one ecosystem over the other. The higher level of aggregation with containers only marginally improves this issue because of the higher complexity and deeper integration in modern distributed systems.
The elephant in the room is that appc does not have the support of Docker, the company that leads in mindshare and controls the format that has quickly become the defacto standard for container packaging. They were not even represented at the panel to share their point of view.
At the same time, the spec is evolving, and rkt is gaining some level of interest. Docker is working on v2 of its package format, protocol and APIs, and the company has significantly improved its approach to community integration.
This is not to unduly criticise Docker or CoreOS, each has valid reasons to be on their respective paths. The reality is, we have two directly competing efforts to advance aspects of container standardization with competing toolchains, competing specs, and incompatible packaging formats. This is like watching a train-wreck in slow motion on Groundhog Day. We, in the broader Linux and open source community, have been down this path multiple times over the past fifteen years, specifically with package formats.
While there needs to be room for experimentation, having two incompatible specs driven by two startups trying to differentiate and in direct competition is *not* a good thing. It would be better for the community and for everyone who depends on our collective efforts if CoreOS and Docker collaborated on a standardized common spec, image format, and distribution protocol. To this end, we at Red Hat will continue to contribute to both initiatives with the goal of driving convergence.
저자 소개
Daniel Riek is responsible for driving the technology strategy and facilitating the adoption of Analytics, Machine Learning, and Artificial Intelligence across Red Hat. Focus areas are OpenShift / Kubernetes as a platform for AI, application of AI development and quality process, AI enhanced Operations, enablement for Intelligent Apps.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.