클라우드(cloud)에서 개발자 작업하기 : 알아 두어야 할 모든 것

 

클라우드의 개발자 작업에는 무엇이 필요하며 조직은이를 어떻게 최대한 활용할 수 있습니까?

What does DevOps in the cloud entail and how do organisations to get the most out of it?

 

모두 개발 운영 및 클라우드 컴퓨팅 경쟁력을 유지하고 오늘날의 조직에서 디지털 변환을 착수에 필수적인 것으로 과대 선전되고있다. DevOps는 비즈니스 프로세스 및 응용 프로그램을 개선하는 데 필요한 것이지만 클라우드는 기본 서비스 및 기술에 관한 것입니다. 그렇다면 기업들은 어떻게 이들을 최대한 활용할 수 있습니까?

Both DevOps and cloud computing have been hyped as essential to maintaining competitiveness and undertaking digital transformation in today's organisation. While DevOps is about improving business processes and applications, cloud is all about the underlying services and technology. So how can businesses make the most of these?

 

클라우드 개발자 작업이 다른 개발자 작업과 다른 점

How cloud DevOps differs from other DevOps

우리가 이상에 관해서 DevOps에 관해 이야기 할 때, "코드로서의 모든 것"또는 "변경 불가능한 인프라"에 대해서는 오랜 시간이 걸리지 않습니다. 클라우드 기반 DevOps는 본질적으로 이러한 아이디어를 이끌어 내고 있다고 기술 컨설팅 6point6의 DevOps 팀장 인 Mark Debney는 설명합니다.

When we talk about DevOps in terms of ideals, it doesn't take long to mention "everything as code" or "immutable infrastructure"; cloud-based DevOps by its nature drives these ideas forward, according to Mark Debney, head of DevOps at tech consultancy 6point6.

클라우드 기반 환경에서는 최상위 네트워크 요소에서 서버에 설치된 단일 패키지까지 전체 스택을 볼 수 있습니다. 간단한 클릭으로 생성, 삭제, 복사 및 수정할 수 있습니다. "라고 그는 말합니다.

"It also allows us to expand our view wider than just the servers or load balancers. In a cloud based environment we can view our complete stack from top level network elements down to a single package installed on a server as a discrete entity, all of which we can create, destroy, copy and modify with a simple click," he says.

 

"클라우드 기반이 아닌 환경에서 팀이 작업하고있는 환경의 가장자리는 제한된 컴퓨팅 용량, 공유 인프라 또는 제한된 기술 선택으로 인해 쉽게 느껴집니다."

"In non-cloud based environments, the edges of the environment a team is working in is more easily felt, be that limited compute capacity, shared infrastructure or limited technology choice."

 

Debney는 클라우드가 DevOps에 더 큰 유연성을 부여한다고 덧붙입니다. 이는 기존 구성 요소를 신속하게 확장하고 새로운 프로젝트를 수행 할 수있는 형태를 취할 수 있으므로 새로운 구성 요소를 테스트하고 발표하는보다 상상력있는 방법을 열어줍니다.

Debney adds that cloud gives DevOps greater flexibility. This can take the form of being able to rapidly scale existing components and bring on new projects, which opens the door to more imaginative ways of testing and releasing new components.

 

또한 광범위한 클라우드 커뮤니티 내에서 도구와 아이디어를 활용할 수있게되었으며 비슷한 제한을 가진 공유 그룹에서 플랫폼을 최대한 활용할 수있게되었습니다. 더 이상 자체 고유의 인프라 기술을 사용하지 않습니다. quirks "라고 그는 말합니다.

"It also allows us to leverage tools and ideas within the wider cloud community. We can get the most out of the platform from a shared group with similar restrictions. We are no longer tied to our own internal set of infrastructure technology with its own unique quirks," he says.

 

 

혜택 받기

Reaping the benefits

 

우리가 클라우드로 이동할 때, 우리는 점점 더 복잡한 레이어를 추가합니다. 의 아름다움 공용 클라우드는 , 그러나, 그것은 소모품 API를 통해 모든 것을 제공합니다. Rubenk의 DevOps 엔지니어 인 Tim Hynes 씨는 API를 범용으로 사용할 수없는 전통적인 환경보다 DevOps 프로세스를 개발할 수있는 환경이 자연스럽게 프로그램 가능하고 더 적합하다고 말합니다. "이를 통해 우리는 애플리케이션을 구축하기위한 현대적이고 확장 가능한 접근 방식을 취할 수있게되었으며 기존 환경에서는 사용할 수 없었던 수준의 유연성과 기회를 제공하게되었습니다."

As we move to cloud, we add more and more layers of complexity. The beauty of public cloud, however, is it presents everything via consumable APIs. Tim Hynes, DevOps engineer at Rubrik, says that makes it a naturally programmable environment and a better fit for developing DevOps processes than traditional environments, where APIs are not universally available. "This enables us to take a modern, scalable approach to building applications and provides levels of flexibility and opportunity that are not available in traditional environments."

 

아미도 (Amido)의 수석 컨설턴트 인 리차드 슬레이터 (Richard Slater)는 DevOps의 가치는 높은 엔지니어링 생산성으로 인한 것이라고 말합니다.

"중기 결과를보기 위해 개발자 작업에 미리 투자해야하며이 작업을 향후 개발 속도 향상을위한 개발 도구, 프로세스 및 교육에 대한 초기 투자로 생각할 수 있습니다." 그는 말한다. "클라우드에서 DevOps를 채택하면 DataDog, Splunk, AppDynamics, New Relic, JIRA, Bamboo 및 CircleCI와 같은 SaaS 도구를 임대함으로써 DevOps Tools의 자본 지출을 줄일 수 있습니다."

Richard Slater, principal consultant at Amido, says the value of DevOps comes from higher engineering productivity – but there's the catch.

"You need to invest in DevOps upfront to see a medium-to-long-term result, and you can think of this as an initial lump sum investment in DevOps tools, processes and training for a percentage increase in velocity for the future," he says. "By adopting DevOps in the cloud, you can reduce the capital expenditure on DevOps Tools by simply renting SaaS tools from the market – for example DataDog, Splunk, AppDynamics, New Relic, JIRA, Bamboo and CircleCI."

 

 

성공하기

Making it a success

 

Agile 및 DevOps 변환이 실패하는 주된 이유 중 하나는 제품 개발 팀에 대한 신뢰 부족 때문이라고 Slater는 말합니다.

One of the primary reasons agile and DevOps transformations fail is the lack of trust placed in the product development teams, says Slater.

 

"민첩성, 클라우드 및 개발 운영을 채택하려는 조직은 의사 결정과 의사 결정을하는 사람들에게 신뢰를 제공해야합니다. 어느 정도까지는 이러한 신뢰가 얻어야합니다. 그러나 오늘날의 많은 기업에서는 기술에 대한 통제가 너무 많습니다. 배달에 어떤 변화든지에 브레이크를 꽝 닫는의 효력이있다. "

"Organisations wanting to adopt Agile, Cloud and DevOps must start to give trust to the individuals making decisions and writing code on the ground. To a certain extent this trust must be earned, but in many of today's enterprises there is so much governance around technical delivery that it has the effect of slamming the brakes on any transformation."

 

Slater에 따르면 DevOps 및 클라우드 채택을 조직의 다른 부서로 확대하는 경우 채택 목표를 최대 3 배로 늘릴 수 있습니다.

Slater says that when it comes to expanding DevOps and cloud adoption to other parts of the organisation, only increase your goal for adoption by a maximum factor of three.

 

"한 프로젝트로 시작한 다음 다른 프로젝트 3 개를 시도한 다음 9 개를 시도해보십시오. 가장 짧은 시간에 가장 많은 비즈니스 가치를 제공하는 프로젝트를 목표로합니다. 벨트 아래에 10 개의 프로젝트가있는 경우 보다 어려운 문제 - 이제는 제품, 공급 업체 계약, 공급 업체, 프로세스 및 사용자 뒤에서 중요한 수량을 보유하고있어 훨씬 쉽게 될 것입니다. "라고 그는 덧붙입니다.

"If you started with one project, next try another three projects, then nine and so on. Aim for the projects that deliver the most business value in the shortest time, once you have ten projects under your belt start looking at tackling some of the harder problems -–these will be a lot easier now you have a critical mass of products, vendor agreements, suppliers, processes and people behind you," he adds.

 

 

모범 사례
Best practices

 

Rackspace의 Iskandar Najmuddin¸ 전문가 건축가는 종단 간 추적 성과 Shift Left와 같은 두 가지 DevOps 모범 사례를 사용해야한다고 말합니다. 종단 간 추적 성은 비즈니스가 클라우드의 변경 사항이 발생한 곳을 추적하여 클라우드를보다 효과적으로 관리 할 수 ​​있음을 의미합니다. 누군가가 버그를보고하면 비즈니스는 해당 코드가 변경된 환경에서 어떤 버전의 코드가 작동 하는지를 이해할 수 있어야합니다.

Iskandar Najmuddin¸ specialist architect at Rackspace, says there are two DevOps best practices businesses should employ: End-to-end traceability and Shift Left. End-to-end traceability means a business is able to trace where any changes in the cloud came from, helping them manage their cloud better. If someone reports a bug, the business needs to be able to understand which versions of code are working in the environment that caused that change.

 

"변화의 파이프 라인을 구축 할 때 중요한 것은 비즈니스가 메타 데이터를 삽입하여 단계를 추적하는 것입니다."라고 그는 말합니다.

"No one tool can solve this – as you build a pipeline of changes, the key is to ensure that the business injects metadata into it to help trace the steps," he says.

시프트 레프트 (Shift Left)는 IBM 테스트 센터에서 나온 아이디어로, 생산 문제를 해결하는 데 많은 비용이 든다는 신념 때문에 비롯된 것이라고 Najmuddin은 말합니다.

Shift Left is an idea that came out of the IBM testing centre and stems from the belief that resolving issues in production is expensive, says Najmuddin.

 

"이러한 문제에는 버그, 다운 타임 및 취약성이 포함될 수 있으며 코드가 생산되면 수정하는 데 비용이 많이 듭니다 .Steft Left는 개발이 왼손에서 이루어지며 생산이 오른쪽에서 이루어 지도록하는 아이디어입니다. 기업이 코드를 계획, 설계, 작성 및 적용하는 방법과 환경에 변화를 초래하는 방법에 영향을 미칩니다. "

"These issues could include bugs, down time and vulnerabilities, and are expensive to fix once code is in production. Shift Left is the idea that development is done on the left hand, and production is on the right. Businesses must identify and fix the problems on the left before they transition toward the right. This affects how businesses plan, design, write and apply code, as well as [how they] introduce any changes into the environment."

 

Tenable의 엔지니어링 및 컨테이너 보안 이사 인 Sasan Padidar는 클라우드에서 DevOps에 대한 모범 사례 중 하나는 독립적으로 작동 할 수있는 부분을 분리하여 응용 프로그램을 작게 유지하는 것입니다. "응용 프로그램의 독립 구성 요소를 개별적으로 확장 할 수 있기 때문에 이는 중요합니다. 전체 응용 프로그램의 복잡성이 줄어들 기 때문에 응용 프로그램 조각을 더 빠르게 배포 할 수 있습니다."라고 Padidar는 말합니다.

Sasan Padidar, director of engineering and container security at Tenable, says one of the best practices for DevOps in the cloud is to keep applications small by decoupling pieces that can function independently. "This is important because independent components of the application can be scaled separately. It also means that pieces of an application can be deployed faster because of the reduced complexity of the overall application," says Padidar.

 

또한 빌드 프로세스 중에 각 응용 프로그램의 모든 종속성을 응용 프로그램과 함께 패키지화하는 것이 가장 좋습니다. 즉, 응용 프로그램을 어디서나 배포 할 수있는 불변 단위로 사용할 수 있습니다. "

"It's also best practice to ensure all dependencies of each application are packaged with the application during the build process. This means that applications are immutable units that can be deployed anywhere."

 

 

더 많은 컨테이너 및 오케스트레이션

More containers and orchestration

Najmuddin은 향후 12 개월에서 18 개월 이내에 컨테이너 오케스트레이션 조경의 통합뿐만 아니라 컨테이너의 더 많은 채택이있을 것이라고 말했습니다. 현재 사용되는 세 가지 주요 시스템이 있지만 사용하기 쉽거나 표준화 될 것입니다.

Najmuddin says that in the next 12 to 18 months, there will be more adoption of containers, as well as a consolidation of the container orchestration landscape. There are three main systems used at the moment, but they will become easier to use or standardised.

 

"DevOps가 조직에서 뚜렷한 직업이나 역할을한다는 생각은 끝나기 시작할 것입니다 .DivOps 전문가는 동일한 작업을 수행하지만 DevOps의 개념이 다른 역할에 통합되므로 동일한 제목이 아닐 수도 있습니다. 이러한 클라우드 환경을 관리하는 기본 방법이 될 것이고이를 반영하여 직책이 진화 할 것입니다. "라고 그는 말합니다.

"The idea that DevOps is a distinct job or role in an organisation will also start to tail off. DevOps specialists will do the same job, but may not have the same title, as the concept of DevOps will be integrated into other roles. DevOps will become the default way to manage these cloud environments, and the job titles will evolve to reflect this," he says.