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.

DigitalOcean: Microservices as the Cloud


Published on

We are happy to announce our next GOTO Night, a joint meetup with Morningstar Tech Talks.
This GOTO Night is one of a series of community events to take place from now until GOTO Chicago 2016. The 4th annual GOTO Chicago Conference and Workshops will take place May 23 - 26, 2016.
Phil Calçado, Software Engineering Director at DigitalOcean and Reid Draper, Director of Engineering at Helium will be presenting on March 22nd, 2016 at Morningstar USA Global Headquarters. We will have pizza and drinks at 5:15 PM and the talk will begin at 6:00 PM - We look forward to seeing you there!
Presentation - DigitalOcean: Microservices as the Cloud by Phil Calçado
Most infrastructure companies use somewhat traditional process when develiping their own systems. DigitalOcean is different, we are a product-driven Cloud company, focusing on building the best developer experience.
Like most product companies these days, we are doing such by quickly moving our achitechture to a service-oriented approach, based on microservices.
A while ago, Martin Fowler proposed that rapud resource provisioning and application deployment are pre-requires for a microservices arquitecture. The best way to achieve these is to move to the Cloud. In fact, that is why a lot of people use DigitalOcean to build their systems!

Published in: Technology

DigitalOcean: Microservices as the Cloud

  1. 1. DigitalOcean: Microservices as the Cloud Phil Calçado @pcalcado
  2. 2. How this kind of talk usually goes like…
  3. 3. Big Bad Monolith Big Bad Database MAGIC Super Awesome Microservices
  4. 4. All my stuff is W.I.P.
  5. 5. Iteration 1: The UNIX Way
  6. 6. Big Bad Database
  7. 7. Problem: Need more machines and datacentres, need to scale
  8. 8. Only vertical scaling Big Bad Database Big Bad Database
  9. 9. Iteration 2: Building a VPS
  10. 10. Big Bad Database Customer Tools Service Internal Tools Service
  11. 11. Problem: VPS are so last week, people want the cloud
  12. 12. Cloud brings even more complexity
  13. 13. Big Bad Database Customer Tools Service Internal Tools Service
  14. 14. Big Bad Database Customer Tools Service Internal Tools Service EVERYTHING
  15. 15. Iteration 3: Building a Cloud
  16. 16. Building a cloud means more servers, services, and datacentres i.e. more essential complexity
  17. 17. Larger services == Larger state-space
  18. 18. Adding stuff here is easier than creating a new service. Why? Big Bad Database Customer Tools Service Internal Tools Service
  19. 19. Because
  20. 20. chef/puppet/ansible /that-thing-on-hacker-news can be a pain, but it’s not the fundamental problem
  21. 21. Everything was managed by chef. Everything was a Pull Request. Everything needed code review.
  22. 22. Everything was painful. Everything was slow.
  23. 23. This is when I apply my bias experience
  24. 24. Back to basics • Rapid provisioning • Basic monitoring • Rapid application deployment
  25. 25. Legacy Services Databases How often do they change? Couple times per month Couple times per year Couple times per day
  26. 26. Legacy Services Databases How often do they change? Chef for now Chef Something else
  27. 27. 1. Rapid provisioning you should be able to fire up a new server in a matter of hours what about 55 seconds?
  28. 28. 2. Basic monitoring detecting technical issues but it's also worth monitoring business issues
  29. 29. 3. Rapid application deployment you need to be able to quickly deploy [services], both to test environments and to production
  30. 30. This is the first step…
  31. 31. …but experience tells me
  32. 32. …and next up Pre-requisites BFFs Programming Language Thunderdome Adopt GRPC or thrift Build a services directory Get bored and go do something else
  33. 33. You should consider being part of this Phil Calçado @pcalcado