Building Cloud Apps Faster with PaaS
•
6 likes•1,145 views
This document discusses building cloud applications faster using Platform as a Service (PaaS). It defines characteristics of cloud-optimized applications like multi-tenancy and elastic resource consumption. RESTful APIs are identified as the language of the cloud for loosely coupling services. Benefits of using PaaS over Infrastructure as a Service (IaaS) are lower development and deployment costs as well as application portability. The document provides examples of PaaS and SaaS services and recommends focusing on unique functionality rather than rebuilding existing services. It outlines considerations for evaluating PaaS options like supported services, deployment preferences, and application strategy fit.
More Related Content
What's hot
What's hot (19)
Similar to Building Cloud Apps Faster with PaaS
Similar to Building Cloud Apps Faster with PaaS (20)
More from Cloud Elements
More from Cloud Elements (20)
Recently uploaded
Recently uploaded (20)
Building Cloud Apps Faster with PaaS
- 1. Title one BUILDING CLOUD APPS FASTER WITH PaaS Title two April, 2013 Cloud Elements Confidential 2013
- 2. WHAT’S A REAL CLOUD APP? Cloud Elements Confidential 2
- 3. 5 CHARACTERISTICS OF CLOUD-OPTIMIZED APPLICATIONS Multi-tenancy Self-service provisioning Elastic & metered resource consumption Services-based integration Accessible from any device Cloud Elements Confidential 3
- 4. WHAT’S THE LANGUAGE OF THE CLOUD? Cloud Elements Confidential 4
- 5. RESTful APIs are the language of the Cloud Representational State Transfer (REST) APIs loosely couple IaaS, PaaS and SaaS services Participate in the “API Economy” Use the same service calls internally as externally Low friction access; well documented API calls Build applications faster by connecting services Cloud Elements Confidential 5
- 6. THE AMAZON MANDATE (PER JEFF BEZOS) − All teams will henceforth expose their data and functionality through (API) service interfaces. − Teams must communicate with each other through these (API) interfaces. − There will be no other form of inter-process communication allowed − The only communication allowed is via service interface calls over the network. − All service interfaces, without exception, must be designed from the ground up to be externalizable. No exceptions. Anyone who doesn’t do this will be fired. Thank you; have a nice day! Cloud Elements Confidential 6
- 7. WHAT PLATFORM SHOULD I BUILD ON ... IaaS or PaaS? Cloud Elements Confidential 7
- 8. WHAT IS PLATFORM-AS-A-SERVICE (PaaS)? A “cloud-aware” application development and deployment environment An abstraction layer between your cloud application and your Infrastructure-as-a-Service (IaaS) provider Fundamentally provides elastic scaling of your application Deployments include public, private and hybrid cloud configurations Cloud Elements Confidential 8
- 9. EXAMPLE: PaaS & IaaS SERVICES With the right PaaS, you also gain the freedom to change cloud infrastructure providers over-time and avoid infrastructure vendor lock-in by making your application portable to any IaaS provider. Cloud Elements Confidential 9
- 10. EXAMPLE: PaaS SERVICES Services: Heroku, AppFog, CloudBees, Standing Cloud, Eucalyptus, Force.com, Azure, Tier 3, Cloud Foundry, Apprenda … Open Source: Cloud Foundry (VMware), OpenShift (RedHat) and Eucalyptus Amazon Web Services (AWS) offers many PaaS-like services − No abstraction layer between these services and their IaaS platform − 3rd party PaaS providers such as AppFog and Eucalyptus provide deployment options to AWS Note: OpenStack & CloudStack are primarily IaaS platforms; not PaaS Cloud Elements Confidential 10
- 11. PRIMARY BENEFITS of PAAS Lower Development Costs (30%+) Lower Deployment and DevOps Costs (Nearly Eliminate) Application Portability (depending on the PaaS) Cloud Elements Confidential 11
- 12. THERE’S A “SERVICE” FOR THAT! Find SaaS services you can leverage in building your app Glue them together through REST APIs − Evaluate the API when evaluating vendors Focus your resources on your unique functionality; not on building services that already exist Case Study: SaaS Distribution Application − Customer Management: SugarCRM (salesforce.com) − Billing: jBilling (Zuora) − Payments: Authorize.net − Email Messaging: SendGrid − SMS Messaging: Twilio − Customer Service: ZenDesk (GetSatisfaction) − Custom: User Interface, Order Entry, Quoting Cloud Elements Confidential 12
- 13. CLOUD APPLICATION ARCHITECTURE WITH PAAS Consider the implications to portability on your application. Will it be more difficult to migrate from the IaaS vendor if you utilize their other application services versus 3rd party application services that work on any cloud? Cloud Elements Confidential 13
- 14. 5 EVALUATION CONSIDERATIONS 1. Does the PaaS support my preferred list of services? − Application runtimes − Development frameworks − Database services 2. Does the PaaS support my deployment preferences? − Public, Private and Hybrid 3. Is application portability important? − Multi-cloud or single-cloud? − Open source available? 4. What are the value-add services? − Marketplaces − Partner ecosystem − SaaS-type services 5. Does it fit my application strategy? − e.g., developing on services such as Azure (Microsoft) and Force.com (salesforce.com) can drive strategic relationships these vendors − e.g., you want to deploy your application to private clouds and open source provides that alternative Cloud Elements Confidential 14
- 15. CLOSING THOUGHTS Don’t just virtualize; optimize Develop on a PaaS Platform not an IaaS Platform Architect before you build ... not after “Integrate First” ... Build Second Service based design; Same APIs internally as externally Cloud Elements Confidential 15
- 16. Cloud Elements Confidential 16
Editor's Notes
- There is a big difference between moving a legacy app and virtualizing it… that is not a true cloud application, it Is not optimized for the cloud.Critical characteristic that companies missed is being able to monitor and scale the application. <take a piece from Steve’s preso – ability to manage>. Just building it on Amazon or Rackspace doesn’t mean that it is monitored and scalable (can through hardware at it on Amazon). Gartner, Forrester are the two main sources for this.
- The whole point is to connect together the services from the various layers and loosely couple them. Well designed application use APIs for both internal and external.Key goals of REST include:Scalability of component interactionsGenerality of interfacesIndependent deployment of componentsIntermediary components to reduce latency, enforce security and encapsulate legacy systems
- Platform as a Service is the most misunderstood layer in the cloud – everyone knows the IaaS and SaaS layers – PaaS is the emerging layer of the cloud. Why is it important? Because if you are building it on Cloud-Foundry – based on the Java Spring Framework. RedHat with openShift build on Jboss framework. All originally built for traditional Frame and service – takes those environments and makes them scalable.Mail Services, Messaging Services…. Application run time, database run time, messaging and queuing capabilities.
- Use the IaaS for what it is meant to be. Networking, computer, and storage. Eg. ViaWest.Figure 1 – The PaaS Tier of Our Cloud Application Architecture ModelThe services provided by Cloud Foundry define the PaaS tier of our model:Application runtime services including Java on Spring, Ruby on Rails and node.jsApplication management services including application health monitoring and alerting, application resource management and application scaling and deployment management.Data services including PostgreSQL, MySQL, MongoDB and Redis. By persisting application data within data services offered by the PaaS, you increase the portability of your application data vs. persisting data directly to the infrastructure level data service, e.g., Rackspace Cloudfiles or AWS relational Data Service (RDS).Messaging & Queuing services including RabbitMQ. Multiple cloud applications deployed within the same environment often need to communicate with each other. The mechanism for communication between applications should leverage the PaaS Messaging and Queuing services, which again eliminates dependencies on the infrastructure. For example, multiple applications should never use environment variables to communicate with each other, as extra effort is required to migrate such configuration from one IaaS provider to another. Use these services at the PaaS level instead of at the Infrastructure level and each of these services will be portable. Every Cloud Foundry Core instance includes the same release version of these services. If you stick with “Core” services your application will be certain to have portability among all Cloud Foundry Core compatible providers.igure 2 – The IaaS Tier Follows Our Selected PaaS Services Based on some prototyping and performance testing, we were able to convince one of our customers to leverage a PaaS for the data and storage services. This also served to validate our application architecture model. Within a year this client decided to migrate to a different public cloud infrastructure provider to lower their costs. This layered architecture saved this customer a substantial amount of money by maintaining the architectural separation between the PaaS and IaaS providers for the data and storage services. The only activity we had to perform with the client was to install Cloud Foundry and replicate the application data to the new IaaS provider. This allowed us to migrate the application, services, and data (using Cloud Foundry Tunneling) to the new cloud infrastructure provider in a matter of days, which otherwise could have taken months.
- What you should expect from a PaaS provider.MongoDB, Hadoop, - noSQL databases – big data environments – great for analyitics.Structured data – using PosGress or mysql.Application Runtime – Java, Ruby, Node.js - .Net environments.Messaging and Queue.RabbitMQ, Application Management – inherent to the PaaS – some have integrating newrelicSteal something from CloudFoundry.org – put in an example.
- Reduced Operations Cost – we generally find that 30% or greater of development time can be consumed in DevOps functions. A PaaS will nearly eliminate the DevOps function and reduce it to simple user administration and resource allocation functions. AppFog, a leading PaaS provider, has a greatinfographic on this topic and our experience validates their claim that almost all DevOps functions can be eliminated by developing and deploying cloud applications using a PaaS.Reduced Development Cost – An IaaS provides network, compute and storage scalability; but it doesn’t automatically provide application scalability. Application scalability is not only an operations issue but it is a development issue as well. A significant amount of development time is spent repeatedly building such functions as application health checks and reporting, but a PaaS provides these functions out of the box. A PaaS provides application runtimes, data and messaging services that are cloud aware. As adoption of the PaaS layer increases, the leading providers are investing time and energy, in providing tools to increase development productivity and the development productivity gains of using a PaaS will continue to increase.Application Portability- It is a bad idea to develop on-premise applications specific to a hardware vendor, so why would it be a good idea to write cloud applications specific to the hardware vendors of the cloud, i.e., IaaS providers? Your PaaS offers developers a set of services that are independent of the infrastructure, ensuring that the application and operational tools you integrate into your application are agnostic of any cloud infrastructure. By leveraging application development runtime environments, data and application management services within an open PaaS you can deploy to your application to any IaaS, without changing a line of code.More Deployment Alternatives – Open and portable PaaS offerings, like Cloud Foundry, can be deployed to public or private cloud configurations giving you the most flexible deployment alternatives. For instance, the Cloud Foundry ecosystem includes multiple public cloud providers including AppFog and Cloudfoundry.com. Additionally, the PaaS bundle is available from CloudFoundry.org for private cloud deployments to your data center, or public clouds such as Amazon Web Services, Rackspace and Hosting.com.More Development Services – We find that a PaaS such as Cloud Foundry has a wider range of run time and data services available than do most IaaS providers. Cloud Foundry for example supports Java, Ruby and Node.js application run-times, as well as PostgreSQL and MongoDB data services. Also, a vibrant ecosystem of partners have extended the available runtimes to include PHP, .Net, and added data services for MySQL, Microsoft SQLServer and Hadoop. Improving speed, flexibility, and agilityPaaS can provide greater speed, flexibility, and agility to the development process. By providing a predictable, heterogeneous application infrastructure, organizations don’t get bogged down with enabling applications and can quickly meet the needs of customers.PaaS helps to do the following:Enable faster time to market by allowing development teams to focus on the applicationEnhance ability to react to changes and opportunities because the organization doesn’t have large up-front costs associated with typical application development and deploymentSpread capital investments further, which allows a company to be more competitive
- Social Networking App on AWS Demonstrates Service IntegrationWe recently designed a social networking application for a startup customer that required the following application layer services: Payments, SMS Messaging, Email and Facebook/Twitter Integration. The application was to be deployed using Cloud Foundry on Amazon EC2. For each of these services Amazon offered alternatives as did third party SaaS providers. We evaluated these application level services, regardless if they’re offered from the IaaS or PaaS provider, like we would services from any third party SaaS provider based on functionality, price, performance and integration capabilities. Consider the implications to portability on your application. Will it be more difficult to migrate from the IaaS vendor if you utilize their other application services versus 3rd party application services that work on any cloud? Consider portability implications across technical, business and contract considerations.
- Use the services at the right layer -