Published on

Published in: Software, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • One resource can have multiple representations, e.g. XHTML, GIF, PDF and plain text.
  • Conway's law (1968) is a valid sociological observation
  • When you need to create an order, just publish an event to the bus, that you need an order.
    Maybe, the asynchronous nature is the single biggest difference between traditional SOA and microservices
  • Being Scalable, Resilient and Responsive is a consequence of being Event-driven
  • Even if you have a reference to an actor, you can not invoke its methods
  • In fact, the Actor has a stack of behavior, receive pointer points to the top one
  • When it is separate repository, you will think twice before deciding that some code should go to one repository not to another.
  • Microservices

    1. 1. Microservices Karol Grzegorczyk June 23, 2014
    2. 2. Microservices rely heavily on REST. Therefore, the first half of slides covers a review of basic REST concepts. If you are familiar with REST feel free to jump to slide 24. The content of this presentation is based on several external articles, books and presentations. See the bibliography on the last slide.
    3. 3. 3/44 Component software Software components are binary units of independent production, acquisition, and deployment that interact to form a functioning system. Clemens Szyperski A component is a unit of software that is independently replaceable and upgradeable. Martin Fowler
    4. 4. 4/44 Componentization via Libraries ● The most popular approach to component-based software engineering ● There are technologies that enable independent deployment, encapsulation and loose coupling between libraries (e.g. OSGi, Project Jigsaw), but they are not very popular in the industry. ● In practice, even if an application is build of multiple components, it is packaged and deployed as monolith, i.e. as a single archive (e.g. WAR or EAR).
    5. 5. 5/44 Monolithic applications ● Client code has access to the whole component implementation ● Often it's only documentation and discipline that prevents clients breaking a component's encapsulation, leading to overly-tight coupling between components. ● Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. ● Scaling requires scaling of the entire application rather than parts of it that require greater resource.
    6. 6. 6/44 Componentization via Web Services ● Services are independently replaceable and upgradeable. Changes to a single service, require only that service to be repackaged and redeployed. ● Remote calls make it easier to keep components loosely coupled. ● Remote calls are more expensive than in-process calls, and thus remote APIs need to be coarser-grained. ● Each service provides a firm module boundary, in terms of responsibility and in terms of technology ● There are many types of Web Services. Some of them support componentization more than others.
    7. 7. 7/44 World Wide Web ● Created by Tim Berners-Lee in the early 1990s while he was a research fellow at CERN. ● Definition according to the Architecture of the World Wide Web document by W3C: – The World Wide Web (WWW, or simply Web) is an information space in which the items of interest, referred to as resources, are identified by global identifiers called Uniform Resource Identifiers (URI) ● The Architecture is relatively short document that describes some key principles of the Web: – Web agents are acting on this information space. They can be peoples (user agents) or software (e.g. servers, proxies, browsers or multimedia players). – The agents communicate using standardized protocols that enable interaction through the exchange of messages which adhere to a defined syntax and semantics. – Agents exchange resource representations, a view of a resource's state at an instant in time. They never access the underlaying resource directly. The same resource, with a single URI, can have multiple different representations (e.g. plain-text, HTML and PDF). – Hypertext – A defining characteristic of the Web is that it allows embedded references to other resources via URIs. ● Popular Web's protocols: HTTP, FTP or SMTP
    8. 8. 8/44 The Hypertext Transfer Protocol ● RFC 2616 – Hypertext Transfer Protocol – HTTP/1.1 ● Idempotent Methods – the side-effects of multiple identical requests is the same as for a single request ● Safe methods – not taking an action other than retrieval Method Idempotent Safe OPTIONS yes yes GET yes yes HEAD yes yes PUT yes no POST no no DELETE yes no PATCH no no RFC 5789
    9. 9. 9/44 HTTP response codes ● 1xx: Informational – Request received, continuing process ● 2xx: Success – The action was successfully received, understood, and accepted – 200 – OK – 201 – Created – 204 – No Content ● 3xx: Redirection – Further action must be taken in order to complete the request ● 4xx: Client Error – The request contains bad syntax or cannot be fulfilled – 404 – Not found – 405 – Method not allowed – 409 – Conflict ● 5xx: Server Error – The server failed to fulfill an apparently valid request – 503 – Service unavailable
    10. 10. 10/44 Richardson Maturity Model [L. Richardson, Justice Will Take Us Millions Of Intricate Moves, Qcon, 2008] Level Description 3 Hypermedia 2 Multiple URI, multiple HTTP methods 1 Multiple URI, single HTTP method 0 Single URI, single HTTP method Leonard Richardson proposed a classification for services on the Web.
    11. 11. 11/44 Level 0 services ● All service operations are exposed via a single URI. ● Level zero services use the Web only as a tunneling technology or as a transport layer. ● Technologies: – SOAP-based services a.k.a. WS-* web services – Plain Old XML (POX) – like SOAP but without the SOAP envelope or any of the other baggage. – XML-RPC
    12. 12. 12/44 WS-* stack ● SOAP-based Web Services ● Began to be popular around year 2000. ● Integration based on open standards. ● Most often, SOAP uses HTTP as transport protocol, but in general SOAP messages can be routed through any transport protocols. ● SOAP do not leverage HTTP application protocol features. It uses single URL and only one HTTP method (POST). ● WS-* can not use web caching (because of POST). ● WSDL describes a service. It can be generated automatically. The service stub can be generated from WSDL. ● Mainstream WSDL tooling promotes poor design practices, like tight coupling [Graphic taken from Wikipedia]
    13. 13. 13/44 Service Oriented Architecture Services interact through a fixed interface shared through documentation or an interface description language (IDL). Distributed services are orchestrated by the centralized business process engine. A service is build of multiple service components, but they run on a single machine As we can see above, in SOA services are itself monoliths, build of multiple components! SOA became integration technology of monolith applications! [© The Open Group]
    14. 14. 14/44 Level 1 services ● Multiple URI, single HTTP method (often POST) ● Mapping business objects to resources ● URI tunneling – mapping URI template to the server side method or function – URI templates ● http://service.com/get_order/{order_id} ● http://service.com/search/{year}/{month}/{day} – URIs are used to encode operations rather then to represent resources itself ● Many services, that claim that they are RESTfull, are in fact just level one services!
    15. 15. 15/44 Level 2 services ● Multiple URI, multiple HTTP methods ● Use of GET and DELETE methods is straightforward ● It is not obvious when to use PUT and when to use POST. In general: – Use POST to create a resource identified by a service-generated URI – Use PUT to create or overwrite a resource identified by a URI computed by the client ● PUT expects the entire resource representation to be supplied to the server, rather than just changes to the resource state. ● 200 vs 204 – aesthetic choice ● PATCH method (introduced in 2010)– “to apply partial modifications to an [existing] resource” ● Level 2 services can be described using WADL
    16. 16. 16/44 REpresentational State Transfer – REST ● Through the years, the Web transitioned from the information publishing platform to the distributed application platform. ● REST was defined by Roy T. Fielding in his PhD dissertation Architectural Styles and the Design of Network-based Software Architectures in 2000. ● Roy Fielding is a co-founder of the Apache HTTP Server project. ● Generalization of the Web's architecture into distributed application platform ● Classic application is a state machine with finite set of states and transitions. ● REST application is a machine with unknown states and transitions! ● When machine reaches new state, new transitions are discovered. ● Hypermedia is a generalization of hypertext
    17. 17. 17/44 Level 3 - HATEOAS ● HATEOAS - Hypermedia As The Engine Of Application State ● Application state is inferred by the consumer based on the state of all the resources – potentially distributed across many services – with witch the consumer is currently interacting. ● Domain Application Protocol (DAP) specifies legal interactions between the consumer and a set of resources involved in a business process. ● Services implement DAPs by adding hypermedia links to resource representations. ● There is no workflow or business logic for the DAP as such. Rather, the service governs the life cycles of particular resources. ● Each service should have a single entry point. ● JAX-RS since version 2.0 supports HATEOAS!
    18. 18. 18/44 RESTfull service example - Neo4j API ● Service root: http://localhost:7474/db/data ● When invoke $wget --header='Accept: text/html' http://localhost:7474/db/data then you get a simple introductory HTML web site ● When invoke $wget --header='Accept: application/json' http://localhost:7474/db/data then you get a JSON document with available linked resources: { "extensions" : {}, "node" : "http://localhost:7474/db/data/node", "node_index" : "http://localhost:7474/db/data/index/node", "relationship_index" : "http://localhost:7474/db/data/index/relationship", "extensions_info" : "http://localhost:7474/db/data/ext", "relationship_types" : "http://localhost:7474/db/data/relationship/types", "batch" : "http://localhost:7474/db/data/batch", "cypher" : "http://localhost:7474/db/data/cypher", "indexes" : "http://localhost:7474/db/data/schema/index", "constraints" : "http://localhost:7474/db/data/schema/constraint", "transaction" : "http://localhost:7474/db/data/transaction", "node_labels" : "http://localhost:7474/db/data/labels", "neo4j_version" : "2.1.1" } For details go to http://neo4j.com/
    19. 19. 19/44 Hypermedia formats ● Hypermedia formats: – XHTML is mainly for humans – Plain Old XML requires schema to provide meaning of tags – JSON like XML does not have a meaning (e.g. does not define a hyperlink) ● The Atom Syndication Format (RFC 4287) – XML-based format that allows software programs to check for updates published on a website. – Represents data as lists, called feeds. – Feeds are made up of one or more timestamped entries, which associate document metadata with web content ● Do not confuse the Atom Syndication Format with the Atom Publishing Protocol (AtomPub or APP, defined in RFC 5023)
    20. 20. 20/44 Example of an Atom feed <?xml version="1.0"> <feed xmlns="http://www.w3.org/2005/Atom"> <id>urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6</id> <title>Order</title> <updated>2003-12-13T18:30:02Z</updated> <link href="http://example.org/order/123" rel="self" /> <entry> <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id> <title>First product in the basket</title> <updated>2003-12-13T18:30:02Z</updated> <link href="http://example.org/order/123/item/456" /> <link rel="removeFromBasket" href="http://example.org/order/123/item/456"/> <link rel="increasePriority" href="http://example.org/order/123/item/456/priority"/> <content type="xhtml"> <div xmlns="http://www.w3.org/1999/xhtml"> <p>This is the entry content.</p> </div> </content> </entry> </feed> On what basis the consumer will know how to interpret these links?
    21. 21. 21/44 Semantics ● An application have to know how to interpret the hypermedia links ● The Resource Description Framework (RDF) is a framework for expressing information about resources. ● The information is expressed in form of a triple. The triple is a subject-predicate- object data structure, which expresses a relationship between two resources. e.g. Customer buys order. Order consists of items. ● SPARQL Protocol and RDF Query Language (SPARQL) is a query language for RDF ● RDF is a building block of the Semantic Web movement. ● RDF define logical relationships. A number of different serialization formats exist for writing down RDF graphs (e.g. Turtle, JSON-LD, RDFa, RDF/XML)
    22. 22. 22/44 Concurrency in Web Services ● When retrieving a resource with GET, server append ETag, which is a checksum of a current state of the resource ● Client should use provided Etag in any subsequent requests it directs to the same resource with If-Match tag, such request are called conditional requests ● If the resource was changed by some other client, then client would get 412 Precondition Failed. The correct thing to do is to retrieve (GET) the resource once more. ● Alternatively client can use Last-Modified tag. ● Traditionally ETags were used for cache control purposes ● When use for cache control, client can use If-None-Match tag. The primary use of it is to save computing resource, to retrieve a resource only if it has changed since last read.
    23. 23. 23/44 RESTful API description languages ● API description languages enable code generation based on API contract and vice versa ● WADL (Web Application Description Language), W3C specification: <application> <resources base=”http://service.com”> <resource path=”order”> <method name=”POST”> <request> <representation mediaType=”application/xml” element=”ord:order”/> </request> <response> <representation status=”201”/> <fault mediatType=”application/xml” element=”ord:order” status=”400”/> </response> </method> </resource> </resources> </application> ● Other popular API description languages: RAML (http://raml.org), Swagger ( http://swagger.io), API Blueprint (https://apiblueprint.org).
    24. 24. 24/44 The microservice architectural style ● To develop a single application as a suite of tiny services ● Each microservice is running in its own process, even if they run on the same machine ● Microservices communicate with lightweight mechanisms, often a HTTP resource API ● Microservices are independently deployable by a fully automated deployment machinery ● There is a bare minimum of centralized management of these services
    25. 25. 25/44 Microservices highlights ● Microservices are really small (~ 100 LOC). They should be small enough to “fit in you head”. – It is better to have more smaller services than less fat services ● Systems built of microservices are inherently loosely coupled ● Different services can be written in different programming languages and can use different data storage technologies ● Services should publish interesting information even if currently no one is interested in it – When an entity is created in a database, then it should be exposed as a HTTP resource ● You have to accept cost of massive serialization and deserialization of data ● It is possible to have multiple versions of the same service at the same time, but it should be done only if necessary.
    26. 26. 26/44 Organization around Business Capabilities ● Often developer teams are separated along technology boundaries, e.g. divided into UI team, server-side team and database team. ● Even small change in functionality requires work from each of those teams ● According to the microservice approach, teams should be organized around business capability. ● Team reorganization as a way to obtain loose coupling between components. 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
    27. 27. 27/44 Organized around Business Capabilities [© Martin Fowler]
    28. 28. 28/44 Products not Projects ● Traditionally, after a production release of a system, responsibility for the system was passed from development team to maintenance team ● To improve communication and collaboration between development and maintenance teams many companies established DevOps teams. ● According to the microservice approach, it is important to have product teams, not project teams. ● Amazon's notion of "you build, you run it", i.e. giving developers operational responsibilities. ● Substantial DevOps skills are required in development team.
    29. 29. 29/44 Smart endpoints and dumb pipes ● In many SOA applications, integration of services is centralized and consists of a set of complex rules (e.g. ESB, BPEL, WS-Choreography). ● Smart endpoints and dumb pipes approach assumes that integration is done via simple RESTfull interfaces or lightweight messaging (RabbitMQ or ZeroMQ) ● Endpoints (services) should know what to do in any situation. They know, how to react to a certain event. ● No need of God Classes or God Services. ● Intelligence should be distributed. There is no central point of orchestration ● Each µ-service subscribes to others µ-services. ● The knowledge about business process or workflow is inside the team
    30. 30. 30/44 Decentralized Data Management ● Traditionally, even if business logic is decentralized, persistent data are stored in a single logical database ● According to the microservice approach, to ensure loose coupling, each microservice has its own database (schema). ● The conceptual model of the environment differ between systems ● Polyglot Persistence - different services might use different types of database ● Microservice architectures emphasize transactionless coordination between services ● Often businesses handle a degree of inconsistency in order to respond quickly to demand
    31. 31. 31/44 Domain-Driven Design ● Domain-Driven Design (DDD) – is a set of design patterns which encourages designing software based on models of the underlying domain, even if the domain is complex and evolving ● Bounded Context – the central pattern in DDD, way of dealing with large models and teams – Traditionally, the effort was made to create a unified domain model of an organization. – In practice, total unification of the domain model for a large system is not feasible or cost-effective – Some concepts in a given bounded context are unrelated to other contexts. Others concepts are shared among multiple bounded contexts. – There is a variety of ways to describe relationships between bounded contexts – Within a given context, team members are using Ubiquitous Language – It is OK to have duplications. In short term, it can happen that in two context there will be similar abstraction. In the long run, one of them can change. ● Context map – a model of relationships between multiple bounded contexts
    32. 32. 32/44 ● Entity - an object that is not defined by its attributes, but rather by its identity. Attributes of the entity can change with time, but it is still the same entity. ● Value Object - an object that contains attributes but has no conceptual identity. They should be treated as immutable. From technical point of view it is often Data transfer object (DTO). ● Aggregate - a collection of objects that are bound together. Often the aggregate is implemented by one separate microservice. ● Aggregate root – a root entity for the aggregate. The only domain object that is exposed to the external world. All other domain objects belonging to the aggregate are hidden. It can be implemented as a public API of a microservice. More DDD concepts [Definitions based on https://en.wikipedia.org/wiki/Domain-driven_design]
    33. 33. 33/44 Infrastructure Automation ● 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 ● Automate IT system administration (e.g. release and deployment automation) – Ansible http://www.ansible.com (simple yet powerful) – Puppet https://puppetlabs.com – Chef https://www.chef.io ● Cloud platforms have reduced the operational complexity of building, deploying and operating services. ● Cloud platforms start offering autoscaling services.
    34. 34. 34/44 Design for failure ● In the monolith application, all or none components are working properly. ● In the microservice applications some component can work properly while others are in failure state. ● As a consequence, applications need to be designed so that they can tolerate the failure of services. ● Sometimes even whole data center can go down (e.g. The Christmas Eve 2012 Netflix/Amazon Outage) ● High quality infrastructure monitoring – Splunk http://www.splunk.com – Nagios https://www.nagios.org
    35. 35. 35/44 Evolutionary Design ● Microservices should be designed to support evolutionary design ● It should be possible to rewrite a microservice without affecting its collaborators ● Sometimes it is even better to replace a service with a new one then modify existing. ● Follow pattern of change, keep things that change at the same time in the same module. ● Use versioning only as a last resort. Design services to be as tolerant as possible to changes in their suppliers. ● Replaceable Component Architecture – an application should be build of components that can be independently upgraded or replaced without affecting its collaborators. ● With microservices, refactoring can be tough. If you implement two services using two different programming languages, then moving some source code from one service to another can be infeasible.
    36. 36. 36/44 Asynchronous calls ● 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: – 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): – Simple messaging via Atom feeds – Apache Kafka (http://kafka.apache.org/) - a high-throughput distributed messaging system ● The event-driven approach is a key element of reactive programming – In reactive programming, when you have a:=b+c assignment, and after that you change b or c, a will change as well
    37. 37. 37/44 Reactive Programming ● Alternative to imperative programming ● According to The Reactive Manifesto (http://www.reactivemanifesto.org), RP allows developers to build systems that are: – Event-driven – Scalable – Resilient (to software, hardware or connection failures) – Responsive (providing rich, real-time interaction with users) ● By reacting it is means to react to: – Events – Load – Failures – Users
    38. 38. 38/44 Actor Model ● Traditionally, in multi-threading application we manage sharing mutable state with synchronization. ● Drawbacks of synchronization: – It can lead to dead-lock. – It utilizes CPU inefficiently (some cores are waiting for another) – Synchronous communication couples sander and receiver ● There are solution to avoid dead-locks, but they make code much more complicated. ● It would be desired to have non-blocking objects → source code without synchronization ● Actor Model was introduced in 1973 by C. Hewitt, P. Bishop and R. Steiger in their paper A Universal Modular Actor Formalism for Artificial Intelligence ● An Actor is an object that only interacts with other objects using asynchronous message passing ● Actors are the most encapsulated form of objects ● In Actor Model blocking is replaced by queuing messages
    39. 39. 39/44 Akka Simplified API: trait Actor { def receive: Receive def sender: ActorRef } Usage: class Counter extends Actor { var count = 0 def receive = { case “incr” => count += 1 case “get” => sender ! count } } A reference to the sender of the message that is currently process by the receive method Receive is a partial function, the function that is defined only for a subset of the possible values of its arguments. operator for sending messages For details go to http://akka.io/
    40. 40. 40/44 Microservices deployment ● Microservices should be containerless (shipped with embedded container) ● They should not be deployed to application servers (like JBoss, WebSphere or WebLogic) but should be distributes as ready-to-be-run software packages – Docker (https://www.docker.com) is an open platform that supports this approach – Microservices can be standalone UNIX services (rc.d) which are distributed as RPM’s – In case of Java apps, they can be packaged as single fat JAR (which includes all dependencies) ● Each microservice should be a separate project inside SCM (different VCS root); not submodule of multimodule project – Keeping as separate projects enforces loose coupling. – It is acceptable to have some common source code, but only infrastructure or management code, not domain or business logic code.
    41. 41. 41/44 Analogy to UNIX pipes ● There is an analogy between the microservice architectural style and Unix utilities. ● Write programs that do one thing and do it well ● Write programs that handle text streams, because text is a universal interface ● One can pipe multiple UNIX commands, e.g. $cat test.txt | grep “come content”
    42. 42. 42/44 Microservices drawbacks ● When your application is build of many simple services then complexity is hidden in connections between them. ● Implementing use cases that span multiple services without using distributed transactions is difficult. ● Writing automated tests that involve multiple services is challenging. ● The microservice architecture also introduces significant operational complexity.
    43. 43. 43/44 Bibliography ● R. Fielding, Architectural Styles and the Design of Network-based Software Architectures, Doctoral dissertation, University of California, Irvine, 2000 ● L. Richardson and S. Ruby, RESTful Web Services, O’Reilly Media, 2007 ● J. Webber, S. Parastatidis, I. Robinson, REST in Practice: Hypermedia and Systems Architecture, O'Reilly Media, 2010 ● C. Hewitt, P. Bishop, R. Steiger, A Universal Modular Actor Formalism for Artificial Intelligence, IJCAI, 1973 ● Architecture of the World Wide Web, W3C, http://www.w3.org/TR/webarch ● J. Lewis, M. Fowler, Microservices, http://martinfowler.com/articles/microservices.html ● M. Fowler, Service Oriented Ambiguity http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html ● Netflix OSS, http://netflix.github.io ● E. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2004
    44. 44. 44/44 Thank you!