Red Hat 계정으로 회원 프로필, 기본 설정 및 고객 상태에 따라 다음의 서비스에 액세스할 수 있습니다.
아직 등록하지 않으셨습니까? 등록해야 하는 이유:
- 한 곳에서 기술 자료 문서를 탐색하고, 지원 사례와 서브스크립션을 관리하고, 업데이트를 다운로드 할 수 있습니다.
- 조직 내의 사용자를 보고, 계정 정보, 기본 설정 및 권한을 편집할 수 있습니다.
- Red Hat 자격증을 관리하고 시험 내역을 조회하며 자격증 관련 로고 및 문서를 다운로드할 수 있습니다.
Red Hat 계정으로 회원 프로필, 기본 설정 및 자신의 고객 상태에 따른 기타 서비스에 액세스할 수 있습니다.
보안을 위해, 공용 컴퓨터 사용 중에 Red Hat 서비스 이용이 끝난 경우 로그아웃하는 것을 잊지 마십시오.로그아웃
What are the typical challenges that organizations need to address as part of this evolution [to IT that at least includes a strong cloud-native component]?
In their response, Mary and Gary note the challenges associated with “having to integrate with conventional systems can slow down the entire process and work against the agile, continuous integration/continuous delivery methodologies these DevOps teams often employ.” At the same time, this integration can’t be dispensed with; they add that “IDC expects cloud-native and conventional applications to become more connected and interdependent over time.” (Check out the recent webinar discussing this and other topics: Next-generation IT strategies: Mixing conventional and cloud-native infrastructure--based on a recent IDC survey.)
So, where does that leave us? Is traditional IT destined to just be a boat anchor when it’s integrated with cloud-native IT? (And make no mistake, integration is an inevitability.)
Variations of this question also come up as part of critiques to the bimodal or two-speed IT idea.
Bimodal refers to having one group of IT assets and operational approaches that are focused primarily on reliability and stability while another group of assets prioritize innovation and speed. The main point of the bimodal argument is that trying to split the difference between stability and speed will result in IT that is neither stable enough nor nimble enough for the needs of the business. “Avoid the timid middle” is the catchphrase sometimes associated with this point.
A critique I sometimes hear is that the bimodal model therefore serves as a license for CIOs unable or unwilling to transform their entire infrastructure and application portfolio by telling them that it’s OK to ignore the legacy stuff. The problem, one of them anyway, is that said legacy IT will drag down any new initiatives for both organizational and technical reasons. No one wants to work on legacy. And integrations will be tough.
I’d argue that this argument misstates an important element of bimodal IT but also highlights some of the key challenges that have to be overcome in order to evolve IT for a more digital age.
The misstatement lies in the word “legacy” which carries something of a derogatory flavor. In fact, in the bimodal model, traditional IT is neither something to be ignored nor wholesale replaced. Rather it’s IT to be modernized when and where appropriate. This may include infrastructure updates using modern x86 servers, Red Hat Enterprise Linux, and JBoss Enterprise Application Platform. It may include introducing agile and DevOps approaches for targeted application projects. It may include exposing existing data sources and workflows using contemporary business rules management and messaging systems.
As such work progresses, the traditional IT systems will be better able to integrate with new applications and cloud-native infrastructure as well as operating more efficiently.
With respect to challenges, the first is that traditional IT must, in fact, modernize over time. This will often involve picking the right (or at least right enough) focused projects that create wins but which aren’t so large and expensive that they cut off the resources needed for new innovation-focused initiatives.
The second challenge is managing the cultural and organizational aspects of having differing priorities (stability and speed) for traditional and cloud-native environments. One way in which projects needing to move fast and do things in new ways have been dealt with in a range of industries is through creating “skunkworks” groups. When it works, it’s effective. (Kelly Johnson’s team at Lockheed is a famous historical example from the aerospace industry.) At the same time, however, gaining the full advantages of faster and more iterative development practices, for example, ultimately requires evolving those values and that culture beyond a small group--and, indeed, beyond the IT organization into the lines of business.
Finally, a third challenge is to integrate different modes of IT in a way that the needed data and events can flow where they are needed without creating tight interdependencies. In many respects, such an approach reflects modern distributed application design more broadly. Encapsulating services and exposing data and functions through APIs allow implementation changes to take place autonomously. Picking the right functional boundaries for such services is often not obvious. However, such a design allows different parts of the IT infrastructure to evolve at different paces and using different technology sets.
Read part 1 of the series: Does cloud-native have to mean all in?