Apache Stratos (incubating) provides a platform as a service (PaaS) for deploying and managing multi-tenant applications on cloud infrastructure. It includes StratosLive for self-service multi-tenant application management, App Factory for an enterprise DevOps PaaS, and the Multi-Tenant Carbon Framework. The document discusses the history and capabilities of these projects, as well as the roadmap for further developing Apache Stratos and the WSO2 PaaS offering.
Tech-Forward - Achieving Business Readiness For Copilot in Microsoft 365
Apache Stratos (incubating) on Amazon EC2, StratosLive, App Factory, and Multi-Tenant Carbon Framework
1. Apache Stratos (incubating) on Amazon EC2,
StratosLive, App Factory, and
Multi-Tenant Carbon Framework
Chris Haddad
@cobiacomm on Twitter
http://blog.cobia.net/cobiacomm
Read more about Platform as a Service (PaaS) at
http://blog.cobia.net/cobiacomm/tag/paas
2. Drivers for a new IT model
Addressing Long Tail Markets Accelerating IT Adoption
The New API-Centric WebAvoiding the Innovators Dilemma
3. When to deliver? Right Now
• Time to create a new product
– Time to design and build
– Time to complete a product trial
• Time to enter a new market
– Time to onboard local partners
– Time to create a marketing
campaign
• Time to react to market events
• Dwell time – time waiting for
the next operation to
commence or complete
4. Our PaaS Vision intersects
Connected Business Objectives
A connected business seamlessly
• integrates people, process, and data across an
extended value chain
• decreases interaction cost
• automatically adapts business activity in response to
market events
5. Connected Business Attributes
Accelerates interactions inside and
outside the organization
Reduces interaction friction and cost
Increases engagement and enhances productivity
Senses business activity
and automatically adapts
6. Technology Trends Shaping PaaS
• Rise in cloud based DevOps and ALM adaptation
• Rise in demand for hybrid cloud configurations
• Big data analysis and complex event processing in
the cloud
• Greater emphasis on required change management
and cost benefits when enterprise organizations
select aPaaS instead of CEAP
9/24/2013 6
7. Cloud Native
• Distributed/Dynamically Wired (works properly in the cloud)
• Supports deploying in a dynamically sized cluster
• Finds services across applications even when they move
• Elastic (Uses the cloud efficiently)
• Scales up and down as needed
• Works with the underlying IaaS
• Multi-tenant (Only costs when you use it)
• Virtual isolated instances with near zero incremental cost
• Implies you have a proper identity model
• Self-service (in the hands of users)
• De-centralized creation and management of tenants
• Automated Governance across tenants
• Granularly Billed and Metered (pay for just what you use)
• Allocate costs to exactly who uses them
• Incrementally Deployed and Tested (seamless live upgrades)
• Supports continuous update, side-by-side operation, in-place testing and
incremental production
12. WSO2 PaaS Offering - Key Differentiators
• A complete set of Cloud-Native middleware services
enabling complex project delivery
• Enterprise-ready foundation
– Scale, performance, SLA, integration
• Re-shapes team collaboration and reduces wait states
– Incorporates DevOps processes
– Fosters Application Lifecycle Management and Governance
best practices
• Business driven PaaS
– Lowest run-time cost
– CxO dashboards delivering portfolio visibility
– Development and DevOps dashboards presenting activity,
iterations, and project blockers
– Showback/chargeback billing9/24/2013 12
13. Stratos History
• June 2010 – Stratos 1.0 alpha and early availability of StratosLive
• November 2010 – Stratos 1.0 launched
• July 2011 – Stratos 1.5 and supported StratosLive
• January 2012 – Stratos 1.5.2
• November 2012 – Stratos 1.6
• February 2013 – Stratos 2.0 beta
• June 2013 – Stratos 2.0 Generally available
• June 2013 – WSO2 donates Stratos 2.0 Foundation to Apache
• Sept/Oct 2013 – First Apache release planned
9/24/2013 13
15. StratosLive Capabilities
• Multi-tenant management and sign-up
• Multiple levels of engagement
– demo -> enterprise
• Each tenant can manage their own user base
– Including Google Apps links or linkage to their own
LDAP
• A complete platform
– Applications, integration, business process,
eventing, data, and analytics available
9/24/2013 15
17. Stratos 2.0
• What is new?
– Cartridge model (Polyglot)
• Pluggable services
• Non-Java / Non-Carbon services
• Multiple instances of a cartridge per tenant
• Single Tenant or Multi-Tenant cartridges
– Command Line
– Git
– jclouds and support for many more IaaS clouds
– Domain Mapping
– Tenant aware load-balancer and Private Jet Mode
9/24/2013 17
20. What did / didn’t go to Apache
• In Apache
– Core framework
– Cloud Controller, Elastic Load Balancer, Stratos
Controller, etc
– Cartridges for Tomcat, MySQL, PHP
• Dependency on WSO2 open source repos:
– Carbon framework
• WSO2 add-ons
– Carbon cartridges (e.g. ESB, AS, BPS, API Manager, CEP, etc)
– Billing and Metering framework
– Logging Framework
9/24/2013 20
21. Apache Stratos Roadmap
• Support for non-HTTP load balancing
– HAProxy plugin, etc
• New architecture for auto-scaling decision making
– Support WSO2 CEP, Apache Storm, etc
– Improvements to policy
• E.g. start new instances in sync in every region
• Pure LXC cartridges
– No requirement to re-create cartridges for different IaaS
layers
• Support for deployment plans
– Multiple connected cartridges
– OASIS CAMP and/or enhancements to CAR file model
9/24/2013 21
22. WSO2 PaaS Roadmap
• Dynamic, policy based elastic sharing and resource pooling
– tenant assignment to shared and private partitions via
policy statements.
– Dynamic, policy based partitioning of private and shared
resources across tenants and services
• IT Business
– Enhance billing to demonstrate custom
showback/chargeback on all tracked elements.
– Dashboard to visually depict usage per tenant, per user,
per application, per service.
• Additional Cloud Services
– API Management as a Service offered as an aPaaS service.
– Cloud IDE
• Expansion of ecosystem community surrounding Apache
Stratos (incubating)
9/24/2013 22
30. Recommended Reading
• The Path to Responsive IT
– http://wso2.com/whitepapers/the-path-to-
responsive-it
• DevOps Meets ALM in the Cloud
– http://wso2.com/whitepapers/devops-meets-alm-
in-the-cloud-cloud-devops-paas
• Cloud-Native Advantage
– http://wso2.com/whitepapers/cloud-native-
advantage-multi-tenant-shared-container-paas
31. On-Premise SaaS
• Step 1: Setup and Configuration
– Download WSO2 Application Server
– Configure Tenants
– Setup mySQL database
• Step 2: Application Installation
– Load CarbonSaaSTest Web Application
• Step 3: Test out Multi-tenancy
– Cache, Registry, Users Management, Tenant
database
32. In-the-Cloud SaaS on PaaS
• Step 1: Create WSO2 StratosLive aPaaS account
– https://stratoslive.wso2.com
• Step 2: Configure database
– Navigate to Storage Service
– Click Relational Storage Provisioning
• Create a new database server instance
• Add Database: toolsdb
• Create database user: toolman
• Create database privilege template
• Attach database user
• Create datasource
• Step 3: Upload database
Editor's Notes
High performance architecture is rapidly changing due to three fundamental drivers:Cloud-Native Platforms - change the way we think about operational infrastructureDevOps - changes application lifecycle practicesAPIs - change how we integrate and evolve infrastructure and applications, especially Mobile apps In this session, Chris will illustrate: Why you should consider Cloud-Native architecture components in your Enterprise ArchitectureWhat is DevOps impact on App and API design guidelinesHow API-centric focus revises Enterprise Architecture
In the abstract, business agility can be defined as your ability to rapidly change business vectors. A business vector is your business speed and direction. The direction may lead into nIew markets and new products, or engaging with new participants. Reducing time to IT solution delivery increases your team’s ability to adjust the business vector and match business opportunity.With adequate instrumentation, IT delivery agility can be quantified. Consider the following agility metric recommendations:Time to create project workspaceTime to build, integrate, testTime to approve, promoteTime to deploy, releaseDwell time – time waiting for the next operation to commence or completeAfter application project inception and before coding commences, systems administrators must create project workspaces. How long does your team wait before gaining access to source code management repositories, requirement management projects, and defect tracking projects?Moving code through build, integration, and test tools is often a time and labor-intensive process. The entire team waits while applications assets are built, integrated, and tested. When teams use iterative development processes, the wait time aggregates over several hundred or thousands cycles. How long does your team wait during build, integration, and test phases?When one team member finishes a task and the work enters an approval phase, how long does the team wait? After the work is approved to move through phase gate, how long before the project is promoted into the next phase?
IntegratedAccelerates interactions inside and outside the organizationAccessibleReduces interaction friction and costCollaborativeIncreases engagement and enhances productivity AdaptiveSenses business activity and automatically adapts
A complete set of middleware services (e.g. integration, API, web services, web applications, event processing, registry, business activity monitoring)Increase team collaboration and reduce wait states by supporting DevOps processes and Application LifeCycle Management practices with Cloud run-time infrastructureCxO dashboards and delivering portfolio visibility (e.g. app/API usage, app/API spend, project pipeline) and demonstrating IT efficiency (e.g. on-time, on-budget, component/API re-use); Development and DevOps dashboards presenting activity, iterations, and project blockers.Lowest run-time cost based on in-process application platform resource sharing yielding industry-leading tenant densityTenant-aware and service-aware load balancer optimizes application platform service sharingOSGI based tenant-isolation leads to reduced application platform license (or subscription) costaPaaS auto-scale functionality reduces DevOp burden by eliminating need to explicitly define application topology- dynamic, policy based partitioning and provisioning of private and shared tenant resources- Automatic, flexible topology provisioning across private, managed, and public CloudsPresents an Application Platform Service view to development teams instead of an infrastructure detail viewBig Data Analytics and Complex Event Processing capabilities for Adaptive Business environments
Cloud platforms exhibiting Cloud Native PaaS architecture provide an opportunity to increase business innovation and creativity. Cloud native platform solutions shield teams from infrastructure details and inject new behavior into the application.Cloud native PaaS architecture requires infrastructure innovation in provisioning, service governance, management, deployment, load-balancing, policy enforcement, and tenancy. Cloud native, innovative provisioning infrastructure increases tenant density and streamlines code deployment and synchronization. Multi-tenancy within middleware containers enables teams to customize applications and services per consumer by changing run-time configuration settings instead of provisioning new instances.A Cloud platform may automate governance and enforce policies (i.e. security, service level management, usage) through enterprise PaaS services. Cloud provisioning may fulfill enterprise deployment requirements across all service providers and technologies used by solution delivery teams.To re-invent the platform and achieve benefits, new Cloud Native platform architectural components and services are required. Traditional client-server and N-tier web application architectures do not exhibit requisite cloud characteristics (i.e. elastic scalability, multi-tenancy, resource pooling, or self-service). Figure 1 below depicts the new Cloud Platform architectural components and services. The PaaS controller layer deploys, scales, monitors, and manages an elastic middleware Cloud. PaaS Foundation services provide common solution building blocks. A complete, comprehensive, and Cloud-aware middleware container layer delivers new cloud-aware capabilities to business applications.The middleware container layer should not be tightly coupled to the PaaS foundation. Acartridge or droplet pattern is used to support running any application or service container on the PaaS. By providing a cartridge plug-point, Cloud Native PaaS environments can run any language, framework, or server (after appropriate integration via the cartridge API and agents).Elastic Load BalancerElastic Load Balancer (ELB) balances load across cloud service instances on-premise or in the cloud. The ELB should provide multi-tenancy, fail-over, and auto-scaling of services in line with dynamically changing load characteristics. Cloud Native Elastic Load Balancers are tenant-aware, service-aware, partition-aware, and region-aware. They can direct traffic based on the consuming tenant or target service. Cloud Native Elastic Load Balancers manage traffic across diverse topologies (i.e. private partitions, shared partitions, hybrid cloud), and direct traffic according to performance, cost, and resource pooling policies. A Cloud Native ELB is tightly integrated with the Service Load monitor component and dynamically adjusts to topology changes. Service Load MonitorThe Service Load Monitor component acquires load information from multiple sources (e.g. app servers, load balancers) and communicates utilization and performance information to an Elastic Load Balancer responsible for distributing requests to the optimal instances, based on tenant association, load balancing policies, service level agreements, and partitioning policies. When the level of abstraction is raised above Infrastructure as a Service (IaaS) instances, Teams no longer have direct access to specific virtual machines. New Cloud Native components are required to flexibly distribute applications, services, and APIs across a dynamic topology. A Cloud Controller, Artifact Distribution Server, and Deployment Synchronizer perform DevOp activities (i.e. continuous deployment, instance provisioning, automated scaling) without requiring a hard, static binding to run-time instances.Cloud ControllerA Cloud Native Cloud Controller (or auto-scaler) component creates and removes cloud instances (virtual machines or Linux containers) based on input from the Load Monitor component. The Cloud Controller right-sizes the instance number to satisfy shifting demand, and conforms instance scaling with quota and reservation thresholds (i.e. minimum instance count, maximum instance count). The Cloud Native Cloud Controller may provision instances on top of bare metal machines, hypervisors, or Infrastructure as a Service offerings (e.g. Amazon EC2, OpenStack, Eucalyptus).Artifact Distribution ServerThe Artifact Distribution Server takes complete applications (i.e. application code, services, mediation flows, business rules, and APIs) and breaks the composite bundle into per-instance components, which are then loaded into instances by a Deployment Synchronizer. The Artifact Distribution Server maintains a versioned repository of run-time artifacts and their association with Cloud service definitions.Deployment SynchronizerThe Deployment Synchronizer checks out and deploys the right code for each Cloud application platform instance (e.g. application server, Enterprise Service Bus, API Gateway). With infrastructure and servers abstracted and encapsulated by the Cloud, a Cloud Native PaaS Management Console allows control of tenant partitions, services, quality of service, and code deployment by either Web UI or command-line tooling.Cloud Native PaaS Architecture Business BenefitsCloud Native PaaS architecture accelerates innovation, increases operational efficiency, and reduces cost.The traditional, keep-the-lights-on, operational run-rate consumes precious resources and limits innovative new projects. By optimizing project footprint across pooled resources on a shared Cloud Native PaaS infrastructure, Responsive IT can reduce operational spend, improve total cost of ownership (TCO), and make more projects financially viable. Multi-tenant delivery models create an efficient delivery environment and significant lower solution deployment cost. For more information on the financial benefits of multi-tenant, Cloud Native platforms, read the white paper.By building a Cloud Native PaaS environment, you provide your teams with a platform to rapidly develop solutions that address connected business use cases (i.e. contextual business delivery, ecosystem development, mobile interactions). Recommended ReadingA Path to Responsive ITPaaS ServicesDoes your PaaS architecture show a paradigm shift?Cloud-aware Applications and PaaS Architecture
Traditional application PaaS (aPaaS) environments do not help organizations build apps, but simply serve as a cloud run-time environment. DevOps PaaS brings no waits, faster phase execution, widespread accessibility, rapid grassroots innovation, and increased resource availability to IT projects.DevOps PaaS delivers development, test, and production run-time clouds that are integrated into development workspaces containing source code management, defect tracking, requirements management, test automation frameworks, and continuous build. Figure 2 describes the infrastructure topology underlying a DevOps PaaS.By automating software activities, workflow, and phase approval gates, a DevOps PaaS decreases software development and delivery times. A rapid IT timeframe closely matching today’s fast business-pace will accelerate revenue growth and enhance customer retention rates. A New IT model driven by DevOps PaaS will expand development team participation, lower IT cost, and increase business agility.Recommended ReadingDevOps Meets ALM in the CloudPaaS Performance MetricsMulti-tenant, shared container PaaS TCOWSO2 App Factory Product Page
When defining a roadmap to align IT’s pace with business agility expectations, establish IT team objectives that quicken IT solution development and delivery, offer new technology as on-demand shared services, and enhance your team’s ability to rapidly satisfy emerging business use cases (e.g. social collaboration, mobile application connectivity, ecosystem partnering).Open source PaaS, Open APIs, and Open Ecosystems are accelerating agility, empowering developers, and enabling innovative business strategies. In a recently published white paper, I describe how adopting a New IT plan can create a responsive IT team.The path to New IT requires moving away from traditional application platforms, traditional team structure, and traditional information flows. Responsive IT teams are adapting their infrastructure, processes and tooling to re-invent the application platform and re-think application delivery. The New IT architecture underlying Responsive IT intelligently incorporates Cloud Platforms, BigData Analytics, Enterprise DevOps, and API first development.