Super!! Thanks by the content

Excellent video. Thank you

Waiting for the next video 😊

This is an interesting one. For an hexagonal arch I would assume quite a few business cases defined in my domain usecases/services and quite some aggregate invariants defined as well. Those will likely (hopefully) rely on repository abstractions that are reused and combined for each usecase. That's already a lot stuff to unit test. And we haven't talked about message versioning and anti corruption layer implementation. So a multiple of the system parts. The integration tests (e.g. lambda -> dynamo, lambda -> s3, talking adapters ofc) have the happy and failure paths from the adapters integration. I think there is a point where you will either end up with more unit tests than int tests (rather quick) or test business cases in integration tests. And in prefer the fast local feedback. In the simple example cases it's often the other way around, but that's not reality.

Nice overview of important concepts in just 4 minutes!😮 Thanks for your great content! 👍 at some point I'll definitely take your course🙏

Thanks for your great explanation. I would also recommend the red book by Vaughn Vernon it goes thorugh all concepts with great examples.

Thank you. I'm wondering, how useful and practical is DDD for existing systems? When should it be used and when not? Because it seems to me that DDD should be done early on in the project.

How do you handle deployment to all of the lambda regions? Is it possible to also check and make sure you are running the correct lambda code?

Really interesting discussion! Thanks guys. I think i have to go through a few examples myself to understand the flow and syntax fully.

Great points. Wisdom from a guru.

This was InCognito for me until now, thanks for the explanation

Great content. Thanks. May I ask, did you ever publish the next promised-video about Anti Corruption Layer? Because I cant find it. If so, can you please share the link.

I missed the part on how he could improve api gateway costs, Could you please gimme some link or a brief explain?

Excellent advice from Yan as always!

The tech industry seems to disagree with me that if it's functionally the same, it's the same. Yes, there are architectural and conceptual differences, perhaps you could argue they function differently simply because of where the consumer is placed in the design, but I can either have a global function callable in an event, perform the function directly in the event handler, or call a command from an event handler. If we aren't talking about command line programs, commands will be invoked by an event on the user interface. & if it is a decent design the user interface will need to react. There is no ultimate difference in function whether it's a command, event handler method call, or inline procedure in the event handler. Although from my experience in WPF, commands make it much harder for the control to properly react.

All these KZbinrs “testing in production” are rather shallow. Nobody talks about how to test the code changes involving data schema changes.

This is a very nice video. Seems like identity pool are similar to OAuth mechanism

Great details with diagram and pros, cons. Thank you. Also follows WAR Framework

for Korean -- 지난 비디오에서 저는 AWS Step Functions이 무엇인지와 어떻게 작동하는지 설명했습니다. 비디오는 Step Functions을 사용하는 이유에 대한 의문으로 끝났습니다. 왜냐하면 Lambda 함수 내에서 모든 오케스트레이션을 쉽게 처리할 수 있기 때문입니다. 이번 비디오에서는 워크플로우를 구현하는 두 가지 옵션을 비교해 보겠습니다. 개인적으로는 단순한 워크플로우나 비용 최적화가 필요한 경우 Lambda를 사용하는 것을 선호하지만, 복잡하거나 비즈니스에 중요한 워크플로우에서는 Step Functions을 사용하는 것을 선호합니다. 이 비디오의 나머지 부분에서 제 생각을 설명하겠지만, Lambda destinations을 사용하여 여러 Lambda 함수를 함께 변경하는 것이 매우 제한된 경우에 유용하다는 점도 언급하고 싶습니다. 자세한 내용은 나중에 다루겠습니다. Lambda의 장점은 분명하고 간단합니다. Step Functions과 비교했을 때 Lambda는 더 단순합니다. 오류 처리, 분기 로직 등 Step Functions에서 할 수 있는 모든 것을 몇 줄의 코드로 Lambda에서 구현할 수 있습니다. 이미 익숙한 프로그래밍 언어로 작성하고 테스트할 수 있으며, 상태 머신이 많은 Lambda 함수를 사용할 경우 비용도 절감됩니다. 왜냐하면 Step Functions의 상태 전환 비용 외에도 Lambda 호출 비용을 지불하게 되기 때문입니다. 따라서 모든 오케스트레이션을 코드로 Lambda 함수 하나에 몰아넣으면 비용이 절감될 가능성이 높습니다. 하지만 코드가 단순히 DynamoDB를 호출하는 것이라면, 모든 Lambda 함수를 직접 통합으로 대체할 수 있어 Lambda 비용이 발생하지 않습니다. Express 워크플로우를 사용하면 Lambda와 비슷한 비용이 들기 때문에 이 경우 비용 차이는 크지 않을 수 있습니다. 그러나 이는 상황에 따라 다릅니다. Lambda 함수 하나로 모든 것을 처리하면 확장성 측면에서도 더 유리할 수 있습니다. 상태 머신이 많은 Lambda 함수를 사용하면 Step Functions과 Lambda의 비율 제한에 의해 확장성이 제한될 수 있습니다. 반면, 단순히 Lambda만 사용하는 경우 Lambda의 동시 호출 한도만 적용되며, 이는 Step Functions의 상태 전환 초당 한도보다 훨씬 높습니다. 따라서 시스템의 전체 확장성은 먼저 도달하는 한도에 의해 결정됩니다. Lambda를 사용할 때는 항상 공통 예산(CO-ART)과 사용자가 대기하는 동기 워크플로우, 최대 15분의 실행 시간이 충분한지 여부를 고려해야 합니다. 또한, 밀리초 단위로 실행 시간을 지불하기 때문에 대기 시간이 필요한 경우 비용 효율적이지 않습니다. 반면, Step Functions은 표준 워크플로우의 가격 모델이 대기 시간에 적합하며, 특히 워크플로우 실행을 시각화할 수 있어 디버깅이 매우 용이합니다. 이는 개발자뿐만 아니라 고객 지원 팀에게도 유용합니다. Step Functions 콘솔에서 실패한 실행을 빠르게 찾아 어디서 문제가 발생했는지 확인할 수 있으며, 모든 입력과 출력, 오류 메시지를 통해 문제를 쉽게 파악할 수 있습니다. Step Functions의 또 다른 강점은 모든 실행에 대한 완전한 감사 기록을 제공한다는 점입니다. 각 상태 전환이 언제 시작되고 끝났는지, 오류가 발생했는지 등을 자세히 기록하므로 디버깅이 매우 용이합니다. 또한, Step Functions은 거의 모든 AWS 서비스와 직접 통합할 수 있어 모든 것을 Lambda 함수로 처리할 필요가 없습니다. Lambda를 사용하지 않으면 공통 예산 문제도 발생하지 않으며, 더 예측 가능한 성능을 얻을 수 있습니다. 높은 최대 지속 시간과 콜백 패턴 구현 능력 덕분에 Step Functions은 매우 유연합니다. 개인적으로 Step Functions을 비즈니스에 중요한 워크플로우에 사용하는 것을 선호하는 이유는 더 견고한 오류 처리를 구현할 수 있기 때문입니다. 예를 들어, 단순한 태스크 상태에서 다양한 유형의 오류에 대해 지수 백오프를 사용한 재시도를 추가할 수 있습니다. 모든 재시도가 소진된 후 오류를 처리하기 위해 캐치 절을 추가할 수도 있습니다. Lambda에서도 몇 줄의 코드로 이를 구현할 수 있지만, Step Functions을 사용하면 이러한 오류 처리와 재시도를 상태 머신 외부로 분리할 수 있어 함수의 타임아웃 설정에 대해 걱정할 필요가 없습니다. 따라서 비즈니스에 중요한 워크플로우를 구축할 때 Step Functions을 사용하는 것이 훨씬 더 신뢰할 수 있는 애플리케이션을 만드는 데 도움이 됩니다. 물론, 이러한 신뢰성에는 추가 비용이 발생하며, Step Functions을 배우는 데도 학습 곡선이 존재합니다. Amazon State Language를 학습하고 구성 및 관리를 위한 추가 작업이 필요하기 때문에 단순한 워크플로우에는 너무 많은 오버헤드일 수 있습니다. 또한, Step Functions을 테스트하는 것이 어렵기 때문에 대부분의 사람들이 어려움을 겪습니다. 제 서버리스 테스트 과정에서는 Step Functions 테스트에 대한 전체 챕터를 할애하여 로컬 및 확장 테스트에서 Step Functions을 테스트하는 방법을 가르치고 있습니다. 현재는 PandaTube15 코드를 사용하면 15% 할인을 받을 수 있습니다. 앞서 언급한 Lambda destinations은 성공 시 Lambda 함수를 함께 연결하여 워크플로우를 구현하는 또 다른 방법입니다. 이 접근 방식은 매우 단순한 원홉 워크플로우에 적합합니다. 예를 들어, 비동기 함수가 이벤트 처리를 마치고 분석 이벤트를 제3자 시스템에 보내는 등의 보조 작업을 오프로딩할 때 유용합니다. 두 번째 단계가 실패하고 재시도될 경우, 원래 이벤트를 두 번 처리할 필요가 없습니다. 하지만 이러한 원홉 워크플로우를 넘어서는 경우에는 사용하지 않는 것이 좋습니다. Lambda to Lambda 체이닝은 제한된 가시성과 비동기 특성으로 인해 디버깅과 오류 처리가 어렵습니다. 활성 트레이싱을 X-Ray와 함께 사용하면 일부 정보를 볼 수 있지만, 기본적으로 샘플링이 많이 되어 대부분의 워크플로우 실행은 여전히 보이지 않습니다. 각 단계에 대해 경고 및 Dead Letter Queue를 설정해야 하며, 그렇지 않으면 문제가 발생했을 때 알 수 없고 데이터 손실이나 이벤트 손실이 발생할 수 있습니다. Step Functions을 사용하면 디버깅이 훨씬 쉬워지므로, 복잡성을 줄이고 빠르게 문제를 해결할 수 있습니다. 따라서 원홉 워크플로우를 제외한 다른 경우에는 Lambda destinations을 사용하지 않는 것이 좋습니다. 이번 Lambda 함수와 Step Functions을 사용한 워크플로우 구축 비교는 여기까지입니다. 이 비디오를 즐기고 새로운 것을 배웠다면, 좋아요를 누르고 채널을 구독해 주세요. 이는 저에게 큰 도움이 되며 서버리스 개발에 대한 더 많은 팁을 공유할 수 있게 해줍니다. 다음 시간까지, 감사합니다!

Woow. That’s a terrific advice

Thank you for sharing your knowledge

For Korean AWS Step Functions는 워크플로우를 상태 머신(state machine)으로 모델링할 수 있게 해주는 오케스트레이션 서비스입니다. 주로 특정 순서대로 그룹화된 Lambda 함수들을 오케스트레이션하고 실행하며, 한 함수의 출력을 다음 함수로 전달하거나 워크플로우의 일부로 분기 로직을 구현하는 데 사용됩니다. 또한, 현재 실행 상태에 따라 의사 결정을 내리거나, 함수의 타임아웃 설정에 구애받지 않는 강력한 오류 처리와 유연성을 제공합니다. 콜백 패턴을 사용하여 사람 운영자를 워크플로우에 포함시킬 수 있어, 워크플로우를 일시 중지하고 그들의 입력을 기다리거나, 맵 리듀스 작업과 같은 대량의 데이터를 병렬로 처리할 수 있습니다. 가능성은 정말 무궁무진하며, Step Functions는 실행 상태를 관리하고, 한 상태에서 다음 상태로 전파하며, 실행 중인 위치를 추적합니다. 이를 통해 애플리케이션을 구축할 수 있는 확장 가능하고 탄력적인 플랫폼을 제공하여 인프라보다는 비즈니스 로직에 집중할 수 있게 해줍니다. 또한, 모든 실행에 대한 자세한 감사 기록을 기본적으로 제공합니다. 상태 머신은 Amazon State Language(ASL)라는 JSON 기반 언어를 사용하여 설계할 수 있으며, Step Functions 콘솔에서 워크플로우를 시각화하거나 시각적 디자이너를 사용하여 새로운 워크플로우를 단계별로 설계할 수 있습니다. 이는 JSON 구문에 방해받지 않고 비즈니스 이해관계자들과 협업할 때 매우 유용합니다. 함께 설계한 상태 머신의 JSON 정의를 인프라 코드로 복사하여 소스 제어가 가능하고 다양한 환경과 AWS 계정에 쉽게 배포할 수 있습니다. 워크플로우를 실행할 때, Step Functions 콘솔의 시각화 도구를 사용하여 진행 상황을 추적할 수 있습니다. 분기 로직이 있는 경우, 실행이 어떤 경로를 탔는지 확인할 수 있고, 각 단계의 입력과 출력을 볼 수 있어 무엇이 잘못되었는지 쉽게 파악할 수 있습니다. Step Functions는 실행 기록에서 최대 25,000개의 이벤트를 기록하며, 이는 디버깅과 Lambda 함수 호출에 유용합니다. 또한, CloudWatch에서 함수와 로그로의 바로 가기를 제공합니다. 용어에 대해 설명하자면, 실행 중인 각 단계를 상태 전환(state transition)이라고 부르며, 시작 및 종료 상태도 포함됩니다. 가격은 상태 전환 수에 따라 청구되며, 백만 번당 25달러입니다. 이는 AWS의 다른 서비스에 비해 다소 비싼 편이며, Lambda보다 훨씬 비쌀 수 있습니다. 그래서 2019년에 AWS는 Express 워크플로우를 도입했습니다. 표준 워크플로우는 최대 1년 동안 실행될 수 있어, 휴가 요청 승인과 같이 사람의 개입이 필요한 워크플로우에 유용합니다. 콜백 패턴을 사용하여 실행을 일시 중지하고, 이메일의 링크를 클릭하거나 메시지 큐에서 메시지를 처리하는 마이크로서비스가 신호를 보내도록 할 수 있습니다. Express 워크플로우는 실행당 이름을 지정할 수 있어, 예를 들어 주문이 한 번만 처리되도록 주문 ID를 실행 이름으로 사용할 수 있습니다. 가격은 상태 전환 수가 아닌 실행 수, 실행 시간, 사용된 메모리에 따라 청구되며, Lambda와 유사한 가격 모델을 가지고 있습니다. 하지만 Express 워크플로우는 내부적으로 Lambda 함수를 사용하지 않습니다. Express 워크플로우는 동기 실행을 지원하여, API Gateway를 사용해 실행을 시작하고 완료될 때까지 기다린 후, 실행 결과를 HTTP 응답으로 반환할 수 있습니다. 이는 표준 워크플로우에서는 여러 번의 라운드 트립이 필요했던 작업을 단순화합니다. 요약하자면, 표준 워크플로우는 결제 처리와 같은 비즈니스에 중요한 워크플로우에 적합하며, 높은 최대 지속 시간과 정확히 한 번 실행 보장을 제공합니다. 반면, Express 워크플로우는 많은 상태 전환이 필요한 워크플로우에 비용 효율적이며, 짧은 최대 지속 시간과 높은 처리량을 지원합니다. 두 가지 워크플로우를 결합하여 각자의 장점을 살리고 단점을 보완할 수도 있습니다. Lambda 함수가 한 번에 15분 동안 실행될 수 있는데, 이는 대부분의 경우에 충분하기 때문에 왜 Lambda 함수를 대신 사용하지 않는지 궁금할 수 있습니다. 이 질문에 대해서는 다음 비디오에서 다룰 예정이니, 구독하고 알림 벨을 클릭하여 새로운 비디오가 올라올 때 놓치지 않도록 하세요. 시청해 주셔서 감사합니다. 다른 서버리스 개발 관련 비디오도 확인해 보세요.

This one's a banger! Can't wait to utilise/re-factor coding styles for this precisely :D

Please I want to buy a tracker with API access

Without using identity pool, it is possible to use the token provided by userpool to access aws resources for ex : app gw. How this works and what is the rationale behind this?

Really great course - thanks a lot! Will definitely try it with websockets

Hi, great video, but let's say I have a website + IOS app + Android APP all using the same user pool. Google want you to create 1 client ID per platform, so here 3. Cognito only allow 1 link to google ( 1 client ID ) ... In the Cognito doc it say to use a identity pool where all 3 client ID are setup. At this point I have no clue how to setup this

7:24 The separation can be done in REST too.

Another grear discussion. Thanks guys!

Great example!

Better than many AWS talks videos

Alof of people getting AWS certifications and Azure certifications are simply cheating...

Thank you!

I recently switched from Node to Go and noticed huge improvements in cold start time. However, once I need to access other services, say DynamoDB, through SSL/TLS the few milliseconds saved from moving from Go to Rust seems negligible. The initial SSL/TLS handshake in my case take at least 500-600ms. Do you have any practical tips to speed up this handshake process in Lambda functions? Not like adding AWS secret keys to environment configuration. Thanks!

It depends on your software architecture, the teams characteristics/culture, the product. In some cases the test pyramid is more adequate (even the inverted pyramid). But I totally agree on the ultimate lesson here: write tests that provide value, no more, no less

your course is really expensive for Indian peoles.

As always, great content. @ 36 mins in, there is a discussion around Amplify (I'd given up on Amplify years ago) and you mentioned Gen2 making Amplify more accessible. Have you found time to see if Gen2 is flexible, like baseline?

The most unexpected thing with CDK is that you are not always getting what you have described in code. For instance, an extra lambda function when you set a retention period.

you explained this topic better than aws docs

What if i have a aws timestream database ingested externally? how can i subscribe any new data inserted to the database?

anything is better than amplify. It sucks and i hate it. love ur vids

a great watch. I am definitely interested in checking this thing out

Excellent video, thanks for sharing

Hi is there a chance to get only Step Function testing module from your course?

cheers

Are Devops engineers going to loose jobs to AI ? Please let me know

this is great! thanks

Farrah rocks!

Nice one, Yan! Succinct, simple language, and straight to the point. Very good. Thanks for recording and sharing!

Very good explanation!