BTR-7404 Stages of maturity on the way to microservices | Devoxx

Stages of maturity on the way to microservices

Conference

archi Architecture & Security

Room 4 (Grand Parade)

Thursday from 14:30 til 15:20

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.

 MicroServices    Microservices Evolution    application architecture  
Jakub Marchwicki Jakub Marchwicki

Jakub has been around software development for past 10 years, wearing multiple hats, getting hands dirty in multiple environments, securing both technical as well as the business side of The Thing. “An engineer with a human friendly interface?”. Some languages, some frameworks, blah blah blah. Architect, programmer, manager, technical trainer, tech lead, wannabe entrepreneur, JUG leader.

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

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