Hotjar는 완전히 외진 곳이기 때문에 의사소통이 가장 큰 난제 중 하나였습니다. 회사가 성장할수록 커뮤니케이션의 중요성은 더욱 커지고 있었습니다.

Hotjar는 점점 더 많은 개발자들이 어떻게 그들의 일을 구조화하고 번거로운 레거시 시스템 사용에 대해 어려움을 겪었습니다. 모든 개발자들은 레거시 도구를 사용하여 동일한 코드 베이스에서 작업해야 했고, 이로인해 생산성이 저하되고 있었습니다. SRE 팀 리더는 '우리가 해결하려고 했던 문제는 어떻게 하면 인프라 레거시 조각이 몇 개 있지만 새로운 마이크로 서비스 구축과 생산성이 저하되지 않고 내부적으로 개발자 수를 계속 늘릴 수 있도록 어떻게 하면 좋은 방식으로 모든 새로운 것들을 통합할 수 있는가 하는 것이었습니다.'라고 말합니다.

개발자들은 소스 코드 호스팅에 Bitbucket을, CI/CD에는 젠킨스를 사용하고 있었습니다. 일부 레거시 애플리케이션의 제약 때문에, 그들은 파이프라인을 지원하기 위해 다량의 Jenkins 고유의 코드를 개발하고 유지해야 했습니다. 이것은 많은 자원을 소모했고 그들의 시간을 효과적으로 사용하지 못했습니다. 그들은 쿠버네티스를 그들의 모든 마이크로 서비스와 몇몇 빌드 파이프라인을 위한 플랫폼으로 이용하고 있었습니다.

Hotjar는 쿠버네티스 통합과 젠킨스 CI/CD의 대체품을 제공하는 도구를 찾고 있었습니다. 그들은 CI/CD와 Concourse에 BitBucket을 사용해 보았지만, 둘 다 필요한 해결책을 제공하지 못했습니다. SRE 리더는 '전체 라이프사이클을 공급하는 쿠버네티스 네이티브 제품의 경우 사실 그렇게 많은 경쟁자를 찾지 못했습니다. Jenkins X는 쿠버네티스 네이티브지만 실제로는 매우 미성숙하고 여전히 많은 버그 가지고 있다는 것을 발견했다'고 말했습니다.