A quick glance into the Microservices architecture and what the architecture offers over its precursor - Monolith Architecture

1. Srinivasan Nanduri
Architect, Mobile Services, IBM CloudMicroservicesArchitecture
@srinivasan_n

2. 2
•Prelude
•Overview
•Principles
•Characteristics
•Challenges
•Best practices
•References
Agenda

3. Prelude

4. 4
Monolith
..an architectural style that structures the application as a
single executable unit
• Simple to develop, test & deploy
o At most one technology per layer
• Simple to scale
o Run multiple copies (horizontal
scaling) behind a load balancer
Benefits
Image source: microservices.io

5. 5
Monolith: Problems
•Difficult to achieve operational agility
o Huge and intimidating code base for developers
o Long lead times for releasing new functionality because involves people with all skills coming
together
§ Redeploy entire unit to change one (sub) component
§ Refactoring take minutes, builds take hours, testing in Continuous Integration takes days
o Interrupts long running background (e.g. Quartz) jobs
o Increase risk of failure
•Single development stack - limits right tool for the job
•Convoluted database model
•Scaling is often a challenge
o Running a copy of the whole system is resource-intense
o Doesn’t scale with data out-of-the-box

6. Overview

7. 7
Overview
..an architectural style where applications are broken into
smaller *autonomous services that work together
• Developed by small engineering teams
• Can be written in any language /
framework
Benefits
*independently developed, run and operated
Trade-off: Complexity
Image source: microservices.io

8. 8
ConceptualTechnicalTeam
One large application that
serves the business
function
Small Independent
autonomous, auto deployable,
domain driven services of one
application
Each service is dependent on
the other
Each service has
independent stack &
de-centralized data
Organizational
UI Team DBA Team Test Team Build TeamServer Team
Service 3 team
Service 1 team
Cross Functional
Autonomous
Service teams
Embraces pure agile that
is cross functional
Every service team is small
and responsible end to
end.
Monolithvs. Microservices

9. Principles

10. 10
Principles
•The term “micro” refers to the sizing
o a microservice must be manageable by a single development team (5-9 developers)
•Independent deployability
o No shared state and inter-process communication (often HTTP REST-ish interfaces)
•Functional system decomposition / vertical slicing (in contrast to horizontal
slicing through layers)
•Each microservice is functionally complete with
o Resource representation
o Data management
Microservices are fun-sized services, as in
“still fun to develop and deploy”

11. 11
Model goodservices
•Each service should be
o Loosely coupled - a change in one should require no change in another
o Highly cohesive - related behaviour sits together, unrelated else where
§ Bounded context helps – a specific responsibility enforced by explicit boundaries. A ‘product’ is
different in the context of a catalog vs. shipping
•Each microservice handles one resource (or verb), e.g.
o Client
o Shop items
o Cart
o Checkout
Should comply with
SRP & LSP

12. Might be well-structured inside.
But, can only be deployed as a whole
Catalog
System
Integration
Testing
Micro services can only be deployed independently if tests are independent & if your Continuous Delivery Pipeline works
Catalog
MonolithicMicroservice
Commit Stage
Automated
Acceptance Testing
Automated
Capability Testing
Manual
Explorative Testing
Release
Release
Manual
Explorative Testing
Automated
Capability Testing
Automated
Acceptance Testing
Commit Stage
Manual
Explorative Testing
Automated
Capability Testing
Automated
Acceptance Testing
Commit Stage
Manual
Explorative Testing
Automated
Capability Testing
Automated
Acceptance Testing
Commit Stage
Manual
Explorative Testing
Automated
Capability Testing
Automated
Acceptance Testing
Commit Stage 7
Independent deployabilityiskey enablesseparationandindependentevolutionof
• codebase
• technologystacks
• scaling
• andfeatures,too

13. 13
Independent codebase
•Each service has its own software repository
•Codebase is maintainable for developers – it fits into their brain
•Tools work fast – building, testing, refactoring code takes seconds
•Service startup only takes seconds
•No accidental cross-dependencies between code bases

14. Independenttechnologystacks
14
•Each service is implemented in its own technology stack
•The technology stack can be selected to fit the task best
•Teams can also experiment with new technologies within a single
microservice
•No system-wide standardized technology stack also means
•No struggle to get your technology introduced to the canon
•No piggy-pack dependencies to unnecessary technologies or libraries
•It‘s only your own dependency hell you need to struggle with
•Selected technology stacks are often very light-weight
•A microservice is often just a single process that is started via command line, and not
code and configuration that is deployed to a container.

15. Independentscaling
•Each microservice can be scaled independently
•Identified bottlenecks can be addressed directly
•Data sharding can be applied to microservices as
needed
•Parts of the system that do not represent bottlenecks
can remain simple and un-scaled
Scaling
Cube
horizontal&vertical
functionaldecomp.
15

16. Independent evolution of features
16
•Microservices can be extended without affecting other services
•For example, you can deploy a new version of (a part of) the UI without
re-deploying the whole system
•You can also go so far as to replace the service by a complete rewrite
But you have to ensure that the service interface remains stable

17. Stable Interfaces – standardized communication
17
•HTTP(S) – battle-tested and broadly available transport protocol
•REST – uniform interfaces on data as resources with known
manipulation means
•JSON – simple data representation format
REST and JSON are convenient because they
simplify interface evolution

18. Characteristics

19. Componentization via Services
19
•Interaction mode: share-nothing, cross-process communication
•Independently deployable (with all the benefits)
•Explicit, REST-based public interface
•Sized and designed for replaceability
•Upgrading technologies should not happen big-bang, all-or-nothing-style
•Downsides
•Communication is more expensive than in-process
•Interfaces need to be coarser-grained
•Re-allocation of responsibilities between services is harder
•Lack of tooling
•Operational complexity

20. FavorsCross-FunctionalTeams
Line of separation is along functional boundaries, not along tiers
VS
Presentation
Logic
DB
DataAccess
20
Any organization that designs a system (defined broadly)
will produce a design whose structure is a copy of the
organization's communication structure
Melvyn Conway

21. DecentralizedGovernance
Principle: focus on standardizing the relevant parts, and leverage battle-tested
standards and infrastructure
Treats differently
•What needs to be standardized
•Communication protocol (HTTP)
•Message format (JSON)
•What should be standardized
•Communication patterns (REST)
•What doesn‘t need to be standardized
•Application technology stack
21

22. DecentralizedDataManagement
•Create a separate database for each service
•OO Encapsulation applies to services as well
•Each service can choose the persistence solution that fits best its
•Data access patterns
•Scaling and data sharding requirements
•Only few services really need enterprisey persistence
22

23. InfrastructureAutomation
•The microservice architectural style assumes using continuous
Integration and continuous delivery development practices
•Continuous Delivery is much easier when the system is build of
microservices
•Having to deploy significant number of services
forces operations to automate the infrastructure for
•Deployment (Continuous Delivery)
•Monitoring (Automated failure detection)
•Managing (Automated failure recovery)
23

24. Challenges

25. How to decompose an application into services?
How to deploy an application’s services?
How to handle cross cutting concerns?
Which communication mechanisms to use?
How do external clients communicate with the services?
How does a client discover the network location of a service instance?
How to prevent a network or service failure from cascading to other services?
How to maintain data consistency and implement queries?
How to understand the behavior of an application and troubleshoot problems?
How to make testing easier?
How to implement a UI screen or page that displays data from multiple services?
Challenges

26. FallaciesofDistributedComputing
Essentially everyone, when they first build a distributed application, makes
the following eight assumptions. All prove to be false in the long run and all
cause big trouble and painful learning experiences.
•The network is reliable
•Latency is zero
•Bandwidth is infinite
•The network is secure
•Topology doesn‘t change
•There is one administrator
•Transport cost is zero
•The network is homogeneous
Peter Deutsch
26

27. MicroservicesPrerequisites
27
Before applying microservices, you should have in place
•Rapid provisioning
o Dev teams should be able to automatically provision new infrastructure
•Basic monitoring
o Essential to detect problems in the complex system landscape
•Rapid application deployment
o Service deployments must be controlled and traceable
o Rollbacks of deployments must be easy
Source
http://martinfowler.com/bliki/MicroservicePrerequisites.html

28. Evolvinginterfacescorrectly
28
•Microservice architectures enable independent evolution of services
– but how is this done without breaking existing clients?
•There are two answers
•Version service APIs on incompatible API changes
•Using JSON and REST limits versioning needs of service APIs
•Versioning is key
•Service interfaces are like programmer APIs – you need to know which version
you program against
•As service provider, you need to keep old versions of your interface
operational while delivering new versions
•But first, let’s recap compatibility

29. API Compatibility
29
There are two types of compatibility
•Forward Compatibility
•Upgrading the service in the future will not break existing clients
•Requires some agreements on future design features, and the design of new versions
to respect old interfaces
•Backward Compatibility
•Newly created service is compatible with old clients
•Requires the design of new versions to respect old interfaces
The hard type of compatibility is forward compatibility!

30. FurtherChallenges
30
•Testing the whole system
•A single microservice isn‘t the whole system.
•A clear picture of upstream and downstream services is needed for integration testing
•Transactions
•Instead of distributed transactions, compensations are used (as in SOA)
•Authentication
•Is often offloaded to reverse proxies making use of authentication (micro) services
•Request logging
•Pass along request tokens
•Add them to the log
•Perform log aggregation

31. MigrationChallenges
31
•Incrementally refactor the monolithic application
•New functionality in a new microservice
•Split frontend and backend
•Extract services
•Service discovery

32. Best practices

33. Thetwelvefactors

34. • Just one tool to deploy everything - as long as the microservice is in a
container, the tool knows how to deploy it.
• Docker has become the de facto standard for containers very quickly.
Deployincontainers

35. Patterns
Image source: microservices.io

36. Asynchronous calls
36
• An application based on asynchronous communication implements a
loosely coupled design, much better so than one based purely on
synchronous method calls
• An event-driven approach can make efficient use of existing
resources. Example:
o When you need to create an order, just publish an event to the bus informing that
you need an order.
• Lightweight messaging technologies (as an alternative for JMS):
o Simple messaging via Atom feeds
o Apache Kafka (http://kafka.apache.org/) - a high-throughput distributed
messaging system
• The event-driven approach is a key element of reactive programming
o In reactive programming, when you have a:=b+c assignment, and after that you
change b or c, a will change as well

37. Reactive Programming
37
• Alternative to imperative programming
• According to The Reactive Manifesto
(http://www.reactivemanifesto.org), RP allows developers to build
systems that are:
o Event-driven
o Scalable
o Resilient (to software, hardware or connection failures)
o Responsive (providing rich, real-time interaction with users)
• By reacting it is means to react to:
o Events
o Load
o Failures
o Users

38. References

39. SourcesandFurtherReading
39
Books:
• Continuous Delivery - Jez Humble, Dave Farley
• Working Effectively with Legacy Code - Michael Feathers
• Domain Driven Design - Eric Evans
• Your Brain atWork - David Rock
• Refactoring Databases - ScottWAmbler & Pramod Sadalage
• Building Microservices - Sam Newman
Articles/Blogs:
• http://microservices.io
• Ball of Mud: http://www.laputan.org/mud/
• Demming - http://leanandkanban.wordpress.com/2011/07/15/demings-14-points/
• Coding Horror: http://www.codinghorror.com/blog/2007/11/the-big-ball-of-mud-and-other-architectural-
disasters.html
• http://devlicio.us/blogs/casey/archive/2009/05/14/commercial-suicide-integration-at-the-database-level.aspx
•EvolutionaryArchitecture and Emergent Design: http://www.ibm.com/developerworks/java/library/j-eaed1/index.html
• Microservices: http://www.infoq.com/presentations/Micro-Services and
http://yobriefca.se/blog/2013/04/29/micro-service-architecture/ and
http://davidmorgantini.blogspot.co.uk/2013/08/micro-services-what-are-micro- services.html

40. SourcesandFurtherReading
40
Aritcles/Blogs:
• https://www.ibm.com/blogs/bluemix/2018/05/architecting-applications-microservices-general-principles/
• http://martinfowler.com/articles/microservices.html
• http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
Case studies:
• https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/
• http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay-on-building-ecosystems-of.html
• https://apiumhub.com/tech-blog-barcelona/microservices-architecture-implementation/

41. Thank you