Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Stay Productive While Slicing Up the Monolith [...

Markus Eisele
September 20, 2016

Stay Productive While Slicing Up the Monolith [CON6472]

With microservices-based architectures, developers are left alone with provisioning and continuous delivery systems, containers and resource schedulers, frameworks and patterns to slice monoliths. How to efficiently develop them without having to provision complete production-like environments locally by hand? How to run microservices-based systems on local development machines, managing provisioning and orchestration of hundreds of services from a command-line tool without sacrificing productivity enablers. New buzzwords, frameworks, and hyped tools have made Java developers forget what it means to be productive. This session shows how much fun it can be to develop large-scale microservices-based systems. Understand the power of a fully integrated microservices development environment.

Markus Eisele

September 20, 2016
Tweet

More Decks by Markus Eisele

Other Decks in Technology

Transcript

  1. Application Server EAR - Enterprise Archive REST Mobile Web UI

    .JAR .JAR .JAR .JAR .JAR .JAR .JAR .JAR .JAR .JAR Browser RDBMS
  2. Application Server Application Server Application Server EAR - Enterprise Archive

    REST Mobile Web UI .JAR .JAR .JAR .JAR .JAR .JAR .JAR .JAR .JAR .JAR Browser RDBMS
  3. LL: Building and Scaling Monoliths • Monolithic application – everything

    is package into a single .ear • Reuse primarily by sharing .jars • A “big” push to production once or twice a year • Single database schema for the entire application • >= 500k loc • >= Heavyweight Infrastructure • Thousands of Testcases • Barely New Testcases • >= 20 Team Member • The single .ear requiring a multi-month test cycle / • Huge bug and feature databases • User Acceptance Undefined • Technical Design Approach • Barely Business Components or Domains • Requiring multiple team involvement & significant oversight • Technical Dept • Outdated Runtimes (Licenses, Complex updates) • Grown applications
  4. New requirements • Rather than acting on data at rest,

    modern software increasingly operates on data in near real-time. • Shortened time-frames for putting changes into production • New business models evolve from existing ones • New questions need to be answered by existing applications • Datacenter costs need to go down constantly
  5. Module Module Module WebUI .JAR .JAR .JAR .JAR .JAR .JAR

    .JAR .JAR .JAR .JAR Browser RDBMS RDBMS RDBMS
  6. Routing Module Tracking Module Order Module Tracker UI Browser HistoryDB

    Order DB RoutesDB Tracker UI Tracker UI Browser Browser
  7. REQ: Building and Scaling Microservices • Lightweight runtime • Cross

    – Service Security • Transaction Management • Service Scaling • Load Balancing • SLA’s • Flexible Deployment • Configuration • Service Discovery • Service Versions • Monitoring • Governance • Asynchronous communication • Non-blocking I/O • Streaming Data • Polyglot Services • Modularity (Service definition) • High performance persistence (CQRS) • Event handling / messaging (ES) • Eventual consistency • API Management • Health check and recovery
  8. “Microservices” is a lousy term • Size is irrelevant We

    want flexible systems and organizations that can adapt to their complex environments, make changes without rigid dependencies and coordination, can learn, experiment, and exhibit emergent behavior.
  9. Software Design Architecture Principles • Single Responsible Principle • Service

    Oriented Architecture – Encapsulation – Separation of Concern – Loose Coupling • Hexagonal Architecture Design Patterns • Domain-driven Design • Bounded Contexts • Event Sourcing • CQRS • Eventual Consistency • Context Maps
  10. Design Best Practices • Design for Automation • Designed for

    failure • Service load balancing and automatic scaling • Design for Data Separation • Design for Integrity • Design for Performance
  11. Strategies For Decomposing Verb or Use Case e.g. Checkout UI

    Noun e.g. Catalog product service Single Responsible Principle e.g. Unix utilities
  12. • Reactive Microservices Framework for the JVM • Focused on

    right sized services • Asynchronous I/O and communication as first class priorities • Highly productive development environment • Takes you all the way to production What is Lagom?
  13. • Event sourced (deltas) with Cassandra backend by default •

    No object/relational impedance mismatch • Can always replay to determine current state • Allows you to learn more from your data later • Persistent entity is an Aggregate Root in DDD • Can be overridden for CRUD if you want Lagom Persistence API
  14. $ cd my-first-system $ mvn lagom:runAll ... [info] Starting embedded

    Cassandra server .......... [info] Cassandra server running at 127.0.0.1:4000 [info] Service locator is running at http://localhost:8000 [info] Service gateway is running at http://localhost:9000 .......... [info] Service helloworld-impl listening for HTTP on 0:0:0:0:0:0:0:0:24266 [info] Service hellostream-impl listening for HTTP on 0:0:0:0:0:0:0:0:26230 (Services started, press enter to stop and go back to the console...)
  15. • Lagom doesn’t prescribe any particular production environment, however out

    of the box support is provided for Lightbend ConductR. • Zookeper based version: https://github.com/jboner/lagom-service-locator- zookeeper • Consul based version: https://github.com/jboner/lagom-service-locator-consul Out of the box support for ConductR but..
  16. >sbt bundle:dist ... [info] Your package is ready in /Users/myfear/lagom-cargotracker/front-

    end/target/universal/front-end-1.0- SNAPSHOT.zip Create Service bundles via sbt
  17. • Creating a bundle configuration file, bundle.conf • Creating a

    start script • Creating a Maven assembly plugin descriptor to create the bundle zip • Binding the Maven assembly plugin and Lagom renameConductRBundle goals to your projects lifecycle Create Service Bundles with Maven http://www.lagomframework.com/documentation/1.1.x/java/ConductRMaven.html
  18. Next Steps! Download and try Lagom! Project Site: http://www.lightbend.com/lagom GitHub

    Repo: https://github.com/lagom Documentation: http://www.lagomframework.com/documentation/1.1.x/Home.html Example: https://github.com/typesafehub/activator-lagom-java
  19. Written for architects and developers that must quickly gain a

    fundamental understanding of microservice-based architectures, this free O’Reilly report explores the journey from SOA to microservices, discusses approaches to dismantling your monolith, and reviews the key tenets of a Reactive microservice: • Isolate all the Things • Act Autonomously • Do One Thing, and Do It Well • Own Your State, Exclusively • Embrace Asynchronous Message-Passing • Stay Mobile, but Addressable • Collaborate as Systems to Solve Problems http://bit.ly/ReactiveMicroservice
  20. The detailed example in this report is based on Lagom,

    a new framework that helps you follow the requirements for building distributed, reactive systems. • Get an overview of the Reactive Programming model and basic requirements for developing reactive microservices • Learn how to create base services, expose endpoints, and then connect them with a simple, web-based user interface • Understand how to deal with persistence, state, and clients • Use integration technologies to start a successful migration away from legacy systems http://bit.ly/DevelopReactiveMicroservice