Mission-Critical Enterprise/Cloud Hybrid Applications

Transcription

1 This presentation is available for download from: Mission-Critical Enterprise/Cloud Hybrid Applications Eugene Ciurana Open-Source Evangelist SOBA Labs

2 Legal All products and services mentioned herein as well as their logos are trademarks or registered trademarks of their respective companies. Data contained in this presentation serves informational purposes only. The case studies in this presentation are based on work performed at public and private companies in the last 18 months. Some names were changed to protect the innocent. Enjoy the show!

3 About Eugene years building mission-critical, high-availability systems 14+ years Java work Open source evangelist Official adoption of open source/linux at Walmart worldwide Trailblazing Hadoop, mongodb, Mule deployments State of the art tech for main line of business roll-outs Largest companies in the world Retail Finance Oil Background: robotics to on-line retail

4 This presentation is about... How to design, implement, and roll-out cloud/enterprise hybrid applications Different cloud architectures PaaS SaaS Private clouds Technologies: ESB, clouds, mini-clouds, Java, App Engine, Chef!/Puppet, etc. How cloud technologies lower costs Understanding the advantages of: Cloud deployments Hybrid deployments distributed in the cloud and enterprise Hybrid deployments involving Java and non-java systems

5 What You ll Learn Identify the applications best suited for cloud deployments Identify the advantages of Platform-as-a-Service or Software-as-a-Service resources Learn the caveats of cross-platform and cross-language integration Learn about high-performance alternatives to XML serialization for data exchange Learn how to structure event-based, stateless apps for maximum scalability

6 What is the Cloud Anyway? Ask 10 different people, get 10 different answers In general, you may use 4 types of cloud offerings Platform as a Service Software as a Service Infrastructure as a Service Private clouds Some times you integrate pre-fabricated apps, some times platform, some times both

7 Cloud Services Features Quick deployment of prepackaged components Uses commodity, virtualized hardware and network resources Amazon Elastic Cloud 2 (EC2) and Simple Storage Service (S3) Google App Engine (Python, Java) Rackspace Cloud Services The overall model is pay as you consume Horizontal scalability is achieved by adding or removing resources as needed May host full applications or only services

8 Cloud Services Features Public clouds could replace the data centre Basic administration moves to the application owner It may move away from the IT team - political fallout For the bean counters... it s an operational expense! Tax advantages Turn on or off as needed In a tight economy, IT infrastructure ends up under the CFO - give the guy options Assuming sensible SLAs, the ROI is better than for colocated or company-owned data centres

9 What do scalability and high-availability mean? Scalability: the property of a system to handle bigger amounts of work or to be easily expanded in response to increased demand Vertical Horizontal Scalability and High Availability Load Balancer Virtual Node 2 Virtual Node 3 Node Node Node Virtual Node 1 Virtual Node 2 Scales out Scales up Virtual Node 1 Virtual Node 0 Virtual Node 0 Load Balancer Dual Core Single Processor 16 GB RAM Dual Core Dual Processor 32 GB RAM Node Node Node Node

10 Scalability and High Availability Availability: how the system provides useful resources over a set period of time Uptime!= availability Many factors affect it: network, storage, processor, etc. Availability Downtime 90% 36.5 days 99% 4 days 99.9% 9 hours 99.99% 53 minutes % 5.3 minutes % 32 seconds Amazon S3 Outage (summer 2008) Major companies affected (LeapFrog, ebay, Apple, many others) Amazon s SLA? Sorry - it won t happen again. Can you afford this?

11 SLAs and Availability Service Level Agreements drive the architectural and technological decisions Cloud systems scalability characteristics are often pitched What is the availability? What is the impact on business? How do you perform disaster recovery? What service level are the vendors offering? The higher the availability (3-nines, 4-nines, 5-nines), the higher the cost Co-lo, data centre deployments still make more sense for 4- nines availability and above

12 A Hybrid Cloud Architecture Many mission-critical systems will live behind the corporate firewall The cloud is used for high-load applications and services The clouds applications work independently of the data center applications, and vice versa Loose coupling over web services Assume that the data in the cloud is throwaway - it s either consolidated or sourced in the data centre The cloud exists mostly for distribution and scalability

13 A Hybrid Cloud Architecture Amazon S3 Google App Engine Datastore Datastore PNG PNG PNG PNG Node Node Node PNG PNG PNG PNG Node Node Node User Firewall services.company.com Enterprise Service Bus Node Node Node Node Legacy Back-end Enterprise Database

14 Which Parts Go To The Cloud? Internet Load Balancer Application Server Tomcat 6 Services Proxy Application Server Tomcat 6 Load Balancer - Backbone Backbone - message filtering, routing, dispatching, queuing, events Mule ESB Mule ESB Mule ESB Mule ESB Load Balancer - Tailbone Load Balancer - Funnybone Load Balancer - Message Broker Mule ESB SOAP, REST Mule ESB SOAP, REST Mule ESB servlet, MTOM Mule ESB servlet, MTOM ActiveMQ ActiveMQ Database NFS share NFS share

15 Which Parts Go To The Cloud? Depending on the cloud configuration, load balancing may not be necessary Amazon provides Elastic Load Balancers and Elastic IP Google App Engine provides stateless calls only The client itself or Memcache keep state instead Rackspace provides either elastic addresses or explicit load balancers Enterprise Service Bus and other integration may exist in both the cloud and the data centre Message routing is OK is if latency is below the SLA requirements Strategic partner, application, and services integration may occur 100% on the cloud, with data consolidation behind the firewall

16 Case Study Large consumer and services company.net / Windows servers infrastructure Java, ASP.Net, PHP SQL Server Two-tier architecture The system just grew and became a business Server pages, services, media 6-month scalability project began in April Implementation complete 25.Sep of the same year

17 Case Study - Objectives Stable architecture defined by July Low cost Build scalability wherever possible Optimal data transfer rate for all properties Web systems Media properties Meet business requirements and SLAs Hard dates set by the business, no input from the technology team Milestones: 1.July, 10.Oct

18 Case Study - Initial Configuration System grew as needed - no planning Combines end-user and internal applications in the same server It only scales vertically -- and not very well Tightly coupled applications + SQL Server database Tightly coupled application servers and services Single environment: from development to production without passing Go nor collecting $200 Disaster recovery? 4 hours minimum From (stale?) backups

19 Case Study - Phase I Scalability

20 Case Study - Phase I Scalability Introduces a CDN for asset delivery Amazon S3 (optional Cloud Front) for asset delivery Reduces load on company servers and bandwidth costs Introduces database replication for production environments Introduces NoSQL storage for write-once, consult-often structured documents Establishes a continuous integration environment Set tools for hybrid UNIX/Windows environment UNIX tools take precedence; Cygwin everywhere Improved build/release process

21 Case Study - Phase I Scalability Browser Various services RSS providers throughout Service Service End Users Outlook the Internet. Some Consumers CWS Providers are public, some are EWS partners Legend HTTP SOAP Custom RPC ODBC/JDBC Direct/API Heavy web services Some XML, some custom Internal Service Providers query reply Search Netezza Lucene Rich Docs (GridFS) Static Files (S3) Firewall Main App CRM Client Relationships App Queue update Internal End Users End Users Dispatcher Custom Queuing System Service Consumers Reporting

22 Case Study - Phase I Scalability Fail-over with traditional database replication techniques Primary Cluster Node 0 Node 1 ESB as app services provider Partition 0 Partition 1 DB 0 DB 1 DB 0b DB 1b

23 Case Study - Phase II Cloud Deployment

24 Case Study - Phase II Cloud Deployment Web applications move to a uniform technology All critical infrastructure moves to Java Separation between end-user and services applications The database and stored procedures are normalized and optimized Applications use common resources via Mule ESB and services No more direct calls from apps to databases Business logic is implemented as stateless POJOs Software stack is best of breed Windows, other servers driven by business requirements Open source software wherever possible

25 Case Study - Phase II Cloud Deployment Web and other RPC services must coexist Different partners use different protocols Mule transformers take care of all the interfaces so that development may scale / continue independently of what happens in other layers Bandwidth can be expen$ive! Data exchange protocols Clients: custom, XML, JSON Images: HTTP, S3 Cloud-to-HQ: JSON, XML/SOAP HQ data centre: POJOs, JSON, BSON, XML Replication strategy: data centre

26 Phase II Cloud Deployment - Sep 2010 Service Consumers Service Providers Various services providers throughout the Internet. Some are public, some are partners End Users Browser RSS Outlook CWS EWS Cloud Firewall New System Acquisition (.Net, PHP, etc.) Internal Service Providers Tomcat App Container Main App (zone Client instance) Relations (Zone Dispatcher Manager) New Apps Static Files (S3) Mule ESB Container: Services, Message Routing, and Transformations Other New Services Local DBs, Other Resource Client Relations Services Rich Documents (GridFS) Dispatcher Services Reporting Main App Services Corporate Firewall OpenMQ Search cron Services m e m c a c h e d Enterprise Services Databases End Users Legend: HTTP Web services (SOAP, REST, JMS, other) JDBC Direct/API/Any

27 Phase II: Hybrid Dev Tools Excellent class library Excellent 3rd party support Great for writing robust apps Java Static Typing Verbose Faster Execution Time Slower Compile/Build/Test/Deploy Cycle Slower Development Time Harder to read? Python Dynamic Typing Concise Slower Execution Time Faster Develop/Deploy Cycle Faster Development Time Easier to read? Java and Python Coexist in Tomcat, Mule, and Spring!

28 Phase II: Hybrid Dev Tools Coding time reduced by at least 50% Developers are fluent in Java and Python Source code reduced by 30% to 75% Algorithmic code saw the least reduction Regular code + API calls average 50% Development/testing cycles reduced from 25% to 50% Save/test vs. save/build/package/deploy/stop/start Can use with or without OSGi Language features help to come up with fresh approaches to problem solving Development Speed Python Java C C Execution Speed Java Python

29 Case Study - Phase III Q1 2011

30 External Service or Consumer Phase III Data Mining - Q Internal Services Tomcat App Container Main App (zone Client instance) Relations (Zone Dispatcher Manager) New Apps Static Files (S3) Mule ESB Container: Services, Message Routing, and Transformations Other New Services Client Relations Services Dispatcher Services Main App Services OpenMQ cron Services m e m c a c h e d Rich Documents (GridFS) Reporting Pig Search Hive Databases HDFS, GridFS, Data Warehouse Hadoop, DB cluster, computational network Cloud-based MapReduce/NoSQL Infrastructure - expand and contract capacity as-needed

31 Phase III: System Architecture Q Three classes of servers. Services and applications are enabled through configuration changes, not software changes. Every server in a given class gets the same exact software. Services Provider Each server runs in its own virtual machine. Services can be combined. Spring DMZ reverse proxy, Apache gateway :80 Client Rels Application Server Load balancer sticky sessions, fail-over, 80:8080 Flex Dispatcher PD 4 ML Main App App server configuration web.xml Hbrnte Mule Client $APP $FRM WORK Internal Features Server Reporting Search PD Spring Flex 4 Hbrnte ML 3rd Party Service App server configuration web.xml Mule Client $FRM WORK Spring DMZ reverse proxy, Apache gateway :80 Client Rel Services Hbrnte Dispatcher Services $FRM WORK Main App Services GridFS jtds ORCL v.4 Mule Services Container $APP Services App server configuration mule-config.xml HTTP Transport Load balancer stateless round robin, 80:8080 RPC Transport SQL Data Srce $OTHER Transport $FRM WORK Tomcat Application Container ulimit configuration Tomcat Application Container ulimit configuration JMS Container (OpenMQ, ActiveMQ, other) ulimit configuration memcached Java 6 or later Java 6 or later memcached Java 6 or later Unique TCP/IP networking configuration Config mgmt: Puppet, SOBA, Chef! Linux (CentOS, Ubuntu Server) Unique TCP/IP networking configuration Config mgmt: Puppet, SOBA, Chef! Linux (CentOS, Ubuntu Server) Unique TCP/IP networking configuration Config mgmt: Puppet, SOBA, Chef! Linux (CentOS, Ubuntu Server) Hosting Hypervisor (EC2, VMware, Xen) Hosting Hypervisor (EC2, VMware, Xen) Hosting Hypervisor (EC2, VMware, Xen)

32 Phase III: System Administration Ubuntu Landscape REST SOBA interface - implementation is transparent to caller! sobadb sobaengine localhost Other Consumer REST SOBA interface EC2 web services API Xen XML-RPC API Amazon EC2 Xen Host End-user App ami-322ec65b End-user App ami-322ec65b F i r e w a l l Oracle vm_uuid: b220c8db Xen Python SOBA Python SOBA Agent

33 Phase III: System Administration SOBA Data mongodb Config Data (Puppet?) CANONICAL Landscape web services JSON R E S T R E S T Other Application easy integration! JSON Mule-based SOBA Engine abstracts provisioning, configuration, and monitoring through web services Java and Python Web Services Interface web services SOBA Engine Python API dict dict Python Native Application easy integration! EC2 web services API XML EC2 Query Xen XML-RPC API XML R E S T JSON SOBA Agent dict Python JSON R E S T DRY Interface Don't Repeat Yourself! EC2 Data amazon EC2 API Ubuntu Server puppet facter SOBA Agent Xen Server API puppet facter Ubuntu Server Ensemble Agent Rackspace Cloud Servers API Ubuntu Server puppet facter SOBA Agent Provisioning, configuration or monitoring via SOBA is the same regardless of target: Same API call, same data payload, same data format, etc. Implementation is abstracted from the caller!

34 Thanks for Coming! Wanna know more about real life cloud, scalable systems? Subscribe to the newsletter! technology tweets Questions? Eugene Ciurana Open source evangelist