Cloud Development is Painful (but necessary)
30 March 2016, by Chris Arnott
So you want to move your application to the cloud? Well is that really the right thing to be doing? There are lots of pros and cons for using cloud services rather than physical servers. In this blog post we’ll discuss some of the different aspects to consider before taking the leap.
If you want to move to a cloud, you’ll have to choose one. All of the big cloud providers will let you deploy standard VM images, with a range of different specification (CPUs, RAM, etc.) but in order to get your code running on one of these you need some method of deployment. This is where you need to be careful. It’s probably going to be possible to get your code running on the machine in a generic way using ssh/scp and a package manager like artifactory. All fine so far, but the problem comes when you start taking full advantage of the cloud and using all of the ancillary services. These will all have their own APIs for configuration, and if you (sensibly) automate all of this configuration for your app, then you’ve now got platform specific code. One possible way of avoiding this would be to use a library like libcloud, but if you’re not careful, this will add cost when moving providers in the future.
This will depend on how popular and compute intensive your application is. Cloud servers are supposed to be cheap, but if you need multiple large instances the costs can rack up quickly. You’ll also need to start paying the cloud costs while you are doing development and testing. The alternative is to pay a hosting company to house a physical server for you. But then you’ll be paying them for the hardware as well as an ongoing cost for support, and if something goes wrong, you’ll be phoning them up rather than just re-creating your misbehaving server. This could be a pro or a con for moving to the cloud. You’ll have to make the call based on your requirements.
If you’re starting a new project and are making the decision between cloud and non-cloud, then this section won’t have much impact. However, if you already have a project and are trying to decide if you should move across or not, you’ll need to consider your deployment process. Brownfield projects typically have a long list of steps you need to take to ensure your deployment goes smoothly. If you move to the cloud you will want to automate all of these steps (options for this include puppet, chef, docker and saltstack, among others), so that you can have a one click deployment (or even better continuous deployment). If the project is long running or particularly large, automating the deployment is probably going to be a significant task, so don’t forget to plan for it!
Separation of services
Cloud providers separate all of the different services that they provide so that you can pick and choose the ones you need. This is great from a separation of concerns point of view, and will force your developers to think about where their data is coming from. This encourages a move towards micro-architecture which is easier to maintain, and lends itself very well to cloud environments. However, if you are moving an existing project into the cloud, there are going to be things in your code that explicitly rely on a service being local, when the cloud expects it to be elsewhere. If this sounds relevant to you, investigate high availability versions of your local resources (Cassandra, Swift, etc). This is something you’ll have to think carefully about before embarking on any work.
Low level infrastructure knowledge
Don’t know your volume group from your logical volume? Not sure how to add and remove rules from iptables? Not sure which is best out of Hyper-V, Xen, and KVM? Well the good news is that if you use the cloud you don’t have to! Cloud solutions take all of the low level hardware and OS configuration, wrap it all up, and present you with a high level interface to use it. This is great, as it means your devs don’t need to learn it all, and neither do you need to hire a devOps employee to learn it all for you. However, if you decide build your own cloud (something I’m mostly avoiding talking about in this post) using something like OpenStack, then be prepared to either hire someone who already has experience with all this or spend a significant amount of time (weeks) ramping up on it and making all the common mistakes.
Stateless web servers
Stateless servers are easy to manage. If you want to harness automatic scaling (see below), then you’ll need to make sure that your app is doing the majority of its processing in a stateless manner. This means that your app needs to be able to cope with any request landing on any server. The best way to deal with this is to use a high availability backend. This allows you to store all your data in a pool of servers, and thus, any processing server can access this pool to retrieve data and process it. If you want a bit of a performance boost, you can use sticky traffic on your load balancer in order to spread out clients rather than individual requests. This allows you to harness caching at a server level, but without losing the benefit that if the server dies requests will continue to work as expected.
Automatic scaling is the process of monitoring your existing stateless servers (see above), and creating more of them when they are busy (or removing some when they are idle). This is a major pro of the cloud, but it only kicks in if you’ve got a large application. Implementing this means that you don’t have to spend loads of money overnight when no one is checking your site, but when you launch that new competition and everyone wants to enter, new servers will magically appear to deal with all the load.
Snowflake servers are bad. They’re full of configuration that someone set up long ago and forget to tell anyone about or clearly document. The cloud won’t let you get away with that! Need Java installed? Make sure it’s part of your build process. Need to configure your web servlet to have lots of specific values to work with your app? Make sure all the config is checked in, and deploy it along with the app. The cloud will force you to have reproducible servers, which is great news, as it means if there are new devs moving onto your team and they need their own box to do some disruptive testing on, it’s going to be really easy to set one up. The first time you try to get your brown field app running on the cloud however, will be painful. There will be lots of things missing, and no one to point out where that missing config value is.
So in summary, by moving to a cloud you’ll get some brilliant new features that will help you run a large website (with the ability to make it larger at short notice). However, there are multiple factors which need consideration as to how your application is structured both on a singular level and a higher architectural level. It is important to consider all these things when creating your app.