Think Big - Build Small

Think Big - Build Small

• 1.
  Think Big (enabled bythe Cloud) Build Small
• 2.
  What we’ll cover •The way we used to (or still) build software • Timing is everything - Hello Cloud • A better* (not easier) way to build software • Not a silver bullet • How to get started
• 3.
  Evolution of Software Development •Long planning, gather requirements, build one big thing • Iterative planning, ship fast, continuous delivery, still build one big thing • Everything becomes an API, mobile on the rise • Automate all things - DevOps • Mostly, still building one big thing - Monolith (or many - still big - things, SOA)
• 4.
  The Monolith Server The Monolith
• 5.
  The Monolith (closerlook) The Monolith Module 1 Module n Module 2 …
• 6.
  • Upgrade serverOS • Upgrade framework • Modify module n • Ship new code • Adopt some new technology The Monolith Struggle
• 7.
  (Hard) Lessons Learned •Codebase becomes huge - Difficult to maintain, on-board new members • Tightly coupled code • Tied in to a specific technology, no room to explore something new or attract more diverse talent • Change is “expensive” and risky • Not shipping fast enough
• 8.
  On Cloud 9 •Servers on demand - no more slow, painful provisioning • Best industry practices available to everyone • API’s to manage servers and services • Ease of deployment • “Infinite” scalability / elasticity
• 9.
  Perfect Timing • Finally,we can afford the operational cost of breaking the monolith • Provisioning new services can be fast and cheap • No need to pre-invest in infra-structure, invest as you go • New cloud services offering automation on so many levels • The rise of containerization (no more “but it works on my local”)
• 10.
  A New Hope(any Star Wars fans out there?) • “Microservices is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities” • Divide and conquer - your business isn’t just one department, why should your software be? • Iterate fast and cheaper, easier to experiment • Identify and isolate areas of experimentation, R&D
• 11.
  Microservices (oversimplified) Server 1 Service1 Server 2 Service 2 Server n Service n … APIAPI API Service 1 Service 2 APIAPI
• 12.
  Micro-service Benefits • Smaller,loosely coupled components, easier to manage, refactor • Each service, only communicating with the outside world via its API • Adopt best technology / tools for each use case • Each service owns its own data (enables polyglot persistency) • Scale per service as needed, more fine grained control • Self organizing teams
• 13.
  Who’s in? and manymore…
• 14.
  With great power… •Not a silver bullet, it still requires solid development and architectural practices • Many moving parts / Complex architecture • Automate automate automate • Setting up an integrated development environment
• 15.
  How do Iget started? • Truly understand your business and your data • Identify areas of responsibility and relationships between them • Educate yourself on microservices, build some pet projects (internal tools are ideal candidates) • Implement a small, low-risk module as a micro-service • Measure impact (time to ship, etc.) • Wash, rinse, repeat
• 16.
  Key Takeaways • Micro-servicesare not easy and are not for everyone or for every use case • You shouldn’t consider micro-services if you don’t understand your data • If you can’t build a good monolith, simply opting for micro-services is not going to fix anything • Getting it right is a constant iterative process • Start small. Experiment. • Automation is King
• 17.
  Thank you! @IraklisAlex Iraklis Alexopoulos