Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Microservice architecture

2,329 views

Published on

Microservice architecture. Short intro into the world of microservices, the talk I gave in VilniusPHP meetup.

Published in: Software
  • Be the first to comment

Microservice architecture

  1. 1. Microservice architecture Žilvinas Kuusas VilniusPHP 0x19, 2014
  2. 2. Who am I? Žilvinas Kuusas lead developer @ Estina / iSign.io t: @kuusas e: zilvinas@kuusas.lt
  3. 3. What is a microservice? The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. Martin Fowler http://martinfowler.com/articles/microservices.html
  4. 4. Microservice ● No long-term relationships with technology stack ● Easy to adopt emerging technologies ● Loose coupling ● Single responsibility ● Fault isolation ● Scalability
  5. 5. UNIX philosophy rename 's/Airplane/Flight/' `find -name "*Airplane*.php”`
  6. 6. UNIX philosophy ls . | sort | tail -n 2 | sort -r | tail -n 1 | cut -c8-21
  7. 7. Microservice architecture Microservice architecture
  8. 8. Monolithic application Reality - monolithic application
  9. 9. Service Oriented Architecture (SOA)
  10. 10. Benefits of monolith ● Quick development ● Simple deployments ● Easy to scale ● Everything in one place
  11. 11. Drawbacks of monolith ● Lots of LOC ● Slow builds ● Development is hard to scale ● Continuous deployments becomes difficult ● Scaling application can be difficult ● Requires a long-term commitment to a technology stack
  12. 12. Microservices Think about microservice as small, single-purpose application. Simple?
  13. 13. Small application ● Runs as individual process ● Smaller means easier for developers to maintain ● Changes does not affect whole system ● Faster to build and deploy ● ...or throw away and rewrite
  14. 14. Small application ● Each service has it’s own database ● Code duplication vs. code coupling ● Shared code - libraries
  15. 15. Small application “If service is bigger than your head then it’s too big” Internet
  16. 16. Deploy independently ● Each microservice runs in it’s own process, so deployment of one service won’t affect the whole application ● Easier to scale development ● Faster feature releases ● Less downtime ● Develop, build and deploy!
  17. 17. Flexible solutions ● Modular ● Polyglot data persistence ● Multi-framework
  18. 18. Right tool for the job
  19. 19. Application: two layers ● System layer ○ gateway: defines interfaces, communication mechanisms ○ rarely changes ● Service layer ○ services with different internal architectures ○ different technology stacks ○ evolves rapidly
  20. 20. Application: two layers Application: two layers
  21. 21. When to use it? ● In the beginning it will slow down the development ● Later - refactoring might be painful ● It’s easier to merge services than split monolith into services ● ...unless monolith already has loosely-coupled modules
  22. 22. Be realistic “Focus on building services that make development and deployment easier - not just tiny services”
  23. 23. Nanoservice antipattern A nanoservice is a service whose overhead (communications, maintenance, and so on) outweighs its utility.
  24. 24. How services communicate? ● HTTP/REST ● AMQP for asynchronous requests ● Event Sourcing ● Streams
  25. 25. Databases ● DB instance per service ● Relational databases, NoSQL, others
  26. 26. How to start? ● ESI (Edge Side Includes) ● RabbitMQ ● Gearman ● PHP multithreading
  27. 27. Shared data problem ● ServiceA needs to read data which is managed by ServiceB
  28. 28. Solution A ServiceA calls ServiceB for data ● Benefits ○ quick implementation ○ data is always fresh ● Drawbacks ○ slows down ServiceA ○ ServiceB might be down at the moment
  29. 29. Solution B Data replication ● Benefits ○ availability ○ speed ● Drawbacks ○ data replication overhead
  30. 30. Performance ● Latency is your foe ● Everything done asynchronously - no problem ● Keep communication between services as effective as possible. No chit-chats.
  31. 31. Drawbacks ● High level of distributed complexity
  32. 32. Automation ● Automate everything ○ CI ○ deployments ○ configuration ○ error logging ○ monitoring
  33. 33. PHP world PHP world
  34. 34. Symfony2 app as service ● Symfony2 isn’t heavy… ● ...if you know how to circumcise it ● Avoid standard edition ● Create your own minimal application http://www.whitewashing.de/2014/04/24/symfony_hello_world.html
  35. 35. Symfony2 benefits ● HttpKernel component is one of the greatest things happened in PHP world in years ● SF2 DIC: flexible and extendable way to grow your project ● Console component for CLI utilities ● Standardised solutions
  36. 36. Symfony2 as gateway ● Basic SF2 application with dumb controllers for routing services ○ via messaging ● Rendering main views for ESI
  37. 37. Challenges ● Define service boundaries ● Continuous Integration ○ Continuous Deployment ● Error logging ● Monitoring ● System tests ○ Consumer tests
  38. 38. More challenges... ● Security layer ● Shared configuration ● Shared assets ● Graceful degradation
  39. 39. Who is using ~120 services to generate 1 page http://highscalability.com/amazon-architecture Has 600+ services in total http://techblog.netflix.com/ http://www.ebaytechblog.com/
  40. 40. Why microservice? ● Scale development ● Scale your application ● Application availability ● Use right tools for the job ● Whole system becomes faster if done right
  41. 41. Dig more ● Martin Fowler http://martinfowler. com/articles/microservices.html ● Fred George https://www.youtube.com/watch? v=2rKEveL55TY ● http://blog.arkency.com/2014/07/microservices-72- resources/
  42. 42. What’s next? Reactive architecture? http://www.reactivemanifesto.org/
  43. 43. Questions?
  44. 44. Join us hello@estina.com

×