grokking microservices in 5 minutes
TRANSCRIPT
Grokking Microservices in 5 Minutes
Comparing and contrasting monolithic systems to Lego pieces at the 50,000 foot view.
Andrew Siemer | Developer [email protected]@asiemer
Andrew Siemerhttp://about.me/andrewsiemer
ASP InsiderMS v-TSP (Azure)
Azure Advisor ProgramFather of 6. Jack of all trades, master of some.
• How to achieve your DREAM career• Discover• Refine• Establish• Advance• Master
DeveloperSpringboard.com@devspringboard
Azure AustinMeetup
An hour of deep dive by technical leaders with a slant on all things Azure!
API Management, DocumentDB, Search, Distributed Systems, Microservices
meetup.com/azureaustin
Clear Measure Workshops
Day long, Clear Measure led, fingers on keyboards, learn by doing
CQRS, DDD, Event Sourcing, Distributed Systems, Micro Services
meetup.com/clear-measure-workshop
Introduction
• Monolithic vs. Microservices• Microservice Cons• How to do Microservices
Monolithicvs.
Microservices
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
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
MicroserviceCons
First rule of distributed systemsDon’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.
Complexity vs. Productivity
From:http://martinfowler.com/bliki/MicroservicePremium.html
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
How to doMicroservices
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
Conway’s Law“organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”
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
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
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
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
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
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
Deployment Strategies
With hundreds of services everything must be automated
• Continuous delivery• Use deployment pipelines• Automate everything
