So far, I’ve been talking mostly about the good that has come out of our move to the cloud for hosting and services on SSWUG.ORG (and vConferenceOnline.com). But of course there have been some lessons learned too.
Along the way, we’ve learned quite a bit about how to, and perhaps not to, do things in the cloud. Here are a few of the bumps and bruises we’ve learned from as we’ve implemented different things.
Cost Control
Perhaps the biggest gotcha is cost. Not in the “everything costs more” type of situation, but more in the “it’s REALLY easy to forget to turn off a feature, or shut down and image or enable a feature and then it takes off unexpectedly well. Each of these can lead to some real surprises cost-wise.
I mentioned previously that it’s wicked-simple to set up a new system (literally just a few clicks) to test and environment or update and make sure all is well. But it’s still a few clicks away to shut it back down too. So many times, we’d set up the test environment and do our testing. We’d discover a change that was needed before we went live and go about doing that change. Two weeks later, we’re still cycling through this process and the instance is still up, taking nourishment and our money. Certainly not a “problem” with the cloud, but one of too convenient.
We are now very careful to review running services and running instances to make sure we’re shutting things down. We’re also more meticulous with our comments on the services and instances so we can tie it back to a specific project or effort – so we can verify whether it should be up and running.
Further, check into reserved or committed instances. They can save you big money by agreeing that you’ll have the server up for a year (or more) – it can really help trim down your bill and this is true on Azure and Amazon AWS – and other platforms that I’ve checked into as well.
Architecture Must Change
Thinking you’re just going to move your hosting to that VM in the cloud and let it be is short-sighted and painful. We made this mistake early on and paid dearly as we worked through re-architecting to take advantage of services, options and capabilities in the cloud. This cost us quite a lot in time and functionality early on. It’s one thing not to use all of the services of your provider (who could?!) but it’s another to ignore the fact that there may be many best of breed choices to select from that you can consider for your environment.
We found, as we rolled out different services, that it was better to take the time up front and cherry pick the things we needed to provide leverage (messaging services, storage, databases, etc.) rather than stumbling around them during implementation.
Provider Lock-In
Yep, I said it. As you use more and more of the features of your provider, I don’t care who it is, you’ll find that you’re more and more locked in to their services. For the most part, this is an early-on choice – which provider you’ll use. But if your requirements are evolving and maturing and using more and more features available, you may find that this lock-in becomes a hinderance to some things you want to do, or at least want to do a certain way.
There can be stark differences between providers on implementation of seemingly similar technologies. Streaming, messaging, databases, VMs, security, SSL, management tools – all of that comes together to make your installation successful. Make sure you take the big picture AND direction of the provider into account, not just the 5 features you need today. We were surprised at just how specific the implementation details were/are for some features and how difficult it could be to maintain some independence if we wanted to.