피드 구독

Editor’s note - This post is the third in a four-part series on private cloud from Red Hat technology evangelist Gordon Haff. Read the earlier posts:

A private cloud is a part of a hybrid cloud

OpenStack: private cloud Infrastructure-as-a-Service (IaaS)

 

Early DevOps discussions often focused on breaking down the wall between developers and operations. The thinking went that, if developers didn’t just toss their new applications over to operations and run away, the world of IT would be a better place. That was how operations viewed the state of affairs in any case.

Don’t talk when you don’t have to

There’s certainly truth in that stereotype of standard practice. We can probably all agree that open communication lines and mutual understanding are good things. But eliminating unnecessary communications can be a good practice too. It’s possible to put infrastructure, processes, and tools in place so that Devs doesn’t need to interact with Ops as much while being (even more) effective. One of the analogies I like to use is that I don’t want to streamline my interactions with a bank teller. For routine and even not so routine transactions, I just want to use an ATM or my smartphone.

It’s up to Ops to build and operate the infrastructure supporting those streamlined transactions, such as a private Infrastructure-as-a-Service (IaaS) cloud. And then provide core services through a modern container platform. In Red Hat’s case this takes the form of Red Hat OpenShift Container Platform running on top of Red Hat OpenStack Platform. Or as an integrated offering in the form of Red Hat Cloud Suite which combines a container-based app-development platform (OpenShift), private cloud infrastructure (OpenStack), and interoperability/management (Red Hat CloudForms).

Why a modern platform?

Optimizing development processes and cloud-native applications is often best done on a modern platform.

You may need scale-out architectures to meet highly elastic service requirements. Application designs with significant scale-up components simply aren’t able to accommodate shifting capacity needs. Or may simply not be able to scale up as far as they need to go.

Modern platforms are software-defined because software functions, such as network function virtualization and software-defined storage, are much more flexible than when the same functions are embedded in hardware.

Modern applications are composed of loosely-coupled services because large monolithic applications can be fragile and can’t be updated quickly. A modern container platform enables iterative software development and deployment in part because modern applications are often short-lived and require frequent refreshes and replacements.

[Related read: DevOps Culture and Practice with OpenShift]

Enter containers

Containers started out as another way to partition a system, a lightweight alternative to hardware virtualization. But transforming containers into a way to package applications is what made them broadly interesting. By providing an image that also contains an application’s dependencies, a container can be made into a packaging construct that is portable and consistent as it moves from development, to testing, and finally to production.

Some other pieces came together as well. Specifications that are now under the governance of the Open Container Initiative (OCI) standardized the image and runtime for containers. These specifications work together to define the contents of a container image and those dependencies, environments, arguments, and so forth necessary for the image to be run properly. As a result of these standardization efforts, the OCI has opened the door for many other tooling efforts that can now depend on stable runtime and Image specs. For example, Red Hat has been involved heavily in container registry and container building projects such as Project Atomic, Skopeo, and Buildah.

An OCI-compliant container runtime, by itself, is very good at managing single containers. However, when you start using more and more containers and containerized apps, broken down into hundreds of pieces, management and orchestration can get tricky. Eventually, you need to take a step back and group containers to deliver services.

Orchestrating and managing

That’s where Kubernetes comes in. Originally developed by Google but now a large community project under the auspices of the Cloud Native Computing Foundation (CNCF), Kubernetes lets you cluster together groups of hosts running Linux containers, and orchestrate (manage) them.

Kubernetes relies on additional projects to provide the services developers and operators might choose to deploy and run cloud-native applications in production. These include a container registry, telemetry, networking, and security. A significant amount of open source innovation is coming together around containers. I’ve only touched on a small piece of it.

Integrating and packaging

OpenShift natively integrates technologies such as OCI-compliant containers and Kubernetes and combines them with an enterprise foundation in Red Hat Enterprise Linux. OpenShift also integrates the architecture, processes, platforms, and services needed by development and operations teams. It’s fully open source with OpenShift Origin as its upstream community project. Users, contributors, and partners come together in OpenShift Commons.

If you consider the level of activity happening in the cloud-native space, the challenges of DIY integration can be pretty clear. (This applies to Infrastructure-as-a-Service as well as container platforms.) There’s a rapid pace of change within projects, new projects are popping up all the time, and different approaches go in and out of favor as developers and users gain experience with different types of tasks and use cases.

In its December 2016 report commissioned by Red Hat, “OpenStack Platform Delivers for Private Cloud Users, Organizations show preference for trusted third parties,” 451 Research wrote: “[our] Voice of the Enterprise research survey shows that nearly 63% of users choose a vendor’s distribution of OpenStack or simply sign on with a service provider, which also may well use a popular distribution. Just 21% of organizations choose a do-it-yourself course.”

The goal for integrated platforms like OpenShift, OpenStack, and Cloud Suite is to simplify the startup process, reduce the level of skills required, and generally help organizations focus on their own application delivery needs rather than on the underlying platform.


저자 소개

Gordon Haff is a technology evangelist and has been at Red Hat for more than 10 years. Prior to Red Hat, as an IT industry analyst, Gordon wrote hundreds of research notes, was frequently quoted in publications such as The New York Times on a wide range of IT topics, and advised clients on product and marketing strategies.

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

채널별 검색

automation icon

오토메이션

기술, 팀, 인프라를 위한 IT 자동화 최신 동향

AI icon

인공지능

고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트

open hybrid cloud icon

오픈 하이브리드 클라우드

하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요

security icon

보안

환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보

edge icon

엣지 컴퓨팅

엣지에서의 운영을 단순화하는 플랫폼 업데이트

Infrastructure icon

인프라

세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보

application development icon

애플리케이션

복잡한 애플리케이션에 대한 솔루션 더 보기

Original series icon

오리지널 쇼

엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리