Breaking Apart the Monolith with Modularity and Microservices CON3127

Size: px

Start display at page:

Download "Breaking Apart the Monolith with Modularity and Microservices CON3127"

Evelyn Jordan
5 years ago
Views:

1 Breaking Apart the Monolith with Modularity and Microservices CON3127 Neil Griffin Software Architect, Liferay Inc. Specification Lead, JSR 378 Portlet 3.0 Bridge for JavaServer Faces 2.2 Michael Han Vice President of Operations, Liferay, Inc.

2 Presenter: Neil Griffin Liferay Faces project lead Contributing Author, JSF 2.0 Complete Reference Specification Lead for JSR 378 Liferay JCP Representative JSR 362 (Portlet 3.0) JSR 372 (JSF 2.3)

3 Presenter: Michael Han Vice President of Operations Responsible for benchmarking and performance management of Liferay's product lines Senior Architect of large-scale distributed systems

4 Microservices Componentized via Independently Deployable Services Designed for Failure, not against Failure Services are Independently Scalable Great! How do I get there?

5 Modularity What do we mean when we use the word modularity? Standards for modularity in Java: JSR 376: Java TM Platform Module System (Project JigSaw) (Available with JDK 9) OSGi TM

6 Types of Modularity Several attempts have been made to define a maturity model for modularity, for example: This presentation describes three basic levels of modularity for a Java application: Level 1: Monolithic (No modularity) Level 2: Composite (Reusable dependencies) Level 3: Dynamic (OSGi)

7 Level 1: Monolithic Application The simplest way to develop a Java application is to develop a monolith Single artifact that contains a large compiled codebase WEB-INF/classes/ CustomerService.class CustomerServiceImpl.class ProductService.class ProductServiceImpl.class PurchaseService.class PurchaseServiceImpl.class.war

Demo & Code Review: Monolith Drawbacks: Services are not reusable outside the application Service API cannot be versioned on its own release schedule All classes are loaded into the same

8 Demo & Code Review: Monolith Drawbacks: Services are not reusable outside the application Service API cannot be versioned on its own release schedule All classes are loaded into the same servlet context ClassLoader No boundaries between the It works! application, Service API and Service Implementation Class.forName( com.liferay.store.monolith.customer.service.customerserviceimpl )

9 Level 2: Composite Applications.jar.jar In order to overcome the drawbacks of a monolith, develop a composite application.jar.jar Package services into separate.jar artifacts.war Include each.jar as an embedded dependency

10 Build Tools MavenTM Build tools like Maven or Gradle can help to achieve the goal of having independently versioned artifacts GradleTM Each artifact can be on an independent release schedule Artifacts can be published to an artifact repository like Maven Central

Demo & Code Review: Composite Benefits: Minimal code in WEB-INF/classes Versioned services can be embedded as dependencies Drawbacks: All classes are still loaded into the same servlet context

11 Demo & Code Review: Composite Benefits: Minimal code in WEB-INF/classes Versioned services can be embedded as dependencies Drawbacks: All classes are still loaded into the same servlet context ClassLoader Not designed to anticipate failure Still no boundaries between the application, It still works! Service API and Service Implementation Class.forName( com.liferay.store.monolith.customer.service.customerserviceimpl )

12 Level 3: Dynamic Modularity bundle.jar bundle.jar In order to overcome the drawbacks of a composite application, develop a dynamic modular application Package services into separate.jar artifacts bundle.jar bundle.jar wab.war OSGi Runtime Deploy each.jar as an OSGi bundle that runs in its own ClassLoader

13 OSGi OSGi is an open standard that achieves the goal of modularity for Java Modules are defined as simple.jar artifacts called OSGi bundles Each bundle runs in its own ClassLoader Bundles communicate via services that are published in the OSGi service registry

14 OSGi Implementations OSGi core framework implementations are available in open source Popular Core Framework Implementations: Felix (Apache) Equinox (Eclipse)

15 OSGi Bundles OSGi bundles are plain old JAR files that contain OSGi Bundle additional information in META-INF/MANIFEST.MF Manifest-Version: 1.0 Bundle-SymbolicName: com.liferay.store.customer Export-Package: com.liferay.store.customer.model;version="1.0.0",com.l iferay.store.customer.service;uses:="com.liferay.store.customer.model ";version="1.0.0" Bundle-Name: com.liferay.store.customer Bundle-Version: 1.0.0

$Bundle API The API of an OSGi bundle is defined at the -exportcontents: \ com.liferay.store.customer.model, \ com.liferay.store.customer.service bnd.$

16 Bundle API The API of an OSGi bundle is defined at the -exportcontents: \ com.liferay.store.customer.model, \ com.liferay.store.customer.service bnd.bnd (source) level of Java packages Manifest-Version: 1.0 Bundle-SymbolicName: com.liferay.store.customer Export-Package: com.liferay.store.customer.model;version="1.0.0",com.l iferay.store.customer.service;uses:="com.liferay.store.customer.model ";version="1.0.0" Bundle-Name: com.liferay.store.customer Bundle-Version: MANIFEST.MF (generated)

17 OSGi Services OSGi bundles communicate with each other via services made available by dependency injection Services are published in the OSGi service registry OSGi (service (dependency injection) OSGi (service consumer)

18 Bundle Dynamism Since OSGi bundles are dynamic (can be deployed and un-deployed dynamically), services can come and go at any time Programing for Failure: Declarative Services Service Tracker

19 Dynamism is a Familiar Concept tomcat/webapps/ context-1/ The Servlet Specification requires that the classes for each webapp (servlet context) be loaded into its own ClassLoader This offers a degree of dynamism: Copy the.war to tomcat/webapps to deploy Delete the webapp context to un-deploy Copy the.war to tomcat/webapps to re-deploy.war context-2/ context-n/

Service API, and Service No embedded service Implementation Modules are dynamic (can come and It doesn t

20 Demo & Code Review: Dynamic Benefits: Minimal code in WEB-INF/classes Versioned services can be deployed as OSGi bundles Each bundle runs in a separate ClassLoader Strict boundaries between the application, Service API, and Service No embedded service Implementation Modules are dynamic (can come and It doesn t work! jars! go at any time) Class.forName( com.liferay.store.monolith.customer.service.customerserviceimpl )

21 OSGi Compared to CDI/Spring OSGi: Services and injectable dependencies are discovered by the build-time system and satisfied at deploy time service implementation service dependency service = true, service = PurchaseService.class) public class PurchaseServiceImpl implements PurchaseService { private CustomerService private ProductService productservice;... bnd-maven-plugin Spring/CDI: Services and injectable dependencies are discovered and satisfied at deploy time by classpath scanning

22 Step 1: In-JVM Microservices OSGi runtimes can contain numerous bundles in a single JVM which can be referred to as In-JVM microservices Benefits: Although you program for failure, it does not have the drawbacks of a distributed system Bundles and service APIs are strictly versioned Bundles will NOT be activated at deploy time unless all service dependencies can be satisfied Direct method invocations and POJOs rather than invoking remote services and processing JSON or XML Less vulnerable to security attacks since service invocations do not go across the network Drawbacks: Heavily utilized services can cause a performance impact on other services since they are in the same JVM

23 Step 2 Distributed OSGi Publish services as remote services Add service properties: service.exported.interfaces, service.exported.configs Service Consumers have no knowledge whether service is remote or not See Apache CXF DOSGi and Eclipse ECF

24 Step 3 Microservices Platform Runtime Platform Must Provide Service Fault Tolerance Auto Scaling Platform Services Centralized Log Management Centralized monitoring Meso, Kubernetes, CloudFoundry, WeDeploy, etc

25 Case Study: Liferay Digital Enterprise Liferay Portal 6.2 CE and EE Web Content Management, Document Management and Collaboration, Workflow and Forms etc Proprietary WAR based modular system for extensions Liferay Portal 7.0 and Digital Enterprise Subsystems: WEM, Collaboration, Forms and Workflow, Platform 500+ modules (JAR)

26 Case Study: Liferay DXP Next Steps Implemented Distributed OSGi Runtime Integrate Distributed OSGi Runtime into PaaS Platform Wedeploy.com Liferay s PaaS Platform Kubernetes, OpenShift, CloudFoundry

27 Semantic Versioning com.mycompany.mybundle jar major.minor.patch com.mycompany.mybundle jar major = breaking changes minor = new feature release com.mycompany.mybundle jar patch = bug fixes Minor & patch versions are guaranteed to be binary backward compatible!

28 Semantic Versioning (Reporting) Reporting and enforcement of semantic versioning rules can be accomplished with the help of Bndtools at build-time mvn bundle:baseline maven-bundle-plugin

29 Thank You Liferay and Liferay Faces are trademarks or registered trademarks of Liferay, Inc. Java Community Process and JCP are service marks of Oracle Corporation in the United States and in other countries Java, Java EE, JavaOne, JVM, and JavaServer are trademarks or registered trademarks of Oracle Corporation in the United States and in other countries OSGi is a trademark of The OSGi Alliance Apache Maven is a trademark of The Apache Software Foundation "Tomcat" is a registered trademark of the Apache Software Foundation. "Apache Tomcat" and the Apache Tomcat project logo are trademarks of the Apache Software Foundation. Gradle is a trademark of Gradle, Inc. in the United States and/or other jurisdictions Payara is a trademark of Payara Services Limited and all its affiliates Spring Boot is a trademark of Pivotal Software, Inc. in the U.S. and other countries All other trademarks mentioned herein are the property of their respective owners

Modularity in Java. With OSGi. Alex Docklands.LJC January Copyright 2016 Alex Blewitt

Modularity in Java. With OSGi. Alex Docklands.LJC January Copyright 2016 Alex Blewitt Modularity in Java With OSGi Alex Blewitt @alblue Docklands.LJC January 2016 Modularity in Java Modularity is Easy? Modularity is Hard! Modularity is Hard! Modularity is Hard! Modularity is Hard! Modularity