To use or not to use… Cloud Services

  • May 6, 2016


Recently we’ve been asked to help to decide whether a client should move all their deployment cycle to a cloud provider, or keep some parts In-house, specially Continuous Integration / Continuous Delivery (CI/CD) tasks.

This gives me the opportunity to think about a broader matter rather than a particular case. Nowadays it is really common, especially for startups, to delegate many key infrastructure services to cloud providers, most notably the e-mail. It’s getting rarer to see small to medium companies that have servers running Zimbra, Postfix, not to mention MS-Exchange. Most of those companies now recur to services like GMail.

Disclaimer and background on me

All of the tools mentioned in this text are just that, tools, and we shall not become a tool fundamentalist, which is not easy since tools help us to get the job done, and believe it or not, one gets attached to them.

Also, I’m an infrastructure guy that comes from the Free/Open Source world, so I like OSS tools and I like to have as much control over my infrastructure as I possibly can, so my opinion is biased towards using tools that I can control.

Jenkins a.k.a In-house solution

Jenkins is the flagship software for CI/CD suite in the Free / Open Source world (FOSS).

For all intents and purposes it is a standard service that runs in your operating system of choice, even windows.

By standard I mean a classic service. You have to deploy yourself by whatever means you see fit, either automated or not, in a bare-bone server, a VM in any virtualization service, or even in a cloud service like DigitalOcean or Amazon’s AWS. When deploying Jenkins you have to do it all by yourself: backups, resources check, performance, and such.

The tradeoff is that you get total freedom, you can do whatever you want with it, you can deploy it with any plugin you want. You can use whatever authentication method you like, use whatever plugin is available, you can even use no plugins as there’s no limit to its extensibility. For example, on the notifications side, you can connect it to Slack, Flowdock, Hipchat, get it to send you emails, SMS, phone calls or send you pigeons if you know how to implement that -it does not pretend to tell you how to do your job.

So basically you are free to do whatever you want, I stress the “you” part of the last sentence, you can hire someone to do it but it’s not a turnkey solution, it’s a piece of software that has to be deployed and implemented by your organization.

The underlying idea here is: ‘You want freedom?’ ‘Good, work for it.’

Cloud-based solution

On the other hand we have cloud-based services. Here you don’t have to do anything but use it, it’s a turnkey solution. You only have to learn its ways and use it.

The provider will take care of everything: updates, patches, performance, escalation, the lot. They won’t bother you asking to keep your software up to date nor ask permission to change anything, they’ll just do it whether you like it or not. Since you don’t own the platform you cannot but suggest changes, and they can choose to pay you attention or not.

Also if there’s something you don’t like you cannot change it, your organization or workflow must adapt to your provider’s intended workflow. In most cases it’s fine since they don’t look to annoy their customers; they’re constantly looking to improve the User Experience (UX), but again you can only make suggestions. And finally, if something goes wrong or breaks you don’t have to take care of it, they do, but if something goes wrong only for you then you depend on their service support, and generally speaking that can be a hit or miss situation.

The Privacy

I could have mentioned this earlier in the article but I think it’s so important that it needs to have its own section. Let me be clear on this:

Information is power.

Why do you think that so many cloud-based services are free?, why is Facebook free?, why is Youtube free?, oh yes!, prepare your tinfoil hats… easy, they’re a very sophisticated intelligence-gathering machine, and yes, I used the word intelligence that’s so commonly associated with the military and state intelligence agencies, but I don’t imply (necessarily) that these products gather information specifically for these kinds of governmental organizations, oh no, they just gather it.

If you think how these products make money you’ll see that they make money through selling ads, and to be effective at that they need to target an audience and to target an audience they need intel (intelligence), and to gather that intelligence they analyze you, your data and your behaviors. If you read most of their services terms of usage you will see that your data is no longer yours when you upload it, it’s theirs.

“But… wait, I’m paying for that!” you say, and yes you’re right, on most of those services service agreements don’t include that clause but they still have your data which they can access. I won’t cite public knowledge cases where agencies asked to retrieve private user data saying that national security was at stake, but the information is out there.

To give this section a closure, even when they say they won’t look at your data, they can, their employees can and eventually someone will.

Final thoughts and/or conclusion

First I must say this: You can achieve the same results using both approaches, the experience may vary, and depending on the implementation the efficiency can vary as well, but the results are more or less the same. Now, on with the conclusions.

To use a In-house solution gives the power to do pretty much whatever you want, however you want it. With the additional advantages of controlling your own data, no 3rd party with access to it, and no 3rd party with the power of denying you access. But this brings another set of problems; sometimes you’re not sure what’s the best approach to get the results you’re looking for, thus the In-house solution can be a double challenge: First you have to get your product out of the door and second you have to tune the machinery to actually produce it and produce it efficiently.

On the other hand, using a cloud-based solution or one owned by someone else, produces a different set of challenges. They might pose a different learning curve, perhaps more gentle at the beginnings, with one big caveat, well, one big caveat functionality-wise – that the limit of what you can do is decided by someone else outside of your organization. One of the biggest trade offs you have to accept when using someone else’s services is that they have complete control over your own data, more control that you have. They control the access to the resources and they hold backups and the physical access to them. For some organizations like governments (ask Germany, Brazil and the list continues if you don’t believe me) this is not acceptable.

Perhaps you noticed I am not mentioning costs. The reason for that is to avoid making this article longer than it currently is, because they are not linear and require a complete separate analysis.

So, you have to choose: Do you want to have the flexibility or the convenience? You need to decide if you would like to do it your way or if you would rather like to get going quickly. Perhaps you don’t want to even think about maintaining the infrastructure and you feel comfortable letting someone else have more control over your own data than you. Or maybe you want to have your infrastructure tailor-made because you know that no cloud provider does it the way you want.

To close the article I will say that being in favor of using cloud-based services or not, or being self-reliant just boils down to a matter of choice, it’s just a choice, but a rather tricky one.