Building Applications Across The Enterprise And Cloud Using Mule Presentation

Editor's Notes

• #4: 2 stages of evolution1st developer agility…2nd business agility…Architectural equivalent of discovering fireSOA, virtualization, SAAS, eventually cloud computing –the platform for all of these things
• #5: Point to Point IntegrationHome grown messaging abstractionRPC onlyHand coded 3rd party integrationHand coded security, monitoring and management
• #6: Picture of Legacy System Architecture
• #7: Picture of Clouds. Discuss what it is and implications Hosting, B2B..SAAS..Virtualization..SOA..IT Oursourcing..P2P…Web 2.0Realization that finally, the network is the computerMeans to deliver service (talk about later infr, platform, app)What’s New about Cloud – self service management, elastic scalingRole of SOA - shapes how you deliver and leverage services in the cloud
• #8: Examples of new types of reusable servicesInfrastructure (IAAS) – AWS, GoGrid, Mosso, Euclyptus, 3Tera, NirvanixPlatform Stack (PAAS) – Force.com, Google AppEngine, MS AzureApplicationBusiness Services (SAAS) – Billing, CRM, Payment, AdvertisingUtility Services - Communication, Data Processing, Doc Mgmt, SecurityInformation Services – Real Time Data, Historical Data, Search
• #10: Challenge - What to do about existing investments in your Enterprise Architecture?If you already have a SOA and are using virtualization in the data center, then you are probably in good shapeIf not, you’ll need to take baby steps while you address your architecture – start with specific projects – possibly new ones that can benefit from the cloudInvestments in datacenter – public and private clouds – redeploy your existing assets into a private cloud. Already using virtualization, this will be easier
• #11: You are handing over the keys to someone else. Loss of control / choiceSLAs can be very different, also viabilityWith AWS - 1 of 60,000 customersAWS offers 99.95% SLA and offers service credits in return Definition of outage is very convoluted. You are especially exposed if customer < 1 yearCustomer must prove the outage within 30 days without help from AWSCredit is to future service, not reimbursement of lost serviceS3 went down for several hours, no data was loss but many websites were shut down until it recoveredAlternatively, 3Tera automatically monitors outages and credits you back for themSLAs are nice, but don’t help recover business loss do to an outage.StorageNo protection necessarily for example if FBI were to raid another company’s data that resided on the same disk as yours that yours would not be takenPatriot Act protectionWhat if provider went under, could you get your data bacK?
• #12: secure multi-tenancy for storage not quite there yet, encryption is not standardManageability – tools are still very immature and no real standard across service providersReliability /Availability – need to vet service provider – SLA, viability, location of datacenters, reliance on any other service providerGovernance – can be much more difficult to ensure complianceCompatibility – few standards except at protocol level (what Mule leverages). Data formats very proprietary (Mule can help some)Self Service, quick to market, elastic scale up and down, pay per use
• #14: Picture of Legacy System Architecture
• #15: Picture of Legacy System Architecture
• #16: Picture of Legacy System Architecture
• #19: EXPAND THISCan you EA adapt to it? If not private, small projectDo services represent business granularityWhat are your security / compliance requirements?New or Legacy AppIntegration Points / CouplingProtocols, Apps, Data independentScalability requirements – elastic or potentially fast growthCore vs ContextESB selection checklist –more than one type of communication protocol? not going to get any of the benefits if cross protocol messaging and transformation that Mule provides.publish services for consumption by other applications? This is a good fit for Mule as it provides a robust and scalable service containermore than 10 applications to integrate? Avoid big-bang projects and consider breaking the project down in to smaller parts. Pilot your architecture on just 3 or 4 systems first and iron out any wrinkles before impacting other systems.need the scalability of an ESB? It’s very easy to over-architect scalability requirements of an application. Mule scales down as well as up making it a popular choice for ‘building in’ scalability. However, there is a price to be paid for this since you are adding a new technology to the architecture.what do you want to achieve with your architecture? Vendors often draw an ESB as a box in the middle with lots of applications hanging off it. In reality, it does not work like that. There is a lot details that need to be understood first around the integration points, protocols, data formats, IT infrastructure, security etc. Starting small helps to keep the scope of the problem manageable. Until you understand your architecture and scope it properly you can’t really make a decision as to whether an ESB is right for you.
• #23: App/SAASVet service providers match needs of new applicationMule has connectors for some SAAS. New ones are very easy to createPrototypeDeployScale
• #24: Use virtualization to scale out existing apps into the cloud - IAASControl, Core - Consider Private Context - PublicMule can provide location transparencyWeb protocols allow to continue to talk to internal systemsMule can Proxy even if apps don’t speak web servicesSecure communicationBuilding new appsChoose IIAS or potentially PAASMule can integrate with GAE, Force.com and others via REST or SOAP web servicesRun Mule inside enterprise and in cloud or embedded in appSimple, L/W allows easily cloud provisioning tools and services
• #26: Applications are no longer silos with expensive PTP integrationCloud computing can only be done effectively in concert with SOAMule can bridge the gap between enterprise and cloud architectureFollow a simple checklist to decide if cloud is the right approach for your app