The extraordinary growth of Java during the last decade owed everything to the set of infrastructure services that application servers provided as part of the platform. However, TCO eventually drove the move to the cloud and PaaS (Platform as a Service) is set to deliver a standard run-time for the next generation of applications, replacing the proprietary infrastructure provided by the application server vendors. Now the question is: where do developers of real-world business applications look for a common set of standard infrastructure services? Is there a common framework that can provide essential application services, such as message queueing, push notifications, email integration, in-memory caching and processing? Amazon Web Services (AWS) with their highly-scaleable IaaS (Infrastructure as a Service) model are an obvious answer, but how best to combine Java's rich ecosystem of tools, frameworks and knowledge with the scale and cost-effectiveness of cloud-based web services? This session will help you to understand how you can deliver applications that make effective use of those services by using a Java PaaS, without being forced to support the underlying infrastructure. In this code-rich session, aimed at architects and developers, Mark Prichard of CloudBees will show how you can: Pass Amazon security credentials and configuration parameters to PaaS applications at run-time to provide customized environments; use JDBC and Amazon RDS (Relational Data Service) to provide resilient and performant relational data servicesReplace JMS queues and topics with Amazon SQS (Simple Queue Service) and SNS (Simple Notification Service) to develop cloud-based messaging applications; use Amazon's SES (Simple Email Service) from Java applications. We'll also look at other cloud e-mail services that offer easy integration with the PaaS modelRun distributed caching solutions in the cloud using Amazon ElastiCache's in-memory distributed caching with Java PaaS deployments.
4. 4
What did we like about JavaEE?
• Standard way to build apps
• Massive, proven eco-system of libraries, APIs, tools
• Rich set of APIs and containers to simplify: e.g.
– Messaging
– Connection Pooling
• Tooling and infrastructure to simplify deployment,
configuration, resource management and monitoring
• It worked
5. 5
What did we not like about JavaEE?
• Stack often too heavy for most applications
• Sizing, scaling and performance: black arts
• Hard to “mix and match” application services
• Too much emphasis on the infrastructure
• Iterative development slowed down
• Pace of innovation slowed
• Loss of developer focus
7. 7
What is Platform-as-a-Service?
• We run your applications for you
• We provide and manage all the supporting infrastructure
needed to run your apps
• We monitor, manage and can scale out your apps
• We provide a full, enterprise-class build environment
using Jenkins CI – the world’s #1 OSS continuous
integration server
• Fully integrated ecosystem of cloud services
9. 9
Have You Met Jenkins?
• #1 OSS CI server
• Easy to install/use
• Extensible via 600+ plugins
• Very widely adopted
– 47K+ installations
• Very active community
– Over 7 years of history, 440+ releases
– 600+ plugins, 300+ developers
• CloudBees adds plugins for cloud builds
10. 10
Cloud Terminology
• Infrastructure-as-a-Service (IaaS)
– Think: Amazon Web Services
– What: Server Instances, Storage Buckets etc
• Software-as-a-Service (SaaS)
– Think: Salesforce.com
– What: Packaged Applications (in the Cloud)
• Plaform-as-a-Service (PaaS)
– What: Managed Service for Custom Apps
34. 34
Quick Sidebar: What Does It Cost?
• Your app always runs in secure, isolated containers to
which only you have access
• We can run those containers for you using shared
resources or dedicated resources
• You pay only for what you need: a fixed subscription or
“pay as you go” pricing
• FREE and COMPLETE for developers: no credit card
required
The way you use ClickStarts and ClickStacks follows what is probably a familiar model. We host them in open source form on a Github-based CloudBees community site. You can fork them, and if you find a way to improve them, submit a pull request to us. Communities like Play and Scala are already doing this, but creating their own galleries of community-managed ClickStarts. And as I was saying, I think you will see customers of ours and SIs like you create brand-new ClickStarts and ClickStacks for use internally, to get new employees up to speed quicker, and to capture standards.
CloudBees Services Used: RUN@cloudEcosystem Services: New RelicLose It! Delivers a Scalable and Compelling Weight Loss Experience Watch what you eat. It’s a core tenet of successful weight loss and weight management programs. Here’s another: there is power in numbers. The Lose It! web application, iPhone app and Android app have enabled users to take advantage of both of these principles to lose more than 10 million pounds collectively, with the average user dropping more than 12 pounds. “Tracking what you eat is a validated way to lose weight, but adding a social component—peer support—improves motivation and the efficacy of tracking,” explains Charles Teague, CEO of FitNow, the start-up company that developed Lose It! “When people form small support groups, they are more apt to stick with a diet program and succeed— and Lose It! helps them do just that.”FitNow decided early on to capitalize on their expertise and organizational knowledge by developing and delivering a great application to help people lose weight and eat healthier. For a five-person start-up, allocating resources and incurring overhead to manage day-to-day infrastructure needs was simply not viewed as a priority. Instead the company wanted to distinguish itself in a crowded software application market by offering a high quality application. “Our operations strategy is to leverage third parties for infrastructure and associated maintenance,” says Teague. “Our business strategy is to provide a great consumer experience that differentiates us, and that’s where we want to focus our resources. We do not want to invest in infrastructure—we just want it to be there.”FitNow executes its operations and business strategies for Lose It! with the CloudBees RUN@cloud Platform as a Service (PaaS) solution. “Thanks to CloudBees, we have managed to avoid hiring a full-time systems administrator to support what would be equivalent to 25 in-house servers,” notes Teague. “We have lower infrastructure maintenance costs and higher productivity because we have access to the computing resources we need, when we need them.”Challenge: Preparing for Unknown DemandWhen FitNow was ready to release the web version of Lose It! with social networking features, the company had no way of accurately predicting user demand, and thus no concrete way of planning how many servers they would need to meet that demand. “We could not predict how successful the application would be, so we didn’t know if we would need three servers or 53 on the day it launched,” says Teague. Infrastructure planning was further hampered by the seasonal nature of interest in weight loss programs, which typically subsides during the holidays but increases in January and at the beginning of summer. Overestimating demand and purchasing servers to provide the expected capacity would be a costly mistake, but so too would underestimating demand and not having enough capacity. It was clear that Lose It! would benefit from a cloud deployment that would enable rapid scaling to match demand.FitNow had made the decision to develop both the front end and the back end of the Lose It! application in Java. “We targeted Java because of its maturity, performance and overall robustness. We also wanted to use Google Web Toolkit on the front end – it is a good tool for creating really great client web experiences. With Java, we were also confident that the back end would live up to our performance, stability and code quality expectations,” explains Teague. The developers needed a solution that would enable them to make the most of Java, the cloud and PaaS deployment. This, in turn, would let Lose It! focus on delivering a great application, instead of dealing with infrastructure and deployment headaches. Teague and his team considered a number of potential solutions, but found that many lacked the automation, transparency and flexibility they wanted—including the ability to custom tune application servers and other aspects of the deployment environment as needed.A Flexible and Scalable SolutionFitNow deployed Lose It! to the cloud using RUN@cloud. All of the servers for the application, including application servers, replicated database servers and cache servers are running on RUN@cloud.The CloudBees infrastructure for Lose It! handles thousands of writes per minute and tens of thousands of reads per minute. “Lose It! is a high volume site. We’re seeing volumes as high as 25,000 transactions per minute and RUN@cloud is handling it all 24/7,” says Teague.When the development team wants to share a test version of the Lose It! website, they can instantly spin up a new server in the cloud. The ability to spin servers up and down as needed in a variety of pre-production states streamlines the development and testing process.Deployment has been streamlined as well. “We deploy once a week on average, though with major releases, it may be multiple times per day. We can do this without worry because it costs next tonothing with RUN@cloud,” says Teague.For FitNow, RUN@cloud has provided a vital layer between Lose It! and Amazon’s Infrastructure asa Service (IaaS) offerings. Teague notes that CloudBees takes care of details that few organizationshave the time or experience to delve into. “For example, I probably wouldn’t have had block stores indifferent isolation zones like CloudBees automatically did for us, thinking that there would never be ablock store problem. When Amazon went down last year, they had a major problem with one isolationzone on the Amazon block store. Siteslike ours which were across multiple zones - with data replicated,were able to restore service quickly and without any data loss,” he explains.FitNow gets real-time visibility into Lose It! application performance with the New Relic Software as aService (SaaS) solution. A part of the CloudBees Ecosystem, the New Relic service enables FitNow totrack server performance and analytics, as well as analyze requests to see how the front end, applicationand network are contributing to response times. FitNow can use this information to tune applicationservers in the cloud when necessary.ResultsDeployment in minutes, not weeks. “When deployment gets as easy as it does with CloudBees, itchanges the way you think about development,” says Teague. “At othercompanies I’ve worked for,deployment was a two-week process. Fixing any bug, even if it took a minute to write code, took twoweeks, so you had to be extremely careful on theproduction server. With RUN@cloud that same processnow takes us five minutes. We can address bugs and performance bottlenecks in minutes, which enablesus to continuously improve the quality of Lose It!”Reliable, high-volume transactions with no administration overhead. “Our application on RUN@cloud is handling more than a million simultaneous users and tens of thousands of transactions perminute—all with no systems administrators. That alone is saving us more than $100,000 per year,” saysTeague. “We are seeing three nines (99.9%) for up-time on the equivalent of 25 dedicated servers, with ahardware IT budget of zero.”Increased focus on core differentiators. “To deliver the Lose It! web application we needed scalability.RUN@cloud was a great fit, because it gave us a flexible, scalable solution with low entry cost,” says Teague.“Off-loading the technical back-end work to CloudBees enabled our team to direct all their efforts towardsone objective—creating a compelling, innovative user experience that will help people lose weight.”For more information about Lose It!http://www.loseit.com
Let’s take a really concrete use case that is driving a lot of new application development today – mobile – and take a look at how the CloudBees PaaS delivers all the tools you need to provide a complete solution. Developers will likely be working on a local machine, often testing locally with a very limited set of devices. They cut code, run unit and device tests, and commit locally. When they’re ready, they push their work to a shared repository. The push kicks off a build and a larger, matrixed and pipelined set of builds. These might include functional and integration tests, or long running tests to track performance regressions and device-specific gesture-driven tests.