소프트웨어 아키텍쳐에서 Antifragile이라는 키워드는 서비스의 단순한 장애나 변화에 대해 회복하는 것을 넘어, 스트레스와 변화를 통해 시스템이 개선되고 발전하는 아키텍처를 의미한다.
Antifragile은 다음과 같은 네가지의 특성을 가진다.

위의 그림과 같이 Auto scaling 시스템을 구성하고 있는 인스턴스를 하나의 Auto Scaling group으로 묶은 다음 그룹에서 유지 되어야 하는 최소 인스턴스를 지정할 수 있다.
또한 CPU, Network, DB 사용량에 따라 인스턴스가 자동으로 증가하거나 감소하는 환경을 의미한다.

위 사진은 Netflix의 구성도인데 이처럼 복잡하게 연결되어 있는 서비스 구성을 MicroService라고 한다.
파란색은 서비스간의 연동을 의미하고 초록색은 마이크로서비스를 나타낸다.
클라우드 네이티브 아키텍쳐, 클라우드 네이티브 어플리케이션에 핵심이라고 볼 수 있다.
운영중인 소프트웨어에 실행중인 방법이나 규칙의 일환이다. 시스템의 갑작스러운 변동, 예견되거나 예견되지 못한 불확실성에 대해 안정적인 서비스를 제공할 수 있도록 구축 되어야 한다는것을 의미한다.

지속적인 통합, 배포를 의미하며 도메인이 분리된 MicroService를 수작업으로 배포할 수 없기 때문에 자동화된 시스템을 구축한다.
시스템은 필요에 따라서 확장 가능한 형태의 아키텍쳐로 발전 되었다. 특히 시스템의 수평적 확장으로 인해 더 많은 사용자의 요청을 처리할 수 있게 되었고, 이렇게 확장된 시스템으로 인해 시스템 부하를 분산시킴과 동시에 가용성을 보장할 수 있게 되었다.
일반적으로 시스템을 Scale-out 하기 위해서는 하드웨어 비용이 증가하겠지만 클라우드 네이티브 아키텍쳐에서는 클라우드 서비스를 제공하는 업체로부터 가상의 서버, 가상의 스토리지, 가상의 네트워크 등을 빌려서 사용함으로써 이러한 비용을 최소화 시켰고, 양적으로 증가되었던 시스템을 더 이상 사용하지 않을 경우에는 다시 빌렸던 리소스를 반납해서 비용을 낮출 수 있게 되었다.
따라서 클라우드 네이티브에서는 가상 서버의 기술이 핵심적으로 필요하게 되었다. 기존의 서버 가상화 방식과 더불어서 컨테이너 방식의 가상화를 같이 사용하게 되었다.
또한 클라우드 네이티브에 구축된 가상 서버와 리소스들은 다양한 모니터링 도구를 이용해서 현재 사용되고 있는 시스템의 상황 및 리소스의 사용량 등을 확인할 수도 있다.
두 번째로 클라우드 네이티브 아키텍쳐는 탄력적인 아키텍처를 갖고 있다. 어플리케이션을 구성하는 각 기능을 하나의 분리된 서비스로 개발을 하고 이렇게 분리되어 개발된 서비스들을 통합하고 배포하기까지 걸리는 시간을 CI/CD라는 자동화 파이프라인을 통해서 처리함으로써 변경이 시스템 환경에 적용되는 시간을 단축 할수 있게 되었다.
엔터프라이즈 어플리케이션으로 갈수록 개발인력의 증가 뿐만 아니라 수많은 개발 환경, 테스트 환경, 심지어는 실제 운영 환경, 또는 예비서버를 고려해서 준비해야 한다. 예비 서버는 적게는 3~4개, 많게는 수십개에서 수백개일 수 있다. 이렇게 무수히 많은 예시 서버에 같은 내용의 서비스를 배포하는 과정이 자동화 되어 있지 않다면, 수많은 인력이 낭비된다.
마이크로서비스는 작게 분리된 독립적인 서비스 이다. 전제 어플리케이션을 구성하고 있는 도메인 특성에 따라 각 서비스간의 경계를 잘 구분하고 거기에 맞게 서비스를 개발해야 한다. 서로 분리된 서비스 간에 원활한 통신을 위해 각각의 서비스들이 서로에게 가지는 종속성을 최소화 시켜야 한다. 또 상태를 갖지 않는 서비스를 제공할려고 노력해야 한다.
전체 어플리케이션을 구축하는 마이크로서비스들은 배포될 때 자신들의 위치가 어디에 있는지 등록을 해야 된다. 그래야 다른 서비스들이나 외부에 연결되어 있는 타 시스템에서도 해당 서비스를 검색하고 사용할 수 있게 된다. 이렇게 마이크로 서비스들의 존재는 Discovery Service라는 곳에 등록되고, 삭제되는 작업을 하게 된다.
마지막으로 클라우드 네이티브 아키텍쳐는 장애복구에 뛰어나다는 특징을 가지고 있으며 여러 개로 분리되어 개발되고 있는 마이크로 서비스들은 하나의 독립적인 작은 단위의 어플리케이션과 같다.
따라서 하나의 마이크로 서비스에 생기는 문제점이나 오류사항은 다른 쪽 서비스로의 영향을 최소화 해야 한다.
어떤 마이크로서비의 특정 부분을 수정한다 하더라도 전체 서비스를 다시 배포해야 되는 것이 아니라 해당 서비스만 다시 배포할 수 있기 때문에 다른 시스템에 영향을 주지 않을 수 있다.