SlideShare a Scribd company logo

Carbon 5 : A Preview

•
•
Sameera Jayasoma
Sameera Jayasoma

Carbon 5 is the next generation of the WSO2 Carbon middleware platform. It has been re-architected using microservices and containers to improve modularity, scalability, and multi-tenancy. Key changes include moving from Apache Axis2 to a lightweight OSGi-based kernel, using Kubernetes for container orchestration instead of Stratos, and releasing initial products like the Microservices Server and Gateway built on this new kernel. The first general availability release of Carbon 5 and these products is planned for December 2015.

Related slideshows

Multitenancy in WSO2 Carbon 5 (C5)
Multitenancy in WSO2 Carbon 5 (C5)Multitenancy in WSO2 Carbon 5 (C5)
Multitenancy in WSO2 Carbon 5 (C5)
 
Deploying WSO2 Middleware on Mesos
Deploying WSO2 Middleware on MesosDeploying WSO2 Middleware on Mesos
Deploying WSO2 Middleware on Mesos
 
Containers in production with docker, coreos, kubernetes and apache stratos
Containers in production with docker, coreos, kubernetes and apache stratosContainers in production with docker, coreos, kubernetes and apache stratos
Containers in production with docker, coreos, kubernetes and apache stratos
 
1 of 23
Download to read offline
Carbon 5 : A Preview Next-generation WSO2 Carbon Platform Sameera Jayasoma Software Architect WSO2
Carbon 5 (C5) • Next-generation WSO2 Carbon platform. • Completely re-architected to keep up with the technology changes. • Light-weight Carbon kernel providing a componentized server development framework. • To provide a streamlined and even more powerful middleware platform than ever. • Supports multi-tenancy and autoscaling
Why C5? • Carbon 4.x and previous versions enabled us to build an enterprise-grade middleware platform with 20+ products to date. • Started way back in 2008, Carbon revolutionized WSO2’ s middleware space. But it’s time to make a change. why?
Why C5?... • Common message model is SOAP Infoset • XML is more native than JSON. • Tight coupling with, • e.g. Apache Axis2, • Apache Synapse. • Server building concepts are from Axis2. Removing these couplings is not easy, hence require a Major release of the Carbon platform and it will not be compatible with previous releases. • In-JVM multitenancy is not optimal for runtime isolation.
History of Carbon
Carbon Platform Releases • Carbon Product = Subset of platform features + Carbon kernel. • All products belong to a single platform release are compatible with each other. • Platform releases are named after Turing award winners. e.g. next carbon platform is called Hamming.
Carbon Platform • OSGi and P2 gives modularity and composability to the platform. • Carbon Kernel - base runtime. • Set of core features for middleware products. • Middleware features • Carbon products as packaged collections of features
Carbon Kernel - 5.0.0 • Light-weight base runtime for the next generation WSO2 Carbon Platform. • Modularity and composability are inherited from OSGi : Dynamic module system for Java and Equinox P2 (Provisioning platform for OSGi based applications) • Carbon Kernel features • Composable Server Architecture • Transport Management • OSGi Startup order resolver • Artifact Deployment Engine • Managed runtime model.
Carbon Kernel Architecture
Composable Server Architecture Souce: https://en.wikipedia.org/wiki/Composability
Composable Server Architecture... • Composable middleware system vs “Suite” of products. • provides a consistent solution to cross-cutting functions, usability, manageability etc. • Benefits of adopting OSGi + P2 . • Carbon Feature Plugin. • To build features, products, products with multiple profiles, mix-and-match components, etc.
Managed Transports • Transports in a Carbon based product can be managed centrally. • Maintenance mode concept to handle upgrades. • New transports can be plugged in easily. • Implement the org.wso2.carbon.kernel.transports.CarbonTransports interface and register it as an OSGi service at runtime. • Start all the transports once all the transport services are available and once the server is ready to serve requests.
Managed Transports...
Artifact Deployment Engine • Manages the artifact deployment in Carbon based products. • Scheduler : Responsible for the scheduling the deployment tasks periodically. • Repository Scanner : Scans deployer directories for artifact updates. • DeployerServiceListener : An OSGi service component, which listens to deployer registrations/unregistrations from other components (CustomDeployers) at run-time. • Periodically checks the repository for changes and invoke relevant deployers
Startup Order Resolver • Startup order resolving mechanisms in OSGi. • In Carbon, these standard mechanisms are not enough. • Intra-component dependencies • e.g. all transports need to be initialized only when all of them are ready. • Inter-component dependencies. • e.g all transports should be started after all the deployers are initialized.
Startup Order Resolver • Provided-Capability vs Require- Capability. • Declaring the capabilities provided by your bundles a. Using the Provide-Capability OSGi MANIFEST header b. Implementing the CapabilityProvider and providing it as an OSGi service
Execution Multi-tenancy with Containers • Issues with in-container multi-tenancy (in-JVM) • Isolation is very hard to achieve. One application can interfere with another application in many ways. • Even though in-container multi-tenancy claims to optimize resource utilization with higher tenant density, it has many other limitations. • Container based multi-tenancy provides true isolation compared to in-container multi-tenancy.
Docker and Kubernetes for Scalability and multi- tenancy • Not for static scale deployments without execution multi- tenancy. • C5 marries a PaaS framework for scalability and multi-tenancy • Moving away from Apache Stratos to Kubernetes as default PaaS framework • K8S namespaces for multi-tenancy • K8S elastic scaling (work in progress)
WSO2 Microservices Server 1.0.0 • A lightweight, high performance microservices runtime • One of the first products to be released with Carbon kernel 5.0.0. • Reusable lightweight micro service engine. • Multiple modes: Standalone, Server mode • Leverages Deployment engine, Transport framework and startup order resolver from kernel.
WSO2 Gateway 1.0.0 • High-performance, lightweight, and configuration-driven message gateway • Another product to be released with Carbon kernel 5.0.0. • Protocol handling layers and message processing layers are fully decoupled • Leverages the Transport framework in Kernel with support from startup order resolver. • Foundation for the upcoming series of WSO2 Gateway* products. e.g. WSO2 API Gateway, WSO2 File Gateway, WSO2 Security Gateway etc.
WSO2 Application Server 6.0.0 • App Server architecture moving from “Carbon underneath” to “Carbon as needed” • Issues in migrating from Tomcat to WSO2 AS. • Classloading complexities etc. • WSO2 AS 6.0.0 = Apache Tomcat + Libraries to leverage WSO2 Platform features. • Security, SSO, DAS integration, classloading improvements etc. • OSGified Tomcat will be available as a middleware feature for webapp hosting within a Carbon 5.0.0 runtime
Carbon Kernel 5.0.0 - Release Plan • We released alpha last week. Just before the con :) • Download alpha version from https://github. com/wso2/carbon-kernel/releases/tag/v5.0.0-alpha. • Source code is available in https://github.com/wso2/carbon- kernel/tree/5.0.x • GA will be released in December 2015 with product-mss and product-gw.
Thank You

More Related Content

Carbon 5 : A Preview

  • 1. Carbon 5 : A Preview Next-generation WSO2 Carbon Platform Sameera Jayasoma Software Architect WSO2
  • 2. Carbon 5 (C5) • Next-generation WSO2 Carbon platform. • Completely re-architected to keep up with the technology changes. • Light-weight Carbon kernel providing a componentized server development framework. • To provide a streamlined and even more powerful middleware platform than ever. • Supports multi-tenancy and autoscaling
  • 3. Why C5? • Carbon 4.x and previous versions enabled us to build an enterprise-grade middleware platform with 20+ products to date. • Started way back in 2008, Carbon revolutionized WSO2’ s middleware space. But it’s time to make a change. why?
  • 4. Why C5?... • Common message model is SOAP Infoset • XML is more native than JSON. • Tight coupling with, • e.g. Apache Axis2, • Apache Synapse. • Server building concepts are from Axis2. Removing these couplings is not easy, hence require a Major release of the Carbon platform and it will not be compatible with previous releases. • In-JVM multitenancy is not optimal for runtime isolation.
  • 6. Carbon Platform Releases • Carbon Product = Subset of platform features + Carbon kernel. • All products belong to a single platform release are compatible with each other. • Platform releases are named after Turing award winners. e.g. next carbon platform is called Hamming.
  • 7. Carbon Platform • OSGi and P2 gives modularity and composability to the platform. • Carbon Kernel - base runtime. • Set of core features for middleware products. • Middleware features • Carbon products as packaged collections of features
  • 8. Carbon Kernel - 5.0.0 • Light-weight base runtime for the next generation WSO2 Carbon Platform. • Modularity and composability are inherited from OSGi : Dynamic module system for Java and Equinox P2 (Provisioning platform for OSGi based applications) • Carbon Kernel features • Composable Server Architecture • Transport Management • OSGi Startup order resolver • Artifact Deployment Engine • Managed runtime model.
  • 10. Composable Server Architecture Souce: https://en.wikipedia.org/wiki/Composability
  • 11. Composable Server Architecture... • Composable middleware system vs “Suite” of products. • provides a consistent solution to cross-cutting functions, usability, manageability etc. • Benefits of adopting OSGi + P2 . • Carbon Feature Plugin. • To build features, products, products with multiple profiles, mix-and-match components, etc.
  • 12. Managed Transports • Transports in a Carbon based product can be managed centrally. • Maintenance mode concept to handle upgrades. • New transports can be plugged in easily. • Implement the org.wso2.carbon.kernel.transports.CarbonTransports interface and register it as an OSGi service at runtime. • Start all the transports once all the transport services are available and once the server is ready to serve requests.
  • 14. Artifact Deployment Engine • Manages the artifact deployment in Carbon based products. • Scheduler : Responsible for the scheduling the deployment tasks periodically. • Repository Scanner : Scans deployer directories for artifact updates. • DeployerServiceListener : An OSGi service component, which listens to deployer registrations/unregistrations from other components (CustomDeployers) at run-time. • Periodically checks the repository for changes and invoke relevant deployers
  • 15. Startup Order Resolver • Startup order resolving mechanisms in OSGi. • In Carbon, these standard mechanisms are not enough. • Intra-component dependencies • e.g. all transports need to be initialized only when all of them are ready. • Inter-component dependencies. • e.g all transports should be started after all the deployers are initialized.
  • 16. Startup Order Resolver • Provided-Capability vs Require- Capability. • Declaring the capabilities provided by your bundles a. Using the Provide-Capability OSGi MANIFEST header b. Implementing the CapabilityProvider and providing it as an OSGi service
  • 17. Execution Multi-tenancy with Containers • Issues with in-container multi-tenancy (in-JVM) • Isolation is very hard to achieve. One application can interfere with another application in many ways. • Even though in-container multi-tenancy claims to optimize resource utilization with higher tenant density, it has many other limitations. • Container based multi-tenancy provides true isolation compared to in-container multi-tenancy.
  • 18. Docker and Kubernetes for Scalability and multi- tenancy • Not for static scale deployments without execution multi- tenancy. • C5 marries a PaaS framework for scalability and multi-tenancy • Moving away from Apache Stratos to Kubernetes as default PaaS framework • K8S namespaces for multi-tenancy • K8S elastic scaling (work in progress)
  • 19. WSO2 Microservices Server 1.0.0 • A lightweight, high performance microservices runtime • One of the first products to be released with Carbon kernel 5.0.0. • Reusable lightweight micro service engine. • Multiple modes: Standalone, Server mode • Leverages Deployment engine, Transport framework and startup order resolver from kernel.
  • 20. WSO2 Gateway 1.0.0 • High-performance, lightweight, and configuration-driven message gateway • Another product to be released with Carbon kernel 5.0.0. • Protocol handling layers and message processing layers are fully decoupled • Leverages the Transport framework in Kernel with support from startup order resolver. • Foundation for the upcoming series of WSO2 Gateway* products. e.g. WSO2 API Gateway, WSO2 File Gateway, WSO2 Security Gateway etc.
  • 21. WSO2 Application Server 6.0.0 • App Server architecture moving from “Carbon underneath” to “Carbon as needed” • Issues in migrating from Tomcat to WSO2 AS. • Classloading complexities etc. • WSO2 AS 6.0.0 = Apache Tomcat + Libraries to leverage WSO2 Platform features. • Security, SSO, DAS integration, classloading improvements etc. • OSGified Tomcat will be available as a middleware feature for webapp hosting within a Carbon 5.0.0 runtime
  • 22. Carbon Kernel 5.0.0 - Release Plan • We released alpha last week. Just before the con :) • Download alpha version from https://github. com/wso2/carbon-kernel/releases/tag/v5.0.0-alpha. • Source code is available in https://github.com/wso2/carbon- kernel/tree/5.0.x • GA will be released in December 2015 with product-mss and product-gw.