Uploaded on

 

More in: Software , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
533
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
20
Comments
0
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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.

Transcript

  • 1. Microservices Karol Grzegorczyk June 23, 2014
  • 2. 2/42 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
  • 3. 3/42 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), but they are not 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).
  • 4. 4/42 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.
  • 5. 5/42 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.
  • 6. 6/42 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 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
  • 7. 7/42 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
  • 8. 8/42 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
  • 9. 9/42 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.
  • 10. 10/42 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
  • 11. 11/42 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]
  • 12. 12/42 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]
  • 13. 13/42 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 level one services.
  • 14. 14/42 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
  • 15. 15/42 WADL ● WADL - Web Application Description Language ● General structure: <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>
  • 16. 16/42 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/42 Level 3 - HATEOAS ● HATEOAS - Hypermedia As The Engine Of Application State ● Application state is inferred by the consumer base on the state of all the resources – potentially distributed across many services – with witch the consumer is currently interacting. ● Domain Application Protocol (DAP) specify the legal interactions between a 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/42 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" }
  • 19. 19/42 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 link) ● 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/42 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/42 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/42 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/42 The microservice architectural style ● To developing 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 an HTTP resource API ● Microservices are independently deployable by fully automated deployment machinery ● There is a bare minimum of centralized management of these services
  • 24. 24/42 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 is necessary.
  • 25. 25/42 Organization around Business Capabilities ● Often developer teams are separated along technology boundaries, i.e. 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
  • 26. 26/42 Organized around Business Capabilities [© Martin Fowler]
  • 27. 27/42 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 microservice approtach, 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.
  • 28. 28/42 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
  • 29. 29/42 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
  • 30. 30/42 Domain-Driven Design ● Domain-Driven Design (DDD) - 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 concept in the Bounded Context are unrelated to other contexts, some are shared. – There are a variety of ways to describe relationships between Bounded Contexts – Within the 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
  • 31. 31/42 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 – Puppet – Chef ● Cloud platforms have reduced the operational complexity of building, deploying and operating services. ● Cloud platforms start offering autoscaling services.
  • 32. 32/42 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 datacenter can go down (The Christmas Eve 2012 Netflix/Amazon Outage) ● High quality infrastructure monitoring – Splunk – Nagios
  • 33. 33/42 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.
  • 34. 34/42 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 - 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
  • 35. 35/42 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
  • 36. 36/42 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
  • 37. 37/42 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
  • 38. 38/42 Microservices deployment ● Microservices should be containerless (embedded container) ● Packaged as single jar, fat jar ● Microservices should be a simple UNIX services (rc.d) that invoke java -jar myservice.jar and should be distributed as rpm’s ● Each microservice is a separate project inside SCM (different VCS root); not submodule of multimodule projec ● 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.
  • 39. 39/42 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”
  • 40. 40/42 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.
  • 41. 41/42 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
  • 42. 42/42 Thank you!