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.

Grokking microservices in 5 minutes


Published on

Comparing and contrasting monolithic systems to Lego pieces (microservices) at the 50,000 foot view. In this presentation we will compare and contrast monolithic systems to microservices. We will then take a look at some of the down sides to microservices. And then we will discuss some strategies for building microservices.

Published in: Technology
  • Be the first to comment

Grokking microservices in 5 minutes

  1. 1. Grokking Microservices in 5 Minutes Comparing and contrasting monolithic systems to Lego pieces at the 50,000 foot view. Andrew Siemer | Developer Springboard @asiemer
  2. 2. Andrew Siemer ASP Insider MS v-TSP (Azure) Azure Advisor Program Father of 6. Jack of all trades, master of some.
  3. 3. • How to achieve your DREAM career • Discover • Refine • Establish • Advance • Master @devspringboard
  4. 4. Azure Austin Meetup An hour of deep dive by technical leaders with a slant on all things Azure! API Management, DocumentDB, Search, Distributed Systems, Microservices
  5. 5. Clear Measure Workshops Day long, Clear Measure led, fingers on keyboards, learn by doing CQRS, DDD, Event Sourcing, Distributed Systems, Micro Services
  6. 6. Introduction • Monolithic vs. Microservices • Microservice Cons • How to do Microservices
  7. 7. Monolithic vs. Microservices
  8. 8. Monolithic vs. Microservices Monolithic • Deploy the world • Dev slows as complexity grows • Large test surface • No code ownership • Reusability forces design choices • Many layers of features creates tighter coupling Microservices • Deploy pieces • New feature, new service • Small test surface • Specific code ownership • Choose technology that fits best • Loose coupling based around contracts
  9. 9. Monolithic vs. Microservices Monolithic • One data access to rule them all • Transactionality, consistency, data storage, designed up front • Feature’s have presence in each layer of the application • All features live in the same repository, versioned together • Code complexity to manage Microservices • One data access per service • Pick what fits each service at the time you build it • Each layer of the service lives with the feature • Each service lives in its own repository, versioned on its own • No code complexity to manage
  10. 10. Microservice Cons
  11. 11. First rule of distributed systems Don’t! Don’t build distributed software unless you know you absolutely need too. The complexity of the development story, the management story, and the system level communication story goes up. Only do this if you know the system will either be complex, needs to scale, or both.
  12. 12. Complexity vs. Productivity From:
  13. 13. Cons • Deployments require automation • Logging and monitoring must be centralized • Governance required for technology adoption • Learning curve to get it right can be steep • Lack of design around resiliency can cause cascading failures
  14. 14. How to do Microservices
  15. 15. Rules for Microservcies • Each service has a single responsibility • One code repository per service • How small? Small enough to fit in your head at one time! • Common code can be shared as a library and treated like you would an open source dependency • Every service runs in its own process (vm, container) • DDD applied: Domains in different bounded contexts should be distinct • Its therefore ok to have duplication! • Conway’s Law
  16. 16. Conway’s Law “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”
  17. 17. Rules for Microservices • Each service can choose its own technology (careful here) • Always resort to building a new service first • If the new service is small enough, refactor it into another service as needed • Splitting services later is harder • A service should control it’s world • Separate data store per service • Separate UI components provided by the service
  18. 18. Data Strategies A service should store and maintain its own data • Foreign keys to other systems might be stored as a REST URI • If you need external data, call a service over keeping your own copy • Don’t fear data redundancy • Replication of data is ok if you need it
  19. 19. UI Strategies A service should provide its own UI components • When possible, a service serves the entire page • Services agree on CSS naming conventions • Centralize shared components such as menu, styles, common resources • UI composition only allowed on the client (SPA) • Create a composite view of UI fragments when embedding data from many services
  20. 20. Security Strategies Security context is spread over many services • Services: authentication, login, authorization, administration • OAuth2 is great for distributed systems • Can use a shared cookie across services
  21. 21. Communication Strategies Everything is allowed, but you should establish one standard • REST works everywhere…but can be slower • Strive for loose coupling • No logic in the communication channel • NO ESB like BizTalk • Asynch messaging is great • Design for resiliency
  22. 22. Testing Strategies Tests should be on the behalf of the consumer not the producer • Integration tests are good enough, services are small • Dependencies should be mocked, only test your service • Consumers of your service writes tests • Contribute tests to a test pool which your service must pass
  23. 23. Deployment Strategies With hundreds of services everything must be automated • Continuous delivery • Use deployment pipelines • Automate everything
  24. 24. Questions? Andrew Siemer – Developer Springboard (512) 387-1976 @asiemer