Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Do Any Development Shops Build-Test-Deploy On A Cloud Service?

Unknown Lamer posted about 4 months ago | from the raining-dev-builds dept.

Cloud 119

bellwould (11363) writes "Our CTO has asked us to move our entire dev/test platform off of shared, off-site, hardware onto Amazon, Savvis or the like. Because we don't know enough about this, we're nervous about the costs like CPU: Jenkins tasks checks-out 1M lines of source, then builds, tests and test-deploys 23 product modules 24/7; as well, several Glassfish and Tomcat instances run integration and UI tests 24/7. Disk: large databases instances packed with test and simulation data. Of course, it's all backed up too. So before we start an in-depth review of what's available, what experiences are dev shops having doing stuff like this in the cloud?"

cancel ×

119 comments

Bamboo OnDemand (5, Interesting)

Anonymous Coward | about 4 months ago | (#46640819)

Atlassian is already trying to push their customers in this direction. Their Bamboo OnDemand offering spins up AWS instance as needed for builds. In this case, you could still host a local Bamboo instance and use elastic remote agents.

One thing I do like about this sort of setup is that it keeps you honest about deployment. Your build environment stands up a new instance every time your remote agent goes stale and is recovered to reduce costs.

Re:Bamboo OnDemand (1)

Jeremiah Cornelius (137) | about 4 months ago | (#46641143)

I think maybe the results of pilot efforts might be looked to, before mandating all development go to this model, based on reference architecture...

Re:Bamboo OnDemand (1)

Anonymous Coward | about 4 months ago | (#46642453)

My company has migrated all development to the cloud for development, quality assurance, pre-production (staging), and in some cases production. The convenience of standardised environments, quick build-up and tear-down, as well as access from practically any network-connected device should not be underestimated.

Re:Bamboo OnDemand (1)

Omeganon (104525) | about 4 months ago | (#46642083)

We're using OnDemand for CI of everything and CD for some. We use spot instances for the workers because we don't mind waiting a bit for the test to happen. We typically have to wait ~3.5 minutes to get an instance but are only paying $0.07/hr for that instance. It's ridiculously cheap for us to do it this way.

50%+ cheaper not to use the cloud (2, Insightful)

Anonymous Coward | about 4 months ago | (#46640833)

It is 50%+ cheaper if you use in-house hardware. This assumes that you are a trained system administrator and you purchase energy and cost efficient hardware. Also, your data will be yours and not Amazons.

Re:50%+ cheaper not to use the cloud (2)

ackthpt (218170) | about 4 months ago | (#46641015)

It is 50%+ cheaper if you use in-house hardware. This assumes that you are a trained system administrator and you purchase energy and cost efficient hardware. Also, your data will be yours and not Amazons.

With reliability of the Cloud we're not considering it ... yet.

Once Cloud is considered reliable and secure, we'll look at it.

Until then .. spinning drives are way cheap.

Re:50%+ cheaper not to use the cloud (2)

mjwalshe (1680392) | about 4 months ago | (#46641083)

Better off renting/leasing your own dedicated servers in a colo AWS is designed to nickle and dime you unless you really really know what your doing and have the right use case.

Re:50%+ cheaper not to use the cloud (-1)

Anonymous Coward | about 4 months ago | (#46641973)

I've heard it argued that you lose readers when you use multiple sentences or even commas in a paragraph apparently they grow bored or become distracted this is especially a concern with the increasing prevalence of ADHD diagnoses I personally don't buy this argument I think sentences make paragraphs easier to parse and understand the benefit of a continuous stream of words notwithstanding English isn't an officiated or prescriptive language though and YMMV this isn't meant to be negative criticism if you prefer the monosentence style I'm just giving you my 14/35ths of a nickle and dime I can understand it myself and even the some of the reason behind it such as I mentioned before and ISPs that nickle and dime you by the sentence or punctuation character or if you've ever been on The O'RLY Factor and want to get a word in edgewise before BULL({=O=})RLY tells you to shut up pinhead shut up and says to cut your mic if you prefer this style carry on it certainly has its charms.

Re:50%+ cheaper not to use the cloud (3, Informative)

Cyberax (705495) | about 4 months ago | (#46641191)

Why would you care about reliability for continuous integration?

We use Amazon EC2 with spot nodes for our CI. After all, if a node dies - you can just restart the whole process on a new one. Sure, you'll lose some time, but given that 32CPU node with 64Gb of RAM can be bought for $0.3 per hour - we simply don't care.

Re:50%+ cheaper not to use the cloud (0)

Anonymous Coward | about 4 months ago | (#46641525)

Once Cloud is considered reliable and secure, we'll look at it.

Secure?

By who's standards, yours or the NSAs?

Re:50%+ cheaper not to use the cloud (1)

jasonrice22 (3458571) | about 4 months ago | (#46641061)

Dedicated hardware also performs better per the cost especially when it comes to disk io. I've experienced minutes of waiting time just making a MySQL database around 15 tables none having more than 5000 rows, whereas it was nearly instantaneous on my local machine. I've also experienced a lack of consistency on EC2. If someone is watching an episode of the smurfs where it is raining, you will notice a difference.

Re:50%+ cheaper not to use the cloud (1)

jasonrice22 (3458571) | about 4 months ago | (#46641077)

ha.. i meant to say on NetFlix

Re:50%+ cheaper not to use the cloud (1)

erlegreer (1994842) | about 4 months ago | (#46641485)

raining on NetFlix

Re:50%+ cheaper not to use the cloud (1)

lgw (121541) | about 4 months ago | (#46641185)

Cloud servers have terrible IOPS. For anything but a DB, it probably doesn't matter, but trying to run a DB on a cloud VM will be painfully slow.

OTOH, most cloud services actually offer DB-as-a-service, in one form or another, and if you can use that then performance will be much better. Not good, mind you, but no longer painful.

Re:50%+ cheaper not to use the cloud (1)

NatasRevol (731260) | about 4 months ago | (#46641387)

Um, LOTS of stuff requires high IO.

Think of a qa VM. It has to do snapshots, installs, reverts. All of which are high IO. Especially if the build is a large install.

high iops != high IO (not always, anyway) (2)

Fubari (196373) | about 4 months ago | (#46641985)

r.e. high IO... iops tend to be bottlenecked by random access (think seek time).

Snapshots, installs, and so on are not so much random access limited as sustained sequential throughput; more streaming than random... SSD's tend to saturate SATA ports so you end up with tricks like raid to get more speed.

*shrug* So... there are different kinds of "high IO". Depends on what your app needs from a storage point of view.
The take home message is that if storage performance matters to your app(s) be sure you understand what kind of storage subsystem options your cloud dealer can give you.

For your research pleasure... [wikipedia.org] (link has performance #'s for an interesting range of devices, worth a look if you're doing data intensive things).

Um, LOTS of stuff requires high IO.

Think of a qa VM. It has to do snapshots, installs, reverts. All of which are high IO. Especially if the build is a large install.

Re:high iops != high IO (not always, anyway) (1)

NatasRevol (731260) | about 4 months ago | (#46642359)

Depends on the type of install - decompress & scatter lots of small files or just copy one large app.

But yes, I'm very familiar with IOPS - I have several 24xRAID of STEC s840 drives ~= 1M IOPS. Large dbs love them.

Re:high iops != high IO (not always, anyway) (2)

lgw (121541) | about 4 months ago | (#46642755)

Of course, the best way to get a fast DB is 10,000 low-end servers. But if you're stuck in the legacy world of trying to scale up, you can't really use a cloud server for a DB, except for testing with token load.

You mentioned snapshotting et al, but you don't do that stuff explicitly with cloud servers, you just stand up servers with the requested image on demand, and leave the implementation to the provider. If you need to move quickly, you just have a pool waiting, or just go parallel. E.g., if you need to run 100 test suits, each starting with a fresh server, you just run 100 servers in parallel and toss em when you're done. You're effectively paying by server-hour, not by server, so it's a different mindset.

Re:high iops != high IO (not always, anyway) (0)

Anonymous Coward | about 4 months ago | (#46642929)

the best way to get a fast DB is 10,000 low-end servers

At the cost of a lot of DBA hours trying to separate it to 10,000 tables/shards/whatever.

Just don't do a join.

Re:high iops != high IO (not always, anyway) (1)

lgw (121541) | about 4 months ago | (#46643181)

Well, do you have to properly understand DB partitioning, to be sure. Still, it's a heck of a lot easier than re-writing everything to work non-transactionally with NoSQL.

Re:high iops != high IO (not always, anyway) (1)

Fubari (196373) | about 4 months ago | (#46643887)

NatasRevol: All valid points; sounds like we're vigorously agreeing :-)
r.e. the s840 raids, I feel a bit jealous - that sounds like fun to work with.

Re:50%+ cheaper not to use the cloud (1)

SethJohnson (112166) | about 4 months ago | (#46641211)

If someone is watching an episode of the smurfs where it is raining, you will notice a difference.

Could performance be improved if Amazon were to offload rendering of the raindrops to the client? I'm thinking if the Roku or AppleTV box had to compute the transparency of the raindrop over the skin of the blue smurfs, it might alleviate these performance hits you're seeing on EC2. Either that or replace the raindrops with snowflakes which are more complex due to every single one being unique, but not having transparency issues to manage might speed things up. I suppose the feasibility would depend on the Smurfs episodes' storylines, however.

Re:50%+ cheaper not to use the cloud (2)

Omeganon (104525) | about 4 months ago | (#46642117)

I would beg to differ on this. For CI, you can easily use spot instances which are dirt cheap. We pay $0.07/hr for ours. Assuming we had a build running 24x7x365, that's $613.20 per year costs. You'd be hard pressed to find a decent box for that price. Additionally, builds are not happening 24x7x365, but rather only when changes are made so your costs are even better than hardware, which is sitting idle and using power and rack space during the interim.

Re:50%+ cheaper not to use the cloud (1)

andy1307 (656570) | about 4 months ago | (#46642497)

This is why I browse slashdot. "Insightful" posts like this backed up by solid data.

Frosty p0st (-1)

Anonymous Coward | about 4 months ago | (#46640851)

Answered in one. These services all offer free trials and the billing practices are clearly outlined on their sites. Fuck off, nigger.

24/7 operation + Amazon (0, Interesting)

Anonymous Coward | about 4 months ago | (#46640859)

You'd better get some serious analytics done on your platform before moving it to a service that has open-ended billing.

EC2 likely too expensive.. (2, Insightful)

Ben Evans (3601821) | about 4 months ago | (#46640861)

If it's all Java / JVM, then look at the Cloudbees offering, or the Waratek JVM (high-density) on something cheaper than EC2. Unless you have a decent grasp of when your environment can be shut down, EC2 is almost certain to be a waste of money, especially for dev / test.

Re:EC2 likely too expensive.. (1)

Anonymous Coward | about 4 months ago | (#46640925)

Amazon just did a huge price drop on all of their AWS services, it might actually have gotten to an affordable level.

Re:EC2 likely too expensive.. (2)

ackthpt (218170) | about 4 months ago | (#46641047)

Amazon just did a huge price drop on all of their AWS services, it might actually have gotten to an affordable level.

There's two "affordabilities"

1. Nearly free, as in beer.

2. It's up when we need it to be. If an outage costs us, that's factored into "affordable" and may be a cost we can't afford.

Says who? (3, Interesting)

kervin (64171) | about 4 months ago | (#46641303)

AWS has some of the lowest cloud prices I've found anywhere. You can get AWS instances for under $3/month reserved according to what you need. 'Small' Linux instances cost about $15/month reserved last I checked. In fact they'll even give you a Micro instance free for a year without spending anything as part of their 'free tier'.

How did you come to the conclusion AWS was expensive?

Re:Says who? (0)

Anonymous Coward | about 4 months ago | (#46643229)

Where are you able to find an AWS instance for $3/mo? Even with reserved instances, it costs me about $14 per micro instance to keep them running.
Even Elastic Cache running on their cheapest Micro instance is about $8/mo.

Doing CTOs job for him (0, Informative)

Anonymous Coward | about 4 months ago | (#46640931)

Were you asked to do something or were you asked if doing something is a good idea?

If you were asked to do something then fucking do it. Any sticker shock is the CTOs problem to explain.

If your asked by your CTO if moving to AWS is a good idea for organizations where money is an issue the answer is typically NO. You can drink all of "the cloud" Kool-Aid you want... you just have to pay for it.

Re:Doing CTOs job for him (2)

pla (258480) | about 4 months ago | (#46641179)

If you were asked to do something then fucking do it. Any sticker shock is the CTOs problem to explain.

In spirit, I agree with you.

In practice, I write two kinds of in-house app on a regular basis - Integrations, and reports (yeah, I know, reporting doesn't generally count as an app, but compiling the data that goes into them behind the scenes very much does). How exactly do you move an integration that hits two (or more!) local servers, which may well contain sensitive (even in the PCI/PII sense) data, to "the cloud"? And for reporting, the task sounds simple until you ask "reporting on what?" Unless you want response times measured in hours or days, that would includes a hidden requirement that I also build a complete mirror of my local data warehouse in the cloud. Even ignoring the cost of that much storage, bandwidth rapidly becomes an issue when talking about trying to keep hundreds of gigs of data as close to realtime-fresh as possible.

So no, you can't always just "fucking do it". The FP likely understands that, and simply hopes to use price as an argument rather than patiently explain to his CTO why playing "Buzzword Bingo" doesn't make a viable long-term IT strategy.

Re:Doing CTOs job for him (1)

Gr8Apes (679165) | about 4 months ago | (#46641271)

Honestly, it's a stupid question for the CTO of a company with the implied sizing and complexity of the codebase. His better question would have been "how do we bring this in house to better utilize our resources and improve productivity". The cloud is the opposite on both questions at the implied scale.

Re:Doing CTOs job for him (0)

Anonymous Coward | about 4 months ago | (#46642251)

So no, you can't always just "fucking do it". The FP likely understands that, and simply hopes to use price as an argument rather than patiently explain to his CTO why playing "Buzzword Bingo" doesn't make a viable long-term IT strategy

Covering for the incompetence of his CTO doesn't make a viable long-term IT strategy either.

Re:Doing CTOs job for him (1)

ShanghaiBill (739463) | about 4 months ago | (#46641289)

If you were asked to do something then fucking do it. Any sticker shock is the CTOs problem to explain.

Careful. If the project fails or costs skyrocket, the CTO will be looking for a scapegoat to save his skin. He may try to pin it on you. So it is better to tactfully document the drawbacks and dangers in an email to the CTO. Then if he later tries to blame you, you can whip out that email and show it to his boss. Maybe get him fired, and you get promoted into his position. He is out the door, and you get a corner office.

Re:Doing CTOs job for him (0)

Anonymous Coward | about 4 months ago | (#46642631)

If you were asked to do something then fucking do it. Any sticker shock is the CTOs problem to explain.

Careful. If the project fails or costs skyrocket, the CTO will be looking for a scapegoat to save his skin. He may try to pin it on you. So it is better to tactfully document the drawbacks and dangers in an email to the CTO. Then if he later tries to blame you, you can whip out that email and show it to his boss. Maybe get him fired, and you get promoted into his position. He is out the door, and you get a corner office.

I used to do that too, get a paper trail for the "I told you so" moments. Still do when I don't catch myself. It doesn't help. If you need to bring that stuff up, you're better off changing jobs. Personally, I'm at a loss as to how to deal with people who ignore warnings and then get upset when they come true, while painting myself as "being negative" when I bring these up ahead of time. You know, when we could take action to mitigate the risks.

Re:Doing CTOs job for him (1)

MerlynEmrys67 (583469) | about 4 months ago | (#46641599)

Were you asked to do something or were you asked if doing something is a good idea?

If you were asked to do something then fucking do it. Any sticker shock is the CTOs problem to explain.

>

Time to bring Goodwin's law out.
Just because you are a guard at a prison, doesn't mean that saying "I was just following orders" is a good defense. It is YOUR job to know details and question things that come out of people's mouths to determine if they are good for YOUR company. Many times the answer is, yes it is a good idea - you don 't have to pay for upgrades, maintenance, or other things people always seem to forget about... Other times, keeping things in house is where you want to be. You should be able to find out what is correct for your organization and make sure that is what happens.

We do this (5, Informative)

CimmerianX (2478270) | about 4 months ago | (#46640937)

I'm IT for a company that does this for 95% of dev/test/qa systems. It's worked out pretty well. Most servers are spun up and then chef'ed, used, then deleted after tests/whetever are complete. We do keep our code in house. SVN/GIT/ and Jenkins along with server build farms are all in house. The cloud services are expensive, but since IT has automated the deployment process for the cloud hosts, it works out better than keeping enough hardware in house to meed all test/qa needs. Plus less hardware in house equals less admin time which is a plus for us.

Re:We do this (2)

Beezlebub33 (1220368) | about 4 months ago | (#46641855)

I'm IT for a company that does this for 95% of dev/test/qa systems. It's worked out pretty well. Most servers are spun up and then chef'ed, used, then deleted after tests/whetever are complete. We do keep our code in house. SVN/GIT/ and Jenkins along with server build farms are all in house. The cloud services are expensive, but since IT has automated the deployment process for the cloud hosts, it works out better than keeping enough hardware in house to meed all test/qa needs. Plus less hardware in house equals less admin time which is a plus for us.

we do something similar. We need a machine up 24/7 to do checkins, builds, automated tests. For that use case, it's better to have your own machine. When we need to spin up multiple machines to do integration testing of our networked app, then it makes sense to use EC2 since we get clean machines, it can get set up, run, and then torn down again.

Security concerns (3, Insightful)

Anonymous Coward | about 4 months ago | (#46640961)

If the stuff (data, processes, etc.) you put in the cloud are in any way sensitive, I would be very hesitant to put that in the hands of another company because of privacy and security. Particularly depending on your terms of service agreements with your users. I would avoid putting your source control system in the cloud too because then it's more accessible by nefarious actors than if it's locked down internally. This is of course assuming you have good security standards and practices in place.

Did your CTO ask how much it would cost? (1)

Anonymous Coward | about 4 months ago | (#46640993)

Forget trying to figure the cost, it isn't worth your time. Just move it and look at the bill. With Amazon and Google, there is no commitment, so try it. Take the bill to the other guys and see if you can beat it, if so move, if not stay. If everyone is too expensive, switch back to hosting it yourself. If cost is the most important issue, then the cheapest is building your own cloud with commodity hardware and OpenStack. You get the redundancy of the cloud with the cheap of whitebox hardware. Think of OpenStack as the "RAID of everything".

Re:Did your CTO ask how much it would cost? (2)

NatasRevol (731260) | about 4 months ago | (#46641425)

LOL.

Maybe if you don't have a complex, co-dependent environment.

Otherwise, you're just going to get fired.

We do (3, Interesting)

Anonymous Coward | about 4 months ago | (#46640995)

We're not at your scale, but we do everything with AWS and have found that it works well.

One thing you might want to do is reexamine your mentality around 24/7...you need to evaluate what really does need to run 24/7 and what needs to be available 24/7 (i.e. something that can tolerate the time it takes to spin up from an AMI).

For example, your Jenkins server could be configured with a master/slave arrangement that allows the main Jenkins server to be a small or medium instance that runs 24/7 and then when a build needs to happen, spin up a beefier slave to rip through it as fast as possible and then shutdown when done. Each build then has a fixed cost, regardless of whether it runs serially or in parallel.

Our main reasons for choosing to use the cloud were:
- We have remote workers, both permanent and a WFH policy...cloud makes it not matter where you're working from.
- Less maintenance...stuff mostly just works and most things are scripted rather than configured.
- We like the mentality of thinking of computing as a resource, not a collection of discreet machines. Running 5 builds in parallel is expensive when you think machines but costs the same as 5 serial builds when you follow the spin up, build, spin down philosophy.

Re:We do (5, Insightful)

Lumpy (12016) | about 4 months ago | (#46641103)

"cloud makes it not matter where you're working from."

Competent IT and VPN does that as well.

Re:We do (2)

NatasRevol (731260) | about 4 months ago | (#46641435)

While providing more security. Though not necessarily speed...

Atlassian FTW (1)

Anonymous Coward | about 4 months ago | (#46641009)

It's pretty easy to go with something like Atlassian Cloud to handle all your build stuff. It will fire off that various EC2 instances when you need them. It handles the basic deploys. Fairly reasonably priced.

What's not easy is setting up a secure EC2 environment that your production code will run in. I'm not saying EC2 isn't secure, I'm just saying you need to wear a lot of hats to really set it up well. You need to know network, firewall, unix, chef (or similar suite), messaging, storage NAS, and app server.

My experience with EC2 was it's cheaper if you had the skills to manage the environment and deployment (i.e. Chef). However, it becomes a lot less cheap if you have to buy a service to help you manage the entire EC2 lifespan (i.e. if something like Chef isn't clicking for the team.)

Mozilla (0)

Anonymous Coward | about 4 months ago | (#46641079)

Mozilla spends a fair chunk of change on the clown: http://armenzg.blogspot.com/2014/04/mozillas-recent-ci-improvements-saves.html

Your CTO is an idiot (2, Interesting)

Gothmolly (148874) | about 4 months ago | (#46641081)

He doesn't want to manage stuff in house because it's hard. But wait, that's his job, and why he draws C-level pay. If you are not just occasionally using it, the whole advantage of "cloud" goes away, unless you replace it with the concept of "outsource". Which might be his goal all along, either way, I would look for a new job. Cloud would be great if you needed to load test from 1000 machines or something, but even for that there are simulators.

Re:Your CTO is an idiot (5, Funny)

Anonymous Coward | about 4 months ago | (#46641201)

I think you're just failing to on-board the new cloud paradigm going forward.
You probably haven't accounted for the synergized trending advantages.

Re:Your CTO is an idiot (3, Funny)

Anonymous Coward | about 4 months ago | (#46641753)

I feel like I just read a week's worth of posts from LinkedIn connections.

Re:Your CTO is an idiot (0)

Anonymous Coward | about 4 months ago | (#46643677)

The key about cloud is agility not costs. In all companies where I have been the requirements for hardware changed. At least quarterly.
With ec2 I can just change the servers as needed and I am done. If I had on premise - operating & scaling & changing is a night mare for a small team.
Even bigger teams - that were using on premise hardware - for cost reasons - had to reject hard business requirements because they couldn't scale fast enough...
If you are big enough and have some predicatable usage, you can save money by running a hybrid cloud. on-premise for predicted demand. Cloud for unpredicted demand and new / changed requirements.

Just do it (3, Interesting)

hawguy (1600213) | about 4 months ago | (#46641113)

Amazon has a detailed AWS cost estimator:

http://calculator.s3.amazonaws... [amazonaws.com]

When we migrated to the cloud, our actual costs were within 15% of the estimated costs.

But really, the easiest thing to do is just build a test environment and try it -- you only pay for the time you use.

When we migrated to AWS we knocked 70% off our colocation bill (we had more space at the coloc than we needed, but it's hard to move production hardware to a smaller space without downtime, plus we had significant savings in equipment leases and maintenance contract costs).

Our dev/test hardware was aging and becoming unreliable (and no longer matched production since we moved to AWS), so we moved that up to AWS as well, but even after that migration our total AWS bill less than half what we paid at the colocation center. We only run the dev/test hardware during business hours, or on-demand as needed -- we set up a simple web interface that lets developers spin up test instances as needed. AWS keeps dropping prices, so we're even as we've grown, our costs have remained relatively constant.

The cloud is not magical. (1)

scorp1us (235526) | about 4 months ago | (#46641139)

I was just explaining this to someone the other day that thought AWS was going to save them money. It's not cheaper than running your own shop. The only advantage I see is that you don't have to house/cool/maintain hardware. You can just move your application to higher capacity, faster servers. You get additional power and network reliability.

If your dev/test platform is already off-site and working, then what is the compelling reason to interrupt everything and do the move? Where I am working today, the tried to move from AWS to Google's cloud and had tons of issues of reliability. We're back on AWS. Our usage model though, lends itself to AWS. We sell "application instances" which are deployed for customers to AWS for its up-time reliability. All our development happens in-house though.

It's not a magic bullet. If you're looking to save money and your place already has a cooled closet and redundant network and power, then it offers no incentive for you to move.

Amazon costs are relatively fixed (4, Informative)

Todd Knarr (15451) | about 4 months ago | (#46641145)

Amazon charges for instances by the hours they're running and the type of instance. Think of an instance as a server, because that's what it is: an instance of a VM. You can find the prices for various services at http://aws.amazon.com/pricing/ [amazon.com] . What you want are EC2 pricing (for the VM instances) and EBS pricing (for the block storage for your disk volumes. For EC2 pricing figure out what size instances you need, then assume they'll be running 720 hours a month (30 days at 24 hours/day) and calculate the monthly cost. For EBS pricing take the number of gigabytes for each disk volume (each EC2 instance will need at least one volume for it's root filesystem) and multiply by the price (in dollars per gigabyte per month) to get your cost. You can manage instances the same way you would any other machine, other than usually needing to use SSH to get access and having to worry about firewalling (these are publicly-accessible machines, you can't shortcut on security by having them accessible only from within your own network).

The cost isn't actually too bad. For generic Linux, the largest general-purpose instance will, for a reserved instance on a 1-year commitment, cost you $987 up front and $59.04/month for runtime in the US West (Oregon) data center. An 8GB regular EBS volume will cost you $0.40/month for the space and $50/month for 1 billion IO requests. And not all instances need to be running all the time. You can, for instance, use on-demand instances for your testing systems and only start them when you're actually doing release testing, you'll need to pay for the EBS storage for their root volumes but you won't have any IO operations or run-time while the instance is stopped.

The downside, of course: if Amazon has an outage, you have an outage and you won't be able to do anything about it. This isn't as uncommon an occurrence as the sales guys would like you to believe. Your management has to accept this and agree that you guys aren't responsible for Amazon's outages or the first time an outage takes everything down it's going to be a horrible disaster for you. Note that some of the impact can be mitigated by having your servers hosted in different regions, but there's a cost impact from transferring data between regions. Availability zones... theoretically they let you mitigate problems, but it seems every time I hear of an AWS outage it's one where either the failure itself took out all the availability zones in the region or the outage was caused by a failure in the availability-zone failover process. This all isn't as major as it sounds, outages and failures happen running your own systems after all and you've dealt with that. It's more a matter of keeping your management in touch with the reality that, despite what the salescritters want everyone to believe, there is no magic AWS pixie dust that makes outages and failures just vanish into thin air.

Re:Amazon costs are relatively fixed (1)

eric2hill (33085) | about 4 months ago | (#46641699)

For this particular use case scenario, it would be better to skip the EBS disks and use ephemeral disks with instances that are spawned purely for the build and test, check their results back into the build system, and self-destruct. You could even request spot instances since the workload isn't particularly time dependent.

You're right, if Amazon goes down, you're down without much recourse. But if you've designed your system to use instances that are launched on demand, you just launch them in a different availability zone and/or region. The odds that *every* Amazon datacenter goes down at the same time are extremely low.

Re:Amazon costs are relatively fixed (1)

Todd Knarr (15451) | about 4 months ago | (#46642589)

Non-EBS-backed instances aren't good for test systems. To run them you need to have an AMI built with everything you need, and you need to keep that AMI updated with current test cases and so on. That's more work than just maintaining an EBS-backed instance would be. Especially considering that you're going to need the test instance to persist for anywhere from several days to several weeks while testing is in progress. We aren't talking unit tests, remember, we're talking about a complete release test of the entire system end-to-end. Even for unit tests, you've got too many test cases that need to be maintained so they can be used every run, plus all the special test cases developers need while diagnosing and debugging issues. Having all of that evaporate when the instance is shut down defeats the whole purpose of testing, you're losing everything you'll need for the next test iteration. Unless of course you go to the trouble of taking everything in the instance and transferring it back to the AMI so that it'll be there the next time the instance is spun up, in which case why not just leave the instance on EBS and be done with it?

Re:Amazon costs are relatively fixed (0)

Anonymous Coward | about 4 months ago | (#46643021)

> The odds that *every* Amazon datacenter goes down at the same time are extremely low.

Yeah, except that it doesn't help you one bit if it is you (your internet connection) that went down.
It's quite a difference whether an internet outage means (more or less) only external mail and browsing doesn't work or that you can just send everyone home until it's fixed.

Re:Amazon costs are relatively fixed (1)

YuppieScum (1096) | about 4 months ago | (#46641989)

The downside, of course: if Amazon has an outage, you have an outage and you won't be able to do anything about it.

Not just Amazon - what if your ISP has an outage? Checked your connectivity SLA recently?

What's your plan if some joker puts a back-hoe through a fibre trunk 10 miles away? Road-trip to Starbucks?

I'm in the process of migrating my business (2, Interesting)

holophrastic (221104) | about 4 months ago | (#46641205)

I've spent over ten years on dedicated servers, and have been very happy. Over the next year, I'll be moving into a private cloud scenario -- (not amazon or google, yuck. A local datacentre rolling their own.) I'll have some dedicated hardware (physical servers: CPU, RAM), and be sharing the rest of the cloud (storage, power, network, et cetera.).

It's interesting because there are no actual benefits to me in terms of performance, capacity, stability, or price by moving -- even backups aren't any more fluid. Of course, my platform and business model have been well-tuned over the years, and my sub-industry doesn't have the fluctuations that are typically heralded by cloud services.

So why am I moving? Abstracted hardware. I've reached that point where migrating from one dedicated server to another is a major undertaking. It's days of work, weeks of testing, and a huge risk to my business if I were to move any significant number of clients at one time; that means spreading it out over a year which means paying for the old and the new at the same time with zero additional revenue.

I've got no problem with resource management and capacity planning. I just have trouble actually growing through the transition points. Moving to a private cloud is likely to give me the convenience of being able to upgrade physical servers instantly without any worries -- it's the virtualization layers and load balancing mostly.

Wish me luck.

Re:I'm in the process of migrating my business (1)

holophrastic (221104) | about 4 months ago | (#46641253)

Oh, in case that wasn't clear (it wasn't), my business is a web development business that builds-tests-deploys all live, and hence would be doing so on the forth-coming cloud service.

Re:I'm in the process of migrating my business (0)

Anonymous Coward | about 4 months ago | (#46643717)

You need more than luck. You sound incompetent.

what's the load you are moving? (0)

Anonymous Coward | about 4 months ago | (#46641209)

Zoom out and think about the economics. If the load you are shifting onto a cloud instance fills a machine or set of machines to their capacity -- i.e. little downtime between check out, build, validate, then I don't see the value proposition. There is a fixed cost to run a box flat out for a given number of years (hardware + care and feeding). I haven't checked in a while but the cost to rent resources in the cloud typically amounted to paying off an equivalent dedicate resource in something like three years. If you buy a resource and run it 5 years, it's cheaper to host it yourself. If the load you are moving to the cloud doesn't keep a system busy then renting may be a better option -- empty machines are expensive.

Re:what's the load you are moving? (1)

Etcetera (14711) | about 4 months ago | (#46641307)

If the load you are moving to the cloud doesn't keep a system busy then renting may be a better option -- empty machines are expensive.

Well, maybe. Physical space is obviously a fixed cost unless you feel like building a Japanese Car Park-style for moving Dell systems around, but you'd be surprised how well modern systems can be power efficient when they're told to.

The basics of suspending HW, using c-states, reducing CPU speed, etc, can take out a significant chunk of your power (and cooling, if applicable) cost. If you're virtualizing (even just Xen/VMWare), there are even more savings to be had.

You'd be surprised how many people hard code power settings to "Max Performance" at initial boot time and never go back to evaluate whether that's always really needed.

Ask on #openstack-infra (freenode) (1)

krotscheck (132706) | about 4 months ago | (#46641227)

The OpenStack infrastructure team is running largest cloud-based continuous deployment environment I've ever seen, and they're more than happy to give people introductions to it.

We Dev/Stage/Prod in AWS (1)

DarkSage (208892) | about 4 months ago | (#46641305)

We moved our development and production systems to AWS in 2008 and have been quite happy. It has allowed us to grow and scale with load on production and quickly test things in development. There a few things to keep in-mind. First, if you know your usage pattern and can drop some money upfront then utilize the reserved instances to save some money. Second, you will need a script management system of some kind to run on the virtual servers at boot/shutdown, I recommend using something like Rightscale or Scalr. Most importantly, don't do it without some experienced help for the setup, a day of a consultant's or system admin's time to walk through your migration plan with you will save you a lot of help down the road. Lastly, aws has a cost estimator that is quite helpful.

The real reason to not do it (-1)

Anonymous Coward | about 4 months ago | (#46641323)

We ran Jenkins on EC2 for a couple of years, and except for being slow as crap, it worked well. I don't think we saved any money because paying developers and QA people to sit around for hours waiting on Amazon's overloaded servers had to cost more than it saved. The reason our CEO had us waste so much time and money on Amazon was that the costs were highest in the 4th quarter just before our 1st quarter release. Given our highest quarter each year is the 4th, the books looked better by keeping server costs in the 4th quarter. That's the only reason it made any sense to do something that wastes so much employee time.

We got rid of it though because of the Republicans. Amazon gives full access to private servers to them. That's how they found-out our CEO was donating to support WA I-502. That caused us to lose several of our largest customers. As long as the Republicans continue to rule this country, you shouldn't ever put anything on an Amazon server. Also since then, our office has been broken into twice. That may or may not have something to do with Amazon's giving of data to Republicans, but I wouldn't doubt it.

Skytap and others. (1)

Anonymous Coward | about 4 months ago | (#46641333)

Have your CTO talk to Skytap. (I don't work for them, I've proposed this at my company) . This is one company, there must be others, who's main product is virtual dev. environments. I presume they run at Amazon. The whole environment can apparently be saved and immediately cloned. So it seems that they take server instances one step further, where there can be several of them in a private network and the whole thing can be versioned and cloned. (sorry for the anonymous, I'll get my login now)

Why would you need a cloud service? (0)

Anonymous Coward | about 4 months ago | (#46641343)

What purpose would a cloud service serve in this case? The best points about cloud services are high availability and reliability. Clients (customer or internal) can access the servers easily from anywhere, and you don't need to be concerned about practicalities like hard disks breaking (but do have a backup plan). The costs can be high, though.

About the Jenkins example, does it need the redundancy or availability provided by a cloud service? A simple setup would be a dedicated machine running the Jenkins jobs in the company's local network. If you need access from outside, just connect to the VPN that you probably already have. When the machine breaks (or a hard disk), just replace it, install the OS from an image, checkout the Jenkins configuration and put it running again. With a well-defined process this should be less than an hour of downtime, or a few days if you need to get the replacement parts. I assume all the data created by the Jenkins job is easily replaced by just running the tests again. If this is not the case, the process gets more complicated.

What I said about Jenkins may apply to everything else, too. Keeping the services running with only the occasional downtime is easy, the hard part is saving the data if it is critical. If your data is easily replaceable, using a cloud service may be overkill.

Not what cloud excels at (1)

AaronLS (1804210) | about 4 months ago | (#46641355)

Cloud is good for reliability, scalability, and if your particular scenario meets certain criteria, sometimes cost. Overall the cloud would be usually be more expensive, but can be cheaper to use cloud and only pay for what you need if you have short periods of high load combined with long periods of little load. Thus cloud might be cheaper because rather than paying for, cooling, powering, and maintaining alot of high end servers waiting to handle a large load only occasionally, you pay for what you need with the cloud. I would speculate you wouldn't see such savings on a single server.

If you could find a development/CI hosting platform that meets your needs, that would probably be a better bet. Such a service might be using cloud behind the scenes, but they benefit from the efficiencies of scale.

Another option is a semi-dedicate VPS. There are some VPS services that give you root access and terms would allow you to use the box as you do now.

I think someone went into this with the assumption that costs would go down using cloud, but your management time is going to be the same or more. You don't have a physical box, but now you will spend more time figuring out the nuances of your cloud host.

The key is to seperate the goal from the premature jump to cloud:
-If the goal is to get rid of the physical box, then VPS is an option.
-If the goal is to get rid of the physical box and lower management time/costs, then a hosted development/build/integration service is a good option. That way you don't even have to manage the OS, updates to the software/services, or perform backups.

Well, Yes (1)

CrankyFool (680025) | about 4 months ago | (#46641423)

Hi, I work at Netflix, you may have heard of us.

dev, test, build, and prod run on Amazon (leaving aside the actual streaming, which comes from cache boxes closer to the customer). We've been pretty public about the process, and some of the issues.

Just going to answer the titled question (1)

jtnix (173853) | about 4 months ago | (#46641477)

Yes.

But as someone else suggested, it sounds like you need a CTO upgrade to go along with your migration to the cloud.

Re:Just going to answer the titled question (1)

Hognoxious (631665) | about 4 months ago | (#46642721)

Get a mauve one. They have the most RAM.

Don't do it. period. (2, Informative)

The Joe Kewl (532609) | about 4 months ago | (#46641495)

We did this at my last job.
In short, it sucked.

More descriptive: It really sucked!
The boss didn't want to manage servers in house to save costs. So as a developer, we had to show up every day, boot our cloud instance up, sync the latest code to that instance, and begin development. Then before going home, you needed check in your code, shut down the instance, and go home.

Doesn't sound so bad, except for the time you had to waste EVERY DAY logging into AWS, booting the EC2 instance, restoring the RDS instance, syncing the code, doing basic readiness tests BEFORE you could even begin working.
Then there was always the fun part of the dev team leader changing out which RDS instance you needed to use, and forgetting to tell you about it.

Not to mention the time you (the developer) had to waste every day shutting down (syncing / checking in code, creating snapshots, closing RDS instances down, etc, etc, etc).

Then there is always the fun times when the cloud was down (yes, it DOES happen people!) or the internet connection was down (ISP issue, internal LAN issues, etc)... All of the time wasted managing the cloud instances (starting up, shutting down each day) could of been spent actually fixing things, and writing code, but I guess that wasn't cost effective enough for them.

Re:Don't do it. period. (1)

bmajik (96670) | about 4 months ago | (#46641899)

Why didn't you script all of the activities you just described?

Re:Don't do it. period. (1)

The Joe Kewl (532609) | about 4 months ago | (#46642257)

For starters, it was on a winblows environment (at least in the beginning).
Mostly though, we were not given the time, and we were not allowed to work on un-approved projects.

Besides, can your really script the ass hat of a lead dev changing RDS images / instances without telling you?
Scripting is no help for the cloud going down either, not to mention connectivity issues.

In short, I am happy to be outta there, that could have possibly been the worst communicating "team" I have ever had the displeasure of working with.

Re:Don't do it. period. (0)

bmajik (96670) | about 4 months ago | (#46642535)

Funny you mention that.

Early in my Microsoft career, I built a system that provisioned thousands of windows machines on an as needed basis, differing by SKU level, language type, windows version, etc.

I'm was proficient in scripting the installs of windows machines -- even back when windows didn't natively support that sort of thing very well(e.g. NT4)

To be honest, Windows looks pretty good compared to any Linux distro I've worked with when it comes to automated provisioning and post configuration. That's a subjective comparison, of course, so I'll just say: I don't think windows was your problem.

It sounds like your management wasn't especially visionary nor technical, and that you failed to make an adequate business case to them regarding how much productivity the team would gain in the long run if you worked to automate these repetitive tasks.

That's a shame. I'm glad you moved on to greener pastures.

Try Heroku (1)

akubot (1285646) | about 4 months ago | (#46641631)

If you are nervous about costs and overhead time required, you can try out some small apps on a PaaS site such as Heroku https://www.heroku.com/ [heroku.com] Then graduate to doing it on Amazon or whatever, once you figure out what you need or don't need, or don't want to be bothered with.

How is it different? (4, Insightful)

msobkow (48369) | about 4 months ago | (#46641697)

When working for companies, everything was "in the cloud" already: on remote servers. It's not like I was running the stuff on my desktop.

SSH to Amazon or SSH to a box in the closet. Pretty much no difference to me.

Re:How is it different? (1)

bananaquackmoo (1204116) | about 4 months ago | (#46643073)

Your closet is a lot closer and quicker to reach.

From experience: no (1)

overnight_failure (1032886) | about 4 months ago | (#46641741)

So, cloud hosting is expensive versus standard hosting, you pay a premium for scalability. Simple as that.

My two cents . . . (2)

Kimomaru (2579489) | about 4 months ago | (#46641795)

Data center operations are expensive when you factor in power, gear and staff. But I don't think cloud solves those problems particularly well and it actually adds some more. Cloud data sits on someone else's secondary storage, and if you don't understand the implications of this you are not thinking hard enough. I think the decision to use cloud varies on a case-by-case basis and that you just have to measure it for yourself. It might make sense for development, but maybe you don't want your code on someone else's systems, for whatever reason. I like to write code on my cubieboard, an SoC platform that runs on 5 volt - runs Debian, can mount a laptop hard drive on it, has a dual core proc on it. Runs great for its purpose. If I try to do the same thing on a cloud system (and I have), the cost rises dramatically. But you can't run a high traffic web site off of a cubieboard. There's a line where cloud begins to make more sense. Depends on what you're looking for. But it won't replace the data center.

Grow effective leading-edge infrastructures (2)

mbaGeek (1219224) | about 4 months ago | (#46641829)

didn't I just read somewhere about Google [slashdot.org] doing something with this enterprise cloud thing?

the answer to the question is "it depends" - my gut says "no" but as others have pointed out, if you want to know if something will be a cost effective solution, you need to test

the game changing benefit of the "cloud" is the ability to scale up/down as needed ... SO from a financial viewpoint the question is similar to "Should we buy a building or rent office space?"

BTW my headline is from a Dilbert gobbledygook generator - which I'm 90% sure that 100% of CTO's use an undefined % of the time

Do both (1)

trajano (220061) | about 4 months ago | (#46641935)

I would recommend doing both. There are significant advantages of moving some of the development/test tools out to the cloud. However, it should only go as far as development and perhaps first stage testing which is probably what your CTO has in mind.

There's no reason why each development project has to pay for the physical space taken up by *shared* development tooling such as Jenkins, Common Git Repository, JIRA/Redmine/Trac and some database and application server that is used for functional testing.

However, a proof of concept system must be present locally even if it is a limited capacity otherwise you'd be wasting a lot of bandwidth going back and forth.

It would also help to design your application architecture so that you can theoretically run everything on a laptop (and provide a powerful laptop to do it). For the developers.

If your'e an IBM shop, you may want to look at JazzHub to manage things for you.

Standing up a new cloud and don't count hours... (1)

NoOnesMessiah (442788) | about 4 months ago | (#46642149)

I'm in the process of standing up a new cloudy little provider and we don't count hours or minutes. Is that so wrong?

The assumption is that the Internet is open 24/7 so why should we be marking time when we know you want it 24/7? We would rather cultivate the developers and geeks as customers. We'll soon have one portal for instant gratification but we're also happy to hand-craft VMs in a private place for you too. And it's built around CloudStack4 so it should feel familiar to many.

Come talk to us while we're young and dumb, before we figure out that our prices are too cheap. 20Gb/s out to the net, BGP/4, IBM BladeCenters for hardware, and we also rent bare metal. Anything from 1vCPU/512MB up to 336 CPUs and 10.5TB of RAM in bare metal if you're willing to pay for it.

http://www.blinkinblox.com/

Disclaimer: Yup, its a commercial plug. I'm pretty much both the King and the garbage man.

Re:Standing up a new cloud and don't count hours.. (0)

Anonymous Coward | about 4 months ago | (#46643467)

This is fucking awesome!!! Just kidding.

Do not do it (1)

TheDarkMaster (1292526) | about 4 months ago | (#46642229)

Do not do it, period.

Network connections are not reliable enough for that, cloud services can (and will) go offline and the worst part, you will be putting your code on a external server on which you have no control. Your secret, revolutionary code free to NSA industrial espionage or worst. NEVER put important/sensitive data on a cloud.

Yes, we do so (0)

Anonymous Coward | about 4 months ago | (#46642315)

We're doing so and I would never go back after the experience. We automatically spin up CI tests for each push of a branch, can bring up sites on demand, etc. We feel free to actually branch as desired, and we can spawn as many sites as we need for any manual testing as desired. The larger you are the more benefit you'll see, but if you put some time into the infrastructure surrounding it, you will be happy. Our purpose is to develop and enhance features, not mess around with if we need 10 or 1000 test machines today. I can create a site from any given branch or start tests on any given branch in less than a minute with the extra infrastructure we've built. Once you realize how many internal headaches can be cut away, any cost for the cloud becomes trivial in comparison, making it an easy decision.

Why do this? (1)

GameboyRMH (1153867) | about 4 months ago | (#46642319)

Because the CTO can spin this to the CEO as being technically better somehow while getting kickbacks from the Amazon sales rep ;-)

Visual Studio 365 Azure Edition (4, Funny)

turgid (580780) | about 4 months ago | (#46642339)

Yes, we use Visual Studio 365 Azure Edition for our C++ projects. Our compile times are a little longer, but we're riding the latest wave of post-Enterprise active data web cloud assured technology.

This gives us all the advantages of future web technology developments as they happen with Microsoft's world-leading Software Engineering/Code ARTezan(R)(TM) Cratfperson paradigm.

As a bonus, all of our best-shored development consultants were able to migrate their legacy Visual Source Safe projects seamlessly using cloud-aware IE plugins.

Re:Visual Studio 365 Azure Edition (0)

Anonymous Coward | about 4 months ago | (#46643497)

This fucking double awesome!!!

Re:Visual Studio 365 Azure Edition (1)

Monkius (3888) | about 4 months ago | (#46643687)

You rule.

Don't be the cloud service, be the cloud server. (0)

Anonymous Coward | about 4 months ago | (#46642349)

Define "cloud" - If it means data that passes through the wavy outlined 'cloud' of uncertainty in the network diagram, no. If you mean a distributed computing solution, then yes.

In house "cloud" is the same as the remote "cloud", except that the uncertainty is removed and thus the iteration speed for the system's construction and refinement is faster. I do several contracts a year building such systems for CTOs who are somewhat clueless, but fortunately have an ace-in-the hole that always makes them look good: Me.

I am the cloud, an unknown, invisible, buzzword-compliant deployment AND documentation guru so who seeks neither fame, nor job security (hence the impeccable docs). I wander the skies among your ivory towers and for a moment obscure your vision, of the highest floors, leaving apparent heroes who have "saved the day" in my vaporous trial.

Once your continuous build, test, deployment systems are migrated to the core system, they can be quickly distributed in house, and the kinks worked out much faster than tackling the a more grand solution, THEN, I can easily knit the structures together across the globe, even as deployment systems to your clients themselves at an unbeatable price. I can graze wild blue yonder and because I'm not greedy, I don't crave acknowledgement. I don't mind holding the wires for your crack team of superheroes flying high in the sky beneath me as I drift silently along.

Only realize the truth: There is no cloud.

iterative migration (0)

Anonymous Coward | about 4 months ago | (#46642627)

need a proof of concept first? though the workflow is far more simple then the old skool you are asking for.
https://www.openshift.com/

missing functionality? or want the oldskool? add it as you wish.
http://openshift.github.io/documentation/oo_cartridge_developers_guide.html

costs (0)

Anonymous Coward | about 4 months ago | (#46643613)

The promise of OpenStack is that it can abstract the infrastructure layer so companies get control over costs and the hardware used. (source: http://www.zdnet.com/red-hat-ceo-whitehurst-on-innovation-openstack-hadoop-7000015292/ - year ago)

Outsourcing 101 (0)

Anonymous Coward | about 4 months ago | (#46642667)

Step 1: Put everything on the cloud... Step 2: Fire American programmer... Step 3: Hire sweat-shop workers

not cheap at all (1)

yalos (1724482) | about 4 months ago | (#46642709)

Amazon is not cheap at all for your task and I am not sure you are looking into the right direction. In the last year I was doing feasibility studies for software in the cloud and I implemented already a system that relies on Amazon 100%. I have evaluated various technical solutions and various providers. My findings are the following: 1. Amazon is second to nothing when it comes to be elastic. If you want to scale from 10 to 100 (you name what you count: CPU/Memory/Storage/Band/DB...) you will have it in a minute. They can scale you inside the box and outside the box and this works perfect. Not the case with other cloud providers. 2. You get the goodies from 1 on a very hefty premium. Going on Amazon is more than twice more expensive than renting an enterprise class server in a datacenter. If you are not so fussy about the brand of the server this can be even 4 times more expensive. Of course you are on your own on the rented servers. All the maintenance is yours. For the kind of setup you describe this can cost you some money with the labor and it might cut the margins. 3. If you choose to use rented hardware the best is to use them as virtual machine farms. It might look awkward to have a machine that runs as visualization server only to one single virtual machine but this gives you that huge option to move the virtual machines as you see fit. It looks to me like the elasticity is not your most important goal so it might happen you will be better on rented hardware. And again you must know that, after all that study, in my case I went for Amazon. Still, I need that elasticity...

Solano Labs is helping people in this space (1)

teooet (719881) | about 4 months ago | (#46642711)

They are very new but I've worked with the founder, Jay Moorthi and have nothing but good experiences with him. Maybe I'll ping him to come and give an overview of how they help. https://www.solanolabs.com/ [solanolabs.com]

Missing the point (0)

Anonymous Coward | about 4 months ago | (#46643589)

The point of cloud services is that you provision things as you need them. That means that everyone can test at the same time - with no conflicts - because everyone has whatever test instances they need.

But don't do development in the cloud: do it on your laptop. Every developer needs to have the whole application stack on their laptop/desktop for development and for running the integration (using mocks) tests locally. Then if your code changes work, check them in (to a cloud-based repository). When the code is checked in, Jenkins can build it and provision a cloud based testing environment on the fly and run all the integration tests with real (non-mocked) resources.

That way no one every has to worry that their tests interfere with someone else and you don't have to maintain servers to test against.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...