Armagan Amcalar

Software architect, Lecturer, Mentor, Founder @ Coyotiv

Armagan is a software architect, public speaker, a mentor and a lecturer. He also leads Coyotiv, a software engineering ecosystem and a school.

A software architect well versed in both the backend and frontend systems, he focuses on building resilient clouds. He is active in the open source community and is the author of cote, a library for building microservices with Node.js, among many others. In his free time, he hacks stuff with JavaScript, ranging from musical gadgets to brain signals processing.

As a mentor, Armagan has helped over 400 engineers join the software industry. He also mentors startups and companies on software and cloud architecture.

Clean Cloud

Apr 01, 2021

As an industry we have only a handful of proven best practices compared to more established fields of engineering. A set of these practices now make the rounds as “Clean Code” and “Clean Architecture”, as made famous by Robert C. Martin. But our struggles and our fights have moved on since this move—it’s now the age of the Cloud. Join Armagan in this talk and take your first step into Clean Cloud, a set of architectural patterns and best practices for cloud applications. Together, let’s find out how our collective experience will guide us about the future of code.

Five rules of Microservices

Mar 13, 2020

The concept of microservices is hot and it draws many developers from a diverse background. Unfortunately, we see a lot of ideas from the past rebranded as microservices; whereas the thinking behind microservices implies and promises a bigger change. This talk will go over the details of what actually makes a microservices architecture and how other distributed systems — that rely on queues and other mechanisms to function — fail to fulfill the promise.

A modern microservices implementation should be;

Zero-configuration: any microservices system will likely have hundreds of services. Therefore, a manual configuration of IP addresses, ports and API capabilities is infeasible.
Highly-redundant: service failures are very common in this scenario. So it should be very cheap to have copies of such services at disposal with proper fail-over mechanisms.
Fault-tolerant: the system should tolerate and gracefully handle miscommunication, errors in message processing, timeouts and more.
Self-healing: it’s normal for outages and failures to occur. The implementation should automatically recover any lost service and functionality.
Auto-discovery: the services should automatically identify other new services that are introduced to the system to start communication without manual intervention or downtime.