By now, everyone has heard the benefits of “moving to the cloud.” And the No. 1 benefit cited is economic.

If you’re a seasonal business, like an online florist, you get spikes around Valentine’s Day, Mother’s Day and religious holidays. But most times, you’re not handling tens of thousands of orders or more, so to install hardware for those peak times that sits idle for the down times is not cost-effective. The cloud offers the ability to provision hardware and pay for it as needed, resulting in huge savings.

For developers, though, the cloud both offers advantages and creates new challenges. Cloud services give developers a whole host of functionality to choose from, but moving applications to the cloud, or creating applications to run in a hybrid cloud situation, requires giving up some control of how the app will perform to a third party.

The undisputed leader in cloud technology today is Amazon Web Services, which offers high-level services for developers in a variety of languages and through thousands of different API functions.

So, if you’re a developer working for a company that wants to run its applications on AWS, where do you start? Jeff Barr, chief evangelist for Amazon Web Services, provided some insights.

“We empower developers in a lot of different ways. We give them a very broad collection of…pick-and-choose, mix-and-match-style service,” he said. “The developers just pick one or two services to get started. It’s the rare developer who would look at the entire spectrum of AWS services and say, ‘I would like to build my first application and use every last one of them.’ It’s like you have this big buffet in front of you and you just want to pick and choose carefully and get some skill and experience with them one or two at a time.

“It’s going to really vary a lot by application, but two that seem to be really good starting-off points are going to be the Simple Storage Service, or S3, that has just a wide variety of different ways they can put it to use,” Barr continued. “If they’re building an application, let’s say, that lets their users upload images or videos or other kind of large-scale content, S3 is a great solution for that. And a lot of users of course need some kind of dynamic hosting or computation so they’re going to be using EC2 for their services and compute power.”

Nothing to fear but fear itself
When looking to build cloud-based applications, developers often have two fears: the fear of failure, naturally, but also the fear of success. Barr explained: “One of the first fears is the kind of classic fear of failure. If you’re a developer, you say, ‘I’m going to put my Web application online, I need to invest in some hosting, I need some servers,’ and in the traditional pre-cloud model you’d have to make long-term commitments before you fully understood how much are we going to succeed. Are we going to succeed a little? Are we going to succeed a lot? You couldn’t practically size your hardware, but the challenge was you’d have to make that upfront investment before you really had any data to go on.

“On the other side, and I think this is just as real for a lot of people I’ve spoken with…it’s kind of a fear of success,” he said. “What I mean there is that you might have this awesome idea, and suddenly your mind starts running away with the idea, and you talk to your friends, and they say, ‘Wow, that’s awesome, the whole world’s going to want to use that. It’s the coolest idea I’ve ever heard.’ And then you think, ‘Wow, that’s kind of scary. What if I get all those users? Where do I get the bandwidth? Where do I get the storage? Do I have to pay for all this upfront?’

“I think developers say, ‘I might shy away from doing some of those kinds of things because I don’t know what’s supposed to happen if I do succeed big-time.’ ”

AWS hedges this with a pay-as-you-go model for services, which helps mitigate the fear of failure by eliminating large upfront fixed payments before you even know what the usage model of the application will be. Barr said, “I always tell developers that it’s really important to understand the business model of your app. What does it cost you to serve up a page, to store an image, to transcode some video? The idea being, you should have a good comprehension, a good understanding. These are different components of the app, and this is how much it costs me to run them. Because of the pay-as-you-go model of AWS, it’s really straightforward for developers to actually understand that, and they can see the different costs of components very easily.”

“For services like S3, developers pay for the actual [gigabytes per month] of storage, but we measure the usage several times per day, and so when you start out, you’re building and testing your app, maybe you’re only using a couple of megabytes of storage. You’ll get tiny little bills, maybe you’ll get a bill for one penny or two pennies as you start developing. And so developers start to get the message pretty quickly that it is a pay-as-you-go model, and they start to get a sense of the economics of their application as they’re going along.”

One AWS scenario
So you want to get started writing AWS applications. Barr offered a common scenario for leveraging those services to your best advantage.

“Let’s say we have a developer building a mobile app. So they’re doing a real simple mobile app that perhaps they want to upload images and they can aspire to video. They’re going to be able to make use of a wide variety of services in that mobile app.

“The most obvious first one will be S3 for the storage of their images as they’re uploaded. Because S3 is pay-as-you-go-based, when they have no users and they’re just testing and slowly uploading test images, they’ll simply pay the several cents of gigabyte-per-month for those images. As the user base grows, they’ll have a nice smooth cost growth that goes along with the user base. They’re paying linearly, even less than linearly, because the price goes down with more data stored. They can always see this nice smooth cost curve that’s in line with the actual utilization.

“So we’re storing images in S3, and the next thing they might want to do is, they see they have users viewing these images from all over the world. So we want to make sure it’s a nice quick responsive app. They might use Amazon CloudFront, the content distribution network, to get the images distributed out to nodes all over the world. That might be a nice second step for them.

“Moving from there, they’re going to say they have people uploading these images, so they may want to start tracking some metadata. So what do we need to track? We have a choice: Do we want to do a relational model? Or do we want to do a NoSQL model? And in either case, there are AWS services to help out there.

“If you’re going to go with the NoSQL model, we have services like DynamoDB where you create your database tables with a certain amount of reads per second and writes per second. The cost is relative to the amount of throughput you provision. So as our hypothetical app starts to get some use, and you start to see that the table is at that level of reads and writes, you can simply go to the table, go to the management console, and just up the level of throughput, so you’re effectively making the table able to sustain more reads or more writes by simply modifying attributes on the table. You can easily scale; you don’t have to think about ‘Is my database going to be my limiting factor?’ ”

There are, however, some caution flags. Michael Masterson, leader of strategic business development for cloud and Big Data at Compuware, said there will be unpredictable levels of performance. “When you run in a cloud as large as AWS, you’re sharing infrastructure, but you have no idea what server you’re running on, and you have no idea what your neighbor is doing,” he said. “The ‘noisy neighbor’ is real. If you do see hiccups in your performance, you need to understand fundamentally if the infrastructure is going through a heavy load phase, or if third-party assets are coming in at the edge on the client-side,” such as ads, content or even aggregation.

As for paying for additional IOPS, Masterson said it’s important to understand where the variables and degradation in your application occur, because it helps in deciding where to spend for the additional read/writes. “You pay a premium for [high levels] of disk access,” he said. “It’s great to have that level of control, but you need knowledge of your application to understand when you want guaranteed performance and where to spend for it within an application.”

Driving away the drudgery
When AWS first began, Barr said, Amazon would launch raw REST and SOAP APIs for developers. Now, there are toolkits for a number of different programming languages, including Java, PHP, Python and Ruby, as well as .NET languages and Node.js. “The thing I think really works for developers is we let them focus on what they generally consider to be the good stuff and the fun stuff,” Barr said. “Developers often enjoy building their application, building the user base. These are the things developers were trained to do and they enjoy.

“The things developers are not always so excited about are the operational benefits, the operational issues, the scale-building, linking backups, adding more hardware, [and] dealing with growth. So I can look at the different things we do for developers and I hope we’re taking away the drudgery, and really making it so they can focus on what traditionally is more enjoyable and more fun.”

Barr added that, where possible, Amazon has put code out on GitHub so developers can root around inside the code and see the source behind the toolkits. Further, the company offers mobile toolkits that target Android or iOS development.