Jarosław Pałka | Devoxx

Jarosław Pałka
Jarosław Pałka Twitter

From Allegro

Od ponad 15 lat w branży IT, jako administrator baz danych, programista, architekt, manager i „inżynier od spraw katastrof”. Brałem udział w małych, średnich i nonsensownie dużych projektach, prowadzonych zgodnie zasadami „waterfall”, Agile oraz przy braku jakichkolwiek metodyk, z tym samym zawsze skutkiem. Co doprowadziło mnie do wniosku, że nie ważne co robisz tak długo, jak robisz to dobrze, w najprostszy z możliwych sposobów i używasz właściwych narzędzi które wykonają pracę za ciebie. W międzyczasie dałem się porwać ideą TDD oraz Software Craftmanship, do granic możliwości wyeksploatować tak piękne w swej prostocie pomysły jak REST i NoSQL, by potem porzucić je by zgłębić tajniki „system thinking” i zachwycić się siłą jaką niesie z sob

Blog: https://plus.google.com/+JarosławPałka

archi Architecture & Security

Stages of maturity on the way to microservices

Conference

Microservies. Everybody is talking about microservices. Everybody says they do microservces (or at least they plan to) . The definition of microservice architecture is quite broad and vague: functional decoupling into discrete services. Therefore a number of approaches, with different flavors and implementations is so great - everybody can do microservices differently.

In this talk we aim to categorize and make some things clear. Based on experience from multiple companies, projects and f*ck ups, we would like to propose certain maturity criteria which organizations must embrace to start with microservices approach. Without these, things might work but times might become even harder. We will walk through multiple practices essential for successful microservices rollout.

This won’t be a purely technical talk - no successful change in the organisation happened on purely technical bases. We will correlate the maturity criteria with some business drivers, which help team-up business and technical guys on the same side.

If your organisation considers microservices, or you - as an engineer - need some argument to better justify the technical choices, this talk might be for you.