Microservice Architectures Dr. Andreas Schroeder 1 About me 250+ staff 12 offfices (9 in Germany) Experts for developing custom IT solutions Involvement in the IT community via • twitter Dr. Andreas Schroeder • github codecentric AG • meetup Elsenheimerstr 55A • … 80687 München andreas.de 2 Agenda • The Pain • Therefore, Microservices • Stable Interfaces: HTTP, JSON, REST • Characteristics • Comparison with Precursors • Challenges • With special focus on Service Versioning • Conclusion 3 The Pain Observed problems • Area of consideration • Web systems • Built collaboratively by several development teams • With traffic load that requires horizontal scaling (i. load balancing across multiple copies of the system) • Observation • Such systems are often built as monoliths or layered systems (JEE) 5 Software Monolith A Software Monolith • One build and deployment unit • One code base • One technology stack (Linux, JVM, Tomcat, Libraries) Benefits • Simple mental model for developers • one unit of access for coding, building, and deploying • Simple scaling model for operations • just run multiple copies behind a load balancer 6 Problems of Software Monoliths • Huge and intimidating code base for developers • Development tools get overburdened • refactorings take minutes • builds take hours • testing in continuous integration takes days • Scaling is limited • Running a copy of the whole system is resource-intense • It doesn’t scale with the data volume out-of-the-box • Deployment frequency is limited • Re-deploying means halting the whole system • Re-deployments will fail and increase the perceived risk of deployment 7 Layered Systems A layered system decomposes a monolith into layers Presentation • Usually: presentation, logic, data access • At most one technology stack per layer • Presentation: Linux, JVM, Tomcat, Libs, EJB client, JavaScript Logic • Logic: Linux, JVM, EJB container, Libs • Data Access: Linux, JVM, EJB JPA, EJB container, Libs Data Access Benefits • Simple mental model, simple dependencies • Simple deployment and scaling model DB 8 Problems of Layered Systems • Still huge codebases (one per layer) • … with the same impact on development, building, and deployment • Scaling works better, but still limited • Staff growth is limited: roughly speaking, one team per layer works well • Developers become specialists on their layer • Communication between teams is biased by layer experience (or lack thereof) 9 Growing systems beyond the limits • Applications and teams need to grow beyond the limits imposed by monoliths and layered systems, and they do – in an uncontrolled way.
• Large companies end up with landscapes of layered systems that often interoperate in undocumented ways. • These landscapes then often break in unexpected ways. How can a company grow and still have a working IT architecture and vision? • Observing and documenting successful companies (e. Amazon, Netflix) lead to the definition of microservice architecture principles.
10 Therefore, Microservices History • 2011: First discussions using this term at a software architecture workshop near Venice • May 2012: microservices settled as the most James Lewis appropriate term • March 2012: “Java, the Unix Way” at 33rd degree by James Lewis • September 2012: “µService Architecture“ at Fred George Baruco by Fred George • All along, Adrian Cockroft pioneered this style at Netflix as “fine grained SOA” http://martinfowler.com/articles/microservices.html#footnote-etymology Adrian Cockroft 12 Underlying principle On the logical level, microservice architectures are defined by a functional system decomposition into manageable and independently deployable components • The term “micro” refers to the sizing: a microservice must be manageable by a single development team (5-9 developers) • Functional system decomposition means vertical slicing (in contrast to horizontal slicing through layers) • Independent deployability implies no shared state and inter-process communication (often via HTTP REST-ish interfaces) 13 More specifically • Each microservice is functionally complete with • Resource representation • Data management • Each microservice handles one resource (or verb), e. • Clients • Shop Items • Carts • Checkout Microservices are fun-sized services, as in “still fun to develop and deploy” 14 Independent Deployability is key It enables separation and independent evolution of • code base • technology stacks • scaling • and features, too 15 Independent code base 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 16 Independent technology stacks Each service is implemented on its own technology stacks • 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 lightweight • 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. 17 Independent Scaling Each microservice can be scaled independently • Identified bottlenecks can be addressed directly Netflix • Data sharding can be applied to microservices as needed • Parts of the system that do not represent bottlenecks can remain simple and un-scaled functional decomp. Scaling Cube JEE Pet Store horizontal & vertical 18 Independent evolution of Features 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 19 Stable Interfaces – standardized communication Communication between microservices is often standardized using • 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 (more on this later) 20 Stable Interfaces: HTTP, JSON, REST HTTP Example GET / HTTP/1.de Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.8 User-Agent: Mozilla/5.36 Accept-Encoding: gzip,deflate Accept-Language: de-DE,de;q=0.1 200 OK Date: Tue, 21 Oct 2014 06:34:29 GMT Server: Apache/2.29 (Amazon) Cache-Control: no-cache, must-revalidate, max-age=0 Content-Encoding: gzip Content-Length: 8083 Connection: close Content-Type: text/html; charset=UTF-8 22 HTTP • Available verbs GET, POST, PUT, DELETE (and more) • Safe verbs: GET (and others, but none of the above) • Non-idempotent: POST (no other verb has this issue) • Mechanisms for • caching and cache control • content negotiation • session management • user agent and server identification • Status codes in response (200, 404, etc) for information, success, redirection, client error, server error • Rich standardized interface for interacting over the net 23 JSON • Minimal and popular data representation format • Schemaless in principle, but can be validated if need be Example of two bank accounts: [{ "number" : 12345, "balance" : -20.00, "currency" : "EUR" }, { "number" : 12346, "balance" : 120.00, "currency" : "USD" }] json.org 24 REST • REST is an architectural style for systems built on the web.
It consists of a set of coordinated architectural constraints for distributed hypermedia systems. • REST describes how to build systems on battle-tested protocols and standards that are already out there (like HTTP) • REST describes the architectural ideas behind HTTP, and how HTTP can be used to do more than serving static web content 25 REST Architectural Constraints • Client-Server: Separation of logic from user interface • Stateless: no client context on the server • Cacheable: reduce redundant interaction between client and server • Layered System: intermediaries may relay communication between client and server (e. for load balancing) • Code on demand: serve code to be executed on the client (e. JavaScript) • Uniform interface • Use of known HTTP verbs for manipulating resources • Resource manipulation through representations which separated from internal representations • Hypermedia as the engine of application state (HATEOAS): the response contains all allowed operations and the resource identifiers needed to trigger them 26 HATEOAS example in JSON Resource representation { "number" : 12345, "balance" : -20.00, "currency" : "EUR", "links" : [ { relation name (known by clients) "rel" : "self", "href" : "https://bank.com/account/12345" }, { "rel" : "deposit", "href" : "https://bank.com/account/12345/deposit" } ] } URI for operation 27 Stable Interfaces • HTTP offers a rich set of standardized interaction mechanisms that still allow for scaling • JSON offers a simple data format that can be (partially) validated • REST provides principles and ideas for leveraging HTTP and JSON to build evolvable microservice interfaces Be of the web, not behind the web Ian Robinson 28 Characteristics Componentization via Services • 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 30 Favors Cross-Functional Teams • Line of separation is along functional boundaries, not along tiers Presentation Logic VS Data Access DB 31 Decentralized Governance 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 32 Decentralized Data Management • 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 33 Infrastructure Automation • 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) • Consider that: • Amazon AWS is primarily an internal service • Netflix uses Chaos Monkey to further enforce infrastructure resilience 34 Comparisons with Precursors Service-Oriented Architecture ORCHESTRATION SERVICE DATA 36 Service-Oriented Architecture SOA systems also focus on functional decomposition, but • services are not required to be self-contained with data and UI, most of the time the contrary is pictured.
• It is often thought as decomposition within tiers, and introducing another tier – the service orchestration tier In comparison to microservices • SOA is focused on enabling business-level programming through business processing engines and languages such as BPEL and BPMN • SOA does not focus on independent deployment units and its consequences • Microservices can be seen as “SOA – the good parts” 37 Component-Based Software Engineering Underlying functional decomposition principle of microservices is basically the same. Additionally, the following similarities and differences exist: • State model • Many theoretical component models follow the share-nothing model • Communication model • Component technologies often focus on simulating in-process communication across processes (e. Java RPC, OSGi, EJB) • Microservice communication is intra-process, serialization-based • Code separation model • Component technologies do require code separation • Components are often developed in a common code repository • Deployment model • Components are often thought as being deployed into a uniform container 38 Challenges Fallacies of Distributed Computing 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.